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.
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
andTAGOUT/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
andPUBLISH_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
, orTAGIN
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 theTRANSPORT_SENSE
tag data is applied to theSENSE_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.
- Distribute and debug the application among "local" devices
such as
FRAME_DEVICE
, using the local multicast pattern. As an example, see theFLASHER_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.
- This may be done by re-organizing resources from a
single-device configuration such as
- Replace the local devices with instances of their
equivalent remote device types, e.g.,
RMT_DEV
orRMT_FRAME
, as appropriate.- Add a
TAGS
resource (typically an instance ofEMB_RES
) to each device to map from local multicast to UDP multicast using instances ofTAGIN
andTAGOUT
as appropriate. - For example, see the
FLASHER_TESTR
system configuration.
- Add a