Basics of OPC UA

OPC Unified Access (OPC UA) is a machine to machine communication protocol developed and maintained by the OPC Foundation. OPC UA has an information model that allows the transmission of data across devices of different vendors.

This chapter gives an introduction to OPC UA.

OPC UA Services

OPC UA is based on a Client-Server-Model. A server provides process data, historical data, alarms and events. A client can request these data elements and subscribe for event notifications. Both client and server communicate with services defined by the OPC UA standard. These services are grouped in Service Sets.

Some services are optional. The profile implemented by a server defines if a service is supported or not.

Discovery Service Set

These services help a client to discover available servers in a network. Furthermore they are used to obtain information about the required security methods for accessing servers. There are also dedicated Discovery Servers.

SecureChannel Service Set

These services are used to manage a secure session between a client and a server.  These connections are used to ensure the confidentiality and integrity of the messages between the two endpoints.

Session Service Set

These services manage sessions established between clients and a server. A session is a logical connection on the application layer.

NodeManagement Service Set

The services of this set are used to create and delete nodes in the address space of a server. There are also services to add and remove references to these nodes. 

View Service Set

These services are used by clients to navigate through the address space of a server. A server can also have views that allow a client to only browse a subset of the address space. 

Query Service Set

These services are used to query large data from a server. 

Method Service Set

The client can invoke methods of objects within the server with these services. After a method has finished execution the result is returned to the client. 

MonitoredItem Service Set

These services manage MonitoredItems of a server. A MonitoredItem defines which node attribute must be monitored, its sampling interval, whether a new sample is sent to the client and if filters must be applied to the sample. 

Subscription Service Set

These services are used to manage subscriptions. Subscriptions have the server publish notifications created by MonitoredItems to the client.

Address Space 

An OPC UA server has an Address Space that contains all objects that represent and influence the device and its automated processes. An object consists of variables and methods. A variable represents a state of an automated process. A client can use a method of an object to execute a functionality of a server.

Node Classes

In order to expose the Address space of a server to any client a description language is needed. OPC UA organizes the Address Space by nodes. An object is made up of several nodes. Each node consists of attributes and references to other nodes. The standard defines node classes that describe a node in terms of attributes and references. A server is not allowed to extend these node classes or to define its own ones.  

The following table lists the Node Classes defined by the OPC UA Standard:

References

References are used to connect nodes of the Address Space. There are several standard types of references. Furthermore a server may define its own references with ReferenceType nodes. The standard defines several types of references that differ in their semantics. Some ReferenceTypes are abstract supertypes of others, i.e. they cannot be used by a node. The following table provides a description of ReferenceTypes defined by the OPC UA standard:

Standard Entry Points

The OPC UA standard defines a certain number of FolderType objects that must be implemented by all servers. Thus a client has well-known entry points for browsing the Address Space of a server. These entry points are shown in the following Figure

Open

Mandatory FolderType objects of an OPC UA Server

Root

This is the standard entry point of the Address Space and references all other entry points.

Views

This object organizes all View nodes of the Address Space. It might also reference object nodes that reference a View node.

Objects

The FolderType object “Objects” organizes all Object nodes.

Types

This node organizes all other entry points of type nodes.

Reference Types

This is the entry point for all ReferenceType nodes. It might also reference other objects that reference a ReferenceType node.

Object Types

This FolderType node organizes all ObjectType nodes. Well-known ObjectTypes might not be included in this hierarchy. This object also contains all the EventTypes supported by the server.

Variable Types

This node organizes all VariableType nodes of a server. The server might not expose well-known VariableTypes in this FolderType node.

Data Types

This FolderType organizes all DataType nodes the server wants to expose to clients. It might reference the DataTypeSystem objects supported by the server. Standard DataTypeSystem nodes are “OPC Binary” and “XML Schema”. These objects describe the supported encodings of data.

The FolderType object “Objects” references the object “Server”. This standard object exposes information about the server. It also contains Diagnostic information for established sessions and subscriptions to the server.  Furthermore this object is the root notifier. A client subscribing to this object will receive all events generated by the server. 

Events

OPC UA defines a set of Event types that can be implemented by objects and views. The MonitoredItem service set and the Subscription service set are used by a client to subscribe to the event notifications of a server. 

EventTypes supported by a server are exposed as ObjectTypes in the Address Space. A server may have subtypes of EventTypes. These subtypes do not expand the functionality but allow to group events in more precise categories. The EventTypes defined by the OPC UA specification are described in the following Table:

Security Model 

The OPC UA specification defines several security objectives. These objectives can only be applied to the OPC UA component of a system. Other components must also be protected by other means.

 A server can support multiple Security Policies. These policies are defined in Security Profiles. The Policies determine the algorithms for encryption, signing and key derivation. A server is allowed to use different Security Policies for each client.

Authentication

Entities, i.e. clients, servers or users, must prove their identity. In order to authenticate a user the client uses the OpenSecureChannel to send a UserIdentityToken to the server. The UserIdentityToken is either a username & password, a X509v3 certificate or a WS-SecurityToken.

Furthermore OPC UA clients and servers can use X509 certificates to identify each other.

Authorization

Only entities that need the respective access rights should be able to read, write or execute resources.  OPC UA only specifies the user authentication. The authorization management is implementation specific.

Confidentiality

Data must not be accessed from unknown or unauthorized entities. Data can be transmitted or reside in volatile and non-volatile memory. This requires encryption algorithms that use a secret that can only be accessed by authenticated and authorized entities. OPC UA uses asymmetric encryption to agree on the key for symmetric encryption of messages.

Integrity

Data received from a sender must not be changed during transmission. OPC UA uses Asymmetric Signatures during Channel establishment. Other messages are signed with symmetric signatures.

Auditability

Actions executed by an entity must be recorded to provide evidence to a stakeholder. This includes:

• Tracking of successful actions (system works as intended)

• Tracking of user actions (who initiated what action)

• Tracking of unsuccessful actions (possible attempts to compromise the system)

The client creates an audit log message of its request in combination with a Log ID. This ID is also transmitted with the request. The server creates an audit log of the received request and the client’s ID. Thus the audit logs are connected across multiple machines. OPC UA defines audit parameters for consistent audit logs and audit events. With these events audit logs can be collected by a tracking system from multiple devices. 

Availability

The system is not turned off and has sufficient resources to handle requests. A system can be attacked by message flooding or by exceeding its resources. OPC UA servers only process most kind of messages after the client has been authenticated. Thus the processing is kept to a minimum. There are two services that can also be used by unauthenticated clients: GetEndpoints and OpenSecureChannel. While the former only requires a static response, the latter can consume server resources as it includes signature processing and encryption. The server could protect itself by delaying the processing of requests or blocking it entirely once a threshold has been reached. 

OPC UA Mappings 

The OPC UA specification defines several mappings that allow the implementation of OPC UA with different technologies. The mappings include Data Encodings, Security Protocols and Transport Protocols. Mappings of these three groups are combined to Stack Profiles. Clients and servers must implement at least one Stack Profile and can only communicate with other endpoints that implemented the same Stack Profiles. 

Data Encodings 

Data Encodings describe how to build messages. OPC UA defines a set of built-in types that can be used to construct structures, arrays and messages. 

OPC UA Binary

This encoding allows a fast encoding and decoding of data. It also provides an efficient transport of data. Each element is encoded into a byte stream. Also it is assumed that both sender and receiver have knowledge about the structure of a message. Thus only the values are transmitted. 

OPC UA XML

If this encoding is selected, data is represented as XML strings. This representation of data is readable for humans and compatible to other exchange formats used by web services or other software. However this encoding is less efficient as it requires more bytes to convey information. This encoding contains meta information like XML tags and attributes. Furthermore values are represented as strings, i.e. one byte is represented by two character bytes. 

OPC UA JSON

This encoding provides data in another popular exchange format that is used by web and enterprise software. This encoding has less overhead than OPC UA XML but is still not efficient as OPC UA Binary. It only uses field names and small delimiter like brackets or colons. But values are still represented as strings. 

Transport Protocols 

The Transport Protocol is responsible for conveying messages from client to server and vice versa. For binary encoded data OPC UA defines an encapsulation protocol that is used in combination with the actual transport protocol. 

OPC UA Connection Protocol

This protocol is encapsulated by the actual transport protocol. It is responsible for establishing a full duplex channel between two endpoints. It is used to negotiate the maximum size of sent and received frames.  It is also responsible for creating a SecureSession that is used for further communication. The OPC UA Connection Protocol also contains the OPC UA Secure Conversation that allows to split OPC UA messages into chunks and to encrypt messages. 

OPC UA TCP

OPC UA can be sent over TCP using the OPC UA Connection Protocol on port 4840. 

OPC UA HTTPS

The HTTPS transport protocol uses HTTP and TLS. It is also possible to use HTTP without TLS. 

WebSockets

WebSocket are established via HTTP(S) and use the respective TCP ports for data exchange. The WebSocket protocol uses a binary header for data framing. Like OPC UA TCP the OPC UA Connection Protocol is used to encapsulate OPC UA messages. 

Security Protocols 

Security Protocols are responsible for managing a SecureChannel between a client and a server. They implement the OpenSecureChannel and CloseSecureChannel services and apply the negotiated security methods to the messages sent over this channel.

There are three security modes: None, SignOnly, and SignAndEncrypt. This means that a SecureChannel does not have to be secure. 

For the OpenSecureChannel request and response messages an asymmetric algorithm is used for signing and encryption. All other messages use a symmetric algorithm for signing and encryption. The exact algorithms to be used and their parameters are specified in SecurityPolicies. A server can support multiple SecurityPolicies. The client requests the SecurityPolicy that should be used. 

Application Certificates

Both the client and the server have certificates based on the X.509 v3 standard in the DER format. Certificates are exchanged via the OpenSecureChannel service. They contain the public keys. If a certificate is signed by a Certification Authority (CA) the signature must be validated, i.e. the CA’s certificate must be available. The end user is responsible for determining which CAs can be trusted. Also expiration dates must be checked. This requires time synchronization. The OPC UA device can either support the Network Time Protocol (NTP) or it can synchronize via the FindServers response from a Discovery Server. 

UserIdentityTokens

The ActivateSession service can be used by a client to authenticate itself as a certain user by issuing a UserIdentificationToken. The following tokens are supported by OPC UA: 

An IssuedIdentityToken can have one of the following formats:

• Kerberos WS-Security token

• JSON Web Token (JWT)

• OAuth2 Access Token 

OPC UA Secure Conversations

This implementation of a Security Protocol handles the encryption and signing of messages in a binary format. It is compatible with the OPC UA Connection Protocol. An OPC UA message can be split into message chunks. The security mechanisms are applied to each chunk and not the whole message.

Each chunk has a message header that indicates the message type and if it is the final chunk.

The security header contains information about the cryptographic operations performed on the chunk. The sequence header contains indicates the sequence of chunks of a message. The actual payload is encoded as OPC UA Binary. The message footer contains padding that depends on the block size used for encryption and the signature. 

The OPC UA Secure Conversations Security Protocol can only be used for binary encoded data. If the transport protocol also supports encryption (e.g. WebSockets) the encryption is applied additionally.

Other Encodings (e.g. XML or JSON) or transport protocols (e.g. HTTPS) do not support the OPC UA Connection Protocol and OPC UA Secure Conversations. They must rely on the encryption provided by the transport protocol. 

Profiles 

The OPC UA specification defines several features for clients and servers. These features are grouped into ConformanceUnits. Multiple ConformanceUnits make up a Profile. Profiles can also contain other Profiles, i.e. the Profile extends the included Profile. An OPC UA client or server usually supports more than one Profile. All Profiles belong to at least one of the categories shown in the table below. 

MonitoredItems and Subscriptions 

A MonitoredItem defines how a node attribute or a node event is monitored. It is connected to a Subscription to send notifications to a subscriber.

A MinitoredItem is defined by 4 parameters:

• Sampling interval

  • interval between two updates of the monitored item

• Monitoring mode

  • DISABLED: no sampling of item

  • SAMPLING: item is sampled, notifications are queued

  • REPORTING: item is sampled, notifications are queued and reported

• Filter

  • Defines criterias for generating notifications

  • DataChangeFilter: create notification if attribute value and/or its status changes

  • EventFIlter: define event fields that are part of a notification

  • AggregateFilter: define aggregate functions that should be applied to values

• Queue Parameter

  • Size of queue for notifications

  • Discard oldest or newest entry in case of overflow

The queued notifications of a monitoredItem can be assigned to a subscription. A subscription can have multiple monitoredItems. It is used to report the notifications to a client.

A subscription as a publishing interval at which a notification message with queued notifications is sent to the client. The client sends a Publish request each publishing cycle. The request is queued and answered each publish cycle. If there is no queued request but there is a notification the next Publish request will be answered immediately. If a subscription has no notifications for a defined number of consecutive publish intervals a keep-alive message is sent. This message is a Publish response without a notification. It also requires a queued Publish request. If publishing for all monitoredItems of a subscription is disabled keep-alive messages are still sent.

If a  consecutive number of publishing intervals with no available Publish request exceeds a limit the subscription is closed and its monitoredItems are closed. A StatuschangeNotification message is sent. 

OPC UA PubSub 

OPC UA PubSub applies the OPC UA Application Layer to a Publisher and Subscriber communication model. Publishers send data and Subscribers receive data. They do not have to know about each other. However they have to agree on the semantics of the published data.

OPC UA PubSub messages rely on a Message Oriented Middleware. There are multiple transport protocols and encodings for PubSub messages. Depending on the transport protocol the middleware is either an entity in the network or the network itself. 

DataSet 

A DataSet is a collection of Events or Variable Values. Each Variable or Event is a DataSet field.

There is also a DataSetClass that can be used as template to create DataSets. 

The DataSetMetaData  describes the content and semantics of a DataSet. It defines a name and version of the DataSet. Also it defines a name and a data type for each DataSet field. It may also define properties for a DataSet field, e.g. an engineering unit. 

Publisher 

The Publisher sends NetworkMesages to the Middleware.

The Publisher collects all Variables or Events for the fields of PulishedDataSet. The DataWriter creates a DataSetMessage from a DataSet. The DataSetWriter has several parameters that control the creation of a DataSetMessage. 

• DataSetFieldContentMask (which attributes of a value shall be included)

  • e.g. status code or timestamp

• DataSetMessageContentMask (which header fields shall be included)

  • e.g status code, timestamp, configuration version of the DataSet,…

• KeyFrameCount (number of intervals until a key frame message must be sent

  • Key frame message contains all DataSet fields

  • Delta frame message only contains DataSet fields of changed values 

Each DataSet has its own DataSetWriter, so for each DataSet an individual DataSetMessage can be created. 

One or more DataSetWriters can belong to a WriterGroup. The WriterGroup creates a NetworkMessage that contains all DataSetMessages from the DataSetWriters pf the WriterGroup.

Each WriterGroup has a WriterGroupId that is unique for each publisher. It can be used by a Subscriber or filtering. The PublishingInterval defines the interval between two NetworkMessages in milliseconds. 

The WriterGroup is also responsible for signing and/or encrypting the NetworkMessages. 

The NetworkMessage is encapsulated by the configured transport protocol and sent to the Middleware. 

Subscriber 

Subscribers consume NetworkMessages received from the Message Oriented Middleware. It might be necessary to establish a connection to the Middleware. 

The Subscriber can filter NetworkMessages by PublisherId, DataSetWriterId or DataSetClassId. If the message passed the filter, its payload might need to be decrypted and the signature might need to be verified.

Each DataSetMessage within a NetworkMessage is passed to a matching DataSetReader. The DataSetReader uses the DataSetMetaData to decode the DataSetMessages. The DataSetMetaData’s version must match the version in the DataSetMessage. 

The Subscriber might dispatch all fields of SubscribedDataSets to the applicable nodes in its AddressSpace. 

Security Key Service (SKS) 

PubSub messages can be encrypted and signed. Therefore Publisher and Subscriber have to agree on an algorithm and a key pair. 

Each set of keys has its own SecurityGroupId. This ID must be set in the Publisher and Subscriber. The SKS can be implemented by a Publisher or a separate entity. Both cases they must provide the PublishSubscribe Object and the GetSecurityKeys Method in their AddressSpace. 

The SetSecurityKeys Method can be used by a SKS to push the keys to a Publisher or Subscriber that has no OPC UA client functionality and cannot invoke the GetSecurityKeys Method. This requires the Publisher and Subscriber to implement OPC UA Server Functionality and provide the method of the PublishSubscribe object in their AddressSpace. 

The SKS must be able to use the OPC UA User Authorization to determine if a Publisher or Subscriper is allowed to access the keys of a security group. 

Message Oriented Middleware 

There are two types of message oriented Middlewares that are used for different transport protocol mappings. 

There is a Broker-less Middlewares where the Network messages are sent to and received from the network directly. The addressing methods must ensure that all messages are sent to all nodes in the network. 

On the other hand there are Broker-based Middlewares where a Broker exists. All participants communicate with the broker. The Publisher sends messages to the Broker that are assigned to a specific criteria, e.g. a topic or queue. The Broker sends messages to all Subscribers that subscribed to such criteria. 

Encoding 

OPC UA PubSub defines two encodings for the NetworkMessages and DataSetMessages.

UADP Message Mapping

This encoding uses a binary format. It also applies message security. It defines the fields for the NetworkMessage header a Group Header and a Security Header and a signature. The UADP Message Mapping also defines the encoding of DataSetMessages. 

JSON Message Mapping

This encoding uses the JSON format where data is encoded a human readable text. It defines the fields for the NetworkMessages and DataSetMessages. 

Transport Protocol Mappings 

OPC UA PubSub defines transport protocols for NetworkMessages. Depending on the selected transport protocol either a broker-less or broker-based Middleware is required. 

OPC UA UDP

This transport protocol mapping uses UDP datagrams to transport UADP encoded NetworkMessages. This mapping is selected by the URL “opc.udp://<host>[:<port>]”.

The field <host> is either the hostname, domain name or an IP Address (Unicast, Multicast, Broadcast). It will be used as the destination of the UDP datagram. Optionally a UDP destination port can be defined. The default port is 4840. 

OPC UA Ethernet

This transport protocol mapping uses Ethernet Frames with the EtherType 0xB62C to transport UADP encoded NetworkMessages. This mapping is selected by the URL “opc.eth://<host>[:<VID>[.PCP]]”. The field <host> is a MAC Address as a group of six hexadecimal digits separated by hyphens (e.g. 12-34-56-78-9a-bc). Optionally <host> could be an IP address or a hostname if the platform can resolve it to a MAC address. Optionally a VLAN ID and a PCP Value can be specified. 

AMQP

The Advanced Message Queuing Protocol is an application layer protocol that uses a Broker to relay messages between different entities. AMQP uses a binary protocol for transportation. The NetworkMessages can be encoded as UADP messages or JSON messages. Additionally to the encryption of the UADP encoding TLS can be used for the transport protocol. However this is no end-to-end encryption. The Broker must be trusted. This mapping can be selected by the URL “amqps://<domain name>[:<port>][/<path>]”. The default port is 6671. Alternatively, Web Sockets can be used: “wss://<domain name>[:<port>][/path]”. The default port is 443. 

MQTT

The Message Queue Telemetry Transport is an application layer protocol that uses a Broker to relay messages between different entities. MQTT uses a binary protocol for transportation. The NetworkMessages can be encoded as UADP messages or JSON messages. Additionally to the encryption of the UADP encoding TLS can be used for the transport protocol. However this is no end-to-end encryption. The Broker must be trusted. This mapping can be selected by the URL “mqtts://<domain name>[:<port>][/<path>]”. The default port is 8883. Alternatively, Web Sockets can be used: “wss://<domain name>[:<port>][/path]”. The default port is 443. 

Configuration of Publishers and Subscribers 

Since Publishers and Subscribers do not establish a session with each other they must be configured by a managing instance. The PubSub Information model defines well-known objects in the Address Space of a Publisher or Subscriber that can be used to configure the PubSub connection. Alternatively, vendor specific configuration means can be used. 

The entry point is the PublishSubscribe instance of a PublishSubscribeType that is a component of the Server Object. It manages a list of PubSubConnectionType Objects and the PublishedDataSetType Objects through the PublishedDataSets folder. 

Objects of thePublishedDataSetType represent published DataSets. Objects of the DataSetWriter Type contain settings for creating DataSetMessages. 

A DataSetReaderType objects contains settings for receiving DataSetMessages. Objects of the SubscribedDataSetsType provide information on how to parse received DataSets. There are aslos Subtypes of these objects that contain specific settings for encodings and transport protocol mappings. 

The objects provide methods for managing the PubSub settings. 

An entity that implements a Security Key Service also has an object of the PubSubKeyServiceType. This object provides methods for managing SecurityGroups. They are organized by the SecurityGroupFolderType that contains SecurityGroupType objects. 

Profiles 

Profiles define what kind of mappings and security parameters are supported by a device. 

Currently there is no profile for a OPC UA PubSub device.