- 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.
In addition to the
service interface types, which use communication networks for
exchange of data, and the
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 (
) or vice versa (
) according to the following features:
- As in the Local
Multicast framework, the local multicast group is identified by
IDinput. 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
TYPEinput as a comma-separated list of data types, e.g.,
- The remote multicast group address is given by the
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
input as explained above.
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 MVC design pattern for other examples). The
data for this table is derived from the instances of the
TAGOUT/TAGINservice 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
PUBLISH_n/SUBSCRIBE_nblocks 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
TAGINtype 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_SENSEtag data is applied to the
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.
- Distribute and debug the application among "local" devices
FRAME_DEVICE, using the local multicast pattern. As an example, see the
- 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_FRAME, as appropriate.