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