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