PLC 如何通过确定性安全逻辑监管智能体 AI

智能体 AI 可以提出操作建议，但不应被信任直接在工业设备上执行这些操作。在更安全的工业 5.0 架构中，PLC 仍然是确定性的安全监管者：在允许任何物理输出动作之前，它会根据硬编码的许可条件、联锁和故障安全逻辑来评估 AI 生成的指令。

智能体 AI 并未取代 PLC，它改变的是 PLC 必须防御的对象。

架构问题很简单：AI 系统生成的是概率性输出，而工业控制系统必须在设备边界处强制执行确定性行为。这种区别并非哲学层面的，而是吞吐量建议与压力管线上阀门行程之间的区别。

在 OLLA Lab 的内部数字孪生压力测试中，不受约束的类 AI 设定点注入在 30 次测试运行中有 25 次产生了模拟执行器超程故障，而在相同场景下，加入确定性钳位和看门狗逻辑后，这些违规行为降为零。方法论：样本量 = 30 次针对阀门和传送带场景的模拟运行；任务定义 = 向梯形图控制的设备注入不稳定的设定点变化和通信丢失；基准比较 = 无钳位/看门狗逻辑对比带有边界许可和超时处理的梯形图逻辑；时间窗口 = 2026 年第一季度。这支持了确定性否决逻辑在仿真中的价值，但它本身并不能确立现场可靠性、SIL 性能或通用的故障降低率。

IEC 61508 及相关的功能安全实践使边界更加清晰：安全关键型动作需要确定性、可追溯性和经过验证的行为。矩阵乘法很有用，但它们不是安全案例。

智能体 AI 以概率方式运行，而 PLC 逻辑以确定性方式执行。

一个操作定义有助于理解这一点。在本文中，智能体 AI 指的是一种软件系统，它能够根据不断变化的输入和优化目标，在固定的顺序脚本之外生成动作、设定点或路径决策。在自动化术语中，这通常意味着以下内容：

• 动态设定点生成，
• 自适应顺序建议，
• 自主路线或路径选择，
• 基于异常的指令建议，
• 跨多个资产的监督优化。

相比之下，确定性 PLC 逻辑指的是基于扫描的控制，即相同的验证输入、逻辑状态和定时条件在定义的执行模型内产生相同的输出行为。

这种区别至关重要，因为工业设备并不关心不安全的指令是来自人类操作员、历史记录脚本还是 AI 智能体。错误的指令依然是错误的。

设备边界处的确定性与概率性控制

PLC 存在于软件意图转化为物理运动的节点上。

现代 AI 服务可能在边缘节点、云服务或本地工业 PC 上异步运行。其响应时间会随网络延迟、模型复杂度、队列深度或上游数据质量而变化。而 PLC 扫描周期在设计上是受限且重复的。这就是为什么 PLC 仍然是强制执行联锁、许可条件、跳闸条件和输出否决的正确位置。

实际对比非常直观：

| 控制属性 | 智能体 AI | PLC / 安全 PLC | |---|---|---| | 执行模型 | 概率性或启发式 | 确定性扫描执行 | | 定时行为 | 可变，异步 | 受限、循环、硬实时或近实时（取决于平台） | | 主要优势 | 优化、适应、模式推理 | 可靠执行、联锁、顺序控制、故障安全响应 | | 安全认证角色 | 不适合作为直接的 IEC 61508 安全功能执行器 | 在设计得当时可实现于经认证的安全架构内 | | 故障模式关注点 | 无界输出、陈旧上下文、幻觉建议、通信丢失 | 逻辑缺陷、集成错误、配置错误，但行为可测试且可追溯 |

为什么 AI 不能简单地“成为控制器”

AI 可以辅助控制，但不应被假定能胜任安全控制器的角色。

IEC 61508 并没有在广义上禁止软件智能，但功能安全要求对系统能力、可预测行为、生命周期控制和经过验证的安全功能提供证据。当前的 AI 模型并非作为确定性安全求解器而设计。在许多实际条件下，它们的输出是上下文相关的且不可重复的。这使得它们不适合直接进行安全驱动。

一个有用的对比是优化与否决权。AI 可以建议，但 PLC 必须决定该建议在物理和程序上是否可接受。

PLC 通过强制每一条外部指令在到达物理输出之前经过确定性许可逻辑，从而否决 AI 指令。

这是核心架构。AI 不会直接写入输出卡，它最多只能写入受监管的指令寄存器、请求的设定点或非安全数据块。随后，PLC 会根据以下硬编码条件评估该请求：

• 急停链健康，
• 模式选择有效，
• 维护锁定未激活，
• 限位开关未触发，
• 过程变量在安全范围内，
• 通信心跳存在，
• 顺序状态有效，
• 无激活的跳闸或锁存故障。

如果任何必要条件失败，PLC 就会阻止、钳位、替换或丢弃该指令。

这就是否决架构。它不如自主控制那样引人注目，但这正是它往往能在调试中存活下来的原因。

作为安全监管者的 PLC

PLC 安全监管者是一个确定性逻辑层，它在允许任何机器状态转换或模拟输出变化之前，根据明确的操作和安全约束来评估 AI 发起的请求。

这个定义是有意缩小的。它描述了可观察的工程行为：

• AI 发出请求，
• PLC 检查许可条件，
• PLC 拒绝、限制或通过该请求，
• 最终执行器行为仍由确定性逻辑控制。

在混合 AI/OT 架构中，PLC 应将 AI 视为不可信但可能有用上游来源。这是常规的控制设计。

实际的否决路径

一个典型的受监管路径如下：

• 来源新鲜度，
• 指令范围，
• 模式许可条件，
• 顺序合法性，
• 设备可用性，
• 安全约束。
• 拒绝指令，
• 将其钳位到安全范围，
• 对变化进行速率限制，
• 替换为后备值，
• 允许通过。

1. AI 生成请求指令或模拟设定点。
2. 该请求被写入非安全 PLC 标签或通过接口层交换。
3. PLC 验证：
4. PLC 执行以下操作之一：
5. 最终输出到执行器的信号仍由 PLC 逻辑产生，而非直接由 AI 产生。

这也是调试纪律发挥作用的地方。不安全的架构通常并不戏剧性，它通常只是一个未检查的写入路径和一个缺失的超时设置。

监管 AI 需要能够检测越界请求、陈旧通信、无效顺序转换和物理破坏性指令速率的梯形图模式。

具体实现因平台而异，但控制模式是稳定的。

1. 用于安全操作窗口的钳位逻辑

钳位逻辑将 AI 生成的模拟值限制在物理上安全且操作上有效的范围内。

这是针对请求速度、阀门位置、压力目标、温度设定点或加药速率的第一道防线。PLC 将请求值与工程限制进行比较，并用有界的替代值替换任何超出范围的值。

典型实现使用：

• `LES` / 小于比较，
• `GRT` / 大于比较，
• 使用移动指令替换最小值/最大值，
• 模式相关限制，
• 用于操作员可见性的报警位。

典型用例：

• 在启动期间将阀门指令限制在 20–80%，
• 防止泵速指令低于最低冷却流量，
• 将温度设定点限制在跳闸阈值以下，
• 在产品传输期间限制传送带速度变化。

钳位逻辑回答了一个基本问题：即使请求在语法上有效，它在物理上是否可接受？

2. 防止机械冲击的速率变化滤波器

速率变化过滤限制了指令值在扫描间隔之间变化的速度。

AI 优化器可能会在不考虑执行器磨损、水锤、皮带打滑或热滞后的情况下，从一个最优值跳转到另一个最优值。设备通常在第二个或第三个周期后就会出现问题。

PLC 可以强制执行：

• 每次扫描的最大增量，
• 每秒的最大增量，
• 加速和减速曲线，
• 死区处理，
• 启动与稳态操作的单独限制。

这在以下情况中尤为重要：

• 变频器（VFD）速度控制，
• 阀门定位，
• 压力和流量回路，
• 机器人或伺服相关运动请求，
• 具有惯性或机械间隙的工艺。

3. 用于心跳监管的看门狗定时器

看门狗定时器验证 AI 源是否存活、当前且在预期间隔内更新。

一种常见的实现方式是使用来自 AI 层的心跳位或递增值。如果信号未能在定义的超时时间内改变，PLC 会设置通信故障并将过程强制进入已知状态。根据危险分析，该状态可以是保持最后值、受控减速、转为手动或完全停止。

典型的梯形图元素包括：

• `TON` 定时器，
• 心跳比较逻辑，
• 故障锁存，
• 复位条件，
• 模式转换逻辑。

看门狗不仅仅是一个通信细节，它是一种声明：陈旧的智能不是智能。

4. 顺序合法性检查

顺序合法性逻辑防止 AI 跳过必要的工艺状态。

这在批处理系统、泵组、HVAC 转换、CIP 顺序和公用设施撬块中非常重要，其中顺序是安全和设备保护的一部分。AI 可能会推断出后续状态是理想的，但工厂可能仍需要先进行吹扫、验证、许可或停留条件。

典型的检查包括：

• 当前步骤验证，
• 打开证明或运行证明反馈，
• 最短停留时间，
• 启动前许可条件，
• 仅在确认后转换的逻辑。

5. 故障锁存与确定性恢复

故障锁存确保不安全或无效的 AI 请求不能被下一个周期隐式清除。

如果 AI 请求非法状态转换或在关键操作期间丢失心跳，PLC 不应在通信恢复时简单地清除问题。许多系统需要锁存故障、操作员确认和定义的重启路径。

这不是官僚主义的过度，这是防止间歇性故障变成反复出现的谜团的方法。

实用的 AI 监管梯形图结合了心跳监控、故障锁存、许可检查和输出门控。

以下是一个简化的梯形图示例，仅供说明。语法会因 PLC 系列而异。

[语言：梯形图]

// AI 心跳超时 |---[ AI_Heartbeat_Changed ]-------------------------(RES T4:0)---| |---[/AI_Heartbeat_Changed ]-------------------------(TON T4:0)---| | PRE 500ms |

// 超时时锁存 AI 通信故障 |---[ T4:0/DN ]--------------------------------------(L AI_Fault)--|

// 仅在操作员复位且心跳恢复正常时清除故障 |---[ Reset_PB ]---[ AI_Healthy ]--------------------(U AI_Fault)--|

// 阀门指令的钳位许可 |---[ AI_Request_GT_Max ]----------------------------(OTE Clamp_Hi)-| |---[ AI_Request_LT_Min ]----------------------------(OTE Clamp_Lo)-|

// 仅在无 AI 故障且所有安全许可条件为真时才允许最终输出 |---[ AI_Command_Enable ]---[/AI_Fault]---[ Safe_Permissive ]---[ No_Trip ]---(OTE Valve_Open)--|

工程重点不在于助记符的选择，而在于控制结构：

• 验证来源新鲜度，
• 确定性地锁存故障，
• 要求明确的恢复条件，
• 通过硬许可条件门控每一个最终输出。

IEC 61508 仍然重要，因为添加 AI 并不能消除对可证明的功能安全的需求；它通常增加了对架构隔离和验证纪律的需求。

IEC 61508 是电气、电子和可编程电子安全相关系统的基础功能安全标准。在实际操作中，它构建了如何在整个生命周期内指定、设计、验证和维护安全功能。它也是许多行业特定标准的基础。

对于本文而言，相关点更窄：安全功能的实现方式必须是可分析、可测试且有证据支持的。AI 生成的输出并不必然被排除在更广泛的系统之外，但它们不能替代确定性安全逻辑。

这在实际控制架构中意味着什么

在一个可信的架构中：

• AI 可以建议设定点。
• BPCS 或 PLC 可以评估并实施其有界版本。
• 安全功能保持独立且确定。
• 跳闸、停机和保护动作不依赖于 AI 推理。

在使用安全 PLC 的地方，隔离必须更加彻底。安全逻辑不是进行概率性即兴发挥的地方。

这并不意味着什么

这并不意味着 AI 在工业自动化中没有用处。

AI 在以下方面很有价值：

• 预测性维护，
• 能源优化，
• 软测量，
• 异常检测，
• 生产调度，
• 自适应调整建议，
• 操作员决策支持。

正确的设计模式是确定性控制执行之上的概率性咨询或监督智能。这是工业 5.0 的实际答案。

“仿真就绪”意味着工程师可以在控制逻辑到达实际过程之前，证明、观察、诊断并强化其针对现实过程行为的控制逻辑。

这个定义是操作性的，而非愿景性的。一名“仿真就绪”的工程师至少可以做六件事：

• 定义控制系统在正常和异常条件下应执行的操作，
• 在执行期间观察 I/O 和内部标签行为，
• 注入现实的故障和异常请求，
• 对比梯形图状态与模拟设备状态，
• 在故障后修改逻辑，
• 记录为什么修改后的逻辑更安全或更稳健。

这就是语法与可部署性之间的区别。

一个能画梯形图的人不一定准备好监管受 AI 影响的设备。一个能够针对现实模型测试看门狗、钳位逻辑、顺序合法性和故障恢复的人则要接近得多。

验证 AI 监管逻辑需要一个风险受控的环境，在该环境中可以注入不稳定的指令，而不会危及硬件、生产或人员。

这就是 OLLA Lab 变得具有操作价值的地方。

OLLA Lab 是一个基于 Web 的梯形图逻辑和数字孪生仿真环境，用户可以在其中构建梯形图程序、在仿真中运行它们、检查变量和 I/O，并根据现实的工业场景验证行为。在这种背景下，其价值是有界且清晰的：它为工程师提供了一个在将类似模式应用于实际系统之前，演练高风险调试逻辑的地方。

OLLA Lab 如何支持 AI 监管练习

相关的平台功能包括：

• 用于构建监管逻辑的基于浏览器的梯形图编辑器，
• 用于安全运行和停止逻辑的仿真模式，
• 用于监控和强制标签的变量面板，
• 用于有界设定点练习的模拟和 PID 工具，
• 用于观察设备行为的 3D / WebXR 仿真，
• 带有联锁、危险和调试说明的基于场景的实验室，
• GeniAI（AI 实验室向导），用于在构建或调试逻辑时提供指导支持。

产品声明应保持谦逊：OLLA Lab 不认证安全功能，不授予现场能力，也不取代实际项目上的 FAT/SAT。它确实让工程师能够演练那种真实工厂无法承担将其视为即兴发挥的逻辑验证。

用于 AI 握手验证的实用 OLLA Lab 工作流程

一个有用的实验室练习是将 AI 模拟为外部指令源，然后测试 PLC 的监管响应。

构建并测试以下内容：

• 示例：`AI_Valve_SP_Request`
• 将其视为不可信输入。

• 最小值/最大值钳位，
• 速率变化限制器，
• 看门狗超时，
• 顺序许可条件，
• 故障锁存。

• 阀门位置，
• 电机运行状态，
• 罐液位响应，
• 传送带运动，
• 风扇速度。

• 突然的 0% 到 100% 跳变，
• 不可能的负值，
• 陈旧心跳，
• 跳闸条件下的指令，
• 无效顺序步骤期间的指令。

• PLC 是否拒绝了请求？
• 故障是否锁存？
• 设备是否保持在安全行为范围内？
• 过程是否移动到了预期的后备状态？

• 调整超时值，
• 收紧许可条件，
• 增加报警可见性，
• 完善重启条件。

1. 创建受监管的指令标签
2. 添加确定性验证逻辑
3. 将输出映射到模拟设备
4. 通过变量面板注入错误案例
5. 观察梯形图状态和模拟设备状态
6. 修改并重新测试

这就是数字孪生验证的实际含义：不是“模型看起来很令人印象深刻”，而是“逻辑在没有产生错误动作的情况下经受住了错误输入”。

工程师应该记录紧凑的证据主体，而不是截图库。

如果目标是证明在 AI-PLC 监管方面的能力，请使用此结构：

1. 系统描述 定义机器或过程、AI 请求的变量、PLC 控制的输出以及操作模式。
2. “正确”的操作定义 用可观察的术语说明正确行为的含义：允许的设定点范围、超时响应、有效的顺序转换、报警行为和安全后备状态。
3. 梯形图逻辑和模拟设备状态 展示相关的梯形图、标签以及仿真中相应的设备响应。
4. 注入的故障案例 记录确切的异常输入：陈旧心跳、不可能的设定点、无效转换或过度的速率变化。
5. 所做的修改 解释更改了哪些逻辑：钳位阈值、看门狗定时、故障锁存、联锁条件或模式处理。
6. 经验教训 说明故障揭示了什么，以及修改后的逻辑现在防止了什么。

这种格式很有用，因为它使工程判断变得可见。任何人都可以声称他们与 AI 和 PLC 合作过。当故障案例明确时，证据才开始显现。

最常见的集成错误是架构上的，而非算法上的。

将 AI 输出视为受信任的控制权限

这是主要错误。如果 AI 在没有确定性验证的情况下直接写入实时指令路径，那么架构本身就是脆弱的。

混淆优化与安全

AI 可能会提高吞吐量或能源利用率。但这并不意味着它适合用于保护动作、跳闸逻辑或联锁旁路决策。

忽略超时和陈旧数据处理

一个断开连接但仍保留最后值的 AI 服务可能比一个嘈杂的服务更危险。静默也是一种状态。

忽略顺序合法性

许多故障的发生不是因为请求的值在数值上是错误的，而是因为它在错误的工艺步骤到达。

仅测试标称案例

如果实验室仅证明系统在一切正常时表现良好，那么它还没有证明太多。调试是审计假设的地方。

PLC 通过在概率性建议和物理设备之间强制执行确定性否决逻辑，充当智能体 AI 的安全监管者。

这是核心设计规则。AI 可以优化、建议和适应。PLC 必须始终验证、约束，并在必要时拒绝。在工业 5.0 中，控制问题不是 AI 或 PLC 的问题，而是如何将两者置于它们确实能够凭证据执行的角色中。

OLLA Lab 作为有界的验证环境符合该工作流程。它允许工程师构建梯形图逻辑、模拟异常的类 AI 输入、观察设备响应，并在类似模式暴露于现场调试风险之前强化监管逻辑。这是仿真的一种可信用途：在金属移动之前证明行为。

- NIST AI 风险管理框架 (AI RMF 1.0) - IEC 61508 功能安全概述 - IEC 62443 工业网络安全标准概述 - 数字孪生赋能技术 (IEEE Access) - 工业 4.0 的工业 AI (Manufacturing Letters)