Posted on

OPC UA Concepts and Implementation

OPC UA is a platform-neutral standard that allows systems and devices to communicate and exchange messages over multiple types of networks. It defines a set of services that servers would implement and clients request. The services are based on an authenticated session and a secure channel. Three transport protocols are defined: OPC UA TCP, SOAP/HTTP, and HTTPS as well as a couple of data encoding: UA Binary and XML/Text. In the rest of the posts, only OPC UA TCP and UA Binary are discussed.

The OPC UA specification is quite large and is included in more than a dozen documents. In this post, we will only present the fundamental concepts.

Definitions

  • A node is the fundamental component of an address space
  • A NodeId is the unique identifier of a node
  • Each node belongs to a class.
  • Classes inherit from the base node class
  • The standard node classes are defined as: Object, Variable, Method, ObjectType, VariableType, ReferenceType, DataType and View
  • Each node has a set of attributes which depend on the class of the node
  • The base node class has the following attributes: NodeId, NodeClass, BrowseName, DisplayName, Description
  • In addition to the base class attributes, classes will have their specific attributes.
  • The variable node class has also the value, data type, value rank, array dimensions, access levels, minimum sampling interval and historizing as attributes
  • An endpoint is the set of URL, security algorithms and parameters used to connect to the server

Open Secure Channel

The connection starts with the creation of a secure channel. The client establishes a TCP connection with the server then sends a ‘Hello Message’. The server replies with an ‘Acknowledge’  (or an ‘Error’) message. During this initial handshake, information such as the maximum number of message chunks, the maximum response size, and the size of send and receive buffers are exchanged between the client and the server. The next step for the client is to send the ‘Open Secure Channel’ message which includes:

  • A certificate identifying the client unless the security mode is set to None in which case this parameter is ignored
  • The request type stating whether the secure channel should be created or renewed
  • An identifier when renewing the secure channel, otherwise left to null.
  • The security mode of the secure channel which indicates whether messages should be signed and/or encrypted
  • A random byte string called client nonce used by the client and server to generate the symmetric keys. The keys are used to encrypt messages.
  • The secure channel lifetime requested by the client. The lifetime is the amount of time that the client and server should wait before renewing the channel.

If everything goes well and the server accepts to open a secure channel, the response includes:

  • A random byte string called server nonce used by the client and server to generate the symmetric keys. The keys are used to encrypt messages.
  • A security token that includes:
    • A unique identifier for the secure channel
    • A token identifier which should be passed with each message and updated  when the secure channel is renewed
    • The time when the security token was created
    • The revised secure channel lifetime

Find Servers and Get EndPoints

After establishing a secure channel, the client will typically request the list of servers known to the (discovery) server using the ‘Find Servers” service. The client can then select one of the servers returned to request the list of endpoints using the ‘Get EndPoints’ service. An endpoint includes, among other things, the following information:

  • The endpoint URL
  • The server certificate associated with the endpoint
  • The endpoint security mode stating whether the messages must be signed, signed and encrypted, or none
  • The security policy URI that defines the security profile and mode. The security profile defines the security algorithm and parameters such as key lengths.

Create and Activate Session

Before using the rest of the services, the client must create a session. When creating a session, the client provides, among other things, the session name, a random byte string, and the client certificate. The server replies, among other things, with a unique session nodeId, an authentication token (used in request headers to identify the session), a random byte string, the server certificate, and the ‘server signature’. The server signature is calculated by appending the client nonce and certificate then signing it with the server’s private key. The client uses the server certificate to verify the server’s signature.

Once the session created, it needs to be activated. To activate the session, the client sends, among other things, a ‘client signature’ and the user credentials when required. The server replies with a ‘server nonce’, which is a random number, of at least 32 bytes, that the client can use to prove possession of its certificate in the next call of ‘Activate Session’.

Browsing the address space

The client can use the ‘Browse’ and ‘Browse Next’ services to navigate the server’s address space. The result of the ‘Browse’ service is a list of nodes based on the parameters passed in the request. The ‘Browse Next’ is used when the result is too large to be passed in one single ‘Browse’ request.

Subscriptions

Subscriptions are used to report notifications to the client. They serve as logical containers for monitored items. When sending the ‘Create Subscription’ request, the client includes:

  • The requested publishing interval. The publishing interval determines how often the server should be sending notifications to the client.
  • The requested lifetime. The subscription lifetime is the maximum amount of time without receiving a ‘Publish’ request from the client, after which the server should delete the subscription.
  • The maximum keep alive count. The keep-alive is the number of publishing intervals without sending notifications to the client, after which the server must send a keep-alive message to keep the subscription alive.
  • The maximum number of notifications per ‘Publish’ response.
  • The subscription ‘enable’ state. If set to false, the subscription is created disabled.

The server replies with the subscription identifier, revised values for the publishing interval, the lifetime, and the maximum keep alive count.

For the subscription to stay alive, the client must keep sending ‘Publish’ messages.

Monitoring Data

For the client to receive data change notifications, it must add ‘Monitored Items’ to the subscription. When creating monitored items, the client includes, among others, the nodeId, the attribute to monitor, the requested sampling interval, and the sampling mode (reporting, sampling, or disabled). Once the monitored items created, the client must keep sending ‘Publish’ messages to the subscription to receive change notifications in the ‘Publish Response’.

Attributes Services

This set of attributes can be used to read and write current and historical data.

  • Read  is used to read one or more Attributes of one or more nodes
  • Write is used to write values to one or more Attributes of one or more nodes
  • ‘History Read’  is used to read historical values or events of one or more nodes
  • ‘History Update’ is used to update historical values or events of one or more nodes
Posted on

Industrial Internet of Things (IIoT) Protocols

The Industrial Internet of Things (IIoT) involves an intensive data exchange and a certain level of interoperability between different kind of devices. The data can be collected locally or sent to cloud-based applications in order to be aggregated, stored, and analyzed. Due to the heterogeneous nature of the environment, some communication standards need to be established in order to facilitate the integration of hundreds, if not thousands of devices. Some protocols have emerged as candidates for the IIoT standard. In this post, we present an overview of three open standards: OPC UA, MQTT and HTTP/REST

The OPC standard has been around for more than a couple of decades and proved to be a good solution to some of the integration issues that are encountered in the industrial sphere. Before the OPC era, industrial applications such as SCADA clients and archiving solutions had to carry their own native drivers in order to communicate with devices made by different vendors. The goal of the OPC standard was to allow a common access to the data as well as widening the spectrum of data sources that industrial applications can connect to

Early versions of the standard, also known as OPC classic, were based on a Microsoft technology called DCOM following a client/server pattern.  The client such as an HMI/SCADA connects to the OPC server through a predetermined DCOM mechanism then queries the interfaces to interact with the server

OPC clients use the interfaces acquired from the server to browse the address space, read, write and subscribe for data change notifications

While OPC classic is dependent on a Microsoft technology and hence on the Windows platform, the new version, called OPC UA (Unified Architecture), is platform-neutral which opens the door for embedded implementations of the protocol. In addition, OPC UA puts a strong emphasis on security and information modeling

Before exchanging OPC UA services, the server and client must establish a secure channel based on exchanging certificates, messages signature and/or encryption. In addition, a user authentication is often required when opening a session

MQTT is a client/server publish/subscribe transport protocol. It is lightweight and designed to have a small code footprint and limited network bandwidth consumption, which makes it ideal for IoT applications. By default, it runs over TCP/IP or other protocols that can guarantee ordered, lossless, and bidirectional connections

  • Through a broker, the publish/subscribe pattern provides one-to-many dispatching and decoupling mechanism
  • The messaging transport is unrelated to the application specific payload content
  • Clients send messages to the broker in order to either subscribe for or publish data
  • Information is organized in topics and clients can subscribe to specific topics and receive the data once published

After the initial connection handshake, client 1 subscribes to topics of interest. When client 2 publishes data, the broker publishes to all clients that subscribed to the topics

HTTP is a client/server application protocol that was initially developed for the world wide web to transfer hypertext documents. The industry has been using HTTP for applications and devices remote configuration but rarely for data exchange

HTTP/REST uses the GET, POST, PUT, DELETE (CRUD) well-defined HTTP methods to access data as resources, similarly to how a web browser would exchange files, forms data,…etc with a web server. The data format is typically either text, XML or JSON. Due to its overhead, HTTP/REST can be used to read records of data every hour but hardly every 100ms.

Client requests data (e.g. temperature) using an HTTP GET command, the response received from the HTTP server is typically some JSON object.

Finally, the figure below shows a possible deployment case of the three protocols

Possible deployment case: A PLC has generally the resources to implement the OPC UA services while sensors and actuators might use a lightweight protocol such as MQTT. Mobile devices can use HTTP/REST to access information.