®

F O U N D A T I O N
OPC Unified Architecture

Release Candidate Specification

Part 1: Concepts

Version 1.00

September 28, 2005

OPC Unified Architecture, Part 1 –2– Release Candidate 1.00

Specification Industry Standard Comments Send comments to

Type Specification : [email protected]

Title: OPC Unified Date: September 28, 2005

Architecture

Part 1 :Concepts

Version: Release Candidate 1.00 Software MS-Word

Source: OPC UA Part 1 - Concepts
RC1.00.doc

Author: OPC Foundation Status: Release Candidate

OPC Unified Architecture, Part 1 –3– Release Candidate 1.00

CONTENTS
Page

FOREWORD........................................................................................................................ 6
INTRODUCTION.................................................................................................................. 7
1 Scope............................................................................................................................ 8
2 Reference documents .................................................................................................... 8
3 Terms, definitions, and abbreviations ............................................................................. 8
3.1 OPC UA terms ...................................................................................................... 8
3.1.1 address space .......................................................................................... 8
3.1.2 alarm ........................................................................................................ 8
3.1.3 attribute .................................................................................................... 8
3.1.4 certificate .................................................................................................. 8
3.1.5 command .................................................................................................. 8
3.1.6 complex data ............................................................................................ 8
3.1.7 event ........................................................................................................ 8
3.1.8 information model ..................................................................................... 8
3.1.9 message ................................................................................................... 9
3.1.10 method ..................................................................................................... 9
3.1.11 monitored item .......................................................................................... 9
3.1.12 node ......................................................................................................... 9
3.1.13 node hierarchy .......................................................................................... 9
3.1.14 node type.................................................................................................. 9
3.1.15 notification ................................................................................................ 9
3.1.16 notification message ................................................................................. 9
3.1.17 notifier ...................................................................................................... 9
3.1.18 object ....................................................................................................... 9
3.1.19 object instance .......................................................................................... 9
3.1.20 object type ...............................................................................................10
3.1.21 profile ......................................................................................................10
3.1.22 program ...................................................................................................10
3.1.23 reference .................................................................................................10
3.1.24 reference type..........................................................................................10
3.1.25 root node .................................................................................................10
3.1.26 subscription .............................................................................................10
3.1.27 view .........................................................................................................10
3.2 Abbreviations and symbols ..................................................................................10
4 Structure of the OPC UA series.....................................................................................11
4.1 Specification Organization ...................................................................................11
4.2 Core Specification Parts ......................................................................................11
4.2.1 Part 1 – OPC UA Concepts ......................................................................11
4.2.2 Part 2 – OPC UA Security Model ..............................................................11
4.2.3 Part 3 – OPC UA Address Space Model....................................................11
4.2.4 Part 4 – OPC UA Services........................................................................11
4.2.5 Part 5 – OPC UA Information Model .........................................................12
4.2.6 Part 6 – OPC UA Service Mappings ..........................................................12
4.2.7 Part 7 – OPC UA Profiles .........................................................................12
4.3 Access Type Specification Parts ..........................................................................12
4.3.1 Part 8 – OPC UA Data Access ..................................................................12
OPC Unified Architecture, Part 1 –4– Release Candidate 1.00

4.3.2 Part 9 – OPC UA Alarms and Events ........................................................12

4.3.3 Part 10 – OPC UA Commands ..................................................................12
4.3.4 Part 11 – OPC UA Historical Data Access.................................................12
4.3.5 Part 12 – OPC UA Batch ..........................................................................12
4.3.6 Part 13 – OPC UA Data Exchange ............................................................12
5 Overview ......................................................................................................................12
5.1 Design goals .......................................................................................................12
5.2 Integrated models and services............................................................................13
5.2.1 Security model .........................................................................................13
5.2.2 Integrated address space model ...............................................................15
5.2.3 Integrated object model ............................................................................15
5.2.4 Integrated services...................................................................................16
5.3 Sessions .............................................................................................................16
5.4 Use of the underlying communications layers .......................................................16
5.5 Redundancy ........................................................................................................17
5.5.1 Redundant server support ........................................................................17
5.5.2 Redundant client support..........................................................................18
6 Systems concepts.........................................................................................................18
6.1 Overview .............................................................................................................18
6.2 OPC UA clients....................................................................................................19
6.3 OPC UA servers ..................................................................................................19
6.3.1 Real objects .............................................................................................20
6.3.2 OPC client ...............................................................................................20
6.3.3 OPC UA server application .......................................................................20
6.3.4 OPC UA address space............................................................................20
6.3.5 Publisher/subscriber entities.....................................................................21
6.3.6 OPC UA Service Interface ........................................................................21
6.3.7 OPC UA Server Messaging ......................................................................22
6.3.8 Server to server interactions.....................................................................22
7 Service sets .................................................................................................................23
7.1 General ...............................................................................................................23
7.2 Server service set ................................................................................................23
7.3 Node management service set .............................................................................23
7.4 View service set ..................................................................................................23
7.5 Attribute service set .............................................................................................24
7.6 Monitored item service set ...................................................................................24
7.7 Subscription Service Set ......................................................................................25
7.8 Command service set ..........................................................................................25
OPC Unified Architecture, Part 1 –5– Release Candidate 1.00

FIGURES
Figure 1 – OPC UA Specification Organization ....................................................................11
Figure 2 – OPC UA Security Architecture ............................................................................14
Figure 3 – OPC UA System Architecture..............................................................................18
Figure 4 – OPC UA Client Architecture ................................................................................19
Figure 5 – OPC UA Server Architecture ...............................................................................20
Figure 6 – Interactions between servers ..............................................................................22
Figure 7 – Chained Server Example ....................................................................................23
OPC Unified Architecture, Part 1 –6– Release Candidate 1.00

OPC FOUNDATION
____________

UNIFIED ARCHITECTURE –

FOREWORD

This specification is the specification for developers of OPC UA clients and servers. The specification is a result of
an analysis and design process to develop a standard interface to facilitate the development of servers and clients
by multiple vendors that shall inter-operate seamlessly together.

TRADEMARKS

Most computer and software brand names have trademarks or registered trademarks. The individual trademarks
have not been listed here.

NON-EXCLUSIVE LICENSE AGREEMENT

The OPC Foundation, a non-profit corporation (the “OPC Foundation”), has defined a set of standard objects,
interfaces and behaviors associated with the objects intended to promote interoperability between
automation/control applications, field systems/devices, and business/office applications in the process control
industry.

The OPC specifications, sample software that demonstrates the implementation of the specifications, standard
interface components deliverables and related documentation (collectively, the “OPC Materials”), form a set of
standard objects, interfaces and behavior that are based on the technology being used in the automation
marketplace, and includes the use of Microsoft Technology as well providing interoperability to non Microsoft
platforms. The technology defines standard objects, methods, and properties for servers of real-time information
like distributed process systems, programmable logic controllers, smart field devices and analyzers in order to
communicate the information that such servers contain to standard compliant technologies enabled devices (e.g.,
servers, applications, etc.).

The OPC Foundation will grant to you (the “User”), whether an individual or legal entity, a license to use, and
provide User with a copy of, the current version of the OPC Materials so long as User abides by the terms
contained in this Non-Exclusive License Agreement (“Agreement”). If User does not agree to the terms and
conditions contained in this Agreement, the OPC Materials may not be used, and all copies (in all formats) of such
materials in User’s possession must either be destroyed or returned to the OPC Foundation. By using the OPC
Materials, User (including any employees and agents of User) agrees to be bound by the terms of this Agreement.

LICENSE GRANT:

Subject to the terms and conditions of this Agreement, the OPC Foundation hereby grants to User a non-exclusive,
royalty-free, limited license to use, copy, display and distribute the OPC Materials in order to make, use, sell or
otherwise distribute any products and/or product literature that are compliant with the standards included in the
OPC Materials.

All copies of the OPC Materials made and/or distributed by User must include all copyright and other proprietary
rights notices include on or in the copy of such materials provided to User by the OPC Foundation.

The OPC Foundation shall retain all right, title and interest (including, without limitation, the copyrights) in the OPC
Materials, subject to the limited license granted to User under this Agreement.

WARRANTY AND LIABILITY DISCLAIMERS:

User acknowledges that the OPC Foundation has provided the OPC Materials for informational purposes only in
order to help User understand Microsoft’s OLE/COM technology. THE OPC MATERIALS ARE PROVIDED “AS IS”
WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
WARRANTIES OF PERFORMANCE, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-
INFRINGEMENT. USER BEARS ALL RISK RELATING TO QUALITY, DESIGN, USE AND PERFORMANCE OF THE
OPC MATERIALS. The OPC Foundation and its members do not warrant that the OPC Materials, their design or
their use will meet User’s requirements, operate without interruption or be error free.
OPC Unified Architecture, Part 1 –7– Release Candidate 1.00

IN NO EVENT SHALL THE OPC FOUNDATION, ITS MEMBERS, OR ANY THIRD PARTY BE LIABLE FOR ANY
COSTS, EXPENSES, LOSSES, DAMAGES (INCLUDING, BUT NOT LIMITED TO, DIRECT, INDIRECT,
CONSEQUENTIAL, INCIDENTAL, SPECIAL OR PUNITIVE DAMAGES) OR INJURIES INCURRED BY USER OR
ANY THIRD PARTY AS A RESULT OF THIS AGREEMENT OR ANY USE OF THE OPC MATERIALS.

GENERAL PROVISIONS:

This Agreement and User’s license to the OPC Materials shall be terminated (a) by User ceasing all use of the
OPC Materials, (b) by User obtaining a superseding version of the OPC Materials, or (c) by the OPC Foundation, at
its option, if User commits a material breach hereof. Upon any termination of this Agreement, User shall
immediately cease all use of the OPC Materials, destroy all copies thereof then in its possession and take such
other actions as the OPC Foundation may reasonably request to ensure that no copies of the OPC Materials
licensed under this Agreement remain in its possession.

User shall not export or re-export the OPC Materials or any product produced directly by the use thereof to any
person or destination that is not authorized to receive them under the export control laws and regulations of the
United States.

The Software and Documentation are provided with Restricted Rights. Use, duplication or disclosure by the U.S.
government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b)
subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or
(c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as
applicable. Contractor / manufacturer are the OPC Foundation,. 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ,
85260-1830

Should any provision of this Agreement be held to be void, invalid, unenforceable or illegal by a court, the validity
and enforceability of the other provisions shall not be affected thereby.

This Agreement shall be governed by and construed under the laws of the State of Minnesota, excluding its choice
or law rules.

This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior
understanding or agreement (oral or written) relating to, the OPC Materials.

INTRODUCTION

This specification defines the address space model and the services that operate on the address model for OPC
Unified Architecture (UA) servers. The services are mapped onto communications technologies in the Annexes.
OPC Unified Architecture, Part 1 –8– Release Candidate 1.00

1 Scope

This specification presents the OPC Unified Architecture concepts. Included are the OPC UA
system concepts, OPC UA object model, and the OPC UA address space structure.

2 Reference documents

It is assumed that the reader is familiar with Web Services. Information on Web Services can
be found at the W3C web site.

3 Terms, definitions, and abbreviations

For the purposes of this specification, the following definitions apply

3.1 OPC UA terms

3.1.1 address space

The collection of information that an OPC server makes visible to its clients.

3.1.2 alarm
A type of event that typically requires acknowledgement. See Part 9 for a description of
alarms.

3.1.3 attribute
A primitive characteristic of a node. All attributes are defined by OPC UA, and may not be
defined by clients or servers. Attributes are the only elements in the address space permitted
to have data values.

3.1.4 certificate
A digitally signed data structure that describes the capabilities of a client or server.

3.1.5 command
An executable component of an object.

3.1.6 complex data

Data that is composed of elements or more than one primitive data type, such as a structure.

3.1.7 event
A generic term used to describe an occurrence of some significance within a system or
system component.

3.1.8 information model

An organizational framework that defines, characterizes, and relates information resources of
a given system or set of systems. The core address space model is designed to support the
representation of information models in the address space.
OPC Unified Architecture, Part 1 –9– Release Candidate 1.00

3.1.9 message
The data unit conveyed between client and server that represents a specific service request
or response.

3.1.10 method
A callable software function.

3.1.11 monitored item

A client-defined entity in the server used to monitor attributes or notifiiers for new
values/event occurrences and generate notifications for them.

3.1.12 node
The fundamental component of an address space.

3.1.13 node hierarchy

A set of related nodes that form a tree structure in the address space. Any combination of
Hierarchical references can be used to construct node hierarchies.

3.1.14 node type

The type of a node in an address space. Node types define the metadata for the components
of the OPC UA Object Model . They also define constructs used to organize the address
space, such as branches and views.

3.1.15 notification
The generic term for data that announces the detection of an event or of a changed attribute
value. Notifications are sent in notification messages.

3.1.16 notification message

A message published from a subscription that contains one or more notifications.

3.1.17 notifier
A node that detects event/alarm occurrences. Monitored items monitor notifiers and generate
notications for the event/alarm occurrences that they detect.

3.1.18 object
A node that represents a physical or abstract element of a system. Objects are modeled
using the OPC UA Object Model. Systems, subsystems, devices are examples of objects.
Objects may be defined as an instance of an object type.

3.1.19 object instance

A synonym for object. Not all objects are defined by object types.
OPC Unified Architecture, Part 1 – 10 – Release Candidate 1.00

3.1.20 object type

A node that represents the type definition for an object instance.

3.1.21 profile
A specific set of capabilities defined in Part 7 of this multi-part specification to which a server
may claim conformance. Each server may claim conformance to more than one profile.

3.1.22 program
An executable object that immediately returns a response when invoked to indicate that
execution has started, and then returns intermediate and final results through subscriptions
identified by the client during invocation.

3.1.23 reference
An explicit relationship (a named pointer) from one node to another. The node that contains
the reference is the source node, and the referenced node is the target node. All references
are defined by reference types.

3.1.24 reference type

A node that represents the type definition of a reference. The reference type specifies the
semantics of a reference. The name of a reference type identifies how source nodes are
related to target nodes, and generally reflect an operation between the two, such as “A
Contains B”.

3.1.25 root node

The beginning or top node of a node hierarchy. The root node of the OPC UA address space
is defined in Part 2 of this multi-part specification.

3.1.26 subscription
A client-defined endpoint in the server used to return notifications to the client. generic term
that describes a set of nodes selected by the client (1) that the server periodically monitors for
the existence of some condition, and (2) for which the server sends notifications to the client
when the condition is detected.

3.1.27 view
A specific subset of the address space that is of interest to the client.

3.2 Abbreviations and symbols

A&E Alarms and Events
API Application Programming Interface
COM Component Object Model
DA Data Access
DCOM Distributed COM
DX Data Exchange
HDA Historical Data Access
PLC Programmable Logic Controller
SOAP Simple Object Access Protocol
UA Unified Architecture
UML Unified Modeling Language
WSDL Web Services Definition Language
OPC Unified Architecture, Part 1 – 11 – Release Candidate 1.00

XML Extensible Markup Language

4 Structure of the OPC UA series

4.1 Specification Organization

This specification is organized as a multi-part specification, as illustrated in Figure 1.

OPC UA Multi-Part Specification

Core Specification Parts Access Type Specification Parts

Part 1 - Concepts Part 8 – Data Access

Part 2 - Security Model Part 9 – Alarms and Events

Part 3 - Address Space Model Part 10 - Commands

Part 4 – Services Part 11 – Historical Data

A
Part 5 – Information Model Part 12 – Batch

Part 6 – Service Mappings Part 13 – Data Exchange

Part 7 – Profiles

Figure 1 – OPC UA Specification Organization

The first seven parts specify the core capabilities of OPC UA. These core capabilities define
the structure of the OPC address space and the services that operate on it. Parts 8 through
13 apply these core capabilities to specific types of access previously addressed by separate
OPC specifications, such as Data Access (DA), Alarms and Events (A&E), and Historical Data
Access (HDA).

Readers are encouraged to read Parts 1 and 3 of the core specifications capabilities prior to
reading Parts 8 through 13. For example, a reader interested in UA Data Access should read
Parts 1, 3, and 8. References in Part 8 may direct the reader to other parts of this
specification.

4.2 Core Specification Parts

4.2.1 Part 1 – OPC UA Concepts

Part 1 of the OPC Unified Architecture multi-part specification describes the concepts
applicable to OPC UA servers and clients.

4.2.2 Part 2 – OPC UA Security Model

Part 2 of the OPC Unified Architecture multi-part specification describes the security model for
securing interactions between the client and the server.

4.2.3 Part 3 – OPC UA Address Space Model

Part 3 of the OPC Unified Architecture multi-part specification describes the contents and
structure of the server address space.

4.2.4 Part 4 – OPC UA Services

Part 4 of the OPC Unified Architecture multi-part specification specifies the services provided
by the OPC server and the callback services provided by OPC clients.
OPC Unified Architecture, Part 1 – 12 – Release Candidate 1.00

4.2.5 Part 5 – OPC UA Information Model

Part 5 of the OPC Unified Architecture multi-part specification specifies the standard types
and their interrelationships defined for OPC UA servers.

4.2.6 Part 6 – OPC UA Service Mappings

Part 6 of the OPC Unified Architecture multi-part specification specifies the OPC UA WSDL
and the OPC UA Application Programming Interfaces. It also defines the binary encoding of
OPC UA service parameters.

4.2.7 Part 7 – OPC UA Profiles

Part 7 of the OPC Unified Architecture multi-part specification specifies the profiles that define
different classes of OPC servers based on their capabilities.

4.3 Access Type Specification Parts

4.3.1 Part 8 – OPC UA Data Access

Part 8 of the OPC Unified Architecture multi-part specification specifies the use of OPC UA for
data access.

4.3.2 Part 9 – OPC UA Alarms and Events

Part 9 of the OPC Unified Architecture multi-part specification specifies use of OPC UA
support for access to alarms and events.

4.3.3 Part 10 – OPC UA Commands

Part 10 of the OPC Unified Architecture multi-part specification specifies use of OPC UA
support for access to commands.

4.3.4 Part 11 – OPC UA Historical Data Access

Part 11 of the OPC Unified Architecture multi-part specification specifies use of OPC UA
support for historical data access.

4.3.5 Part 12 – OPC UA Batch

Part 12 of the OPC Unified Architecture multi-part specification specifies use of OPC UA to
support batch operations.

4.3.6 Part 13 – OPC UA Data Exchange

Part 13 of the OPC Unified Architecture multi-part specification specifies use of OPC UA to
support data exchange between servers.

5 Overview

5.1 Design goals

OPC UA is designed as the migration path for OPC servers that are based on Microsoft
DCOM technology. OPC was originally organized to solve the problem of creating server
applications that would make data collected from the field available to client applications
running on Microsoft platforms through a common application programming interface (API).

The introduction of the Microsoft .NET framework provided a software environment that
supports the migration from DCOM to a service-oriented architecture. The architecture
OPC Unified Architecture, Part 1 – 13 – Release Candidate 1.00

provides for the use of platform- and protocol-independent messages. OPC UA is designed to
provide a migration path for OPC DCOM servers to this architecture.

OPC UA also is designed to integrate the data models and services defined for DCOM OPC
servers. OPC DA servers provide access to plant floor data, while OPC A&E servers allow
clients to receive event/alarm notifications. Not only do these servers have separate and
unrelated address spaces and naming schemes, they also have their own services.

OPC UA provides a consistent, integrated address space and service model. This allows a
single OPC UA server to integrate plant floor data, alarms and events, and history into its
address space, and to provide access to them using an integrated set of services.

OPC UA also is designed to allow servers to provide clients with type definitions for the
objects accessed from the address space. This allows standard information models to be
used to describe the contents of the address space.

OPC UA also provides for consistent application of quality codes. Quality codes are used by
servers to indicate how good data values are. They are generally assigned based on factors
associated with the data acquisition. OPC UA defines the criteria for assigning quality codes
in a consistent manner.

Finally, OPC is designed to provide robustness of published data. A major feature of all OPC
servers is to publish data and event notifications. OPC UA provides mechanisms for clients to
quickly detect and recover from communication failures associated with these transfers,
without having to wait for long timeouts provided by the underlying protocols.

OPC UA is designed to support a wide range of servers, from plant floor PLCs to enterprise
servers. These servers are characterized by a large variance in their size, performance,
execution platforms, and functional capabilities. Therefore, OPC UA defines a comprehensive
set of capabilities. Servers may elect to implement a subset of these capabilities. To promote
interoperability, OPC UA defines standard subsets, referred to as profiles, to which servers
may claim conformance. Clients are able to discover the profiles of a server, and tailor their
interactions with that server based on the profiles. Profiles are defined in Part 7 of this multi-
part specification.

5.2 Integrated models and services

5.2.1 Security model

OPC UA security is concerned with the authentication of clients and servers, the integrity and
confidentiality of their communications, and the verifiability of claims of functionality. It does
not specify under which circumstances the various security mechanisms are required. That
specification is crucial, but it is made by the designers of the system at a given site and may
be specified by other standards.

Rather, OPC UA provides a security model, defined in Part 2 of this multi-part specification, in
which security measures can be selected and configured to meet the security needs of a
given installation. This model includes standard security mechanisms and parameters. In
some cases, the mechanism for exchanging security parameters is defined, but how the
applications use these parameters is not. This framework also defines a minimum set of
security profiles that all UA servers must support, even though they may not be used in all
installations. Security profiles are defined in Part 7 of this multi-part specification.

OPC UA security is designed to be complementary to the security infrastructure provided by

most web service capable platforms. It is based on the three level architecture shown in
Figure 2. The three levels are user security, application security and transport security.
OPC Unified Architecture, Part 1 – 14 – Release Candidate 1.00

Client Platform Server Platform Authorization

and Access
User User security token controls Server
Client Application Server Application
security Objects

Authentication of
AP client, server and
security OPC UA Comms OPC UA Comms
messages

Transport Encryption
security Platform Comms Platform Comms

Figure 2 – OPC UA Security Architecture

OPC UA user level security is incorporated into session establishment, as described in Part 4
of this multi-part specification. The client passes an encrypted security token to the server
application for the user. The supported formats for the security token are specified in Part 7.
The server uses this security token to authenticate the user and authorize subsequent
requests to access objects in the server. Authorization mechanisms, such as access control
lists, are not specified by the OPC UA specification. They are application and/or system
specific.

User level security also includes support for security audit trails through two mechanisms.
First, it provides for traceability between client and server audit logs. If the client writes an
audit log entry for an operation that includes a request that it sends to the server, it can
include the local identifier of the log entry in the request. If the server audits requests that it
receives, it can include the client’s entry id in its audit log entry. In this fashion, if a security
related problem is detected at the server, the associated client audit log entry can be located
and examined.

Alternatively, OPC UA also provides the capability for servers to generate event notifications
that report auditable events to clients capable of processing and logging them. See Part 9 for
a description of this capability.

Second, OPC UA also defines other standard security audit parameters that can be included
in audit logs. This promotes consistency across audit logs. Part 5 of this multipart
specification defines the data types for these parameters. Part 7 defines security profiles
which include the ability to write audit logs and use these parameters, including the client
audit record id.

OPC UA application level security is also part of session establishment and involves the
exchange of digitally signed certificates. OPC Foundation generated certificates identify the
client and the server software and the OPC UA profiles that they implement. They also
indicate the OPC UA certification level reached for each profile. The details of each profile
and the certificates are specified in Part 7 of this multi-part specification.

Certificates issued by other organizations may also be exchanged during session

establishment. These certificates describe additional server capabilities, such as support for a
specific information model. These organizations also may have their own certification
process.

Application level security uses a digitally signed session identifier that allows servers to
authenticate requests without having to include client security tokens and certificates in each
one. The session identifier is created by the server when the session is established, and it is
used in all subsequent requests. Session identifiers are signed to protect against
unauthorized use, and hence, to prevent unauthorized clients from submitting requests on the
OPC Unified Architecture, Part 1 – 15 – Release Candidate 1.00

session. Parts 4 and 6 of this multi-part specification specify the details of session identifiers
and their signatures.

When user and application level security is not adequate, transport level security can be used
to encrypt messages. Encryption is used to protect against disclosure of information and to
protect the integrity of information. Encryption capabilities are provided by the underlying
communications technology used to transport session messages. The supported encryption
algorithms and protocols are specified in Part 7 of this multi-part specification.

5.2.2 Integrated address space model

The set of objects and related information that the OPC UA server makes available to clients
is referred to as its address space. The OPC UA address space represents its contents as a
set of nodes interconnected by references.

Primitive characteristics of nodes are described by OPC-defined attributes. Attributes are the
only elements of a server that have data values. Data types that define attribute values may
be simple or complex.

Nodes in the address space are typed, based on their use and their meaning. Node types
define the metadata for the OPC UA address space. Part 3 of this multi-part specification
defines the OPC UA node types.

The base node type defines three attributes common to all nodes, the node identifier, the
node type, and the browse name used for display purposes in user interfaces. Each node
type inherits these attributes and may additionally define its own attributes.

To promote interoperability of clients and servers, the UA address space is structured

hierarchically with the top levels standardized for all servers. Although nodes in the address
space are all accessible via the hierarchy, they may have references to each other, allowing
the address space to represent an interrelated network of nodes. The structure of the
address space is defined in Part 3 of this multi-part specification.

OPC servers may subset the address space into views to simplify client access. The entire
address space is the default view. Views, like the address space, are always represented as a
hierarchy that can contain references between nodes. Views are visible to all clients, and
clients are able to browse views to determine their structure. Servers may define their own
views in the address space, or views may be created by the client using OPC UA services.

5.2.3 Integrated object model

The OPC UA Object Model provides a consistent, integrated set of node types for
representing objects in the address space. This model represents objects in terms of their
variables (data/properties), commands (methods and programs), notifiers (event reporters),
and their relationships with other objects. Part 3 of this multi-part specification describes this
model.

Notifications are used to report data changes or alarm/event occurrences within the server or
underlying system. Clients subscribe to data change notifications by subscribing to variables
or to attributes. Examples of data changes include changes to variable and attribute values,
changes in program execution state, and state changes associated with the server itself.

Clients subscribe to alarm/event notifications by subscribing to notifiers. Notifiers are system

components that detect alarm and event occurrences. Filters are defined for defining
subscription criteria, such as deadband or alarm category, when subscribing to variables and
notifiers.

Part 4 of this multi-part specification defines the services that clients use to subscribe to
notifications, while Part 8 – Data Access and Part 9 – Alarms and Events, define the different
OPC Unified Architecture, Part 1 – 16 – Release Candidate 1.00

types of notifications to which clients can subscribe and the filters used to define subscription
criteria.

The OPC UA object model allows servers to provide type definitions for objects and their
components. Type definitions may be subclassed. They also may be standardized or they
may be system-specific. Each type is identified by the organization responsible for its
definition. OPC UA defines a set of top-level types, from which others can be derived.

This model allows plant floor data, alarms and events, and history data to be integrated into a
single OPC UA server. For example, OPC UA servers are able to represent a temperature
transmitter as an object that is composed of a temperature value, a set of alarm parameters,
and a corresponding set of alarm limits.

5.2.4 Integrated services

The interface between OPC UA clients and servers are modeled as a set of abstract services.
These services are organized into logical groupings called service sets. Service sets are
discussed in Clause 7 and specified in Part 4 of this multi-part specification.

OPC UA services provide two capabilities to clients. They allow clients to issue requests to
servers and receive responses from them. They also allow clients to subscribe to servers for
notifications. Notifications are used by the server to report occurrences such as alarms, data
value changes, tracking events, simple events, and program execution results.

Service requests, responses, and event notifications are conveyed between clients and
servers through the exchange of messages. OPC UA messages are defined in WSDL in Part
6 of this multi-part specification.

The use of WSDL to define messages provides for platform and protocol independence,
allowing OPC interoperability across Microsoft and non-Microsoft platforms using a variety of
underlying protocols. In addition to defining the WSDL, Part 6 also defines standard APIs
generated from it, including the C# API for Microsoft .NET platforms. These APIs are defined
as a convenience for the programmer and are not normative, since they do not directly affect
the conveyance of messages between the client and the server.

OPC UA messages may be conveyed as pure web services or they may be conveyed in binary
for efficiency purposes. Servers may provide either or both of these interface types as defined
by Part 7 of this multi-part specification. The binary interface uses a single web method
through which the binary encoding of service requests and responses is passed. Part 6
specifies the conveyance of OPC UA services.

5.3 Sessions

Sessions are defined as logical connections between clients and servers. Servers may limit
the number of concurrent sessions based on resource availability, licensing restrictions, or
other constraints. Each session is independent of the underlying communications protocols.
Failures of these protocols do not automatically cause the session to terminate. Sessions
terminate based on client or server request, or based on inactivity of the client. The inactivity
time interval is negotiated during session establishment.

5.4 Use of the underlying communications layers

OPC UA specification does not define the underlying communications protocols used by OPC
UA clients and servers. Instead, Part 7 – OPC UA Profiles identifies a set of standard
protocols for use by sessions and subscriptions. OPC UA clients and servers are configured
to use those most appropriate for their environment.
OPC Unified Architecture, Part 1 – 17 – Release Candidate 1.00

5.5 Redundancy

5.5.1 Redundant server support

OPC UA provides the ability for server vendors to construct redundant servers. A redundant
server may consist of two or more servers. The servers that comprise the redundant server
are referred to as a redundant set or as a redundant pair, depending on the number of servers
in the set.

To qualify as a redundant server, all servers in the redundant set must provide access to the
same objects or to a subset of those objects, and must use the same identifiers for them.
This allows clients to continue operation after a switchover and access the same objects using
the same identifiers.

All servers in the redundant set must also support the server redundancy objects defined in
Part 5 of this multi-part specification. These objects identify the servers in the redundant set,
provide runtime and diagnostic information related to redundancy operations, and allow for the
configuration of site-specific redundancy parameters.

In addition, all redundant servers support a backup mode. The backup mode defines the
server’s ability to rapidly switch-over. Values are hot, warm, and cold. The ability for a client
to configure the backup mode using OPC UA services depends on a number of factors,
including the ability of the underlying system to support multiple simultaneous servers.

Backup servers configured as hot or warm maintain subscriptions that are backups for those
defined in the active server. Those configured as hot enable sampling on all subscriptions,
while those configured as warm disable sampling. During switchover, sampling must be
enabled for warm servers. In both cases, publishing is disabled while the server is in backup
mode and must be enabled during switchover. The value cold indicates that the server is
operational, but has no subscriptions defined and is not accepting requests to create them.

Redundant servers are classified and profiled based on two redundancy capabilities. The first
defines how subscriptions are configured and synchronized across the servers in the
redundant set. The second defines how switch-over is accomplished.

Two variations on configuration and synchronization are specified, client-controlled and

server-controlled. Client-controlled configuration and synchronization relies on the client to
configure its subscriptions in the active server and in one or more backup servers. Each
server in the redundant set operates independently, and the client selects the server or
servers to be used as backup from information stored in the active server’s redundancy
objects. The client is responsible for configuring its subscriptions in the selected backups and
keeping their definitions synchronized.

Server-controlled configuration and synchronization provides for the automatic copying and
synchronization of client subscriptions across the servers in the redundant set. If a redundant
server supports this capability, the client establishes a session with an active server in the
redundant set and configures its subscriptions. That server is responsible for copying the
subscriptions to one or more backup servers in the redundant set and for keeping the
subscription definitions synchronized. During switchover, the backup is responsible for
enabling the subscriptions. A configuration setting in the server allows a client to disable the
automatic copying and synchronization of its subscriptions, thus allowing the server to operate
as a client-controlled server for that client.

The second redundancy capability defines how switchover is accomplished. Transparent

switchover is provided by the server without client involvement. In this case, when the active
server fails, the preferred backup assumes the role of the active server and begins using its
network address. How this is accomplished is vendor-specific. For hot backups, clients are
required to re-establish their sessions to continue operation only if the session they are using
terminates as a result of the server failure. Additional recovery activities required of the client
OPC Unified Architecture, Part 1 – 18 – Release Candidate 1.00

depend on the redundancy mode and the type of configuration control employed by the
server.

Non-transparent switchover, on the other hand, requires the client to know the address of the
preferred backup and establish a session with it. For faster switchovers, the client may have
already established the session before the failure of the active server. If client-controlled
configuration is used, the client may also choose to configure the subscriptions prior to the
failure.

5.5.2 Redundant client support

OPC UA servers, whether redundant or not, all support redundant clients. Redundant client
support is provided by three capabilities.

First, subscriptions that publish data/events exist independently of the session between the
client and the server. This means that subscriptions created by a client are not terminated
immediately if a client terminates unexpectedly.

Second, servers maintain a list of active clients, to which redundant clients can subscribe.
When a redundant client is notified that its primary client has disconnected from the server,
the redundant client can assume the role of primary client.

Third, to support this failover, the address to which a subscription publishes subscription
data/events can be reconfigured by the client. Therefore, when the primary client terminates,
a secondary client can reconfigure the subscription to publish to the secondary client.

6 Systems concepts

6.1 Overview

The OPC UA systems architecture models OPC UA clients and servers as interacting
partners. Each system may contain multiple clients and servers. Each client may interact
concurrently with one or more servers, and each server may interact concurrently with one or
more clients. Servers may embed a client component to allow it to interact with other servers
as described in Clause 6.3.8.

OPC UA clients and servers are described in the clauses that follow. Figure 3 illustrates the
architecture that includes a server with an embedded client.

Client Client
requests requests
OPC
OPC UA OPC
UA Server server Server UA
client responses with responses server
embedded
client
Published Published
notifications notifications

Figure 3 – OPC UA System Architecture

OPC Unified Architecture, Part 1 – 19 – Release Candidate 1.00

6.2 OPC UA clients

The OPC UA client architecture models the client endpoint of client/server interactions.
Figure 4 illustrates the major elements of an OPC UA client and how they relate to each other.

OPC UA Client
Client-Application
Requests to Delivery of Requests to Delivery of
send service received service send publishing received
requests responses requests notifications

OPC UA Client Service Interface

OPC UA Client
Messaging Req Msg Rsp Msg Publ Msg Notif Msg

To OPC From To From

UA OPC UA OPC UA OPC UA
server server subscription subscription

Figure 4 – OPC UA Client Architecture

The Client Application is the code that implements the function of the client. It uses the OPC
UA Client Service Interface to send and receive OPC UA service requests and responses to
the OPC UA server. The services defined for OPC UA are described in Clause 7, and
specified in Part 4 of this multi-part specification. OPC UA defined client APIs for these
services are specified in Part 6 for selected programming languages. These APIs are not
normative since they are not directly involved in the conveyance of messages.

OPC UA Client Messaging converts OPC UA Client Service Interface calls into messages and
sends them through the underlying communications entity to the server at the request of the
client application.

OPC UA Client Messaging also receives response and notification messages from the
underlying communications entity and delivers them to the client application through the OPC
UA Client Service Interface.

6.3 OPC UA servers

The OPC UA server architecture models the server endpoint of client/server interactions.
Figure 5 illustrates the major elements of the OPC UA server and how they relate to each
other.
OPC Unified Architecture, Part 1 – 20 – Release Candidate 1.00

OPC UA Server

OPC UA Server Application

Real
Objects OPC Client

OPC UA Address Space

Monitored
Node Item
Node Node

Node Node
View
Node Node
Node Subscription
Subscription
Node Subscription

OPC UA Server
Service Interface

OPC UA Server
Messaging Req Msg Rsp Msg Publ Msg Notif Msg

From To From To
OPC UA OPC UA OPC UA OPC UA
client client client client

Figure 5 – OPC UA Server Architecture

6.3.1 Real objects

Real objects are physical or software objects that are accessible by the OPC server
application or that it maintains internally. Examples include physical devices and diagnostics
counters.

6.3.2 OPC client

OPC UA servers may have embedded OPC clients that allow them to access other OPC
servers. These clients may access the address space directly as shown to exchange data
with other servers. The remote servers may be any type of OPC servers, including OPC UA
and OPC DCOM servers. This allows OPC UA servers to front-end other OPC servers.

6.3.3 OPC UA server application

The OPC UA server application is the code that implements the function of the server. It
represents real objects and objects accessed through its OPC clients in its address space. It
uses the OPC UA Server API to send and receive OPC UA messages from OPC UA clients.

6.3.4 OPC UA address space

6.3.4.1 Address space nodes

The address space is modeled as a set of nodes accessible by clients using OPC services
(interfaces and methods). Nodes in the address space are used to represent real objects,
their definitions, and their references to each other. Each of the previous OPC specifications
defined its own address space model and its own set of services. OPC UA unifies the
previous models into a single integrated address space.
OPC Unified Architecture, Part 1 – 21 – Release Candidate 1.00

6.3.4.2 Address space organization

All OPC UA address spaces are organized hierarchically. This specification also defines a
standard organizational framework for the address space required of all UA servers. This
framework is defined in Part 3 of this multi-part specification.

Servers are free to organize their nodes within this framework as they choose. The use of
references between nodes permits servers to organize the address space into a full mesh
network of nodes.

6.3.4.3 Address space views

A view is a subset of the address space. Views are used to restrict the nodes that the server
makes visible to the client, thus restricting the size of the address space for the service
requests submitted by the client. The default view is the entire address space. Servers may
optionally define other views, or allow clients to create views. The creation of views is
discussed in Clause 7.4. Parts 8, 9, and 10 define the creation of standard views for data
access, alarms and events, and historical data access.

6.3.4.4 Support for information models

The OPC UA address space is designed to support information models. Support for
information models is provided through:

a) node references that allow objects in the address space to be related to each other.
b) object type definition nodes that provide semantic information for real objects (type
definitions).
c) object type nodes hierarchies to support subclassing of type definitions.
d) data type definition nodes that allow industry specific data types to be used.
e) OPC UA companion standards that permit industry groups to define how their specific
information models are to be represented in OPC UA server address spaces.

6.3.5 Publisher/subscriber entities

6.3.5.1 Monitored items

Monitored items are entities in the server created by the client that monitor address space
nodes and their real-world counterparts. When they detect a data change or an event/alarm
occurrence, they generate a notification that is transferred to the client by a subscription.

6.3.5.2 Subscriptions

A subscription is an endpoint in the server that publishes notifications to clients. Clients

control the rate at which publishing occurs by using publish messages.

6.3.6 OPC UA Service Interface

6.3.6.1 General

The services defined for OPC UA are described in Clause 7, and specified in Part 4 of this
multi-part specification. OPC UA defined client APIs for these services are specified in Part 5.

6.3.6.2 Request/response services

Request/response services are services invoked by the client through the OPC UA Service
Interface to perform a specific task on one or more nodes in the address space and to return a
response.
OPC Unified Architecture, Part 1 – 22 – Release Candidate 1.00

6.3.6.3 Publisher services

Publisher services are services invoked through the OPC UA Service Interface for the
purpose of periodically sending notifications to clients. Notifications include events, alarms,
data changes, and program outputs.

6.3.7 OPC UA Server Messaging

OPC UA Server Messaging receives messages from the underlying communications entity
and invokes the service interface to handle them. It also receives requests from server
components to send messages through the communications entity.

6.3.8 Server to server interactions

Server to server interactions are interactions in which one server acts as a client of another
server. Server to server interactions allow for the development of servers that:

a) exchange information with each other on a peer-to-peer basis,

b) are chained in a layered architecture of servers to provide:
1) aggregation of data from lower layer servers,
2) higher layer data constructs to clients, and/or
3) concentrator interfaces to clients for single points of access to multiple underlying
servers.

Figure 6 illustrates interactions between servers.

OPC
Client

Plant Floor Network

OPC Server OPC Server

server client
interface Interactions interface
between servers
client server
interface interface

Figure 6 – Interactions between servers

OPC Unified Architecture, Part 1 – 23 – Release Candidate 1.00

Figure 7 extends the previous example and illustrates the chaining of OPC UA servers
together for vertical access to data in an enterprise.

OPC OPC
Client Client
Enterprise Network
Enterprise
Semantic
OPC Layer
Server

OPC OPC
Client Client Process
Operations Network
Semantic
Layer
OPC OPC
Server Server

OPC OPC
Client Client Device
Plant Floor Network Semantic
Layer
OPC OPC
Server Server

Figure 7 – Chained Server Example

7 Service sets

7.1 General

OPC UA services are divided into service sets, each defining a logical grouping of services
used to access a particular aspect of the server. The service sets are described below. The
service sets and their services are specified in Part 4 of this multi-part specification.

7.2 Server service set

The server service set is used by clients to establish a session with the server. The session is
used to control various aspects of client access to objects in the server, such as security and
lifetimes of views.

The server service set also provides for the translation of codes, such as error codes, into
displayable text strings.

7.3 Node management service set

The node management service set allows clients to add, modify, and delete nodes in the
address space. These services are provided to provide a standard interface for the
configuration of servers.

7.4 View service set

The view service set is used to create, modify, and delete views, and to discover nodes in a
view. In addition to views created by clients using these services, servers may include their
own views in the address space.

Views are publicly defined subsets of the address space that, like the address space, are
always represented as a hierarchy with a root node and whose member nodes can contain
references between nodes. The entire address space is the default view, and therefore, the
view services are capable of operating on the entire address space.
OPC Unified Architecture, Part 1 – 24 – Release Candidate 1.00

Each client created view has a limited lifetime that is dependent on its use. Each view
remains in the address space as long as the client session used to create it is still open, or as
long as there are subscriptions defined for it. When neither is true, the server automatically
deletes the view.

The view service set allows clients to discover nodes in a view, either by browsing or by
querying. Browsing allows clients to navigate up and down the hierarchy, or to follow
references between nodes contained in the view. In this manner, browsing also allows client
to discover the structure of the view.

Querying allows clients to select a subset of the nodes in a view. The nodes selected from
the view by the query statement are referred to as a result set. The query response contains
the node identifier for the result set. The node identifier allows result sets to be browsed by
the client to determine their contents. Result sets have a limited lifetime.

Servers may find it difficult to process queries that require access to runtime data, such as
device data, that involves resource intensive operations and/or significant delays. In these
cases, the server may find it necessary to reject the query. See Clause 6.3.4.3 for more
information on views.

7.5 Attribute service set

The attribute service set is used to read and write attribute values. Attributes are primitive
characteristics of nodes that are defined by OPC UA. They may not be defined by clients or
servers. Attributes are the only elements in the address space permitted to have data values.
A special attribute, the Value attribute is used to define the value of variables.

7.6 Monitored item service set

The monitored item service set is used by the client to create and maintain monitored items.
Monitored items monitor variables, attributes, and notifiers and generate notifications for them
when they detect certain conditions. They monitor variables for a change in value or quality,
attributes for a change in value, and notifiers for newly generated alarm and event reports.

Each monitored item identifies the item to monitor and the subscription to use to periodically
publish notifications to the client (see Clause 7.7). Each monitored item also specifies the rate
at which the item is to be monitored (sampled) and, for variables and notifiers, the filter
criteria used to determine when a notification is to be generated. Filter criteria for attributes
are specified by their attribute definitions in Part 5 of this multi-part specification.

The sample rate defined for a monitored item may be faster than the publishing rate of the
subscription. For this reason, the monitored item may be configured to either queue all
notifications or to queue only the latest notification for transfer by the subscription. In this
latter case, the queue size is one.

Monitored item services also define a monitoring mode. The monitoring mode is configured to
disable sampling and reporting, to enable sampling only, or to enable both sampling and
reporting. When sampling is enabled, the server samples the item. In addition, each sample
is evaluated to determine if a notification should be generated. If so, the notification is
queued. If reporting is enabled, the queue is made available to the subscription for transfer.

Finally, monitored items can be configured to trigger the reporting of other monitored items. In
this case, the monitoring mode of the items to be reporting is typically set to sampling only,
and when the triggering item generates a notification, any queued notifications of the items to
report are made available to the subscription for transfer.
OPC Unified Architecture, Part 1 – 25 – Release Candidate 1.00

7.7 Subscription Service Set

The subscription service set is used by the client to create and maintain subscriptions.
Subscriptions are entities that periodically publish notification messages for the monitored
items assigned to them (see Clause 7.6). The notification message contains a common
header followed by a series of notifications. The format of notifications is specific to the type
of item being monitored (i.e. variables, attributes, and notifiers).

Once created, the existence of a subscription is independent of the client’s session with the
server. This allows one client to create a subscription, and a second, possibly a redundant
client, to receive notification messages from it.

OPC UA also provides for client acknowledgment of alarms. See Part 9 of this multi-part
specification for the definition of alarm variables.

To protect against non-use by clients, subscriptions have a configured lifetime that clients
periodically renew. If any client fails to renew the lifetime, the lifetime expires and the
subscription is closed by the server. When a subscription is closed, all monitored items
assigned to the subscription are deleted.

Subscriptions include features that support detection and recovery of lost messages. Each
notification message contains a sequence number that allows clients to detect missed
messages. When there are no notifications to send within the keep-alive time interval, the
server sends a keep-alive message that contains the sequence number of the last notification
message sent. If a client fails to receive a message after the keep-alive interval has expired,
or if it determines that it has missed a message, it can request the server to resend one or
more messages.

7.8 Command service set

The command service set is used to invoke the execution of tasks, called commands, for an
object. Two types of commands are defined, the method and the program. Methods are
invoked by calling them, and may return results in their responses. Programs are invoked by
starting them, and may return results through subscriptions as they execute.

In addition, programs may be stateful, allowing their execution to be controlled by the client
when they are running. Services are defined to suspend, resume, restart, terminate, and
abort programs. OPC UA specifies the behavior associated with these services using a
standard program state table defined in Part 10 of this multi-part specification.