5. INTEROPERABILITY PROVISIONS

Devices and resources conforming to this specification shall fulfill the following interoperability requirements.

5.1 Physical layer

The physical layer shall be capable of supporting the requirements specified below for Data Link layer services.

5.2 Data link layer

Data link layer services shall be capable of supporting the requirements of interfacing the underlying physical layer to the Transport and Session protocols specified below.

5.3 Network, Transport and Session layers

The Network layer services shall be Internet Protocol (IP) as defined in IETF RFCs 791, 792 and 950. Transport and Session layer services shall be Transmission Control Protocol (TCP) as defined in IETF RFC 761 or multicast User Datagram Protocol (UDP) as defined in IETF RFC 768, with packet lifetime limited to a single hop.
Compliant UDP implementations shall be capable of transporting a payload of up to 1472 octets (the maximum payload of a single UDP packet over Ethernet using IPv4 without IP fragmentation).
In order to avoid conflict with addresses reserved by IETF RFCs 1112 and 1700, the following restrictions shall be observed:
  1. IP addresses for multicast UDP shall be limited to the ranges 225.0.0.0 through 231.255.255.255 and 233.0.0.0 through 239.255.255.255, respectively.
  2. Port numbers shall be restricted to the range 1024 through 65535.
  3. The "special cases for IP addresses" listed in IETF RFC 1700 shall be observed.

The services of these layers shall be provided by the functional equivalent of encapsulating an instance of the appropriate class from the package java.net, in an appropriate instance of an IEC 61499-1 Communication Service Interface Function Block (CSIFB). The encapsulated class corresponding to each generic CSIFB type is listed in Table 5.3. Implementation-specific details of CSIFB types are given in subclause 5.5.

Table 5.3 - Equivalent encapsulated Java™ classes

Generic CSIFB type

Encapsulated class

PUBLISH java.net.DatagramSocket
SUBSCRIBE java.net.MulticastSocket
CLIENT java.net.Socket
SERVER java.net.Socket

5.4 Presentation layer

Data shall be exchanged among devices using the IEC61499-FBDATA syntax and the COMPACT encoding defined in Annexes E.3.2 and E.3.3.2 of IEC 61499-1, respectively. The data transferred shall correspond to the ASN.1 expression

CHOICE{NULL, FBDataSequence} .

5.4.1 Encoding of FBDataSequence elements

An FBDataSequence shall be encoded as a sequence of one or more contiguous FBData elements, and shall not include a preceding type or length field.
NOTE - This differs from the encoding specified in ISO/IEC 8825-1, which permits zero or more elements in a sequence-of encoding. In this Compliance Profile, an empty sequence is encoded as a NULL element as defined in 5.4.2.

5.4.2 Encoding of the NULL element

The NULL element shall be encoded as a single byte containing the tag of the NULL type ( 16#05 ) as defined in ISO/IEC 8825-1.

5.4.3 Unsupported types

Since many run-time systems do not support unsigned 64-bit integer values, it is not required that the ULINT type be supported.

It is not required that the data types DATE and TIME_OF_DAY be supported, since strings representing their values can always be derived as substrings of a full string representation of the corresponding DATE_AND_TIME type.

5.4.4 Encoding of values of elementary data types

The values of elementary data type elements shall be transferred according to the following modified ASN.1 syntax:

ElementaryData ::= CHOICE{
BOOL,
FixedLengthInteger,
FixedLengthReal,
TIME,
AnyDate,
AnyString,
FixedLengthBitString,
ARRAY}

5.4.4.1 Encoding of time-related values

Values of the time-related data types shall be encoded as specified in the syntax of Annex E.3.2 and the encoding rules of Table E.1 of IEC 61499-1, with the exception that the value of DATE_AND_TIME type shall be encoded as for type LINT rather than ULINT (see 5.4.3).

5.4.4.2 Encoding of string elements

The length field of STRING and WSTRING elements shall be encoded as for the UINT type, i.e., a 16-bit unsigned integer.

NOTE - This would appear to restrict the maximum number of elements of a STRING or WSTRING to 65535. However, the actual length may be further restricted by the maximum number of octets that can be transferred by the underlying transport protocol. For compliant UDP implementations as defined in 5.3, this number is 1472. Thus, the maximum transmittable length of a STRING element using UDP would be (maximum octets - tag octets - length octets)/(character length) = (1472-1-2)/1 = 1469 characters, and the maximum transmittable length of a WSTRING element using UDP would be (1472-1-2)/2 = 734 characters.

The encoded character sequence for both STRING and WSTRING values shall be such that the first character in the string is the first encoded value, e.g., for the string " ABC " the first encoded character shall be " A " and the last shall be " C ". The values of the individual character elements of the STRING and WSTRING types shall be encoded in the same way as the values of the USINT and UINT types, respectively.

5.4.4.3 Encoding of ARRAY elements

ARRAY elements shall be transferred according to the following modified ASN.1 syntax:

ARRAY ::= [APPLICATION 22] IMPLICIT SEQUENCE OF FBData

NOTE - Since ARRAY is a subclass of FBData , a multidimensional ARRAY may be encoded recursively as an ARRAY whose elements are ARRAY elements.

The encoding of ARRAY elements shall be constructed in the sense of ISO/IEC 8825, with the following provisions for COMPACT encoding:

  1. The "length" subfield of the ARRAY element shall be encoded as a value of the UINT type without identifier or length octets, i.e., as a 16-bit unsigned integer.

    NOTE - This would appear to restrict the maximum number of elements of an ARRAY to 65535. However, the actual length may be further restricted by the maximum number of octets that can be transferred by the underlying transport protocol. For compliant UDP implementations as defined in 5.3, this number is 1472. Then, for instance, the maximum transmittable length of an ARRAY of BYTE elements using UDP would be (maximum octets - tag octets - length octets - element type octets)/(element length) = (1472-1-2-1)/1 = 1468 elements.

  2. The COMPACT encoding specified in IEC 61499-1 shall be used for the first element of the values field.
  3. Subsequent elements, if any, shall be encoded using the COMPACT syntax without an identifier subfield.
  4. If the specified length of the received ARRAY is less than the locally allocated space, the remaining elements of the local array shall be unaffected; if the length of the received ARRAY is greater than the locally allocated space, the remaining received elements shall be ignored.

5.4.5 Encoding of values of derived data types

Values of derived data types shall be transferred according to the following modified ASN.1 syntax:

DerivedData ::= CHOICE{
DirectlyDerivedData,
EnumeratedData,
SubrangeData,
ArrayData,
STRUCT}

5.4.5.1 Encoding of structured data type elements

The encoding of instances of structured data types shall be constructed in the sense of ISO/IEC 8825, with the following provisions for COMPACT encoding:

  1. The "length" subfield shall not be used in the encoding of the main element.
  2. Elements of the structure shall be encoded in the order given in the declaration of the structured data type, using the COMPACT encoding rules without an identifier subfield.

5.4.5.2 Encoding of enumerated data type elements

The encoding of values of enumerated data types shall use the COMPACT encoding rules, according to the following modified ASN.1 syntax:

EnumeratedData ::= [typeID] IMPLICIT USINT

The encoded value zero (0) shall correspond to the first enumerated value, with subsequent encoded values corresponding to the subsequent enumerated values.

NOTE - This limits the maximum number of enumerated values to 256.

5.4.5.3 Encoding of subrange data type elements

The encoding of values of subrange data types shall use the COMPACT encoding rules, according to the IEC61499-FBDATA syntax given in IEC 61499-1-F.3.1.1.

5.4.5.4 Encoding of array data type elements

Values of array data types shall be transferred according to the following modified ASN.1 syntax:

ArrayData ::= [typeID] IMPLICIT ARRAY

The encoding of values of array data types shall follow the rules given in 5.4.4.3, where the [APPLICATION 22] tag is replaced by the assigned tag of the array type.

5.5 Application layer

  1. Communication service interface function blocks (CSIFBs) for unidirectional data exchange among devices shall be instances of the PUBLISH/SUBSCRIBE function block types defined in Annex F.2.1 of IEC 61499-1. For the purposes of this Compliance Profile, the following extensions apply:
  2. CSIFBs for bidirectional data exchange among devices shall be instances of the CLIENT/SERVER function blocks defined in Annex F.2.2 of IEC 61499-1.
  3. CSIFB types for the exchange of defined numbers of data items shall have the following type name formats:
  4. A value of zero (0) for N, NI or NO in the above formats indicates that a corresponding NULL data item, encoded as specified in subclause 5.4.2, is to be transmitted or received.
  5. The PARAMS input of the standard CSIFBs shall be renamed ID and shall be of type WSTRING (this substitution is allowed by Table 3.1.1 of IEC 61499-1). The contents of this string shall correspond to the syntax and semantics of the hostport element defined in IETF RFC 1630.
  6. The STATUS output of the standard CSIFBs shall be of type WSTRING. The values of this string and their corresponding semantics shall be as shown in Table 5.5.

Table 5.5 - STATUS output values

Value Corresponds to Semantics
"OK" INITO+, CNF+, IND+ Valid operation
"INVALID_ID" INITO- Invalid ID input
"TERMINATED" INITO- Service termination
"INVALID_OBJECT" CNF-, IND- Invalid object type received or requested to be sent
"DATA_TYPE_ERROR" CNF-, IND- Received object type does not match actual output type
"INHIBITED" CNF- Caused by REQ-
"NO_SOCKET" CNF- No socket available to serve REQ+
"OVERFLOW" CNF-, IND- Encoded data exceeds communication buffer size
"UNDERFLOW" CNF-, IND- Received data is insufficient to supply all required RD values
Other values INITO-, CNF-, IND- Socket service errors
Last updated: 2016-03-10.
©2011-2016 Holobloc Inc.
Licensed under the Academic Free License version 3.0.