Design Pattern: Tagged Data

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 example 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.

Tool Support

• 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 reading or 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 a tag is selected and visible in the tag table when a new FB instance is created, the initial FB name in the FB creation dialog is set to the tag name. If the created FB instance is of type TAGIN or TAGOUT, the associated Tag data is automatically applied to the input parameters of the FB.
• If a new row is selected in the tag table when a FB instance is selected in the diagram, the tag data is applied to the FB instance if appropriate. For instance, in the example below the TRANSPORT_SENSE 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 layered MVC 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.