OPC Unified Architecture Specification
(Release 1.03)
OPC 统一架构规范
Part 1 Overview and Concepts 1.03 Specification
（第一部分 概述和概念）
kipway 译
http://www.kipway.com
此规范是OPC UA应用程序开发人员的规范。该规范是分析和设计过程的结果，用于开发标准接口，以便多个供应商开发无缝集成的应用程序。
Copyright © 2006-2015, OPC Foundation, Inc
任何未经授权使用本规范可能违反版权法，商标法和通讯规定和法规。本文档包含受版权保护的信息。版权所有。图书，电子或机械的任何形式，包括复印，录音，录音或信息存储和检索系统 - 未经版权许可，不得以任何形式或任何方式复制或使用本作品所涵盖的此作品的任何部分。 ---所有者。
禁止OPC基金会成员和非成员复制和重新分发本规范。 所有副本必须单独获得，直接从OPC基金会网站http://www.opcfoundation.org下载。
采用者的注意力在于遵守或采用OPC规范可能需要使用专利权所涵盖的发明的可能性。 OPC不负责识别任何OPC规范可能需要许可的专利，或对引起其注意的专利的法律效力或范围进行法律调查的责任。 OPC规范仅供参考和咨询。 潜在用户负责保护自己免受专利侵权责任。
译者对本文的翻译无法保证准确无误，并可能包含错误。译者对本文不承担任何明示或暗示的担保，包括但不限于任何对所有权的担保，暗示对适销性或适用于特定用途或使用的保证。在任何情况下，译者对于本文所含的错误或直接，间接，偶发，特殊，后果性，依赖性或覆盖面的任何损失，包括任何用户或任何第三方的利润损失，收入，数据或使用，均不承担责任与本材料的使用，性能或使用有关，即使已被告知可能发生此类损害。
本文的英文原版属于OPC Foundation, Inc，翻译后的版本未经译者同意任何个人和组织不得转载。
第1部分介绍了OPC统一架构（OPC UA）的概念和概述。 阅读本文档有助于了解此多部分文档集的其余部分。 每个其他部分都会简要说明一下建议的阅读顺序。 本部分是非规范性的。
以下文件全部或部分在本文档中规范引用，对于其应用是不可或缺的。对于注明日期的引用文件，只有引用的版本适用。对于未注明日期的引用文件，适用最新版本的引用文件（包括任何修订）。
第2部分：OPC UA规范：第2部分 - 安全模型
http://www.opcfoundation.org/UA/Part2/
第3部分：OPC UA规范：第3部分 - 地址空间模型
http://www.opcfoundation.org/UA/Part3/
第4部分：OPC UA规范：第4部分 - 服务
http://www.opcfoundation.org/UA/Part4/
第5部分：OPC UA规范：第5部分 - 信息模型
http://www.opcfoundation.org/UA/Part5/
第6部分：OPC UA规范：第6部分 - 映射
http://www.opcfoundation.org/UA/Part6/
第7部分：OPC UA规范：第7部分 - 配置文件
http://www.opcfoundation.org/UA/Part7/
第8部分：OPC UA规范：第8部分 - 数据访问
http://www.opcfoundation.org/UA/Part8/
第9部分：OPC UA规范：第9部分 - 警报和事件
http://www.opcfoundation.org/UA/Part9/
第10部分：OPC UA规范：第10部分 - 程序
http://www.opcfoundation.org/UA/Part10/
第11部分：OPC UA规范：第11部分 - 历史访问,版本1.01或更高版本
http://www.opcfoundation.org/UA/Part11/
第12部分：OPC UA规范：第12部分 - 发现
http://www.opcfoundation.org/UA/Part12/
第13部分：OPC UA规范：第13部分 - 聚合
http://www.opcfoundation.org/UA/Part13/
在本文档和本系列引用的其他部分中，使用某些文档约定。
斜体用于表示系列的其中一个部分中的“术语和定义”子句中出现的定义术语或定义。斜体也用于表示服务输入或输出参数的名称或通常在表中定义的结构的结构或元素的名称。斜体的术语和名称也经常以骆驼案（写入复合词或短语的练习，其中元素无间隙地连接，每个元素的初始字母在化合物内大写）。例如，定义的术语是AddressSpace而不是地址空间。这使得更容易理解，AddressSpace有一个定义，而不是地址和空间的单独定义。(译者注：译文不再使用斜体)
为了本文档的目的，以下条款适用。
OPC UA服务器对其客户端(Clients)可见的信息的收集
注：有关Server AddressSpace的内容和结构的描述，请参阅第3部分。
一个从原生数据(Raw data)计算派生值的函数
注：原生数据可能来自历史数据库或缓冲实时数据。普通聚合包括给定时间范围内的平均值，时间范围内的最小值和时间范围内的最大值。
与通常需要确认的状态条件相关联的事件(Event)类型
注：参见第9部分关于Alarms的描述。
节点(Node)的原始特征
注：所有属性(Attributes)由OPC UA定义，可能不被客户端(Clients)或服务器(Servers)定义。属性(Attributes)是AddressSpace中允许具有数据值的唯一元素。
数字签名数据结构，描述客户端(Clients)或服务器(Servers)的功能。
向OPC UA服务器(Servers)发送符合本规范规定的服务消息(Messages)的应用程序。
Event扩展的通用术语。
注: 一个Condition 表示系统或其组件之一的conditions，并且始终存在于某种状态。
译者注：这个应该是事件的一种，始终保持一种状态的事件，不好用恰当的中文描述，因此保持英文原名。
位于应用程序和硬件之间的软件模块，提供各种功能，用于编码，加密和格式化用于发送的消息(Message)，并解码，解密和解包接收的消息(Message)。
数据由多个基本数据类型的元素组成，例如结构体。
OPC UA Client获取有关OPC UA服务器的信息的过程，包括端点和安全信息。
用于描述系统或系统组件中某些重要性的事物的通用术语。
节点的特殊属性(Attribute)，用于表示客户端可以订阅该特定节点以接收事件发生的通知。
组织框架，用于定义，描述和关联给定系统或系统集的信息资源。
注：核心地址空间模型支持AddressSpace中信息模型(Information Model)的表示。有关基本OPC UA信息模型(Information Model)的说明，请参见第5部分。
在客户端(Client)和服务器(Client)之间传送的表示特定服务(Service)请求或响应的数据单元
对象(Object)组件的可调用软件功能。
服务器(Server)中客户端定义(Client-defined)的实体，用于监视属性或EventNotifiers的新值或事件发生，并为其生成通知(Notifications)。
地址空间(AddressSpace)的基本组成部分。
地址空间中节点的类
注：NodeClasses定义OPC UA对象模型的组件的元数据。它们还定义了用于组织AddressSpace的构造，如视图(Views)。
通知用于申明事件检测或更改的属性值的数据;通知在NotificationMessages中发送。
从订阅(Subscription)中发布的包含一个或多个(Notifications)的消息(Message)。
表示系统的物理或抽象元素的节点(Node)
注：对象(Objects)使用OPC UA对象模型进行建模。 系统，子系统和设备都是对象的具体例子。 Object可以被定义为ObjectType的一个实例。
对象的同义词
注：不是所有对象(Objects)都由ObjectTypes定义。
表示对象(Object)的类型定义的节点(Node)
服务器(Server)可能要求一致性的特定功能集。
注1：每个服务器(Server)可能要求符合一个以上的配置文件(Profile)
注2：这个功能集在第7部分中定义
可执行对象(Object)，当被调用时，立即返回一个响应以指示执行已经启动，然后通过在调用期间由客户端标识的订阅(Subscriptions)返回中间和最终结果
显式关系（一个命名指针）从一个节点(Node)到另一个节点
注：包含引用的节点是源节点，引用节点是目标节点。所有引用由ReferenceTypes定义。
代表引用类型定义的节点
注1：条目：ReferenceType指定引用的语义。 ReferenceType的名称标识源节点如何与目标节点相关，并且通常反映两者之间的操作，例如“A包含B”。
开始或顶层层次结构的节点
注：OPC UA地址空间(AddressSpace)的根节点(RootNode)在第5部分中定义。
实现和并提供本套规范中指定的服务的软件应用程序。
OPC UA服务器(Server)中的客户端(Client)可调用操作。
注：服务(Services)在第4部分中定义。服务(Services)类似于编程语言中的方法调用或Web服务WSDL契约中的操作。
一组相关的服务集合(Services)
客户端(Client)和服务器(Server.)之间的逻辑长时间运行的连接。
注：会话维护从客户端到服务器的服务调用之间的状态信息。
服务器中的客户端定义的端点，用于将通知返回给客户端
注：“订阅”是一个通用术语，用于描述客户端（1）选择的一组节点，即服务器定期监视某些状况的存在，以及（2）服务器向客户端发送通知(Notifications)当检测到条件时。
作为独立实体存在的硬件或软件平台。 UA应用程序取决于实体的存在以执行UA服务。但是，实体不依赖于UA应用程序。
注：硬件和软件平台包括物理硬件，固件，操作系统，网络，非UA应用程序以及其他UA应用程序。分布式控制系统，PLC /设备和UA服务器是基础系统的示例。
包含值的节点(Node)
客户端(Client)感兴趣的AddressSpace的特定子集。
A＆E警报和事件
API应用程序编程接口
COM组件对象模型
DA数据访问
DCS分布式控制系统
DX数据交换
HDA历史数据访问
人机界面人机界面
LDAP轻量级目录访问协议
MES制造执行系统
OPC OPC基金会（非营利行业协会）以前是“OLE过程控制”的缩写。 不再使用
PLC可编程逻辑控制器
SCADA监控和数据采集
SOAP简单对象访问协议
UA统一架构
UDDI通用描述，发现和集成
UML统一建模语言
WSDL Web服务定义语言
XML可扩展标记语言
该规范被组织为多部分规范，如图1所示。
前七部分规定了OPC UA的核心功能。 这些核心功能定义了OPC AddressSpace的结构以及对其进行操作的服务(Services)。 第8至11部分适用这些核心功能可以由先前由单独的OPC COM解决的特定类型的访问规范,如数据访问(DA),警报和事件(A＆E)和历史数据访问(HDA), 第12部分描述了OPC UA的发现(Discovery)机制，第13部分描述了这种方法聚合数据。
在读取第8至13部分之前，鼓励读者阅读核心规范的第1至第5部分。例如，对UA数据访问有兴趣的读者应阅读第1部分至第5部分和第8部分。参考文献第8部分可指导读者参考其他部分的规格。
第1部分 - 概述和概念
介绍OPC UA的概念和概述。
第2部分 - 安全模型(Security Model)
描述了用于确保OPC UA客户端和OPC UA服务器之间交互的模型。
第3部分 - 地址空间模型(Address Space Model)
描述了服务器地址空间(AddressSpace.)的内容和结构。
第4部分 - 服务(Services)
规定了OPC UA服务器提供的服务(Services)。
第5部分 - 信息模型(Information Model)
指定为OPC UA服务器定义的类型及其关系。
第6部分 - 映射(Mappings)
规定了OPC UA支持的传输协议和数据编码的映射。
第7部分 - 配置文件(Profiles)
指定可用于OPC客户端和服务器的配置文件(Profiles)。 这些配置文件提供可用于一致性级别认证的服务或功能组。 服务器和客户端将根据配置文件进行测试。
第8部分 - 数据访问(Data Access)
规定了使用OPC UA进行数据访问。
第9部分 - 警报和Conditions (Alarms and Conditions)
规定使用OPC UA支持来访问报警(Alarms)和Conditions。 基础系统包括对简单事件(Events)的支持; 此规范将该支持扩展到包括对“警报和Conditions”的支持。
第10部分 - 程序(Programs)
规定OPC UA对程序访问的支持。
第11部分 - 历史访问(Historical Access)
规定了使用OPC UA进行历史访问。 此访问包括历史数据和历史事件(Events)。
第12部分 - 发现(Discovery)
指出了Discovery Servers如何在不同的场景中运行，并描述了UA客户端和服务器应如何与它们进行交互。 它还定义了如何使用诸如UDDI和LDAP之类的常用目录服务协议访问UA相关信息。
第13部分 - 总结(Aggregates)
指定如何计算和返回聚合，如最小，最大，平均等。聚合可以与当前和历史数据一起使用。
OPC UA适用于现场设备，控制系统，制造执行系统和企业资源规划系统等应用领域的制造软件。 这些系统旨在交换信息，并为工业过程使用命令和控制。 OPC UA定义了一个通用的基础架构模型，以便于此信息交换OPC UA指定以下内容：
•表示结构、行为和语义的信息模型。
•应用程序之间交互的消息模型。
•在端点之间传输数据的通信模型。
•保证系统间互操作性的一致性模型。
OPC UA是一种独立于平台的标准，各种系统和设备可以通过各种类型的网络在客户端和服务器之间发送消息进行通信。 它支持强大的安全通信，保证客户端和服务器的身份，并抵御攻击。 OPC UA定义服务器可能提供的服务集，并且各个服务器指定客户端支持哪些服务集。 信息使用OPC UA定义和供应商定义的数据类型传达，服务器定义客户端可以动态发现的对象模型。服务器可以提供对当前和历史数据以及警报和事件的访问，以通知客户端重要更改。 OPC UA可以映射到各种通信协议，并且可以以各种方式对数据进行编码以折衷可移植性和效率。
OPC UA提供一致的，集成的AddressSpace和服务模型。 这允许单个OPC UA服务器将数据，警报和事件以及历史记录集成到其AddressSpace中，并使用一整套服务来提供对它们的访问。 这些服务(Services)还包括一个集成的安全模型。
OPC UA还允许服务器为客户端提供从AddressSpace访问的对象的类型定义。 这样可以使用信息模型来描述AddressSpace的内容。 OPC UA允许以许多不同的格式显示数据，包括二进制结构和XML文档。 数据的格式可以由OPC，其他标准组织或供应商定义。 通过AddressSpace，客户端可以向服务器查询描述数据格式的元数据。 在许多情况下，没有预编程的数据格式知识的客户端将能够在运行时确定格式并正确使用数据。
OPC UA增加了对节点之间的许多关系的支持，而不仅限于单个层次结构。 以这种方式，OPC UA服务器可以按照一组客户端通常想要查看数据的方式定制各种层次结构中的数据。 这种灵活性，结合对类型定义的支持，使OPC UA适用于各种各样的问题领域。 如图2所示，OPC UA不仅仅针对SCADA，PLC和DCS接口，而且也是提供更高级别功能之间更大的互操作性的一种方式。
OPC UA旨在提供已发布数据的鲁棒性。 所有OPC服务器的主要功能是发布数据和事件通知。 OPC UA为客户端提供了快速检测和恢复与这些传输相关联的通信故障的机制，而无需等待基础协议提供的长时间超时。
OPC UA旨在支持从车间PLC到企业服务器的各种服务器。这些服务器的特点是具有广泛的大小，性能，执行平台和功能功能。 因此，OPC UA定义了一套全面的功能，而服务器可以实现这些功能的一部分。 为了促进互操作性，OPC UA定义了称为“配置文件”的子集，服务器可能声称其一致性。 然后，客户端可以发现服务器的配置文件，并根据配置文件定制与该服务器的交互。 配置文件在第7部分中定义。
OPC UA规范被分层以将核心设计与底层计算技术和网络传输隔离开来。 这允许OPC UA在必要时映射到未来的技术，而不会否定基本设计。 第6部分描述了映射和数据编码。定义了两个数据编码：
•XML /文本
•UA二进制
另外，定义了三种传输协议：
•OPC UA TCP
•SOAP / HTTP
•HTTPS
支持多种传输和编码的客户端和服务器将允许最终用户在部署时对性能和XML Web服务兼容性之间的权衡做出决策，而不是在产品定义时由OPC供应商确定这些权衡。
OPC UA被设计为基于Microsoft COM技术的OPC客户端和服务器的迁移路径。 OPC UA的设计中已经注意到OPC COM服务器（DA，HDA和A＆E）公开的现有数据可以通过OPC UA进行映射和暴露。 供应商可以选择将其产品本身迁移到OPC UA，或使用外部包装器将OPC COM转换为OPC UA，反之亦然。 以前的每个OPC规范都定义了自己的地址空间模型及其自己的一套服务。 OPC UA通过一套服务将以前的型号统一为单个集成地址空间。
OPC UA安全性涉及客户端和服务器的认证，用户认证，其通信的完整性和机密性以及功能声明的可验证性。它没有规定需要各种安全机制的情况。该规范至关重要，但由系统的设计人员在给定的地点进行，并且可以由其他标准规定。
相反，OPC UA提供了第2部分中描述的安全模型，其中可以选择和配置安全措施以满足给定安装的安全需求。该模型包括安全机制和参数。在某些情况下，定义交换安全参数的机制，但应用程序不使用使用这些参数。该框架还定义了所有UA服务器支持的最小安全配置文件集，尽管它们可能不会在所有安装中使用。安全性配置文件在第7部分中定义。
应用程序级安全性依赖于在应用程序会话期间处于活动状态的安全通信通道，并确保所有交换的消息的完整性。这意味着当应用会话建立时，用户只需要一次身份验证。第4部分和第6部分将介绍发现OPC UA服务器和建立安全通信通道和应用程序会话的机制。有关发现过程的其他信息，请参见第12部分。
当会话建立时，客户端和服务器应用程序协商一个安全的通信通道。数字(X.509)证书用于识别客户端和服务器及其提供的功能。授权生成的软件证书指示应用程序实现的OPC UA配置文件，并为每个配置文件达到OPC UA认证级别。每个简介和证书的细节在第7部分中规定。其他组织颁发的证书也可在会议期间进行交换。
服务器进一步验证用户并授权后续请求访问服务器中的对象。授权机制（如访问控制列表）不由OPC UA规范指定。它们是应用程序或系统特定的。
OPC UA支持在客户端和服务器审核日志之间具有可追溯性的安全审计跟踪。如果在服务器上检测到与安全相关的问题，则可以找到并检查关联的客户端审核日志条目。OPC UA还提供服务器生成事件通知的功能，该事件通知可将可审核事件报告给能够处理和记录的客户端。 OPC UA定义可以包含在审计日志条目和审计事件通知中的安全审核参数。第5部分定义了这些参数的数据类型。并非所有服务器和客户端都提供所有审核功能，在第7部分中的配置文件指出支持哪些功能。
OPC UA安全补充了大多数支持Web服务的平台提供的安全基础设施。
传输级安全性可用于加密和签署消息。加密和签名可防止信息泄露并保护消息的完整性。 加密功能由用于在OPC UA应用程序之间交换消息的底层通信技术提供。第7部分定义了要用于给定配置文件的加密和签名算法。
OPC UA服务器向客户端提供的对象和相关信息的集合称为其AddressSpace。 OPC UA地址空间将其内容表示为通过引用(References.)连接的一组节点(Node)。
节点的原始特征由OPC定义的属性(Attributes)描述。属性是具有数据值的服务器的唯一元素。定义属性值的数据类型可能很简单或复杂。
AddressSpace中的节点根据用途和意义进行分类。 NodeClasses定义OPC UA AddressSpace的元数据。第3部分定义了OPC UA NodeClasses。
Base NodeClass定义了所有节点通用的属性，允许识别，分类和命名。每个NodeClass继承这些属性，并可能另外定义自己的属性。
为了促进客户端和服务器的互操作性，OPC UA地址空间的层次结构与所有服务器的顶层相同。虽然AddressSpace中的节点通常可以通过层次结构访问，但它们可能具有彼此的引用，允许AddressSpace表示节点的相互关联的网络。 AddressSpace的模型在第3部分中定义。
OPC UA服务器可以将AddressSpace子集到Views中，以简化客户端访问。 6.3.4.3节详细介绍了AddressSpace视图。
OPC UA对象模型提供了一组一致的NodeClasses，用于表示AddressSpace中的对象。 该模型根据它们的变量，事件和方法及其与其他对象的关系来表示对象。 第3部分描述了这个模型。
OPC UA对象模型允许服务器为对象及其组件提供类型定义。 类型定义可以被子类化。 它们也可能是常见的，或者它们可能是系统特定的。 ObjectTypes可以由标准组织，供应商或最终用户定义。
该模型允许将数据，警报和事件及其历史记录集成到单个OPC UA服务器中。 例如，OPC UA服务器能够将温度变送器表示为由温度值，一组报警参数和相应的一组报警限制组成的对象。
OPC UA客户端和服务器之间的接口被定义为一组服务(Services)。 这些服务被组织成称为服务集的逻辑组。 服务集在第6.4条中讨论并在第4部分中规定。
OPC UA服务为客户端提供两种功能。 它们允许客户端向服务器发出请求并接收他们的响应。 它们还允许客户端订阅服务器通知。服务器使用通知(Notifications)来报告事件，例如警报，数据值更改，事件和程序执行结果。
源于效率目的，OPC UA消息(Messages)可以被编码为XML文本或二进制格式。 它们可以使用多个底层传输进行传输，例如通过HTTP的TCP或Web服务。 第6部分中定义了服务器可以提供的不同的编码和传输。
OPC UA需要一个有状态的模型。 状态信息保存在应用程序会话中。 状态信息的示例是跨多个请求的操作的订阅，用户凭证和连续点。
会话被定义为客户端和服务器之间的逻辑连接。 服务器可能会根据资源可用性，许可限制或其他限制来限制并发会话的数量。 每个会话独立于底层通信协议。 这些协议的故障不会自动导致会话终止。 会话根据客户端或服务器请求终止，或者基于客户端的不活动。 会话建立期间协商不活动时间间隔。
OPC UA系统架构将OPC UA客户端和服务器作为交互伙伴模型进行建模。每个系统可能包含多个客户端和服务器。 每个客户端可以与一个或多个服务器并发地进行交互，并且每个服务器可以与一个或多个客户端同时交互。 应用程序可以组合服务器和客户端组件，以允许与其他服务器和客户端进行交互，如6.3.7所述。
OPC UA客户端架构模拟客户端/服务器交互的客户端端点。
图4说明了典型OPC UA客户端的主要元素，以及它们如何相互关联。
客户端应用程序是实现客户端功能的代码。 它使用OPC UA客户端API发送和接收OPC UA服务请求和对OPC UA服务器的响应。 为OPC UA定义的服务在第6.4节中描述，并在第4部分中规定。
请注意，“OPC UA客户端API”是将客户端应用程序代码与OPC UA通信堆栈隔离的内部接口。 OPC UA通信协议栈将OPC UA客户端API调用转换为消息，并根据客户端应用程序的要求将它们通过底层通信实体发送到服务器。 OPC UA通信协议栈还从基础通信实体接收响应和NotificationMessages，并通过OPC UA客户端API将其发送给客户端应用程序。
OPC UA服务器架构模拟客户端/服务器交互的服务器端点。
实际对象是可由OPC UA服务器应用程序访问的物理或软件对象，也可由内部维护。 示例包括物理设备和诊断计数器。
OPC UA服务器应用程序是实现服务器功能的代码。 它使用OPC UA服务器API从OPC UA客户端发送和接收OPC UA消息。 请注意，“OPC UA服务器API”是将服务器应用程序代码与OPC UA通信堆栈隔离的内部接口。
AddressSpace被建模为由客户端使用OPC UA服务（接口和方法）访问的一组节点。 地址空间中的节点用于表示真实对象，它们的定义和它们的引用。
第3部分包含用于以一致的方式从互连节点创建AddressSpace的元模型“building blocks”的细节。服务器可以自由地在AddressSpace内组织他们的节点。节点之间的引用(References)使用允许服务器将AddressSpace组织成层次结构，全网状节点网络或任何可能的组合。
第5部分定义了OPC UA节点和引用(References)及其在AddressSpace中的预期组织。一些配置文件将不要求实现所有UA节点。
视图(View)是AddressSpace的一个子集。 视图用于限制服务器对客户端可见的节点，从而限制客户端提交的服务请求的AddressSpace的大小。 默认的View是整个AddressSpace。 服务器可以可选地定义其他视图。视图隐藏了AddressSpace中的一些节点或引用。视图通过AddressSpace可见，客户端能够浏览视图以确定其结构。视图通常是层次结构，客户端更容易在树中导航和表示。
OPC UA AddressSpace支持信息模型。 此支持通过以下方式提供：
a）允许AddressSpace中的对象彼此相关的节点引用。
b）为实际对象（类型定义）提供语义信息的ObjectType节点。
c）支持类型定义子类化的ObjectType节点。
d）在AddressSpace中公开的允许使用行业特定数据类型的数据类型定义。
e）OPC UA协议标准允许行业组织定义其特定信息模型如何在OPC UA服务器地址空间(Server AddressSpace)中表示。
MonitoredItems是由客户端在服务器中创建的用于监视AddressSpace节点及其real-world副本的实体。当它们检测到数据更改或事件/报警发生时，它们会生成通过订阅传送到客户端的通知(Notification)。
订阅(Subscription)是服务器中向客户端发布通知(Notifications)的端点。客户端通过发送发布消息(Messages)来控制发布的速度。
为OPC UA定义的服务(Services)在第6.4节中描述，并在第4部分中规定。
请求/响应服务是客户端通过OPC UA服务接口调用的服务(Services)，用于在AddressSpace中的一个或多个节点上执行特定任务，并返回响应。
发布商服务(Services)是通过OPC UA服务接口调用的服务，用于定期向客户端发送通知(Notifications)。通知包括事件(Events)，警报(Alarms)，数据变化(data changes)和程序输出(Program outputs)。
服务器到服务器的交互是一个服务器作为其他服务器的客户端的交互。 服务器到服务器的交互允许开发服务器：
f）在对等的基础上彼此交换信息，这可能包括用于维护系统范围类型定义的冗余或远程服务器（见图6），
g）链接在服务器的分层架构中，以提供：
1）来自下层服务器的数据聚合，
2）更高层数据结构到客户端，
3）与客户端的集中器接口，用于单个访问多个底层服务器的接入点。
图6说明了服务器之间的交互。
图7扩展了前面的例子，并且说明了OPC UA服务器链接在一起用于企业中的数据的垂直访问。
OPC UA提供以标准化方式实现冗余的数据结构和服务。 冗余可用于高可用性，容错和负载平衡。 第4部分正式定义了客户端，服务器和网络冗余。 只有部分配置文件第7部分将需要冗余支持，而不需要基本配置文件。
所需的客户端和服务器行为与两种不同的服务器冗余模式相关联，透明和不透明。 使用透明或非透明冗余时的客户端和服务器责任在第4部分中定义。
支持不透明冗余的服务器还可以支持客户端控制的负载平衡。服务器的健康状况，包括服务请求的能力，共同定义为ServiceLevel. 见第5部分ServiceLevel的正式定义。 第4部分定义了四个不同的ServiceLevel子范例和示例用法。
OPC UA服务分为服务集，每个服务集定义用于访问服务器特定方面的服务的逻辑分组。服务集如下所述。服务集及其服务在第4部分中指定。服务器是否支持服务集或服务集中的特定服务由其配置文件定义。配置文件在第7部分中描述。
此服务集定义了用于发现系统中可用的OPC UA服务器的服务。它还提供了一种客户端可以读取连接到服务器所需的安全配置的方式。发现服务由单独的服务器和专用的发现服务器实现。众所周知的专用发现服务器为客户端提供了一种发现所有注册的OPC UA服务器的方法。第12部分描述了如何使用发现服务与专用的发现服务器。
此服务集定义了用于打开通信通道的服务，以确保与服务器交换的所有消息的机密性和完整性。 UA安全的基本概念在第2部分中定义。
SecureChannel服务与其他服务不同，因为它们通常不由UA应用程序直接实现。相反，它们由UA应用程序构建的通信栈提供。例如，UA服务器可以构建在允许应用程序使用WS-SecureConversation规范建立SecureChannel的SOAP堆栈上。在这些情况下，UA应用程序只需要验证WS-SecureConversation在收到消息时是否处于活动状态。第6部分描述了如何使用不同类型的通信堆栈实现SecureChannel服务。
SecureChannel是单个客户端和单个服务器之间长期运行的逻辑连接。该通道维护一组仅对客户端和服务器已知的密钥(keys)，用于对通过网络发送的消息(Messages)进行身份验证和加密。 SecureChannel服务允许客户端和服务器安全地协商要使用的密钥(keys)。
用于验证和加密消息的确切算法在服务器的安全策略中有描述。这些策略通过发现服务集公开。客户端在创建SecureChannel时，选择服务器支持所需安全策略的适当端点。
当客户端和服务器通过SecureChannel进行通信时，它们会验证所有传入的消息是否已根据安全策略进行了签名和/或加密。 UA应用程序应该忽略不符合该通道的安全策略的任何消息。
SecureChannel与UA应用会话分开；然而，只能通过单个SecureChannel访问单个UA应用程序会话。这意味着UA应用程序能够确定哪个SecureChannel与每个消息相关联。提供SecureChannel机制但不允许应用程序知道为给定消息使用SecureChannel的通信堆栈不能用于实施SecureChannel服务集。
UA应用程序会话(Application Session)和SecureChannel之间的关系如图8所示。UA应用程序使用通信堆栈来交换消息。首先，SecureChannel服务用于在两个通信栈之间建立一个SecureChannel，允许它们以安全的方式交换消息。二，UA应用程序使用会话服务集建立UA应用会话。
此服务集定义了代表特定用户在会话上下文中建立应用程序层连接的服务。
NodeManagement服务集允许客户端在AddressSpace中添加，修改和删除节点。这些服务提供了一个用于配置服务器的界面。
视图(View)被公开定义，服务器创建的AddressSpace子集。整个AddressSpace是默认的View，因此View Services能够在整个AddressSpace上运行。此规范的未来版本也可以定义服务以创建客户端定义的视图。
查看服务集允许客户端通过浏览在视图中发现节点。浏览允许客户端在层次结构上上下导航，或者遵循View中包含的节点之间的引用。以这种方式，浏览也允许客户端发现视图的结构。
查询服务集允许用户访问地址空间，无需浏览和不知道用于数据内部存储的逻辑模式。
查询允许客户端根据某些客户端提供的过滤器条件在视图中选择节点的子集。从查询语句查看中选择的节点称为结果集。
服务器可能会发现难以处理需要访问运行时数据的查询，例如devicedata，涉及资源密集型操作或重大延迟。在这些情况下，服务器可能会发现有必要拒绝该查询。
属性服务集(Attribute Service Set)用于读写属性值。属性(Attribute)是由OPC UA定义的节点的原始特征。它们可能不被客户端或服务器定义。属性是AddressSpace中允许具有数据值的唯一元素。特殊属性，值属性(Value Attribute)用于定义变量(Variables)的值。
方法(Methods)表示对象的函数调用。它们在第3部分中定义。方法被调用并在完成后返回，无论成功还是不成功。方法的执行时间可能会有所不同，具体取决于其执行的功能。
方法服务集(Method Service Set)定义了调用方法的方法。 方法始终是对象的一个组件。通过浏览和查询服务提供发现。客户端通过浏览识别其支持的方法的所有对象来发现服务器支持的方法。
由于方法可以控制工厂操作的某些方面，方法调用可能取决于环境或其他条件。 尝试在完成执行后立即重新调用方法时尤其如此。调用方法所需的条件可能还没有返回到允许方法再次启动的状态。此外，一些方法可能能够支持并发调用，而其他方法可能在给定时间执行单个调用。
MonitoredItem服务集由客户端用于创建和维护MonitoredItems。 MonitoredItems监视变量，属性和EventNotifiers。当他们检测到某些条件时，它们会生成通知。他们监测变量的值或状态的变化;价值变化的属性;和新生成的报警和事件报告的EventNotifiers。
每个MonitoredItem标识要监视的项目和用于定期向客户端发布通知的订阅（见7.11）。每个MonitoredItem还指定要监视（采样）该项目的速率，并为变量和EventNotifiers指定用于确定何时生成通知的过滤条件。属性的过滤条件由第4部分中的属性定义指定。
为MonitoredItem定义的采样率可能比订阅的发布速度更快。因此，MonitoredItem可能被配置为对所有通知进行排队，也可以仅排队订阅所传送的最新通知。在后一种情况下，队列大小为1。
MonitoredItem Services还定义监视模式。监控模式被配置为禁用采样和报告，仅允许采样，或启用采样和报告。启用采样时，服务器对该项进行采样。此外，评估每个样本以确定是否应生成通知。如果是，通知将排队。如果启用了报告功能，则可将订单中的队列提供给转移。
最后，MonitoredItems可以配置为触发其他MonitoredItems的报告。在这种情况下，要报告的项目的监控模式通常设置为仅采样，并且当触发项目生成通知时，报告项目的任何排队通知将提供给订阅用于传输。
订阅服务集(Subscription Service Set)由客户端用于创建和维护订阅(Subscriptions)。订阅是定期发布分配给它们的MonitoredItem的NotificationMessages的实体（见7.9）。 NotificationMessage包含一个通用标题，后跟一系列通知。通知的格式特定于正在监视的项目的类型（即变量，属性和事件通知器）。
一旦创建，订阅的存在与客户端与服务器的会话无关。这允许一个客户端创建订阅，另一个可能是冗余客户端从其接收NotificationMessages。
为了防止客户端不使用，订阅具有配置的生命周期，客户端定期更新。如果任何客户端无法续订生命周期，生命周期终止，并且订阅由服务器关闭。订阅关闭时，分配给订阅的所有MonitoredItem都将被删除。
订阅(Subscriptions)包括支持丢失消息的检测和恢复的功能。 每个NotificationMessage包含一个序列号，允许客户端检测错过的消息。当没有在保活活动时间间隔内发送的通知时，服务器发送一个保留消息，其中包含发送的下一个NotificationMessage的序列号。 如果客户端在保持活动间隔已过期后无法接收到消息，或者如果确定它已经错过了消息，则可以请求服务器重新发送一个或多个消息。