OPC_OPC UA Specification_Overview and Concepts

OPC UA overview

1 UA application domain

OPC UA is a component widely used in industrial domains, such as industrial sensors and actuators, control systems, manufacturing execution systems and enterprise information systems, including IIoT (Industrial Internet of Things, Industrial Internet of Things) , Machine to machine communication (Machine to machine, M2M), and Industry 4.0 and Made in China 2025. These systems are designed to exchange information and send command and control over industrial processes. OPC UA defines a common base model to facilitate this information exchange. OPC UA specifies the following:

• An information model representing structure, behavior, and semantics;
• A message model for interacting with the application;
• A communication model for transferring data between end-points;
• A conformance model to ensure interoperability between systems.

2 General

OPC UA is a platform-independent (platform-independent) standard.
With this standard, various types of systems and devices can communicate by sending request and response messages between clients and servers, or by sending network messages between publishers and subscribers on various types of networks. It supports robust, secure communication, ensures the identity of OPC UA applications and defends against attacks.

In the C/S (Client Server) model, OPC UA defines the service set that the server may provide, and individual servers specify the service set supported by the client. Information is passed using OPC UA with vendor-defined data types, and the server defines an object model that clients can discover dynamically. The server can access current and historical data, as well as alarms and events, to notify clients of important changes. OPC UA can be mapped onto various communication protocols, and data can be encoded in various ways to provide a trade-off between portability and efficiency.

In addition to the C/S model, OPC UA also defines a mechanism for publishers to pass information to subscribers using the PubSub model.

3 Design goals

OPC UA provides a unified, integrated address space (AddressSpace) and service model. It allows a single server to integrate data (data), alarm (alarm) and events (event) and history (history) into its address space, and use a set of integrated service sets to provide access. These services also include an integrated security model.

OPC UA also allows servers to provide clients with type definitions for objects accessed from an address space. This allows an information model to be used to describe the contents of an address space. OPC UA allows data to be exposed/disclosed in different formats, including binary structures, XML and JSON documents. The format of the data may be defined by OPC, other standards organizations or vendors. Through the address space, the client can query the server for metadata (metadata, used to describe the data format). In many cases, clients that do not have pre-programmed knowledge of the data format are able to determine the format at runtime and utilize the data correctly.

OPC UA adds support for multiple relationships between nodes, not limited to a single hierarchy. In this way, the server can present data in a variety of hierarchies to suit the way a set of clients would normally want to view the data. This flexibility, combined with support for type definitions, makes OPC UA applicable to a wide variety of problem domains. As shown in the figure below, OPC UA is not only aimed at the interface of SCADA, PLC and DCS, but also as a way to provide greater interoperability between higher-level functions.

OPC UA target application

OPC UA aims to increase the robustness of published data. An important feature of all OPC servers is the ability to publish data and event notifications. OPC UA provides mechanisms for clients to quickly detect and recover from transport-related communication failures without having to wait for long timeouts provided by the underlying protocols.

OPC UA is designed to support a wide range of servers, from PLCs on the shop floor to enterprise servers. These servers come in different sizes, performance, execution platforms, and functional capabilities. Therefore, OPC UA defines a comprehensive set of functions, and the server can implement some of them. To improve interoperability, OPC UA defines subsets, called profiles, to which servers can declare conformance to the subset profiles. The client can then discover the server's configuration file and customize its interaction with that server based on the configuration file. Profiles are defined in OPC 10000-7.

The OPC UA specification has a layered design, which isolates the core design from the underlying computing technology and network transmission. This allows OPC UA to map to future technologies as needed (the core design remains unchanged, the actual technology can be replaced), without negating the basic design. OPC 10000-6 describes mapping and data encoding, defining three data encodings:

• XML/text
• UA Binary
• JSON

Additionally, several protocols are defined:

• OPC UA TCP
• HTTPS
• WebSockets

OPC UA applications support multiple transports and encodings, allowing end-users to decide the performance and compatibility trade-offs at deployment time rather than OPC vendors at product definition time.

OPC UA is designed for OPC clients and servers based on Microsoft COM technology. When designing OPC UA, special consideration was given to the existing public data of OPC COM servers (DA, HDA and A&E), which can be easily mapped and exposed through OPC UA. Vendors can choose to migrate their products natively to OPC UA or use external wrappers to convert OPC COM to OPC UA and vice versa. Each of the preceding OPC specifications defined its own address space model and set of services. OPC UA unifies previous models into a single integrated address space and set of services.

OPC UA PubSub opens up new application areas for OPC UA. Here are some application examples of PubSub:

• Configurable peer-to-peer/peer-to-peer communication between controllers and between controllers and HMIs. These endpoints are not directly connected, and do not even need to know that each other exists. Data exchange usually requires a fixed time window; it may be point-to-point or multipoint connections.
• Asynchronous workflow. For example, an order handler can put an order on a message queue or an enterprise service bus. It can then be processed by one or more workers.
• Log to multiple systems. For example, sensors or actuators may write logs to monitoring systems, HMIs, archive programs for later query, etc.
• A server representing a service or device can stream data to an application in the cloud. For example, backend servers, big data analytics for system optimization and predictive maintenance.

PubSub is not tied to a particular messaging system. Instead, it can be mapped to different systems, here are two examples:

• In a production environment where small amounts of data are frequently transferred, PubSub over UDP may be useful. It allows data exchange in one-to-one and one-to-many configurations.
• Using established messaging protocols such as ISO/IEC MQP 1.0 combined with JSON data encoding supports cloud integration paths and can easily process information from modern streaming and batch analytics systems.

4 Integrated models and services

4.1 Security Model

4.1.1 General

OPC UA security involves authentication of clients and servers, authentication of users, integrity and confidentiality of communications, and verifiability of capability claims. The specification does not specify that security mechanisms are required in every case. This specification is critical, but it is developed by the system's designer at a given site, and may be specified by other standards.

Instead, OPC UA provides a security model, which is described in OPC 10000-2.
Among other things, security measures can be selected and configured to meet the security needs of a particular installation. In some cases, mechanisms for exchanging security parameters are defined, but how applications use these parameters is not. The framework also defines a minimum set of Security Profiles that are supported by all OPC UA applications, although they may not be used in all installations. Security profiles are defined in OPC 10000-7.

4.1.2 Discovery and session establishment

Application level security relies on a secure communication channel that remains active during an application session and ensures the integrity of all messages exchanged. This means that users only need to authenticate once to establish an application session. The mechanisms for discovering servers, establishing secure communication channels and application sessions are described in OPC 10000-4 and OPC 10000-6. More information on the discovery process is described in OPC 10000-12.

When a session is established, the client and server applications negotiate a secure communication channel. Digital (X.509) certificates are used to identify clients and servers. The server also further authenticates the user and authorizes subsequent requests to access objects on the server.

4.1.3 Audit

OPC UA includes functionality for a secure audit trail that can be traced between client and server audit logs. If a security-related issue is detected on the server, the relevant client-side audit log entries can be located and examined. OPC UA also provides the ability for servers to generate event notifications that report auditable events to clients capable of processing and logging them. OPC UA defines security audit parameters that can be included in audit log entries and audit event notifications. OPC 10000-5 defines the data types for these parameters. Not all servers and clients provide all auditing features. Profiles in OPC 10000-7 indicate which features are supported.

4.1.4 Transmission Security

OPC UA security complements the security infrastructure provided by most web services platforms.

Transport-level security can be used to encrypt and sign messages. Encryption and signing can prevent information leakage and protect the integrity of messages. Cryptographic capabilities are provided by the underlying communication technology used to exchange messages between OPC UA applications. OPC 10000-7 defines encryption and signing algorithms for a given profile.

4.2 Integrated AddressSpace model Integrated AddressSpace model

The collection of objects and related information provided by the server to the client is called an address space (AddressSpace) . An OPC UA address space represents its content as a set of nodes connected by references.

The basic characteristics of a node are described by attributes defined by OPC. Attributes are the only elements in the server that have data values. The data type that defines the attribute value can be simple or complex.

Nodes in the address space are classified according to their purpose and meaning. NodeClasses define the metadata of the OPC UA address space. OPC 10000-3 defines a classification of OPC UA nodes.

The base NodeClass defines properties common to all nodes, allowing identification, classification and naming. Each NodeClass inherits these properties and can define its own properties.

To improve client and server interoperability, the OPC UA address space is organized hierarchically, with the top layer being the same for all servers. Although nodes in an address space are generally accessible through a hierarchy, they may reference each other, allowing the address space to represent the associated network of nodes. The address space model is defined in OPC 10000-3.

The server can divide the address space into views to simplify client access. Clause 6.3.4.3 describes the address space view in more detail.

4.3 Integrated Object Model

The OPC UA object model provides a consistent, integrated collection of NodeClasses for representing objects in an address space. The model represents objects in terms of their variables, events, and methods, and their relationships to other objects. OPC 10000-3 describes this model.

The OPC UA object model allows servers to provide type definitions for objects and their components. Type definitions can be subclassed. They may be generic or system specific. Object types can be defined by standards bodies, vendors, and end users.

This model allows the integration of data, alarms and events and their history into a single server. For example, a server could represent a temperature transmitter as an object consisting of a temperature value, a set of alarm parameters, and a set of corresponding alarm limits.

4.4 Integration Services

The interface between client and server is defined as a set of services. These services are organized into logical groupings called service sets. Service Sets are discussed in detail in 6.4 and specified in OPC 10000-4.

OPC UA services provide two functions to clients. They allow clients to send requests to and receive responses from servers. They also allow the client to be notified about the server. Notifications are used by servers to report occurrences such as alarms, data value changes, events, and program execution results.

For efficiency, OPC UA messages can be encoded in XML text or binary format. They can be transported using a variety of underlying transports, such as TCP or web services over HTTP. The server can provide different encodings and transmissions according to the OPC 10000-6 definition.

5 Session Session

OPC UA C/S interactions require a state model. State information is maintained within an application session. Examples of state information include subscriptions, user credentials, and continuation points for operations across multiple requests.

A session is defined as a logical connection between a client and a server. The server may limit the number of concurrent sessions based on resource availability, license limits, and other constraints. Each session is independent of the underlying communication protocol. Incidents of these protocols do not automatically result in session termination. Termination of a session is at the request of the client or the server, or the client ceases activity. The interval of inactivity is negotiated during session establishment.

6 System concept

6.1 Client Server Overview Client Server Overview

The OPC UA system architecture model regards client and server as interaction partners. Each system consists of multiple clients and servers. Each client can interact with one or more servers at the same time, and each server can also interact with one or more clients at the same time (interact concurrently). Applications can combine server and client components to allow interaction with other servers and clients.

The figure below shows an architecture combining server and client.

OPC UA system architecture

6.2 OPC UA client

The OPC UA client architecture models the client endpoints for C/S interactions. The diagram below illustrates the main elements of a typical client and the relationships between elements.

OPC UA Client Architecture

The client application refers to the code that implements the client functionality. It uses the client API to send and receive OPC UA service requests and responses to the server. The services defined for OPC UA are described in clause 6.4 of the specification and specified in OPC 10000-4.

Note that the client API is an internal interface that isolates the client application code from the OPC UA communication stack. The OPC UA communication stack converts client API calls into messages and sends them to the server through the underlying communication entity in response to the client application's request. The OPC UA communication stack also receives response and notification messages from the underlying communication entities and passes them on to the client application through the client API.

6.3 OPC UA Server

6.3.1 General

The OPC UA server architecture models server endpoints for C/S interactions. The following diagram illustrates the main elements of the server and the relationships between them.

OPC UA Server Architecture

6.3.2 Real objects

Real objects are physical or software objects that a server application can access or maintain internally. Examples include physical devices and diagnostic counters.

6.3.3 Server application

A server application is code that implements server functionality. It uses the server API to send messages or receive messages from clients (OPC UA messages). Note that the server API is an internal interface that isolates the server application code from the OPC UA communication stack.

6.3.4 OPC UA AddressSpace

6.3.4.1 AddressSpace node

AddressSpace is modeled as a set of nodes, accessed by clients using OPC UA services (interfaces and methods). Nodes in AddressSpace are used to represent actual objects, object definitions, and mutual references between objects.

6.3.4.2 AddressSpace organization

OPC 10000-3 contains details of the metamodel "building blocks" used to create address spaces from interconnected nodes in a consistent manner. Servers are free to organize their nodes in the address space as they choose. The use of references between nodes allows servers to organize address spaces into hierarchies, complete mesh networks of nodes, or possibly hybrid structures.

OPC 10000-5 defines OPC UA nodes and references and their intended organization in the address space. Some profile designs do not require all UA nodes to be implemented.

6.3.4.3 AddressSpace view

Views are a subset of AddressSpace. Views are used to limit the nodes visible to the client by the server, thereby limiting the size of the AddressSpace for service requests submitted by the client. The default view is the entire AddressSpace. The server may choose to define other views. The view hides some nodes and references in the AddressSpace. Views are visible through AddressSpace, and clients are able to browse the view to determine its structure. Views are usually hierarchical so that clients can more easily represent them in a tree menu bar.

6.3.4.4 Support for information models

OPC UA AddressSpace supports information models. Support is provided by:

1. Node references allow objects in an AddressSpace to be related to each other;
2. The object type node provides semantic information for the actual object (type definition);
3. Object type nodes support subclassing type definitions;
4. Data type definitions exposed in AddressSpace allow the use of industry-specific data types;
5. The OPC UA Partner Standard allows industry groups to define how a particular information model is represented in a server AddressSpace.

6.3.5 Subscription entities

6.3.5.1 MonitoredItems

MonitoredItems are entities created in the server by clients to monitor AddressSpace nodes and their real-world counterparts. When they detect data changes or events/alarms occur, they generate a notification, which is delivered to the client via a subscription.

6.3.5.2 Subscriptions

Subscriptions are endpoints in the server that publish notifications to clients. Clients control the rate at which publications are generated by sending them publication messages.

6.3.6 OPC UA service interface

6.3.6.1 General

The services defined for OPC UA are defined in clause 6.4 and detailed in OPC 10000-4.

6.3.6.2 Request/Response Service

The request/response service is a service called by the client through the OPC UA service interface to perform specific tasks on one or more nodes in AddressSpace and return a response.

6.3.6.3 Subscription Services

Call the publishing service through the OPC UA service interface to send notifications to the client periodically. Notifications include events, alarms, data changes, and program output.

6.3.7 S2S interactions from server to server

In the C/S model, the interaction between servers (S2S for short) refers to the interaction in which one server acts as the client of another server. S2S allows the development of servers that:

1. Information is exchanged on an end-to-end basis, which may include redundant or remote servers for maintaining system-wide type definitions.
2. Linked in a layered architecture of servers to provide:
   a. Aggregation of data from lower-layer servers;
   b. Higher-layer data construction for clients
   ; c. Concentrator interface to clients for multiple lower-layer The server provides a single point of access.

p2p interaction between servers

Similar p2p interactions can also be done with the OPC UA PubSub model, where each peer application is a publisher and a subscriber.

The following diagram expands on the previous example to illustrate how servers can be chained together to enable vertical/vertical access to data in an enterprise.

Chained server example

6.4 Redundancy Redundancy

OPC UA provides data structures and services in a standardized way for redundancy. Redundancy is used for high availability, fault tolerance, and load balancing. OPC 10000-4 formally defines client, server and network redundancy. Only certain OPC 10000-7 profiles require redundancy support, not the basic profile.

The desired client and server behavior is associated with two different server redundancy modes, transparent and non-transparent. When using transparent or non-transparent redundancy, the responsibilities of clients and servers are defined in OPC 10000-4.

Servers that support non-transparent redundancy also support client-controlled load balancing. The health of a server (including its ability to service requests) is collectively referred to as the Service Level. OPC 10000-4 defines four different Service Class subscopes and example usages.

6.5 Publish-Subscribe

Using PubSub, OPC UA applications cannot directly exchange requests and responses. Instead, publishers send messages to message-oriented middleware without knowing which subscribers there may be. Similarly, a Subscriber expresses interest in a particular type of data and processes messages containing that data, unaware of the Publishers.

Message-oriented middleware is software or hardware infrastructure that supports sending and receiving messages between distributed systems. The implementation of this distribution depends on message-oriented middleware.

To cover a large number of cases, OPC UA PubSub supports two different message-oriented middleware variants. They are:

• The brokerless form, where message-oriented middleware is the network infrastructure capable of routing packet-based messages. Subscribers and publishers use packet protocols such as UDP multicast.
• Broker-based form, where the message-oriented middleware is the broker. Subscribers and publishers communicate with the broker using a standard messaging protocol such as AMQP or MQTT. All messages are published to specific queues (e.g. topics, nodes) exposed by the broker, which can be listened to by subscribers. Brokers can translate the formal messaging protocol of publishers to the formal messaging protocol of subscribers.

PubSub is used for message communication between different system components, which do not need to know each other's identity.

Publishers are pre-configured with the data to be sent. There is no connection established between the publisher and the subscriber.

Information about subscribers and data to be published are forwarded to subscribers by message-oriented middleware. The publisher doesn't know or even care if there is one or more subscribers. The capacity and resource requirements of publishers are predictable and independent of the number of subscribers.

OPC 10000-14 describes the details of the OPC UA PubSub model.

6.6 Synergy of models

Both PubSub and C/S are based on the OPC UA information model. Therefore, PubSub can be easily integrated into servers and clients. Typically, the publisher is the server (owner of the information), and the subscriber is usually the client. First, the PubSub configuration information model adopts the OPC UA C/S model to improve the configuration of publishers and subscribers. The diagram below depicts an OPC UA application acting as both server and publisher.

Model of Integrating C/S and PubSub

However, PubSub communication does not require role dependencies. For example, a client can also be a publisher, and a server can also be a subscriber. In fact, it is not necessary for publishers or subscribers to participate in PubSub communication as servers or clients.

7 Service Sets Service Sets

7.1 General

OPC UA services are divided into Service Sets, each Service Set defines a set of logical services for accessing specific aspects of the server. The service set is described below. Service sets and their services are specified in OPC 10000-4. Whether a server supports a service set, or specific services in a service set, is defined by its configuration file. Profiles are described in OPC 10000-7.

7.2 Discovery Service Set Discovery Service Set

This service set defines the services used to discover the servers available in the system. It also provides a way for clients to read the security configuration required to connect to the server. The discovery service is implemented by individual servers and dedicated discovery servers. As we all know, a dedicated discovery server provides a way that clients can discover all registered servers. OPC 10000-12 describes how to use discovery services and dedicated discovery servers.

7.3 SecureChannel Service Set SecureChannel Service Set

This service set defines the services used to open a communication channel that ensures the confidentiality and integrity of all messages exchanged with the server. The basic concepts of UA security are defined in OPC 10000-2.

Secure Channel Services differ from other services in that they are usually not implemented directly by OPC UA applications. Instead, they are provided by the communication stack upon which the OPC UA application is built. The OPC UA application only needs to verify that the secure channel is active when the message is received. OPC 10000-6 describes how to implement secure channel services using different types of communication stacks.

A secure channel is a long-running logical link between a single client and a single server. The channel maintains a set of keys, known only to the client and server, that are used to authenticate and encrypt messages sent across the network. The Secure Channel service allows a client and server to securely negotiate the key to use.

The exact algorithms used to authenticate and encrypt messages are described in the server's security policy. These policies are exposed through the discovery service set. When creating a secure channel, the client selects (supported by the server's desired security policy) the appropriate endpoint.

When a client and server communicate over a secure channel, they verify that all incoming messages are signed or encrypted according to the security policy. UA applications should ignore all messages that do not comply with the channel security policy.

Secure channels and UA application sessions are separate; however, a single UA application session can only be accessed through a single secure channel. This means that UA applications are able to determine which secure channel each message is associated with. If the communication stack provides a secure channel mechanism, but does not allow the application to know what secure channel was used for a given message, it cannot be used to implement a secure channel server set.

The relationship between UA application sessions and secure channels is shown in the figure below. UA applications exchange messages using a communication stack. First, the Secure Channel service is used to establish a secure channel between two communication stacks, allowing them to exchange messages in a secure manner. Second, the UA application uses the session service set to establish a UA application session.

Secure Channel and Session Services

7.4 Session service set

This set of services defines the services used to establish application layer connections within the context of a session.

7.5 Node management service set

The node management service set allows clients to add, modify and delete nodes in address visibility. These services provide an interface for server configuration.

7.6 View service set

Views are publicly defined and are subsets of the address space created by the server. The default view is the entire address space, so view services can operate on the entire address space. Future versions of this specification may also define services to create client-defined views.

7.7 Query service set

Query service sets allow users to access the address space without browsing and without understanding the logical schema of the data stored internally.

Queries allow the client to select a subset of the nodes in the view, based on client-supplied filter criteria. The query statements selected in the view are called the result set.

Servers can have difficulty handling queries that require access to runtime data, such as device data, that involve resource-intensive operations or large latencies. In this case, the server may reject the query.

7.8 Attribute service set

The attribute service set is used to read and write attribute values. Attributes are the basic characteristics of nodes defined by OPC UA. They cannot be defined by the client or the server. Attributes are the only elements in an address space that are allowed to have data values. A value attribute is a special attribute that defines the value of a variable.

7.9 Method service set

A method represents a function call on an object. They are defined in OPC 10000-3. After the method is called, it will return on completion, whether successful or not. The execution time of methods depends on the functional functions they perform.

The method service set defines the method to call the method. Methods are always an integral part of an object. Discovery is provided through browse and query services. A client discovers the methods supported by a server by browsing the owning object that identifies the methods it supports.

Because methods can control certain aspects of factory operation, method invocations may depend on environmental or other conditions. This is especially important when trying to re-invoke a method as soon as it has finished executing. A condition required to invoke a method may not have been restored to a state that allows the method to be restarted. Also, some methods may support concurrent invocations, while other methods may only perform a single invocation at a given time.

7.10 Monitoring item service set

The set of watch item services is used by clients to create and maintain watch items. Watch items monitor variables, properties, and event notifications. Notifications are generated when they detect certain conditions. They monitor changes in the value or state of variables; changes in the value of attributes; and new alarm and event reports generated by event notifiers.

Each monitoring item identifies an item to monitor and a subscription for publishing notifications to clients on a regular basis. Each watch item also specifies the rate at which the item is monitored (sampled) and, for variable and event notifiers, the filter criteria used to determine when notifications are generated. The attribute definition in OPC 10000-4 defines the filter criteria for the attribute.

The sample rate defined for a watch item may be faster than the subscription's publish rate. Therefore, a watch item can be configured to queue all notifications, or only the latest notifications for delivery by a subscription. In the latter, the queue has a size of 1.

The watch item service also defines a watch mode. Monitor mode is configured to disable sampling and reporting, and enable only sampling. When sampling is enabled, the server samples items. Additionally, each sample is evaluated to determine if the notification should be generated. If yes, the notification will be queued. If reporting is enabled, the queue will be used for subscriptions for delivery.

Finally, Watch Items can be configured to trigger reporting on other Watch Items. In this case, the monitor mode of the item to be reported is usually set to sample only, and when an item is triggered to generate a notification, any queued notifications for the item to be reported will be subscribed for delivery.

7.11 Subscribing to Service Sets

Subscription service sets are used by clients to create and maintain subscriptions. A subscription is an entity that periodically publishes notification messages for a watch item to its assigned watch items. Notification messages contain a common header followed by a list of notifications. The format of the notification depends on the type of monitored item (ie variable, property and event notification).

Once created, a subscription exists independently of the client's session with the server. This allows one client to create a subscription from which another client (possibly redundant) receives notification messages.

In case the client does not use it, the subscription has a configured lifetime, and the client renews it periodically. If none of the clients renew the lifetime, the lifetime will expire and the server will close the subscription. When a subscription is closed, all monitoring items assigned to the subscription will be deleted.

Subscriptions include functionality to support detection and recovery of lost messages. Each notification message contains a sequence number, allowing clients to detect lost messages. When there are no notifications to send within the keep-alive interval, the server sends a keep-alive message containing the sequence number of the next notification message to be sent. If the client fails to receive a message after the keep-alive interval has expired, or if it determines that some messages were lost, it can request the server to resend one or more messages.