This clause describes the configuration settings for the connection types defined in Clause 5.5.1 using PubSub as a communication model. For simplicity, all samples describe a single logical connection contained in the ConnectionConfigurationSet. Note, however, that as shown in E.1.3, a ConnectionConfigurationSet may contain multiple Connections, which may have different connection types.

The examples provide illustrations of how PubSub communication can be configured. The configuration contains various settings that have an influence on the communication model, including Address, PublishingInterval, QoS, MessageReceiveTimeout, ReceiveQos and SecurityMode (see 6.13.3 for additional details). Some of these settings can be complex to apply, such as the Address. Depending on the type of connection, this Address might contain a destination address, a receiving address, or a multicast address.

To set up the PubSubConfiguration for the bidirectional connection (illustrated in Figure E.1), information from multiple configuration elements is used, as illustrated in Figure E.10. For a simpler overview, configuration data not related to the communication model and the Endpoint2 are omitted.

Figure E.10 – Configuring PubSub

CommunicationModelConfig contains the PubSub configuration elements to be applied to the AutomationComponent. The ConnectionManager uses the configuration information in Flow1 and Sub1 to update the communication model. CommunicationLinks indicate which DataSetReader and DataSetWriter contained in the communication model are relevant for this ConnectionEndpoint. This information is also used to set up the ToDataSetReader and ToDataSetWriter References on Con_A.

The ConnectionConfiguration for a bidirectional connection contains the following configuration information (see Figure E.11):

• EndpointA, indicating InputVariables and OutputVariables,
• EndpointB, indicating InputVariables and OutputVariables,
• Flow1 and SubB describing the configuration for the information flow from EndpointA to EndpointB,
• Flow2 and SubA for the information flow from EndpointB to EndpointA.

Figure E.11 – Bidirectional connection illustration

The ConnectionConfiguration for a unidirectional connection with heartbeat contains the following configuration information (see Figure E.12):

• EndpointA, indicating OutputVariables,
• EndpointB, indicating InputVariables,
• Flow1 and SubB describing the configuration for the information flow from EndpointA to EndpointB,
• Flow2 and SubA for the heartbeat from EndpointB to EndpointA.

Figure E.12 – Unidirectional connection with heartbeat illustration

The ConnectionConfiguration for a unidirectional connection contains the following configuration information (see Figure E.13):

• EndpointA, indicating OutputVariables,
• EndpointB, indicating InputVariables,
• Flow1 and SubB describing the configuration for the information flow from EndpointA to EndpointB.

Figure E.13 – Unidirectional connection illustration

The ConnectionConfiguration for an autonomous publisher contains the following configuration information (see Figure E.14):

• EndpointA, indicating OutputVariables;
• Flow1, describing the configuration for the information flow from EndpointA to one or more unknown Subscribers.

For an autonomous publisher, no SubscriberConfiguration is required (see 6.13.3.2).

Figure E.14 – Autonomous publisher illustration

The ConnectionConfiguration for an autonomous subscriber contains the following configuration information (see Figure E.15):

• EndpointA, indicating InputVariables,
• Flow1 and SubA describing the configuration for the information flow from an unknown Publisher to EndpointA.

For an autonomous subscriber, no ToOutboundFlow Reference is required. Configuration which applies only to the Publisher of the information flow may be omitted, i.e., Address and TransmitQos (see E.4.1).

Figure E.15 – Autonomous subscriber illustration

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:

1. Preconfigured DataSets exist on both endpoints.
2. A preconfigured DataSet exists on just one of the endpoints.
3. 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.