Connections between FunctionalEntities are designed to exchange data by utilizing OPC UA communication models. This revision of the specification supports the PubSub communication model as defined in OPC 10000-14. Future revisions may support the Client / Server communication model.
This clause illustrates how Connections utilize the PubSub communication model, focusing on three use cases relevant in the context of industrial automation and the design of AutomationComponents. These are just illustrations, and additional or different uses may also apply.
This use case, illustrated in Figure 12, describes a single logical connection between two FunctionalEntities located on the AutomationComponents A and B, each containing a Publisher, a Subscriber, and a single PubSubConnectionEndpoint. Both FunctionalEntities could be publishing data (bidirectional connection), or only one could be publishing data while the other publishes a heartbeat (unidirectional connection with heartbeat).
Figure 12 illustrates the logical connection between the two FunctionalEntities FE_A1 and FE_B1. Each FunctionalEntity contains a PubSubConnectionEndpoint (Con_A1 and Con_B1) which references a DataSetReader and DataSetWriter.
Figure 13 illustrates two Connections, each between two PubSubConnectionEndpoints. Each PubSubConnectionEndpoint on AC_A (and similarly on AC_B) references a DataSetWriter (and DataSetReader) that are located under the same WriterGroup (and ReaderGroup).
The PubSub instances are configured to exchange data between AC_A and AC_B using unicast NetworkMessages. This use case is called aggregated because a single NetworkMessage aggregates multiple DataSetMessages (one per logical connection). Aggregation reduces the required network bandwidth.
This use case, illustrated in Figure 14, could be applied to an AutomationComponent (AC_A) communicating with multiple AutomationComponents (AC_B and AC_C). To minimize network bandwidth usage in specific topologies, AC_A may aggregate published data into a single NetworkMessage, which is sent via multicast to the associated AutomationComponents AC_B and AC_C. In turn, AC_B and AC_C publish an individual NetworkMessage back to AC_A. Multicast can also help with scaling issues in the device (less processing of network messages is required).
Connections are configured by an engineering tool on behalf of Descriptors and are deployed to a ConnectionManager (see 5.5.2). Independent of the lifetime of a Connection, another engineering tool may update a FunctionalEntity, including its preconfigured DataSets. In addition, the Descriptor may describe a different version of the FunctionalEntity to be connected at runtime. This may result in misinterpretation of the exchanged data.
To prevent this error scenario, PubSub provides the DataSetMetaData. DataSetMetaData describes the content and semantics of a DataSet. In addition, the DataSetMetaData provides the details defining the contract between Publisher and Subscriber, including how to encode and decode the DataSetMessage. Thus, Subscribers must have knowledge about the DataSetMetaData of the PublishedDataSet. For the concepts of the DataSetMetaData and its definition, see OPC 10000-14.
Any change to a PublishedDataSet regarding its content but also its semantics (e.g., engineering units) would generate changes to its DataSetMetaData, indicated by a change in its ConfigurationVersion (see OPC 10000-14). Depending on the chosen UADP header layout, the ConfigurationVersion of an individual Publisher or a GroupVersion combining the ConfigurationVersions of all Publishers belonging to a WriterGroup is transmitted with the NetworkMessage. Any mismatch between the transmitted version and the one configured at the Subscriber will cause the Subscriber to go into Error. To resolve the Error, the Subscriber needs an update of the DataSetMetaData. OPC 10000-14 offers multiple manners for accomplishing this.