6. CONFIGURABILITY PROVISIONS

Software tools and devices conforming to this specification shall satisfy the following requirements for configurability.

6.1 Software tools

Software tools shall be capable of utilizing the management capabilities of devices that are configured according to the functional equivalent of Figure 6.3-1.

EXAMPLE - The hostport value to access the management services in a remote device named m51568 would typically be represented as "m51568:61499". If a Domain Name System (DNS) server were not available, but the remote device's Internet Protocol (IP) address were known to be 161.153.19.227, the corresponding hostport value would be "161.153.19.227:61499".

6.2 Device management services

The device management services to be implemented are provided by the functional equivalent of an instance of the DEV_MGR type shown in Figure 6.2-1. The types and semantics of the inputs and outputs of this type are identical to the correspondingly named inputs and outputs of the MANAGER type defined in subclause 3.3.2 of IEC 61499-1, with the following differences:

1. The DST input designates the destination of the RQST input as follows:
   • A value of "" (the empty string) designates the device.
   • A value containing an IEC 61131-3 identifier designates a resource within the device. For example, a DST value of "RES1" indicates that the RQST input is destined for a resource named RES1 contained in the managed device.
   • A value containing a sequence of IEC 61131-3 identifiers separated by full stops (the "." character) indicates a resource in a containment hierarchy of resources, with the leftmost identifier corresponding to the outermost resource and the rightmost identifier corresponding to the innermost resource. For example, a DST value of "MOTOR1.WINDING2" indicates that the RQST input is destined for a resource named WINDING2 contained in a resource named MOTOR1 which is contained in the managed device.
2. The RQST input and RESP outputs are encoded according to the Request and Response elements, respectively of the XML DTD given in subclause 6.4. The semantics of these elements shall be as defined in subclause 6.5.
3. As illustrated in Figure 6.2-1, a REQ+ primitive input always results in a CNF+ primitive output, since the actual result including failure conditions is encoded in the RESP output. Similarly, a REQ- input always results in a CNF- output, since no management operation is attempted in this case. In particular, this means that, in an instance of the DM_KRNL function block type shown in Figure 6.3-2, an IND- primitive from the communication service interface will neither cause a management operation to be performed, nor will a response message be generated.

The sequences of service primitives for device management shall be as shown in Figure 6.2-1. The object denoted manager in these service sequences is an instance of class FBManager described in Annex C.2 of IEC 61499-1. This is the manager of the device or a contained resource depending on the value of the DST input.

6.3 Devices

Management of devices shall be accomplished by the functional equivalent of the configuration shown in Figure 6.3-1 in each device type. The DM_KRNL function block type used in this configuration is shown in Figure 6.3-2.

Suppliers of devices shall provide the equivalent of the value of the MGR_ID input of their instance of the RMT_DEV type shown in Figure 6.3-1, that is, the value of the hostport element defined in IETF RFC 1630 to be used for access to the device management services. This value will typically be "localhost:61499". This value may be defined as part of a library element file for the device type, or may be configured through some means beyond the scope of this specification, for instance via a local serial port or configuration file.

6.4 FBMGT Document Type Definition (DTD)

The Request and Response elements defined in the FBMGT DTD represent the XML syntax for the RQST input and RESP output, respectively, of the DM_KRNL function block type. Explanations of the elements of this DTD, and (where applicable) references to the formal syntax for their attributes, are given in Table 6.4-2. Allowable combinations of elements, and constraints on their usage, are as given in Table 5.2 of IEC 61499-2 for the various device classes.

An example of the use of these elements is given in Annex B.

NOTE - To provide compact messaging, the prolog and Misc* components used in the XML document production are not used in FBMGT messages since these components are implicit in the management context; thus, only the Request or Response element is transmitted as the management message.

NOTE 1 - Depending on the context, the syntax of a Source or Destination element should correspond to the syntax of the respective element in one of the productions connection_end_point or accessed_data given in Annex B.5 of IEC 61499-1.

NOTE 2 - The productions input_variable_name and output_variable_name apply when the associated VarDeclaration element is part of an InputVars or OutputVars element, respectively.

NOTE 3- The syntax of this element when present shall be equivalent to the syntactic expression (subrange {',' subrange}) | integer {',' integer}, where the non-terminals subrange and integer are as defined in Annex B of IEC 61131-3. Each term of the second form is equivalent to the subrange 0..n-1, where n is the value of the corresponding integer syntactic element. If this element is missing, the variable is not an array.

NOTE 4 - The syntax of this element is the syntax for initialization of the corresponding variable type as defined in Annex B.1.4.3 of IEC 61131-3.

NOTE 5 – The terms event_input_name and event_output_name apply when the Event element is part of an EventInputs or EventOutputs element, respectively.

NOTE 6 – The expressions (input_variable_name {',' input_variable_name}) and (output_variable_name {',' output_variable_name}) apply when the Event element is part of an EventInputs element or an EventOutputs element, respectively.

NOTE 7 - The terms plug_name and socket_name apply when the associated AdapterDeclaration element is part of a Plugs or Sockets element, respectively.

6.5 Request/Response semantics

The following rules shall apply to the use of the Request and Response elements defined in subclause 6.4 in the normal_request service sequence shown in Figure 6.2-1.

1. The ID attribute of the Response element shall be identical to the ID attribute of the Request element to which the Response element refers.
2. The absence of a Reason attribute in a Response element shall be used to indicate normal completion of the requested operation.
3. The use of sub-elements in Request and Response elements, and the meaning of possible Reason attributes of the Response element when the requested operation fails, shall be as defined in Tables 6.5-1 and 6.5-2.

• NOTE 1 - A normal Response to a READ Request will contain a Parameter sub-element with no Reference attribute, and with a Value attribute corresponding to the value of the referenced parameter.
• NOTE 2 - A WRITE Request contains a Parameter sub-element with its Reference and Value attributes encoded as specified in Table 6.4-2. A normal Response to the WRITE Request will have a Reference attribute equal to that in the request, and will have no Value attribute.
• NOTE 3 - Additional Reason codes may be defined by providers of management function blocks. Software tools may but are not required to recognize and process these codes.
• NOTE 4 - In this case, all managed FBs are started or stopped as follows:
  • First, all FBs that are not instances of E_RESTART are started in the reverse order of their creation.
  • Second, instances of E_RESTART are started in the reverse order of their creation.
  This procedure is followed to ensure that later-created FBs (which are usually "downstream" in event flow from earlier-created FBs) are ready to receive events from "upstream" FBs and E_RESTART instances when the latter are started.