DOCUMENT: FF-883
REVISION: FS 1.2
DATE: December 8, 2005
Resolution List
No. Description of Resolution Affected
Sections
AR1519 Editorial Error 4
DISCLAIMER OF WARRANTIES
This document is provided on an “as is” basis and may be subject to future additions, modifications, or corrections depending on the results of
field trial testing. The Fieldbus Foundation hereby disclaims all warranties of any kind, express or implied, including any warranty of
merchantability or fitness for a particular purpose, for this document. In no event will the Fieldbus Foundation be responsible for any loss or
damage arising out of or resulting from any defect, error or omission in this document or from anyone’s use of or reliance on this document.
System Management Addendum Fieldbus Specifications FF-883 FS 1.2
Table of Contents
1 Scope............................................................................................................................................................................................................1
2 Overview.......................................................................................................................................................................................................2
2.1 Host Procedure .....................................................................................................................................................................................2
3 Common Software Download Specification .............................................................................................................................................5
3.1 Device Download Classes ....................................................................................................................................................................5
3.2 Common Software Download State Machine .......................................................................................................................................5
3.2.1 State Diagram ..............................................................................................................................................................................6
3.2.2 State Transitions ..........................................................................................................................................................................7
3.2.3 State Machine Events ..................................................................................................................................................................7
3.2.4 State Machine Functions..............................................................................................................................................................8
3.3 Download File .....................................................................................................................................................................................10
3.3.1 Description .................................................................................................................................................................................10
3.3.2 File Name...................................................................................................................................................................................11
3.3.3 File Format .................................................................................................................................................................................11
3.4 Device ID Format ................................................................................................................................................................................11
4 System Management Information Base Additions .................................................................................................................................12
1 Scope
The purpose of this specification is to allow the field devices of any manufacturer to receive software upgrades from any host. The
software upgrade for a device may consist of one or more binary images. The following sections describe the procedure for downloading
one or more binary images without regard to their purpose or content.
This Common Software Download Specification (CSDS) is independent of the device architecture. The specification only specifies the
services, objects, and the object behavior associated with downloading software to a device. It does not address system issues such as
security, user interfaces, etc. This addendum does not preclude alternate means of upgrading software. The format of the binary image
(syntax and semantics) is outside of the scope of this specification. Vendors may have proprietary syntax and semantics in this image to
support, for example, incremental downloads or downloads of specific blocks.
Support for this Common Software Download procedure is optional.
2 Overview
The Common Software Download procedure was created to allow the field devices of any manufacturer to receive software upgrades from
any host. Software upgrades may be partitioned into separate downloadable images.
The following paragraphs describe a protocol for the download of binary images without regard to their purpose. The concept of “Device
Family” is introduced as a means for associating binary images with devices. This allows alternate binary images to be associated with a
physical device, thus allowing the Device Type of the device to be programmable, rather than being determined by the physical hardware.
The format of the file that contains the binary image is also irrelevant to the procedure, with the exception that a common header in the file
precedes the binary image. The purpose of the header is to assist in avoiding the download of images incompatible with the device.
The format of the binary image (syntax and semantics) that follows the header is outside of the scope of this specification. Vendors may
have proprietary syntax and semantics in this image to support, for example, incremental downloads or downloads of specific blocks.
The software download procedure is designed for use in both H1 and HSE devices. It uses the Generic Domain Download services defined
by FMS [FF-870] and FDA [FF-588]. Objects are added to the H1 or HSE System Management Information Base (SMIB) to control the
download.
In addition, the CSDS supports a range of download capacities. Simple devices may be upgradeable through the download of a single file,
while other devices may support the download of a set of files. Still more complex devices may support more than one set of download
files. A PC-based HSE device with separately downloadable cards, each with multiple domains, is an example of such a device.
When a device download consists of a set of download files, then all files in the download set are described by a MultiDomainDescriptor.
To support the software download the device shall implement
a) the System Management Information Base objects defined in Section 4,
b) the FMS Generic Download services in a server capacity on the standard management VCR (see the FMS Specification [FF-870] and
the HSE FDA Specification [FF-588]),
c) the state machine defined in Section 3.2.
For example, the user may determine that the function block software for a specific transmitter is to be downloaded. If the host user
does not know which domain in the device is to receive the download or which software is to be downloaded, then the domain
descriptors can be read from the device. Each descriptor contains to the OD Index of the Activated Domain Header. The Activated
Domain Header contains the manufacturer id, the device family, the device type, the software revision, the domain name, and the
software name that describes the currently active (executing) binary image. The domain name indicates the use of the domain, and
the software name identifies the function of the software that has been loaded into the domain. The name of the file that contains the
binary image is constructed using these elements (see Section 3.3.2).
In addition, the user may wish to download a specific card in a device over HSE. In this case, the user would locate the appropriate
Multidomain Descriptor to determine the Multidomain Mfg Id and Multidomain Family. Using these two, the host can locate the files
associated with the card.
2. After the user selects the device and the binary images to download, the host may examine the header field of each domain to be
downloaded to ensure that it can be downloaded to the device. It does this by comparing the manufacturer id, the device family, the
device type, and the domain name contained in the file name to those contained in the device’s domain header. If the download file
provides new capabilities for the device, the host may find it necessary to examine the new Capabilities File for that device. In
addition, host systems may allow the override of these checks and permit a single binary image file to be downloaded to a family of
device types.
3. Before beginning the download, the host determines the download class of the device by reading the DWNLD_PROPERTY SMIB
attribute. If the attribute indicates a Class 2 or Class 3 device, the host may take the device off control before continuing the download
procedure.
4. If the device is a single domain device, as indicated in the SMIB directory header, then the host proceeds to the Step 5. If the device
is a multi-domain device, the host ensures that it has selected a complete set of files to download. It does this by selecting all files for
the device with the desired software revision for each file. It then reads the Multidomain Descriptor attribute, to determine the current
download state of the device and to determine if it can download more than one Multidomain Descriptor at a time. Then it reads the
appropriate Multidomain Descriptors, and performs the following sub-steps for each:
4.1 If the value of the Command element is “IDLE”, the host writes “BEGIN” to it to begin the download procedure. Receipt of a
positive response from device indicates to the host that the device is ready for the download procedure to start.
4.2 If its value is “BEGIN”, the device is currently downloading. In this case, the host can write “END” to it to cause the device to
terminate all download operations. Any domains being downloaded when “END” is received are terminated as though the host
had written the value “CANCEL_DWNLD” to the “Command” element of the DOMAIN_DESCRIPTOR SMIB attribute for the
domain. Then, the host can read the value of the MULTI_DOMAIN_DEVICE attribute periodically until it changes to “IDLE”.
Once the download procedure has started, the host may write “END” to the MULTI_DOMAIN_DEVICE attribute to terminate the
download procedure.
4.3 If its value is “END”, the device is currently completing the download. In this case, the host should wait until its value transitions
to IDLE or to one of the activate error codes. Alternatively, the host can write “ABORT” to it to force the device to “IDLE”.
4.4 If its value one of the activate error codes, a previous download has failed. In this case, the host should evaluate the failure and if
appropriate write “ABORT” to it to force it to “IDLE”.
4.5 Once its value has been confirmed to be “IDLE”, the host can proceed to Step 5.
5. The host then begins downloading and activating each of the domains individually. For each domain:
5.1 The host obtains the OD Index of the Download Domain for the binary image to be downloaded. The header of the binary file
contains the Domain Name of the domain, and the host matches it with the Domain Name of one of the DOMAIN_DESCRIPTORs
contained in the List Of Domain Descriptors composite object in the SMIB. The DOMAIN_DESCRIPTOR contains the Download
Domain Index.
5.2 The host then examines the ”State” element of the DOMAIN_DESCRIPTOR of the domain to verify that the domain is in the
DWNLD_NOT_READY state. If it is, the host can continue the download procedure. If not, the host can drive the domain to that
state by writing the value “CANCEL_DWNLD” to the “Command” element of the DOMAIN_DESCRIPTOR.
5.3 The host then writes the value “PREPARE_FOR_DWNLD” to the “Command” element of the DOMAIN_DESCRIPTOR.
Unconstrained devices will clear the memory used for the download image and enter the DWNLD_PREPARING state for the
domain. Class 3 (memory constrained devices) may reset, make memory resources available to support the download and enter the
DWNLD_PREPARING state for the domain. This may cause the device to abort the VCR, requiring the host to reestablish it.
Some Class 3 devices may not return a Write Response indicating that the “PREPARE_FOR_DWNLD” value was written
successfully. A bit in the DWNLD_PROPERTY SMIB attribute indicates whether or not the device returns this response.
5.4 The host then periodically reads the “State” element of the DOMAIN_DESCRIPTOR to detect when the device has transitioned
the domain from the DWNLD_PREPARING state to the DWNLD_READY state. If the domain has not transitioned to this state
(or if the VCR was aborted and the host was not able to reestablish it) within a timeout period specified by the
DWNLD_PROPERTY SMIB attribute, then the host assumes that the device is not able to prepare the domain for download. The
host may then decide to write the value “CANCEL_DWNLD” to the “Command” element of the DOMAIN_DESCRIPTOR to
drive the domain to the DWNLD_NOT_READY state.
5.5 When the DWNLD_READY state has been reached, the host downloads the binary image to the domain using the FMS Generic
Domain Download services. The FMS State Machine for Generic Download defines the procedures for using these services. The
first segment sent using these services must contain the entire file header. The host must be prepared to wait for the Terminate
Download service to complete. This may take longer than other confirmed services because the device may perform procedures to
ensure that the downloaded image is complete.
5.6 If the device determines that the downloaded image has not been received correctly (e.g. checksum error), the domain will enter
the DWNLD_FAIL state and remain there until the host writes the value “CANCEL_DWNLD” to the “Command” element of the
DOMAIN_DESCRIPTOR.
5.7 Upon completion of the successful download of the domain, the domain transitions the domain to the DWNLD_OK state and the
Download Domain Header is set to reflect the value of the newly downloaded binary image file.
5.8 After verifying that the domain has reached this state, the host may also read the Download Domain Header to verify that it
matches the header of the downloaded binary image file. The host then writes the value “ACTIVATE” to the “Command” element
of the DOMAIN_DESCRIPTOR to instruct the device to begin executing the new domain software, and to update the Activated
Domain Header to reflect the newly loaded binary image. The Download Domain Header values are cleared to indicate that it is
once again available for downloading. Some devices may not return a Write Response indicating that the “ACTIVATE” value was
written successfully. A bit in the DWNLD_PROPERTY SMIB attribute indicates whether or not the device returns this response.
5.9 The host periodically reads the “State” element of the DOMAIN_DESCRIPTOR to determine when the domain state has changed
to DWNLD_NOT_READY. This signifies the end of the activation for the domain. The host then reads the Activate Error Code
of the SMIB Domain Descriptor Object for each downloaded domain to determine if the activation succeeded. It may also read the
Activated Domain Header to verify that it has been updated.
5.10 If the device is a multi-domain device, then the host proceeds to the next domain to download for the Multidomain Descriptor. In
certain cases, the device may reset after a domain has been downloaded and activated. In these cases, the device must be prepared
to retain the BEGIN value that had been written to the Multidomain Descriptor Command element. However, if the device resets
after the final domain of a multidomain downloaded has been activated, the device can transition the Multidomain Descriptor
Command element to “IDLE” when it restarts.
6. Once all domains for a Multidomain Descriptor have been downloaded and activated, the host terminates the download procedure for
it. For single domain devices, no explicit action is required from the host to terminate the download procedure. However, for multi-
domain devices, the host writes “END” to the Multidomain Descriptor Command element to signify that the download procedure is
complete unless the device has gone through reset and has restarted with the value “IDLE”. At this point, a multi-domain device may
determine that the downloaded domains do not operate properly as a unit. In this case, the device should write an error code to the
MULTI_DOMAIN_DEVICE attribute to identify the error.
7. For multidomain devices, the host repeats this procedure until the downloads are complete for all desired Multidomain Descriptors.
(16) CANCEL_DWNLD
DWNLD_ (13) CANCEL_DWNLD
NOT_
READY (14) ACTIVATE
(3) Powerup
(8) CANCEL_DWNLD DWNLD_ Ready
READY
The states of the Common Software Download State Machine are shown below. The state is reflected in “State” element of the
DOMAIN_DESCRIPTOR.
State Description
DWNLD_INCOMPLETE During power up, the device has detected a failed download attempt.
DWNLD_NOT_READY The device is capable of preparing for download. This may mean that the device has
a valid download and is currently operating from it, or that it is waiting to be
downloaded.
DWNLD_PREPARING The device is preparing for the download. Class 3 devices may temporarily
disappear from the live list while in this state.
DWNLD_READY The device has been prepared for download, and is ready to receive an FMS
Generic Initiate Download request, which will start the FMS Generic Download.
DOWNLOADING The device is executing the FMS Generic Download procedures. The FMS Generic
Download State Machine is in the LOADING, COMPLETE, or INCOMPLETE state.
DWNLD_OK The domain has been successfully downloaded. While in this state, the device waits
for instructions to activate the newly downloaded binary image or to reject the newly
downloaded binary image. If it receives instructions to activate it, and the process of
activating the code causes the device to fail or if it fails for any other reason, then it
will return to this state after power up (reset).
DWNLD_FAIL The download has failed. The device stores the cause of the failure as one of the
following failure substates:
• CHECKSUM_FAIL
• FMS_DOWNLOAD_FAIL
• VCR_FAIL
• OTHER.
3.2.3.2 CANCEL_DWNLD
An FMS Write indication has been received containing the value CANCEL_DWNLD for the “Command” element of the
DOMAIN_DESCRIPTOR and the value has been successfully written, or the value “END” has been successfully written to the
MULTI_DOMAIN_DEVICE attribute of a multi-domain device
3.2.3.3 DownloadFails
Download failure is the result of one of the following:
a) the VCR used for the download has aborted.
b) the FMS State Machine for Generic Download state machine has transitioned from the COMPLETE state to the EXISTENT state
c) the FMS State Machine for Generic Download state machine has transitioned from the LOADING state to the EXISTENT state.
3.2.3.4 DownloadSucceeds
The FMS State Machine for Generic Download state machine has transitioned to the READY state.
3.2.3.5 FmsGenericDownloadStarts
The FMS State Machine for Generic Download state machine has transitioned to the LOADING state.
3.2.3.6 PowerupDwnldOk
The device has powered up and detected that the last state of the Common Software Download State Machine was DWNLD_OK.
3.2.3.7 PowerupIncomplete
The device has powered up and detected that the last state of the Common Software Download State Machine was not
DWNLD_NOT_READY, DWNLD_READY, nor DWNLD_OK, indicating that the device lost power without completing a download.
3.2.3.8 PowerupNotReady
The device has powered up and detected that the last state of the Common Software Download State Machine was
DWNLD_NOT_READY.
3.2.3.9 PowerupReady
The device has powered up and detected that the last state of the Common Software Download State Machine was DWNLD_READY.
3.2.3.10 PreparationComplete
The device has completed preparing for the download.
3.2.3.11 PreparationFails
Preparing for the download has failed, or the Preparation Timer has expired.
3.2.3.12 PREPARE_FOR_DWNLD
An FMS Write indication has been received containing the value PREPARE_FOR_DWNLD for the “Command” element of the
DOMAIN_DESCRIPTOR and the value has been successfully written.
3.2.3.13 Timeout
The time interval defined in DWNLD_PROPERTY, “Ready for Download Delay”, has expired.
Function
This function causes the FMS State Machine for Generic Download to terminate the download procedure and return to the
EXISTENT state.
Input Parameters Output Parameters
None None
3.2.4.2 ActivateDomain()
Function
This function activates the software that has been downloaded successfully into the domain. This may cause a restart of the
device. The device may not be able to respond to the FMS Write used to write the value ACTIVATE to the Command element of
the DOMAIN_DESCRIPTOR.
When this function begins, the ActivationTimer is started using the value defined in the “Activation Delay” element of the
DWNLD_PROPERTY. If this timer expires before this function completes, the activation fails.
This function returns the success or failure code associated with the activation. The valid values are specified for the Error Code
element of the DOMAIN_DESCRIPTOR.
Note: Implementers should set Error Code to a failure code when beginning the download and activation so that if the either fails
such that the device is not able to set the reason for failure, an error value already will be present. When the activation completes,
then Error Code can be set to the appropriate value.
Input Parameters Output Parameters
None Activate Error Code
3.2.4.3 BeginPreparingDomain()
Function
This function starts the process of preparing the domain for the download. The behavior depends on the class of device, as defined
in the DWNLD_PROPERTY SMIB attribute. In all classes, normal operation of the NMIB and SMIB continue, except as noted
below, and in Section 3.1.
Class 1: The device continues normal operation. Other preparations that the device may take are not externally visible.
Class 2: The device degrades to a reduced, stable mode of operation. For example, one or more blocks may transition to OOS
mode; some VCRs may be terminated.
Class 3: The device may restart and reappear in the live list at the same address. It degrades to a significantly reduced stable
mode of operation. This may include elimination of the Function block application process. Some or all VCRs may be
terminated. The device’s configuration may be lost.
Input Parameters Output Parameters
None None
3.2.4.4 PerformFmsGenericDownload ()
Function
This function performs the software download using the Fms Generic Download services.
Input Parameters Output Parameters
None None
3.2.4.5 SetFailureSubstate()
Function
This function sets the failure substate value of the DWNLD_FAIL state to indicate the cause of the failure.
Input Parameters Output Parameters
None None
3.2.4.6 StartPreparationTimer()
Function
This function starts the Preparation Timer for the interval defined in the “Ready for Download Delay” element of the
DWNLD_PROPERTY.
Input Parameters Output Parameters
None None
3.2.4.7 StopPreparationTimer()
Function
This function stops the Preparation Timer.
Input Parameters Output Parameters
None None
3.2.4.8 SwapDomains()
Function
This function causes the downloaded image in the download domain to be referenced by the activated domain. The download
domain reference is initialized so that it no longer references the downloaded image. After the reference is initialized, its state is set
to EXISTENT. The term reference is used here to mean a logical pointer to the domain contents. Whether the contents are copied,
or whether addresses are changed in the object description, or whether the indexes are swapped for the domains is implementation
dependent.
Input Parameters Output Parameters
None None
The components of the file name are selected to match the attributes of the header of the file. Hosts should compare the first 10 characters
of the file name against those in the DeviceID, and the Domain Name component of the file name against the Domain Name in the
Activated Domain Header to determine whether the download file matches the device and domain.
Device manufacturers are allowed to change the Domain Name, and/or the Software Name when downloading new software by embedding
this information in the download itself. When the device activates the domain, it makes the appropriate changes and updates the Activated
Domain Header in the SMIB with the new information. In this case, the Activated Domain Header will not match the downloaded binary
image file header.
Instance It is possible for a device to support more than one instance of a given Multidomain Family. This
element identifies the instance of the Multidomain Family within this device.
If the length of the Instance is less than 8 characters, then it is blank filled (space characters) to
the right. Set to blanks if the domain is empty.
This element is a VisibleString whose valid characters are all upper and lower case letters A – Z,
the numbers 0 – 9, and the hyphen “-“ character. All other characters are invalid.
Hardware Revision Vendor assigned hardware revision number associated with this multidomain object.
Software Revision Vendor assigned software revision number associated with this multidomain object.
DomainDescriptor Starting Index DomainDescriptor objects are assigned consecutive indexes in the OD for each
MultiDomainDescriptor. This read-only element contains the OD index of the first
DomainDescriptor object for this MultiDomainDescriptor. The Domain Descriptor objects
contained in the list referenced by this element must be contained in the list referenced by the
SMIB Directory entry “List Of Software Download Domain Descriptors Starting OD Index”.
Number of MultiDomainDescriptors This read-only element contains the number of DomainDescriptor objects of this
MultiDomainDescriptor.
NOTE: The “Number of This Directory Object” in the description of the Numeric Identifier indicates which directory object is being
identified. For this calculation, directory objects are numbered consecutively starting at 0 (zero). Therefore, the SM directory
object is located at the First Index S-OD+0, and the successive directory objects (if present) are located at consecutive OD
Indexes following the SM directory object.
Following is a description of the H1 and HSE SMIB Directories. Both the H1 and HSE SMIB Directories have 5 entries that follow the
Directory Header. Sixth and seventh entries have been added to each to reference the Software Download objects. The Directory Revision
Number shall be set to 1, indicating that the Version 1 directory structure has not been invalidated. These entries are not present if software
download is not supported.
SM_SUPPORT
Following is a description of the H1 and HSE SMIB SM_SUPPORT attribute. The bit definitions of this attribute for H1 and HSE are
shown in the table below. Note that both start with the msb, but Bit 0 is the msb for H1 and bit 32 is the msb for HSE. To identify devices
that support software download, a new bit is defined, as follows in H1 (bit 15) and HSE (bit17).
Bit Value Bit H1 System Management Feature HSE System Management Feature Bit
0x80 00 00 00 0 (msb) Set Physical Device Tag (agent) Reserved 32 (msb)
0x40 00 00 00 1 Set Field Device Address (agent) Reserved 31
0x20 00 00 00 2 Clear Address (agent) Clear Address (agent) 30
0x10 00 00 00 3 Identify (agent) Identify (agent) 29
0x08 00 00 00 4 Locating Function Blocks (agent) Locating Function Blocks (agent) 28
0x04 00 00 00 5 Set Physical Device Tag (manager) Set PD Tag and Index (manager) 27
0x02 00 00 00 6 Set Field Device Address (manager) Reserved 26
0x01 00 00 00 7 Clear Address (manager) Clear Address (manager) 25
0x00 80 00 00 8 Identify (manager) Identify (manager) 24
0x00 40 00 00 9 Locating Function Blocks (manager) Locating Function Blocks (manager) 23
0x00 20 00 00 10 FMS Server Role FMS Server Role 22
0x00 10 00 00 11 Application Clock Synch (Time Slave) Reserved 21
0x00 08 00 00 12 Scheduling Function Block Scheduling Function Blocks 20
0x00 04 00 00 13 Application Clock Synch (Time Publisher) Application Clock Synch (time master) 19
0x00 02 00 00 14 Operational Powerup 18
0x00 01 00 00 15 Software Download Supported (agent) Software Download Supported (agent) 17
Record: DWNLD_PROPERTY
This specifies the general characteristics of the device with respect to Software Download.
Name: DWNLD_PROPERTY
Numeric Identifier: Software Download Starting OD Index
Data Type Index: 138 (DWNLD_PROPERTY_STRUCTURE)
Number of Elements: 6
Password: Not Defined Here
Access Groups: Not Defined Here
Access Rights: Ra
Local Address: Not Defined Here
Extension: Not Defined Here
Record: MULTI_DOMAIN_SUMMARY
This attribute provides summary information for multi-domain devices. It is not present for devices with a single download domain.
Name: MULTI_DOMAIN_SUMMARY
Numeric Identifier: Software Download Starting OD Index + 1
Data Type Index: 139 (MULTI_DOMAIN_SUMMARY_STRUCTURE)
Number of Elements: 5
Password: Not Defined Here
Access Groups: Not Defined Here
Access Rights: Ra
Extension: Not Defined Here
List of Local Address: Not Defined Here
Local Address: Not Defined Here
SMK Usage: Read
Record: DOMAIN_DESCRIPTOR
This is the List of Domain Descriptors object. Each entry in the list is a DOMAIN_DESCRIPTOR record that describes a single domain
capable of being downloaded and activated. If there is more than one entry in the list, then FMS Write Requests to this list are only
enabled if the value of the MULTI_DOMAIN_DEVICE object is “BEGIN”. FMS Write Requests received when there is more than one
entry in the list, and the value is not BEGIN results in a negative response being returned with the Error Class = “Service” and Error Code
= “Object-Constraint-Conflict”.
Name: DOMAIN_DESCRIPTOR
Numeric Identifier: List Of Domain Descriptors Starting OD Index + Offset
(Offset is Number of Domain Descriptor objects - 1)
Data Type Index: 137 (DOMAIN_DESCRIPTOR_STRUCTURE)
Number of Elements: 7
Password: Not Defined Here
Access Groups: Not Defined Here
Access Rights: Ra
Local Address: Not Defined Here
Extension: Not Defined Here
SMK Usage: Read/Write (see the DOMAIN_DESCRIPTOR_STRUCTURE definition above for the
writable elements).
Record: DOMAIN_HEADER
The DOMAIN_HEADER record is referenced by the DOMAIN_DESCRIPTOR elements “Download Domain Header Index” and
“Activated Domain Header Index”.
Name: Download Domain Header or Activated Domain Header
Numeric Identifier: Defined by the DOMAIN_DESCRIPTOR elements “Download Domain Header Index” and
“Activated Domain Header Index”
Data Type Index: 136 (DOMAIN_HEADER_STRUCTURE)
Number of Elements: 10
Password: Not Defined Here
Access Groups: Not Defined Here
Access Rights: Ra
List of Local Address: Not Defined Here
Extension: Not Defined Here
SMK Usage: Read