来源：数字化企业

作者：彭瑜

在⼯业的数字化转型中，彻底释放数据是必经之途。要彻底释放数据⾸先要解决三个关键问题，即：

• 创建规模化和范围广泛的设备连接和各种数据源连接

• 获取数据，并确定这些数据的存储空间

• 进行数据转换和处理，并发送到需要这些信息的系统和设备，供分析和决策、执行

本文旨在探讨如何解决这三个关键问题。

数字化转型规划其涉及的范围远超原有的⾃动化控制系统和企业管理系统的范围，因⽽规模趋⼤，趋于复杂，需要⾼效、⾼性能和包容性的通信技术和系统架构。

连接和获取数据的⽅法分为两⼤类: 

1）控制特定的⽹络和协议，

2）基于开放/标准的协议。

前者是标准的和专⽤的现场总线和⼯业以太⽹，后者包括两个正在流⾏的趋势，涉及 OPC UA 和 MQTT。开放协议 MQTT + Sparkplug 和 OPC UA + OPC 配套规范和信息模型是解决⼯业物联⽹ IIoT标准化和互操作性的重要选项。

MQTT 是⼀种轻量级通信传输协议，适⽤于带宽有限的⽹络和具有多个客户端和设备 的应⽤，这些客户端和设备以多对多的⽅式共享数据（图 1）。它使客户端能够发布和订阅 云或内部托管代理中的数据，这些代理（brokers）管理数据并将其路由到订阅的客户端。MQTT 本⾝并没有定义数据包中的数据格式（即有效负载），这会导致互操作性问题，以及 由于供应商规定了有效负载格式⽽形成的供应商锁定的⻛险。Sparkplug 扩展了基本的 MQTT，为⽤户、集成商和供应商提供了⼀种标准化的有效载荷格式，尽管不像OPC UA 信息模型那样定义得很完善，但还是定义了⽤于交换数据的模型。

MQTT 和 Sparkplug 的 ⽤户需要考虑使⽤智能的 MQTT 客户端和代理，⽽不仅仅是移动数据。智能客户端或智能代理将在同⼀连接上处理多种有效负载格式，能够⾃动将 MQTT 主题数据提取到标记中，以便于提供OPC 等标准使⽤，并处理数据连接质量状态的传播。如果控制决策依赖于MQTT 数据，那么智能客户端或智能代理必须解决丢失和⽆序消息的管理问题，保证消息顺序不发⽣差错地保存，并处理失败的写操作，以及⽹络停机时的地址存储和转发。

OPC UA（开放平台通信统⼀架构）标准是为不同⼯业系统、设备和应⽤之间提供数据交换和通信标准化框架的另⼀种强有⼒的⼿段。作为 OPC 经典标准的演进，OPC UA 标准定义了交换⼴泛⼯业数据的安全集成⽅法，以及通常⽤于特定的垂直⾏业数据交换的标准 化信息模型，这些信息模型具有定义完善的命名空间。

OPC UA 规范除了规定了基本的信息模型（DA，Data Access 数据存取信息模型，AC，Alarms& conditions 报警和状态信息模型，HA，Histories Access 历史数据存取信息 模型，等）外，还配备了以配套信息模型描述的⼯业标准信息模型（如 PLCopen、ISA 95、AutomationML 等）。图2 给出 OPC UA 信息模型的架构。

OPC UA 配套规范为 OPC 基⾦会发布的可⽤⾏业或通⽤技术信息模型提供了 XML 定 义⽂件，以快速授权客户端和服务器应⽤共享模型中的⾏业特定数据。⼀般⽽⾔，OPC UA 内含有语法的标准，不负责语义的定义，其语义的表达是通过配套的⾏业信息模型或某种专有技术的配套信息模型及其相应的规范来表达的，所以在这个意义讲，OPC UA 只是传递语义，⽽⾮定义语义。

经验丰富的⽤户和集成商还可以根据他们的业务需要定义和发布他们⾃⼰的配套信息模型，以便于与供应链或其他合作伙伴交换⼯⼚数据。这些数据不仅包括原始数据，还包 括历史和事件数据、元数据，还包括有关数据源、数据质量和数据点之间相互关系的详细 信息。OPC UA Pub/Sub (发布/订阅)是 OPC UA 协议的扩展，⽤于需要多对多通信的应⽤，为所有类型的数据提供有效的传输，包括在 OPC UA 信息模型中（⽆论是从配套规范 还是⽤户定义）的原始数据或格式化的数据。OPC UA Pub/Sub 也可以在 MQTT 传输上使⽤，使⽤户能够利⽤ OPC UA 配套规范和信息模型的⾼度标准化，以及 MQTT 的灵活性和简单性。

在任何实现中，都会存在没有以任何形式就地实现MQTT 或 OPC UA 系统和要连接的设备，因此必须通过设备更换或集成软件，或者提供连接和集成标准 PLC 和控制协议、传统设备和⾮标准协议设备的解决⽅案（⻅图 3）。现有的商⽤⼯业软件通过创建符合 MQTT 和 OPC UA 标准的具有可视化的组态接⼝，连接任何只具有串⾏或以太⽹的设备，并且运 ⽤ OPC UA 和 MQTT 标准的⽂档化及通信协议。这样的解决⽅案可以使众多的串⾏、USB 和以太⽹接⼝的设备即使不使⽤开放/标准协议集成，也⽆需编写任何⾃定义代码，就可以参与 MQTT和OPC UA 的数据交换。

现有⼤多数的⼯业信息系统建模采⽤的传统⾦字塔⽹络和系统架构结构（如图 4 所 示），依据⽤于定义控制功能和其他企业功能之间接⼝的功能建模标准 IEC 62264 /ISA 95 标准。这种体系结构的特点是⽤⼀个技术堆栈对包括位于底部的⼯⼚级组件和位于顶部的企业/云组件进⾏描述。在这个堆栈中，每⼀层相互连接，并且只与直接在其上或其下的⼀层通信。因此，数据通过点对点连接，且每次向上或向下传输⼀层。这种基于分层客户端- 服务器的架构，是实现 IEC 62264 /ISA 95 标准的⼀种⽅式。然⽽，IEC 62264 /ISA 95 并没有规定实现⾦字塔⽹络和系统体系结构的⽅法，这是因为它纯粹是⼀个功能建模标准，⽽不是⼀个互连⽹络标准。

显然，这种架构⽅法不适合构建智能制造系统，⼀⽅⾯是由于这种系统难以管理，数 据传输的耦合过于紧密，更重要的是这种系统不可扩展。明眼⼈从图 5 中就能清晰地看出其弊端。

图5 传统架构难以管理，耦合过于紧密，不可扩展

更合适的智能制造架构应该是如图 6 所示的模式，⽹络的参与者彼此之间不直接接触。它们将⾃⼰的信息发布到⼀个中央信息存储库，即⼀个统⼀的命名空间。然后，其他 参与者可以按需从统⼀命名空间中提取对其有⽤的信息。由于所有的直接通信都被完全删 除，因此很容易将控制系统与 IT 系统合并，⽽不需要了解彼此的实现细节。事实上，在统 ⼀命名空间体系结构中，如果将供应商 A 的设备替换为供应商 B 的设备，只要新设备的信息发布到与⽼设备相同的主题命名空间，其他⽹络参与者甚⾄会浑然不知这种变化。使⽤统⼀命名空间还允许智能制造系统可以按需地加以扩展，这是另外⼀个明显的优点。

最早的 UNS 项⽬由 UNS 的最重要的倡导者 Walker Reynolds 于 2005 年构建的。这个项⽬是为盐矿实施的，使⽤了动态数据交换（DDE）与 Excel 电⼦表格。在接下来的⼀年⾥，该项⽬适应了 MQTT 技术。

从⾃动化的⻆度来看，UNS 是⼀种通⽤的命名约定，它根据设备、数据点和服务的位置、功能、类型等属性进⾏组织。进⼀步说 UNS 不仅是⼀种命名约定，⽽且是⼀种满⾜以下要求的架构:

• UNS 是业务数据和事件的语义层次结构。；

• UNS 是连接所有智能设备和 IT 基础设施的枢纽。；

• UNS 是业务中所有数据和信息的唯⼀真实来源。；

• UNS 是数字化转型的基础。；

• UNS 是业务的当前状态所在，⽀持业务的实时快照。

总之，UNS 是⼀个本体通信层，它连接了 IIoT 中的所有其他部分。它提供了⼀个共享 的数据枢纽，⽀持不同系统和利益相关者之间的通信和协作，⽽不管其底层技术或供应商如何。这种共享的数据枢纽可以提⾼⼯业物联⽹系统的互操作性、可扩展性和灵活性，降低集成成本，加快上市或⼯程时间。

从本质上讲，统⼀命名空间是⼀种中间件解决⽅案，运⽤它可以从各种⼯业系统采集数 据，为其添加语义环境，并 将 其 转 换 为 其 他 系 统 可 以 理 解 的 格 式 。实 现 统 ⼀ 命 名 空 间 的 ⽅ 法 之⼀是使⽤基于 Sparkplug 的⽹络体系结构。事实证明，统⼀命名空间体系结构和 IEC 62264 /ISA 95 实际上是相互补充的。我们完全可以基于统⼀命名空间架构设计智能制造系统，然后使⽤ IEC 62264 /ISA 95 标准对推送到统⼀命名空间的数据对象进⾏建模。这样我们便可以使⽤⼀种创新和现代的⽅式来组织制造系统的组件，并完善地结合⼀种经过验证和测试、 且在全球⼴泛使⽤的企业信息集成的功能建模标准。

由此我们可以得出这样的结论，虽然依据 IEC 62264 /ISA 95 标准构成的数据架构在世纪90年代中后期起发挥了很⼤作⽤，但当前如果企业盲⽬地将其作为数字化转型战略的基础，显然会冒着巨⼤的⻛险，导致许多数字化转型的努⼒都以失败告终。

创建和实现统⼀命名空间（UNS）的概念是⼀种积极的趋势，它⽀持有效的信息交 换，从⽽⽀持实时决策。使⽤ UNS 有助于打破信息孤岛，使企业能够从⼴泛的来源收集和 分析数据，从⽽提供更完整的运营情况。UNS ⽀持在所有应⽤的分布式环境中都有效，⽽不是仅在某⼀处有效。进⼊ UNS 模型的信息的⼯具应该符合标准化的要求。OPC UA、UA信息模型、UA Pub/Sub、MQTT 和 MQTT Sparkplug、OPC UA over MQTT 都是满⾜这些要 求的技术，此外,HTTP、Modbus Plus 也是可以⽤于 UNS。运⽤这些技术使数据进⼊ UNS 成为可能。在这些⼯具中，MQTT Sparkplug 使⽤轻量级消息传递协议，使其⾮常适合低带 宽或不可靠的⽹络。⽽ OPC UA 采⽤更健壮的消息传递协议，能够处理更⼤的数据量，这更适合⾼速和安全的⽹络。

将未经验证的数据发送到云端既浪费带宽，⼜浪费数据摄⼊费⽤和时间。解决这个问 题的措施是数据验证、语义语境化，将数据转化为信息，并进⾏处理运⾏操作和业务或事 务数据库和系统的集成，这是运⽤数据增值的⼀个重要环节。经过这些转换和处理后所取 得的信息，可以为提供可操作的⻅解，实现明智的决策，推动运营效率的提⾼和⽀持持续 改进计划发挥巨⼤作⽤，从⽽为增值作出贡献。应该指出的是，在⼯业⾃动化的范畴内语 义语境化严格受到⾏业标准的规范和限制，这也是 OPC UA 通过配套信息模型构建⾏业语义语境的基本出发点。

填平数据鸿沟需要⼀个超越前⾯讨论的典型连接性的全⾯解决⽅案，即统⼀分析框架 （UAF，Unified Analysis Framework）。这种解决⽅案的基本功能包括数据清理、规格化 （normalizing，⽤标准格式表示）和语义语境化，以及向各种使⽤者，包括前⾯提到的统⼀命名空间 UNS 提供数据。此项⼯作内容应该尽可能在靠近数据源的边缘⾼效地完成，⽽不应该将可能⽆效或未聚合的数据发送到云端进⾏分析、机器学习和进⾏其他增值活动。

为 OT 构建⼀个对业务和云集成有敏锐理解的统⼀分析架构 UAF 和数据转换处理的软件。UAF 解决⽅案的⽬的是转换在边缘收集的数据，为在云中进⾏的⾼级分析、⼈⼯智能 和机器学习做好准备。可以将此视为将⼯业信息源（如流程历史数据、业务数据、⼿动收 集的数据等）连接到各种数据使⽤端的信息中⼼。作为⼀个中⼼，该软件为来⾃各种源的 数据语义语境化、数据清理和 KPI 计算提供了⼀个集中的位置，以便⼤规模地执⾏和管理。

理想情况下，UAF 解决⽅案在边缘运⾏，并囊括本地 OT 数据（DCS、PLC、智能⼿机 等）的连接，以及与事务性业务数据源（ERP、MES、过程历史数据库、SQL 数据库等）的连接；并且进⾏数据转换处理计算和语义语境化，还可以通过业务层和云发布结果（⻅图 7）。这样做的好处是降低了云系统摄⼊数据的成本，但更重要的是，可以确保将⾼质量的 数据交付给云系统，⽽不是在分析之前浪费时间清理云中的数据。可以通过在不同层进⾏跨业务管理的模板化来提供可伸缩的数据治理⼯程。

在基于统⼀分析架构 UAF 的数据处理软件中，OPC 路由器是⼀款⾼度可组态的软件⼯ 具，⽤于使⽤拖放可视化⼯作流集成各种⼯业业务和物联⽹数据源，旨在减少智能制造，⼯业物联⽹和数字化转型应⽤中的⼯程时间和⻛险。主要特点是:

• OPC 客户端连接到 OPC UA, OPC DA 和 OPC XML-DA 服务器 

• OPC UA 服务器，包括数据访问和 Method 触发器 

• 与数据库的连接包括：Microsoft SQL Server, MySQL, Oracle, MongoDB, InfluxDB 和其它 ODBC 数据库 

• 通过 SMB (Windows 共享)和 FTP (SSL & plain)访问⽂件，⽤于可扩展企业实现的 存储和转发、冗余和模板 

• 可视化⼯作流加快了与各种数据源的连接 

• SAP 认证的 ERP 集成连接器 

• SOAP-Web 服务连接器，⽤于集成其他 ERP/MES 系统或将任何 SOAP Web 服务 数据转换为 OPC

智能制造和⼯业数字化转型计划的成功需要考虑许多因素。其中最为关键的是要解决获取正确的数据，对其进⾏转换并将其传送到正确的位置，供进⼀步分析决策使⽤。在这个关键的环节中，国内尚没有相应的系统成套的⼯具性⼯业软件，致使在⼯业企业数字化转型的规划中都需要⾃⾏开发类似的软件，因⽽⼯作效率和成功率都难以保证。开发可供⼴泛运⽤的⼯具性软件应该受到急迫的重视和推动。