.NET Based OPC UA Client/Server SDK  3.3.3.537
OPC Unified Architecture Overview

Overview

The OPC Unified Architecture consists of different building blocks that fall into one of the two categories information model layer and communication layer.

l2opcuaoverview4.png
OPC Unified Architecture Overview

The information model layer consists of OPC UA Meta Model, Built-In Information Models, Companion Information Models and Vendor Specific Information Models.

The communication layer consists of OPC UA Services for Client/Server, Service Protocol Binding, Messaging Model for PubSub and PubSub Protocol Binding. See also OPC UA Client/Server vs. PubSub for more details regarding use cases for client/server or PubSub.

The OPC UA Security features affect the communication layer and also the information model layer.

OPC UA Meta Model

The OPC UA Meta Model is the foundation for OPC UA information models. It defines the basic concepts of the information model layer and the rules on how to expose an object oriented address space. Objects consists of variables and methods and can fire events. All information is typed and types are also exposed in the address space. An address space contains typically several information models e.g. one for the device management, one for functionality of the device (e.g. RFID reader) and one for alarms and conditions of the device.

The Address Space Model in UA Part 3 specifies the building blocks to expose instance and type information and thus the OPC UA meta model used to describe and expose information models and to build an OPC UA server address space.

More details are described in the Address Space Concepts section.

Built-In Information Models

The base information model specified in UA Part 5 provides the structure for all information models using OPC UA. It defines

  • The entry points into the address space used by clients to navigate through the instances and types of an OPC UA server
  • The base types building the root for the different type hierarchies
  • The built-in but extensible types like object types and data types
  • The Server Object providing capability and diagnostic information.

Other OPC UA specification parts provide concrete built-in models like

  • Data Access for access to process data with corresponding meta data like units
  • State machines
  • Alarms and Conditions to expose process alarms and condition monitoring
  • Programs for long running actions and programs
  • OPC UA security configuration and management
  • File transfer for exposing file systems and file transfer
  • Device identification, configuration and management

Companion Information Models

Companion information models are device, machine or use case specific information models that are developed by joint working groups between domain expert organizations and OPC UA experts from the OPC Foundation. They are standard information models for a specific scope.

A big group of companion information models defines a mapping of existing standards to OPC UA. This could be

  • programming languages like the PLCopen model (IEC 61131-3)
  • XML or other meta models like AutomationML or ISA 95
  • communication systems like BACnet, IEC 61850 or field bus systems
  • device descriptions like FDI (Field Device Integration) or FDT (Field Device Tool)

Other groups define models for concrete industrial devices like AutoID (bar-code readers, RFID readers) or vision systems or commercial kitchen device like coffee machines, dish washer or cookers.

Other groups define machine type specific information models like EUROMAP for injection molding machines, machine tools or wood working machines.

Vendor Specific Information Models

Product vendors implementing concrete OPC UA applications define their own information models. It is strongly recommended to use existing standard information models if they exist for the product feature. In this case the standard models are extended with vendor specific features not covered by the standard model. In this case the vendor types typically derive from the types defined by the standard information models.

OPC UA Services for Client/Server

The abstract UA Services defined in UA Part 4 represent the possible interactions between UA client and UA server applications.

The client uses the services to find and access information provided by the server. The Services are abstract because they are defining the information to be exchanged between UA applications but not the concrete representation on the wire and also not the concrete representation in an API used by the applications.

The concrete representation on the wire is defined by the Service Protocol Binding.

The concrete representation in an API used for the SDK is defined by the programming language and the communication stack implementing the Service Protocol Binding.

The client / server communication with Services is following the request / response pattern.

A Service definition consist of a request message and a response message. A Service invocation is always a combination of request and response. E.g. a Read request defines the list of variables to read from the server and the Read response returns the values for the variables from the server to the client.

Half of the Services are defined for information exchange and the other half to manage and optimize the communication context for Sessions, Subscriptions and Monitored Items in Subscriptions. The client server subscription and the communication context is further described in the OPC UA Client/Server Subscription Concept.

The Services for information exchange are

  • GetEndpoints to get the available security settings necessary to establish a connection to a server (see also Discovery and Security Configuration)
  • Browse to navigate through the OPC UA server address space
  • TranslateBrowsePathToNodeIds to follow a known path of BrowseNames from a starting node to get the target node identifier
  • Read to get the current value of a variable or any other attribute value of OPC UA nodes
  • Write to update the current value of a variable
  • Call to invoke a method on an object
  • HistoryRead to read the time series data of a variable or the event log of an object
  • HistoryUpdate to insert, modify, update or delete historical information
  • Data and event streams using the OPC UA Client/Server Subscription Concept for data and event monitoring

Service Protocol Binding

A protocol binding for client server Services consists of message encoding, message security and message transport.

OPC UA defines the three message encodings OPC UA Binary, JSON and XML.

The mandatory OPC UA protocol binding combines UA Binary with UA TCP and UA Secure Conversation.

Additional optional protocol bindings are https and web sockets with the corresponding security features for the protocol. These optional protocol bindings are typically combined with OPC UA Binary or JSON encoding. They are mainly used for web applications.

Native OPC UA applications use the mandatory OPC UA binding with UA Secure Conversation and UA Binary.

Messaging Model for PubSub

The OPC UA PubSub communication model provides an alternative mechanism for the OPC UA Client/Server Subscription Concept. See also OPC UA Client/Server vs. PubSub for more details.

This alternative mechanism supports features like one to many communication or deterministic real-time communication that is not possible with the client/server subscription.

The client/server subscription is a one to one communication that provides dynamic configurable subset of information of interest for the one client that created the subscription.

In a PubSub environment, the publishers are configured to send data and events independent of the number of subscribers. A Publisher sends a message with data or events once to the network and the infrastructure like network switches and message brokers are responsible to distribute the messages to the interested Subscribers.

Since the communication is planned, a cyclic and deterministic real-time communication is possible if all involved components like data source and network fulfill real-time requirements.

The PubSub communication model is further described in OPC UA PubSub Messaging Concept.

PubSub Protocol Binding

The PubSub communication model defines different message mappings and different transport protocol mappings.

The message mapping defines the content of the message payload with the encoded data and necessary OPC UA PubSub headers.

  • UADP message mapping - defines OPC UA binary encoded messages with headers defined for UADP (UA Datagram Protocol)
  • JSON message mapping - defines JSON encoded messages with optional headers in JSON encoding

The transport protocol mappings define the used transport protocol and the corresponding transport protocol headers

  • OPC UA UDP is a simple UDP (User Datagram Protocol) based protocol that is used to transport UADP messages
  • OPC UA Ethernet is a simple Ethernet based protocol using EtherType B62C that is used to transport UADP messages as payload of the Ethernet II frame without IP or UDP headers.
  • MQTT (Message Queue Telemetry Transport) is typically used with a message broker that relays messages (UADP or JSON) between applications that cannot communicate directly.
  • AMQP (Advanced Message Queuing Protocol) is also a protocol that is used to communicate with a message broker

OPC UA Security

OPC UA security affects different building blocks of the OPC UA Unified Architecture.

On the protocol level, OPC UA defines application authentication, message signing and message encryption.

On Service level, OPC UA defines User Authentication.

The role based User Authorization and permission handling down to OPC UA node level affects the information model level.

See also Discovery and Security Configuration for more details.

In addition, OPC UA provides audit mechanisms to log interaction with an OPC UA server that either has security impact (connect, disconnect, failed connects with a server) or that influences the system with OPC UA Write or Call Services.

OPC UA Client/Server vs. PubSub

The client/server Services provide full access to all information in an OPC UA address space.

An OPC UA information model consist of a type system, instances of objects, variables and methods and the relations between objects. The information model contains semantic information that changes infrequently or never. Such semantic are type systems or properties of variables describing the variable value like a unit of a value. This kind of information is exchanged with Browse and Read at the time the receiving application needs this information.

The information model contains also live data that is frequently changing or is updated by external applications. Ad-hoc access to this is done with Read and Write.

Ad-hoc access to semantic, Read and Write access to Data or the execution of Methods (Call) requires a request response pattern that is only provided by client / server.

clientserver_vs_pubsub.png
Features covered by Client/Server and by PubSub

Changing data or events can be sent as notifications to interested applications. Such data and event notifications can be exchanged using the OPC UA Client/Server Subscription Concept.

Data and event notifications can also be exchanged using the OPC UA PubSub Messaging Concept.

Client/server subscriptions are more flexible for the receiving application.

PubSub messaging is needed if many receivers are interested in the same information, if the load on the sending application should be limited or if special timing requirements exist.

The next chapter describes the Address Space Concepts.