如何在工业 5.0 中编程实现安全的人机共存

要在工业 5.0 中编程实现安全的人机共存，工程师必须验证动态安全区域、确定性互锁以及速度与分离监控逻辑。OLLA Lab 提供了一个受限的数字孪生环境，可以在物理调试开始前对梯形图逻辑、I/O 因果关系和故障响应进行测试。

工业 5.0 并非仅仅是一个让工厂变得更具人文关怀的口号。它是对“全自动化始终是最佳控制哲学”这一狭隘假设的修正。欧盟委员会的框架表述非常明确：未来的工业必须以人为本、具有韧性且可持续，而不仅仅是最大强度的自动化（欧盟委员会，2021 年）。

其实际原因很简单。“黑灯工厂”系统在处理重复性任务时表现出色，但当遇到未预先建模的偏差时，其处理能力较差。生产线可以被完美优化，直到现实情况发生——而现实往往不期而至。

在最近的 OLLA Lab WebXR 压力测试中，工程师在模拟动态区域入侵时发现，若未经人工审查修正，AI 生成的草稿安全梯形图在 32 次任务运行中有 7 次未能实现要求的硬停止行为，失败率高达 21.9%。方法论：n=32 次模拟协作单元互锁任务，基准比较器 = 人工审查的确定性梯形图集，时间窗口 = 2026 年 1 月至 3 月。 这仅支持一个狭隘的观点：草稿生成并不等同于可部署的安全逻辑证明。它并不支持关于所有 AI 辅助 PLC 工作的广泛主张。

黑灯工厂正在转型，因为缺乏自适应人类判断的优化是脆弱的。工业 4.0 强调互联性、自动化和数据驱动的运营。工业 5.0 保留了这些成果，但将人类操作员、技术人员和工程师重新定位为系统韧性的主动组成部分，而非边缘化的剩余劳动力。

欧盟委员会的工业 5.0 模型是对这一转变最清晰的正式表述。它并不拒绝自动化，而是拒绝将自动化视为唯一的最高工业目标（欧盟委员会，2021 年）。

这在控制工程中至关重要，因为异常状态正是哲学转化为梯形图逻辑的地方。供应中断、传感器漂移、产品变形、维护覆盖和部分人工干预并不会因为生产线高度自动化而消失。它们恰恰是检验控制策略是为现实设计还是为宣传手册设计的试金石。

工业 4.0 与工业 5.0 控制哲学对比

| 维度 | 工业 4.0 重点 | 工业 5.0 重点 | |---|---|---| | 主要目标 | 效率、互联性、吞吐量 | 韧性、以人为本的运营、可持续性能 | | 人类角色 | 自动化资产的监督者 | 主动异常处理者、协作者、决策者 | | PLC/控制系统角色 | 确定性自动化骨干 | 确定性骨干 + 安全人机共存 | | 安全方法 | 防护隔离、固定自动化区域 | 动态协作、在合理范围内共享空间以降低风险 | | 故障姿态 | 最小化中断 | 从中断和偏差中安全恢复 |

需要纠正的一个误区是：工业 5.0 意味着“减少自动化”。它通常意味着更合理的认知分配。机器人负责重复，人类负责解释。优秀的系统会刻意同时利用这两者。

安全的机器人并不孤立存在，安全的应用程序才存在。这种区别不仅仅是语义上的修饰，它是评估、验证和调试协作系统的核心。

对于协作机器人应用，标准讨论通常集中在：

• ISO 10218：工业机器人安全要求
• ISO/TS 15066：协作机器人操作指南
• IEC 61508：电气、电子和可编程电子安全相关系统的功能安全

ISO/TS 15066 并没有赋予机器人某种神秘的“安全”地位。它定义了协作操作概念、风险降低预期以及应用层面的考量，如力、接触、速度、分离和监控状态。与此同时，IEC 61508 为安全相关的控制行为和生命周期管理提供了更广泛的功能安全框架。

四种公认的协作操作模式

1. 安全额定监控停止 (SRMS) 当人员进入协作空间时，机器人停止运动，仅在受控条件下恢复运动。
2. 手动引导 (HG) 人类通过使能设备和受限的操作逻辑，物理引导机器人的运动。
3. 速度与分离监控 (SSM) 机器人的速度或运动状态根据与人员的测量距离动态变化。
4. 功率与力限制 (PFL) 机器人和工具的设计确保接触力保持在定义应用的允许范围内。

SSM 的工程负担最重，因为它依赖于动态传感、确定性响应和经过验证的区域逻辑。“动态”并不意味着模糊，它意味着逻辑根据定义的时序和安全约束，基于测量的分离距离改变状态。

这些标准在 PLC 术语中意味着什么

对于控制工程师而言，标准转化为可观察的行为：

• 扫描仪或安全传感器状态必须由故障安全输入表示
• 许可信号（Permissives）必须在信号丢失或状态无效时坍缩至安全状态
• 速度降低和停止指令必须是确定性的
• 复位行为必须是审慎的、有界的，且在风险评估要求时不得自动执行
• 异常条件必须经过测试，而非假设其不存在

这就是许多团队发现语法与可部署性之间差距的地方。

VR 仿真对于 SSM 非常有用，因为对区域入侵进行物理测试既昂贵、缓慢，有时还存在不必要的风险。如果工程师第一次观察扫描仪逻辑在人员入侵下的表现是在现场调试期间，那么该过程在风险曲线上已经太晚了。

实际上，SSM 验证要求工程师核实：

• 操作员位置变化下的区域状态转换
• 外部警告区域被入侵时的减速指令
• 内部保护区域被入侵时的停止指令
• 区域清除后的复位和重启条件
• 传感器掉线、状态陈旧或无效转换期间的故障安全行为

OLLA Lab 在此作为受限的排练环境非常有用。工程师可以在浏览器中构建梯形图逻辑，运行仿真，检查变量和 I/O 状态，并观察 3D 或 WebXR 工作单元在虚拟操作员进入定义区域时的响应。重点不在于视觉新颖性，而在于因果关系。

“仿真就绪”在操作层面意味着什么

“仿真就绪”应由行为而非信心来定义。当工程师能够做到以下几点时，即为仿真就绪：

• 在部署前证明预期的控制行为
• 在正常和异常状态下观察 I/O 因果关系
• 诊断许可信号为何失败或保持锁定
• 注入真实故障并验证产生的安全状态
• 在故障案例后修改逻辑并重新测试序列
• 在不进行空谈的情况下，对比梯形图状态与仿真设备状态

这是调试的定义，而不是简历上的形容词。

为什么 WebXR 和数字孪生在此至关重要

数字孪生在操作上是有用的，前提是虚拟设备状态足够接近，以便在现场工作前测试控制假设、序列逻辑和故障响应。它不能替代最终调试，也不应被描述为替代品。但它对于及早发现分类错误非常有用：错误的许可顺序、错误的复位路径、错误的默认状态、错误的定时预期。

让虚拟协作单元崩溃比让物理单元崩溃成本更低。这不是什么深刻的见解，但它仍然未被充分应用。

动态安全区域逻辑应该是确定性的、故障安全的且易于审计的。该结构通常将外部区域减速、内部区域停止行为和手动复位条件分开，而不是将它们混合在一个巧妙的梯级中。在调试过程中，过于“巧妙”的设计往往会带来麻烦。

为什么常闭逻辑在故障安全状态中很常见

常闭表示法常用于安全相关状态，因为信号丢失应趋向于安全结果。如果扫描仪发生故障、电缆完整性受损或安全输入丢失，许可信号应断开，而不是保持虚假的健康状态。

简单来说：

• 存在健康输入 → 如果满足所有其他条件，许可信号可保持为真
• 输入丢失或故障 → 许可信号坍缩
• 许可信号坍缩 → 机器人根据安全设计过渡到降低风险或停止状态

具体实现取决于安全架构、控制器和风险评估。但指导原则是稳定的：不确定的状态不应伪装成安全状态。

工程师应能解释的最小因果关系

验证此逻辑的工程师应能回答：

• 是什么导致减速而不是完全停止？
• 确切的什么状态会导致硬停止？
• 扫描仪故障与有效区域入侵的区别是什么？
• 运动可以自动恢复，还是需要确认？
• 在接受复位之前必须满足哪些条件？
• 如果区域信号变得矛盾或陈旧，安全状态是什么？

如果这些答案不明确，逻辑就没有准备好。它可能仍然可以运行，但这与“准备好”是两码事。

人机回环验证之所以重要，是因为操作员并不总是按照“理想路径”行事。他们进入得太早、复位得太快、绕过序列预期，偶尔还会制造出设计审查中遗漏的特定条件。

这就是 OLLA Lab 发挥操作价值的地方。在协作包装或物料搬运场景中，工程师可以：

• 构建区域许可和机器人状态指令的梯形图逻辑
• 运行仿真并实时观察输出
• 使用变量面板强制改变扫描仪状态、故障和确认
• 对比梯形图状态与 3D 或 VR 设备响应
• 在注入异常条件后修改逻辑

该产品在此处的价值是有限且可信的。它为高风险任务提供了反复练习的机会，这些任务在实际设备上很难排练，特别是对于初级工程师而言。它不能证明能力、取代现场监督，也不能消除对正式安全验证的需求。

模拟协作单元内的实用故障注入工作流

一个有用的验证序列如下：

1. 从健康的扫描仪状态和全速机器人许可开始。
2. 入侵外部区域并验证是否仅过渡到减速。
3. 入侵内部区域并验证停止指令和许可信号丢失。
4. 清除区域但保持复位未确认；如果设计禁止，确认没有自动重启。
5. 在区域清除时注入扫描仪故障；验证系统保持在安全禁止状态。
6. 在无效条件下尝试复位；确认复位被拒绝。
7. 如果仍存在任何意外重启或陈旧许可，修正梯级结构。

该序列比十张完成的梯级截图更具教育意义。工程证据应展示故障下的思考，而不仅仅是理想条件下的语法。

有用的仿真记录是一份紧凑的工程证据，而不是截图库。文档应显示测试内容、为何被认为是正确的、什么失败了以及逻辑是如何改变的。

使用此结构：

1. 系统描述 定义单元、机器或过程段。识别受控资产、安全输入、操作员交互点和预期的操作模式。
2. “正确”的操作定义 以可观察的术语陈述预期行为。例如：“外部区域入侵强制在模拟状态转换内减速；内部区域入侵断开安全许可并发出停止指令；重启需要在区域清除后进行手动复位。”
3. 梯形图逻辑和模拟设备状态 展示相关的梯级和相应的数字孪生状态。显示标签名称、许可信号、输出和视觉机器响应。
4. 注入的故障案例 描述引入的异常条件：扫描仪掉线、区域输入卡死、过早复位、矛盾状态、延迟确认或操作员再次进入。
5. 所做的修订 记录逻辑的确切更改。例如：在复位许可前增加了故障主导地位，将外部区域速度逻辑与内部区域停止逻辑分开，或移除了意外的自动复位路径。
6. 经验教训 陈述测试揭示的关于序列设计、故障安全假设、复位行为或操作员交互的内容。

该格式对于学习、审查和招聘对话非常有用，因为它展示了工程判断力。

最常见的故障模式不仅仅是“代码写得不好”，而是状态设计不佳。逻辑可能编译、仿真甚至看起来井然有序，但在处理边缘情况时却不正确。

典型的故障模式包括：

• 复位路径主导错误，即复位绕过了仍然无效的许可信号
• 故障屏蔽，即扫描仪故障和有效的清除状态被处理得过于相似
• 区域层级不清，在警告、减速和停止区域之间界限模糊
• 自动重启假设，从未被应用风险评估所证明
• 陈旧状态保留，即物理条件改变后输出仍保持锁定
• 标签语义不清，导致审查困难并掩盖了因果关系
• 将标准控制逻辑与安全意图混合，且缺乏清晰的架构边界

纠正模式同样一致：

• 首先定义安全状态
• 其次定义所有有效转换
• 第三定义故障主导地位
• 在宣布序列完成前测试异常条件

这种顺序可以节省时间并降低调试风险。

AI 辅助最适合用于草稿生成、解释和审查支持，而不是最终的安全判断。它可以加速梯级脚手架、标签建议和教学指导。它不能独自承担确定性验证的重任。

在 OLLA Lab 中，GeniAI 可以通过解释梯形图元素、建议逻辑结构并帮助学习者完成场景，从而降低入门门槛。这很有用，特别是对于那些还不知道自己犯了什么错误的早期工程师。但最终验收测试仍然是人工主导且基于证据的。

一个安全的框架是：

• AI 可以提议
• 仿真可以暴露
• 工程师必须决策

这是协作安全工作的适当层级。

工业 5.0 将控制工程师的角色从序列编写者扩展为共存设计师。工作不再仅仅是自动化运动，而是定义何时允许运动、何时必须降级、何时必须停止，以及人类如何在不产生隐藏状态危险的情况下安全地重新进入过程。

这种转变改变了技能的定义。了解指令语法仍然很重要，但语法只是入场券。更强的信号是工程师是否能够验证故障下的行为、解释许可因果关系，并在现实的异常事件后修改逻辑。

这就是仿真至关重要的原因。它为工程师提供了一个积累故障经验的地方，而无需以损坏硬件或不安全的调试工时为代价。

- IEC 61131-3: 可编程控制器 — 第 3 部分：编程语言 - IEC 61508 功能安全标准系列 - NIST AI 风险管理框架 (AI RMF 1.0) - 欧盟工业 5.0 政策背景 - 数字孪生概述 (NIST)