This subclause provides an overview of PubSub communication options and the use of DataSets. For a complete description of PubSub communication, PubSub communication options, DataSets and DataSetMetaData, please see OPC 10000-14.
PubSub communication has multiple options that are defined by Profiles. To see what is defined in UAFX for a controller or device, see the UAFX-defined Profiles in the Profile database. When setting up communication between controllers, between a device and a controller, or even between devices, the engineering tool must ensure that the PubSub Profile to be used for the communication is available on the communicating devices. To ensure interoperability, the UAFX controller Profile require a specific PubSub Profile. Vendors are free to add additional PubSub Profiles.
At this point, UADP is required in UAFX Profiles, and thus, this discussion will focus on this communication protocol. Within a Profile, there are options related to the communication configuration. The engineering tools and/or ConnectionManager can make various selections. This can include optimizations which group multiple DataSetMessages into a single Network Message (see Figure E.16).
Figure E.16 – UADP network message overview
Many of the options are self-described in the UADP PubSub communication protocol, allowing a Subscriber to handle a larger range of published messages. The UADP communication includes header information that describes the overall DataSet. It can include information like a timestamp and/or status information (see Figure E.17).
Figure E.17 – DataSetMessage header
The DataSetMessage can use the periodic fixed mapping, depending on the communication options selected. It is a fixed structure where all items defined in the DataSet have a value that is returned in every message. The message only contains the values, so the Subscriber has to be aware of the order/mapping of Variables in the DataSet (see Figure E.18). The encoding of the value is also configurable. The period fixed profile requires the encoding as a raw value. Other profiles support a variant encoding (which allows for a status to be sent in the case of a bad status) or a DataValue (value, status, and timestamps) encoding.
Figure E.18 – Fixed DataSetMessage
Other PubSub Profiles can include a dynamic layout. In this case, the DataSetMessage can also be a delta frame, which is very similar to Client Server communication, and only changed values are sent. In this type of DataSetMessage, an index and the value are packaged into the message. The index is only an index into the array of Variables defined in the DataSet (see Figure E.19).
Figure E.19 – Delta frame DataSetMessage
The DataSetMessage can also be an Event. Events are much like fixed DataSetMessages, except that they are always a structure that is encoded as a Variant (see Figure E.20).
Figure E.20 – Event DataSet data
In this version of this document, Events are not used.
The configuration of a DataSet is defined as an array of a structure, where the structure lists the details of the item that is to be published, and the array provides the order in which they will be in the DataSet. These DataSets may be preconfigured or be created at run time. Figure E.21 illustrates what is defined as part of a DataSet (both Publisher and Subscriber).
Figure E.21 – Dataset definition information
Preconfigured DataSets can be provided in UAFX as part of a FunctionalEntity or as part of an AutomationComponent.
For this version of the document, it is recommended to provide preconfigured DataSets as part of a FunctionalEntity. Use cases for DataSets as part of an AutomationComponent may be added in a later version of this document.
When establishing communication, the DataSet and the Publisher's DataSetMetaData define what is on the wire. This includes which Nodes are used for the Values, their DataTypes (on the wire and native), the size (if an array or string) and the possible pre-processing of the Values (filtering, error handling, etc.).
The DataSet definition on the Subscriber describes the mapping of fields in the DataSet to Variables in the Server. It includes error handling and allows for restricting the data field to a specific index in the field (fields that were arrays on the wire). The (Standalone-) SubscribedDataSet can select a subset of the transmitted fields, i.e., it can skip any values that it is not interested in.
In a ConnectionConfigurationSet, a specific Connection can use a preconfigured DataSet or dynamically create a DataSet for the Publisher or Subscriber. Regardless of whether the DataSet is preconfigured or dynamically configured, the important aspect for the engineering tool and the ConnectionManager is that the appropriate published Variable is mapped to the appropriate subscribed Variable. This also includes checking that the DataType of the Variables is correct (and matches) and that the engineering units or other metadata associated with the Variable also matches (see 5.5.6.2.5).
The verification of metadata and DataSet can be minimized if the ConnectionEndpointParameter contains ExpectedPublishedDataSetVersion and/or ExpectedSubscribedDataSetVersion. These Variables can be used to confirm that the current configuration matches what was defined in the engineering tool.
Three possible combinations of DataSets exist for an information flow on a Connection between two FunctionalEntities to be configured:
- Preconfigured DataSets exist on both endpoints.
- A preconfigured DataSet exists on just one of the endpoints.
- Preconfigured DataSets do not exist on either endpoint.
For scenario (a), the engineering tool configuring the information flow uses the preconfigured DataSets.
NOTE A unidirectional Connection has one information flow. A bidirectional Connection consists of two information flows (see 5.5.1).
For scenario (b), the engineering tool configuring the information flow creates a customized DataSet with DataSetMetaData matching the preconfigured DataSet for the desired variables. The engineering tool should provide (as in scenario (a) the name of the preconfigured DataSet for one ConnectionEndpoint but leave the name empty on the other ConnectionEndpoint.
For scenario (c), the engineering tool configuring the information flow creates customized DataSets with matching DataSetMetaData for both ConnectionEndpoints.
An engineering tool or the ConnectionManager may generate the PubSubConfiguration.
If the engineering tool generates the PubSubConfiguration, it will store customized DataSets within the PubSubConfiguration, e.g. PublishedDataSets in publishedDataSets and SubscribedDataSets as part of the DataSetReader. Preconfigured DataSets are used by setting the dataSetName in the DataSetWriter or DataSetReader.
If the ConnectionManager is intended to generate the PubSubConfiguration, the engineering tool would add the names of preconfigured DataSets to be used in the ConnectionEndpointConfigurationParameter (e.g., PreconfiguredPublishedDataSetName or PreconfiguredSubscribedDataSetName). Customized DataSets can be stored in the PublishedDataSetData or SubscribedDataSetData (see F.1.5) or within the vendor-specific download format.
A ConnectionConfigurationSet might contain multiple Connections that all need to be communicating as a set. In this case, the ConnectionManager and/or the engineering tool can also optimize communication by grouping Variables for multiple Connections into a single DataSet or into a single network message. For example, if the ConnectionConfigurationSet has three Connections between two AutomationComponents (different FunctionalEntities), the PubSub configuration might be a single DataSet with all the required Variables. Alternatively, it might be three DataSets in a single network message. If more AutomationComponents are in the set, it might even be a multicast network message that multiple AutomationComponents could be subscribing for. Please refer to Clause 5.5.6.2 for further information.