OPC UA Specifications

OPC UA is a layered set of specifications separated into multiple parts. It is purposely described in abstract terms (technology and language independent) to ensure that OPC UA will long outlive the lifetime of base technologies like DCOM. Only in a single part (Part 6 Mapping) OPC UA is mapped to an existing technology on which OPC UA software can be built. The parts of the OPC UA Specifications can be grouped into the following sets:

• Core Specification Parts
• Access Type Specification Parts
• Utility Specification Parts

Core Specification Parts As shown in Fig. 1, the Core Specification set consists of the following seven parts: Part 1 – Overview and Concepts This part describes the goal of OPC UA and introduces the models to achieve it. Part 2 – Security Model OPC UA provides countermeasures to resist threats that can be made against the environments in which OPC UA will be deployed. It describes how OPC UA relies upon other standards for security, e.g. the World Wide Web Consortium (w3c) or the OASIS Organization. The proposed architecture is structured in an Application Layer and a Communication Layer. The Security Policy is part of an End Point Description and defines the security to be used. Part 3 – AddressSpace Model There is no doubt that information technology and process control engineering have to be integrated to benefit from macro optimization and synergy effect. According to the specification, a set of objects that represents an underlying (real-time) system is exposed as an AddressSpace by an OPC UA Server. The key feature of the AddressSpace concept allows representing both the real process environment and the (real-time) process behavior in a unified manner that is mutually understandable by diverse systems. To achieve this, the AddressSpace provides a set of Nodes that are interconnected by References. Part 4 – Services The OPC UA Services are a collection of abstract remote procedure calls (RPCs) that is to be implemented by the servers and called by the clients. The services are considered abstract because no particular implementation in any specific technology is defined in this part. Separation of the Service definition and implementation allows for easy adoption of new emerging technologies by the addition of new mappings. Part 5 – Information Model To make the data exposed by the AddressSpace mutually understandable by diverse systems, the Information Model part standardizes the information representation as computer centric data. To promote interoperability, the Information Model defines the content of the AddressSpace of an OPC UA Server. Definitions provided in this part are considered abstract because they do not define any particular representation on the wire. Part 6 – Mappings This part defines Mappings between abstract definitions contained in the specification (e.g. in the parts: Information Model, Services, Security Model) and real technologies that can be used to implement them. Mappings are organized into three groups: data encodings, security protocols and transport protocols. Different Mappings are combined together to create Stack Profiles. Part 7 – Profiles This part describes the OPC UA Profiles as groups of Services or functionality that can be used for conformance level certification. Individual features are grouped into conformance units, which are further grouped into Profiles. All OPC UA applications shall implement at least one Stack Profile and can only communicate with other OPC UA applications that implement the same Stack Profile. Servers and clients will be tested and certified against Profiles. When establishing a connection, the server and client exchange the supported Profiles as part of their software certificates. Access Type Specification Parts The Access Type Specification set contains the following four parts: Part 8 – Data Access The Information Model associated with the Data Access (DA) model includes, in particular, an additional definition of Variable Types and a complementary description of AddressSpace Objects. In addition, this part also provides descriptions of Node Classes and Attributes needed for DA, as well as DA specific usage of Services to access process data. Part 9 – Alarms and Conditions The Alarms and Conditions part describes the representation of configurable states in the OPC UA AddressSpace and introduces the concepts of Condition, Dialog, Acknowledgeable Condition, Confirmable Condition and Alarm. To expose above information, it extends the Information Model related to Events defined in other parts and describes alarm specific methods. Part 10 – Programs This part introduces the concept of Programs as a complex state machine in a server or underlying system that can be invoked and managed by an OPC UA Client. The provided definitions describe the standard representation of Programs in the AddressSpace of a server. There are described Methods which can be used to manage the Programs. Part 11 – Historical Access The Information Model associated with Historical Access (HA) that is described in this part includes additional and complementary definitions of the representation of historical time series data and historical event data. Additionally, this part covers HA specific usage of Services to detect and access Historical Data and Events. Utility Specification Parts The Utility Specification set contains the following two parts: Part 12 – Discovery The main goal of this part is to describe the Discovery process that allows clients to find servers on the network and then find out how to connect to them. This part describes how UA clients and servers interact to exchange information that is on different resources distributed on a network. To achieve this goal, the concept of a Discovery Server that is a placeholder of global scope information is introduced. In addition, a local Discovery Server, whose main task is to manage information vital to local resources is also specified. Finally, this part describes how to discover OPC UA applications when using common directory service protocols such as UDDI (Universal Description, Discovery and Integration) and LDAP (Lightweight Directory Access Protocol). Part 13 – Aggregates This part specifies the Information Model associated with Aggregates and describes how to compute and return Aggregates like minimum, maximum, average etc. Aggregates can be used with base (live) data as well as Historical (HA) data. This part also addresses the aggregate specific usage of Services. Authors: Peter Seeberg, Product Marketing Manager, Softing Industrial Automation GmbH Jürgen Lange, Area Account Manager Embedded Technology Products, Softing Industrial Automation GmbH  

Learn More