OPC UA Client and Server Development (PDFDrive)

OPC UA SDKs .
NET Introduction
Develop OPC UA Clients and OPC UA Servers
with C# / VB.NET for .NET and .NET Standard
Introduction
Windows | Linux | Mac OS X | iOS

Document Control
Version Date Comment
1.0.0 07-DEC-2018 Initial version

1.0.6 23-MAR-2019 Updated for .NET Standard
Purpose and audience of document

Microsoft’s .NET Framework is an application development environment that supports multiple languages and
provides a large set of standard programming APIs. This document defines an Application Programming
Interface (API) for OPC UA Client and Server development based on the .NET programming model.
The OPC UA specification can be downloaded from the web site of the OPC Foundation. But only [UA Part 1]
(Overview and Concepts) is available to the public. All other parts can only be downloaded from OPC
Foundation members and may be used only as long as the user is an active OPC Foundation member. Because
of this fact the OPC UA SDK .NET API hides most of the OPC UA specifications to provide the possibility to
delevlop OPC UA Clients and OPC UA Servers in the .NET environment without the need to be an OPC
Foundation member. The API does support OPC Unified Architecture.
This document is intended as reference material for developers of OPC UA compliant Client and Server
applications. It is assumed that the reader is familiar with the Microsoft’s .NET Framework and the needs of
the Process Control industry.
Summary
This document gives a short overview of the functionality of the OPC UA SDKs .NET and OPC US SDKs .NET Standard
product family. The goal of this document is to give an introduction and can be used as base for your own implementations
Referenced OPC Documents
Documents
This document partly uses extracts taken from the OPC UA specifications to be able to give at least a short
introduction into the specifications. The specifications itself are available from:
http://www.opcfoundation.org/Default.aspx/01_about/UA.asp?MID=AboutOPC#Specifications
OPC Unified Architecture Textbook, written by Wolfgang Mahnke, Stefan-Helmut Leitner and Matthias Damm:
http://www.amazon.com/OPC-Unified-Architecture-Wolfgang-
Mahnke/dp/3540688986/ref=sr_1_1?ie=UTF8&s=books&qid=1209506074&sr=8-1
[UA Part 1] OPC UA Specification: Part 1 – Concepts
http://www.opcfoundation.org/UA/Part1/
[UA Part 2] OPC UA Specification: Part 2 – Security
[UA Part 3] OPC UA Specification: Part 3 – Address Space Model
[UA Part 4] OPC UA Specification: Part 4 – Services
[UA Part 5] OPC UA Specification: Part 5 – Information Model
[UA Part 6] OPC UA Specification: Part 6 – Mappings
[UA Part 7] OPC UA Specification: Part 7 – Profiles
[UA Part 8] OPC UA Specification: Part 8 – Data Access
[UA Part 9] OPC UA Specification: Part 9 – Alarm & Conditions
[UA Part 11] OPC UA Specification: Part 11 – Historical Access

[UA Part 13] OPC UA Specification: Part 13 – Aggregates

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 3 of 119
© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

Other Referenced Documents
SOAP Part 1: SOAP Version 1.2 Part 1: Messaging Framework
http://www.w3.org/TR/soap12-part1/
SOAP Part 2: SOAP Version 1.2 Part 2: Adjuncts
http://www.w3.org/TR/soap12-part2/
XML Encryption: XML Encryption Syntax and Processing
http://www.w3.org/TR/xmlenc-core/
XML Signature:: XML-Signature Syntax and Processing
http://www.w3.org/TR/xmldsig-core/
WS Security: SOAP Message Security 1.1
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
WS Addressing: Web Services Addressing (WS-Addressing)
http://www.w3.org/Submission/ws-addressing/
WS Trust: Web Services Trust Language (WS-Trust)
http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf
WS Secure Conversation: Web Services Secure Conversation Language (WS-SecureConversation)
http://specs.xmlsoap.org/ws/2005/02/sc/WS-SecureConversation.pdf
SSL/TLS: RFC 2246: The TLS Protocol Version 1.0
http://www.ietf.org/rfc/rfc2246.txt
X200 : ITU-T X.200 – Open Systems Interconnection – Basic Reference Model

http://www.itu.int/rec/T-REC-X.200-199407-I/en
:X509: X.509 Public Key Certificate Infrastructure
http://www.itu.int/rec/T-REC-X.509-200003-I/e
HTTP: RFC 2616: Hypertext Transfer Protocol - HTTP/1.1
HTTPS: RFC 2818: HTTP Over TLS
IS Glossary: Internet Security Glossary
NIST 800-12: Introduction to Computer Security
http://csrc.nist.gov/publications/nistpubs/800-12/
NIST 800-57: Part 3: Application-Specific Key Management Guidance
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_PART3_key-management_Dec2009.pdf
NERC CIP: CIP 002-1 through CIP 009-1, by North-American Electric Reliability Council
http://www.nerc.com/page.php?cid=2|20
IEC 62351: Data and Communications Security
http://www.iec.ch/heb/d_mdoc-e050507.htm

SPP-ICS: System Protection Profile – Industrial Control System, by Process Control Security Requirements Forum (PCSRF)
http://www.isd.mel.nist.gov/projects/processcontrol/SPP-ICSv1.0.pdf
SHA-1: Secure Hash Algorithm RFC
http://tools.ietf.org/html/rfc3174
PKI: Public Key Infrastructure article in Wikipedia
http://en.wikipedia.org/wiki/Public_key_infrastructure
X509 PKI: Internet X.509 Public Key Infrastructure
EEMUA : 2nd Edition EEMUA 191 - Alarm System - A guide to design, management and procurement
(Appendixes 6, 7, 8, 9).
http://www.eemua.co.uk/

T ABLE OF C ONTENTS
1 Overview .................................................................................................................................. 11
1.1 OPC Technology ........................................................................................................ 11
1.1.1 Classic OPC Specifications ........................................................................... 11
1.1.1.1 Data Access (DA) ......................................................................... 11
1.1.1.2 Alarms&Events (AE)....................................................................12
1.1.1.3 Historical Data Access (HDA) ..................................................... 13
1.1.2 OPC XML-DA Specification ........................................................................ 14
1.1.3 OPC .NET 4.0 (WCF) ................................................................................. 14
1.1.4 OPC Unified Architecture Specification ......................................................15
2 OPC UA SDKs .NET Product Line ......................................................................................... 16
2.1 .NET Standard based SDKs .......................................................................................17
2.1.1 OPC UA Client SDK .NET Standard ............................................................17
2.1.2 OPC UA Server SDK .NET Standard .......................................................... 18
2.2 .NET based SDKs ...................................................................................................... 19
2.2.1 OPC UA Client SDK .NET ........................................................................... 19
2.2.2 OPC UA Server SDK .NET .......................................................................... 20
2.2.3 OPC UA Client Gateway .NET ....................................................................21
3 Introduction ............................................................................................................................ 22
4 OPC UA Basics ........................................................................................................................ 24
4.1 Overview ................................................................................................................... 24
4.1.1 Specifications .............................................................................................. 24
4.1.2 Graphical Notation ..................................................................................... 25
4.1.2.1 Overview...................................................................................... 25
4.1.2.2 Simple Notation .......................................................................... 25
4.1.2.3 Extended Notation ...................................................................... 27
4.1.3 Terms, definitions and abbreviations ........................................................ 29
4.1.3.1 OPC UA........................................................................................ 29
4.1.3.2 OPC UA Security ......................................................................... 33
4.1.3.3 OPC UA Address Space .............................................................. 39
4.1.3.4 OPC UA Services ......................................................................... 41
4.1.3.5 OPC UA Information Model ....................................................... 43
4.1.3.6 OPC UA Mappings ...................................................................... 44
4.1.3.7 OPC UA Profiles .......................................................................... 46

4.1.3.8 OPC UA Data Access ................................................................... 48
4.1.3.9 OPC UA Alarms & Conditions .................................................... 50
4.1.3.10 OPC UA Programs ...................................................................... 52
4.1.3.11 OPC UA Historical Access ........................................................... 53
4.1.3.12 OPC UA Discovery ...................................................................... 56
4.1.3.13 OPC UA Aggregates .................................................................... 58
4.2 Security ...................................................................................................................... 63
4.2.1 Overview ..................................................................................................... 63
4.2.1.1 Environment ................................................................................ 63
4.2.1.2 Authentication ............................................................................. 64
4.2.1.3 Authorization............................................................................... 64
4.2.1.4 Confidentiality ............................................................................. 64
4.2.1.5 Integrity ....................................................................................... 64
4.2.1.6 Auditability .................................................................................. 64
4.2.1.7 Availability ................................................................................... 64
4.2.2 Security Architecture .................................................................................. 65
4.3 Address Space ........................................................................................................... 67
4.3.1 Node Model ................................................................................................ 67
4.3.1.1 General ........................................................................................ 67
4.3.1.2 NodeClasses ................................................................................ 68
4.3.1.3 Attributes ..................................................................................... 68
4.3.1.4 References ................................................................................... 68
4.3.2 Variables ..................................................................................................... 69
4.3.2.1 General ........................................................................................ 69
4.3.2.2 Properties .................................................................................... 69
4.3.2.3 DataVariables .............................................................................. 69
4.3.3 TypeDefinitionNodes .................................................................................. 69
4.3.3.1 General ........................................................................................ 69
4.3.3.2 Complex TypeDefinitionNodes and their InstanceDeclarations 71
4.3.3.3 Subtyping..................................................................................... 72
4.3.3.4 Instantiation of complex TypeDefinitionNodes ......................... 72
4.3.4 Event Model ................................................................................................ 73
4.3.4.1 General ........................................................................................ 73
4.3.4.2 EventTypes .................................................................................. 74
4.3.4.3 Event Categorization .................................................................. 74

4.3.5 Methods ...................................................................................................... 75
4.4 Services ..................................................................................................................... 76
4.4.1 Service Set Model ....................................................................................... 76
4.4.2 Request/response Service procedures ...................................................... 79
4.4.3 MonitoredItem Service Set .........................................................................80
4.4.3.1 MonitoredItem model .................................................................80
4.4.4 Subscription Service Set ............................................................................. 86
4.4.4.1 Subscription model ..................................................................... 86
4.5 Information Model .................................................................................................... 88
4.5.1 Nodes .......................................................................................................... 88
4.5.2 References ................................................................................................... 89
4.5.3 Standard AddressSpace .............................................................................. 89
4.5.4 Data Types ..................................................................................................90
4.6 Mappings .................................................................................................................. 91
4.7 Profiles ...................................................................................................................... 93
4.7.1 ConformanceUnit ....................................................................................... 94
4.7.2 Profiles ........................................................................................................ 94
4.7.3 Profile Categories ....................................................................................... 94
4.8 Data Access ............................................................................................................... 95
4.8.1 Model .......................................................................................................... 96
4.9 Alarms and Conditions ............................................................................................. 97
4.9.1 Conditions ................................................................................................... 97
4.9.2 Acknowledgeable Conditions ..................................................................... 99
4.9.3 Previous States of Conditions ................................................................... 101
4.9.4 Condition State Synchronization .............................................................. 101
4.9.5 Severity, Quality, and Comment .............................................................. 102
4.9.6 Dialogs ...................................................................................................... 102
4.9.7 Alarms ....................................................................................................... 102
4.9.8 Multiple Active States ............................................................................... 104
4.9.9 Condition Instances in the Address Space .............................................. 104
4.9.10 Alarm and Condition Auditing ................................................................. 105
4.9.11 Model ........................................................................................................ 106
4.9.11.1 Condition Model ....................................................................... 107
4.9.11.2 Dialog Model ............................................................................. 108
4.9.11.3 Acknowledgeable Condition Model ......................................... 109

4.9.11.4 Alarm model ............................................................................... 110
4.10 Programs ...................................................................................................................111
4.11 Historical Access ...................................................................................................... 112
4.12 Discovery .................................................................................................................. 113
4.13 Aggregates ............................................................................................................... 114
4.13.1 Aggregate Objects ..................................................................................... 114
4.13.1.1 General ....................................................................................... 114
4.13.1.2 AggregateFunctions Object ....................................................... 115
4.13.2 MonitoredItem AggregateFilters .............................................................. 117
4.13.2.1 MonitoredItem AggregateFilter Defaults ................................. 117
4.13.2.2 MonitoredItem Aggregates and Bounding Values ................... 118
4.13.3 Exposing Supported Functions and Capabilities...................................... 118

Disclaimer
© Technosoftware GmbH. All rights reserved. No part of this document may be altered, reproduced or
distributed in any form without the expressed written permission of Technosoftware GmbH.
This document was created strictly for information purposes. No guarantee, contractual specification or
condition shall be derived from this document unless agreed to in writing. Technosoftware GmbH reserves the
right to make changes in the products and services described in this document at any time without notice and
this document does not represent a commitment on the part of Technosoftware GmbH in the future.
While Technosoftware GmbH uses reasonable efforts to ensure that the information and materials contained in
this document are current and accurate, Technosoftware GmbH makes no representations or warranties as to
the accuracy, reliability or completeness of the information, text, graphics, or other items contained in the
document. Technosoftware GmbH expressly disclaims liability for any errors or omissions in the materials
contained in the document and would welcome feedback as to any possible errors or inaccuracies contained
herein.
Technosoftware GmbH shall not be liable for any special, indirect, incidental, or consequential damages,
including without limitation, lost revenues or lost profits, which may result from the use of these materials. All
offers are non-binding and without obligation unless agreed to in writing.
Trademark Notice
Microsoft, MSN, Windows and the Windows logo are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries. All other trademarks are the property of their
respective owners.

1 Overview
If your application requires access to the OPC technology, you have to decide which of the OPC Specifications
you want to support. The decision depends on many factors like the used OPC specifications supported by
third party products or the system architcture you want to use. Technosoftware GmbH is specialized in
software consulting and development services for technical and industrial applications based on OPC and the
founder of Technosoftware GmbH was involved in the design and development of many software products
with OPC connectivity with more than 15 years extensive knowledge about OPC.
The OPC Unified Architecture (UA) is THE next generation OPC standard that provides a cohesive, secure and
reliable cross platform framework for access to real time and historical data and events.
It's time to adapt this specification for use in your applications with keeping in mind that you may need to
support other OPC specifications as well. The Classic OPC specifications are widely used and it is important
that your application can support these specifications. We recommend that you design your application to use
the OPC Unified Architecture in the first place, with the option to have access to the Classic OPC Specifications
in the second place. A short overview of the mainly used Classic OPC Specifications should give you an
understanding of the requirements your application design have to fullfill.
1.1 OPC Technology

1.1.1 Classic OPC Specifications
The Classic OPC specifications are DCOM based specifications like OPC Data Access (DA), OPC Alarms&Events
(AE) and OPC Historical Access (HDA). Each of these specifications is a separate specification and several
more exists.
According to the different requirements within industrial applications, three major Classic OPC specifications
have been developed. Support of one or more of these specifications should be provided by most of the OPC
Client or OPC Server applications.
1.1.1.1 Data Access (DA)

An OPC DA Server allows OPC DA Clients to retrieve information about several objects: the server, the group
and the items.
The OPC server object maintains information about the server and acts as a container for OPC group
objects.
The OPC group object maintains information about itself and provides the mechanism for containing
and logically organizing OPC items.
The OPC items represent connections to data sources within the server.
The OPC DA Specification defines two read/write interfaces:
Synchronous
The client can perform a synchronous read from cache (simple and reasonably efficient). This may be
appropriate for fairly simple clients that are reading relatively small amounts of data.
Asynchronous
The client can ‘subscribe’ to cached data using IAdviseSink or IOPCDataCallback which is more
complex but very efficient. Asynchronous access is recommended because it minimizes the use of CPU
and NETWORK resources.
In all cases the OPC DA Server gives the client access to current values of the OPC items. The OPC DA Server
only holds current information in cache. Old information is overwritten. As a result of this it cannot be
guaranteed that an OPC DA Client retrieves all changes in values (also not in asynchronous mode).

For such cases, there exist two more OPC specifications, the OPC Alarms&Events and the OPC Historical Data
Access Specification.
Technosoftware GmbH offers the following products supporting the Classic OPC Data Access Specification:
OPC UA Client Gateway .NET
The OPC UA Client Gateway.NET extends the OPC UA Client SDK .NET with an OPC DA/AE/HDA
server wrapper. Because of the functionality of the use Classic OPC Server access is limited to the DA,
AE and the HDA features of the Classic OPC server.
1.1.1.2 Alarms&Events (AE)

The OPC AE interface provides a mechanism for OPC AE clients to be notified when a specified event and/or
alarm condition occurs. The browser interface also allows OPC AE clients to determine the list of events and
conditions supported by an OPC AE Server as well as to get their current status.
Within OPC, an alarm is an abnormal condition and is thus a special case of a condition. A condition is a
named state of the OPC Event Server or of one of its contained objects that is of interest to an OPC AE client.
For example, the tag Temperature may have the following conditions associated with it: HighAlarm,
HighHighAlarm, Normal, LowAlarm, and LowLowAlarm.
On the other hand, an event is a detectable occurrence that is of significance to the OPC Server, the device it
represents, and its OPC AE clients. An event may or may not be associated with a condition. For example, the
transition into HighAlarm and Normal conditions are events, which are associated with conditions. However,
operator actions, system configuration changes, and system errors are examples of events, which are not
related to specific conditions. OPC AE clients may subscribe to be notified of the occurrence of specified
events.
The OPC AE specification provides methods enabling the OPC AE client to:
Determine the types of events that are supported by the OPC AE server.
Enter subscriptions to specified events so that OPC AE clients can receive notifications of their
occurrences. Filters may be used to define a subset of desired events.
Access and manipulate conditions implemented by the OPC AE server.
Technosoftware GmbH offers the following products supporting the Classic OPC Alarms&Events Specification:

1.1.1.3 Historical Data Access (HDA)
Historical engines today produce an added source of information that should be distributed to users and
software clients that are interested in this information. Currently most historical systems use their own
proprietary interfaces for dissemination of data. There is no capability to augment or use existing historical
solutions with other capabilities in a plug-n-play environment. This requires the developer to recreate the
same infrastructure for their products, as all other vendors have had to develop independently with no
interoperability with any other systems.
In keeping with the desire to integrate data at all levels of business, historical information can be another type
of data.
There are several types of Historian servers. Some key types supported by the HDA specification are:
Simple Trend data servers.
These servers provided little else then simple raw data storage. (Data would typically be the types of data
available from an OPC Data Access server, usually provided in the form of a duple [Time Value & Quality])
Complex data compression and analysis servers. These servers provide data compression as well as
raw data storage. They can provide summary data or data analysis functions, such as average values,
minimums and maximums etc. They can support data updates and history of the updates. They can
support storage of annotations along with the actual historical data storage.
Technosoftware GmbH offers the following products supporting the Classic OPC Historical Data Access
Specification:

1.1.2 OPC XML-DA Specification
The OPC XML-DA specification is a web services-based specification and is a step between Classic OPC and
OPC Unified Architecture. The functionality is restricted to OPC DA.
Technosoftware GmbH does not offer any products supporting the OPC XML-DA Specification.
1.1.3 OPC .NET 4.0 (WCF)

OPC .NET 4.0 (WCF) is not a specification like the others mentioned here, it bridges the gap between
Microsoft.NET and the world of Classic OPC. OPC .NET 4.0 is an OPC standard C# Application Programming
Interface (API) designed to simplify client access to OPC Classic servers. It also includes a formal WCF
Interface; however, there is no compliance or certification program for this interface. The Classic OPC
interfaces are still the primary means to ensure multi-vendor interoperability.
Technosoftware GmbH does not offer any products supporting the OPC .NET 4.o API. We suggest to support
the Classic OPC specifications through a wrapper to the OPC Unified Architecture, like included with the OPC
UA Client SDK .NET – DA/AE/HDA Add-On. This gives you support for the Classic OPC specifications as well
as the new OPC Unified Architecture.

1.1.4 OPC Unified Architecture Specification
OPC Unified Architecture (UA) is a platform-independent standard through which various kinds of systems
and devices can communicate by sending Messages between Clients and Servers over various types of
networks. It supports robust, secure communication that assures the identity of Clients and Servers and resists
attacks. OPC UA defines standard sets of Services that Servers may provide, and individual Servers specify to
Clients what Service sets they support. Information is conveyed using standard and vendor- defined data types,
and Servers define object models that Clients can dynamically discover. Servers can provide access to both
current and historical data, as well as Alarms and Events to notify Clients of important changes. OPC UA can
be mapped onto a variety of communication protocols and data can be encoded in various ways to trade off
portability and efficiency.
The OPC Foundation provides deliverables for its member companies. These include a .NET based OPC UA
Stack, an ANSI C based OPC UA Stack and a Java based OPC UA Stack. The .NET based OPC UA Stack is the
base of all Technosoftware GmbH's .NET based products.
Technosoftware GmbH offers the following products supporting the OPC Unified Architecture Specification:
OPC UA Client SDK .NET Standard
The OPC UA Client SDK .NET Standard offers a fast and easy access to the OPC UA Client technology.
Develop OPC UA 1.00, 1.01, 1.02, 1.03 and 1.04 compliant UA Clients with C#/VB.NET targeting the
.NET Standard.
.Net Standard allows you develop applications that run on all common platforms available today,
including Linux, iOS, Android (via Xamarin) and Windows 7/8.1/10 (including embedded/IoT
editions) without requiring platform-specific modifications.
OPC UA Client SDK .NET
The OPC UA Client SDK .NET offers a fast and easy access to the OPC client technology. Develop
client applications supporting OPC Unified Architecture with C#/VB.NET for the .NET framework.
The OPC UA Client Gateway .NET allows any OPC UA Clients to access Classic OPC DA, AE and HDA
servers.
OPC UA Server SDK .NET
The OPC UA Server SDK .NET offers a fast and easy access to the OPC Unified Architecture (UA)
technology. Develop OPC UA 1.01 / 1.02 / 1.03 compliant Servers with C#/VB.NET for the .NET
framework.
OPC UA Server SDK .NET Standard
The OPC UA Server SDK .NET Standard offers a fast and easy access to the OPC Unified Architecture
(UA) technology. Develop OPC UA 1.00, 1.01, 1.02, 1.03 and 1.04 compliant Servers with C#/VB.NET
or any other compiler capable of generating a .NET assembly.
.Net Standard allows you develop applications that run on all common platforms available today,
including Linux, iOS, Android (via Xamarin) and Windows 7/8.1/10 (including embedded/IoT
editions) without requiring platform-specific modifications.

2 OPC UA SDKs .NET Product Line
The OPC UA SDK .NET product line consists of toolkits for OPC Client and OPC Server Development as well as
tools to give Unified Architecture applications access to the Classic OPC specifications.
The first products where based on .NET and are now available for .NET 4.7.2 and .NET 4.6.1. They base on a
now no longer support OPC UA Stack from the OPC Foundation, see https://github.com/OPCFoundation/UA-
.NET-Legacy for more information.
Because of this we introduced new products with mainly the same API as the .NET versions but basing on the
now officially supported OPC UA Stack from the OPC Foundation, see
https://github.com/OPCFoundation/UA-.NETStandard for more information.
The table below shows some differences in features available for both product lines:
Feature .NET Standard .NET
Operating Systems (32bit and 64bit)
Windows 10
Windows 7 SP1, Windows 8.1
Windows Server 2016,
Standard and Datacenter
Windows Server 2012 R2
Linux
iOS, Android (via Xamarin)
.NET SDKs
.NET 4.7.2
.NET 4.6.1
.NET Standard 2.0 (if applicable)
OPC UA Specifications
OPC UA 1.00 / 1.01 / 1.02 / 1.03
OPC UA 1.04
.NET Standard 2.0 (if applicable)
Feature Updates and Maintenance
New features and updates coming
Critical Security Updates
Existing customers with an ongoing support contract can switch free of charge to the corresponding .NET
Standard version. For more information please get in contact with us.

2.1 .NET Standard based SDKs
2.1.1 OPC UA Client SDK .NET Standard
The OPC UA Client SDK .NET Standard offers a fast and
easy access to the OPC UA Client technology. Develop OPC
compliant UA Clients with C#/VB.NET targeting the .NET
Standard.
.Net Standard allows you develop applications that run on
all common platforms available today, including Linux, iOS,
Android (via Xamarin) and Windows 7/8.1/10 (including
embedded/IoT editions) without requiring platform-
specific modifications.
The OPC Unified Architecture (UA) is THE next generation
OPC standard that provides a cohesive, secure and reliable
cross platform framework for access to real time and
historical data and events.
It’s Time to Adapt this specification for use in your
applications and we recommend considering designing
your application to use the OPC Unified Architecture.
We recommend considering designing your application to use the OPC Unified Architecture in the first place by
using our new OPC UA Client SDK .NET Standard toolkit which allows development of client applications
supporting OPC UA.
The OPC UA Client SDK .NET API defines classes which can be used to implement an OPC client capable to
access OPC servers supporting different profiles with the same API. These classes manage client side state
information; provide higher level abstractions for OPC tasks such as managing sessions and subscriptions or
saving and restoring connection information for later use.

2.1.2 OPC UA Server SDK .NET Standard
The OPC UA Server SDK .NET Standard offers a fast and easy
access to the OPC Unified Architecture (UA) technology.
Develop OPC UA 1.00, 1.01, 1.02, 1.03 and 1.04 compliant
Servers with C#/VB.NET or any other compiler capable of
generating a .NET assembly.
.NET Standard allows you develop applications that run on all
common platforms available today, including Linux, iOS,
Android (via Xamarin) and Windows 7/8.1/10 (including
embedded/IoT editions) without requiring platform-specific
modifications.
cross platform framework for access to real time and historical
data and events.
applications and we recommend considering designing your
application to use the OPC Unified Architecture.
We recommend considering designing your application to use
the OPC Unified Architecture in the first place by using our
new OPC UA Server SDK .NET Standard toolkit which
allows development of server applications supporting OPC UA.
The developer can concentrate on his application and servers can be developed fast and easily without the
need to spend a lot of time learning how to implement the OPC Unified Architecture specification. The server
API is easy to use and many OPC specific functions are handled by the framework.
The included Model Compiler can be used to create the necessary C# classes of Information Model’s specified
in XML and CSV based files. At the moment the XML files must be edited by a text editor but a Model
Designer is planned for the future. This will then improve code quality and programming efficiency.

2.2 .NET based SDKs
2.2.1 OPC UA Client SDK .NET
If If your application requires access to the
OPC technology you have to decide which
of the OPC Specifications you want to
support. The decision depends on many
factors like the used OPC specifications
supported by third party products or the
system architecture you want to use.
Technosoftware GmbH is specialized in
software consulting and development
services for technical and industrial
applications based on OPC and the founder
of Technosoftware GmbH was involved in
the design and development of many
software products with OPC connectivity
with more then 20 years extensive
knowledge about OPC.
The OPC Unified Architecture (UA) is THE
next generation OPC standard that provides
a cohesive, secure and reliable cross
platform framework for access to real time
and historical data and events.
It’s Time to Adapt this specification for use in your applications and we recommend considering designing your
application to use the OPC Unified Architecture.
The OPC UA Client SDK .NET offers a fast and easy access to the OPC UA Client technology. Develop OPC
compliant UA Clients with C#/VB.NET for the .NET 4.0 and .NET 4.6.1 frameworks.
The OPC UA Client SDK .NET API defines classes which can be used to implement an OPC client capable to
access OPC servers supporting different profiles with the same API. These classes manage client side state
information; provide higher level abstractions for OPC tasks such as managing sessions and subscriptions or
saving and restoring connection information for later use.
A large set of sample controls can be used as reference on how to implement different use cases. The sample
controls as well as a client using them is included in source code.

2.2.2 OPC UA Server SDK .NET
If your application requires access to the OPC technology you
have to decide which of the OPC Specifications you want to
support. The decision depends on many factors like the used
OPC specifications supported by third party products or the
system architecture you want to use. Technosoftware GmbH
is specialized in software consulting and development services
for technical and industrial applications based on OPC and the
founder of Technosoftware GmbH was involved in the design
and development of many software products with OPC
connectivity with more then 20 years extensive knowledge
about OPC.
cross platform framework for access to real time and historical
data and events.
applications with keeping in mind that you may need to
support other OPC specifications as well. The Classic OPC
specifications are widely used and it is important that your
application can support these specifications.
The OPC UA Server SDK .NET offers a fast and easy access to the OPC Unified Architecture (UA) technology.
Develop OPC UA 1.01, OPC UA 1.02 and OPC UA 1.03 compliant Servers with C#/VB.NET or any other
compiler capable of generating a .NET assembly.
The developer can concentrate on his application and servers can be developed fast and easily without the
need to spend a lot of time learning how to implement the OPC Unified Architecture specification. The server
API is easy to use and many OPC specific functions are handled by the framework.

2.2.3 OPC UA Client Gateway .NET
You have a Classic OPC Server which is no longer supported
or updated by the server vendor but need to integrate it into
OPC UA? You want to eliminate the need to configure DCOM
for network operation? The OPC UA Client Gateway.NET is
the right choice for this.
The OPC UA Client Gateway.NET allows any OPC UA
Clients to access Classic OPC DA, AE and HDA servers.
The OPC UA Client Gateway.NET can be configured with an
integrated configuration tool. With this tool you can specify
the Classic OPC Server to be used as well as starting node
(folder) within the UA address space to be used for mapping
the Classic OPC Server address space.
In general Technosoftware has tested the OPC UA Client
Gateway .NET with Classic OPC servers and OPC UA clients
from different vendors.
Features:
OPC UA Client Gateway .NET is fully compliant to OPC UA 1.01 / 1.02 / 1.03.
OPC UA Client Gateway .NET is fully compliant to OPC DA 2.05, OPC DA 3.0, OPC AE 1.10 and OPC
HDA 1.20 servers.
Supports 32bit and 64bit mode with the same assembly (build with Any CPU).
OPC DA, AE and HDA address space and functionality is mapped to separate nodes within the UA
address space.
Automatically reconnect a Classic OPC Server in case connection is lost.
Can be configured to use multiple Classic OPC Servers, each server’s address space mapped to its own
folder.
Increased maintainability and usability.
Easy to understand and well documented.

3 Introduction
OPC Unified Architecture (UA) is a platform-
independent standard through which various kinds
of systems and devices can communicate by
sending Messages between Clients and Servers
over various types of networks. It supports robust,
secure communication that assures the identity of
Clients and Servers and resists attacks. OPC UA
defines standard sets of Services that Servers may
provide, and individual Servers specify to Clients
what Service sets they support. Information is
conveyed using standard and vendor-defined data
types, and Servers define object models that Clients
can dynamically discover. Servers can provide access to both current and historical data, as well as Alarms and
Events to notify Clients of important changes. OPC UA can be mapped onto a variety of communication
protocols and data can be encoded in various ways to trade off portability and efficiency.
OPC UA provides a consistent, integrated AddressSpace and service model. This allows a single OPC UA
Server to integrate data, Alarms and Events, and history into its AddressSpace, and to provide access to them
using an integrated set of Services. These Services also include an integrated security model.
OPC UA also allows Servers to provide Clients with type definitions for the Objects accessed from the
AddressSpace. This allows standard information models to be used to describe the contents of the
AddressSpace. OPC UA allows data to be exposed in many different formats, including binary structures and
XML documents. The format of the data may be defined by OPC, other standard organizations or vendors.
Through the AddressSpace, Clients can query the Server for the metadata that describes the format for the
data. In many cases, Clients with no pre-programmed knowledge of the data formats will be able to determine
the formats at runtime and properly utilize the data.
OPC UA adds support for many relationships between Nodes instead of being limited to just a single hierarchy.
In this way, an OPC UA Server may present data in a variety of hierarchies tailored to the way a set of Clients
would typically like to view the data. This flexibility, combined with support for type definitions, makes OPC
UA applicable to a wide array of problem domains. As illustrated below, OPC UA is not targeted at just the
telemetry server interface, but also to provide greater interoperability between higher level functions.
OPC UA is designed to provide robustness of published data. A major feature of all OPC servers is the ability 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 broad scope of size, performance, execution platforms and functional
capabilities. Therefore, OPC UA defines a comprehensive set of capabilities, and Servers may 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 can then discover the Profiles of a Server, and tailor
their interactions with that Server based on the Profiles. Profiles are defined in [UA Part 7].

The OPC UA specifications are layered to isolate the core design from the underlying computing technology
and network transport. This allows OPC UA to be mapped to future technologies as necessary, without
negating the basic design. Mappings and data encodings are described in [UA Part 6]. Two data encodings are
defined in this part:
• XML/text
• UA Binary
In addition, two transport mappings are defined in this part:
• TCP
• SOAP Web services over HTTP
Clients and Servers that support multiple transports and encodings will allow the end users to make decisions
about tradeoffs between performance and XML Web service compatibility at the time of deployment, rather
than having these tradeoffs determined by the OPC vendor at the time of product definition.
OPC UA is designed as the migration path for OPC clients and servers that are based on Microsoft COM
technology. Care has been taken in the design of OPC-UA so that existing data exposed by OPC COM servers
(DA, HDA and A&E) can easily be mapped and exposed via OPC UA. Vendors may choose to migrate their
products natively to OPC UA or use external wrappers to convert from OPC COM to OPC UA and vice-versa.
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 with a single set of Services.

4 OPC UA Basics
This chapter describes the base concepts of the OPC UA specification. It is not intended to replace studying the
OPC UA specification; its purpose is to introduce the base concepts of the OPC UA specification.
4.1 Overview
4.1.1 Specifications
The OPC UA specification is organized as a multi-part specification, splitted into 3 sections:
1. Core Specification Parts
The first seven parts specify the core capabilities of OPC UA. These core capabilities define the
structure of the OPC AddressSpace and the Services that operate on it.
2. Access Type Specification Parts
Parts 8 through 11 apply these core capabilities to specific types of access previously addressed by
separate OPC COM specifications, such as Data Access (DA), Alarms and Events (A&E) and Historical
Data Access (HDA).
3. Utility Specification Parts
Part 12: describes Discovery mechanisms for OPC UA and Part 13 describe ways of aggregating data.
Unfortunatley most of the OPC UA specification documents can only be downloaded by OPC Foundation
members from the OPC Foundation web site. Only part 1 (Overview and Concepts) is available to the public.
All other parts are available only to OPC Foundation members and may be used only as long as the user is an
active OPC Foundation member.
The OPC Foundation offers an OPC UA SDK but also this one is only available for OPC Foundation members.
Because of this Technosoftware GmbH decided to develop the OPC UA Client SDK .NET with the following
main goals:
Ease of Use
By hiding the complexity of the OPC UA specification it should be possible for a developer with just
OPC UA Basic Knowledge to implement an OPC UA client.
Compliance
By using the OPC UA SDK provided by the OPC Foundation as base of the OPC UA Client SDK .NET
compliance to the OPC UA specification can be guaranteed.
The following sections give the reader an introduction in OPC UA. Most of these parts are summaries of the
OPC UA specifications and are reduced to those parts which are required for the reader to understand the
basics of OPC UA. Mappings between definitions in the OPC UA specifications and those used in the OPC UA
Client SDK .NET are given as soon as they are used the first time.
In case you are interested in an Overview of OPC UA please consider downloading part 1 (Overview and
Concepts) through the OPC Foundation web site. The direct link is
http://www.opcfoundation.org/DownloadFile.aspx?CM=3&RI=414&CN=KEY&CI=283&CU=7.

4.1.2 Graphical Notation
The OPC UA specification [UA Part 3] defines a graphical notation for an OPC UA AddressSpace. It defines
graphical symbols for all NodeClasses and how References of different types can be visualized. This notation is
also used in this documentation and therefore explained in this chapter.
4.1.2.1 Overview
The OPC UA specification [UA Part 3] defines a graphical notation for OPC UA data. It is normative, that is,
the notation is used in the OPC UA specification to expose examples of OPC UA data. However, it is not
required to use this notation to expose OPC UA data.
The graphical notation is able to expose all structural data of OPC UA. Nodes, their Attributes including their
current value and References between the Nodes including the ReferenceType can be exposed. The graphical
notation provides no mechanism to expose events or historical data.
The notation is divided into two parts. The simple notation only provides a simplified view on the data hiding
some details like Attributes. The extended notation allows exposing all structure information of OPC UA,
including Attribute values. The simple and the extended notation can be combined to expose OPC UA data in
one figure. The following chapters describe the simple and the complex notation.
Common to both notations is that neither any colour nor the thickness or style of lines is relevant for the
notation. Those effects can be used to highlight certain aspects of a figure.
4.1.2.2 Simple Notation

Depending on their NodeClass Nodes are represented by different graphical forms as defined in the following
table:
NodeClass Graphical Representation Comment
Object Rectangle including text representing the string-part of
Object the DisplayName of the Object. The font shall not be set
to italic.
ObjectType Shadowed rectangle including text representing the
ObjectType string-part of the DisplayName of the ObjectType. The
font shall be set in italic.
Variable Rectangle with rounded corners including text
Variable representing the string-part of the DisplayName of the
Variable. The font shall not be set in italic.
VariableType Shadowed rectangle with rounded corners including text
VariableType representing the string-part of the DisplayName of the
VariableType. The font shall be set in italic.
DataType Shadowed hexagon including text representing the
DataType string-part of the DisplayName of the DataType.
ReferenceType Shadowed six-sided polygon including text representing

ReferenceType the string-part of the DisplayName of the ReferenceType.
Method Oval including text representing the string-part of the

Method DisplayName of the Method.
View Trapezium including text representing the string-part of

View the DisplayName of the View.

References are represented as lines between Nodes as exemplified in the figure below. Those lines can vary in
their form. They do not have to connect the Nodes with a straight line; they can have angles, arches, etc.
Node1 ReferenceName Node2
The next table defines how symmetric and asymmetric References are represented in general, and also defines
shortcuts for some ReferenceTypes. Although it is recommended to use those shortcuts, it is not required.
Thus, instead of using the shortcut also the generic solution can be used.
ReferenceType Graphical Representation Comment
Any symmetric ReferenceType Symmetric ReferenceTypes are represented as lines
ReferenceType between Nodes with closed and filled arrows on both
sides pointing to the connected Nodes. Near to the line
has to be a text containing the string-part of the
BrowseName of the ReferenceType.
Any asymmetric ReferenceType Asymmetric ReferenceTypes are represented as lines
ReferenceType between Nodes with a closed and filled arrow on the side
pointing to the TargetNode. Near to the line has to be a
text containing the string-part of the BrowseName of the
ReferenceType.
Any hierarchical ReferenceType Asymmetric ReferenceTypes that are subtypes of
ReferenceType HierarchicalReferences should be exposed the same way
as asymmetric ReferenceTypes except that an open arrow
is used.
HasComponent The notation provides a shortcut for HasComponent
References shown on the left. The single hashed line has
to be near the TargetNode.
HasProperty The notation provides a shortcut for HasProperty
References shown on the left. The double hashed lines
have to be near the TargetNode.
HasTypeDefinition The notation provides a shortcut for HasTypeDefinition
References shown on the left. The double closed and
filled arrows have to point to the TargetNode.
HasSubtype The notation provides a shortcut for HasSubtype
References shown on the left. The double closed arrows
have to point to the SourceNode.
HasEventSource The notation provides a shortcut for HasEventSource
References shown on the left. The closed arrow has to
point to the TargetNode.

4.1.2.3 Extended Notation
In the extended Notation some additional concepts are introduced. It is allowed only to use some of those
concepts on elements of a figure.
The following rules define some special handling of structures.
• In general, values of all DataTypes should be represented by an appropriate string representation.
Whenever a NamespaceIndex or LocaleId is used in those structures they can be omitted.
• The DisplayName contains a LocaleId and a String. Such a structure can be exposed as
[<LocaleId>:]<String>; where the LocaleId is optional. For example, a DisplayName can be
“en:MyName”. Instead of that, also “MyName” can be used. This rule applies whenever a
DisplayName is shown, including the text used in the graphical representation of a Node.
• The BrowseName contains the NamespaceIndex and a String. Such a structure can be exposed as
[<NamespaceIndex>:]<String>; where the NamespaceIndex is optional. For example, a BrowseName
can be “1:MyName”. Instead of that, also “MyName” can be used. This rule applies whenever a
BrowseName is shown, including the text used in the graphical representation of a Node.
Instead of using the HasTypeDefinition reference to point from an Object or Variable to its ObjectType or
VariableType the name of the TypeDefinition can be added to the text used in the Node. The TypeDefinition
has to be prefixed with “::”. The next figure gives an example, where “Node1” uses a Reference and “Node2”
the shortcut. A figure can contain HasTypeDefinition References for some Nodes and the shortcut for other
Nodes. It is not allowed that a Node uses the shortcut and additionally is the SourceNode of a
HasTypeDefinition.
Node1 SampleType
Node2::SampleType
To display Attributes of a Node additional text can be put inside the form representing the Node under the text
representing the DisplayName. The DisplayName and the text describing the Attributes have to be separated
using a horizontal line. Each Attribute has to be set into a new text line. Each text line shall contain the
Attribute name followed by an “=” and the value of the Attribute. On top of the first text line containing an
Attribute shall be a text line containing the underlined text “Attribute”. It is not required to expose all
Attributes of a Node. It is allowed to show only a subset of Attributes. If an optional Attribute is not provided,
the Attribute can be marked by a strike-through line, for example “Description”. Examples of exposing
Attributes are shown in the figure below:
FT1001 DataItem
Attribute Attribute
NodeId = “1000“ NodeClass = Variable
NodeClass = Object DisplayName = “DataItem“
DisplayName = “FT1001“ BrowseName = “DataItem“
BrowseName = “FTX001“ MinimumSamplingInterval = -1
Description
EventNotifier = 0

To avoid too many Nodes in a figure it is allowed to expose Properties inside a Node, similar to Attributes.
Therefore, the text field used for exposing Attributes is extended. Under the last text line containing an
Attribute a new text line containing the underlined text “Property” has to be added. If no Attribute is provided,
the text has to start with this text line. After this text line, each new text line shall contain a Property, starting
with the BrowseName of the Property followed by “=” and the value of the Value Attribute of the Property. The
figure below shows some examples exposing Properties inline. It is allowed to expose some Properties of a
Node inline, and other Properties as Nodes. It is not allowed to show a Property inline and as well as an
additional Node.
FT1001 DataItem
Attribute Attribute
NodeId = “1000“ NodeClass = Variable
DisplayName = “FT1001“ DisplayName = “DataItem“
BrowseName = “FTX001“ BrowseName = “DataItem“
Description MinimumSamplingInterval = -1
EventNotifier = 0 Property
Property Prop1 = 12
Prop1 = 12 Prop2 = “PropValue“
Prop2 = “PropValue“
FT1002 DataItemX
Property
Property Prop1 = 12
Prop1 = 12 Prop2 = “PropValue“
Prop2 = “PropValue“
It is allowed to add additional information to a figure using the graphical representation, for example callouts.

4.1.3 Terms, definitions and abbreviations
For the purposes of this specification, the following definitions apply. Please note that the following sections
are an excerpt of [UA Part 1] of the OPC UA specification.
4.1.3.1 OPC UA
4.1.3.1.1 Terms
AddressSpace
The collection of information that an OPC UA Server makes visible to its Clients. See [UA Part 3] for a
description of the contents and structure of the Server AddressSpace.
Alarm
A type of Event associated with a state condition that typically requires acknowledgement. See [UA Part 9]
for a description of Alarms.
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 AddressSpace permitted to have data values.
Certificate
A digitally signed data structure that describes capabilities of a Client or Server.
Client
A software application that sends Messages to OPC UA Servers conforming to the Services specified in this set
of specifications.
Condition
A generic term that is an extension to an Event. A Condition represents the conditions of a system or one of its
components and always exists in some state.
Communication Stack
A layered set of software modules between the application and the hardware that provides various functions to
encode, encrypt and format a Message for sending, and to decode, decrypt and unpack a Message that was
received.
Complex Data
Data that is composed of elements or more than one primitive data type, such as a structure.
Discovery
The process by which OPC UA Clients obtain information about OPC UA Servers, including endpoint and
security information.
Event
A generic term used to describe an occurrence of some significance within a system or system component.
EventNotifier
A special Attribute of a Node that signifies that a Client may subscribe to that particular Node to receive
Notifications of Event occurrences.

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 supports the representation of Information Models in the
AddressSpace. See [UA Part 5] for a description of the base OPC UA Information Model.
Message
The data unit conveyed between Client and Server that represents a specific Service request or response.
Method
A callable software function that is a component of an Object.
MonitoredItem
A Client-defined entity in the Server used to monitor Attributes or EventNotifiers for new values or Event
occurrences and generate Notifications for them.
Node
The fundamental component of an AddressSpace.
NodeClass
The class of a Node in an AddressSpace. NodeClasses define the metadata for the components of the OPC
UA Object Model. They also define constructs, such as Views, that are used to organize the AddressSpace.
Notification
The generic term for data that announces the detection of an Event or of a changed Attribute value.
Notifications are sent in NotificationMessages.
NotificationMessage
A Message published from a Subscription that contains one or more Notifications.
Object
A Node that represents a physical or abstract element of a system. Objects are modelled using the OPC UA
Object Model. Systems, subsystems and devices are examples of Objects. An Object may be defined as an
instance of an ObjectType.
Object Instance
A synonym for Object. Not all Objects are defined by ObjectTypes.
ObjectType
A Node that represents the type definition for an Object.
Profile
A specific set of capabilities, defined in [UA Part 7], to which a Server may claim conformance. Each Server
may claim conformance to more than one Profile.
Program
An executable Object that, when invoked, immediately returns a response to indicate that execution has
started, and then returns intermediate and final results through Subscriptions identified by the Client during
invocation.

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
ReferenceTypes.
ReferenceType
A Node that represents the type definition of a Reference. The ReferenceType specifies the semantics of a
Reference. The name of a ReferenceType identifies how source Nodes are related to target Nodes and
generally reflects an operation between the two, such as “A Contains B”.
RootNode
The beginning or top Node of a hierarchy. The RootNode of the OPC UA AddressSpace is defined in
[UA Part 5].
Server
A software application that implements and exposes the Services specified in this set of specifications.
Service
A Client-callable operation in an OPC UA Server. Services are defined in [UA Part 4]. A Service is similar to a
method call in a programming language or an operation in a Web services WSDL contract.
Service Set
A group of related Services.
Session
A logical long-running connection between a Client and a Server. A Session maintains state information
between Service calls from the Client to the Server.
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.
Variable
A Variable is a Node that contains a value.
View
A specific subset of the AddressSpace that is of interest to the Client.

4.1.3.1.2 Abbreviations and symbols
A&E Alarms and Events
API Application Programming Interface
COM Component Object Model
DA Data Access
DCS Distributed Control System
DX Data Exchange
HDA Historical Data Access
HMI Human-Machine Interface
LDAP Lightweight Directory Access Protocol
MES Manufacturing Execution System
OPC OPC Foundation (a non-profit industry association)
PLC Programmable Logic Controller
SCADA Supervisory Control And Data Acquisition
SOAP Simple Object Access Protocol
UA Unified Architecture
UDDI Universal Description, Discovery and Integration
UML Unified Modelling Language
WSDL Web Services Definition Language
XML Extensible Mark-up Language

4.1.3.2 OPC UA Security
4.1.3.2.1 Terms
Application Instance
an individual installation of a program running on one computer.
NOTE: There can be several Application Instances of the same application running at the same time on several
computers or possibly the same computer.
Application Instance Certificate

a Digital Certificate of an individual Application Instance that has been installed in an individual host.
NOTE: Different installations of one software product would have different Application Instance Certificates.
Asymmetric Cryptography
a Cryptography method that uses a pair of keys, one that is designated the Private Key and kept secret, the
other called the Public Key that is generally made available.
NOTE: ‘Asymmetric Cryptography, also known as "public-key cryptography". In an Asymmetric Encryption
algorithm when an entity A wants to ensure Confidentiality for data it sends to another entity B, entity A
encrypts the data with a Public Key provided by entity B. Only entity B has the matching Private Key that is
needed to decrypt the data. In an asymmetric Digital Signature algorithm when an entity A wants to ensure
Integrity or provide Authentication for data it sends to an entity B, entity A uses its Private Key to sign the data.
To verify the signature, entity B uses the matching Public Key that entity A has provided. In an asymmetric key
agreement algorithm, entity A and entity B each send their own Public Key to the other entity. Then each uses
their own Private Key and the other's Public Key to compute the new key value.’ according to IS Glossary
Asymmetric Encryption
the mechanism used by Asymmetric Cryptography for encrypting data with the Public Key of an entity and for
decrypting data with the associated Private Key.
NOTE: See [UA Part 2] for details.
Asymmetric Signature
the mechanism used by Asymmetric Cryptography for signing data with the Private Key of an entity and for
verifying the data’s signature with the associated Public Key.
NOTE: See [UA Part 2] for details.
Auditability
a security objective that assures that any actions or activities in a system can be recorded.

Auditing
the tracking of actions and activities in the system, including security related activities where the Audit records
can be used to review and verify system operations.
Authentication
a security objective that assures that the identity of an entity such as a Client, Server, or user can be verified.
Authorization
a security objective that assures the control to grant the right or the permission to a system entity to access a
system resource.
Availability
a security objective that assures that the system is running normally. that is, no services have been
compromised in such a way to become unavailable or severely degraded.
CertificateAuthority
an entity that can issues Digital Certificates, also known as a CA.
Note: The Digital Certificate certifies the ownership of a Public Key by the named subject of the Certificate.
This allows others (relying parties) to rely upon signatures or assertions made by the Private Key that
corresponds to the Public Key that is certified. In this model of trust relationships, a CA is a trusted third party
that is trusted by both the subject (owner) of the Certificate and the party relying upon the Certificate. CAs are
characteristic of many Public Key infrastructure (PKI) schemes
CertificateStore
persistent location where Certificates and Certificate revocation lists (CRLs) are stored.
Note: It maybe a disk resident file structure or on Windows platforms, it maybe a Windows registry location.
Confidentiality
a security objective that assures the protection of data from being read by unintended parties.
Cryptogrophy
transforming clear, meaningful information into an enciphered, unintelligible form using an algorithm and a
key.
Cyber Security Management System (CSMS)

a program designed by an organization to maintain the security of the entire organization’s assets to an
established level of Confidentiality, Integrity, and Availability, whether they are on the business side or the
industrial automation and control systems side of the organization.
Digital Certificate
a structure that associates an identity with an entity such as a user, a product or an Application Instance where
the Certificate has an associated asymmetric key pair which can be used to authenticate that the entity does,
indeed, possess the Private Key.
Digital Signature
a value computed with a cryptographic algorithm and appended to data in such a way that any recipient of the
data can use the signature to verify the data's origin and Integrity.

Hash Function
‘an algorithm such as SHA-1 for which it is computationally infeasible to find either a data object that maps to
a given hash result (the "one-way" property) or two data objects that map to the same hash result (the
"collision-free" property).’ according to IS Glossary
Hashed Message Authentication Code (HMAC)

a MAC that has been generated using an iterative Hash Function.
Integrity
a security objective that assures that information has not been modified or destroyed in a unauthorized
manner.
NOTE: definition from IS Glossary.
Key Exchange Algorithm

a protocol used for establishing a secure communication path between two entities in an unsecured
environment whereby both entities apply a specific algorithm to securely exchange secret keys that are used
for securing the communication between them.
NOTE: A typical example of a Key Exchange Algorithm is the SSL Handshake Protocol specified in SSL/TLS.
Message Authentication Code (MAC)

a short piece of data that results from an algorithm that uses a secret key (see Symmetric Cryptography) to
hash a Message whereby the receiver of the Message can check against alteration of the Message by computing
a MAC that should be identical using the same Message and secret key.
Message Signature
a Digital Signature used to ensure the Integrity of Messages that are sent between two entities.
NOTE: There are several ways to generate and verify Message Signatures however they can be categorized as
symmetric (See [UA Part 2]) and asymmetric (See [UA Part 2]) approaches.

Non-Repudiation
strong and substantial evidence of the identity of the signer of a Message and of Message Integrity, sufficient to
prevent a party from successfully denying the original submission or delivery of the Message and the Integrity
of its contents.
Nonce
a random number that is used once, typically by algorithms that generate security keys.
OPC UA Application
an OPC UA Client, which calls OPC UA services, or an OPC UA Server, which performs those services.
Private Key
the secret component of a pair of cryptographic keys used for Asymmetric Cryptography.
Public Key
the publicly-disclosed component of a pair of cryptographic keys used for Asymmetric Cryptography.
IS Glossary
Public Key Infrastructure (PKI)

the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute,
and revoke Digital Certificates based on Asymmetric Cryptography.
NOTE: The core PKI functions are to register users and issue their public-key Certificates, to revoke
Certificates when required, and to archive data needed to validate Certificates at a much later time. Key pairs
for data Confidentiality may be generated by a Certificate authority (CA), but requiring a Private Key owner to
generate its own key pair improves security because the Private Key would never be transmitted. IS Glossary.
See PKI and X509 PKI for more details on Public Key Infrastructures.
Rivest-Shamir-Adleman (RSA)
an algorithm for Asymmetric Cryptography, invented in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman.
IS Glossary
Secure Channel
in OPC UA, a communication path established between an OPC UA Client and Server that have authenticated
each other using certain OPC UA services and for which security parameters have been negotiated and applied.

Symmetric Cryptography
A branch of cryptography involving algorithms that use the same key for two different steps of the algorithm
(such as encryption and decryption, or Signature creation and signature verification). IS Glossary
Symmetric Encryption
the mechanism used by Symmetric Cryptography for encrypting and decrypting data with a cryptographic key
shared by two entities.
Symmetric Signature
the mechanism used by Symmetric Cryptography for signing data with a cryptographic key shared by two
entities.
NOTE: The signature is then validated by generating the signature for the data again and comparing these
two signatures. If they are the same then the signature is valid, otherwise either the key or the data is different
from the two entities. [UA Part 2] defines a typical example for an algorithm that generates Symmetric
Signatures.
TrustList
a list of Certificates that an application has been configured to trust.
Transport Layer Security (TLS)

a standard protocol for creating Secure Channels over IP based networks.
X.509 Certificate
a Digital Certificate in one of the formats defined by X.509 v1, 2, or 3. An X.509 Certificate contains a sequence
of data items and has a Digital Signature computed on that sequence.

AES Advanced Encryption Standard
CA Certificate Authority
CRL Certificate Revocation List
CSMS Cyber Security Management System
DNS Domain Name System
DSA Digital Signature Algorithm
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
HMAC Hash-based Message Authentication Code
PKI Public Key Infrastructure
RSA public key algorithm for signing or encryption, Rivest, Shamir, Adleman
SHA Secure Hash Algorithm (Multiple versions exist SHA1, SHA256,…)
SSL Secure Sockets Layer
TLS Transport Layer Security

URI Uniform Resource Identifier

4.1.3.3 OPC UA Address Space
4.1.3.3.1 Terms
DataType
An instance of a DataType Node that is used together with the ValueRank Attribute to define the data type of a
Variable.
DataTypeId
NodeId of a DataType Node.
DataVariable
Variables that represent values of Objects, either directly or indirectly for complex Variables, where the
Variables are always the TargetNode of a HasComponent Reference.
EventType
ObjectType Node that represents the type definition of an Event
Hierarchical Reference
Reference that is used to construct hierarchies in the AddressSpace
NOTE All hierarchical ReferenceTypes are derived from HierarchicalReferences.
InstanceDeclaration
Node that is used by a complex TypeDefinitionNode to expose its complex structure; It is an instance used by a
type definition
ModellingRule
metadata of an InstanceDeclaration that defines how the InstanceDeclaration will be used for instantiation; It
also defines subtyping rules for an InstanceDeclaration
Property
Variables that are the TargetNode for a HasProperty Reference; Properties describe the characteristics of a
Node
SourceNode
Node having a Reference to another Node; For example, in the Reference “A contains B”, “A” is the SourceNode
TargetNode
Node that is referenced by another Node; For example, in the Reference “A Contains B”, “B” is the TargetNode
TypeDefinitionNode
Node that is used to define the type of another Node; ObjectType and VariableType Nodes are
TypeDefinitionNodes
VariableType
Node that represents the type definition for a Variable
4.1.3.3.2 Abbreviations

UML Unified Modeling Language
W3C World Wide Web Consortium
XML Extensible Markup Language

4.1.3.4 OPC UA Services
4.1.3.4.1 Terms
Deadband
permitted range for value changes that will not trigger a data change Notification
NOTE Deadband can be applied as a filter when subscribing to Variables and is used to keep noisy signals
from updating the Client unnecessarily. This standard defines AbsoluteDeadband as a common filter.
[UA Part 8] defines an additional Deadband filter.
Endpoint
physical address available on a network that allows Clients to access one or more Services provided by a Server
NOTE Each Server may have multiple Endpoints. The address of an Endpoint must include a HostName.
Gateway Server
Server that acts as an intermediary for one or more Servers
NOTE Gateway Servers may be deployed to limit external access, provide protocol conversion or to provide
features that the underlying Servers do not support.
HostName
unique identifier for a machine on a network
NOTE This identifier shall be unique within a local network; however, it may also be globally unique. The
identifier can be an IP address.
Security Token
identifier for a cryptographic key set
NOTE All Security Tokens belong to a security context which is in case of OPC UA the Secure Channel.
SoftwareCertificate
digital certificate for a software product that can be installed on several hosts to describe the capabilities of the
software product
NOTE Different installations of one software product could have the same software certificate. Software
certificates are not relevant for security. They are used to identify a software product and its supported
features. SoftwareCertificates are described in [UA Part 4].

BNF Backus-Naur Form
CA Certificate Authority
CTL Certificate Trust List
DA Data Access
URL Uniform Resource Locator

4.1.3.5 OPC UA Information Model
4.1.3.5.1 Terms
ClientUserId
String that identifies the user of the client requesting an action
NOTE: The ClientUserId is obtained directly or indirectly from the UserIdentityToken passed by the Client in
the ActivateSession Service call. See [UA Part 5], Chapter 6.4.3 for details.


4.1.3.6 OPC UA Mappings
4.1.3.6.1 Terms
Data Encoding
Is a way to serialize OPC UA Messages and data structures.
Mapping
Specifies how to implement an OPC UA feature with a specific technology.
NOTE For example, the OPC UA Binary Encoding is a Mapping that specifies how to serialize OPC UA data
structures as sequences of bytes.
Security Protocol
Ensures the integrity and privacy of UA Messages that are exchanged between OPC UA applications
Stack
Is a collection of software libraries that implement one or more Stack Profiles; Stacks have an API which hides
the implementation details from the Application developer
Stack Profile
Is a combination of DataEncodings, SecurityProtocol and TransportProtocol Mappings
NOTE OPC UA applications implement one or more StackProfiles and can only communicate with OPC UA
applications that support a StackProfile that they support.
Transport Protocol
Represents a way to exchange serialized OPC UA Messages between OPC UA applications

ASN.1 Abstract Syntax Notation #1
BP WS-I Basic Profile Version
BSP WS-I Basic Security Profile
CSV Comma Separated Value (File Format)
HTTP Hypertext Transfer Protocol
HTTPS Secure Hypertext Transfer Protocol
IPSec Internet Protocol Security
RST Request Security Token
OID Object Identifier (used with ASN.1)
RSTR Request Security Token Response
SCT Security Context Token
SHA1 Secure Hash Algorithm
SSL Secure Sockets Layer (Defined in SSL/TLS)
TCP Transmission Control Protocol
TLS Transport Layer Security (Defined in SSL/TLS)
UTF8 Unicode Transformation Format (8-bit)
UASC OPC UA Secure Conversation
WS-* XML Web Services Specifications
WSS WS Security
WS-SC WS Secure Conversation

4.1.3.7 OPC UA Profiles
4.1.3.7.1 Terms
Application
a software program that executes or implements some aspect of OPC UA.
Note: The application could run on any machine and perform any function. The application could be software
or it could be a hardware application, the only requirement is that it implements OPC UA
ConformanceUnit
a specific set of OPC UA features that can be tested as a single entity.
Note: A ConformanceUnit can cover a group of services, portions of services or information models. For
additional detail see [UA Part 7].
ConformanceGroup
a group of ConformanceUnits that is given a name.
Note: This grouping is only to assist in organizing ConformanceUnits. Typical ConformanceGroups include
groups for each of the service sets in OPC UA and each of the Information Model standards.
Facet
a Profile dedicated to a specific feature that a Server or Client may require.
Note: Facets are typically combined to form higher-level Profiles. The use of the term Facet in the title of a
Profile indicates that the given Profile is not a standalone Profile.
ProfileCategory
arranges Profiles into application classes, such as Server or Client.
Note: These categories help determine the type of Application that a given Profile would be used for. For
additional details see [UA Part 4] section 4.4
TestCase
a technical description of a set of steps required to test a particular function or information model.
Note: TestCases provide sufficient details to allow a developer to implement them in code. TestCases also
provide a detailed summary of the expected result(s) from the execution of the implemented code and any
precondition(s) that must be established before the TestCase can be executed.

TestLab
a facility that is designated to provide testing services.
Note: These services include but are not limited to personal that directly perform testing, automated testing
and a formal repeatable process. The OPC Foundation has provided detailed standard describing OPC UA
TestLabs and the testing they are to provided (see Compliance Part 8 UA Server, Compliance Part 9 UA
Client,)
DA Data Access
HA Historical Access
HMI Human Machine Interface
PKI Public Key Infrastructure
RSA Rivest-Shamir-Adleman

4.1.3.8 OPC UA Data Access
4.1.3.8.1 Terms
DataItem
link to arbitrary, live automation data, that is, data that represents currently valid information
NOTE Examples of such data are
• device data (such as temperature sensors),
• calculated data,
• status information (open/closed, moving),
• dynamically-changing system data (such as stock quotes),
• diagnostic data.
AnalogItem
DataItems that represent continuously-variable physical quantities (e.g., length, temperature), in contrast to
the digital representation of data in discrete items
NOTE Typical examples are the values provided by temperature sensors or pressure sensors. OPC UA
defines a specific VariableType to identify an AnalogItem. Properties describe the possible ranges of
AnalogItems.
DiscreteItem
DataItems that represent data that may take on only a certain number of possible values (e.g., OPENING,
OPEN, CLOSING, CLOSED)
NOTE Specific VariableTypes are used to identify DiscreteItems with two states or with multiple states.
Properties specify the string values for these states.
ArrayItem
DataItems that represent continuously-variable physical quantities and where each individual data point
consists of multiple values represented by an array (e.g., the spectral response of a digital filter)
NOTE Typical examples are the data provided by analyser devices. Specific VariableTypes are used to identify
ArrayItem variants.
EngineeringUnits
Units of measurement for AnalogItems that represent continuously-variable physical quantities (e.g., length,
mass, time, temperature)
NOTE This standard defines Properties to inform about the unit used for the DataItem value and about the
highest and lowest value likely to be obtained in normal operation.

DA Data Access
EU Engineering Unit

4.1.3.9 OPC UA Alarms & Conditions
4.1.3.9.1 Terms
Acknowledge
“Operator action that indicates recognition of a new Alarm”
Note: as defined in EEMUA. The term “Accept” is another common term used to describe Acknowledge. They
can be used interchangeably. This document will use Acknowledge.
Active
a state for an Alarm that indicates that the situation the Alarm is representing currently exists.
Note: Other common terms defined by EEMUA are “Standing” for an Active Alarm and “Cleared” when the
Condition has returned to normal and is no longer Active.
ConditionClass
a Condition grouping that indicates in which domain or for what purpose a certain Condition is used.
Note: Some top-level ConditionClasses are defined in this specification. Vendors or organisations may derive
more concrete classes or define different top-level classes.
ConditionBranch
a specific state of a Condition.
Note: The Server can maintain ConditionBranches for the current state as well as for previous states.
ConditionSource
Element which a specific Condition is based upon or related to.
Note: Typically, it will be a Variable representing a process tag (e.g. FIC101) or an Object representing a
device or subsystem.
In Events generated for Conditions, the SourceNode Property (inherited from the BaseEventType) will contain
the NodeId of the ConditionSource.
Confirm
Operator action informing the Server that a corrective action has been taken to address the cause of the Alarm.
Disable
“System is configured such that the Alarm will not be generated even though the base Alarm Condition is
present”
Note: This concept is further described in EEMUA
Operator
Special user who is assigned to monitor and control a portion of a process
Note: “A Member of the operations team who is assigned to monitor and control a portion of the process and
is working at the control system’s Console” as defined in EEMUA. In this standard an Operator is a special
user. All descriptions that apply to general users also apply to Operators.
Refresh

the act of providing an update to an Event Subscription that provides all Alarms which are considered to be
Retained.
Note: This concept is further described in EEMUA.
Retain
Alarm in a state that is interesting for a Client wishing to synchronize its state of Conditions with the Server’s
state.
Shelving
“Facility where the Operator is able to temporarily prevent an Alarm from being displayed to the Operator
when it is causing the Operator a nuisance.
Note: A Shelved Alarm will be removed from the list and will not re-annunciate until un-shelved” as defined
in EEMUA.
Suppress
the act of determining whether an Alarm should not occur
Note: “An Alarm is suppressed when logical criteria are applied to determine that the Alarm should not occur,
even though the base Alarm Condition (e.g. Alarm setting exceeded) is present” as defined in EEMUA.
Abbreviations and symbols

DA Data Access
UML Unified Modelling Language

4.1.3.10 OPC UA Programs
4.1.3.10.1 Terms
Function
programmatic task performed at a server or device, usually accomplished by computer code execution
Finite State Machine

sequence of states and valid state transitions along with the causes and effects of those state transitions that
define the actions of a Program in terms of discrete stages
ProgramType
ObjectType Node that represents the type definition of a Program and is a subtype of the
FiniteStateMachineType
Program Control Method

Method specified by this specification having specific semantics designed for the control of a Program by
causing a state transition
Program Invocation
unique Object instance of a Program existing on a Server
NOTE The Program Invocation is distinguished from other Object instances of the same ProgramType by the
object node’s unique browse path.
DA Data Access
FSM Finite State Machine
HMI Human Machine Interfaces
PCM Program Control Method
PGM Program
PI Program Invocation

4.1.3.11 OPC UA Historical Access
4.1.3.11.1 Terms
Annotation
metadata associated with an item at a given instance in time
NOTE An Annotation is metadata that is associated with an item at a given instance in time. There does not
have to be a value stored at that time.
BoundingValues
values associated with the starting and ending time
NOTE BoundingValues are the values that are associated with the starting and ending time of a
ProcessingInterval specified when reading from the historian. BoundingValues may be required by Clients to
determine the starting and ending values when requesting raw data over a time range. If a raw data value
exists at the start or end point, it is considered the bounding value even though it is part of the data request. If
no raw data value exists at the start or end point, then the server will determine the boundary value, which
may require data from a data point outside of the requested range. See [UA Part 11] for details on using
BoundingValues.
HistoricalNode
Object, Variable, Property or View in the AddressSpace where a Client can access historical data or Events
NOTE A Error! Unknown document property name. is a term used in this document to represent any
Object, Variable, Property or View in the AddressSpace for which a Client may read and/or update historical
data or Events. The terms “Error! Unknown document property name.’s history” or “history of a Error!
Unknown document property name.” will refer to the time series data or Events stored for this
HistoricalNode where HistoricalNode is an Object, Variable, Property or View. The term Error! Unknown
document property name. refers to both Error! Unknown document property name.s and Error! Unknown
document property name.s, and is used when referencing aspects of the specification that apply to accessing
historical data and Events.
HistoricalDataNode
Variable or Property in the AddressSpace where a Client can access historical data
NOTE A Error! Unknown document property name. represents any Variable or Property in the
AddressSpace for which a Client may read and/or update historical data. The terms “Error! Unknown
document property name.’s history” or “history of a Error! Unknown document property name.” will refer
to the time series data stored for this HistoricalNode where HistoricalNode is an Object, Variable, or Property.
Some examples of such data are:
• device data (like temperature sensors)
• calculated data
• status information (open/closed, moving)
• dynamically changing system data (like stock quotes)
• diagnostic data
The term Error! Unknown document property name.s is used when referencing aspects of the specification
that apply to accessing historical data only.

HistoricalEventNode
Object or View in the AddressSpace where a Client can access historical Events
NOTE A Error! Unknown document property name. represents any Object or View in the AddressSpace
for which a Client may read and/or update historical Events. The terms “Error! Unknown document
property name.’s history” or “history of a Error! Unknown document property name.” will refer to the time
series Events stored in some historical system. Some examples of such data are:
• Notifications
• system Alarms
• operator action Events
• system triggers (such as new orders to be processed)
The term Error! Unknown document property name. is used when referencing aspects of the specification
that apply to accessing historical Events only.
Modified values
Error! Unknown document property name.’s value that has been changed
NOTE A modified value is a Error! Unknown document property name.’s value that has been changed (or
manually inserted or deleted) after it was stored in the historian. For some servers, a lab data entry value is
not a modified value, but if a user corrects a lab value, the original value would be considered a modified value,
and would be returned during a request for modified values. Also manually inserting a value that was missed
by a standard collection system may be considered a modified value. Unless specified otherwise, all historical
Services operate on the current, or most recent, value for the specified Error! Unknown document property
name. at the specified timestamp. Requests for modified values are used to access values that have been
superseded, deleted or inserted. It is up to a system to determine what is considered a modified value.
Whenever a server has modified data available for an entry in the historical collection it shall set the ExtraData
bit in the StatusCode.
Raw data
data that is stored within the historian for a Error! Unknown document property name.
NOTE Raw data is data that is stored within the historian for a Error! Unknown document property name.
. The data may be all data collected for the DataValue or it may be some subset of the data depending on the
historian and the storage rules invoked when the item’s values were saved.
StartTime / EndTime
the bounds of a history request and define the time domain
NOTE The StartTime and EndTime specify the bounds of a history request and define the time domain of the
request. For all requests, a value falling at the end time of the time domain is not included in the domain, so
that requests made for successive, contiguous time domains will include every value in the historical collection
exactly once.
TimeDomain
interval of time covered by a particular request, or response
NOTE The interval of time covered by a particular request, or by a particular response. In general, if the start
time is earlier than or the same as the end time, the time domain is considered to begin at the start time and
end just before the end time; if the end time is earlier than the start time, the time domain still begins at the
start time and ends just before the end time, with time "running backward" for the particular request and
response. In both cases, any value which falls exactly at the end time of the TimeDomain is not included in the

TimeDomain. See the examples in the [UA Part 11]. BoundingValues effect the time domain as described in the
[UA Part 11].
All timestamps which can legally be represented in an UtcTime DataType are valid timestamps, and the server
may not return an invalid argument result code due to the timestamp being outside of the range for which the
server has data. See [UA Part 3] for a description of the range and granularity of this DataType. Servers are
expected to handle out-of-bounds timestamps gracefully, and return the proper StatusCodes to the Client.
Structured History Data

structured data stored in a history collection where parts of the structure are used to uniquely identify the data
NOTE Structured History Data is structured data stored in a history collection where one or more parameters
of the structure are used to uniquely identify the data within the data collection. Most historical data
applications assume only one current value per timestamp. Therefore the timestamp of the data is considered
the unique identifier for that value. Some data or meta data such as Annotations may permit multiple values to
exist at a single timestamp. In such cases the Server would use one or more parameters of the Structured
History Data entry to uniquely identifiy each within the history collection. Annotations are examples of
Structured History Data.

DA Data Access

4.1.3.12 OPC UA Discovery
4.1.3.12.1 Terms
CertificateManagement Server
a software application that manages the Certificates used by Applications in an enterprise.
DirectoryService
a software application, or a set of applications, that stores and organizes information about network resources
such as computers or services.
DiscoveryServer
an Application that maintains a list of OPC UA Servers that are available on the network and provides
mechanisms for Clients to obtain this list.
DiscoveryUrl
a URL for a network Endpoint that provides the information required to connect to a Server.
GlobalDiscoveryServer (GDS)
a DiscoveryServer that maintains a list of OPC UA Applications available in an enterprise.
Note: a GDS may also provide certificate management services.
IPAddress
a unique number assigned to a network interface that allows Internet Protocol (IP) requests to be routed to
that interface.
Note: An IPAddress for a host may change over time.
LocalDiscoveryServer (LDS)
a DiscoveryServer that maintains a list of all Servers that have registered with it.
Note: Servers normally register with the LDS on the same host.
LocalDiscoveryServer-ME (LDS-ME)
a LocalDiscoveryServer that includes the MulticastExtension.
MulticastExtension
an extension to a LocalDiscoveryServer that adds support for the mDNS protocol.
MulticastSubnet
a network that allows multicast packets to be sent to all nodes connected to the network.
Note: a MulticastSubnet is not necessarily the same as a TCP/IP subnet.
ServerCapabilityIdentifier
a short identifier which uniquely identifies a set of discoverable capabilities supported by a Server.
Note: the OPC Foundation maintains a list of the currently defined ServerCapabilityIdentifiers.

GDS Global Directory Server
IANA The Internet Assigned Numbers Authority
LDS Local Discovery Server
LDS-ME Local Discovery Server with the Multicast Extension.
TLS Transport Layer Security
DCHP Dynamic Host Configuration Protocol
DNS Domain Name System
UDDI Universal Description, Discovery and Integration
LDAP Lightweight Directory Access Protocol
mDNS Multicast Domain Name System
DER Distinguished Encoding Rules
SHA1 Secure Hash Algorithm
PEM Privacy Enhanced Mail
PFX Personal Information Exchange

4.1.3.13 OPC UA Aggregates
4.1.3.13.1 Terms
Aggregate
way to produce derived values from Raw data
NOTE Provides summarized data values. An Aggregate is a way to produce a set of values derived from the
Raw data. This Raw data may be from a historian or buffered real time data. Clients may specify an Aggregate
when using the HistoryRead service or as part of a Subscription as a filter. Complete details of the various
standard Aggregates and their behaviour are outlined in [UA Part 13]. Common Aggregates include averages
over a given time range, minimum over a time range and maximum over a time range.
ProcessingInterval
the amount of time that lies between two bounding timestamps
NOTE A ProcessingInterval is the amount of time that lies between two bounding timestamps, and represents
the subsection of a given time range an Aggregate is applied over. For example, performing a 10 minute
Average over the time range 12:00-12:30 would result in a set of three intervals of ProcessingInterval length,
with each interval having a start time of 12:00, 12:10 and 12:20 respectively. The rules used to determine
interval Bounds are discussed in [UA Part 13].
Interpolated
calculated from data samples
NOTE Interpolated data is data that is calculated from data samples; this may be historical data or buffered
real time data. An interpolated value is calculated from the data points on either side of the requested
timestamp. The document refers to two types of interpolation, depending on how the data is represented.
EffectiveEndTime
time immediately before endTime
NOTE All Aggregate calculations include the startTime but exclude the endTime. However, it is sometimes
necessary to return an Interpolated End Bound as the value for an Interval with a timestamp that is in the
interval. Servers are expected to use the time immediately before endTime where the time resolution of the
Server determines the exact value (do not confuse this with hardware or operating system time resolution).
For example, if the endTime is 12:01:00, the time resolution is 1 second then the EffectiveEndTime is 12:00:59.
If the Server time resolution is 1 millisecond the EffectiveEndTime is 12:00:59.999. See [UA Part 13].
If time is flowing backwards, Servers are expected to use the time immediately after endTime where the time
resolution of the Server determines the exact value.
Extrapolated
data constructed from a discrete data set but is outside of the discrete data set
NOTE Extrapolated data is data that is constructed from a discrete data set but is outside of the discrete data
set. It is similar to the process of interpolation, which constructs new points between known points, but its
result is subject to greater uncertainty. Extrapolated data is used in cases where the requested time period falls
farther into the future than the data available in the underlying system. See example in Table 1.

SlopedInterpolation
simple linear interpolation
NOTE SlopedInterpolation and/or SlopedExtrapolation refer to simple linear interpolation, as in the method of
curve fitting using linear polynomials. See example in Table 1.
SteppedInterpolation
interpolating the value based on a horizontal line fit
NOTE SteppedInterpolation and/or SteppedExtrapolation refers to holding the last data point constant, or
interpolating the value based on a horizontal line fit.
For example, consider the following table of raw and Interpolated/Extrapolated values:
Table 1 – Interpolation Examples

Timestamp Raw Value Sloped Interpolation Stepped Interpolation
12:00:00 10
12:00:05 15 10
12:00:08 18 10
12:00:10 20
12:00:15 25 20
12:00:20 30
SlopedExtrapolation SteppedExtrapolation
12:00:25 35 30
12:00:27 37 30
Bounding Values
values at the startTime and endTime
NOTE Many Aggregates require values at the startTime and endTime in order to compute the result. These
values are called Bounding Values. If Raw data does not exist at these times a value must be estimated. There
are two ways to determine Bounding Values for an interval. One way (called Interpolated Bounding Values)
uses the first non-Bad data points found before and after the timestamp to estimate the bound. The other
(called Simple Bounding Values) uses the data points immediately before and after the boundary timestamps to
estimate the bound even if these points are bad.
In all cases the TreatUncertainAsBad (see [UA Part 13]) flag is used to determine whether uncertain values
are Bad or non-Bad.
If a Raw value was not found and a non-Bad bounding value exists the Aggregate Bits (see [UA Part 13]) are
set to ‘Interpolated’.
When calculating bounding values; the value portion of Raw data that has Bad status is set to null. This means
the value portion is not used in any calculation and a null is returned if the raw value is returned. The status
portion is determined by the rules specified by the bound or aggregate.
The Interpolated Bounding Values approach (see [UA Part 13]) is the same as what is used in Classic OPC
Historical Data Access (HDA) and is important for applications such as advanced process control where having

useful values at all times is important. The Simple Bounding Values approach (see [UA Part 13]) is new in this
specification and is important for applications which must produce regulatory reports and cannot use
estimated values in place of Bad data.
Interpolated Bounding Values

Bounding Values determined by a calculation using the nearest good value
NOTE Interpolated Bounding Values using SlopedInterpolation are calculated as follows:
• If a non-Bad Raw value exists at the timestamp then it is the bounding value;
• Find the first non-Bad Raw value before the timestamp;
• Find the first non-Bad Raw value after the timestamp;
• Draw a line between before value and after value;
• Use point where the line crosses the timestamp as an estimate of the bounding value;
The calculation can be expressed with the following formula:
Vbound = (Tbound – Tbefore)*(Vafter – Vbefore)/(Tafter – Tbefore) + Vbefore
Where Vx is a value at ‘x’ and Tx is the timestamp associated with Vx.
If no non-Bad values exist before the timestamp the StatusCode is Bad_NoData. The StatusCode is
Uncertain_DataSubNormal if any Bad values exist between the before value and after value. If either the
before value or the after value are Uncertain the StatusCode is Uncertain_DataSubNormal. If the after value
does not exist the before value must be extrapolated using SlopedExtrapolation or SteppedExtrapolation.
The period of time that is searched to discover the good values before and after the timestamp is server
dependent, but if a good value is not found within some reasonable time range then the server will assume it
does not exist. The server as a minimum should search a time range which is at least the size of the
ProcessingInterval.
Interpolated Bounding Values using SlopedExtrapolation are calculated as follows:
• Find the first non-Bad Raw value before timestamp;
• Find the second non-Bad Raw value before timestamp;
• Draw a line between these two values;
• Extend the line to where it crosses the timestamp;
• Use the point where the line crosses the timestamp as an estimate of the bounding value;
The formula is the same as the one used for SlopedInterpolation.
The StatusCode is always Uncertain_DataSubNormal. If only one non-Bad raw value can be found before the
timestamp then SteppedExtrapolation is used to estimate the bounding value.
Interpolated Bounding Values using SteppedInterpolation are calculated as follows:
• If a non-Bad Raw value exists at the timestamp then it is the bounding value;
• Find the first non-Bad Raw value before timestamp;
• Use the value as an estimate of the bounding value;
The StatusCode is Uncertain_DataSubNormal if any Bad values exist between the before value and the
timestamp. If no non-Bad Raw data exists before the timestamp then the StatusCode is Bad_NoData. If the
value before the timestamp is Uncertain the StatusCode is Uncertain_DataSubNormal. The value after the

timestamp is not needed when using SteppedInterpolation; however, if the timestamp is after the end of the
data then the bounding value is treated as extrapolated and the StatusCode is Uncertain_DataSubNormal.
SteppedExtrapolation is a term that describes SteppedInterpolation when a timestamp is after the last value in
the history collection.
Simple Bounding Values

Bounding Values determined by a calculation using the nearest value
NOTE Simple Bounding Values using SlopedInterpolation are calculated as follows:
• If any Raw value exists at the timestamp then it is the bounding value;
• Find the first Raw value before timestamp;
• Find the first Raw value after timestamp;
• If the value after the timestamp is Bad then the before value is the bounding value;
• Draw a line between before value and after value;
• Use point where the line crosses the timestamp as an estimate of the bounding value;
The formula is the same as the one used for SlopedInterpolation.
If a Raw value at the timestamp is Bad the StatusCode is Bad_NoData. If the value before the timestamp is Bad
the StatusCode is Bad_NoData. If the value before the timestamp is Uncertain the StatusCode is
Uncertain_DataSubNormal. If the value after the timestamp is Bad or Uncertain the StatusCode is
Uncertain_DataSubNormal.
Simple Bounding Values using SteppedInterpolation are calculated as follows:
• If any Raw value exists at the timestamp then it is the bounding value;
• Find the first Raw value before timestamp;
• If the value before timestamp is non-Bad then it is the bounding value;
If a Raw value at the timestamp is Bad the StatusCode is Bad_NoData. If the value before the timestamp is Bad
the StatusCode is Bad_NoData. If the value before the timestamp is Uncertain the StatusCode is
Uncertain_DataSubNormal.
If either bounding time of an interval is beyond the last data point then extrapolation may be used if the Server
feels it is appropriate for the data.
In some Historians, the last Raw value does not necessarily indicate the end of the data. Based on the
Historian's knowledge of the data collection mechanism, i.e. frequency of data updates and latency, the
Historian may extend the last value to a time known by the Historian to be covered. When calculating Simple
Bounding Values the Historian will act as if there is another Raw value at this timestamp.
In the same way, if the earliest time of an interval starts before the first data point in history and the latest time
is after the first data point in history, then the interval will be treated as if the interval extends from the first
data point in history to the latest time of the interval and the StatusCode of the interval will have the Partial bit
set [See [UA Part 13]].
The period of time that is searched to discover the values before and after the timestamp is server dependent,
but if a value is not found within some reasonable time range then the server will assume it does not exist. The
server as a minimum should search a time range which is at least the size of the ProcessingInterval.

DA Data Access

4.2 Security
4.2.1 Overview
4.2.1.1 Environment
OPC UA is a protocol used between components in the operation of an industrial facility at multiple levels:
from high-level enterprise management to low-level direct process control of a device. The use of OPC UA for
enterprise management involves dealings with customers and suppliers. It may be an attractive target for
industrial espionage or sabotage and may also be exposed to threats through untargeted malware, such as
worms, circulating on public networks. Disruption of communications at the process control end causes at
least an economic cost to the enterprise and can have employee and public safety consequences or cause
environmental damage. This may be an attractive target for those who seek to harm the enterprise or society.
OPC UA will be deployed in a diverse range of operational environments, with varying assumptions about
threats and accessibility, and with a variety of security policies and enforcement regimes. OPC UA, therefore,
provides a flexible set of security mechanisms. Figure 1 - OPC UA Network Model is a composite that shows a
combination of such environments. Some OPC UA Clients and Servers are on the same host and can be more
easily protected from external attack. Some Clients and Servers are on different hosts in the same operations
network and might be protected by the security boundary protections that separate the operations network
from external connections. Some OPC UA Applications run in relatively open environments where users and
applications might be difficult to control. Other applications are embedded in control systems that have no
direct electronic connection to external systems.
Internet
OPC Client S CA
Ted
Enterprise Network
S S
Attacker
Attacker OPC Server S
Eve
OPC Client CA OPC Client

Bob Theresa
Operations Network OPC Client
OPC Server OPC Server

Alice
OPC Client OPC Client
Plant Floor Network
OPC Server OPC Server

S = Security
Boundary
Protection
Figure 1 - OPC UA Network Model

OPC UA Applications may run at different places in this wide range of environments. Clients and Servers may
communicate within the same host or between hosts within the highly protected control network.
Alternatively, OPC UA Clients and Servers may communicate in the much more open environment over the
Internet. The OPC UA activities are protected by whatever security controls the site provides to the parts of the
system within which OPC UA Applications run.
Fundamentally, information system security reduces the risk of damage from attacks. It does this by identifying
the threats to the system, identifying the system’s vulnerabilities to these threats, and providing
countermeasures. The countermeasures reduce vulnerabilities directly, counteract threats, or recover from
successful attacks.
Industrial automation system security is achieved by meeting a set of objectives. These objectives have been
refined through many years of experience in providing security for information systems in general and they
remain quite constant despite the ever-changing set of threats to systems. They are described in [UA Part 2].
Following the sections that describe the OPC UA security architecture and functions, [UA Part 2] reconciles
these objectives against the OPC UA functions. [UA Part 2] offers additional best practice guidelines to Client
and Server developers or those that deploy OPC UA Applications.
4.2.1.2 Authentication
Entities such as clients, Servers, and users should prove their identities. Authentication can be based on
something the entity is, has, or knows.
4.2.1.3 Authorization
The access to read, write, or execute resources should be authorized for only those entities that have a need
for that access within the requirements of the system. Authorization can be as coarse-grained as allowing or
disallowing a Client to access a Server or it could be much finer grained, such as allowing specific actions on
specific information items by specific users.
4.2.1.4 Confidentiality
Data must be protected from passive attacks, such as eavesdropping, whether the data is being transmitted, in
memory, or being stored. To provide Confidentiality, data encryption algorithms using special secrets for
securing data are used along with Authentication and Authorization mechanisms for accessing that secret.
4.2.1.5 Integrity
Receivers must receive the same information that the sender sent, without the data being changed during
transmission.
4.2.1.6 Auditability
Actions taken by a system have to be recorded in order to provide evidence to stakeholders that this system
works as intended and to identify the initiator of certain actions and that attempts to compromise the system
were denied.
4.2.1.7 Availability
Availability is impaired when the execution of software that needs to run is turned off or when software or the
communication system is overwhelmed processing input. Impaired Availability in OPC UA can appear as
slowing down of Subscription performance or inability to add sessions for example.

4.2.2 Security Architecture
The OPC UA security architecture is a generic solution that allows implementation of the required security
features at various places in the OPC UA Application architecture. Depending on the different mappings
described in [UA Part 6] , the security objectives are addressed at different levels. The OPC UA Security
Architecture is structured in an Application Layer and a Communication Layer atop the Transport Layer as
shown in Figure 2 – OPC UA Security Architecture.
OPC UA Client OPC UA Server
Application Layer Application Layer

• User Authorization Session • User Authorization
• User Authentication • User Authentication
Communication Layer Communication Layer

• Confidentiality Secure Channel • Confidentiality
• Integrity • Integrity
• App Authentication • App Authentication
Transport Layer
Figure 2 – OPC UA Security Architecture
The routine work of a Client application and a Server application to transmit information, settings, and
commands is done in a session in the Application Layer. The Application Layer also manages the security
objectives user Authentication and user Authorization. The security objectives that are managed by the
Application Layer are addressed by the Session Services that are specified in [UA Part 4]. A session in the
Application Layer communicates over a Secure Channel that is created in the Communication Layer and relies
upon it for secure communication. All of the session data is passed to the Communication Layer for further
processing.
Although a session communicates over a Secure Channel and has to be activated before it can be used, the
binding of users, sessions, and Secure Channels is flexible.
Impersonation allows the user of the session to change. A session can have a different user than the user that
activated the session for the first time, since user credentials are not validated before activating a session.
When a Secure Channel breaks, the session will remain valid and the Client will be able to re-establish the
Secure Channel, otherwise the session closes after its lifetime expires.
The Communication Layer provides security mechanisms to meet Confidentiality, Integrity and application
Authentication as security objectives.
One essential mechanism to meet the above mentioned security objectives is to establish a Secure Channel (see
[UA Part 2]) that is used to secure the communication between a Client and a Server. The Secure Channel
provides encryption to maintain Confidentiality, Message Signatures to maintain Integrity and Digital
Certificates to provide application Authentication for data that comes from the Application Layer and passes
the “secured” data to the Transport Layer. The security mechanisms that are managed by the Communication
Layer are provided by the Secure Channel Services that are specified in [UA Part 4].

The security mechanisms provided by the Secure Channel services are implemented by a protocol stack that is
chosen for the implementation. Mappings of the services to some of the protocol stack options are specified in
[UA Part 6] , which details how the functions of the protocol stack are used to meet the OPC UA security
objectives.
The Communication Layer can represent an OPC UA protocol stack. OPC UA specifies alternative stack
mappings that can be used as the Communication Layer. These mappings are described in [UA Part 6] .
If the OPC UA Native mapping is used, then functionalities for Confidentiality, Integrity, application
Authentication, and the Secure Channel are similar to the SSL/TLS specifications, as described in detail in
[UA Part 6] .
If the Web Services mapping is used, then WS Security, WS Secure Conversation and XML Encryption as well as
XML Signature: are used to implement the mechanisms for Confidentiality, Integrity, application Authentication
as well as for implementing a Secure Channel. For more specific information, see [UA Part 6] .
The Transport Layer handles the transmission, reception and the transport of data that is provided by the
Communication Layer.
To survive the loss of the Transport Layer connections (e.g. TCP connections) and resume with a new
connection, the Communication Layer is responsible for re-establishing the Transport Layer connection
without interrupting the logical Secure Channel.

4.3 Address Space
The primary objective of the OPC UA AddressSpace is to provide a standard way for Servers to represent
Objects to Clients. The OPC UA Object Model has been designed to meet this objective. It defines Objects in
terms of Variables and Methods. It also allows relationships to other Objects to be expressed. Figure 3 – OPC
UA Object ModelFigure 3 illustrates the model.
Object
Data change
Notifications
Variables
_________
Read/Write _________
_________
References to
other Objects
Invoke Methods
_____()
_____()
_____()
Event
Notifications
Figure 3 – OPC UA Object Model
The elements of this model are represented in the AddressSpace as Nodes. Each Node is assigned to a
NodeClass and each NodeClass represents a different element of the Object Model.
4.3.1 Node Model
4.3.1.1 General
The set of Objects and related information that the OPC UA Server makes available to Clients is referred to as
its AddressSpace. The model for Objects is defined by the OPC UA Object Model.
Objects and their components are represented in the AddressSpace as a set of Nodes described by Attributes
and interconnected by References. Figure 4 – AddressSpace Node Model illustrates the model of a Node and
the remainder of this subclause discusses the details of the Node Model.
Node
Attributes Attributes describe a node

_____
_____ References define relationships
to other nodes
References
_____ Node
_____
Figure 4 – AddressSpace Node Model

4.3.1.2 NodeClasses
NodeClasses are defined in terms of the Attributes and References that shall be instantiated (given values)
when a Node is defined in the AddressSpace. Attributes are discussed in 4.3.1.3 and References in 4.3.1.4.
[UA Part 3] defines the NodeClasses for the OPC UA AddressSpace. These NodeClasses are referred to
collectively as the metadata for the AddressSpace. Each Node in the AddressSpace is an instance of one of
these NodeClasses. No other NodeClasses shall be used to define Nodes, and as a result, Clients and Servers are
not allowed to define NodeClasses or extend the definitions of these NodeClasses.
4.3.1.3 Attributes
Attributes are data elements that describe Nodes. Clients can access Attribute values using Read, Write, Query,
and Subscription/MonitoredItem Services. These Services are defined in [UA Part 4].
Attributes are elementary components of NodeClasses. Attribute definitions are included as part of the
NodeClass definitions and, therefore, are not included in the AddressSpace.
Each Attribute definition consists of an attribute id (for attribute ids of Attributes, see [UA Part 6] ), a name, a
description, a data type and a mandatory/optional indicator. The set of Attributes defined for each NodeClass
shall not be extended by Clients or Servers.
When a Node is instantiated in the AddressSpace, the values of the NodeClass Attributes are provided. The
mandatory/optional indicator for the Attribute indicates whether the Attribute has to be instantiated.
4.3.1.4 References
References are used to relate Nodes to each other. They can be accessed using the browsing and querying
Services defined in [UA Part 4].
Like Attributes, they are defined as fundamental components of Nodes. Unlike Attributes, References are
defined as instances of ReferenceType Nodes. ReferenceType Nodes are visible in the AddressSpace and are
defined using the ReferenceType NodeClass.
The Node that contains the Reference is referred to as the SourceNode and the Node that is referenced is
referred to as the TargetNode. The combination of the SourceNode, the ReferenceType and the TargetNode are
used in OPC UA Services to uniquely identify References. Thus, each Node can reference another Node with the
same ReferenceType only once. Any subtypes of concrete ReferenceTypes are considered to be equal to the
base concrete ReferenceTypes when identifying References. Figure 5 – Reference Model illustrates this model
of a Reference.
SourceNode
*ReferenceName TargetNode
* Name of the Reference’s ReferenceType
Figure 5 – Reference Model
The TargetNode of a Reference may be in the same AddressSpace or in the AddressSpace of another OPC UA
Server. TargetNodes located in other Servers are identified in OPC UA Services using a combination of the
remote Server name and the identifier assigned to the Node by the remote Server.
OPC UA does not require that the TargetNode exists, thus References may point to a Node that does not exist.

4.3.2 Variables
4.3.2.1 General
Variables are used to represent values. Two types of Variables are defined, Properties and DataVariables. They
differ in the kind of data that they represent and whether they can contain other Variables.
4.3.2.2 Properties
Properties are Server-defined characteristics of Objects, DataVariables and other Nodes. Properties differ from
Attributes in that they characterise what the Node represents, such as a device or a purchase order. Attributes
define additional metadata that is instantiated for all Nodes from a NodeClass. Attributes are common to all
Nodes of a NodeClass and only defined by this specification whereas Properties can be Server-defined.
For example, an Attribute defines the DataType of Variables whereas a Property can be used to specify the
engineering unit of some Variables.
To prevent recursion, Properties are not allowed to have Properties defined for them. To easily identify
Properties, the BrowseName of a Property shall be unique in the context of the Node containing the Properties.
A Node and its Properties shall always reside in the same Server.
4.3.2.3 DataVariables
DataVariables represent the content of an Object. For example, a file Object may be defined that contains a
stream of bytes. The stream of bytes may be defined as a DataVariable that is an array of bytes. Properties may
be used to expose the creation time and owner of the file Object.
For example, if a DataVariable is defined by a data structure that contains two fields, “startTime” and
“endTime” then it might have a Property specific to that data structure, such as “earliestStartTime”.
As another example, function blocks in control systems might be represented as Objects. The parameters of
the function block, such as its setpoints, may be represented as DataVariables. The function block Object might
also have Properties that describe its execution time and its type.
DataVariables may have additional DataVariables, but only if they are complex. In this case, their DataVariables
shall always be elements of their complex definitions. Following the example introduced by the description of
Properties in 4.3.2.2, the Server could expose “startTime” and “endTime” as separate components of the data
structure.
As another example, a complex DataVariable may define an aggregate of temperature values generated by
three separate temperature transmitters that are also visible in the AddressSpace. In this case, this complex
DataVariable could define HasComponent References from it to the individual temperature values that it is
composed of.
4.3.3 TypeDefinitionNodes
4.3.3.1 General
OPC UA Servers shall provide type definitions for Objects and Variables. The HasTypeDefinition Reference shall
be used to link an instance with its type definition represented by a TypeDefinitionNode. Type definitions are
required, however, [UA Part 5] defines a BaseObjectType, a PropertyType, and a BaseDataVariableType so a
Server can use such a base type if no more specialised type information is available. Objects and Variables
inherit the Attributes specified by their TypeDefinitionNode.
In some cases, the NodeId used by the HasTypeDefinition Reference will be well-known to Clients and Servers.
Organizations may define TypeDefinitionNodes that are well-known in the industry. Well-known NodeIds of
TypeDefinitionNodes provide for commonality across OPC UA Servers and allow Clients to interpret the
TypeDefinitionNode without having to read it from the Server. Therefore, Servers may use well-known NodeIds

without representing the corresponding TypeDefinitionNodes in their AddressSpace. However, the
TypeDefinitionNodes shall be provided for generic Clients. These TypeDefinitionNodes may exist in another
Server.
The following example, illustrated in Figure 6 – Example of a Variable Defined by a VariableType, describes
the use of the HasTypeDefinition Reference. In this example, a setpoint parameter “SP” is represented as a
DataVariable in the AddressSpace. This DataVariable is part of an Object not shown in the figure.
To provide for a common setpoint definition that can be used by other Objects, a specialised VariableType is
used. Each setpoint DataVariable that uses this common definition will have a HasTypeDefinition Reference
that identifies the common “SetPoint” VariableType.
TypeDefinitionNodes
Variable defined by
a VariableType. Variable
Inherited Value may “SP” VariableType
be overridden. “SetPoint”
References
HasTypeDefinition Attributes
This value is dynamic, but its initial Value
value is inherited from the value of the Attributes ______
VariableType. The inherited value may Value
be overridden when the Variable is ______
created by the server.
Figure 6 – Example of a Variable Defined by a VariableType

4.3.3.2 Complex TypeDefinitionNodes and their InstanceDeclarations
TypeDefinitionNodes can be complex. A complex TypeDefinitionNode also defines References to other Nodes as
part of the type definition. The ModellingRules specify how those Nodes are handled when creating an instance
of the type definition.
A TypeDefinitionNode references instances instead of other TypeDefinitionNodes to allow unique names for
several instances of the same type, to define default values and to add References for those instances that are
specific to this complex TypeDefinitionNode and not to the TypeDefinitionNode of the instance. For example, in
Figure 7 – Example of a Complex TypeDefinition the ObjectType “AI_BLK_TYPE”, representing a function
block, has a HasComponent Reference to a Variable “SP” of the VariableType “SetPoint”. “AI_BLK_TYPE” could
have an additional setpoint Variable of the same type using a different name. It could add a Property to the
Variable that was not defined by its TypeDefinitionNode “SetPoint”. And it could define a default value for
“SP”, that is, each instance of “AI_BLK_TYPE” would have a Variable “SP” initially set to this value.
TypeDefinitionNodes ObjectType VariableType

“AI_BLK_TYPE” “SetPoint”
References Attributes
HasComponent Value
______ ______
Variable Variable defined by a

“SP” VariableType.
Used by a TypeDefinitionNode
References and is therefore an
HasTypeDefinition InstanceDeclaration
Attributes
Value This value is not
______ dynamic. Inherited value
may be overridden.
Figure 7 – Example of a Complex TypeDefinition
This approach is commonly used in object-oriented programming languages in which the variables of a class
are defined as instances of other classes. When the class is instantiated, each variable is also instantiated, but
with the default values (constructor values) defined for the containing class. That is, typically, the constructor
for the component class runs first, followed by the constructor for the containing class. The constructor for the
containing class may override component values set by the component class.
To distinguish instances used for the type definitions from instances that represent real data, those instances
are called InstanceDeclarations. However, this term is used to simplify this specification, if an instance is an
InstanceDeclaration or not is only visible in the AddressSpace by following its References. Some instances may
be shared and therefore referenced by TypeDefinitionNodes, InstanceDeclarations and instances. This is similar
to class variables in object-oriented programming languages.

4.3.3.3 Subtyping
This standard allows subtyping of type definitions. The subtyping rules are defined in [UA Part 3]. Subtyping of
ObjectTypes and VariableTypes allows:
• Clients that only know the supertype are able to handle an instance of the subtype as if it were an
instance of the supertype;
• instances of the supertype can be replaced by instances of the subtype;
• specialised types that inherit common characteristics of the base type.
In other words, subtypes reflect the structure defined by their supertype but may add additional characteristics.
For example, a vendor may wish to extend a general “TemperatureSensor” VariableType by adding a Property
providing the next maintenance interval. The vendor would do this by creating a new VariableType which is a
TargetNode for a HasSubtype reference from the original VariableType and adding the new Property to it.
4.3.3.4 Instantiation of complex TypeDefinitionNodes
The instantiation of complex TypeDefinitionNodes depends on the ModellingRules. However, the intention is
that instances of a type definition will reflect the structure defined by the TypeDefinitionNode. Figure 8 –
Object and its Components defined by an ObjectType shows an instance of the TypeDefinitionNode
“AI_BLK_TYPE”, where the ModellingRule Mandatory was applied for its containing Variable. Thus, an
instance of “AI_BLK_TYPE”, called AI_BLK_1”, has a HasTypeDefinition Reference to “AI_BLK_TYPE”. It also
contains a Variable “SP” having the same BrowseName as the Variable “SP” used by the TypeDefinitionNode
and thereby reflects the structure defined by the TypeDefinitionNode.
Type Definition ObjectType Variable Type

Nodes “AI_BLK_TYPE” “SetPoint”
References Attributes
HasComponent Variable defined by a Value
______ VariableType. ______
Object Variable
“AI_BLK_1” Variable defined by “SP”
being part of the
References ObjectType. References
HasTypeDefinition HasTypeDefinition
HasComponent ______
This value is not
______ dynamic. Inherited value
Variable
Attributes may be overridden.
“SP”
Value
References
This value is dynamic, but
HasTypeDefinition
its initial value is inherited.
______
The inherited value may
be overridden when the
variable is created by the Attributes
server. Value
Figure 8 – Object and its Components defined by an ObjectType
A client knowing the ObjectType “AI_BLK_TYPE” can use this knowledge to directly browse to the containing
Nodes for each instance of this type. This allows programming against the TypeDefinitionNode. For example, a
graphical element may be programmed in the client that handles all instances of “AI_BLK_TYPE” in the same
way by showing the value of “SP”.

There are several constraints related to programming against the TypeDefinitionNode. A TypeDefinitionNode
or an InstanceDeclaration shall never reference two Nodes having the same BrowseName using hierarchical
References in forward direction. Instances based on InstanceDeclarations shall always keep the same
BrowseName as the InstanceDeclaration they are derived from. A special Service defined in [UA Part 4] called
TranslateBrowsePathsToNodeIds may be used to identify the instances based on the InstanceDeclarations.
Using the simple Browse Service might not be sufficient since the uniqueness of the BrowseName is only
required for TypeDefinitionNodes and InstanceDeclarations, not for other instances. Thus, “AI_BLK_1” may
have another Variable with the BrowseName “SP”, although this one would not be derived from an
InstanceDeclaration of the TypeDefinitionNode.
Instances derived from an InstanceDeclaration shall be of the same TypeDefinitionNode or a subtype of this
TypeDefinitionNode.
A TypeDefinitionNode and its InstanceDeclarations shall always reside in the same Server. However, instances
may point with their HasTypeDefinition Reference to a TypeDefinitionNode in a different Server.
4.3.4 Event Model

4.3.4.1 General
The Event Model defines a general purpose eventing system that can be used in many diverse vertical markets.
Events represent specific transient occurrences. System configuration changes and system errors are examples
of Events. Event Notifications report the occurrence of an Event. Events defined in this document are not
directly visible in the OPC UA AddressSpace. Objects and Views can be used to subscribe to Events. The
EventNotifier Attribute of those Nodes identifies if the Node allows subscribing to Events. Clients subscribe to
such Nodes to receive Notifications of Event occurrences.
Event Subscriptions use the Monitoring and Subscription Services defined in [UA Part 4] to subscribe to Event
Notifications of a Node.
Any OPC UA Server that supports eventing shall expose at least one Node as EventNotifier. The Server Object
defined in [UA Part 5] is used for this purpose. Events generated by the Server are available via this Server
Object. A Server is not expected to produce Events if the connection to the event source is down for some
reason (i.e. the system is offline).
Events may also be exposed through other Nodes anywhere in the AddressSpace. These Nodes (identified via
the EventNotifier Attribute) provide some subset of the Events generated by the Server. The position in the
AddressSpace dictates what this subset will be. For example, a process area Object representing a functional
area of the process would provide Events originating from that area of the process only. It should be noted that
this is only an example and it is fully up to the Server to determine what Events should be provided by which
Node.

4.3.4.2 EventTypes
Each Event is of a specific EventType. A Server may support many types. This part defines the BaseEventType
that all other EventTypes derive from. It is expected that other companion specifications will define additional
EventTypes deriving from the base types defined in this part.
The EventTypes supported by a Server are exposed in the AddressSpace of a Server. EventTypes are
represented as ObjectTypes in the AddressSpace and do not have a special NodeClass associated to them.
[UA Part 5] defines how a Server exposes the EventTypes in detail.
EventTypes defined in this document are specified as abstract and therefore never instantiated in the
AddressSpace. Event occurrences of those EventTypes are only exposed via a Subscription. EventTypes exist in
the AddressSpace to allow Clients to discover the EventType. This information is used by a client when
establishing and working with Event Subscriptions. EventTypes defined by other parts of this standard or
companion specifications as well as Server specific EventTypes may be defined as not abstract and therefore
instances of those EventTypes may be visible in the AddressSpace although Events of those EventTypes are
also accessible via the Event Notification mechanisms.
Standard EventTypes are described in [UA Part 3]. Their representation in the AddressSpace is specified in
[UA Part 5].
4.3.4.3 Event Categorization

Events can be categorised by creating new EventTypes which are subtypes of existing EventTypes but do not
extend an existing type. They are used only to identify an event as being of the new EventType. For example,
the EventType DeviceFailureEventType could be subtyped into TransmitterFailureEventType and
ComputerFailureEventType. These new subtypes would not add new Properties or change the semantic
inherited from the DeviceFailureEventType other than purely for categorization of the Events.
Event sources can also be organised into groups by using the Event ReferenceTypes. For example, a Server may
define Objects in the AddressSpace representing Events related to physical devices, or Event areas of a plant or
functionality contained in the Server. Event References would be used to indicate which Event sources
represent physical devices and which ones represent some Server-based functionality. In addition, References
can be used to group the physical devices or Server-based functionality into hierarchical Event areas. In some
cases, an Event source may be categorised as being both a device and a Server function. In this case, two
relationships would be established. Refer to the description of the Event ReferenceTypes for additional
examples.
Clients can select a category or categories of Events by defining content filters that include terms specifying the
EventType of the Event or a grouping of Event sources. The two mechanisms allow for a single Event to be
categorised in multiple manners. A client could obtain all Events related to a physical device or all failures of a
particular device.

4.3.5 Methods
Methods are “lightweight” functions, whose scope is bounded by an owning (see Note) Object, similar to the
methods of a class in object-oriented programming or an owning ObjectType, similar to static methods of a
class. Methods are invoked by a client, proceed to completion on the Server and return the result to the client.
The lifetime of the Method’s invocation instance begins when the client calls the Method and ends when the
result is returned.
NOTE The owning Object or ObjectType is specified in the service call when invoking the Method.
While Methods may affect the state of the owning Object, they have no explicit state of their own. In this
sense, they are stateless. Methods can have a varying number of input arguments and return resultant
arguments. Each Method is described by a Node of the Method NodeClass. This Node contains the metadata
that identifies the Method’s arguments and describes its behaviour.
Methods are invoked by using the Call Service defined in [UA Part 4]. Each Method is invoked within the
context of an existing session. If the session is terminated during Method execution, the results of the Method’s
execution cannot be returned to the client and are discarded. In that case, the Method execution is undefined,
that is, the Method may be executed until it is finished or it may be aborted.
Clients discover the Methods supported by a Server by browsing for the owning Objects References that
identify their supported Methods.

4.4 Services
4.4.1 Service Set Model
The OPC UA Service definitions are abstract descriptions and do not represent a specification for
implementation. The mapping between the abstract descriptions and the Communication Stack derived from
these Services are defined in [UA Part 6] . In the case of an implementation as web services, the OPC UA
Services correspond to the web service and an OPC UA Service corresponds to an operation of the web service.
These Services are organised into Service Sets. Each Service Set defines a set of related Services. The
organisation in Service Sets is a logical grouping used in this standard and is not used in the implementation.
The Discovery Service Set, illustrated in Figure 9 – Discovery Service Set, defines Services that allow a Client to
discover the Endpoints implemented by a Server and to read the security configuration for each of those
Endpoints.
Node Class
Browse Name HasComponent TargetNode
Attributes
____
____
____
References TargetNode
HasComponent
*
*
Figure 9 – Discovery Service Set
The SecureChannel Service Set, illustrated in Figure 10 – SecureChannel Service Set , defines Services that allow
a Client to establish a communication channel to ensure the Confidentiality and Integrity of Messages
exchanged with the Server.
Server
SecureChannel Security Policy

services
Security Token
Figure 10 – SecureChannel Service Set

The Session Service Set, illustrated in Figure 11 – Session Service Set, defines Services that allow the Client to
authenticate the user on whose behalf it is acting and to manage Sessions.
Server
Session
services
Session
Figure 11 – Session Service Set
The NodeManagement Service Set, illustrated in Figure 12 – NodeManagement Service Set, defines Services
that allow the Client to add, modify and delete Nodes in the AddressSpace.
OPC UA Server
OPC UA AddressSpace
Node
Node Node
NodeManagement
Node Node
services
Node Node
Node Node
Figure 12 – NodeManagement Service Set
The View Service Set, illustrated in Figure 13 – View Service Set, defines Services that allow Clients to browse
through the AddressSpace or subsets of the AddressSpace called Views. The Query Service Set allows Clients to
get a subset of data from the AddressSpace or the View.
OPC UA Server
OPC UA AddressSpace
View
View Node
services Node Node
Node Node
Node Node
Query Node Node
services
Figure 13 – View Service Set

The Attribute Service Set is illustrated in Figure 14 – Attribute Service Set . It defines Services that allow Clients
to read and write Attributes of Nodes, including their historical values. Since the value of a Variable is modelled
as an Attribute, these Services allow Clients to read and write the values of Variables.
OPC UA Server
OPC UA AddressSpace
Other Node Types
Attributes
___
___
Object
Attributes
Attribute ___
services ___
Variables
Attributes
___
___
Figure 14 – Attribute Service Set
The Method Service Set is illustrated in Figure 15 – Method Service Set. It defines Services that allow Clients to
call methods. Methods run to completion when called. They may be called with method-specific input
parameters and may return method-specific output parameters.
OPC UA Server
OPC UA Address Space
Object Node
Variables
___
___
Call Methods
service ___()
___()
Figure 15 – Method Service Set

The MonitoredItem Service Set and the Subscription Service Set, illustrated in Figure 16 – MonitoredItem and
Subscription Service Sets, are used together to subscribe to Nodes in the OPC UA AddressSpace.
The MonitoredItem Service Set defines Services that allow Clients to create, modify, and delete MonitoredItems
used to monitor Attributes for value changes and Objects for Events.
These Notifications are queued for transfer to the Client by Subscriptions.
The Subscription Service Set defines Services that allow Clients to create, modify and delete Subscriptions.
Subscriptions send Notifications generated by MonitoredItems to the Client. Subscription Services also provide
for Client recovery from missed Messages and communication failures.
OPC UA Server
OPC UA AddressSpace
Node
Attributes
___
___
MonitoredItem Monitored
services Item
Events
Subscription Subscription
services
Figure 16 – MonitoredItem and Subscription Service Sets
4.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. The error handling for this step is specific to the communication
technology used and is described in [UA Part 6] .
If it succeeds, then it attempts to access each operation identified in the request and perform the requested
operation. For each operation in the request, it generates a separate success/failure code that it includes in a
positive response Message along with any data that is to be returned.
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 implementation of each service request or response handling shall check that each service parameter lies
within the specified range for that parameter.

4.4.3 MonitoredItem Service Set
4.4.3.1 MonitoredItem model
4.4.3.1.1 Overview
Clients define MonitoredItems to subscribe to data and Events. Each MonitoredItem identifies the item
to be monitored and the Subscription to use to send Notifications. The item to be monitored may be
any Node Attribute.
Notifications are data structures that describe the occurrence of data changes and Events. They are
packaged into NotificationMessages for transfer to the Client. The Subscription periodically sends
NotificationMessages at a user-specified publishing interval, and the cycle during which these messages
are sent is called a publishing cycle.
Four primary parameters are defined for MonitoredItems that tell the Server how the item is to be
sampled, evaluated and reported. These parameters are the sampling interva l, the monitoring mode,
the filter and the queue parameter. Figure 17 – MonitoredItem Model illustrates these concepts.
Reporting may The monitoring mode defines whether sampling and

be enabled or reporting of notifications is enabled or disabled
disabled for the
subscription.
f Monitored Item Attribute
The sampling interval

Subscription f Monitored Item Variable defines the cyclic rate
used by the server to
sample the real item.
f Monitored Item Node
Queue attributes describe the

queueing of notifications to a Filters are used to select A monitored item may monitor an attribute,
subscription samples or events to report a value, or a node providing events
Figure 17 – MonitoredItem Model
Attributes, other than the Value Attribute, are only monitored for a change in value. The filter is not
used for these Attributes. Any change in value for these Attributes causes a Notification to be generated.
The Value Attribute is used when monitoring Variables. Variable values are monitored for a change in
value or a change in their status. The filters defined in the OPC UA Specification [UA Part 4] and in
[UA Part 8] are used to determine if the value change is large enough to cause a Notification to be
generated for the Variable.
Objects and views can be used to monitor Events. Events are only available from Nodes where the
SubscribeToEvents bit of the EventNotifier Attribute is set. The filter defined in in the OPC UA
Specification [UA Part 4] is used to determine if an Event received from the Node is sent to the Client.
The filter also allows selecting fields of the EventType that will be contained in the Event such as
EventId, EventType, SourceNode, Time and Description.
OPC UA Specification [UA Part 3] describes the Event model and the base EventTypes.
The Properties of the base EventTypes and the representation of the base EventTypes in the
AddressSpace are specified in OPC UA Specification [UA Part 5] .

4.4.3.1.2 Sampling interval
Each MonitoredItem created by the Client is assigned a sampling interval that is either inherited from
the publishing interval of the Subscription or that is defined specifically to override that rate. A negative
number indicates that the default sampling interval defined by the publishing interval of the
Subscription is requested. The sampling interval indicates the fastest rate at whic h the Server should
sample its underlying source for data changes.
A Client shall define a sampling interval of 0 if it subscribes for Events.
The assigned sampling interval defines a “best effort” cyclic rate that the Server uses to sample the
item from its source. “Best effort” in this context means that the Server does its best to sample at this
rate. Sampling at rates faster than this rate is acceptable, but not necessary to meet the needs of the
Client. How the Server deals with the sampling rate and how often it actually polls its data source
internally is a Server implementation detail. However, the time between values returned to the Client
shall be greater or equal to the sampling interval.
The Client may also specify 0 for the sampling interval, which indicates that the Server should use the
fastest practical rate. It is expected that Servers will support only a limited set of sampling intervals to
optimize their operation. If the exact interval requested by the Client is not supported by the Server,
then the Server assigns to the MonitoredItem the most appropriate interval as determined by the Server.
It returns this assigned interval to the Client. The Server Capabilities Object defined in [UA Part 5]
identifies the sampling intervals supported by the Server.
The Server may support data that is collected based on a sampling model or generated based on an
exception-based model. The fastest supported sampling interval may be equal to 0, which indicates
that the data item is exception-based rather than being sampled at some period. An exception -based
model means that the underlying system does not require sampling and reports dat a changes.
The Client may use the revised sampling interval values as a hint for setting the publishing interval as
well as the keep-alive count of a Subscription. If, for example, the smallest revised sampling interval of
the MonitoredItems is 5 seconds, then the time before a keep-alive is sent should be longer than 5
seconds.
Note that, in many cases, the OPC UA Server provides access to a decoupled system and therefore has
no knowledge of the data update logic. In this case, even though the OPC UA Server samples at the
negotiated rate, the data might be updated by the underlying system at a much slower rate. In this
case, changes can only be detected at this slower rate.
If the behaviour by which the underlying system updates the item is known, it will b e available via the
MinimumSamplingInterval Attribute defined in [UA Part 3] . If the Server specifies a value for the
MinimumSamplingInterval Attribute it shall always return a revisedSamplingInterval that is equal or
higher than the MinimumSamplingInterval if the Client subscribes to the Value Attribute.
Clients should also be aware that the sampling by the OPC UA Server and the update cycle of the underlying
system are usually not synchronized. This can cause additional delays in change detection, as illustrated in
Figure 18 – Typical delay in change detection.

Change detected via
sampling at ”28”.
0 10 20 30 40
Time axis
(s)
Sampling (every
10 s)
Update Cycle of
underlying system
(every 15 s)
Actual change occurs at “12”
Figure 18 – Typical delay in change detection
4.4.3.1.3 Monitoring mode

The monitoring mode parameter is used to enable and disable the sampling of a MonitoredItem, and
also to provide for independently enabling and disabling the reporting of Notifications. This capability
allows a MonitoredItem to be configured to sample, sample and report, or neither. Disabling sampling
does not change the values of any of the other MonitoredItem parameter, such as its sampling interval.
When a MonitoredItem is enabled (i.e. when the MonitoringMode is changed from DISABLED to
SAMPLING or REPORTING) or it is created in the enabled state, the Server shall report the first sample
as soon as possible and the time of this sample becomes the starting point for the next sampling
interval.
4.4.3.1.4 Filter
Each time a MonitoredItem is sampled, the Server evaluates the sample using the filter defined for the
MonitoredItem. The filter parameter defines the criteria that the Server uses to determine if a
Notification should be generated for the sample. The type of filter is dependent on the type of the item
that is being monitored. For example, the DataChangeFilter and the AggregateFilter are used when
monitoring Variable Values and the EventFilter is used when monitoring Events. Sampling and
evaluation, including the use of filters, are described in this standard. Additional filters may be defined
in other parts of this series of standards.

4.4.3.1.5 Queue parameters
If the sample passes the filter criteria, a Notification is generated and queued for transfer by the
Subscription. The size of the queue is defined when the MonitoredItem is created. When the queue is
full and a new Notification is received, the Server either discards the oldest Notification and queues the
new one, or it replaces the last value added to the queue with the new one. The MonitoredItem is
configured for one of these discard policies when the MonitoredItem is created. If a Notification is
discarded for a DataValue and the size of the queue is larger than one, then the Overflow bit (flag) in
the InfoBits portion of the DataValue statusCode is set. If discardOldest is TRUE, the oldest value gets
deleted from the queue and the next value in the queue gets the flag set. If discardOldest is FALSE, the
last value added to the queue gets replaced with the new value. The new value gets the flag se t to
indicate the lost values in the next NotificationMessage. Figure 19 – Queue overflow handling illustrates
the queue overflow handling.
Sampling Sampling Sampling Sampling Sampling Sampling
Value 1 2 3 4 5 6
Node1 Tim e axis
Monitored Item 1
1 2 3 4 5 6
NodeToMonitor = Node1 1 2 3 4 5
Dis cardOldes t = TRUE
1 2 3 4
QueueSize = 4
1 2 3
Overflow
bit s et
Monitored Item 2
1 2 3 4 5 6
NodeToMonitor = Node1 1 2 3 3 3
Dis cardOldes t = FALS E
1 2 2 2
QueueSize = 4
1 1 1
Change of queue content
Figure 19 – Queue overflow handling
If the queue size is one, the queue becomes a buffer that always contains the newest Notification. In
this case, if the sampling interval of the MonitoredItem is faster than the publishing interval of the
Subscription, the MonitoredItem will be over sampling and the Client will always receive the most up-
to-date value. The discard policy is ignored if the queue size is one.
On the other hand, the Client may want to subscribe to a continuous stream of Notifications without
any gaps, but does not want them reported at the sampling interval. In this case, the MonitoredItem
would be created with a queue size large enough to hold all Notifications generated between two
consecutive publishing cycles. Then, at each publishing cycle, the Subscription would send all
Notifications queued for the MonitoredItem to the Client. The Server shall return Notifications for any
particular item in the same order they are in the queue.
The Server may be sampling at a faster rate than the sampling interval to support other Clients; the
Client should only expect values at the negotiated sampling interval. The Server may deliver fewer
values than dictated by the sampling interval, based on the filter and implementation constraints. If a
DataChangeFilter is configured for a MonitoredItem, it is always applied to the newest value in the
queue compared to the current sample.

If, for example, the AbsoluteDeadband in the DataChangeFilter is “10”, the queue could consist of values in the
following order:
• 100
• 111
• 100
• 89
• 100
Queuing of data may result in unexpected behaviour when using a Deadband filter and the number of
encountered changes is larger than the number of values that can be maintained. The new first value
in the queue may not exceed the Deadband limit of the previous value sent to the Client.
The queue size is the maximum value supported by the Server when monitoring Events. In this case,
the Server is responsible for the Event buffer. If Events are lost, an Event of the type
EventQueueOverflowEventType is placed in the queue. This Event is generated when the first Event has
to be discarded on a MonitoredItem subscribing fo r Events. It is put into the Queue of the
MonitoredItem in addition to the size of the Queue defined for this MonitoredItem without discarding
any other Event. If discardOldest is set to TRUE it is put at the beginning of the queue and is never
discarded, otherwise at the end. An aggregating Server shall not pass on such an Event. It shall be
handled like other connection error scenarios.
4.4.3.1.6 Triggering model

The MonitoredItems Service allows adding items that are reported only when some other item (the
triggering item) triggers. This is done by creating links between the triggered items and the items to
report. The monitoring mode of the items to report is set to sampling -only so that it will sample and
queue Notifications without reporting them. Figure 20 – Triggering Model illustrates this concept.
Monitored Item Items to Report are

Triggering item defines monitored items whose
Monitored Item Monitored Item notifications are sent when
a set of triggered items
the triggering item triggers.
Monitored Item Their lifetime is independent
of the lifetime of the triggered
Triggering links link the triggering item with items items that reference them.
to report. These links are defined for the triggering
item and are deleted when the triggering item is
deleted.
Figure 20 – Triggering Model
The triggering mechanism is a useful feature that allows Clients to reduce the data volume on the wire
by configuring some items to sample frequently but only report when some other Event happens.

The following triggering behaviours are specified.
a) If the monitoring mode of the triggering item is SAMPLING, then it is not reported when the triggering item
triggers the items to report.
b) If the monitoring mode of the triggering item is REPORTING, then it is reported when the triggering item
c) If the monitoring mode of the triggering item is DISABLED, then the triggering item does not trigger the
items to report.
d) If the monitoring mode of the item to report is SAMPLING, then it is reported when the triggering item
e) If the monitoring mode of the item to report is REPORTING, this effectively causes the triggering item to be
ignored. All notifications of the items to report are sent after the publishing interval expires.
f) If the monitoring mode of the item to report is DISABLED, then there will be no sampling of the item to
report and therefore no notifications to report.
g) The first trigger shall occur when the first notification is queued for the triggering item after the creation of
the link.
Clients create and delete triggering links between a triggering item and a set of items to report. If the
MonitoredItem that represents an item to report is deleted before its associated triggering link is
deleted, the triggering link is also deleted, but the triggering item is otherw ise unaffected.
Deletion of a MonitoredItem should not be confused with the removal of the Attribute that it monitors.
If the Node that contains the Attribute being monitored is deleted, the MonitoredItem generates a
Notification with a StatusCode Bad_NodeIdUnknown that indicates the deletion, but the MonitoredItem
is not deleted.

4.4.4 Subscription Service Set
4.4.4.1 Subscription model
4.4.4.1.1 Overview
Subscriptions are used to report Notifications to the Client. Their general behaviour is summarized
below. Their precise behaviour is described in the OPC UA Specification [UA Part 4] .
h) Subscriptions have a set of MonitoredItems assigned to them by the Client. MonitoredItems generate
Notifications that are to be reported to the Client by the Subscription (see [UA Part 4] for a description of
MonitoredItems).
i) Subscriptions have a publishing interval. The publishing interval of a Subscription defines the cyclic rate at
which the Subscription executes. Each time it executes, it attempts to send a NotificationMessage to the
Client. NotificationMessages contain Notifications that have not yet been reported to Client.
j) NotificationMessages are sent to the Client in response to Publish requests. Publish requests are normally
queued to the Session as they are received, and one is de-queued and processed by a subscription related to
this Session for each publishing cycle, if there are Notifications to report. When there are not, the Publish
request is not de-queued from the Session, and the Server waits until the next cycle and checks again for
Notifications.
k) At the beginning of a cycle, if there are Notifications to send but there are no Publish requests queued, the
Server enters a wait state for a Publish request to be received. When one is received, it is processed
immediately without waiting for the next publishing cycle.
l) NotificationMessages are uniquely identified by sequence numbers that enable Clients to detect missed
Messages. The publishing interval also defines the default sampling interval for its MonitoredItems.
m) Subscriptions have a keep-alive counter that counts the number of consecutive publishing cycles in which
there have been no Notifications to report to the Client. When the maximum keep-alive count is reached, a
Publish request is de-queued and used to return a keep-alive Message. This keep-alive Message informs the
Client that the Subscription is still active. Each keep-alive Message is a response to a Publish request in which
the notificationMessage parameter does not contain any Notifications and that contains the sequence
number of the next NotificationMessage that is to be sent. In the clauses that follow, the term
NotificationMessage refers to a response to a Publish request in which the notificationMessage parameter
actually contains one or more Notifications, as opposed to a keep-alive Message in which this parameter
contains no Notifications. The maximum keep-alive count is set by the Client during Subscription creation
and may be subsequently modified using the ModifySubscription Service. Similar to Notification processing
described in (c) above, if there are no Publish requests queued, the Server waits for the next one to be
received and sends the keep-alive immediately without waiting for the next publishing cycle.
n) Publishing by a Subscription may be enabled or disabled by the Client when created, or subsequently using
the SetPublishingMode Service. Disabling causes the Subscription to cease sending NotificationMessages to
the Client. However, the Subscription continues to execute cyclically and continues to send keep-alive
Messages to the Client.
o) Subscriptions have a lifetime counter that counts the number of consecutive publishing cycles in which there
have been no Publish requests available to send a Publish response for the Subscription. Any Service call that
uses the SubscriptionId or the processing of a Publish response resets the lifetime counter of this
Subscription. When this counter reaches the value calculated for the lifetime of a Subscription based on the
MaxKeepAliveCount parameter in the CreateSubscription Service ( [UA Part 4]), the Subscription is closed.
Closing the Subscription causes its MonitoredItems to be deleted. In addition the Server shall issue a
StatusChangeNotification notificationMessage with the status code Bad_Timeout. The
StatusChangeNotification notificationMessage type is defined in [UA Part 4].

p) Sessions maintain a retransmission queue of sent NotificationMessages. NotificationMessages are retained
in this queue until they are acknowledged. The Session shall maintain a retransmission queue size of at least
two times the number of Publish requests per Session the Server supports. The minimum size of the
retransmission queue may be changed by a Profile in [UA Part 7]. The minimum number of Publish requests
per Session the Server shall support is defined in [UA Part 7]. Clients are required to acknowledge
NotificationMessages as they are received. In the case of a retransmission queue overflow, the oldest sent
NotificationMessage gets deleted. If a Subscription is transferred to another Session, the queued
NotificationMessages for this Subscription are moved from the old to the new Session.
The sequence number is an unsigned 32-bit integer that is incremented by one for each
NotificationMessage sent. The value 0 is never used for the sequence number. The first
NotificationMessage sent on a Subscription has a sequence number of 1. If the sequence number rolls
over, it rolls over to 1.
When a Subscription is created, the first Message is sent at the end of the first publishing cycle to inform
the Client that the Subscription is operational. A NotificationMessage is sent if there are Notifications
ready to be reported. If there are none, a keep -alive Message is sent instead that contains a sequence
number of 1, indicating that the first NotificationMessage has not yet been sent. This is the only time a
keep-alive Message is sent without waiting for the maximum keep -alive count to be reached, as
specified in (f) above.
The value of the sequence number is never reset during the lifetime of a Subscription. Therefore, the
same sequence number shall not be reused on a Subscription until over four billion NotificationMessages
have been sent. At a continuous rate of one thousand NotificationMessages per second on a given
Subscription, it would take roughly fifty days for th e same sequence number to be reused. This allows
Clients to safely treat sequence numbers as unique.
Sequence numbers are also used by Clients to acknowledge the receipt of NotificationMessages. Publish
requests allow the Client to acknowledge all Notifications up to a specific sequence number and to
acknowledge the sequence number of the last NotificationMessage received. One or more gaps may
exist in between. Acknowledgements allow the Server to delete NotificationMessages from its
retransmission queue.
Clients may ask for retransmission of selected NotificationMessages using the Republish Service. This
Service returns the requested Message.

4.5 Information Model
The base OPC UA specifications provide only the infrastructure to model information. The information can be
modeled by vendors in different ways. To avoid that situation, the OPC UA specification provides possibilities
to define Information Model specifications based on OPC UA. The base principles of the OPC UA information
modeling are:
• Using object-oriented techniques including type hierarchies and inheritance.
• Type information is exposed and can be accessed the same way as instances.
• Full meshed network of nodes allowing information to be connected in various ways.
• Extensibility regarding the type hierarchies as well as the types of references.
• No limitation on how to model information in order to allow an appropriate model for the provided
data.
• OPC UA information modeling is always done on server-side.
4.5.1 Nodes
The base modeling concepts of OPC UA are Nodes and References between Nodes.
Nodes can include Variables, Events, Methods, History and the functionality of Nodes can be extended.

4.5.2 References
Nodes are hierarchical organized and can reference to other nodes:
4.5.3 Standard AddressSpace

OPC UA defines a standard AddressSpace including
• Views (like database views^)
• Objects (the Nodes worked with)
• Types (Data Types supported by the server)

4.5.4 Data Types
OPC UA supports:
• Standard “scalar“ data types
• Complex data types possible
• Definition of object types and instances
• Definition of custom specific data types

4.6 Mappings
The first 5 parts of the OPC UA specification are written to be independent of the technology used for
implementation. This approach means OPC UA is a flexible specification that will continue to be applicable as
technology evolves. On the other hand, this approach means that it is not possible to build an OPC UA
Application with the information contained in [UA Part 1] through to [UA Part 5] because important
implementation details have been left out.
This standard 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.
This standard defines the DataEncodings, the SecurityProtocols and the TransportProtocols. The StackProfiles
are defined in [UA Part 7].
All communication between OPC UA Applications is based on the exchange of Messages. The parameters
contained in the Messages are defined in [UA Part 4]; however, their format is specified by the DataEncoding
and TransportProtocol. For this reason, each Message defined in [UA Part 4] shall have a normative description
which specifies exactly what shall be put on the wire. The normative descriptions are defined in the
appendices.
A Stack is a collection of software libraries that implement one or more StackProfiles. The interface between an
OPC UA Application and the Stack is a non-normative API which hides the details of the Stack implementation.
An API depends on a specific DevelopmentPlatform. Note that the datatypes exposed in the API for a
DevelopmentPlatform may not match the datatypes defined by the specification because of limitations of the
DevelopmentPlatform. For example, Java does not support unsigned integers which means that any Java API
will need to map unsigned integers onto a signed integer type.
Figure 21 – The OPC UA Stack Overview illustrates the relationships between the different concepts defined in
this standard.

Client
UA Application Server
Development Platforms
.NET 3.0
ANSI C API
JRE 5.0
Data Encodings
Serialization Layer UA Binary
UA XML
Encoded Message
Security Protocols
Stack Secure Channel Layer WS Secure Conversation
UA Secure Conversation
Security Transforms
Signing Secured Message
Encryption
Transport Protocols
Transport Layer UA TCP
SOAP/HTTP
Wire Protocol WSDL and XML Schema

UA Binary Schema
Mappings
Figure 21 – The OPC UA Stack Overview
The layers described in this specification do not correspond to layers in the OSI 7 layer model [X200]. Each
OPC UA StackProfile should be treated as a single Layer 7 (Application) protocol that is built on an existing
Layer 5, 6 or 7 protocol such as TCP/IP, TLS or HTTP.The SecureChannel layer is always present even if the
SecurityMode is None. In this situation, no security is applied but the SecurityProtocol implementation shall
maintain a logical channel with a unique identifier. Users and administrators are expected to understand that a
SecureChannel with SecurityMode set to None cannot be trusted unless the Application is operating on a
physically secure network or a low level protocol such as IPSec is being used.

4.7 Profiles
The OPC Unified Architecture multipart specification describes a number of Services and a variety of
information models. These Services and information models can be referred to as features of a Server or Client.
Servers and Clients need to be able to describe which features they support. This part provides a grouping of
these features. The individual features are grouped into ConformanceUnits which are further grouped into
Profiles. Figure 22 - Profile - ConformanceUnit - TestCases provides an overview of the interactions between
Profiles, ConformanceUnits and TestCases. The large arrows indicate the components that are used to
construct the parent. For example a Profile is constructed from Profiles and ConformanceUnits. The figure also
illustrates a feature of the OPC UA compliance test tool, in that it will test if a requested Profile passes all
ConformanceUnits. It will also test all other ConformanceUnits and report any other Profiles that pass
conformance testing. The individual TestCases are defined in separate. The TestCases are related back to the
appropriate ConformanceUnits defined in this specification. This relationship is also displayed by the OPC UA
Compliance Test Tool.
Grouped into Profiles /

ProfileCategories Facets
Will determine
Composed Conformant Profile(s)
of for Application
Other
Profiles /
Facets
Organized by
Conformance Conformance Process Test Cases
Groups Units For Conformance Unit
Each
Conformance UA
Unit is Application Compliance
Composed of Tests
Test Cases Will execute
Figure 22 - Profile - ConformanceUnit - TestCases

4.7.1 ConformanceUnit
Each ConformanceUnit represents a specific set of features (e.g. a group of services, portions of services or
information models) that can be tested as a single entity. ConformanceUnits are the building blocks of a
Profile. Each ConformanceUnit can also be used as a test category. For each ConformanceUnit, there would be
a number of TestCases that test the functionality described by the ConformanceUnit. The description of a
ConformanceUnit is intended to provide enough information to illustrate the required functionality, but in
many cases to obtain a complete understanding of the ConformanceUnit the reader may be required to also
examine the appropriate part of the OPC UA specification. Additional Information regarding testing of a
ConformanceUnit are provided in the test specifications.
The same features do not appear in more than one ConformanceUnit.
4.7.2 Profiles
Profiles are named groupings of ConformanceUnits. The Servers and Clients in an OPC UA application will
provide the names of Profiles that they support. The definition of Profiles is a dynamic activity, in that it is
expected that new Profiles will be added in the future. A Profile can be defined to inherit from an existing
Profile. The new Profile may add additional ConformanceUnits. These additional ConformanceUnits may add
additional features that are to be tested. The additional ConformanceUnits may also further restrict inherited
ConformanceUnits.
An OPC UA Application will typically support multiple Profiles.
Multiple Profiles may include the same ConformanceUnit.
Testing of a Profile consists of testing the individual ConformanceUnits that comprise the Profile.
Profiles are named based on naming conventions
4.7.3 Profile Categories

Profiles are grouped into categories to help vendors and end users understand the applicability of a Profile.
Categories include: Server and Client, but other example could also include Power Generation or Chemical
Plant. A Profile shall be assigned to one or more categories.
Table 2 – Profile Categories contains the list of currently defined ProfileCategories.
Table 2 – Profile Categories
Category Description
Client Profiles of this category specify a complete functional set for an OPC UA Client.
The URI of such profiles has to be part of a Software Certificate passed in the
CreateSession request.
Discovery Server Profiles of this category are for Discovery Servers
External Profiles that are defined outside
Security Profiles of this category specify a security policy. The URI of such profiles has
to be part of an Endpoint Description returned from the GetEndpoint service.
Server Profiles of this category specify a complete functional set for an OPC UA Server.
The URI of such profiles has to be part of a Software Certificate returned with
the CreateSession service response.
Transport Profiles of this category specify a specific protocol mapping. The URI of such
profiles has to be part of an Endpoint Description.

4.8 Data Access
Data Access deals with the representation and use of automation data in OPC UA Servers.
Automation data can be located inside the OPC UA Server or on I/O cards directly connected to the OPC UA
Server. It can also be located in sub-servers or on other devices such as controllers and input/output modules,
connected by serial links via field buses or other communication links. OPC UA Data Access Servers provide
one or more OPC UA Data Access Clients with transparent access to their automation data.
The links to automation data instances are called DataItems. Which categories of automation data are provided
is completely vendor-specific. Figure 23 – OPC DataItems are linked to automation data illustrates how the
AddressSpace of an OPC UA server might consist of a broad range of different DataItems.
OPC UA Server
Root Addressspace
with data items
Figure 23 – OPC DataItems are linked to automation data
Clients may read or write DataItems, or monitor them for value changes. The services needed for these
operations are specified in [UA Part 4]. Changes are defined as a change in status (quality) or a change in
value that exceeds a client-defined range called a Deadband. To detect the value change, the difference
between the current value and the last reported value is compared to the Deadband.

4.8.1 Model
The DataAccess model extends the variable model by defining VariableTypes. The DataItemType is the base
type. ArrayItemType, AnalogItemType and DiscreteItemType (and its TwoState and MultiState subtypes) are
specializations. See Figure 24 – DataItem VariableType Hierarchy. Each of these VariableTypes can be further
extended to form domain or server specific DataItems.
BaseDataVariableType Defined in
[UA Part 5]
<other>Type DataItemType
ArrayItemType AnalogItemType DiscreteItemType
TwoState MultiState MultiStateValue

DiscreteType DiscreteType DiscreteType
Figure 24 – DataItem VariableType Hierarchy

4.9 Alarms and Conditions
This standard defines an Information Model for Conditions, Dialog Conditions, and Alarms including
acknowledgement capabilities. It is built upon and extends base Event handling which is defined in
[UA Part 3], [UA Part 4] and [UA Part 5]. This Information Model can also be extended to support the additional
needs of specific domains. The details of what aspects of the Information Model are supported are defined via
Profiles (see [UA Part 7] for Profile definitions). Some systems may expose historical Events and Conditions via
the standard Historical Access framework (see [UA Part 11] for Historical Event definitions).
4.9.1 Conditions
Conditions are used to represent the state of a system or one of its components. Some common examples are:
• a temperature exceeding a configured limit
• a device needing maintenance
• a batch process that requires a user to confirm some step in the process before proceeding
Each Condition instance is of a specific ConditionType. The ConditionType and derived types are sub-types of
the BaseEventType (see [UA Part 3] and [UA Part 5]). This part defines types that are common across many
industries. It is expected that vendors or other standardisation groups will define additional ConditionTypes
deriving from the common base types defined in this part. The ConditionTypes supported by a Server are
exposed in the AddressSpace of the Server.
Condition instances are specific implementations of a ConditionType. It is up to the Server whether such
instances are also exposed in the Server’s AddressSpace. Condition instances shall have a unique identifier to
differentiate them from other instances. This is independent of whether they are exposed in the
AddressSpace.
As mentioned above, Conditions represent the state of a system or one of its components. In certain cases,
however, previous states that still need attention also have to be maintained. ConditionBranches are
introduced to deal with this requirement and distinguish current state and previous states. Each
ConditionBranch has a BranchId that differentiates it from other branches of the same Condition instance. The
ConditionBranch which represents the current state of the Condition (the trunk) has a Null BranchId. Servers
can generate separate Event Notifications for each branch. When the state represented by a ConditionBranch
does not need further attention, a final Event Notification for this branch will have the Retain Property set to
False. Maintaining previous states and therefore also the support of multiple branches is optional for Servers.
Conceptually, the lifetime of the Condition instance is independent of its state. However, Servers may provide
access to Condition instances only while ConditionBranches exist.
The base Condition state model is illustrated in Figure 25 – Base Condition State Model. It is extended by the
various Condition subtypes defined in this standard and may be further extended by vendors or other
standardisation groups. The primary states of a Condition are disabled and enabled. The Disabled state is
intended to allow Conditions to be turned off at the Server or below the Server (in a device or some
underlying system). The Enabled state is normally extended with the addition of sub-states.
This standard defines an Information Model for Conditions, Dialog Conditions, and Alarms including
acknowledgement capabilities. It is built upon and extends base Event handling which is defined in [UA Part 3],
[UA Part 4] and [UA Part 5]. This Information Model can also be extended to support the additional needs of
specific domains. The details of what aspects of the Information Model are support are provided via Profiles
(see [UA Part 7]). It is expected that systems will provide historical Events and Conditions via the standard
Historical Access framework (see [UA Part 11]).

Disabled
Enabled
Figure 25 – Base Condition State Model
A transition into the Disabled state results in a Condition Event however no subsequent Event Notifications are
generated until the Condition returns to the Enabled state.
When a Condition enters the Enabled state, that transition and all subsequent transitions result in Condition
Events being generated by the Server.
If Auditing is supported by a Server, the following Auditing related action shall be performed. The Server will
generate AuditEvents for Enable and Disable operations (either through a Method call or some Server /
vendor – specific means), rather than generating an AuditEvent Notification for each Condition instance being
enabled or disabled. AuditEvents are also generated for any other Operator action that results in changes to
the Conditions.

4.9.2 Acknowledgeable Conditions
AcknowledgeableConditions are sub-types of the base ConditionType. AcknowledgeableConditions expose
states to indicate whether a Condition has to be acknowledged or confirmed.
An AckedState and a ConfirmedState extend the EnabledState defined by the Condition. The state model is
illustrated in Figure 26 – AcknowledgeableConditions State Model. The enabled state is extended by adding
the AckedState and (optionally) the ConfirmedState.
Disabled
Enabled
AckedState = TRUE AckedState = FALSE
ConfirmedState ConfirmedState
= TRUE = FALSE
Figure 26 – AcknowledgeableConditions State Model
Acknowledgment of the transition may come from the Client or may be due to some logic internal to the
Server. For example, acknowledgment of a related Condition may result in this Condition becoming
acknowledged, or the Condition may be set up to automatically acknowledge itself when the acknowledgeable
situation disappears.
Two Acknowledge state models are supported by this standard. Either of these state models can be extended
to support more complex acknowledgement situations.
The basic Acknowledge state model is illustrated in Figure 27 – Acknowledge State Model. This model defines
an AckedState. The specific state changes that result in a change to the state depend on a Server’s
implementation. For example, in typical Alarm models the change is limited to a transition to the Active state
or transitions within the Active state. More complex models however can also allow for changes to the
AckedState when the Condition transitions to an inactive state.

AckedState = TRUE
Ack
Acknowledge
By
Method
Server
AckedState = FALSE
Figure 27 – Acknowledge State Model
A more complex state model which adds a confirmation to the basic Acknowledge is illustrated in Figure 28 –
Confirmed Acknowledge State Model. The Confirmed Acknowledge model is typically used to differentiate
between acknowledging the presence of a Condition and having done something to address the Condition. For
example an Operator receiving a motor high temperature Notification calls the Acknowledge Method to inform
the Server that the high temperature has been observed. The Operator then takes some action such as
lowering the load on the motor in order to reduce the temperature. The Operator then calls the Confirm
Method to inform the Server that a corrective action has been taken.
``
Acknowledged Unacknowledged
Acknowledge Method
Acknowledge By Server
Server restricts to
Unconfirmed until
Acknowledged
Unconfirmed Confirmed
Confirm Method
Confirmed by Server
Figure 28 – Confirmed Acknowledge State Model

4.9.3 Previous States of Conditions
Some systems require that previous states of a Condition are preserved for some time. A common use case is
the acknowledgement process. In certain environments it is required to acknowledge both the transition into
Active state and the transition into an inactive state. Systems with strict safety rules sometimes require that
every transition into Active state has to be acknowledged. In situations where state changes occur in short
succession there can be multiple unacknowledged states and the Server has to maintain ConditionBranches for
all previous unacknowledged states. These branches will be deleted after they have been acknowledged or if
they reached their final state.
Multiple ConditionBranches can also be used for other use cases where snapshots of previous states of a
Condition require additional actions.
4.9.4 Condition State Synchronization

When a Client subscribes for Events, the Notification of transitions will begin at the time of the Subscription.
The currently existing state will not be reported. This means for example that Clients are not informed of
currently Active Alarms until a new state change occurs.
Clients can obtain the current state of all Condition instances that are in an interesting state, by requesting a
Refresh for a Subscription. It should be noted that Refresh is not a general replay capability since the Server is
not required to maintain an Event history.
Clients request a Refresh by calling the ConditionRefresh Method. The Server will respond with a
RefreshStartEvent. This Event is followed by the Retained Conditions. The Server may also send new Event
Notifications interspersed with the Refresh related Event Notifications. After the Server is done with the
Refresh, a RefreshEndEvent is issued marking the completion of the Refresh. Clients shall check for multiple
Event Notifications for a ConditionBranch to avoid overwriting a new state delivered together with an older
state from the Refresh process. If a ConditionBranch exists, then the current Condition shall be reported. This
is true even if the only interesting item regarding the Condition is that ConditionBranches exist. This allows a
Client to accurately represent the current Condition state.
A Client that wishes to display the current status of Alarms and Conditions (known as a “current Alarm
display”) would use the following logic to process Refresh Event Notifications. The Client flags all Retained
Conditions as suspect on reception of the Event of the RefreshStartEvent. The Client adds any new Events
that are received during the Refresh without flagging them as suspect. The Client also removes the suspect
flag from any Retained Conditions that are returned as part of the Refresh. When the Client receives a
RefreshEndEvent, the Client removes any remaining suspect Events, since they no longer apply.
The following items should be noted with regard to ConditionRefresh:
• Some systems require that previous states of a Condition are preserved for some time. Some Servers –
in particular if they require acknowledgement of previous states – will maintain separate
ConditionBranches for prior states that still need attention.
ConditionRefresh shall issue Event Notifications for all interesting states (current and previous) of a
Condition instance and Clients can therefore receive more than one Event for a Condition instance
with different BranchIds.
• Under some circumstances a Server may not be capable of ensuring the Client is fully in sync with the
current state of Condition instances. For example if the underlying system represented by the Server is
reset or communications are lost for some period of time the Server may need to resynchronize itself
with the underlying system. In these cases the Server shall send an Event of the
RefreshRequiredEventType to advise the Client that a Refresh may be necessary. A Client receiving this
special Event should initiate a ConditionRefresh as noted in this clause.

• To ensure a Client is always informed, the three special EventTypes (RefreshEndEventType,
RefreshStartEventType and RefreshRequiredEventType) ignore the Event content filtering associated
with a Subscription and will always be delivered to the Client.
• ConditionRefresh applies to a Subscription. If multiple Event Notifiers are included in the same
Subscription, all Event Notifiers are refreshed.
4.9.5 Severity, Quality, and Comment

Comment, Severity and Quality are important elements of Conditions and any change to them will cause Event
Notifications.
The Severity of a Condition is inherited from the base Event model defined in [UA Part 5]. It indicates the
urgency of the Condition and is also commonly called ‘priority’, especially in relation to Alarms in the
ProcessConditionClass.
A Comment is a user generated string that is to be associated with a certain state of a Condition.
Quality refers to the quality of the data value(s) upon which this Condition is based. Since a Condition is
usually based on one or more Variables, the Condition inherits the quality of these Variables. E.g., if the
process value is “Uncertain”, the “LevelAlarm” Condition is also questionable.
4.9.6 Dialogs
Dialogs are ConditionTypes used by a Server to request user input. They are typically used when a Server has
entered some state that requires intervention by a Client. For example a Server monitoring a paper machine
indicates that a roll of paper has been wound and is ready for inspection. The Server would activate a Dialog
Condition indicating to the user that an inspection is required. Once the inspection has taken place the user
responds by informing the Server of an accepted or unaccepted inspection allowing the process to continue.
4.9.7 Alarms
Alarms are specializations of AcknowledgeableConditions that add the concepts of an Active state, a Shelving
state and a Suppressed state to a Condition. The state model is illustrated in Figure 29 – Alarm State Machine
Model.

Disabled
Enabled
Active = FALSE
Active = TRUE
Suppressed = TRUE Suppressed = FALSE
Shelved Unshelved
AckedState = TRUE AckedState = FALSE
ConfirmedState
ConfirmedState
= FALSE
= TRUE
Figure 29 – Alarm State Machine Model
An Alarm in the Active state indicates that the situation the Condition is representing currently exists. When an
Alarm is an inactive state it is representing a situation that has returned to a normal state.
Some Alarm subtypes introduce sub-states of the Active state. For example an Alarm representing a
temperature may provide a high level state as well as a critically high state.
The Shelving state can be set by an Operator via OPC UA Methods. The Suppressed state is set internally by the
Server due to system specific reasons. Alarm systems typically implement the Suppress and Shelve features to
help keep Operators from being overwhelmed during Alarm “storms” by limiting the number of Alarms an
Operator sees on a current Alarm display. This is accomplished by setting the SuppressedOrShelved flag on
second order dependent Alarms and/or Alarms of less severity, leading the Operator to concentrate on the
most critical issues.
The Shelved and Suppressed states differ from the Disabled state in that Alarms are still fully functional and can
be included in Subscription Notifications to a Client.

4.9.8 Multiple Active States
In some cases it is desirable to further define the Active state of an Alarm by providing a sub-state machine for
the Active State. For example a multi-state level Alarm when in the Active state may be in one of the following
sub-states: LowLow, Low, High or HighHigh. The state model is illustrated in Figure 30.
Active = FALSE
Active = TRUE
Low High
LowLow HighHigh
Figure 30 – Multiple Active States Example
With the multi-state Alarm model, state transitions among the sub-states of Active are allowed without
causing a transition out of the Active state.
To accommodate different use cases both a (mutually) exclusive and a non-exclusive model are supported.
Exclusive means that the Alarm can only be in one sub-state at a time. If for example a temperature exceeds
the HighHigh limit the associated exclusive LevelAlarm will be in the HighHigh sub-state and not in the High
sub-state.
Some Alarm systems, however, allow multiple sub-states to exist in parallel. This is called non-exclusive. In the
previous example where the temperature exceeds the HighHigh limit a non-exclusive LevelAlarm will be both
in the High and the HighHigh sub-state.
4.9.9 Condition Instances in the Address Space

Because Conditions always have a state (Enabled or Disabled) and possibly many sub-states it makes sense to
have instances of Conditions present in the AddressSpace. If the Server exposes Condition instances they
usually will appear in the AddressSpace as components of the Objects that “own” them. For example a
temperature transmitter that has a built-in high temperature Alarm would appear in the AddressSpace as an
instance of some temperature transmitter Object with a HasComponent Reference to an instance of a
LevelAlarmType.

The availability of instances allows Data Access Clients to monitor the current Condition state by subscribing to
the Attribute values of Variable Nodes.
While exposing Condition instances in the AddressSpace is not always possible, doing so allows for direct
interaction (read, write and Method invocation) with a specific Condition instance. For example, if a Condition
instance is not exposed, there is no way to invoke the Enable or Disable Method for the specific Condition
instance.
4.9.10 Alarm and Condition Auditing

The OPC UA Standards include provisions for auditing. Auditing is an important security and tracking concept.
Audit records provide the “Who”, “When” and “What” information regarding user interactions with a system.
These audit records are especially important when Alarm management is considered. Alarms are the typical
instrument for providing information to a user that something needs the user’s attention. A record of how the
user reacts to this information is required in many cases. Audit records are generated for all Method calls that
affect the state of the system, for example an Acknowledge Method call would generate an AuditConditionAck
Event.
The standard AuditEventTypes defined in [UA Part 5] already includes the fields required for Condition related
audit records. To allow for filtering and grouping, this standard defines a number of sub-types of the
AuditEventTypes but without adding new fields to them.
This standard describes the AuditEventType that each Method is required to generate. For example, the Disable
Method has an AlwaysGeneratesEvent Reference to an AuditConditionEnableEventType. An Event of this type
shall be generated for every invocation of the Method. The audit Event describes the user interaction with the
system, in some cases this interaction may affect more than one Condition or be related to more than one
state.

4.9.11 Model
The Alarm and Condition model extends the OPC UA base Event model by defining various Event Types based
on the BaseEventType. All of the Event Types defined in this standard can be further extended to form
domain or Server specific Alarm and Condition Types.
Instances of Alarm and Condition Types may be optionally exposed in the AddressSpace in order to allow
direct access to the state of an Alarm or Condition.
Figure 31 – ConditionType hierarchy

4.9.11.1 Condition Model
The Condition model extends the Event model by defining the ConditionType. The ConditionType introduces
the concept of states differentiating it from the base Event model. Unlike the BaseEventType, Conditions are
not transient. The ConditionType is further extended into Dialog and AcknowledgeableConditionTypes, each
of which have their own subtypes.
The Condition model is illustrated in Figure 32 – Condition model and formally defined in the subsequent
tables. It is worth noting that this figure, like all figures in this document, is not intended to be complete.
Rather, the figures only illustrate information provided by the formal definitions.
BaseEventType
ConditionType
PropertyType: PropertyType
:
ConditionName ConditionClassId
PropertyType: PropertyType:
BranchId ConditionClassName
PropertyType:
Retain
ConditionRefresh
ConditionVariableType:
Quality
ConditionRefresh 2
LastSeverity
Enable
TwoStateVariableType:
EnableState
Disable
Comment AddComment
ClientUserId
Acknowledgeable Dialog
ConditionType ConditionType
Figure 32 – Condition model

4.9.11.2 Dialog Model
The Dialog Model is an extension of the Condition model used by a Server to request user input. It provides
functionality similar to the standard Message dialogs found in most operating systems. The model can easily
be customized by providing Server specific response options in the ResponseOptionSet and by adding
additional functionality to derived Condition Types.
The DialogConditionType is used to represent Conditions as dialogs. It is illustrated in Figure 33 -
DialogConditionType Overview
Figure 33 - DialogConditionType Overview

4.9.11.3 Acknowledgeable Condition Model
The Acknowledgeable Condition Model extends the Condition model. States for acknowledgement and
confirmation are added to the Condition model.
AcknowledgeableConditions are represented by the AcknowledgeableConditionType which is a subtype of the
ConditionType. The model is formally defined in the following sub clauses.
The AcknowledgeableConditionType extends the ConditionType by defining acknowledgement characteristics.
It is an abstract type. The AcknowledgeableConditionType is illustrated in Figure 34 -
AcknowledgeableConditionType Overview.
ConditionType
EnableState
Acknowledgeable
ConditionType
Has TrueSubState TwoStateVariableType:

AckedState Acknowledge
TwoStateVariableType:
ConfirmedState
Confirm
Figure 34 - AcknowledgeableConditionType Overview

4.9.11.4 Alarm model
Figure 35 - AlarmConditionType hierarchy model informally describes the AlarmConditionType, its sub-types
and where it is in the hierarchy of Event Types.
ConditionType
AcknowledgeableConditionType
AlarmConditionType
LimitAlarmType Discrete AlarmType
OffNormalAlarmType
ExclusiveLimit NonExclusiveLimit
AlarmType AlarmType SystemOffNormalAlarmType
Exclusive Exclusive Exclusive NonExclusive NonExclusive NonExclusive

Level MultiDeviation RateOfChange Level MultiDeviation RateOfChange
Figure 35 - AlarmConditionType hierarchy model
The AlarmConditionType is an abstract type that extends the AcknowledgeableConditionType by introducing an

ActiveState, SuppressedState and ShelvingState. The Alarm model is illustrated in Figure 36 -
AlarmConditionType definition. This illustration is not intended to be a complete definition.
Figure 36 - AlarmConditionType definition

4.10 Programs
Integrated automation facilities manage their operations through the exchange of data and coordinated
invocation of system functions like illustrated in Figure 37 – Automation facility control. Services are required
to perform the data exchanges and to invoke the functions that constitute system operation. These functions
may be invoked through human machine interfaces, cell controllers, or other supervisory control and data
acquisition type systems. OPC UA defines Methods and Programs as an interoperable way to advertise,
discover, and request these functions. They provide a normalizing mechanism for the semantic description,
invocation of, and result reporting of these functions. Together Methods and Programs complement the other
OPC UA Services and ObjectTypes to facilitate the operation of an automation environment using a client
server hierarchy.
Filling Cleaning
Labelling
Palletizing
Packaging
Figure 37 – Automation facility control
Methods and Programs model functions typically having different scopes, behaviours, lifetimes, and
complexities in OPC Servers and the underlying systems. These functions are not normally characterized by the
reading or writing of data which is accomplished with the OPC UA Attribute service set.
Methods represent basic functions in the server that can be invoked by a client. Programs by contrast, model
more complex and stateful functionality in the system. For example, a method call may be used to perform a
calculation or reset a counter. A Program is used to run and control a batch process, execute a machine tool
part program, or manage a domain download. Methods and their invocation mechanism are described in
[UA Part 3] and [UA Part 4].

4.11 Historical Access
This standard defines the handling of historical time series data and historical Event data in the OPC
Unified Architecture. Included is the specification of the representation of historical data and Events in
the AddressSpace.
A Server supporting Historical Access provides Clients with transparent access to different historical
data and/or historical Event sources (e.g. process historians, event historians , etc.).
The historical data or Events may be located in a proprietary data collection, database or a short term
buffer within the memory. A Server supporting Historical Access will provide historical data and Events
for all or a subset of the available Variables, Objects, Properties or Views within the Server
AddressSpace.
Figure 38 – Possible OPC UA Server supporting Historical Access illustrates how the AddressSpace of
a UA Server might consist of a broad range of different historical data and/or historical Event sources.
server client
Operator
Display
Operator
Station 2 Event
Logger, etc.
OPC UA
Historical Access
Server
OPC UA
Historical
Access
Server
OPC-COM
Proprietary OPC UA Other data
Server
Data Server Server source
(DA or A&E)
Figure 38 – Possible OPC UA Server supporting Historical Access
The Server may be implemented as a standalone OPC UA Server that collects data from another OPC
UA Server or another data source. The Client that references the OPC UA Server supporting Historical
Access for historical data may be simple trending packages that just desire values over a given time
frame or they may be complex reports that require data in multiple formats.

4.12 Discovery
The discovery process allows the Clients to first find Servers on the network and then discover how to connect
to them. Once a Client has this information it can save it and use it to connect directly to the Server again
without going through the discovery process. If the Client finds that it cannot connect then that could mean
the Server configuration has changed and the Client needs to go through the discovery process again.
The discovery process requires that the Client locate a service that can provide it with information about
Servers on the network. The most basic approach relies on manual entry of URLs or MachineNames which are
known to have Servers running on them. A more advanced approach sends multicast messages to
MachineDiscoveryServers running on the local network which respond with the MachineName assigned to
them. The Client can then use the MachineNames returned to communicate with the LocalDiscoveryServers
running on those machines.
Servers shall allow themselves to be discovered by Clients by implementing a discovery Endpoint and
registering themselves with the LocalDiscoveryServer running on the same machine. Application Administrators
may also register Servers with the GlobalDirectoryService for the system.
The URL for a discovery Endpoint provides all of the information that the Client needs to connect to the
Endpoint. This implies that no security can be applied to the message, however, some implementations may
use transport layer security where the secure protocol is identified in the URL (e.g. HTTPS).
A discovery Endpoint shall provide the FindServers and GetEndpoints services defined in [UA Part 4]. Clients
use the FindServers service request a list of known Servers from the discovery Endpoint of a DiscoveryServer.
Clients use the GetEndpoints service defined in [UA Part 4] to request a list of supported Endpoints from the
discovery Endpoint of a Server.
Servers use the RegisterServer service defined in [UA Part 4] to tell the LocalDiscoveryServer that they are
available. Servers may call this service when they are installed, however, they shall call this service when they
start and continue to call it periodically as long as they are running and accepting Client connections.
Administrators shall be able to disable Server registration because they may not want some Servers to be
discoverable. By default, all Servers shall be configured to call RegisterServer.

4.13 Aggregates
The [UA Part 3] specification defines the representation of Aggregate historical or buffered real time data in
the OPC Unified Architecture. This includes the definition of Aggregates used in processed data retrieval and in
historical retrieval. This definition includes both standard Reference types and Object types.
4.13.1 Aggregate Objects
4.13.1.1 General
OPC UA servers can support several different functionalities and capabilities. The following standard Objects
are used to expose these capabilities in a common fashion, and there are several standard defined concepts
that can be extended by vendors.
4.13.1.1.1 AggregateConfigurationType
The AggregateConfigurationType defines the general characteristics of a Node that defines the Aggregate
configuration of any Variable or Property. AggregateConfiguration Object represents the browse entry point for
information on how the Server treats Aggregate specific functionality such as handling Uncertain data. It is
formally defined in Table 3.
Table 3 – AggregateConfigurationType Definition
Attribute Value
BrowseName AggregateConfigurationType
IsAbstract False
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the BaseObjectType defined in [UA Part 5]
HasProperty Variable TreatUncertainAsBad Boolean PropertyType Mandatory
HasProperty Variable PercentDataBad Byte PropertyType Mandatory
HasProperty Variable PercentDataGood Byte PropertyType Mandatory
HasProperty Variable UseSlopedExtrapolation Boolean PropertyType Mandatory
The TreatUncertainAsBad Variable indicates how the server treats data returned with a StatusCode severity
Uncertain with respect to Aggregate calculations. A value of True indicates the server considers the severity
equivalent to Bad, a value of False indicates the server considers the severity equivalent to Good, unless the
aggregate definition says otherwise. The default value is True. Note that the value is still treated as Uncertain
when the StatusCode for the result is calculated.
The PercentDataBad Variable indicates the minimum percentage of bad data in a given interval required for the
StatusCode for the given interval for processed data request to be set to Bad. (Uncertain is treated as
defined above). For details on which Aggregates use the PercentDataBad Variable, see the definition of each
Aggregate. The default value is 100.
The PercentDataGood Variable indicates the minimum percentage of Good data in a given interval required for
the StatusCode for the given interval for the processed data requests to be set to Good. For details on
which Aggregates use the PercentDataGood Variable, see the definition of each Aggregate. The default value is
100.
The PercentDataGood and PercentDataBad must follow the following relationship PercentDataGood >= (100 –
PercentDataBad). If they are equal the result of the PercentDataGood calculation is used.
The UseSlopedExtrapolation Variable indicates how the server interpolates data when no boundary value exists
(i.e. extrapolating into the future from the last known value). A value of False indicates that the server will use
a SteppedExtrapolation format, and hold the last known value constant. A value of True indicates the server

will project the value using UseSlopedExtrapolation mode. The default value is False. For SimpleBounds this
value is ignored.
4.13.1.2 AggregateFunctions Object

This Object is used as the browse entry point for information about the Aggregates supported by a Server. The
content of this Object is already defined by its type definition. All Instances of the FolderType use the standard
BrowseName of ‘AggregateFunctions’. The HasComponent Reference is used to relate a ServerCapabilities
Object and/or any HistoricalServerCapabilites Object to an AggregateFunctions Object.
Table 4 – Aggregate Functions Definition
Attribute Value
BrowseName AggregateFunctions
References Node BrowseName DataType TypeDefinition ModellingR
Class ule
HasTypeDefinition Object FolderType Defined in [UA Part 5]
Type
Each ServerCapabilities and HistoricalServerCapabilities Object shall reference an AggregateFunctions Object.

In addition, each HistoricalConfiguration Object belonging to a HistoricalDataNode may reference an
AggregateFunctions Object using the HasComponent Reference.
4.13.1.2.1 AggregateFunctionType
This ObjectType defines an Aggregate supported by a UA server. This Object is formally defined in Table 5.
Table 5 – AggregateFunctionType Definition
Attribute Value
BrowseName AggregateFunctionType
IsAbstract False
References Node BrowseName DataType Type Mod.
Class Definition Rule
Subtype of the BaseObjectType defined in [UA Part 5]
For the AggregateFunctionType, the Description Attribute (inherited from the Base NodeClass), is mandatory.
The Description Attribute provides a localized description of the Aggregate.
Table 6 specifies the BrowseName and Description Attributes for the standard Aggregate Objects. The
description is the localized “en” text. For other locales it shall be translated.

Table 6 – Standard AggregateType Nodes
BrowseName Description
I nt e r p ol at i o n A g g r e g at e
Interpolative A t t h e b e gi n n i n g o f e a c h i n t e r va l , r e t r i e v e t h e c a l c u l a t e d v a l u e fr o m
t h e d a t a p o i n t s o n e i t h e r s i d e o f t h e r e q u e s t e d t i m e s t a mp .
D a t a A v e r ag i ng a n d S u mma t i o n A g g r e g a t e s
A v e r a ge R e t r i e v e t h e a v e r a g e v a l u e o f t h e d a t a o v e r t h e i n t e r va l .
Ti m e A v e r a g e R e t r i e v e t h e t i m e w e i gh t e d a v e r a ge d a t a o ve r t h e i n t e r va l u s i n g
Interpolated Bounding Values .
Ti m e A v e r a g e 2 R e t r i e v e t h e t i m e w e i gh t e d a v e r a ge d a t a o ve r t h e i n t e r va l u s i n g S i m p l e
Bounding Values.
To t a l R e t r i e v e t h e t o t a l ( t i m e i n t e gr a l ) o f t h e d a t a o v e r t h e i n t e r va l u s i n g
Interpolated Bounding Values.
To t a l 2 R e t r i e v e t h e t o t a l ( t i m e i n t e gr a l ) o f t h e d a t a o v e r t h e i n t e r va l u s i n g
Simple Bounding Values.
D a t a V a r i at i o n A g g r e g at e s
M i n i mu m R e t r i e v e t h e mi n i m u m r a w v a l u e i n t h e i n t e r v a l w i t h t h e t i m e s t a mp o f
t h e s t a r t o f t h e i n t e r va l .
M a x i mu m R e t r i e v e t h e m a xi mu m r a w v a l u e i n t h e i n t e r v a l w i t h t h e t i m e s t a mp o f
t h e s t a r t o f t h e i n t e r va l .
M i n i mu m A c t u a l T i m e R e t r i e v e t h e mi n i m u m va l u e i n t h e i n t e r v a l a n d t h e Ti m e s t a mp o f t h e
m i n i mu m v a l u e .
M a x i mu m A c t u a l Ti m e R e t r i e v e t h e m a xi mu m v a l u e i n t h e i n t e r v a l a n d t h e Ti m e s t a mp o f t h e
m a xi m u m v a l u e .
R a n ge R e t r i e v e t h e d i f f e r e n c e b e t w e e n t h e m i n i m u m a n d m a xi m u m V a l u e
o ve r t h e i n t e r v a l .
M i n i mu m2 R e t r i e v e t h e mi n i m u m v a l u e i n t h e i n t e r v a l i n c l u d i n g t h e S i m p l e
Bounding Values.
M a x i mu m 2 R e t r i e v e t h e m a xi mu m v a l u e i n t h e i n t e r v a l i n c l u d i n g t h e S i m p l e
Bounding Values.
M i n i mu m A c t u a l T i m e 2 R e t r i e v e t h e mi n i m u m v a l u e wi t h t h e a c t u a l t i m e s t a m p i n c l u d i n g t h e
M a x i mu m A c t u a l Ti m e R e t r i e v e t h e m a xi mu m v a l u e wi t h t h e a c t u a l t i m e s t a m p i n c l u d i n g t h e
2 Simple Bounding Values.
R a n ge 2 R e t r i e v e t h e d i f f e r e n c e b e t w e e n t h e M i n i mu m 2 a n d M a x i mu m 2 va l u e
o ve r t h e i n t e r v a l .
C o u n t i ng A g g r e g at e s
Count R e t r i e v e t h e n u mb e r o f r a w v a l u e s o v e r t h e i n t e r va l .
DurationInStateZero R e t r i e v e t h e t i m e a B o o l e a n o r n u me r i c w a s i n a z e r o s t a t e u s i n g
DurationInStateNonZ R e t r i e v e t h e t i m e a B o o l e a n o r n u me r i c w a s i n a n o n - z e r o s t a t e u s i n g
ero Simple Bounding Values.
N u mb e r O f T r a n s i t i o n s R e t r i e v e t h e n u mb e r o f c h a n g e s b e t w e e n z e r o a n d n o n - z e r o t h a t a
B o o l e a n o r N u m e r i c v a l u e e xp e r i e n c e d i n t h e i n t e r va l .
T i me A g g r e g at e s

Start Retrieve the value at the beginning of the interval using Interpolated
Bounding Values.
End R e t r i e v e t h e v a l u e a t t h e e n d o f t h e i n t e r va l u s i n g I n t e r p o l a t e d
Bounding Values.
Delta Retrieve the difference between the Start and End value in the
interval.
StartBound Retrieve the value at the beginning of the interval using Simple
Bounding Values.
EndBound R e t r i e v e t h e v a l u e a t t h e e n d o f t h e i n t e r va l u s i n g S i m p l e B o u n d i n g
Values.
DeltaBounds R e t r i e v e t h e d i f f e r e n c e b e t w e e n t h e S t a r t B o u n d a n d E n d B o u n d va l u e i n
t h e i n t e r va l .
D a t a Q u al i t y A g g r e g at e s
D u r a t i o n Go o d R e t r i e v e t h e t o t a l d u r a t i o n o f t i m e i n t h e i n t e r va l d u r i n g wh i c h t h e
d a t a i s go o d .
DurationBad R e t r i e v e t h e t o t a l d u r a t i o n o f t i m e i n t h e i n t e r va l d u r i n g wh i c h t h e
data is bad.
PercentGood R e t r i e v e t h e p e r c e n t o f d a t a ( 0 t o 1 0 0 ) i n t h e i n t e r va l wh i c h h a s go o d
StatusCode.
PercentBad R e t r i e v e t h e p e r c e n t o f d a t a ( 0 t o 1 0 0 ) i n t h e i n t e r va l wh i c h h a s b a d
StatusCode.
Wo r s t Q u a l i t y R e t r i e v e t h e wo r s t S t a t u s C o d e o f d a t a i n t h e i n t e r va l .
Wo r s t Q u a l i t y 2 R e t r i e v e t h e wo r s t S t a t u s C o d e o f d a t a i n t h e i n t e r va l i n c l u d i n g t h e
H i s t or i c al A n no t at i o n A g g r e g at e s
An n o t a t i o n C o u n t R e t r i e v e t h e n u mb e r o f A n n o t a t i o n s i n t h e i n t e r v a l . ( a p p l i e s t o
H i s t o r i c a l A g g r e g a t e s o n l y)
S t a t i s t i c al A g g r e g at e s
S t a n d a r d D e vi a t i o n S a R e t r i e v e t h e s t a n d a r d d e vi a t i o n fo r t h e i n t e r v a l fo r a s a m p l e o f t h e
mple population (n-1).
VarianceSample R e t r i e v e t h e v a r i a n c e fo r t h e i n t e r va l a s c a l c u l a t e d b y t h e
S t a n d a r d D e vi a t i o n S a mp l e .
S t a n d a r d D e vi a t i o n R e t r i e v e t h e s t a n d a r d d e vi a t i o n fo r t h e i n t e r v a l fo r a c o mp l e t e
Population p o p u l a t i o n ( n ) wh i c h i n c l u d e s S i m p l e B o u n d i n g V a l u e s .
VariancePopulation R e t r i e v e t h e v a r i a n c e fo r t h e i n t e r va l a s c a l c u l a t e d b y t h e
S t a n d a r d D e vi a t i o n P o p u l a t i o n wh i c h i n c l u d e s S i m p l e B o u n d i n g V a l u e s .
4.13.2 MonitoredItem AggregateFilters
4.13.2.1 MonitoredItem AggregateFilter Defaults

The default values used for MonitoredItem Aggregates are the same as those used for historical Aggregates.
For additional information on MonitoredItem AggregateFilters see [UA Part 4].

4.13.2.2 MonitoredItem Aggregates and Bounding Values
When calculating MonitoredItem Aggregates that require the use of Bounding Values, the bounds may not be
known. The calculation is done in the same manner as a historical read with the Partial Bit set. The historian
may wait some amount of time (normally no more than one processing interval) before calculating the interval
to allow for any latency in data collection and reduce the use of the Partial Bit.
A historical read done after data collection and the data from MonitoredItems over the same interval may not
be the same.
4.13.3 Exposing Supported Functions and Capabilities

Figure 39 – Representation of Aggregate Configuration information in the AddressSpace outlines a possible
representation of Aggregate information in the AddressSpace. In this example, although the Server at the
highest level may support aggregate functionality for Interpolative, Total, Average, and others, DataVariable X
only supports Interpolative, Total and Average, while DataVariable Y supports Average, a vendor defined
Aggregate and other (unstated) Aggregates.
Server Capabilities
(Part 5 – Real Time) HasHistoricalConfiguaration
DataVariable X
HistoryServer Capabilities HA Configuration

(Part 11 – Historical Access) (Part 11 – Historical Access)
AggregateFunctions
AggregateFunctions AggregateFunctions
Organizes
Interpolative AggregateConfiguration
Total TreatUncertainAsBad
Organizes
Average PercentDataGood
PercentDataBad
TimeAverage
SteppedSlopedExtrapolation
...others...
DataVariable Y
Vendor
Aggregate
Organizes
HA Configuration
(Part 11 – Historical Access)
AggregateFunctions
AggregateFunctionType AggregateConfigurationType
Figure 39 – Representation of Aggregate Configuration information in the AddressSpace

Why Technosoftware GmbH?…
Professionalism
Technosoftware GmbH is, measured by the number of employees, truly not a big company. However
when it comes to flexibility, service quality, and adherence to schedules and reliability, we are surely a
great company which can compete against the so called leaders in the industry. And this is THE crucial
point for our customers.
Continuous progress
Lifelong learning and continuing education is, especially in the information technology, essential for
future success. Concerning our customers, we will constantly accepting new challenges and exceeding
their requirements again and again. We will continue to do everything to fulfill the needs of our
customers and to meet our own standards.
High Quality of Work

We reach this by a small, competent and dynamic team of coworkers, which apart from the satisfaction
of the customer; take care of a high quality of work. We concern the steps necessary for it together
with consideration of the customers’ requirements.
Support
We support you in all phases – consultation, direction of the project, analysis, architecture & design,
implementation, test and maintenance. You decide on the integration of our coworkers in your project;
for an entire project or for selected phases.
Technosoftware GmbH
Windleweg 3, CH-5235 Rüfenach
sales@technosoftware.com
www.technosoftware.com

OPC UA Client and Server Development (PDFDrive)

Uploaded by

Copyright:

Available Formats

OPC UA Client and Server Development (PDFDrive)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OPC UA Client and Server Development (PDFDrive)

Uploaded by

Copyright:

Available Formats

OPC UA SDKs .

Windows | Linux | Mac OS X | iOS

1.0.0 07-DEC-2018 Initial version

Purpose and audience of document

[UA Part 11] OPC UA Specification: Part 11 – Historical Access

[UA Part 13] OPC UA Specification: Part 13 – Aggregates

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 3 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

X200 : ITU-T X.200 – Open Systems Interconnection – Basic Reference Model

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 4 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 5 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 6 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 7 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 8 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 9 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 10 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

1.1 OPC Technology

1.1.1.1 Data Access (DA)

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 11 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

1.1.1.2 Alarms&Events (AE)

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 12 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 13 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

1.1.3 OPC .NET 4.0 (WCF)

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 14 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 15 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 16 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 17 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 18 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 19 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 20 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 21 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 22 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 23 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

OPC UA SDKs .NET Introduction - Version 1.0.6 - 23/03/19 Page 24 of 119

© Copyright 2011-2019, Technosoftware GmbH – www.technosoftware.com

4.1.2.2 Simple Notation

ReferenceType Shadowed six-sided polygon including text representing

Method Oval including text representing the string-part of the

View Trapezium including text representing the string-part of