OPC UA Specification 基础之三：概述

5 概述
5.1 OPC UA适用范围

 OPC UA适用于现场设备、控制系统、制造执行系统（MES）以及企业资源规划系统（ERPs）等领域的制造过程软件。这些软件的设计目的是用于工业过程领域的信息的交互、控制及指令。OPC UA定义了通用框架模型，用于促进上述领域的信息交互。

 OPC UA具体规定以下内容：

• 用于表示结构、行为及语义的信息模型（Information Model）；
• 应用之间相互沟通的消息模型（Message Model）；
• 用于在端点（endpoint）之间传递数据的通信模型（Communication Model）；
• 用于保证系统间互操作的一致性模型（Conformance Model）。

5.2 General

 OPC UA是平台独立的标准，通过这个标准，不同类型的系统和设备可以实现客户端（Clients）和服务器（Servers）之间跨越不同种类网络的消息（Message）发送，实现相互通信。OPC UA支持稳健的（robust）、加密的通信，用以保证客户端（Clients）和服务器（Servers）的身份一致性，以及对外来攻击的有效防御。

 OPC UA定义了服务器（Servers）端可能提供的服务（services）集合，而每个独立的服务器（Servers）都应向客户端明确说明它所提供的服务集合。

 信息的交互是利用OPC UA定义的和供应商定义的数据类型实现的。服务器（Servers）定义了客户端（Clients）能动态发现的对象模型。服务器（Servers）能提供对实时、历史数据的访问，以及用以通知客户端（Clients）重要变化内容的报警（Alarms）和事件（Events）的访问。OPC UA可以被映射到多种不同的通信协议，数据可以用不同的编码方式进行编码以便在灵活性和高效性之间做出权衡（trade off）。

5.3设计目标

 OPC UA提供了一致的、完整的地址空间（Address Space）和服务模型。保证了OPC UA服务器（Servers）可以在它的地址空间（Address Space）中集成数据、报警（Alarms）和事件（Events）以及历史，并提供一个完整的服务（services）集合用以访问上述信息。这些服务（services）也包含一个完整的安全模型。

 OPC UA也允许服务器（Servers）向客户端（Clients）提供针对自身地址空间（Address Space）中可访问对象进行类型定义的功能，这样就可以用信息模型对地址空间（Address Space）中的内容进行描述。OPC UA允许数据以不同的数据格式进行展现，包括二进制格式和XML文档。通过地址空间，客户端（Clients）可以向服务器（Servers）查询用于描述数据格式的元数据（meta data）。在多数案例中，客户端（Clients）在没有预先得知数据格式编码方式的情况下，也可以在运行时动态获知数据编码格式并正确使用数据。

 OPC UA增加了对节点（Nodes）之间多种关联的支持，而不仅局限于单一的层次结构。因此，OPC UA服务器（Servers）可以根据客户端（Clients）的需求，用不同的层次结构定制（tailored）展现数据，这种灵活性，结合对类型定义的支持，使OPC UA能适应不同的应用领域。如下图所示，OPC UA不仅局限于SCADA、PLC、DCS，也可以在顶层应用之间提供更广泛的互操作性。

图表 1：OPC UA目标应用环境

 OPC UA被设计成用于保证所发布数据的稳健性。所有OPC UA 服务器的一个主要特性是发布数据和事件通知（Event Notification）的能力。OPC UA为客户端（Clients）提供一种机制，用于快速检测数据传输通信故障并从故障中恢复，而不用等待底层协议提供的超时后的恢复。

 OPC UA被设计为支持广泛类型的服务器（Servers），从现场的PLC到企业服务器。这些服务器（Servers）可以从尺寸、性能、运行平台以及功能特性等方面进行分类。因此OPC UA定义了一系列复杂的功能（capabilities）集合，服务器（Servers）可以实现这些功能集合的一个子集。为了提供互操作能力，OPC UA定义了被称为配置文件（profile）的子集，服务器（Servers）可以据此保证一致性（conformance），客户端（Clients）也可以获取服务器（Servers）的配置文件（profile），并依据此配置文件（profile）定制与此服务器（Servers）的互操作功能。配置文件（profile）在第七部分（Part 7）定义。

 OPC UA规范是分层定义的，用以隔离底层的计算技术和网络传输，这种分层定义允许OPC UA可以适应未来的技术，而无需否定（negating）技术设计。映射（mapping）和数据编码（data encoding）在第六部分（part 6）定义。有两种数据编码方式：

• XML/Text；
• UA Binary。

三种传输协议

• OPC UA TCP；
• SOAP/HTTP；
• HTTPS。

 支持多种传输协议和编码方式的客户端（Clients）和服务器（Servers）允许最终用户在发布时能够在XML WEB服务的便利性和性能之间左侧权衡，而不是由OPC供应商在设计产品时决定。

 OPC UA是沿着基于Microsoft COM技术发展的OPC 客户端、服务器技术的路线演变而来的，用于确保现有的OPC COM服务器（DA、HAD和A&E）能很容易的映射到OPC UA中。开发商可以选择从基础上迁移到OPC UA，也可以选择利用OPC UA 包装器（wrappers）。OPC UA将之前的各种OPC规范定义的独立的命名空间和服务统一到单一的、完整的地址空间和服务中。

5.4 统一的模型和服务
5.4.1安全模型
5.4.1.1 General

 OPC UA安全性设计到客户端（Clients）和服务器（Servers）之间的认证（authentication）、用户的认证、通信的完整性和保密性以及功能性声明的可验证性（verifiability of claims of functionality）。它并没有明确规范哪种应用环境需要哪种安全机制，尽管这种规定是至关重要的，但这是由系统的设计者根据特定要求决定的，通常是依据其它规范规定的（at a given site and may be specified by other standards）。

 OPC UA提供一种安全模型（part 2中说明），在这个安全模型中，可以根据特定安装（installation）的安全需求，选择和配置安全措施（security measures）。这个模型包含安全机制和参数。在一些情况下，定义了用于交换安全参数的方法，但应用程序如何使用这些参数并没有被定义。这个框架也定义了所有UA服务器应该支持的安全配置文件（profiles）的最小集合，尽管这些配置文件（profiles）不可能被所有的安装所使用。安全配置文件在part 7中说明。

5.4.1.2发现并建立会话

 应用层的安全依赖于安全通信信道，这个安全通信信道在整个应用会话（session）期间都是激活的并确保所交换的所有消息（messages）的完整性。这意味着用户只能在应用会话（session）建立时被认证（authenticated）一次。这种发现OPC UA服务器、建立安全通信信道以及应用会话的机制在Part 4和Part 6中说明。关于发现（Discovery）过程的附加信息在Part 12中说明。

 当会话（session）建立后，客户端（Clients）和服务器（Servers）应用协商一个安全通信信道，数字（X.509）证书（Certificates）被用于识别客户端（Clients）和服务器（Servers）的身份以及他们所提供的功能。授权产生的软件证书（Certificates）标明了由应用实现的OPC UA的配置文件（profiles），以及每个配置文件（profiles）所达到的OPC UA证书（Certificates）级别。每个配置文件（profiles）及证书（Certificates）在Part 7中说明。

 在会话（session）建立期间，其他机构颁发的证书（Certificates）也可以被交换。

 服务器（Servers）进一步对用户进行认证，并授权后续的对服务器中对象（Objects）的访问。认证机制，例如访问控制清单，并不是OPC UA规定的，而是和应用或系统相关的。

5.4.1.3审核

 OPC UA拥有对安全审核索引的支持，这种安全审核索引具备对客户端（Clients）和服务器（Servers）之间的审核日志进行相互追溯能力。如果在服务器（Servers）端检测到安全相关的问题，与之对应的客户端（Clients）审核日志条目可以被定位并，这种功能可以向具备处理和记录功能的客户端（Clients）发送审核事件（Events）通知。OPC UA定义了安全审核参数，这些参数可以被包含在审核日志和审核事件通知（Event Notifications）中。Part 5定义了这些参数的数据类型。并非所有的客户端（Clients）和服务器（Servers）都提供全部的审核特性，Part 7中说明的配置文件（profiles）指明了那些审核特性是被支持的。

5.4.1.4传输安全

 OPC UA安全机制对那些由支持web服务的平台所提供的安全架构做了完善。传输层的安全机制可以对消息（Messages）做加密及签名。加密和签名可以保证信息不被泄露，并保证消息（Messages）的一致性。加密的能力是由用于在OPC UA应用之间传输消息（Messages）的底层通信技术提供的。Part 7说明针对特定配置文件使用什么样的加密和签名算法。

5.4.2一体化的地址空间模型

 OPC UA服务器（Servers）向客户端（Clients）开放的对象（Objects）集合以及相关信息被定义为地址空间（Address Space）。OPC UA地址空间（Address Space）将其内容描述为一系列由引用（References）连接的对象（Objects）集合。属性（Attributes）是节点（Nodes）的最基本的特征。属性（Attributes）是服务器（Servers）的元素中的唯一拥有数据值的元素，数据值的数据类型可以是简单类型也可以是复杂类型。

 地址空间（Address Spaces）中的节点（Nodes）依据他们的使用方式和含义被划分为不同的类型。节点类（NodeClasses）定义了OPC UA地址空间（Address Spaces）的元数据，Part 3定义了OPC UA的节点类（NodeClasses）。

 基础节点类（Base NodeClass）定义了所有节点（Nodes）通用的属性（Attributes），并允许这些属性被标识、分类及命名。每个节点类（NodeClasses）都继承这些属性（Attributes）并可以自定义特有的属性（Attributes）。

 为了提供客户端（Clients）和服务器（Servers）之间的互操作能力，OPC UA地址空间（Address Spaces）被设计为层次化的结构，而这种层次化结构的顶层对所有的服务器（Servers）都是相同的。虽然地址空间（Address Space）中的节点（Nodes）通常是依据层次来访问的，但这些节点（Nodes）之间通过引用（References）互相连接，使得地址空间（Address Space）可以描绘出一种相互关联的节点（Nodes）网络。地址空间（Address Space）模型在Part 3中定义。

5.4.3统一的对象模型

 OPC UA对象模型提供一种一致的、统一的节点类（NodeClass）集合用以描绘地址空间（Address Space）中的对象（Objects）。这种模型从以下术语描述对象（Objects）：变量（Variables）、事件（Events）、方法（Methods）以及对象之间的关联。Part 3描述了这种模型。

 OPC UA 对象模型允许服务器（Servers）为对象（Objects）和组件提供类型定义。类型定义可以是子类化（SubClassed）的。可以是通用的也可以是系统特有的。对象类型（ObjectTypes）可以由标准化组织、开发商或最终用户定义。这种对象模型允许数据、报警（Alarms）和事件（Events）以及各种历史数据被集成到一个OPC UA服务器中。例如，OPC UA服务器可以把一个温度变送器描述为一个对象（Objects），这个对象（Objects）由温度值、报警参数以及报警限值等组合而成。

5.4.4统一的服务

 OPC UA客户端（Clients）和服务器（Servers）之间的接口被定义为服务（Services）集合。这些服务被划分为一些逻辑组，称为服务集（Service Sets）。

 OPC UA服务（Services）为客户端（Clients）提供两种能力，一种是允许客户端（Clients）向服务器（Servers）发起请求并接收反馈，第二种允许客户端（Clients）向服务器（Servers）订阅通知（Notifications），服务器（Servers）使用通知（Notifications）向客户端（Clients）发送报警（Alarms）、数据值的变化、事件（Events）以及程序（Program）执行结果。

 OPC UA消息（Messages）可以用XML或二进制格式编码，其底层传输方式有多种，例如TCP或HTTP WEB服务。服务器（Servers）可以提供不同的编码传输方式。

5.5会话

 OPC UA需要有状态的模型。状态信息在应用程序的会话（Sessions）内部维护。状态信息的例子包括订阅（Subscriptions）、用户凭证以及扩展多个请求的连续的操作点。

 会话（Sessions）被定义为客户端（Clients）和服务器（Servers）之间的逻辑上的联系。服务器（Servers）可以根据自身资源的可用程度、许可限制或其它因素限值并发会话（Sessions）的数量。对底层通信协议而言，每个会话（Sessions）都是独立的。通信协议的故障不会自动引起会话（Sessions）的结束。会话（Sessions）的结束是根据客户端（Clients）和服务器（Servers）的请求，或者根据客户端（Clients）的休止状态而定的。客户端（Clients）的休止时间间隔是在会话（Sessions）建立时商定的。