Problem Statement

Ensure that:

• Data used in a local multicast channel is consistent with that used in the corresponding distributed multicast channel.
• Data subscribed from a multicast channel is consistent with that published on the channel.

Framework

In addition to the PUBLISH_n/SUBSCRIBE_n service interface types, which use communication networks for exchange of data, and the PUBL_n/SUBL_n service interface types described under the Local Multicast pattern, only the two additional functional block types shown below are required. The function of these these blocks is to translate data from a local multicast group to a remote multicast group ( TAGOUT ) or vice versa ( TAGIN ) according to the following features:

• As in the Local Multicast framework, the local multicast group is identified by the ID input. For convenience, the default value of this input is set to the function block's instance name. This can be overridden by connection to a non-default variable or configuration parameter.
• The number, order and types of data elements being transferred is given by the TYPE input as a comma-separated list of data types, e.g., "BOOL,UINT,WSTRING".
• The remote multicast group address is given by the CHANNEL input, e.g., "225.0.0.1:1025".

An abstract internal implementation of each of these function block types is shown below for the case when a single data element is being transferred. The actual number and types of data being transferred is determined by the TYPE input as explained above.

Hover on a highlighted element to pop up its description.

Tool Support

The FBDK provides built-in support for the use of tagged data when a system configuration is being edited:

• A tag data base is maintained in the form of a Tags table as illustrated below (see the MVCD design pattern for other examples). The data for this table is derived from the instances of the PUBLISH_n/SUBSCRIBE_n, PUBL_n/SUBL_n and TAGOUT/TAGIN service interface types in the system configuration.
• Inconsistencies among usages of instances of function block types using the same tag are detected and flagged as errors when editing a system configuration. Such inconsistencies include
  • Inconsistent numbers or types of data being transferred.
  • Inconsistent multicast channel IDs among TAGOUT/TAGIN and PUBLISH_n/SUBSCRIBE_n blocks using the same tag.
• If feasible, a tag can be applied to an instance of the PUBLISH_n, SUBSCRIBE_n, PUBL_n, SUBL_n, TAGOUT, or TAGIN type by selecting the tag in the Tags table, then using the Drag and Drop gesture to drag the tag from the table to the instance name of the FB. For instance, in the example below the TRANSPORT_SENSE tag data is applied to the SENSE_TRANSPORT FB.

Methodology

The methodology for using this design pattern consists of the two steps listed below. It can be used as a sub-pattern to simplify and avoid errors in the Distribution phase of other methodologies, such as the MVCD pattern.

1. Distribute and debug the application among "local" devices such as FRAME_DEVICE, using the local multicast pattern. As an example, see the FLASHER_TESTD system configuration.
   • This may be done by re-organizing resources from a single-device configuration such as FLASHER_TESTL, using the Move To pop-up menu item on a resource in the Navigation tree.
2. Replace the local devices with instances of their equivalent remote device types, e.g., RMT_DEV or RMT_FRAME, as appropriate.
   • Add a TAGS resource (typically an instance of EMB_RES) to each device to map from local multicast to UDP multicast using instances of TAGIN and TAGOUT as appropriate.
   • For example, see the FLASHER_TESTR system configuration.