从可视化到行动：Unity、机器信息系统、人工智能代理和工业数字孪生

面向系统集成商、OEM厂商和自动化工程师的实用指南

与realvirtual.io 的首席执行官Thomas Strigl合作

作者简介：Thomas Strigl 是 realvirtual.io 的首席执行官，在仿真和自动化软件领域拥有超过 18 年的经验。

简介

在我们之前的指南中，设计、模拟、部署：为什么Unity对工业Digital Twins至关重要我们讨论了Unity作为构建工业系统实时3D模型平台的应用。那里提出的论点仍然适用。在本系列共两部分、内容全面的电子书中，我们将重点讨论两个与该基础密切相关的议题：

大型语言模型、人工智能代理和模型上下文协议（MCP）的快速发展：这些工具现在已经从研究领域转移到一些集成商开始在生产环境中使用的工具领域。

欧盟机械法规 (EU) 2023/1230 ：该法规于 2023 年通过，其全面实施日期——2027 年 1 月 20 日——已广为人知。现在发生变化的是截止日期临近了。现在发生变化的是截止日期临近了。距离目标日期不到两年，配套框架正在逐步形成：协调标准正在修订，应用指南正在起草，机器制造商正在从意识层面转向实施层面。新的网络安全规定正在成为运营要求，而该法规对结构化数字文档的明确支持，正在将文档从静态交付物转变为可维护的生命周期资源。

这两个发展通常是分开讨论的。本电子书系列将它们放在一起讨论，因为它们的基础工作有很多重叠之处。人工智能系统需要结构化的、有依据的数据。为遵守监管规定而准备的结构化数字文档也可以作为工业人工智能系统的基础材料。第 1 部分中描述的四层架构——信号、MES 上下文、文档和空间上下文——既支持操作员，也支持以后添加的任何 AI 工具。

3D HMI （或者更准确地说，当实时机器数据、企业环境和结构化文档集成到同一空间表面时出现的机器信息系统）是机器数据、文档和 AI 生成的信息汇聚在一起供操作员使用的地方。

本文的目的并非声称人工智能将改变工厂，而是描述集成商可能会发现有用的实用架构模式，并使用现有的工具和标准。该架构本身就具有运营价值；法规只是让欧洲市场的时机更加明确。

第一部分

连接层：数据、文档和3DHMI

1.超越数字孪生

前一本电子书讨论了数字孪生作为一种工具，当它们连接到真正的自动化系统并反映整个生命周期中真实的机器行为时，就会变得更加有用。这一基础至今仍在影响着制造商进行数字化转型的方式。

对于系统集成商而言，价值问题通常不在于视觉保真度，而在于集成性。包装线、堆垛机或分布式仓库需要具备可操作性、可支持性和可维护性——通常需要十年或更长时间。相关问题变成了数字孪生体如何很好地连接数据、人员和文档，从而使系统在其运行生命周期内得到支持。

这种一体化环境带来的运营效益是巨大的，而且与任何监管环境无关：

• 更快的故障诊断：

连接到实时机器和过程数据的3D HMI可以缩短故障诊断时间，因为操作员可以在空间上下文中看到受影响的组件，而不是将符号故障代码映射到物理位置。

• 降低专业技能门槛：

降低经验门槛对于新员工、轮班工人和轮岗人员来说——鉴于机械和电气领域熟练技术人员短缺的普遍现象，这几乎与每个工业部门都相关。

• 高效的远程支持：

这使得远程支持变得有意义，因为制造商的服务技术人员可以看到操作员在相同的3D环境中看到的内容，并可以给出精确的指示。

• 培训不中断生产：

允许在不停止生产的情况下，针对实际机器配置进行训练。

• 机器层面的运行环境：

最后，当机器信息系统数据（订单、批次、KPI、能源数据）叠加在同一个3D视图上时，操作员不仅可以看到机器是否在运行，还可以看到它在上下文中的运行情况。

无论法规是否要求提交文件包，这些好处都会随之而来。它们是本指南所述架构的实际应用案例。第 3 节讨论的监管案例是并行进行的：新的欧盟机械法规引入的结构性变化恰好与同一架构相一致，这意味着监管工作和运营工作相互重叠，而不是争夺单独的预算。

这改变了数字孪生体的角色。3D模型不仅仅是一种可视化工具，它还可以作为空间索引，将信号、企业数据和文档以操作员以及越来越多的 AI 工具可以浏览的形式联系起来。

2.构成数字孪生的四个数据层

运行中使用的数字孪生体通常与四个不同的数据层进行交互。它们各自单独来看都是不完整的。

信号层速度最快，成本最低。PLC 输入和输出、驱动器位置、传感器状态、报警——这些值以毫秒为周期变化。这是虚拟调试和行为仿真已经使用的层，通常通过 OPC 买量、Beckhoff ADS、Siemens S7 TCP/IP 或 MQTT 来实现。对于大多数数字孪生应用场景，10-50毫秒范围内的更新周期就足够了。

MES层速度较慢且范围较广。生产订单、批次、配方、关键绩效指标、物料流、质量记录、能源数据。这些数据是事件驱动的，通常通过 REST API、OPC 买量、消息代理或直接数据库连接来访问。这一层提供了使信号数据可解释的上下文：同一条传送带以相同的速度运行，根据它当前正在处理的订单的不同，其含义也不同。

文档层历来是最不受重视的一层。操作说明、电气原理图、工艺流程图、风险评估、合格声明、零件清单、软件版本、维护程序、维修历史记录。在大多数安装中，这一层以绑定器、网络共享或 PDF 存档的形式存在——只有知道自己要查找什么的人才能搜索。根据新的欧盟机械法规，这一层的结构正在发生变化，这是下一节的主题。

空间/上下文层就是3D模型本身。它可以作为其他三层之间的统一坐标系。信号地址是抽象的；而将同一信号映射到操作员可以看到并点击的特定阀门上，则更容易解释。

3.根据新机械法规提交的文件

十多年来，投放欧洲市场的机械设备的随附技术文件一直受机械指令 2006/42/EC 的约束。熟悉的义务——附件七下的技术文件、使用说明、欧盟符合性声明、10 年的保存期——通常通过印刷手册、PDF 存档和纸质声明来履行。

该框架将被替换。新的机械法规（欧盟）2023/1230 号于 2023 年 6 月 14 日通过，并将于 2027 年 1 月 20 日全面生效。它废除了 2006/42/EC 号指令，并且作为一项法规而不是指令，直接适用于所有欧盟成员国，无需各国进行国家层面的转化。

该法规已经颁布一段时间了，但配套框架仍在完善中。委员会于 2025 年 1 月通过了向 CEN 和 CENELEC 提出的标准化请求，目标是在 2026 年底前在官方期刊上发布一套完整的协调标准。官方申请指南的初稿预计将于 2026 年初开始编写，最终版本可能在 2026 年底出版。实际的解释工作正在进行中，从 2027 年 1 月 20 日起投放市场的项目都需要符合相关规定。

在描述这些变化之前，需要指出一个关键点，因为这一点很容易被误解：纸质文件在新法规下仍然完全合规。以下所述的变更适用于选择以数字方式交付文档的制造商——该法规现在明确地开辟了这条途径，但并未强制要求。

该法规引入的三项变更与机械制造商和系统集成商尤为相关。相关文章全文转载于附录中。

现在明确允许使用电子文档：第 10(7) 条允许以数字格式提供使用说明。第 10(8) 条允许以数字方式提供欧盟符合性声明，可通过互联网地址或机器可读代码访问。部分完成的机械的组装说明（第 11 条）也可以以数字方式提供。纸质文件仍应按需提供，某些对非专业用户而言至关重要的安全信息必须保留纸质形式。

对于选择数字化路线的制造商而言，相关文档必须在机器投放市场后至少 10 年内，或在机器的预期使用寿命内（以较长者为准）保持在线可访问状态。实际上，这很少仅仅是十年：工业机器通常运行十五年、二十年甚至三十年，因此，对于大多数装置而言，使用寿命条款才是具有约束力的限制，而不是 10 年的基准。制造商始终负责在整个产品生命周期内保持文档的可访问性、时效性和版本控制。

网络安全被列为一项重要的健康和安全要求。附件三第 1.1.9 节（防止腐败）和第 1.2.1 节（控制系统的安全性和可靠性）要求控制系统能够抵御可能导致危险情况的合理可预见的恶意企图。基于人工智能的安全功能和自学习系统明确在范围内，高风险类别需进行更严格的合格评定。

实际结果是，采用数字化路线的制造商从一次性交付转变为维护、结构化的在线资源，该资源在其机器的整个运行周期内与机器并存。纸质交付仍然是一种完全合规的替代方案，并且对于面向非专业用户的安全关键信息仍然是强制性的。

新规对制造商意味着什么

一个相关的实际问题是，供应商提供的组件数据（驱动器、传感器、阀门、PLC、安全组件、IO-Link 主站）如何输入到制造商的技术文件中。目前发展势头最强劲的结构化格式是资产管理外壳 (AAS) ，它是由 IEC 63278 和工业数字孪生协会 (IDTA) 定义的机器可读数字孪生规范，用于各个组件。

AAS分层以标准化的形式存储特定组件的铭牌数据、技术规格、文档和子模型（用于安全、能源、维护），任何具备 AAS 能力的用户都可以读取这些数据。

AAS 还不是普遍的行业标准——采用情况尚不完全，生态系统仍在发展成熟，许多供应商才刚刚开始发布——但发展轨迹才是关键：一旦达到一定数量的供应商交付 AAS 子模型，满足 (EU) 2023/1230 条例的结构化电子文档，同时为基于 AI 的诊断奠定基础，就变成了一个配置问题，而不是一个手动集成项目。

已发布 AAS 子型号的供应商包括西门子（SIMATIC S7-1500）、费斯托（VTSA 阀终端）、ABB（ACS880 驱动器）、倍加福（IO-Link 主站）、WAGO 和 Murrelektronik。将 AAS 作为标准供应商输入格式，使得机器的整个生命周期内组件链可追溯——这是法规对机器随附技术文档的要求——并且使得机器信息系统运行时引用的结构化文档（在第 6 节的参考架构中显示为供应商 AAS输入）能够扩展。

4.从3DHMI到机器信息系统

在前一本电子书中， 3D HMI被描述为一个可视化层，它反映了机器在空间环境中的状态。通过添加 MES 和文档层，同样的3D HMI演变成更大的东西：机器信息系统——一个集成实时机器状态、企业环境和结构化文档的单一空间表面，并将所有这些信息呈现给操作员在相关位置的信息。

术语很重要。传统的HMI是一种控制和监控界面——它显示机器状态并接受操作员输入。制造执行系统 ​​(MES) 位于更高的组织层级，负责管理跨机器和生产线的订单和生产数据。在本电子书中，机器信息系统 (MIS) 位于机器本身：它是一个集成视图，将有关这台特定机器的各种信息（传感器状态、当前订单、手册、原理图、报警历史记录、软件版本、符合性声明）整合到一个可导航的空间界面中。

它扩展了HMI的信息功能，但不一定包含控制功能：机器信息系统可以是纯粹只读的，在很多情况下，这是更简单、更安全的选择。原因在于：网络安全要求下的攻击面减少，需要认证和记录的范围缩小，并且其态势能够清晰地映射到操作员信息、维护支持和培训工作流程。

定义机器信息系统

关于术语的说明：本电子书中使用的资产级机器信息系统(MIS) 是我们提出的一个术语，而不是一个既定的行业类别。传统人机界面 (HMI) 侧重于机器控制和操作员交互，制造执行系统 ​​(MES) 平台管理企业级生产和工作流程，而资产生命周期信息管理系统处理工程、文档和生命周期数据。每种方法都满足了操作员的部分信息需求，但没有一种方法能够完全描述通过空间3D界面呈现的集成式、机器特定的视图。

这里使用“机器信息系统”一词来描述缺失的层面：一个统一的机器级信息表面，它将运行状态、企业环境和结构化文档结合起来，为操作员提供单一的空间体验。

一个常见的实际应用例子是故障诊断。

• 在传统的HMI中，操作员通常会看到故障代码和文本消息，然后查阅单独的手册来查找相关章节。
• 在更集成的HMI中，操作员可以点击3D视图中受影响的组件，查看器可以显示当前信号状态、来自 MES 的活动生产订单、相关的维护历史记录以及数字手册的相应部分——所有这些都通过 GLB 文件或场景图中存在的相同组件 ID 进行引用。

这种方法的价值远远超出了故障处理的范围。

将机器信息系统置于操作员体验核心的项目中，通常会持续出现以下四项运营优势：

更快的故障识别和响应：工业机器通常包含数百个传感器、驱动器和组件，每个组件在扁平命名空间中都有自己的标识符。诸如“传感器 BG2-S147 故障”之类的符号消息需要操作员将抽象标识符转换为物理位置。3D视图中显示的相同故障——实际机器几何体上突出显示受影响的传感器——消除了平移步骤。对于复杂的机器或不每天使用该系统的人员来说，这相当于五分钟的搜索时间和立即响应之间的区别。

统一操作环境：当 MES 数据叠加到3D场景上时，操作员不仅可以看到机器是否正在运行，还可以看到机器相对于当前订单、目标周期时间和最近 KPI 的性能表现。维护和质量信息显示在它们所指的组件上，而不是在单独的后台中。这就是机器信息系统基于空间上下文而不是表格和列表所能实现的，这也是为什么对于这种架构所产生的效果而言，“机器信息系统”这个术语比“3D HMI”更准确。

减少对专业知识的依赖：并非所有操作人员都像制造商那样对每个部件都有深入的了解。通过同一个3D视图访问文档、传感器状态和操作说明，经验不足的员工可以执行以前需要高级技术人员或服务电话才能完成的一线诊断和常规干预。在技​​术熟练的技工数量有限的行业中，这一点越来越重要，它使交接班、休假安排和周末运营更加稳健。远程支持反过来也能获得同样的益处：制造商的服务技术人员可以看到与现场操作员相同的3D环境，并且可以通过视频通话或共享会话级别/会话次数提供精确的、具有空间定位的指示。

持续运营知识获取：这是机器信息系统经常被忽视的一个作用。机器附带的文档集必然是不完整的——它无法预料到每一种故障组合、每一种被证明有效的解决方法，以及维护人员在多年使用过程中发现的每一个原因和解决方法。当操作员和技术人员能够将观察结果直接附加到3D场景中受影响的组件上时——故障描述、诊断原因、应用的解决方案、更换的部件、照片或简短说明——该系统就成为了该特定装置实际运行情况的长期记录。在机器的整个使用寿命期间，这将积累成一个结构化的故障和解决历史记录，并以与制造商原始文档相同的组件 ID 为锚点。其结果是为资产的知识驱动操作奠定了基础：交接班时可以参考真实的先前事件，经验不足的员工可以继承前任的诊断经验，并且（如第 2 部分所述）基于人工智能的诊断工具可以将答案建立在该装置的实际历史记录之上，而不仅仅是建立在制造商手册之上。

实现此类集成所需的技术组件目前已经可用：WebSocket 流用于实时信号，REST 或 OPC 买量用于 MES 上下文，与组件标识符关联的结构化数字文档，以及渲染组合视图的3D查看器（Unity原生、WebGL 或基于浏览器的堆栈，例如 realvirtual.io Web 查看器，其公开演示位于 web.realvirtual.io/demo）。集成商剩下的工作主要是架构方面的，而不是技术方面的。

5.集成商的架构模式

构建机器信息系统的最佳实践

将3D场景视为几何和可识别真理的来源。组件 ID、运动学结构和元数据可以存储在场景文件中（例如，作为 GLB 中的扩展数据或Unity预制件元数据）。其他系统随后会引用这些 ID，而无需重新定义它们。这种方法允许在3D视图中单击一次，即可一致地解析为信号、MES 记录和手动部分。下面的屏幕截图显示了真实包装线上的这种模式： Unity编辑器是创作环境，机器制造商在其中导入 CAD，定义运动学和组件层次结构，配置传感器和驱动行为，并附加结构化元数据，该元数据将随每个游戏对象一起在机器的剩余生命周期内传递。

在右侧的检查器中，运行时元数据和运行时可交互组件是空间索引模式在实践中的实现方式：组件 ID 存在于 GameObject 中，而不是外部映射表中，因此导出到 GLB 时，几何体会携带标识符。虚拟调试在同一场景中进行——来自真实虚拟核心的驱动和传感器模型响应连接的PLC，在物理机器存在之前执行运动学和信号映射。场景验收通过后，将相同的创作内容导出为 GLB 并交付给运行时，无需单独的下游重新建模步骤。

为每个数据层使用轻量级、特定用途的适配器。用于信号的 WebSocket 适配器、用于 MES 的 REST 或 OPC 买量客户端、按组件 ID 公开手册和原理图的文档服务。每个适配器负责一个数据源。realvirtual.io 等工具包按照这些思路构建信号和场景端；同样的模式可以扩展到 MES 和文档。

对机器信息系统进行版本控制，使其与软件同步更新。如果文档以数字方式提供，则机械法规要求欧盟符合性声明和使用说明在机器的整个生命周期内（包括软件更新期间）保持可访问性。务实的答案比单纯的文档更广泛：整个机器信息系统3D场景、信号映射、组件元数据、结构化文档以及多年来积累的捕获的操作知识——本身就是一个版本化的工件，与特定的机器序列号和软件版本相关联。这里需要的特性正是软件开发在过去二十年中已经解决的特性：不可变的历史状态，可以精确地重建任何过去的交付；用于标记市场投放状态的签名自定义广告标签对接，以达到监管目的；用于机器变体和客户特定配置的分支；以及分布式克隆，可以在任何单一工具供应商的十年以上时间内存活——这通常是工业机械的实际运行寿命，而不是监管规定的最低寿命。Git应用于整个机器软件包的层面，而不仅仅是源代码，它与这些特性非常契合。Gitea（realvirtua.io 参考架构第 6 节中的归档层）等系统正在成为工业机器软件包的自然交付和归档格式，其在软件开发中发挥承重作用的版本控制模式直接转化为传统机械交付的限制。

通过结构化API公开文档集。对于人工操作员来说，能够根据组件 ID 和故障代码返回相关手册章节的文档服务非常有用。同样的结构化访问也支持第 2 部分讨论的用例，其中 AI 工具可以基于制造商的实际文档来输出结果，而不是仅仅依赖训练数据。

6.参考架构

到目前为止介绍的要素——四个数据层、机器信息系统概念和上述架构模式——组合成一个参考架构，集成商可以对其进行调整。下图显示了 realvirtua.iol 参考堆栈——创作环境、Gitea 归档、机器信息系统运行时和工厂连接——作为该模式的一个具体分层。创作和交付之间这种大致的分离可以通过不同的特定工具来实现。

• 在创作方面， Unity Editor从Unity Asset Manager获取 CAD 和3D素材资源，从供应商 AAS 源（西门子、费斯托、ABB）和 PDM 系统获取机器元数据，并针对 realvirtual.io Core 生成元数据、信号和文档映射。然后使用Unity对导入的机器 CAD 模型进行设置，将材质、运动学行为和运动约束应用于各个组件。这使得静态几何体转变为完全交互式且物理上逼真的3D机器模型，用户可以实时导航和操作。

出口包3D机器模型 (GLB)、AAS 数据、文档和已签署的符合性声明——以带标签的版本存档在 Gitea 存储库中，旨在作为机械法规 (EU) 2023/1230 要求的 10 年存档。

• 在交付方面，机器信息系统运行时——基于 Three.js、TypeScript、AGPL 许可且可自托管的 realvirtual.io WEB——从 Gitea 归档部署，并通过 rv Connect（实时信号）、InfluxDB（时间序列）和机器的 PLC 接口连接到运行中的工厂，向操作员呈现机器状态、文档、维护、备件管理和分析。
• realvirtual.io 的核心——共享的驱动器、传感器和运动学行为——存在于创作环境和运行时环境中：在创作和虚拟调试期间作为Unity组件，在运行时作为 Three.js 组件，因此驱动仿真的相同行为模型也驱动交付的机器信息系统。
• 现有的自动化系统——PLC、驱动器、传感器、机器人、MES——在堆栈的最底层保持不变。在其上方是信号层和 MES 层，大多数集成商已经在构建这些层了。除此之外，按组件 ID 和故障代码构建的文档服务，既满足了监管存档要求，又满足了操作员在机器旁快速获取权威参考资料的需求。

点击这里查看第 2 部分，其中我们讨论了如何在不改变底层架构的情况下将 MCP 和代理层集成到其中。