OPC UA Book

The first OPC Unified Architecture Book, written by Wolfgang Mahnke, Stefan-Helmut Leitner and Matthias Damm one of the co-founders of ascolab.

OPC UA 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.

uaapplications

Transport

The transport layer transforms these methods into a protocol, which means it serializes/deserializes the data and transmits it 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. In addition, there is a combination of both protocols, the so-called hybrid protocol. Here, a binary encoded (unencrypted) message is sent using an encrypted channel (HTTP). 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 own attributes for read access (Data Access (DA), Historical Data Acess (HDA)), methods which can be called (Commands), and triggered events which can be fired (AE, DA DataChange) to exchange certain information between devices. 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. The most important 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 new and 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