Security Key Managementand
Configuration Managementmodels, which have an only indirect impact on the in-band PubSub Applications interoperability.
NetworkMessagestructure using underlying communication stack. As illustrated in the following domain model (Figure 1), directly or indirectly the specification defines the following actors:
Publisher: pushes the current process data formatted as the
NetworkMessagestructure to an underlying communication stack
Subscriber: consumes the process data, which is recovered from the
NetworkMessagestructures polled from the underlying communication stack
Distribution Channel- selected common underlying communication stack
Security Key Management- a service that provides security keys used to sign and encrypt
Configuration Management- an external application used to remotely configure PubSub Application
Publisheris the actor that pushes
NetworkMessagestructures to an underlying communication stack responsible to transport it over the network. It represents a certain data source, for example, a control device, a manufacturing process, a weather station or a stock exchange. It may be also OPC UA Client, OPC UA Server or in general any application that understand the syntax and semantics of the
Subscriberactors are the consumers of
NetworkMessagestructures, which are polled from the underlying transport layer. They may be OPC UA Client, OPC UA Server or in general any applications that understand the syntax and semantics of the
Publisherand all associated
Subscribersnodes depend on a common
Distribution Channelmodels common knowledge necessary to use an underlying messages transport communication stack, i.e. underlying protocol stack and relevant parameters to route the messages over the network.
Security Key Managementprovides keys for message security that can be used by the
Publisherto sign and encrypt
NetworkMessagestructures and by the
Subscriberto verify the signature of and decrypt the
NetworkMessagesecurity concerns the integrity and confidentiality of the published message payload. The level of security can be:
Subscriberinstances) and requires common knowledge of the cryptographic artifacts necessary to sign and encrypt on the
Publisherside as well as validate the signature and decrypt on the
Subscriberside. The message security is independent of the transport protocol mapping and is defined by the specification.
Security Key Managementservices and many possible scenarios that can be used to select the security profile and provide appropriate security artifacts to the
Subscriberusing this model. One of them is to implement this model as the OPC UA Server or OPC UA Client where the OPC UA IM model is used to describe the server OPC UA Address Space. A detailed description of all possible scenarios applicable to select security profile and exchange security artifacts is outside of the scope of this section.
Subscribernodes may be configurable through vendor-specific engineering tools or using the dedicated configuration OPC UA Information Model described in this standard. This model allows a standard OPC UA Client based configuration tool to configure a PubSub Application connecting to the embedded OPC UA Server. Using remote Configuration Tool over an OPC UA Session does not determine how dynamic the configuration can be. More detailed description of this model is outside of the scope of this section.
NetworkMessagemust be populated using external process data.
Subscribercan be obtained. For UDP multicast messages distribution may be applied to send
Internet Protocol (IP)(figure below) datagrams to a group of interested receivers in a single transmission. For the broker-based transport, all messages are published to specific queues (e.g. topics, nodes) that the broker exposes and
Subscriberscan listen to these queues.
NetworkMessagesas payload of the Ethernet II frame without IP or UDP headers
OPC UA UDPand
OPC UA Ethernetin section References they are inferred from the context. Based on this mapping in the figure below the architecture of protocol stack is determined as the domain diagram. The diagram has been worked out on the best effort approach.
OSI Network, and
OSI Data Link) may aggregate and use a variety of protocols depending on the local network infrastructure, e.g. IEEE 802.11 for
OSI Data Link Layer.
AMQP. They may be recognized as the underlying API of the protocol stack and are aggregated into one common communication layer used to exchange the messages over the network (section Semantic-Data Message Centric Communication ).
transport protocolhas nothing in common with the Open System Interconnection Reference Model (OSI model) Transport Layer. Referring to the OSI model the
AMQPprotocols should be recognized as the
OSI Application Layerprotocols. The
OSI Application Layeris the one at the top of the model. For the sake of simplicity, the
OSI Application Layeris not present in the diagram. Because the PubSub specification defines also the protocol on the same layer some functionality is redundant in this case - they overlap on each other. For the purpose of traversing the network by the messages, the PubSub Application uses
AMQPprotocols as a transparent communication service. Applying the broker-based approach also means that some functionality related to communication reliability, data selection, and distribution is delegated to them. Details related to
MQTTmapping are covered by the section Underlying Transport over MQTT. Details related to
AMQPmapping are covered by the section Underlying Transport over AMQP.
OSI Presentation Layerrepresents the services that are responsible for the translation of the application data encoding to network encoding, and translation back from the network encoding to application encoding. In other words, the layer “presents” data for the application or the network. This functionality (encoding/decoding) is embedded in the definition of the PubSub message syntax rules. This syntax rules (OPC UA Part 6) are common for all the OPC UA specifications suite. For the sake of simplicity, the
OSI Presentation Layeris not present in the diagram.
OSI Session Layeris empty, so it is ignored in the domain model presented in figure above.
MQTT, so an abstract
OSI Transport Layeris used in the proposed model as the underlying communication layer for them. In this case, all requirements against relevant specifications apply.
User Datagram Protocol (UDP)protocol (UDP) is pointed out by the PubSub specification as the only concrete implementation of the
OSI Transport Layer. In this case, the protocol can be recognized as the base for the
UDPmapping rules stated by the specification and a not sharable part of the abstract
OSI Transport Layer.
Internet Protocol (IP)multicast option to fulfill this requirement. Formally there are no additional mapping rules defined for this protocol, but as a result, this concrete protocol has been selected as the base for
User Datagram Protocol (UDP)protocol and is an embedded part of the
OSI Network Layer.
UDPmapping, special equipment and dedicated configuration of that equipment are required. Both make this solution applicable only for the local network segments in the administration realm of the protocol users. It is hard to imagine the usage of this communication option even in case of enterprise scoped networks. From the practice, we know that particularly with factory networks, the manufacturing/engineering and IT organizations of the same company don't agree upon the management boundaries in a single plant. On the other hand, a broker-less PubSub
UDPmapping using unicast addressing is a highly specialized case where the
Publisheris intimately coupled to the
UDPmapping rules are covered by the section Underlying Transport over UDP.
Ethernetmapping rules have been defined (see figure above). The Ethernet term is recognized as a keyword with a very broad meaning (IEEE 802.3 ETHERNET WORKING GROUP). The specification doesn't define normative reference in this respect. In the figure above it is presented as a concrete implementation compliant with the
IEEE 802.3standard suit. In case the UDP protocol is removed form the stack to replace the application selection functionality offered by the socket concept the registered B62C EtherType is recommended, which is used as the protocol discrimination. Removing IP from the communication stack means that the addressing possibility is limited to local network segment. Detailed description of the
Ethernetmapping rules are covered by the section Underlying Transport over Ethernet.
OSI Data Link Layer. In any case, these solutions are invisible for the implementation of the communication layers above
OSI Data Link Layer, so they are invisible for upper layers and doesn't have any impact on the PubSub interoperability, therefore should be considered as statements outside the scope of the specification. It is also worth stressing that these solutions can be applied in spite of the above communication stack selection - it is the common point in the transport protocol stack for all mappings. In other words, the mentioned solutions are not dedicated to OPC UA at all and can be applied for any communication protocol.
NetworkMessagedata structure. Each
NetworkMessageincludes header information (e.g. identification and security data) and one or more
DataSetMessagemay be signed and encrypted in accordance with the configured message security. Each
DataSetMessagecontains process data.
NetworkMessagestructure can be serialized using the following encoding:
UAOOI.Networking.SemanticDatalibrary is designed to be a foundation of developing application programs that are taking part of message-centric communication pattern and interconnected using the reactive networking concept described in the section Semantic-Data Processing Architecture. To promote interoperability this library is a collection of types aimed at implementation of the Part 14 PubSub standard.
OOI Reactive Applicationnetwork-based data exchange programming experience. Working through this tutorial gives you an introductory understanding of the steps required to customize existing
OOI Reactive Application.
ReferenceApplicationcovers the description of a project aimed at implementation of an example of the
OOI Reactive Applicationsupporting producer and consumer roles simultaneously implemented as independent concurrent threads. The purpose of the
ReferenceApplicationis to demonstrate the concepts and architecture of the reactive networking application implementation, rather than to necessarily provide a realistic scenario for its use. For more extensive examples, see the Semantic-Data Processing Architecture.