FF883

Copyright by the Fieldbus Foundation 1994-2006. All rights reserved.

FOUNDATION™ Specification System Management Addendum for Software Download

DOCUMENT: FF-883 REVISION: FS 1.2 DATE: December 8, 2005

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.

Foreword .

Open Issue List No. Description of Issue Affected

Documents

Resolution List No. Description of Resolution Affected

Sections AR1519 Editorial Error 4

System Management Addendum Fieldbus Specifications FF-883 FS 1.2

© Fieldbus Foundation 1994-2006 Page i

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

FF-883 FS 1.2 Fieldbus Specifications System Management Addendum

Page ii © Fieldbus Foundation 1994-2006

This page intentionally left blank


© Fieldbus Foundation 1994-2006 Page 1

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.


Page 2 © Fieldbus Foundation 1994-2006

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. The download process is comprised of three steps: 1. If the software upgrade consists of a file set, the host writes “BEGIN“ to its MultiDomainDescriptor attribute in the SMIB. This

permits the device to prepare itself to receive one or more domain downloads. The files that belong to the download file set have the same manufacturer id and device family in their file names.

2. For each domain to be downloaded: Commanding the device to Prepare for Download for a specified domain. Downloading the software binary image to the specified domain. Commanding the device to activate the downloaded software.

3. When Step 2 is completed, writing “END“ to the Multidomain Descriptor attribute in the SMIB, if the host attempted to download more than one domain. This permits the device to perform any post download processing. The host may then return to Step 1 above to download another file set if desired.

4. Because of the timing involved, and the potential for device reset, writing to the MULTI_DOMAIN_DEVICE and commanding the device to prepare for or activate downloaded domains may occur on different instances of the management VCR. However, domain downloads must occur on the same VCR, as specified by the FMS Generic Download services [FF-870].

2.1 Host Procedure The following procedure describes the software download mechanism in more detail. 1. The host user begins by identifying the device and the binary images to be downloaded. The host identifies the binary images that

can be downloaded to the device based on the manufacturer id and the device family, and the user selects those to download from this list. If the device supports multiple domains, the Multidomain Descriptors contain a Multidomain Family attribute that can be used in the file name in place of the device family to help identify the set of associated files. 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.



3 Common Software Download Specification

3.1 Device Download Classes This specification defines three download classes of devices. The download class designates how device operation is affected by the download process. Class 1 – A device that continues normal/full operation during the download process.

The device is capable of downloading a new executable image while continuing full operation with its existing code. The device presents its full, normal set of capabilities to the network. The NMIB and all the blocks continue to operate independently of, and unaffected by, the download process. The SMIB, with the exception of the new attributes that support the download, shall also continue to operate independently of, and unaffected by, the download procedure.

Class 2 – A device that does not continue normal/full operation during the download process: The NMIB and the FBAP Object Dictionary remain unaffected by the download. The blocks may transition to OOS mode when the download process is started. The SMIB, with the exception of the new attributes that support the download, also continues to operate independently of, and unaffected by, the download.

Class 3 – A memory constrained device A memory-constrained device may free up its Flash ROM and/or RAM resources after it is commanded to prepare for download. The device may go through software reset, causing it to temporarily disappear from the live list. During the download preparation, the device: a) retains its original Device Id b) includes only its System Management VFD in its VFD_LIST c) retains its Node Address and PD Tag d) retains its management VCR to provide access to the SMIB

In all classes, the device retains its DeviceID, PD Tag, and Node Address after the new software is downloaded and activated.

3.2 Common Software Download State Machine The CSDS state machine operates in conjunction with the FMS State Machine for Generic Download. It is used separately for the download of each domain. The CSDS state machine starts in the DWNLD_NOT_READY state. When the value “PREPARE_FOR_DWNLD” is written to the DWNLD_COMMAND SMIB attribute it transitions to the DWNLD_PREPARING state. While in this state, the Download Domain contents are cleared. For devices that continue operation, the contents are not actually lost. Instead, the device maintains the executing code in the Activated domain. While in this state, the device performs any other device specific preparations, including possibly leaving the live-list and then reappearing. When it completes its preparation, the FMS State Machine for Generic Download state machine is in the EXISTENT state. At this point, the FMS State Machine for Generic Download state machine is ready to be downloaded. The Common Software Download State Machine then transitions to the DWNLD_READY state where it waits for one of the following outcomes:

· CANCEL_FOR_DWNLD is written to the “Command” element of the DOMAIN_DESCRIPTOR. · the FMS State Machine for Generic Download indicates that the download has completed successfully. · the FMS State Machine for Generic Download indicates that the download has completed unsuccessfully.

If the download succeeds: 1. the FMS State Machine for the domain is in the READY state, allowing the contents to be uploaded using the FMS Upload services. 2. the file header for the downloaded binary image becomes visible in the SMIB in the DOMAIN_HEADER attribute of the Download

Domain. This SMIB attribute is updated and available for reading as soon as the file header bytes are received. 3. the Common Software Download State Machine transitions to the DWNLD_OK state where it waits for one of the following

outcomes: · CANCEL_FOR_DWNLD is written to the “Command” element of the DOMAIN_DESCRIPTOR, indicating that the domain

contents are not to be used. · ACTIVATE_CODE is written to the “Command” element of the DOMAIN_DESCRIPTOR, indicating that the device should

begin operating using the newly downloaded contents. The device stores the result of the activation (success or failure code) in the Activate Error Code of the SMIB Domain Descriptor Object. In addition, the file header for the downloaded binary image becomes visible in the SMIB in the DOMAIN_HEADER attribute of the Activated Domain (except as noted in Section 3.3.2), and the DOMAIN_HEADER attribute of the Download Domain is cleared.

If the download does not result in the activation of the newly downloaded domain, then the domain remains in its current state until the next PREPARE_FOR_DWNLD for that domain is written to the “Command” element of the DOMAIN_DESCRIPTOR.



3.2.1 State Diagram The Common Software Download state diagram is shown in the figure below. Numbers in parentheses indicate the transition number in the state transition table that follows.

DWNLD_ NOT_

READY

DWNLD_ READY

(5) PREPARE_FOR_DWNLD

(12) Download Succeeds

DWNLD_ OK

(13) CANCEL_DWNLD

(10) Download Fails

DWNLD_ FAIL

(8) CANCEL_DWNLD

DWNLD_ PREPARING

(6) Preparation Complete

(15) CANCEL_DWNLD (7) CANCEL_DWNLD

Or Timeout Or Preparation Fails

(2) Powerup lncomplete

(16) CANCEL_DWNLD

(1) Powerup NotReady

(4) Powerup DwnldOk

(3) Powerup Ready

(14) ACTIVATE

DOWN LOADING

DWNLD_ INCOMPLETE

(11) CANCEL_DWNLD

(9) FMS Generic Download Starts

Figure 1 –Common Software Download State Diagram



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.2 State Transitions

Table 1 – State Table Transitions

# Current State Event Action Next State 1 PowerupNotReady DWNLD_NOT_READY 2 PowerupIncomplete DWNLD_INCOMPLETE 3 PowerupReady DWNLD_READY 4 PowerupDwnldOk DWNLD_OK 5 DWNLD_NOT_READY PREPARE_FOR_DWNLD Activate Error Code = 0

BeginPreparingDomain() StartPreparationTimer()

DWNLD_PREPARING

6 DWNLD_PREPARING PreparationComplete StopPreparationTimer() DWNLD_READY 7 DWNLD_PREPARING CANCEL_DWNLD

|| Timeout || PreparationFails

DWNLD_NOT_READY

8 DWNLD_ READY CANCEL_DWNLD DWNLD_NOT_READY 9 DWNLD_ READY FmsGenericDownloadStarts PerformFmsGenericDownload() DOWNLOADING 10 DOWNLOADING DownloadFails SetFailureSubstate() DWNLD_FAIL 11 DOWNLOADING CANCEL_DWNLD AbortDownload() DWNLD_NOT_READY 12 DOWNLOADING DownloadSucceeds DWNLD_OK 13 DWNLD_OK CANCEL_DWNLD DWNLD_NOT_READY 14 DWNLD_OK ACTIVATE Activate Error Code =

ActivateDomain() If (Activate Error Code == Success) SwapDomains()

DWNLD_NOT_READY

15 DWNLD_FAIL CANCEL_DWNLD DWNLD_NOT_READY 16 DWNLD_INCOMPLETE CANCEL_DWNLD DWNLD_NOT_READY

3.2.3 State Machine Events 3.2.3.1 ACTIVATE An FMS Write indication has been received containing the value ACTIVATE for the “Command” element of the DOMAIN_DESCRIPTOR and the value has been successfully written and the response returned. If the device leaves the bus as part of the activation, it aborts the VCR first.



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.

3.2.4 State Machine Functions 3.2.4.1 AbortDownload()

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.


3.2.4.4 PerformFmsGenericDownload ()

Function This function performs the software download using the Fms Generic Download services.


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.


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.




3.2.4.7 StopPreparationTimer()

Function This function stops the Preparation Timer.


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.


3.3 Download File

3.3.1 Description This download specification intentionally leaves the definition of most of the download file to the vendor. This has been done to eliminate any dependency on device architectures. The following standard information is included in the file as a header, formally specified by the DOMAIN_HEADER_STRUCTURE data structure definition in the SMIB: • Header Version Number • Header Size • Manufacturer ID • Device Family • Device Type • Device Revision • DD Revision • Software Revision • Software Name • Domain Name The values of the above attributes in the file header characterize the Binary Image that follows the header in the file. The resource block in the device shall reflect the values in the header after the file is downloaded and activated. The manufacturer may encode any information in the Binary Image of the file. This may include, but is not limited to: • Checksum • Scrambled data • Additional identification information



3.3.2 File Name The file name is constructed as follows: “Manufacturer ID” + “Device Family” + “_” + “Device Type” + “_” + “Domain Name” ” + “_” +“Software Name” + “_” +“Software Revision” + “.” + “ffd”, where: 1. Manufacturer ID is represented as six hexadecimal digits (leading and trailing zeroes are included). For Multidomain devices, the

device’s Manufacturer Id is replaced by Multidomain Descriptor’s Manufacturer Id, 2. Device Family is represented as four hexadecimal digits (leading and trailing zeroes are included). For Multidomain devices, Device

Family is replaced by Multidomain Family, 3. Device Type is represented as four hexadecimal digits (leading and trailing zeroes are included), 4. Leading “0”s are not suppressed for Manufacturer ID and Device Type, 5. Trailing blanks are stripped from Device Family, Domain Name, Software Name, and Software Revision. 6. If Software Name or Software Revision is composed of all blanks, then the underscore that would have preceded it is omitted to

prevent names with two adjacent underscores, or from having the underscore character appear directly before the “.ffd”. For example, if the file contains the following header values, Manufacturer ID = 660027 (0xA123B) Device Family = “0300” Device Type = 789 (0x315) Domain Name = “DOM01 ” Software Name = “SW01 ” Software Revision = “0102”

Then the file name would be: “0A123B0300_0315_DOM01_SW01_0102.ffd” 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.

3.3.3 File Format The format of the file is as follows:

Table 2 – Download File Format

Parameter Name Octet Offset

Data Type Octet Length

Description

Header DOMAIN_HEADER_STRUCTURE 32 Header structure common to all domains Binary Image 32 OctetString N Vendor Specific

3.4 Device ID Format The format of the Device ID for devices that support this specification conforms to FF Technote TN-002-1.0, “Format of the Device ID”, with the following exception. Rule (2) defines the four octets following the manufacturer id to be the Device Type. Devices that support this specification are required to use these four characters for the Device Family instead of the Device Type.



4 System Management Information Base Additions This section defines the objects added to the System Management Information Base (FF-880) to support the software download function. Modify the following attributes in the SMIB, as follows.

Data Type Structure Description: DOMAIN_HEADER_STRUCTURE This data type structure defines the format of the domain header contained in the binary image.

Numeric Identifier: 136 Number of Elements: 10 List of Element: Data Type Index: 6 (Unsigned16) /* Header Version Number */ Length: 2 Data Type Index: 6 (Unsigned16) /* Header Size */ Length: 2 Data Type Index: 9 (VisibleString) /* Manufacturer Id */ Length: 6 Data Type Index: 9 (VisibleString) /* Device Family */ Length: 4 Data Type Index: 9 (VisibleString) /* Device Type */ Length: 4 Data Type Index: 5 (Unsigned8) /* Device Revision */ Length: 1 Data Type Index: 5 (Unsigned8) /* DD Revision */ Length: 1 Data Type Index: 9 (VisibleString) /* Software Revision */ Length: 8 Data Type Index: 9 (VisibleString) /* Software Name */ Length: 8 Data Type Index: 9 (VisibleString) /* Domain Name */ Length: 8



The elements of the DOMAIN_HEADER_STRUCTURE are described in the table below.

Table 3 – Domain Header Element Description

Parameter Name Description

Header Version Number The version number for this header. The initial value is 1. This number will be incremented whenever the specification changes the format of the header.

Header Size The size of the header in bytes including the size of this field. The binary image to be loaded starts at byte “Header Size + 1”.

Manufacturer ID The MANUFAC_ID attribute of the Resource Block, as defined in the FBAP Part 2 Specification [FF-891] represented as six hexidecimal digits.

Device Family The Device Family is used by device manufacturers to classify devices for software upgrade purposes. Each Device Family defines a set of devices that can accept the same set of binary image files. This permits manufacturers to develop devices whose Device Type is determined by software. Software upgrades, therefore, have the potential of changing the Device Type. The values used for Device Family are manufacturer specific, and therefore, may be related to, or may be the same as the hexadecimal representation of the Device Type.

Device Type DEV_TYPE attribute of the Resource Block, as defined in the FBAP Part 2 Specification [FF-891] represented as four hexadecimal digits.

Device Revision DEV_REV attribute of the Resource Block, as defined in the FBAP Part 2 Specification [FF-891].

DD Revision DD_REV attribute of the Resource Block, as defined in the FBAP Part 2 Specification [FF-891].

Software Revision Vendor Specific Software Revision. If the length of the Software Revision 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.

Software Name Vendor Specific Name of the Software. If the length of the name is less than 8 characters, then the name is blank filled to the right. 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.

Domain Name Vendor Specific Domain Name of this binary image. If the length of the name is less than 8 characters, then the name is blank filled to the right. This name must match the Domain Name of the Domain Descriptor for this binary image. That is, it not permitted to store a binary image into domain whose Domain Descriptor has a different Domain Name. 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.



Data Type Structure Description: DOMAIN_DESCRIPTOR_STRUCTURE This data type structure defines the format of the information used to download a domain.

Numeric Identifier: 137 Number of Elements: 7 List of Element: Data Type Index: 5 (Unsigned8) /* Command */ Length: 1 Data Type Index: 5 (Unsigned8) /* State */ Length: 1 Data Type Index: 6 (Unsigned16) /* Error Code */ Length: 2 Data Type Index: 7 (Unsigned32) /* Download Domain Index */ Length: 4 Data Type Index: 7 (Unsigned32) /* Download Domain Header Index */ Length: 4 Data Type Index: 7 (Unsigned32) /* Activated Domain Header Index */ Length: 4 Data Type Index: 9 (VisibleString) /* Domain Name */ Length: 8

The elements of the DOMAIN_DESCRIPTOR are described in the table below.



Table 4 – DOMAIN_DESCRIPTOR_STRUCTURE Element Description

Element Name Description

Command This read/write element defines the various commands that can be sent to the domain as part of the Software Download process. Its values are: 0: Reserved 1: PREPARE_FOR_DWNLD

A request to write this value will fail if the “State” element of the DOMAIN_DESCRIPTOR is not DWNLD_NOT_READY. A negative response is returned that indicates “service/object-state-conflict”. A request to write this value will fail if the Upload state of the domain is not NON-EXISTENT. A negative response is returned that indicates “service/object-constraint-conflict”.

2: ACTIVATE A request to write this value will fail if the “State” element of the DOMAIN_DESCRIPTOR is not DWNLD_OK. A negative response is returned that indicates “service/object-state-conflict”.

3: CANCEL_DWNLD A request to write this value is valid in all DOMAIN_DESCRIPTOR states.

State This read-only element contains the state of the domain with respect to the software download procedure. Its values are: 0: Reserved 1: DWNLD_NOT_READY 2: DWNLD_PREPARING 3: DWNLD_READY 4: DWNLD_OK 5: DOWNLOADING 6 –10: DWNLD_FAIL 6: CHECKSUM_FAIL 7: FMS_DOWNLOAD_FAIL 8: DWNLD_INCOMPLETE 9: VCR_FAIL 10: OTHER 11-255: RESERVED

Error Code This read-only element identifies the error, if any, that occurred while downloading or activating the downloaded software for the domain. The variable is cleared (set to zero) when a PREPARE_FOR_DWNLD command is received that identifies this domain. The values for the Activate Error Code are: 0: success, configuration retained 1: success, configuration necessary 2 – 32767: reserved for use by Fieldbus Foundation 32768 – 65535 reserved for vendor-specific error codes

Download Domain Index The read-only element contains the OD Index of the domain that can be downloaded. If multiple download domains are supported, their Download Domain Index values must be consecutive.

Download Domain Header Index This read-only element contains the OD Index of the domain header variable for the download domain. This variable provides variable read access to the header of the binary image in the download domain.

Activated Domain Header Index This read-only element contains the OD Index of the domain header variable for the activated domain. This variable provides variable read access to the header of the binary image in the activated domain. The activated domain contains the currently executing software for this domain descriptor. This includes software that has been installed though local interfaces, such as factory installed software, and software that has been downloaded using the mechanisms defined in this specification. If this domain has never been activated, or it has been invalidated during the download procedure, then the domain is considered to be empty (see the description of the DOMAIN_HEADER_STRUCTURE for the header values to be used when the domain is empty.)

Domain Name This read-only element identifies the domain to be downloaded. The value is vendor specific. This value is read by the host to determine which binary image to associate with this Domain Descriptor. If the length of the name is less than 8 characters, then the name is blank filled to the right. 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.



Data Type Structure Description: DWNLD_PROPERTY_STRUCTURE This data type structure defines characteristics related to the device’s support for software download.

Numeric Identifier: 138 Number of Elements: 6 List of Element: Data Type Index: 5 (Unsigned8) /* Download Class */ Length: 1 Data Type Index: 5 (Unsigned8) /* Write Rsp Returned For ACTIVATE */ Length: 1 Data Type Index: 5 (Unsigned8) /* Write Rsp Returned For PREPARE */ Length: 1 Data Type Index: 5 (Unsigned8) /* Reserved */ Length: 1 Data Type Index: 6 (Unsigned16) /* ReadyForDwnld Delay Secs */ Length: 2 Data Type Index: 6 (Unsigned16) /* Activation Delay Secs */ Length: 2

The elements of the DWNLD_PROPERTY_STRUCTURE are described in the table below.

Table 5 – DWNLD_PROPERTY_STRUCTURE Element Description


Download Class This read-only element defines the download class of the device. Its values are: 0: Reserved 1: Class 1 2: Class 2 3: Class 3 4-255 Reserved

Write Rsp Returned For ACTIVATE

This element specifies whether or not the device returns an FMS Write response to indicate successful writing of the value “ACTIVATE” to the Command element of DOMAIN_DESCRIPTORs. Its values are: 0: Write Response Not Returned 1: Write Response Returned 3-255 Reserved Since writing this command can result in the device going offline, the device may not be able to guarantee that the response is actually transmitted before the device goes offline.

Write Rsp Returned For PREPARE

This element specifies whether or not the device returns an FMS Write response to indicate successful writing of the value “PREPARE_FOR_DWNLD” to the Command element of DOMAIN_DESCRIPTORs. Its values are: 0: Write Response Not Returned 1: Write Response Returned 3-255 Reserved Since writing this command can result in the device going offline, the device may not be able to guarantee that the response is actually transmitted before the device goes offline.

Reserved Reserved, set to 0 ReadyForDwnld Delay Secs This element specifies the maximum time needed by the device to transition to the DWNLD_READY

state. The host system performing the download can consider the device to have timed out if the actual time taken to reach this state exceeds this limit.

Activation Delay Secs This element specifies the maximum time needed by the device to transition from the DWNLD_OK state to the DWNLD_NOT_READY state after receiving an ACTIVATE command. The host system performing the download can consider the device to have timed out if the actual time taken to reach this state exceeds this limit.



Data Type Structure Description: MULTIDOMAIN_SUMMARY_STRUCTURE This data type structure defines summary information that describes multiple domains.

Numeric Identifier: 139 Number of Elements: 5 List of Element: Data Type Index: 1 (Boolean) /* ConcurrentDownload */ Length: 1 Data Type Index: 5 (Unsigned8) /* State */ Length: 1 Data Type Index: 6 (Unsigned16) /* Reserved */ Length: 2 Data Type Index: 7 (Unsigned32) /* MultiDomainDescriptor Starting Index */ Length: 4 Data Type Index: 7 (Unsigned32) /* Number of MultiDomainDescriptors */ Length: 4

The elements of the MULTIDOMAIN_SUMMARY_STRUCTURE are described in the table below.

Table 6 – MULTIDOMAIN_SUMMARY_STRUCTURE Element Description


ConcurrentDownload This read-only Boolean element indicates, when TRUE, that the device supports downloading to two or more MultiDomainDescriptor objects at the same time. When FALSE, the device is capable of supporting a download to only one MultiDomain Descriptor at a time.

State This read-only element indicates whether downloads are in progress for any of its MultiDomainDescriptors. Its values are: 0: NOT_DOWNLOADING 1: DOWNLOADING 2-255: RESERVED

Reserved Reserved, set to 0. MultiDomainDescriptor Starting Index MultiDomainDescriptor objects are assigned consecutive indexes in the OD. This read-only

element contains the OD index of the first MultiDomainDescriptor object. Number of MultiDomainDescriptors This read-only element contains the number of MultiDomainDescriptor objects.



Data Type Structure Description: MULTIDOMAIN_DESCRIPTOR_STRUCTURE This data type structure defines summary information that describes multiple domains.

Numeric Identifier: 140 Number of Elements: 11 List of Element: Data Type Index: 5 (Unsigned8) /* Command */ Length: 1 Data Type Index: 5 (Unsigned8) /* Error Code */ Length: 1 Data Type Index: 5 (Unsigned8) /* Additional Code */ Length: 1 Data Type Index: 10 (OctetString) /* Reserved */ Length: 3 Data Type Index: 9 (VisibleString) /* Multidomain Mfg Id */ Length: 6 Data Type Index: 9 (VisibleString) /* Multidomain Family */ Length: 4 Data Type Index: 9 (VisibleString) /* Instance */ Length: 8 Data Type Index: 6 (Unsigned16) /* Hardware Revision */ Length: 2 Data Type Index: 6 (Unsigned16) /* Software Revision */ Length: 2 Data Type Index: 7 (Unsigned32) /* DomainDescriptor Starting Index */ Length: 4 Data Type Index: 7 (Unsigned32) /* Number of DomainDescriptors */ Length: 4

The elements of the MULTIDOMAIN_DESCRIPTOR_STRUCTURE are described in the table below.



Table 7 – MULTIDOMAIN_DESCRIPTOR_STRUCTURE Element Description


Command This read/write element defines the various commands that can be sent to the domain as part of the Software Download process. Its values are: 0: Reserved 1: IDLE (default value)

This value cannot be written. Writes with this value cause a negative response to be returned with Error Class = “Service” and Error Code = “Parameter-Inconsistent”

2: BEGIN If the value of this variable is “IDLE” when the FMS Write with the value “BEGIN” is received, the device enables FMS Writes to the Command element of its Domain Descriptors, and also performs any other preparations necessary to support the download process. If the value of this variable is not “IDLE” when the FMS Write with the value “BEGIN” is received, the write is rejected and a Negative response returned with Error Class = “Service” and Error Code = “Object-Constraint-Conflict” After being successfully written, the value “BEGIN” persists unless there has been no download activity for 300 consecutive seconds. After 300 consecutive seconds of no activity, the device locally issues a write to this variable with the value “END” and performs the “END” processing described below.

3: END If the value of this variable is “IDLE” or “END” when the FMS Write with the value “END” is received, the write is rejected and a Negative response returned with Error Class = “Service” and Error Code = “Object-Constraint-Conflict”. If the value of this variable is “BEGIN” when the FMS Write with the value “END” is received, the write is accepted and a positive response is returned. Then the device performs any necessary post-download processing. After performing the post processing, the device changes the value of this attribute to “IDLE” or to one of the Activation Error Codes (values 256-32767).

4: ABORT If the value of this variable is “IDLE” or “BEGIN” when the FMS Write with the value “ABORT” is received, the write is rejected and a Negative response returned with Error Class = “Service” and Error Code = “Object-Constraint-Conflict”. If the value of this variable is “END” or one of the Activation Error Codes defined below when the FMS Write with the value “ABORT” is received, the write is accepted and a positive response is returned. Then the device aborts any post-download processing it is performing, and changes the value of this attribute to “IDLE”. Writing this value allows the host to reset the value of this attribute if the device has not successfully transitioned from “END” to “IDLE”.

5 - 255: Reserved, not used Negative response returned with Error Class = “Service” and Error Code = “Parameter-Inconsistent”

Error Code Readable values set by the device to inform the host that the device encountered a failure condition during the download or when trying to operate using all activated domains. Its values are: 0: No error 1: Download Failure 2: General Activation Failure 3 - 255: Reserved

Additional Code Vendor specific code used to supplement the ErrorCode or provide additional status information. Reserved Reserved, set to 0. Multidomain Mfg Id The six character hex representation of the FF Manufacturer Id for the manufacturer of this

Multidomain. Multidomain Family Multidomain Descriptors describe a set of related domains that can be downloaded as a group.

This element identifies the type, or family, of the domains. Families can be used to identify different types of multidomain VFDs or downloadable hardware components (e.g. cards) supported by the device. If the length of the Multidomain Family 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.



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.

Array: SMIB Directory Object Name: Not Defined Here Numeric Identifier: FirstIndex-S-OD + (Number of This Directory Object) This Directory Object is 0. Data Type Index: 6 (Unsigned16) for H1, 7(Unsigned32) for HSE Length: 2 Number of Elements: 20 Password: Not Defined Here Access Groups: Not Defined Here Access Rights: Ra Local Address: Not Defined Here Extension: Not Defined Here SMK Usage: Read

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.



Array Index

Directory Entry

H1 Description HSE Description

1 Header Reserved 2 Directory Revision Number (1) 3 Number of Directory Objects (1) 4 Total Number of Directory Entries (=7) 5 Directory Index of First Composite List Reference(0) 6 Number of Composite List References(0) 7 1 SM Agent Starting OD Index SM Characteristics OD Index 8 Number of SM Agent Objects Number of Objects in SM Characteristics 9 2 Sync and Scheduling Starting OD Index

10 Number of Sync and Scheduling Objects 11 3 Address Assignment Starting OD Index Device Identification OD Index 12 Number of Address Assignment Objects Number of Objects in Device Identification 13 4 VFD List Starting OD Index 14 Number of VFD List Objects 15 5 FB Schedule Starting OD Index 16 Number of FB Schedule Objects 17 6 Software Download Starting OD Index 18 Number of Software Download Objects 19 7 List Of Software Download Domain Descriptors Starting OD Index 20 Number of Software Download Domain Descriptor Objects



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 SMK Usage: Read

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

FF883

Documents

Transcript of FF883