The logical functionality of an AutomationComponent is represented by one or more FunctionalEntities described in 4.4. An important part of the functional model is the data exchange between FunctionalEntities using logical connections. Figure 8 illustrates this interaction.

A logical connection is represented by two ConnectionEndpoints, one on each FunctionalEntity that is part of the connection. Figure 28 provides a more detailed view of the Objects involved.

Logical connections are configured using ConnectionConfigurationSets.

The following types of logical connections are supported (see Figure 10):

Bidirectional connections describe bidirectional data exchange between two FunctionalEntities.

Unidirectional connections with heartbeat describe unidirectional data exchange in one direction and a heartbeat message (for logical connection monitoring) in the opposite direction between two FunctionalEntities.

Unidirectional connections describe unidirectional data exchange between two FunctionalEntities.

Autonomous publisher describes data published by a FunctionalEntity, where the related subscribing ConnectionEndpoint(s) are unknown to the logical connection.

Autonomous subscriber describes data subscribed by a FunctionalEntity, where the related publishing ConnectionEndpoint(s) are unknown to the logical connection.

Figure 10 – Connection types

Auditing reports problems and changes triggered by an external application. A subscription within a Connection is considered a source of data (for source of data, see OPC 10000-4). Changes in values of Variables from a data source do not generate Audit Events.

This document defines the required data model for logical connection configuration information, represented by the ConnectionConfigurationSetType and additional ObjectTypes it utilizes.

The ConnectionManagerType (see 6.7) exposes configuration information related to the establishment of logical connections. The configuration information may be generated by an engineering tool based on offline or online information.

OfflineEngineering (see OPC 10000-83) offers the concept of Descriptors that describe the AutomationComponents; see Figure 11 label 1. Using these Descriptors or retrieving information online from the AutomationComponents, application engineers use vendor-specific engineering tools to generate the configuration data for logical connections (see Figure 11 label 2). All configuration data represented by one or more logical connections are defined in a ConnectionConfigurationSet. The instances may also include configuration information for the utilized OPC UA communication model (e.g., PubSub or Client Server [future]).

Engineering tool and ConnectionManager could reside on separate devices or be located on the same device.

ConnectionConfigurationSets may be deployed to the ConnectionManager (see Figure 11 label 3) using functionality defined in Annex F or vendor-specific means.

A ConnectionConfigurationSet may allow changes. For example, addressing information that is only available at commissioning time or communication-related properties like the PublishingInterval for data exchange may be modified by a system integrator. What changes can be made can be restricted by the generator of the ConnectionConfigurationSet.

The ConnectionManager exposes the ConnectionConfigurationSets (see 6.86.8), representing sets of logical connections to be established. Using generic tools (Clients), the ConnectionConfigurationSets can be modified as restricted (see Figure 11 label 4).

Figure 11 – Configuration information generation, deployment, and modification

The ConnectionManager provides optional Methods to interact with these sets of logical connections, i.e., for editing and committing updates to sets (see 6.7.4) and to trigger processing (establishment for all logical connections) of sets (see 6.7.5). The ConnectionManager may also provide vendor-specific means.

As introduced in 4.7, logical connection establishment may be executed by a ConnectionManager. If present on a Server, the ConnectionManager is represented in the Information Model by ConnectionManagerType (see 6.7). To start the establishment of logical connections, the ConnectionManager could be triggered by vendor-specific means or by a Client using the ProcessConnectionConfigurationSets Method. It could also be an application that is always executing. The ConnectionManager calls the EstablishConnections Method on the AutomationComponents to establish the logical connections.

For each logical connection to be established, the ConnectionConfigurationSet includes:

• address information, e.g., Server address, BrowsePath to the AutomationComponent, FunctionalEntity, etc.,
• optional parameters to be used for verifying the Assets and FunctionalEntities,
• optional parameters to be used for establishing control,
• optional parameters to be used for configuring the application behaviour,
• the definition of the data to be exchanged via the logical connection,
• communication model-specific properties for the utilized OPC UA communication model (e.g., PubSub or Client Server [future]).

For more details on the ConnectionConfigurationSetType, see 6.8. For details on ConnectionManager functionality, see 6.7.

The ConnectionManager could be triggered to close logical connections by vendor-specific means or by a Client invoking the ProcessConnectionConfigurationSets Method. The ConnectionManager calls the CloseConnections Method on the AutomationComponents to close the logical connections.

A consumer of data can always detect data loss (e.g., caused by loss of network communication or a faulty producer), but in many industrial control applications, it is of interest to the application producing the data whether the consumer(s) of that data are still available. OPC UA FX provides a configurable clean-up of logical connections and all associated resources.

The lifetime of a logical connection on an AutomationComponent may be tied to its Status (see 6.6.2), which is, in turn, tied to the reception of data or heartbeat messages. A configurable CleanupTimeout (see 6.6.2) allows the deletion of all resources allocated to a specific ConnectionEndpoint once its status indicates loss of data reception.

This revision of the specification supports logical connections that utilize the PubSub communication model and hence builds on the usage of either DataSetMessages or heartbeat messages (see OPC 10000-14).

Establishing logical connections may involve creating several Objects within the AutomationComponents.

Persistence refers to the ability of AutomationComponents to store configuration, which allows these Objects to be restored after a power cycle or other restart. Individual logical connections may be marked for persistence (see IsPersistent in 6.6.2).

An AutomationComponent may provide preconfigured Objects (e.g., PublishedDataSet or ConnectionEndpoint). An example might be a FunctionalEntity that includes a preconfigured PublishedDataSet that is used as part of a logical connection. The other parts of the logical connection (e.g., ConnectionEndpoint, WriterGroup, DataSetWriter) are all created during connection establishment. If the Connection is not marked for persistence, the other parts are deleted on clean-up or on a power cycle, and the preconfigured Objects will remain.

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. The grey-blue boxes in these illustrations are defined in this document, while the yellow blocks are defined in OPC 10000-14.

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 – Single Connection using unicast network messages

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.

The PubSub instances are configured to exchange data between AutomationComponents AC_A and AC_B using unicast NetworkMessages.

This use case, illustrated in Figure 13, typically applies to AutomationComponents that host multiple FunctionalEntities and/or nested FunctionalEntities.

Figure 13 – Multiple Connections using unicast network messages (aggregated)

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 is 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).

Figure 14 – Multiple Connections using multicast network messages

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 the Publisher and the 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.