Glossary for OPC UA

OPC UA Application

Client, which calls OPC UA Services, or a Server, which performs those Services, or an OPC UA Publisher or an OPC UA Subscriber. ¹

A more generic definition would be an application, that implements some of the models required by the standard (object model, service model, security model, …) with respect to the communication profiles of part 7.

OPC UA Services

The actual service definitions used to build a working server are mentioned at a number of different locations throughout the online reference. Generally speaking, while services can be part of the regular AddresSpace, there is a difference between the object model used to manage data and the service model used to issue requests to a server. The official references use different NodeSet schemata to create and parse services when building a custom API layer for a specific server. This makes sense, since the service definitions (as part of the NodeSet2.xml) do not need to be used as part of the compilation step, when creating a custom application using the default namespace, companion specifications and custom extensions. Therefore having a separate set of definitions for setting up services to build APIs for servers does make sense.

4.2 Request/response Service procedures Request/response Service procedures describe the processing of requests received by the Server, and the subsequent return of responses. The procedures begin with the requesting Client submitting a Service request Message to the Server. Upon receipt of the request, the Server processes the Message in two steps. In the first step, it attempts to decode and locate the Service to execute. […] If it succeeds, then it attempts to access each operation identified in the request and perform the requested operation. […] To perform these operations, both the Client and the Server may make use of the API of a Communication Stack to construct and interpret Messages and to access the requested operation.²

The two steps involved are locating a service on a server and invoking a specific operation as part of the service. Keep in mind, Services are abstract definitions. The standard defines multiple service sets, which are groups of related services, that can be part of a specific OPC UA implementation for a server. It is up to the library provider to implement these services.

Whether or not a Server supports a Service Set, or a Service within a Service Set, is defined by its Profile. Profiles are described in OPC 10000-7.³

A library would implement a basic set of services to support specific functions on a server, called Profiles. Profiles are groups of well known functions a server needs to support to work with other OPC UA applications. Profile definitions can be discovered by clients to determine what API is supported by the target server. Annex A covers the definitions for the NodeIDs and in our case the default NodeSet2.xml as well as the NodeSet2.Service.xml. Both of these are required when interacting with an OPC UA application since these provide the “well known” IDs required to parse a custom Namespace.

Clause A.3 defines the numeric identifiers for all of the numeric NodeIds defined by the OPC UA Specification. The identifiers are specified in a UTF8 encoded CSV file. The syntax is informative and provided to assist developers of tools. The UANodeSet is the normative source for all identifiers.⁴

The current files and schemata to map between well known Node IDs and Services can be found on GitHub and the reference page of the Foundation:

The NamespaceUri for all NodeIds defined is http://opcfoundation.org/UA/ The CSV released with this version of the standards can be found here: https://reference.opcfoundation.org/files/NodeIds.csv?u=http://opcfoundation.org/UA/&v=1.05.04 ⁴

This second aspect of the appendix B⁵ is quite important for our use case and solves the issue of how to decode Request and Response Messages to a server:

The complete Information Model Schema includes many types which are only used in Service Requests and Responses and should not be used by Servers to populate their Address Space.

and

OPC UA provides a consistent, integrated AddressSpace and service model. ⁶

OPC UA makes a distinction between the different models. While the AddressSpace is used to create and manage the object model, the service model is a separate entity within the server.

Extension Object or Prefix

This Object is part of the OPC UA message structure and required to to issue service requests and responses. The communication model for client and server is built around the abstract service definitions which are mentioned in part 4 of the standard documents. To trigger any service, we need to tell the server what service we need to invoke. When checking the message structure this is not immediately obvious how this would work, since we need to pass a specific NodeID to the server, corresponding to a service definition. The extension object or prefix is used as part of the message body to locate a service and pass the request/response data as the rest of the body.

Protocol Layers - Protocol Bindings

OPC UA operates on top of TCP with respect to the OSI layer model. Therefore OPC UA should be considered a typical application protocol. However, OPC UA also defines a set of custom layers when targeting industrial applications, which can be used to create devices for very specific use cases. UA Automation has a great overview that shows the different layers that can be used to create custom OPC applications⁷

General Overview to the different OPC UA layer models by UA Automation

The base layer, here called protocol bindings, shows the different options that are currently supported for using OPC UA. Depending on the type of application and the communication requirements different transport protocols and encodings can be used to pass information between communicating parties.

This document defines Mappings between the abstract specifications and technologies that can be used to implement them. The Mappings are organized into three groups: DataEncodings, SecurityProtocols and TransportProtocols. Different Mappings are combined together to create StackProfiles. All OPC UA applications shall implement at least one StackProfile and can only communicate with other OPC UA applications that implement the same StackProfile.⁸

UACP - OPC UA Communication Protocol

the opc ua transport layer. the communication protocol is used for a few things here: manage the custom transport size between UASC and custom hardware. since opc is not limited to desktop hardware, this mechanism can be used to determine different transport options for embedded or high performance hardware.

uacp has different functions: manage transmit and receive buffers on both ends, create a duplex channel, create reverse connection in recent changes, handle message chunks.

the main header for the transport level protocol is made up of three fields: a message type that also supports dual use for UASC, a reserved flag, that is not used by this layer and a message size field.

there is a level of overlap between uasc and uacp. this overlap is used as part of the secure handshake between two nodes to create a secured session. uasc defines custom message types, which should be understood by the uacp layer so the stack can forward messages between layers.

tbd.

• UASC - OPC UA Secure Communication
• communication architecture
  • pubsub
  • request response
  • events and notifications, how are these different to pubsub?
• extensions
  • companion specifications
• global services

1. https://reference.opcfoundation.org/Core/Part1/v105/docs/2.1.30 ↩︎

2. https://reference.opcfoundation.org/Core/Part4/v105/docs/4.2 ↩︎

3. https://reference.opcfoundation.org/Core/Part4/v104/docs/5 ↩︎

4. https://reference.opcfoundation.org/Core/Part6/v105/docs/A.3#_Ref294144163 ↩︎ ↩︎²

5. https://reference.opcfoundation.org/Core/Part6/v105/docs/B ↩︎

6. https://reference.opcfoundation.org/Core/Part1/v105/docs/4.3 ↩︎

7. https://documentation.unified-automation.com/uagds/1.0.1/html/L2OpcUaFundamentalsOverview.html ↩︎

8. https://reference.opcfoundation.org/Core/Part6/v105/docs/4 ↩︎