UA Overview

Introduction

OPC Unified Architecture (UA) follows today’s and future requirements of industrial communication needs. It unifies and extends the individual standards of the first generation OPC (also called OPC COM or OPC Classic) using a service oriented architecture (SOA) paradigm. This result is platform independent, scalable and high-performance communication infrastructure. The use in small devices of process and measurement technology with their specialized operating systems is just as well possible as the use in enterprise applications on Unix/Linux machines or Mainframes.

The rich information model can represent complex relationships of data and its semantics. Specially designed transport protocols offer highest communication speed and interoperability.

Furthermore OPC UA provides security mechanisms like authentification, authorization, encryption and data integrity based on the latest cryptographic standards such as PKI, AES, and SHA.

Concepts

OPC UA Is Service Oriented

The OPC UA architecture is a Service Orientated Architecture (SOA) and is based on different logical levels. All of the Base Services defined by OPC are abstract method descriptions which are protocol independent and provide the basis for the whole OPC UA functionality.

Transport

The transport layer transforms these methods into a protocol, which means it serializes/deserializes the data and transmits them over the network. Currently there are two TCP/IP based protocols specified for this purpose. One is a binary, high performance optimized TCP protocol and the second, a webservice based protocol. The binary protocol is mandatory and is supported by all UA stacks. Additional protocols are possible and may be added when necessary.

Data Modell

The OPC Information Model is not just a hierarchy based on folders, items and properties anymore, but a so-called Full Mesh Network based on Nodes instead. This network of Nodes can additionally transmit all varieties of meta information and diagnostic data. The closest image of a node would be an object, known from object-oriented programming (OOP). It can be composed of Variables that can be read or written, Methods which can be called, and Events which can be fired. An Event contains among other things a time of notification, a message and a severity. Nodes are used for process data as well as for all other types of meta data. The newly modeled OPC namespace now contains the Type Model used to describe all possible data types as well.

Expandability

Based on this new architecture, other organizations are specifying their own information source, the so-called companion specifications. One of the first of these specifications is the DI (device integration) model. It describes devices and forms a base for further companion specifications like ADI, PLCopen, or FDI, which for their part define own information models. Client software has the ability to verify which of the so-called Profiles a server supports. This way clients can detect whether a server only supports DA (data access) functionality or additionally A&C (alarms and conditions), HDA (historical data access), etc. Additionally, information can be obtained whether a server supports e.g. the DI profile and therefore the client knows that there will be DI-specific device descriptions as well as configuration and diagnostic information available.

Additional important features of OPC UA are:

• service oriented architecture using a asynchronous request/response paradigm
• combines all features of the previous “classic OPC” specifications
• bulk operations for all access operations
• bandwith-friendly transmission
• redundancy support on client and server side, multiple redundancy
• heartbeat for connection monitoring in both directions; i.e. the server as well as the client recognize failures
• buffering of data and acknowledgements of transmitted data
• lost connections do not lead to data loss anymore; lost data packages can be fetched again

OPC UA Services

Abstract Definition of Services
The service oriented architecture (SOA) follows the request/response paradigm. OPC UA defines a fixed set of services with exactly defined parameters and behavior. These services are generic. There is for instance only one “Read” service for reading attributes, i.e. data as well as properties. There is a “Browse” for navigating through a UA server’s address space.
The genericity and standardization of these Services assures interoperability. They are combined into so-called “service sets” according to their purpose.

The following list shows these groups of services.

Service Set	Description
SecureChannel Service Set	retrieve endpoint and security configuration to establish a secure connection
Session Service Set	create and administrate user-specific connection between application
NodeManagement Service Set	modify the server’s address space (if permitted)
View Service Set	navigate and follow (hierarchical) references in the server’s address space, search for and filter information
Attribute Service Set	read and write attributes of (an) node(s), especially the value attribute, but historical data or events as well
Method Service Set	invoke methods which a server provides at the nodes in its address space
MonitoredItem Service Set	create a set of attributes of nodes to be monitored by the server and for which changes should be reported
Subscription Service Set	create, modify, or delete monitored items
Query Service Set	perform a filtered search for information in the server’s address space

OPC UA Data Model

OPC UA defines a generic object model including the associated type system. In addition to this data model, rules have been defined to describe how to transform every physical system into a model conforming with OPC UA to represent it in an OPC UA server. Every kind of device, function, and system information can be described using this meta model. The base type system supports relationships between objects, so-called references, as well as multiple inheritance. Thus it can be compared to a modern object oriented programming language. The base model provides object and variable types as well as reference and data types. Based on this model, OPC UA can represent every kind of data including their metadata and semantics.

UA Models

The OPC UA data model forms the base for UA information models. Being specialized models, they extend the base by adding specific functionality like Data Acess, Alarms and Conditions, Historical Access or Programs.

Extensions

The data and type model is arbitrarily expandable. It is mandatory for a server to provide its type model, especially if it provides types which are not UA base types, the so-called “well known types”. The goal is to specify extensions as possible as industry-sector-specific models. This is worked out in additional specifications, so-called companion specifications. Here, the OPC Foundation collaborates with other organisations to obtain common UA conform representations.

OPC UA Security

UA security is a multilayer concept. It contains authentication and authorization as well as encryption and data integrity by signing. A distinction is made between application layer and transport layer security.

Application Layer

There are several security mechanisms on application layer. The user or operator of an application can be identified by a user/password combination, a Kerberos token, or a user certificate. The permissions can be adjusted for each single node: It is possible that a user is only allowed to read values, whereas an administrator may also have write access, but a guest may not even be able to browse a node. In addition to that, audit mechanisms are defined and a server may log which person has changed which value at which time (audit event, audit log).

Security is not optional, the features are integral parts of the specification and the UA stack.

Transport Layer

OPC UA defines message security for the binary as well as for the web service protocol. The OPC foundation did not invent a security mechanism but adopts well-established IT mechanisms. The authentication exclusively uses x509 certificates. It’s up to the application developer to decide to which certificate store the UA application is bound to. For instance, it is possible to use the Public Key Infrastructure (PKI) of an Active Directory.

OPC UA Applications

A UA application, no matter if client or server, is composed of several layers (see figure below).

UA Stack

The following tasks are in the responsibility of the UA stack:

• encoding/decoding of messages (serialization)
• transport related security features (secure channel layer)
• transmission over the network (transport layer).

The operating system specific adaption is realized centrally in a platform layer (portability layer). Therefore, the .NET UA stack uses the .NET framework and the Java UA stack requires Java Runtime Environment (JRE).

The dark blue parts of the figure represent UA Stacks and are provided by the OPC Foundation. The portability layer of the ANSI C stack allows to port the stack to other platforms. A limited set of platform layers is provided by the OPC Foundation. Other platform layers, e.g. for IPv6, 64 bit, Linux, QNX, vxWorks, WindowsCE etc. are available from commercial suppliers.

Software Development Kit (Toolkit)

In addition to the OPC UA stack of the OPC Foundation, which provides a low-level interface, more, partly generic, functionality is desirable, especially on server side. This “glue code” between application and UA stack is typically encapsulated in libraries and provides a high-level interface and convenience functions for the application. SDKs or toolkits are offered by several OPC Foundation members and contain, apart from the libraries, examples, tutorials, and documentation as well as professional support. The SDKs contain the UA stack as well and thus provide full access to OPC UA technology for non-members of the OPC Foundation.