Problem Statement

Instances of adapter types provide a convenient means of reducing diagram clutter by replacing a bundle of related, and possibly bidirectional, event and data connections with a single graphical connection. In addition, an adapter type can be used as an abstract model for an associated service specification, in contrast to a Service Interface Function Block (SIFB) type, which defines a concrete implementation of its associated service specification.

In a distributed system configuration, it is desirable to be able to extend an adapter connection across resources, which may be in different devices. Since the adapter connection can contain multiple event and data connections, each of which may be oriented in the plug-to-socket or socket-to-plug direction (but not both), implementation using PUBLISH/SUBSCRIBE SIFBs would require the establishment and maintenance of multiple UDP multicast channels. However, since adapter connections are defined as one-to-one (plug-to-socket) in IEC 61499-1, a single CLIENT/SERVER connection would be suitable, providing some means can be provided to multiplex the several event connections that may exist in the adapter connection onto the single CLIENT.REQ⇒SERVER.IND event connection and the single SERVER.RSP⇒CLIENT.CNF event connection.

Framework

• An instance of the E_TO_UINT FB type is used to multiplex multiple events into a single CLIENT.REQ or SERVER.RSP event input, plus a UINT value (E_TO_UINT.N) indicating the event number,which is connected to the SD_1 input of the respective CLIENT or SERVER.
• An instance of the E_DEMUX FB type is used to demultiplex the SERVER.IND or CLIENT.CNF event output, using the RD_1 output of the CLIENT or SERVER as the event number (E_DEMUX.K).

Methodology

1. Develop the required adapter type.
   • It is recommended to name the adapter type xxx_ADP, where xxx is the name of the service provided across the adapter connection. See, for example, the TUNING_ADP adapter type.
2. Develop a pair of function block types xxx_ppp and xxx_sss, where ppp names the functionality of the block containing the plug adapter of type xxx_ADP and sss names the functionality of the block containing the socket adapter of type xxx_ADP. See, for example, the FB types TUNING_HMI and TUNING_SIM, respectively.
3. Test the adapter type by interconnecting instances of the two FB types developed above via an adapter connection in a single resource. See, for example, the TUNING_TEST system configuration.
4. Develop the composite function block types xxx_CLIENT and xxx_SERVER, using the event multiplexing/demultiplexing scheme described above. For example, see the TUNING_CLIENT and TUNING_SERVER function block types.
5. Build and test a distributed system configuration using interconnected instances of the xxx_ppp and xxx_CLIENT types in one resource, and interconnected instances of the xxx_SERVER and xxx_sss types in a different resource (possibly in a remote device). See, for example, the TUNING_TESTR system configuration.

Tool Support

It is possible that software tools could automatically generate and deploy instances of the required xxx_CLIENT and xxx_SERVER function block types when a connection of the xxx_ADP adapter type must be deployed across resources or devices, as described above.