参考链接地址：https://opcfoundation.org/developer-tools/specifications-unified-architecture

1.OPC协议简介

OPC全称是Object Linking and Embedding（OLE） for Process Control，它的出现为基于Windows的应用程序和现场过程控制应用建立了桥梁。在过去，为了存取现场设备的数据信息，每一个应用软件开发商都需要编写专用的接口函数。由于现场设备的种类繁多，且产品的不断升级，往往给用户和软件开发商带来了巨大的工作负担。通常这样也不能满足工作的实际需要，系统集成商和开发商急切需要一种具有高效性、可靠性、开放性、可互操作性的即插即用的设备驱动程序。在这种情况下，OPC标准应运而生。OPC标准以微软的OLE技术为基础，它的制定是通过提供一套标准的OLE/COM接口完成的，在OPC技术中使用的是OLE 2技术，OLE标准允许多台微机之间交换文档、图形等对象.

COM是Component Object Model的缩写，是所有OLE机制的基础。COM是一种为了实现与编程语言无关的对象而制定的标准，该标准将Windows下的对象定义为独立单元，可不受程序限制地访问这些单元。这种标准可以使两个应用程序通过对象化接口通讯，而不需要知道对方是如何创建的。例如，用户可以使用C++语言创建一个Windows对象，它支持一个接口，通过该接口，用户可以访问该对象提供的各种功能，用户可以使用Visual Basic，C，Pascal，Smalltalk或其它语言编写对象访问程序。在Windows NT4.0操作系统下，COM规范扩展到可访问本机以外的其它对象，一个应用程序所使用的对象可分布在网络上，COM的这个扩展被称为DCOM（Distributed COM）。

通过DCOM技术和OPC标准，完全可以创建一个开放的、可互操作的控制系统软件。OPC采用客户/服务器模式，把开发访问接口的任务放在硬件生产厂家或第三方厂家，以OPC服务器的形式提供给用户，解决了软、硬件厂商的矛盾，完成了系统的集成，提高了系统的开放性和可互操作性。OPC服务器通常支持两种类型的访问接口，它们分别为不同的编程语言环境提供访问机制。这两种接口是：自动化接口（Automation interface）；自定义接口（Custom interface）。

自动化接口通常是为基于脚本编程语言而定义的标准接口，可以使用VisualBasic、Delphi、PowerBuilder等编程语言开发OPC服务器的客户应用.

自定义接口是专门为C++等高级编程语言而制定的标准接口.

1、在控制领域中，系统往往由分散的各子系统构成；并且各子系统往往采用不同厂家的设备和方案。用户需要，将这些子系统集成，并架构统一的实时监控系统。

2、这样的实时监控系统需要解决分散子系统间的数据共享，各子系统需要统一协调相应控制指令。

3、再考虑到实时监控系统往往需要升级和调整。

4、就需要各子系统具备统一的开放接口。

5、OPC(OLE for Process Control) 规范正是这一思维的产物。

6、OPC 基于Microsoft公司的 Distributed interNet Application (DNA) 构架和 Component Object Model (COM) 技术的，根据易于扩展性而设计的。OPC规范定义了一个工业标准接口。

7、OPC是以OLE/COM机制作为应用程序的通讯标准。OLE/COM是一种客户/服务器模式，具有语言无关性、代码重用性、易于集成性等优点。OPC规范了接口函数，不管现场设备以何种形式存在，客户都以统一的方式去访问，从而保证软件对客户的透明性，使得用户完全从低层的开发中脱离出来。

8、OPC定义了一个开放的接口，在这个接口上，基于PC的软件组件能交换数据。它是基于Windows的OLE——对象链接和嵌入、COM——部件对象模型(Component Object Model)和DCOM——分布式COM(Distributed COM)技术。因而，OPC为自动化层的典型现场设备连接工业应用程序和办公室程序提供了一个理想的方法。

OPC是为了连接数据源(OPC服务器)和数据的使用者(OPC应用程序)之间的软件接口标准。数据源可以是PLC，DCS，条形码读取器等控制设备。随控制系统构成的不同，作为数据源的OPC服务器既可以是和OPC应用程序在同一台计算机上运行的本地OPC服务器，也可以是在另外的计算机上运行的远程OPC服务器。OPC接口既适用于通过网络把最下层的控制设备的原始数据提供给作为数据的使用者(OPC应用程序)的HMI(硬件监督接口)/SCADA(监督控制与数据采集)，批处理等自动化程序，以至更上层的历史数据库等应用程序，也适用于应用程序和物理设备的直接连接。所以OPC接口是适用于很多系统的具有高厚度柔软性的接口标准。

2 OPC协议有关定义

2.1 OPC UA条款

2.1.1 AddressSpace

OPC UA服务器使其客户端可见的信息集合。[UA Part 3]

2.1.2 Alarm

与通常需要确认的状态条件相关联的事件类型。[UA Part 9]

2.1.3 Attribute

节点的基本特征。所有属性都是由OPC UA定义的，并且可能不是由客户机或服务器定义的。属性是AddressSpace中惟一允许具有数据值的元素。

2.1.4 Certificate

描述客户机或服务器功能的数字签名数据结构。

2.1.5 Client

一种软件应用程序，它将消息发送到符合本规范集中指定的服务的OPC UA服务器。

2.1.6 Communication Stack

应用程序和硬件之间的一组分层软件模块，提供各种功能来编码、加密和格式化发送的消息，以及解码、解密和解压接收到的消息。

2.1.7 Complex Data

由元素或多个基本数据类型(如结构)组成的数据。

2.1.8 Event

一种通用术语，用于描述在系统或系统组件中发生的具有某种意义的事件。

2.1.9 EventNotifier

节点的一种特殊属性，表示客户机可以订阅该特定节点以接收事件发生的通知.

2.1.10 Information Model

一种组织框架，定义、描述和关联给定系统或一组系统的信息资源。核心地址空间模型支持地址空间中信息模型的表示。[UA Part 5]。

2.1.11 Message

客户端和服务器之间传输的数据单元，表示特定的服务请求或响应。

2.1.12 Method

一个可调用的软件功能。

2.1.13 MonitoredItem 

服务器中客户端定义的实体，用于监视属性或事件通知程序的新值或事件发生，并为它们生成通知.

2.1.14 Node

地址簿的基本组成部分。

2.1.15 nodeclass

地址空间中节点的类。nodeclass为OPC UA对象模型的组件定义元数据。它们还定义了用于组织AddressSpace的结构，比如视图.

2.1.16 Notification

数据的通用术语，用于宣布检测事件或更改的属性值。通知以NotificationMessages的形式发送。

2.1.17 NotificationMessage

从包含一个或多个通知的订阅中发布的消息。

2.1.18 Object

表示系统的物理或抽象元素的节点。对象使用OPC UA对象模型建模。系统、子系统和设备就是对象的例子。对象可以定义为ObjectType的实例。

2.1.19 Object Instance

对象的同义词。并非所有对象都由ObjectTypes定义。

2.1.20 ObjectType

表示Objec类型定义的节点。

2.1.21 profile

在[UA第7部分]中定义的一组特定功能，服务器可以对其声明一致性。每个服务器可以声明多个配置文件的一致性。

2.1.22 Program

一个可执行对象，当被调用时，立即返回一个响应，以指示执行已经开始，然后通过调用期间客户端标识的订阅返回中间结果和最终结果。

2.1.23 Reference

从一个节点到另一个节点的显式关系(命名指针)。包含引用的节点是源节点，引用的节点是目标节点。所有引用都由ReferenceTypes定义。

2.1.24 ReferenceType

从一个节点到另一个节点的显式关系(命名指针)。包含引用的节点是源节点，引用的节点是目标节点。所有引用都由ReferenceTypes定义。

2.1.25 RootNode 

层次结构的开始或顶部节点。OPC UA地址空间的根节点在[UA Part 5]中定义。

2.1.26 Server 

实现并公开在这组规范中指定的服务的软件应用程序.

2.1.27 Service 

在OPC UA服务器中可调用的客户端操作。服务在[UA第4部分]中定义。服务类似于编程语言中的方法调用或Web服务WSDL契约中的操作。

2.1.28 Service Set 

一组相关服务。

2.1.29  Session 

客户机和服务器之间的逻辑长时间运行的连接。会话维护从客户机到服务器的服务调用之间的状态信息。

2.1.30 Subscription 

服务器中客户端定义的端点，用于向客户端返回通知。泛型术语，描述客户端选择的一组节点(1)，服务器定期监视这些节点以确定是否存在某些条件;(2)当检测到条件时，服务器向客户端发送通知。

2.1.31 Variable 

变量是包含值的节点.

2.1.32 View 

客户端感兴趣的地址空间的特定子集

2.2 缩写词和符号

A&E                   Alarms and Events

API                    应用程序接口

COM                 组件对象模型

DA                     数据存取

DX                     数据交换

HDA                  历史数据存取

HMI                   人机界面

MES                  可集成制造执行系统

PLC                   可编程序逻辑控制器

SCADA              数据采集与监视控制系统

SOAP                简单对象访问协议

UA                      统一架构

UML                    统一建模语言

WSDL                服务描述语言

XML                  可扩展的标记语言

3.OPC UA体系结构

3.1 规范组织

该规范被组织为一个多部分规范，如图1所示。

图1

前七个部分指定了OPC UA的核心功能。这些核心功能定义了OPC地址空间的结构以及在其上运行的服务。第8部分到第11部分将这些核心功能应用于以前由单独的OPC COM规范处理的特定类型的访问，如数据访问(DA)、警报和事件(A&E)以及历史数据访问(HDA)。

3.2  Core Specification Part

3.2.1 Part 1 – OPC UA Concepts 

本规范描述了适用于OPC UA服务器和客户机的概念.

3.2.2  Part 2 – OPC UA Security Model 

[UA Part 2]描述了用于保护OPC UA客户机和OPC UA服务器之间交互的模型

3.2.3 Part 3 – OPC UA Address Space Model

[UA Part 3]描述了服务器地址空间的内容和结构。

3.2.4  Part 4 – OPC UA Services 

[UA Part 4]指定OPC UA服务器提供的服务。

3.2.5 Part 5 – OPC UA Information Model 

[UA Part 5]指定为OPC UA服务器定义的标准类型及其关系。

3.2.6 Part 6 – OPC UA Service Mapping

[UA Part 6]指定OPC UA支持的传输映射和数据编码。

3.2.7 Part 7 – OPC UA Profiles 

[UA Part 7]指定OPC客户机和服务器可用的概要文件。这些概要文件提供了可用于一致性级别认证的服务或功能组。服务器和客户机将根据概要文件进行测试。

3.3 Access Type Specification Parts 

3.3.1 Part 8 – OPC UA Data Access 

[UA Part 8]指定使用OPC UA进行数据访问

3.3.2 Part 9 – OPC UA Alarms and Conditions

[UA Part 9]指定使用OPC UA支持访问警报和条件。基本系统包括对简单事件的支持;该规范扩展了这种支持，包括对警报和条件的支持。

3.3.3 Part 10 – OPC UA Programs

[UA Part 10]指定了对程序访问的OPC UA支持。

3.3.4 Part 11 – OPC UA Historical Access 

[UA Part 11]指定使用OPC UA进行历史访问。这种访问包括历史数据和历史事件。

4. 综述

4.1 介绍

OPC统一架构(UA)是一种平台无关的标准，通过它，各种系统和设备可以通过各种类型的网络在客户机和服务器之间发送消息进行通信。它支持健壮、安全的通信，确保客户端和服务器的身份，并抵御攻击。OPC UA定义了服务器可能提供的标准服务集，各个服务器向客户机指定它们支持哪些服务集。信息使用标准和供应商定义的数据类型来传递，服务器定义了客户端可以动态发现的对象模型。服务器可以提供对当前和历史数据的访问，还可以提供警报和事件来通知客户端重要的更改。OPC UA可以映射到各种通信协议上，数据可以以各种方式编码，以权衡可移植性和效率。

4.2 设计目标

OPC UA提供了一致的、集成的地址空间和服务模型。这允许单个OPC UA服务器将数据、警报、事件和历史集成到其地址空间中，并使用一组集成的服务提供对它们的访问。这些服务还包括一个集成的安全模型。

这允许使用标准信息模型来描述AddressSpace的内容。OPC UA允许以多种不同的格式公开数据，包括二进制结构和XML文档。数据的格式可以由OPC、其他标准组织或供应商定义。通过AddressSpace，客户机可以向服务器查询描述数据格式的元数据。在许多情况下，没有预先编程的数据格式知识的客户机将能够在运行时确定格式并正确地利用数据。

通过这种方式，OPC UA服务器可以在各种层次结构中显示数据，这些层次结构根据一组客户机通常希望查看数据的方式进行定制。这种灵活性，加上对类型定义的支持，使得OPC UA适用于广泛的问题领域。如下图所示，OPC UA不仅针对遥测服务器接口，而且还作为一种在更高级别的功能之间提供更大互操作性的方法。

图2

所有OPC服务器的一个主要特性是能够发布数据和事件通知。OPC UA为客户端提供了一种机制，可以快速检测和从与这些传输相关的通信故障中恢复，而不必等待底层协议提供的长时间超时.

这些服务器的特点是具有广泛的规模、性能、执行平台和功能功能。因此，OPC UA定义了一组全面的功能，服务器可以实现这些功能的子集。为了促进互操作性，OPC UA定义了标准子集，称为概要文件，服务器可以声明对这些子集的一致性。然后，客户端可以发现服务器的概要文件，并根据概要文件定制与该服务器的交互。概要文件在[UA第7部分]中定义。

这使得OPC UA可以根据需要映射到未来的技术，而不需要否定基本的设计。映射和数据编码在[UA第6部分]中进行了描述。本部分定义了两种数据编码:

（1）XML/text

（2）UA Binary

此外，本部分定义了两个传输映射：

（1）TCP

（2）SOAP Web services over HTTP 

支持多种传输和编码的客户机和服务器将允许最终用户在部署时对性能和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使用一组服务将以前的模型统一到一个集成的地址空间中。

4.3 综合模型及服务

4.3.1 Security model

4.3.1.1 General

OPC UA安全性涉及客户机和服务器的身份验证、用户的身份验证、通信的完整性和机密性，以及功能声明的可验证性。它没有指定需要各种安全机制的情况。该规范是至关重要的，但是它是由给定站点上的系统设计人员制定的，并且可以由其他标准指定.

相反，OPC UA提供了在[UA第2部分]中定义的安全模型，其中可以选择和配置安全措施来满足给定安装的安全需求。该模型包括标准的安全机制和参数。在某些情况下，定义了交换安全参数的机制，但没有定义应用程序使用这些参数的方式。这个框架还定义了所有UA服务器都必须支持的最小安全概要文件集，即使它们不能在所有安装中使用。安全概要文件在[UA第7部分]中定义。

4.3.1.2 Session establishment 

应用程序级安全性依赖于一个安全的通信通道，该通道在应用程序会话期间处于活动状态，并确保交换的所有消息的完整性。这意味着只需要在建立应用程序会话时对用户进行一次身份验证。建立安全通信通道和应用程序会话的机制见[UA Part 4]和[UA Part 6]。

在建立会话时，客户机和服务器应用程序协商一个安全的通信通道，并交换软件证书，这些证书标识客户机和服务器及其提供的功能。OPC基金会生成的软件证书表明应用程序实现的OPC UA概要文件和每个概要文件达到的OPC UA认证级别。每个概要文件和证书的详细信息在[UA Part 7]中指定。其他组织颁发的证书也可以在会议设立期间交换。

服务器进一步对用户进行身份验证，并授权后续请求访问服务器中的对象。OPC UA规范没有指定诸如访问控制列表之类的授权机制。它们是特定于应用程序或系统的。

4.3.1.3 Auditing 

用户级安全性包括对安全审计跟踪的支持，以及客户机和服务器审计日志之间的可跟踪性。如果在服务器上检测到与安全性相关的问题，则可以定位和检查关联的客户机审计日志条目。OPC UA还为服务器提供了生成事件通知的功能，该事件通知向能够处理和记录可审计事件的客户机报告可审计事件。OPC UA定义了可以包含在审计日志条目和审计事件通知中的标准安全审计参数。[UA Part 5]定义了这些参数的数据类型。并非所有服务器和客户端都提供所有审计功能。在[UA Part 7]中找到的概要文件指出支持哪些特性。

4.3.1.4 Transport security

OPC UA安全补充了大多数支持web服务的平台所提供的安全基础设施。

传输级别安全性可用于对消息进行加密和签名。加密和签名可以防止信息泄露，并保护消息的完整性。加密功能由用于在OPC UA应用程序之间交换消息的底层通信技术提供。[UA Part 7]定义了用于给定概要文件的加密和签名算法。

4.3.2 Integrated AddressSpace model 

OPC UA安全补充了大多数支持web服务的平台所提供的安全基础设施。

传输级别安全性可用于对消息进行加密和签名。加密和签名可以防止信息泄露，并保护消息的完整性。加密功能由用于在OPC UA应用程序之间交换消息的底层通信技术提供。[UA Part 7]定义了用于给定概要文件的加密和签名算法。

AddressSpace中的节点根据它们的用途和含义进行类型化。nodeclass为OPC UA地址空间定义元数据。[UA Part 3]定义OPC UA nodeclass。 

基本NodeClass定义了所有节点共有的属性，允许标识、分类和命名。每个NodeClass都继承这些属性，并且可以额外定义自己的属性。 

为了促进客户端和服务器之间的互操作性，OPC UA地址空间是分层结构的，所有服务器的顶层都是标准化的。虽然AddressSpace中的节点通常可以通过层次结构访问，但它们可能彼此有引用，从而允许AddressSpace表示一个相互关联的节点网络。地址空间的模型在[UA Part 3]中定义。

OPC UA服务器可以将AddressSpace子集化为视图，以简化客户机访问。第5.3.3.3条更详细地描述了AddressSpace视图。

4.3.3 Integrated object model 

OPC UA对象模型为表示地址空间中的对象提供了一组一致的、集成的nodeclass。该模型根据对象的变量、事件和方法以及它们与其他对象的关系来表示对象。[UA第3部分]描述了这个模型。 

OPC UA对象模型允许服务器为对象及其组件提供类型定义。类型定义可以子类化。它们也可能是标准化的，或者是特定于系统的。对象类型可以由OPC基金会、其他标准组织、供应商或最终用户定义。

该模型允许将数据、警报和事件及其历史集成到一个OPC UA服务器中。例如，OPC UA服务器能够将温度变送器表示为一个对象，该对象由一个温度值、一组报警参数和一组相应的报警限制组成。

4.3.4 Integrated services

OPC UA客户机和服务器之间的接口被定义为一组服务。这些服务被组织成称为服务集的逻辑分组。服务集在第7条中讨论，并在[UA Part 4]中指定。

OPC UA服务为客户端提供两种功能。它们允许客户机向服务器发出请求并从服务器接收响应。它们还允许客户端订阅服务器以获取通知。服务器使用通知来报告发生的事件，如警报、数据值更改、事件和程序执行结果。 

为了提高效率，OPC UA消息可以编码为XML文本或二进制格式。它们可以使用多种底层传输传输，例如TCP或HTTP上的web服务。服务器可以根据[UA Part 7]的定义提供不同的编码和传输。

4.4 Sessions 

OPC UA需要一个有状态模型。状态信息在应用程序会话中维护。状态信息的示例包括跨多个请求的操作的订阅、用户凭证和延续点。

会话被定义为客户机和服务器之间的逻辑连接。服务器可以根据资源可用性、许可限制或其他限制限制并发会话的数量。每个会话都独立于底层通信协议。这些协议的失败不会自动导致会话终止。会话根据客户机或服务器请求或客户机的不活动而终止。不活动时间间隔在会话建立期间协商。

4.5 Redundancy

OPC UA的设计确保供应商能够以一致的方式创建冗余客户机和冗余服务器。冗余可用于高可用性、容错和负载平衡。冗余的详细信息可以在[UA Part 4]中找到。只有一些概要文件[UA Part 7]需要冗余支持，但不需要基本概要文件。

5. 系统概念

5.1 综述

OPC UA系统架构将OPC UA客户机和服务器建模为交互伙伴。每个系统可以包含多个客户机和服务器。每个客户机可以与一个或多个服务器并发交互，并且每个服务器可以与一个或多个客户机并发交互。应用程序可以结合服务器和客户端组件，以允许与其他服务器和客户端交互，如第5.3.6条所述。

OPC UA客户机和服务器将在下面的子句中描述。图3说明了包含组合服务器和客户机的体系结构。

图3

5.2 OPC UA Clients

OPC UA客户机体系结构为客户机/服务器交互的客户机端点建模。图4说明了典型OPC UA客户机的主要元素以及它们之间的关系。

图4

客户机应用程序是实现客户机功能的代码。它使用OPC UA客户机API向OPC UA服务器发送和接收OPC UA服务请求和响应。OPC UA定义的服务在第7条中描述，并在[UA Part 4]中指定。 

注意，“OPC UA客户端API”是一个内部接口，它将客户端应用程序代码与OPC UA通信堆栈隔离开来。OPC UA通信堆栈将OPC UA客户机API调用转换为消息，并应客户机应用程序的请求通过底层通信实体将它们发送到服务器。OPC UA通信堆栈还接收来自底层通信实体的响应和通知消息，并通过OPC UA客户机API将它们传递给客户机应用程序。

5.3 OPC UA Servers

OPC UA服务器体系结构为客户机/服务器交互的服务器端点建模。图5说明了OPC UA服务器的主要元素以及它们之间的关系。 

图5

5.3.1 Real objects 

实际对象是OPC UA服务器应用程序可以访问的物理对象或软件对象，或者是OPC UA服务器应用程序内部维护的对象。示例包括物理设备和诊断计数器。 

5.3.2 OPC UA Server application

实际对象是OPC UA服务器应用程序可以访问的物理对象或软件对象，或者是OPC UA服务器应用程序内部维护的对象。示例包括物理设备和诊断计数器。 

它使用OPC UA服务器API从OPC UA客户机发送和接收OPC UA消息。注意，“OPC UA服务器API”是一个内部接口，它将服务器应用程序代码与OPC UA通信堆栈隔离开来。这可能是OPC Foundation提供的标准实现，也可能是特定于供应商的实现。

5.3.3 OPC UA AddressSpace 

5.3.3.1 AddressSpace Nodes 

AddressSpace被建模为客户端使用OPC UA服务(接口和方法)访问的一组节点。AddressSpace中的节点用于表示实际对象、它们的定义以及彼此之间的引用。 

5.3.3.2 AddressSpace organization 

[UA Part 3]包含元模型“构建块”的详细信息，用于以标准的、一致的方式从互连节点创建地址空间。服务器可以根据自己的选择自由地在AddressSpace中组织节点。节点之间引用的使用允许服务器将地址空间组织成层次结构、节点的完整网状网络或任何可能的组合。 

[UA Part 5]定义了标准OPC UA节点和引用，以及它们在地址空间中的期望组织。一些概要文件不需要实现所有标准的UA节点

5.3.3.3 AddressSpace Views 

视图是AddressSpace的子集。视图用于限制服务器对客户机可见的节点，从而限制客户机提交的服务请求的地址空间大小。默认视图是整个AddressSpace。服务器可以选择定义其他视图。视图隐藏了AddressSpace中的一些节点或引用。视图通过AddressSpace可见，客户端可以浏览视图来确定它们的结构。视图通常是层次结构，客户端更容易在树中导航和表示。

5.3.3.4 Support for information models 

OPC UA地址空间支持信息模型。这项支助是通过:

a)允许AddressSpace中的对象相互关联的节点引用。

b)为实际对象(类型定义)提供语义信息的ObjectType节点。

c) ObjectType节点，以支持类型定义的子类化。

d) AddressSpace中公开的数据类型定义，允许使用特定于行业的数据类型。

e) OPC UA伙伴标准，允许行业组织定义如何在OPC UA服务器地址空间中表示其特定的信息模型。

5.3.4 Publisher/subscriber entities 

5.3.4.1 MonitoredItem

MonitoredItems是客户端创建的服务器中的实体，用于监视AddressSpace节点及其实际对等节点。当它们检测到数据更改或事件/警报发生时，它们生成一个通知，该通知通过订阅传输到客户机。

5.3.4.2 Subscriptions

订阅是服务器中的端点，它向客户机发布通知。客户机通过发送发布消息来控制发布的速率。客户机通过发送发布消息来控制发布的速率。

5.3.5 OPC UA Service Interface

5.3.5.1 General 

OPC UA定义的服务在第7条中描述，并在[UA Part 4]中指定。

5.3.5.2 Request/response Services 

请求/响应服务是客户机通过OPC UA服务接口调用的服务，用于在AddressSpace中的一个或多个节点上执行特定任务并返回响应。

5.3.5.3 Publisher Services 

发布者服务是通过OPC UA服务接口调用的服务，用于定期向客户端发送通知。通知包括事件、警报、数据更改和程序输出。

5.3.6 Server to Server interactions 

服务器到服务器的交互是指一个服务器充当另一个服务器的客户机的交互。服务器到服务器的交互允许开发以下服务器:

a)一个对等的基础上互相交换信息,这可能包括冗余或远程服务器用于维护系统广泛的类型定义,

b)链接在一个分层架构的服务器提供:

1)来自下层的数据聚合服务器,

2)客户更高层次数据结构,

3)集中器接口为单点访问多个潜在客户服务器。

图6演示了服务器之间的交互

图6

图7扩展了前面的示例，并演示了将OPC UA服务器链接在一起以垂直访问企业中的数据。

图7

6. Service Sets

6.1 General

OPC UA服务被划分为服务集，每个服务集定义用于访问服务器特定方面的逻辑服务分组。服务集描述如下。服务集及其服务在[UA第4部分]中指定。服务器是否支持服务集或服务集中的特定服务由其概要文件定义。简介见[UA第7部分]。

6.2 SecureChannel Service Set

此服务集定义用于发现服务器的安全配置和打开通信通道的服务，该通信通道确保与服务器交换的所有消息的机密性和完整性。UA安全的基本概念在[UA第2部分]中定义。

SecureChannel服务与其他服务不同，因为它们通常不是由UA应用程序直接实现的。相反，它们是由构建UA应用程序的通信堆栈提供的。例如，可以在SOAP堆栈上构建UA服务器，允许应用程序使用WS-SecureConversation规范建立SecureChannel。在这些情况下，UA应用程序只需验证WS-SecureConversation是否在接收到消息时处于活动状态。[UA第6部分]描述如何实现SecureChannel服务。

SecureChannel是单客户机和单服务器之间的长时间逻辑连接。该通道维护一组密钥，这些密钥只有客户机和服务器知道，用于对通过网络发送的消息进行身份验证和加密。SecureChannel服务允许客户机和服务器安全地协商要使用的密钥。

用于验证和加密消息的确切算法在服务器的安全策略中进行了描述。客户机在创建SecureChannel时必须选择服务器支持的安全策略之一。

当客户机和服务器通过SecureChannel通信时，它们必须验证所有传入消息都已根据安全策略签名和/或加密。一个UA应用程序不能处理任何不符合通道安全策略的消息。

SecureChannel与UA应用程序会话分离;但是，一个UA应用程序会话只能通过一个SecureChannel访问。这意味着UA应用程序必须能够确定哪个SecureChannel与每个消息相关联。提供SecureChannel机制但不允许应用程序知道为给定消息使用了什么SecureChannel的通信堆栈不能用于实现SecureChannel服务集。

图8显示了UA应用程序会话和SecureChannel之间的关系。UA应用程序使用通信堆栈来交换消息。首先，SecureChannel服务用于在两个通信堆栈之间建立SecureChannel，允许它们以安全的方式交换消息。其次，UA应用程序使用会话服务集来建立一个UA应用程序会话.

图8

当客户机建立SecureChannel时，它可能提供用户标识。此用户标识可能与客户机打开UA应用程序会话时提供的用户标识不同。

6.3 Session Service Set 

此服务集定义用于在会话上下文中代表特定用户建立应用程序层连接的服务。

6.4 NodeManagement Service Set 

节点管理服务集允许客户端在AddressSpace中添加、修改和删除节点。这些服务为服务器的配置提供了一个标准接口。

6.5 View Service Set 

视图是公开定义的，服务器创建的AddressSpace子集。整个AddressSpace是默认视图，因此视图服务能够在整个AddressSpace上运行。此规范的未来版本还可以定义服务来创建客户端定义的视图。

视图服务集允许客户端通过浏览发现视图中的节点。浏览允许客户机在层次结构中上下导航，或者跟踪视图中包含的节点之间的引用。通过这种方式，浏览还允许客户端发现视图的结构。

6.6 Attribute Service Set

属性服务集用于读取和写入属性值。属性是由OPC UA定义的节点的基本特征。它们可能不是由客户机或服务器定义的。属性是AddressSpace中惟一允许具有数据值的元素。值属性是一个特殊的属性，用于定义变量的值。

6.7 Method Service Set 

方法表示对象的函数调用。它们在[UA第3部分]中定义。方法被调用并在完成后返回，无论成功与否。方法的执行时间可能不同，这取决于它们所执行的函数。

方法服务集定义了调用方法的方法。方法必须是对象的组件。发现是通过浏览和查询服务提供的。客户端通过浏览标识其支持方法的所属对象来发现服务器支持的方法。

由于方法可能控制工厂操作的某些方面，所以方法调用可能取决于环境或其他条件。当尝试在方法完成执行后立即重新调用该方法时，这一点可能尤其正确。调用方法所需的条件可能尚未返回到允许方法重新启动的状态。此外，一些方法可能支持并发调用，而另一些方法可能在给定时间执行单个调用。

6.8 MonitoredItem Service Set 

客户端使用MonitoredItem服务集来创建和维护MonitoredItems。MonitoredItems监视变量、属性和事件通知程序。当检测到某些条件时，它们会生成通知。它们监视变量的值、状态或时间戳的变化;值更改的属性;以及用于新生成警报和事件报告的事件通知器。 

每个MonitoredItem标识要监视的项和用于定期向客户机发布通知的订阅(参见第7.9条)。每个MonitoredItem还指定要监视(采样)项的速率，对于变量和事件通知程序，还指定用于确定何时生成通知的筛选条件。属性的筛选条件由[UA第4部分]中的属性定义指定。 

为MonitoredItem定义的示例速率可能快于订阅的发布速率。因此，MonitoredItem可以配置为对所有通知排队，也可以只对最新的通知排队，以便通过订阅进行传输。在后一种情况下，队列大小为1。 

MonitoredItem服务还定义了监视模式。监视模式被配置为禁用抽样和报告，只启用抽样，或同时启用抽样和报告。启用抽样时，服务器对项进行抽样。此外，将对每个示例进行评估，以确定是否应该生成通知。如果是，则通知将排队。如果启用了报表，则将队列提供给订阅以进行传输。 

最后，可以将MonitoredItems配置为触发其他MonitoredItems的报告。在这种情况下，通常将要报告的项的监视模式设置为仅抽样，当触发项生成通知时，订阅方可以使用要报告的项的任何排队通知进行传输。

6.9 Subscription Service Set 

客户端使用订阅服务集来创建和维护订阅。订阅是定期发布分配给它们的MonitoredItem通知消息的实体(参见第6.7条)。通知消息包含一个公共头，后面跟着一系列通知。通知的格式特定于所监视的项的类型(即变量、属性和eventnotifier)。 

一旦创建，订阅的存在就独立于客户机与服务器的会话。这允许一个客户机创建订阅，另一个客户机(可能是冗余客户机)从订阅中接收通知消息。 

为了防止客户端不使用，订阅有一个配置的生命周期，客户端定期更新。如果任何客户机未能更新生存期，则生存期将过期，服务器将关闭订阅。当订阅被关闭时，分配给订阅的所有MonitoredItems都将被删除。 

订阅包括支持检测和恢复丢失消息的功能。每个通知消息都包含一个序列号，允许客户端检测丢失的消息。当在keep-alive时间间隔内没有要发送的通知时，服务器发送一个keep-alive消息，其中包含最后发送的通知消息的序列号。如果客户机在keep-alive间隔过期后未能接收到消息，或者如果客户机确定错过了消息，则可以请求服务器重新发送一条或多条消息。

6.10 Query Service Set 

查询服务集允许客户端根据客户端提供的筛选条件在地址空间或视图中选择节点子集。查询服务选择的节点及其属性称为结果集。结果集可以是“平面”节点集，也可以通过返回连接结果集中节点的引用来保持结构。

服务器可能会发现很难处理需要访问运行时数据的查询，比如涉及资源密集型操作或重大延迟的设备数据。在这些情况下，服务器可能会发现有必要拒绝查询