REDISANT 提供互联网与物联网开发测试套件 #

OPC UA 的动机 #

第一个也是最成功的经典 OPC 标准——OPC DA 被设计为通信驱动程序的接口，允许对自动化设备中的当前数据进行标准化的读写访问。主要用例是 HMI 和 SCADA 系统使用硬件供应商提供的一个定义软件接口访问来自不同供应商的不同类型自动化硬件和设备的数据。后来的标准，如 OPC 报警事件和 OPC 历史数据访问，也被设计用于访问 SCADA 系统提供的信息。

随着 OPC 在数千种产品中的成功采用，OPC 如今被用作自动化金字塔不同层级的自动化系统之间的标准化接口。它甚至被用于许多它原本没有被设计的领域，还有更多的领域，制造商希望使用像 OPC 这样的标准，但由于 OPC 的 COM 依赖性或使用 DCOM 进行远程访问的限制而无法使用它。

OPC XML-DA 是 OPC 基金会保留 OPC 成功功能但使用与供应商和平台无关的通信基础设施的第一个方法。有几个原因导致仅创建成功的 OPC 规范的 Web 服务版本无法满足新一代 OPC 的要求。其中一个原因是 XML Web 服务的性能与原始 COM 版本相比较差。此外，使用不同的 XML Web 服务堆栈会导致互操作性问题。

但除了平台独立性问题之外，OPC 成员公司还提出了公开复杂数据和复杂系统的要求，从而消除了传统 OPC 的限制。

OPC 统一架构的诞生源于这样的愿望：创建一种真正替代所有现有基于 COM 的规范的方案，而不会丢失任何功能或性能。此外，它必须满足平台独立系统接口的所有要求，具有丰富且可扩展的建模功能，能够描述复杂系统。使用 OPC 的广泛应用需要可扩展性，从 SCADA 和 DCS 的嵌入式系统到 MES 和 ERP 系统。表 1.1{reference-type=“ref” reference=“table-1-1”} 列出了 OPC UA 最重要的要求。

这些要求可以分为分布式系统之间能够交换信息的通信要求和描述系统和可用信息的数据建模要求。

经典 OPC 被设计为设备驱动程序接口。如今 OPC 被用作系统接口；因此，分布式系统之间通信的可靠性非常重要。由于网络通信从定义上来说并不可靠，因此稳健性和容错性是重要的要求，包括高可用性的冗余。平台独立性和可扩展性对于将 OPC 接口直接集成到在许多不同平台上运行的系统中是必不可少的。要取代专有通信，一个重要的要求始终是在内联网环境中的高性能。但通过防火墙的互联网通信也必须能够开箱即用，这使得安全性和访问控制成为另一个重要的要求。最重要的是，来自不同供应商的系统之间的互操作性仍然是最重要的要求。

{#table-1-1}

在传统 OPC 中，数据建模非常有限，需要通过为所有 OPC 数据提供通用的面向对象模型来增强。该模型必须包含一个可扩展的类型系统，以便能够提供元信息并描述复杂系统。服务器提供和描述的方法以及客户端可调用的方法的可用性是使 OPC 灵活且可扩展所需的强大功能。需要复杂数据来支持复杂数据结构的描述和一致传输。增强建模能力是一项重要要求，但同样重要的是用简单的概念支持简单的模型。因此，需要有一个简单、抽象但可扩展的基础模型，以便能够从简单模型扩展到复杂模型。

除了新一代 OPC 的功能要求外，定义 OPC 统一架构要求和用例的初始小组由 40 多名代表组成，他们不仅由 OPC 成员组成。其他标准化组织（如 IEC 和 ISA）也参与了早期的设计过程，这些组织有意使用 OPC 作为其信息的传输机制。在这个小组中，OPC 基金会定义了如何描述和传输数据，而合作组织则根据他们的信息模型定义他们想要描述和传输什么数据。

另一个重要的设计目标是允许轻松迁移到 OPC 统一架构，以保护对非常成功的经典 OPC 标准的投资，并在 OPC 的庞大安装基础上进行构建。

OPC UA 概述 #

为了达到定义的目标，OPC统一架构建立在不同的层上，如图1.6{reference-type=“ref” reference=“fig-1-6”}所示。

{#fig-1-6 width=“0.8\linewidth”}

OPC 统一架构的基本组成部分是传输机制和数据建模。

传输定义了针对不同用例优化的不同机制。OPC UA 的第一个版本定义了一种优化的二进制 TCp 协议，用于高性能内部网通信，以及映射到公认的互联网标准（如 Web 服务、XML 和 HTTP），以实现防火墙友好的互联网通信。两种传输都使用与 Web 服务相同的基于消息的安全模型。抽象通信模型不依赖于特定的协议映射，并允许在将来添加新协议。第 6 章更详细地描述了传输机制。

数据建模定义了使用 OPC UA 公开信息模型所需的规则和基本构建块。它还定义了进入地址空间的入口点和用于构建类型层次结构的基本类型。可以通过在抽象建模概念之上构建的信息模型来扩展此基础。此外，它还定义了一些增强的概念，例如描述在不同信息模型中使用的状态机。第 2 章介绍了信息建模的基础知识，第 3 章介绍了一个示例和最佳实践。

UA 服务是信息模型供应商服务器与信息模型消费者客户端之间的接口。服务以抽象方式定义。它们使用传输机制在客户端和服务器之间交换数据。

OPC UA 的这一基本概念使 OPC UA 客户端能够访问最小的数据片段，而无需了解复杂系统所公开的整个模型。OPC UA 客户端还了解特定模型，可以使用为特殊领域和用例定义的更多增强功能。图 1.7{reference-type=“ref” reference=“fig-1-7”} 显示了由 OPC、其他组织或供应商定义的不同层次的信息模型。

{#fig-1-7 width=“0.8\linewidth”}

为了涵盖传统 OPC 中已知的所有成功功能，OPC UA 在基础规范之上定义了过程信息领域的信息模型。DA 定义了自动化数据特定的扩展，例如模拟或离散数据的建模以及如何公开服务质量。所有其他 DA 功能都已包含在基础规范中。警报条件 (AC) 指定用于过程警报管理和条件监控的高级模型。历史访问 (HA) 定义了访问历史数据和历史事件的机制。程序 (Prog) 指定启动、操作和监控程序执行的机制。

其他组织可以在 UA 基础或 OPC 信息模型之上构建他们的模型，通过 OPC UA 公开他们的特定信息。已经在映射到 OPC UA 的标准示例是现场设备集成 (FDI)，结合了电子设备描述语言 (EDDL) 和现场设备工具 (FDT)，两者都用于描述、配置和监控设备，以及 PLCopen，这是 PLC 编程语言的标准。

将直接使用 UA 基础、OPC 模型或其他基于 OPC-UA 的信息模型来定义其他特定于供应商的信息模型。

OPC UA 规范 #

OPC UA 规范分为不同的部分，这也是 IEC 标准化所必需的。OPC UA 将被称为 IEC 62541 标准。图 1.8{reference-type=“ref” reference=“fig-1-8”} 显示了所有规范部分的概览，分为定义 OPC UA 基础的核心规范和主要指定 OPO UA 信息模型的访问类型特定部分。

{#fig-1-8 width=“0.8\linewidth”}

前两部分不是规范性的。概念部分 [UA 第 1 部分] 概述了 OPC UA，[UA 第 2 部分] 描述了 OPC UA 的安全要求和安全模型。

了解如何建模和访问信息最重要的是第 3 部分和第 4 部分。这两个规范是设计和开发 OPC UA 应用程序的关键文档。

地址空间模型 [UA 第 3 部分] 指定了用于公开实例和类型信息的构建块，从而指定了用于描述和公开信息模型以及构建 OPC UA 服务器地址空间的 OPC UA 元模型。

[UA 第 4 部分] 中定义的抽象 UA 服务表示 UA 客户端和 UA 服务器应用程序之间可能的交互。客户端使用服务来查找和访问服务器提供的信息。服务是抽象的，因为它们定义了要在 UA 应用程序之间交换的信息，而不是网络上的具体表示，也不是应用程序使用的 API 中的具体表示。图 1.9{reference-type=“ref” reference=“fig-1-9”} 显示了 OPC UA 的分层通信架构。

{#fig-1-9 width=“0.8\linewidth”}

[UA 第 6 部分] 定义了 UA 服务与消息的映射、应用于消息的安全机制以及消息的具体有线传输。只有 UA 堆栈的实施者才需要完全理解此规范。由于 OPC 基金会提供了适当的 UA 堆栈，因此典型的 UA 应用程序架构师和程序员不需要阅读此规范。

[UA 第 5 部分] 中指定的基本信息模型为使用 OPC UA 的所有信息模型提供了框架。它定义了以下内容：

• 客户端用于浏览 OPC UA 服务器的实例和类型的地址空间入口点

• 为不同类型层次结构构建根的基类型

• 内置但可扩展的类型，如对象类型和数据类型

• 提供功能和诊断信息的服务器对象

配置文件（Profiles）定义了 [UA 第 7 部分] 中 OPC UA 功能的有用子集。这样的子集必须由 UA 应用程序完全实现，以确保所定义子集的互操作性。该规范在两个级别上定义了子集。第一级是一致性单元，它定义了一小组始终一起使用的功能，可以使用一致性测试工具进行测试并作为单元进行验证。第二级是配置文件，由一系列一致性单元组成。配置文件必须完全实现，并将在 OPC UA 产品认证期间验证为完整集。在客户端和服务器之间建立连接期间，将交换受支持和使用的配置文件列表，并允许应用程序确定通信伙伴是否支持所需的功能。

DA 信息模型定义了如何表示和使用自动化数据和特定特征，例如 [UA 第 8 部分] 中的工程单元。

AC 信息模型在 [UA 第 9 部分] 中指定了过程报警和条件监控特定状态机和事件类型。

程序信息模型在 [UA 第 10 部分] 中定义了用于执行、操作和监控程序的基本状态机。

[UA 第 11 部分] 中的 HA 信息模型指定了历史访问服务的使用以及如何呈现有关数据和事件历史配置的信息。

用于从原始数据样本计算聚合值的聚合器在[UA 第 13 部分] 中有规定。聚合器用于历史访问以及当前值的监控。

[UA Part 12]定义了如何在网络中查找服务器以及客户端如何获取必要的信息以便与某个服务器建立连接。

OPC UA 软件层 #

OPC UA 使用与传统 OPC 类似的客户端-服务器概念。想要向其他应用程序公开其自身信息的应用程序称为 UA 服务器，想要使用来自其他应用程序的信息的应用程序称为 UA 客户端。但预计一个应用程序中同时是 UA 服务器和 UA 客户端的应用程序将比传统 OPC 中的应用程序多得多。原因之一是更多的 UA 服务器将直接集成到设备中。实现 UA 客户端还可以实现设备到设备的通信。另一个原因是使用 OPC UA 作为配置接口，其中 UA 客户端也是通过 OPC UA 配置的 UA 服务器。

典型的 OPC UA 应用程序由图 1.10{reference-type=“ref” reference=“fig-1-10”} 所示的三个软件层组成。完整的软件堆栈可以用 C/C++、.NET 或 JAVA 实现。OPC UA 不限于这些编程语言和开发平台，但目前只有这些环境用于实现 OPC 基金会 UA 堆栈交付成果。

{#fig-1-10 width=“0.8\linewidth”}

OPC UA 应用程序是一个希望通过 OPC UA 公开或使用数据的系统。它包含应用程序的特定功能以及通过使用 OPC UA 堆栈和 OPC UA 软件开发工具包 (SDK) 将此功能映射到 OPC UA。

OPC UA 客户端或服务器 SDK 实现作为应用程序层一部分的通用 OPC UA 功能，因为 UA 堆栈仅实现通信通道。OPC UA SDK 减少了开发工作量并促进了 OPC UA 应用程序的更快互操作性。

OPC UA 堆栈实现 [UA 第 6 部分] 中定义的不同 OPC UA 传输映射。堆栈用于跨进程或网络边界调用 UA 服务。OPC UA 定义了三个堆栈层，每个层都有不同的配置文件。消息编码层以二进制和 XML 格式定义服务参数的序列化。消息安全层指定如何使用 Web 服务安全标准或 Web 服务标准的 UA 二进制版本来保护消息。消息传输层定义所使用的网络协议，可以是 UA TCP 或 HTTP 和用于 Web 服务的 SOAP。图 1.11{reference-type=“ref” reference=“fig-1-11”} 说明了不同的 UA 通信堆栈层。UA 堆栈中各层的实现以及应用程序的 API 不属于 OPC UA 规范。UA 堆栈为 UA 客户端和 UA 服务器应用程序提供语言相关的 API，但服务及其参数相似，并基于 [UA 第 4 部分] 中的抽象服务定义。

{#fig-1-11 width=“0.8\linewidth”}

通过在 ANSI C/C++、.NET 和 JAVA 中实现，OPC 基金会开发和维护的 UA Stacks 涵盖了主要的开发环境和编程语言。

进化而非革命 #

OPC UA 比所有 Classic OPC 规范加起来更加灵活，功能也更多，但它融合了现有 OPC 规范的所有成功概念，修复了现有标准中的已知问题，并为许多额外用例增加了标准化。

允许从 Classic OPC 轻松迁移到 OPC UA 是一个重要的设计目标。因此，大多数 Classic OPC 中已知的功能都可以在 OPC UA 中找到，有时使用的术语略有不同。不可能使用 Classic OPC 接口公开所有 UA 功能，但将 Classic OPC 功能映射到 OPC UA 是没有问题的。

OPC UA 允许简单的映射并提供迁移策略来集成基于先前 OPC 标准的 OPC 产品。迁移策略的一部分甚至不需要更改现有产品。OPC 基金会提供的包装器和代理能够将不同的 Classic OPC 接口转换为 OPC UA，反之亦然。供应商可以使用迁移策略中的第一级来支持旧产品的 OPC UA。

向 OPC UA 迁移的第二个层次是将 OPC UA 直接集成到现有产品中，而无需添加 OPC UA 特定功能。此步骤不需要更改目前系统与其 OPC 通信组件之间使用的接口。如果系统的现有接口不必更改，则集成新组件要容易得多。与使用包装器或代理相比，其优势在于通过删除额外的软件层，性能更好，配置和工程工作更少。直接集成将更容易消除包装器和代理的潜在限制，并允许通过逐步添加 OPC UA 功能采用迭代开发方法。

第三个层次可能需要更改产品的内部接口以支持产品感兴趣的所有 OPC UA 功能。OPC UA 将允许系统以标准方式提供产品功能，如果没有 OPC UA 提供的新选项，它们现在就无法展示这些功能。

对于最终用户来说，拥有可用的包装器和代理以将大量安装的 Classic OPC 产品迁移到 OPC UA 非常重要。最终用户可以安装包装器和代理，以便通过防火墙传输传统 OPC，包括通过互联网进行安全传输和经过身份验证的访问，因此它们只是为现有的经过行业验证的解决方案增加了价值。

这些组件只是第一步。对于供应商而言，更重要的是 OPC UA 在标准的所有领域提供抽象、模块化和简单的基础概念，从而允许将现有 OPC 功能轻松迁移到 OPC UA。扩展此基础的强大概念使供应商能够通过 OPC UA 展示越来越多的系统功能。这导致了一个迭代开发和改进过程。

总结 #

关键信息 #

OPC 基金会为工业自动化中的数据交换提供了标准。这包括非常成功的当前数据 OPC DA 规范，以及警报和事件的 OPC A&E 和历史数据的 OPC HDA。所有这些规范都基于即将淘汰的 COM/DCOM 技术。迈向最先进技术的第一步是 OPC XML-DA，它仅使用 XML 作为数据传输格式，因此不符合典型 OPC 应用程序的性能要求。

根据从 OPC XML-DA 中吸取的经验教训，OPC 基金会创建了一个名为统一架构的新标准。在这里，传输可以通过 SOAP 和 HTTP 等标准使用防火墙友好的 Web 服务或优化的二进制 TCP 协议来实现高性能通信。OPC UA 提供可互操作且独立于平台、高性能、可扩展、安全且可靠的应用程序间通信。从 Microsoft 的 COM/DCOM 到最先进的、独立于平台的传输协议的技术转换允许 OPC UA 应用程序在智能设备和控制器以及 DCS 和 SCADA 系统上运行，甚至在企业级 MES 和 ERP 系统中运行。与传统 OPC 应用程序相比，这极大地增加了使用范围。

除了传输之外，OPC UA 的第二大成就是信息建模。OPC UA 通过在一个地址空间中公开当前数据、事件通知和两者的历史记录，统一了不同传统 OPC 规范的功能。它还使用面向对象的概念提供了一个丰富且可扩展的信息模型，允许公开应用程序的元数据和复杂数据。可扩展机制允许其他组织定义标准信息模型，这些组织可以利用 OPC UA 通信基础设施并专注于标准化要公开的信息。目前已经有计划定义标准信息模型，例如，通过将 EDDL 和 FDT 映射到 OPC UA 来定义设备描述的 FDI，或通过 PLCopen 定义 PLC 编程语言的 FDI。与传输功能一样，OPC UA 的建模功能也具有良好的可扩展性。您可以使提供的信息保持简单，类似于传统 OPC，但您也可以使用类型系统来丰富信息，从而提供更多在许多应用场景中有用的信息。

哪里可以找到更多信息？ #

有关经典 OPC 的信息可在 OPC 基金会网站 (www.opcfoundation.org) 上找到。还有一本关于经典 OPC [IL06] 的书。有几家供应商提供经典 OPC 产品和工具包。可在 www.opcconnect. com 上找到列表；在这里您可以找到有关 OPC（包括 OPC UA）的概述信息。可在本书网站 www.opcuabook.com 上找到其他链接和信息。

有关 OPC UA 的一般信息可在 OPC 基金会网站上找到，其中包括有关 OPC UA 的特别部分 (www.opcfoundation.org/ua)。该网站还提供对 OPC UA 规范的访问，其中 [UA 第 4 部分] 和 [UA 第 6 部分] 侧重于数据传输，[UA 第 3 部分] 和 [UA 第 5 部分] 侧重于建模信息。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：https://blog.redisant.cn