In the nineties of the last century, the use of Windows-based PC software for automation sys- tems was getting more and more popular. As a result, many different vendor-specific protocols and interfaces that were not compatible to each other were developed and used. To overcome this incompatibility, a task force of different vendors of Human Machine Interface (HMI) and Supervisory Control and Data Acquisition (SCADA) software was formed in 1995. The aim of this task force was to define a standard for Windows-based device drivers that provide a uni- form way to access automation systems. After only one year of development, the first standard was released. This standard provides services for reading, writing, and monitoring of control data. Since it uses Microsoft’s technology Windows OLE to provide a unified way to access the network, the name OLE for Process Control (OPC) was chosen. During this first release, the nonprofit organization called OPC foundation was formed. The OPC foundation is a non- profit organization that provides and maintains all OPC related specifications. Today, nearly all distinguished vendors that deal with industrial automation are member of the OPC foundation. In addition to this first standard release, many other OPC specifications have been defined. Therefore, the initial OPC standard was later renamed to OPC Data Access (OPC DA). Other important OPC standards are OPC Alarm&Event (OPC A&E), OPC Historical Data Access (OPC HDA), OPC Batch, OPC Security, OPC Data Exchange (OPC DX), OPC Compliance Tests, and OPC and XML. All these standards have been continuously revised by the OPC foundation. In its current version 3, OPC DA is the most prominent OPC specification [6].
The main reasons of the success of OPC are the focus-oriented design and the existence of well-defined interfaces. The main goal was to provide an easy-to-use Application Programming Interface (API) that hides the complexity of the underlying communication system. Thanks to these unified OPC interfaces, developers of OPC client software are able to concentrate on the functionality of their clients – they do not have to worry about communication details of the underlying network technologies. To provide such a unified communication interface, Microsoft’s technologies Component Object Model (COM) and Distributed Component Object Model (DCOM) were used in OPC. Thus, OPC was dedicated to Windows-based systems exclusively. Choosing Microsoft Windows as standard platform for OPC had another advantage. At the time of the first OPC standard release, most HMI and SCADA systems were Windows- based systems and so, a quick adoption to the new OPC standards was possible.
However, while the usage of COM/DCOM was the key driver for OPC’s success, relying
on COM/DCOM introduces several disadvantages that are getting a major problem in modern automation systems. This is for various reasons:
• OPC is limited to Windows-based systems – implementing OPC on Linux-based platforms
or even on embedded devices is not possible.
• COM/DCOM is only practicable for Local Area Networks (LANs). Using it within Wide
Area Networks (WANs) like for remote access via the Internet is not possible due to limited support for routing and security of COM/DCOM.
• Configuration and management of COM/DCOM is not an easy task. Especially, configur-
ing the security is a major problem.
• Due to the use of COM/DCOM, the compatibility of OPC software also depends on the
used Windows versions. For example, there are problems when Windows XP based systems are used with systems that are based on Windows Vista or Windows 7.
In addition to the lack of COM/DCOM, the OPC specifications have further drawbacks and open issues. The functionality needed to implement a comprehensive OPC software is spread over several OPC specifications. This may introduce a barrier for software developers since they must have detailed knowledge about the different OPC specifications. The situation may be even worse since different versions of the same type of OPC specification are only partly compatible. Another drawback of classical OPC is its rudimentary data model where modelling of information is only possible in a very restricted way. Modelling complex data structures is not feasible due to missing features.
To overcome the drawbacks of these so called classical OPC specifications, the OPC founda- tion decided to define a new specification that is referred to as OPC Unified Architecture (OPC
UA). The main goal of OPC UA was to eliminate the dependency to Windows COM/DCOM by
using a Service Oriented Architecture (SOA). To achieve this, OPC UA uses Web services or a TCP based protocol for data exchange that both enable full platform-independence. In addition to this new communication concept, another key concept within OPC UA is the support of a powerful and extensible information model which can be used to model any kind of information and data. The current version of OPC UA [5] will soon be published as IEC 62541 [7].
The OPC UA specification consists of 13 parts [8]. OPC UA covers the whole area of all classical OPC specifications and so OPC UA can be seen as a full replacement to classical OPC – if OPC UA is applied, other specifications from classical OPC are not needed anymore. However, to be able to further use classical OPC devices and software, so called OPC UA wrappers can be used. Figure 2 shows an overview of the different parts of the OPC UA specification.
The OPC UA specification has two main goals. First, it defines mechanisms to model infor- mation about the process under control (i.e., process data, meta-information about the process and its environment). To achieve this, OPC UA specifies a so called address space model which can be used to model any kind of information (cf. Section 2.1). In addition, OPC UA also specifies mechanisms to access the modelled data. Therefore, various communication services and ways to implement them are also included (cf. Section 2.2).
2.1 Address space model and information modelling in OPC UA
A key requirement of modern automation systems is interoperability. To support interoperability between devices of different vendors or between devices that may even use different technolo- gies, it is essential to provide a standardized, well-defined way to model the data that shall be
Part 1: Concepts
Part 3: Address Space Model Part 2: Security Model
Part 4: Services
Part 5: Information Model Part 6: Service Mappings Part 7: Profiles
Part 8: Data Access
Part 10: Programs
Part 9: Alarm and Conditions
Part 11: Historical Access Part 13: Aggregates
Part 12: Discovery
Core Specification Access Type Specification
OPC UA Specification
Figure 2: OPC UA specification [8]
accessible by the different devices. In classical OPC DA, modelling data is only possible in a very limited way since important mechanisms like specifying a type hierarchy or using other object-oriented concepts are missing. Therefore, complex data structures can not be defined in OPC DA. To overcome this limitation, OPC UA introduces a so called address space model which provides the following features [8]:
• The address space model supports object-oriented mechanisms allowing the definition of
type hierarchies and inheritance.
• Type information and type hierarchies can be accessed by clients since they are exposed
like normal data.
• The modelling concept allows a definition of models that consists of full-meshed nodes. • Vendors and developers can extend OPC UA’s information model by defining their own
models on top of the built-in model.
• Information models are defined server-side and so, clients do not need to be aware of the
models since they are able to retrieve them from the server.
A key concept of OPC UA information modelling is that the OPC-specific information model can be extended by defining own models on top of the existing one. Figure 3 shows the basic concept of information modelling in OPC UA.
Information modelling in OPC UA is based on defining nodes and references between them. Nodes are used to model any kind of information. This includes the representation of data instances or the definition of data types. Each node belongs to exactly one node class. In OPC UA, the following node classes are distinguished:
• Base NodeClass: This node class represents the base class from which all other node
classes are derived.
• ReferenceType NodeClass: This kind of nodes is used to define different reference
OPC UA Alarm and Conditions (Part 9) OPC UA Data Access (Part 8) OPC UA Programs (Part 10) OPC UA Historical Access (Part11) Information models from other domains or organizations
Vendor-specfic, proprietary information models
OPC UA base information model (Part 5)
Figure 3: Information models in OPC UA
types.
• View NodeClass: A view summarizes a subset of the nodes of the address space.
Views are used to make only part of the address space visible to the clients.
• Object NodeClass: Objects are used to represent real-world entities like system com-
ponents, hardware and software components, or even whole systems.
• ObjectType NodeClass: This node class is used to provide type definitions for objects. • Variable NodeClass: Variables are used to model values of the system. OPC UA
distinguishes between data variables (e.g., data points that represent physical values of the process under control) and properties (e.g., meta-data that further describes nodes).
• VariableType NodeClass: This node class is used to provide type definitions for vari-
ables.
• DataType NodeClass: The DataType NodeClass is used to provide type definitions
for the values of variables.
• Method NodeClass: Methods are used to model callable functions.
Depending on the node class, a node has several attributes that describe it. Some attributes are common to all nodes like the NodeId (uniquely identifies a node within the address space), the NodeClass (defines the node class), the DisplayName (localized text that can be used by a client for displaying the name), and the BrowseName (identifies a node when browsing the address space). Other attributes are only available for certain node classes. For example, variables have the attribute Value that represents the value of the variable and the attribute DataType that indicates the data type of the Value attribute. For a complete list of all at- tributes, see [5].
The list of attributes can not be extended by the user. Adding additional semantic to nodes has to be done by introducing a type hierarchy and by adding references to other nodes. A key concept within OPC UA is the modelling of complex type definitions for objects and variables. A complex type is an object or variable that embeds other nodes as sub components. The assignment of these sub nodes to their parent node is done by using references.
Another powerful modelling mechanism is the use of references. References are always de- fined from one to another – references are therefore always one-to-one relations. References can be defined symmetric or asymmetric. Symmetric references are bidirectional and valid in both directions. If a reference is asymmetric, it is possible to specify a name for the inverse
direction of the reference. References can further be hierarchical or non-hierarchical. Hierar- chical references can be used to introduce topologies and hierarchies within the model. Typical examples of OPC-specific hierarchical references are Organizes (used to introduce a general hierarchy of nodes) and HasComponent (use to reference a complex type to its sub nodes). An example of an OPC-specific non-hierarchical reference is HasTypeDefinition which is used to reference a object or variable to its type definition.
There are many other modelling mechanisms in OPC UA which can not be described here. For more details about these mechanisms, see [5].
2.2 Services and communication in OPC UA
OPC UA is completely based on the client/server model – the communication is performed in sessions. To gain access to data, an OPC client establishes a connection to one or more OPC servers. In OPC UA, devices can choose one of two different transport protocols for communication. The first one is based on WS-I Basic Profile 1.1 [9] where SOAP and HTTP are used. The second one is a binary TCP based protocol which has been developed by the OPC foundation.
Since OPC devices are mainly located at the management level where the network may be shared with other application domains, a security model has been introduced in OPC UA. To secure the communication, a secured channel is set up during session establishment. This secured channel is provided by the OPC communication layer which is located between the transport layer and the application layer. The secured channel uses cryptographic techniques to guarantee data confidentiality, freshness, and data origin authentication. Entity authentication is provided during session establishment with the help of certificates. Authorization i.e., access control to the control data and services, is left up to the application.
Based on these secure transport protocols, OPC UA defines different services that are used by OPC clients to communicate with the servers and vice versa. These services are grouped into so called services sets. Typical service sets are the Attribute Service Set which contains services to read and write attributes of nodes as well as the Session Service Set that consists of services to open and close a session. For a complete list of all services specified by OPC UA, see [5].