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.

EXAMPLE - Ethernet data link services per ISO/IEC 8802-3 may be used when the underlying physical layer is Ethernet per ISO/IEC 8802-3.

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.

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.
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:
   • CLIENT_NI_NO or SERVER_NI_NO, where NI is the number of data items to be transmitted and NO is the number of data items to be received.
   • CLIENT_N or SERVER_N, where N is the number of data items to be both transmitted and received.
   • PUBLISH_N or SUBSCRIBE_N, where N is the number of data items to be transmitted or received, respectively.
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.

   EXAMPLE - A SERVER function block type with two data inputs SD_1 and SD_2 and a single data output RD_1 would have the type name SERVER_2_1. A corresponding CLIENT function block type would have a single data input SD_1 and two data outputs RD_1 and RD_2, and would have the type name CLIENT_1_2.

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 fbURI component of the following syntax in the ABNF notation:

   fbURI = [scheme "://"] fbhost ":" port
fbhost = IPv4address / "localhost"

   The syntax and semantics of the scheme, port, and IPv4address components shall be as defined in IETF RFC 3986.

   At the date of this document, CSIFBs shall ignore the scheme "://" prefix if present, unless the provider of the CSIFB specifies otherwise.

   The range of addresses for PUBLISH and SUBSCRIBE function blocks is limited to the IPv4 multicast address range, namely 224.0.0.1 through 239.255.255.255, and the socket number is limited to the range {1..65535}.

   • NOTE 1 - The above provisions guarantee that the ID input of the standard CSIFBs will be a syntactically valid URI as defined in IETF RFC 3986.
   • NOTE 2 - The possible use of the IPv6address component (or a subset thereof) defined in IEC RFC 3986 is under consideration.
   • EXAMPLE 1 - The ID input for a SERVER block at port number 1499 of a host device with IPv4 address "161.153.19.227" could be represented as "161.153.19.227:1499", "localhost:1499" or "127.0.0.1:1499". The ID input of a CLIENT block desiring access to this SERVER could be "161.153.19.227:1499". If it were located in the same device as the SERVER block, its ID input could also have the form "localhost:1499" or "127.0.0.1:1499".
   • EXAMPLE 2 - The ID input for a PUBLISH function block desiring to publish data at UDP (User Datagram Protocol) port number 230.0.0.1:4445 would be represented as "230.0.0.1:4445". This would be identical to the ID input(s) of the corresponding SUBSCRIBE block(s).
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.