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

OPC Classic Concepts and Implementation

Before the OPC era, industrial applications had to carry the burden of maintaining their own communication drivers. The OPC standard provided a common method for accessing data. Consequently, OPC client applications can access all sorts of devices such as PLC, DCS, RTU…etc, using the same interfaces.

OPC classic is based on a Microsoft interprocess communications standard called COM. A COM component is identified by a CLSID or its user-friendly version called ProgID. COM components expose their services through interfaces that users can query then use to interact with the components. The interfaces are defined using the IDL language.

OPC Classic is a set of specifications, each one defines a set of COM interfaces. For example, Data Access Specification defines interfaces to access real-time data.

In order for an OPC client to connect to a server, it needs the server’s ProgID and hostname. Once connected, the client queries the interfaces from the server as shown in the code snippet below:

// retrieve CLSID from user friendly ProgID
Type opcServerType = Type.GetTypeFromProgID(progId, machine, false);
if (opcServerType != null)
{
  // connect to OPC server using CLSID
  opcServerObject = Activator.CreateInstance(opcServerType);
  // query IOPCServer interface using a simple cast
  opcServer = opcServerObject as IOPCServer;
  if (opcServer != null)
  {
     opcCommon = opcServerObject as IOPCCommon;
     opcBrowse = opcServer as IOPCBrowseServerAddressSpace;
     opcItemProperties = opcServer as IOPCItemProperties;
     opcConnectionPointContainer = opcServerObject as IConnectionPointContainer;
     // ...
     // do something useful with the interfaces
     // ...
  }
}

OPC Interfaces

The list below shows the main responsibilities of the most important OPC DA interfaces:

  • IOPCServer is used by a client to add/remove groups and retrieve the server status information
  • IOPCBrowseServerAddressSpace is used by a client to browse the server’s address space and provide the user with a graphical representation of the address space hierarchy
  • IOPCItemProperties retrieves item properties
  • IOPCItemMgt adds, validates and removes items
  • IOPCSyncIO allows the client to perform synchronous read and write requests
  • IOPCAsyncIO2 same as above except that the requests are non-blocking
  • IOPCDataCallback is a client interface used by the server to notify the client about changes in item values and qualities

OPC Item

An OPC item is the simplest unit of information provided by a server. An item might correspond to a physical I/O such as a relay state, a temperature or humidity value, a robotic arm position… or a value in memory such as the constants of a PID algorithm…

An OPC item has static properties, such as the canonical datatype, the description, the engineering unit…etc and runtime properties such as the value, the quality (level of confidence in the value provided), the timestamp of the latest change in value and/or quality and the item active state.

OPC Subscription

While it is possible for a client to make synchronous or asynchronous calls to read and write, creating a subscription is the most common and efficient way for a client to receive data. Basically, a subscription occurs when the client registers itself at the server in order to receive notifications when item values or qualities change. This method saves CPU/bandwidth by avoiding unnecessary read calls for items that didn’t necessarily change.

OPC Group

A group is a logical container for OPC items, the most important properties of a group are:

  • Active State: when a group is inactive the server stops sending change notifications for all the items that belong to the group
  • Update Rate: The server should not send change notifications to the client faster than the update rate (in milliseconds). When set to zero, the client requests data to be sent as quickly as possible

Be careful, when changing the value of this property, a small value may lead to a situation where data is oversampled which means an increase in the network traffic and eventually an overload of the end controller.

Subscriptions are made at the group level and they use a COM interface called IConnectionPointContainer as illustrated in the code snippet below:

// retrieve the connection point container interface from IOPCGroupStateMgt
// IOPCGroupStateMgt is returned from a call to IOPCServer::AddGroup
callbackConnectionPointContainer = opcGroupStateMgt as IConnectionPointContainer;
// retrieve the callbakc interface GUID
Guid riid = typeof(IOPCDataCallback).GUID;
// retrieve the connection point
callbackConnectionPointContainer.FindConnectionPoint(ref riid, out callbackConnectionPoint);
// use the connection point to register the caller object as recipient of change notifications
callbackConnectionPoint?.Advise(this, out callbackCookie);

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.