如何在安全 PLC 中编程确定性否决逻辑以覆盖 AI 幻觉

为了覆盖工业自动化中的 AI 幻觉，工程师必须将 AI 置于确定性 PLC 否决逻辑之后。在任何执行动作发生前，PLC 应根据固定限值、状态许可条件和硬连线安全功能来验证 AI 请求的指令。这种分层防御将概率性优化与确定性执行分离开来。

AI 并不会因为听起来自信就变得安全。在工业控制中，信心不是控制变量。

工程冲突显而易见：大语言模型（LLM）和代理式 AI 系统是概率性的且非确定性的，而 PLC 则在可重复的扫描周期内执行具有边界行为的逻辑。这种差异并非哲学问题，而是架构问题，在涉及安全的上下文中，它是决定性的。

在最近的一项内部测试中，通过 OLLA Lab 的数字孪生验证工作流运行了 500 组模拟的 AI 生成设定点异常，PLC 侧的变化率钳制器加上明确的状态许可条件，在虚拟阀门和电机模型执行动作之前，拦截了 100% 的灾难性越界指令。方法论：在受限的速度、压力和阀门位置任务中注入 n=500 个异常案例；基准比较器 = 将 AI 请求的指令直接透传至模拟执行器标签；时间窗口 = Ampergon Vallis 内部实验室于 2026 年第一季度进行的运行测试。这支持了在仿真中进行确定性验证的价值。它不构成 IEC 61508 认证、SIL 证据，也不代表对所有工厂架构的声明。

实际的答案不是禁止 AI，而是拒绝赋予 AI 直接执行权限，并要求 PLC 始终保持确定性否决权。

AI 幻觉需要确定性否决逻辑，因为 AI 输出无法像 PLC 执行那样保证是有界的、可重复的或与扫描同步的。

在控制系统中，即使不安全指令是由统计学上令人印象深刻的模型生成的，它依然是不安全的。阀门并不关心 Token 的概率看起来多么具有说服力。

IEC 61508 和 ISO 13849 是围绕可预测行为、定义的故障处理和已知的安全状态构建的。与安全相关的控制功能必须以可分析、可界定和可验证的方式失效。当前的 LLM 类系统无法达到这一标准，因为它们的失效模式无法像确定性安全逻辑所要求的那样进行详尽的表征。这就是真正的问题所在：不是因为 AI 是新技术，而是因为 AI 没有被系统地界定到足以拥有最终执行路径的程度。

扫描周期与推理引擎

PLC 周期性地执行逻辑。它扫描输入、求解逻辑、更新输出，并以已知的间隔重复，通常在毫秒级，具体取决于平台、任务结构和负载。

AI 推理引擎的行为并非如此。其响应时间随模型大小、计算可用性、网络状况、编排开销和提示词复杂度而变化。即使平均延迟看起来可以接受，最坏情况下的时序和输出行为仍然是问题所在。

这产生了两种风险：

• 时序风险： AI 响应可能到达较晚、顺序错误或在无效的机器状态下到达。
• 内容风险： AI 响应可能请求执行不可能的、不安全的或脱离上下文的操作。

PLC 可以容忍延迟或拒绝的请求，但泵组无法容忍幻想。

标准实际上要求什么？

标准要求的是可预测的安全行为，而不是时髦的软件。

从宏观层面看：

• IEC 61508 涉及电气、电子和可编程电子安全相关系统的功能安全。
• ISO 13849 涉及控制系统的安全相关部分，特别是在机械环境中。
• 这两个框架都依赖于定义的架构、经过验证的行为以及对故障条件的已知响应。

这并不意味着工业堆栈中的每个非确定性软件组件在任何地方都被禁止。这意味着非确定性组件不应被视为最终的安全权威。这种区别很重要。感知和优化可以是概率性的；但否决和停机路径不能是。

确定性否决逻辑是一种硬编码的、受扫描周期约束的逻辑结构，它评估请求的指令，并在指令违反物理限值、过程约束或机器状态许可条件时对其进行拦截、钳制或覆盖。

这是一个操作定义，而非口号。确定性否决逻辑必须在逻辑中可观察，并能针对故障案例进行测试。

在实践中，确定性否决逻辑通常包括：

• 边界检查： 拒绝或钳制高于或低于允许限值的数值
• 变化率限制： 防止超出安全斜坡速率的突变
• 状态许可条件： 仅在有效的操作状态下允许指令
• 验证反馈检查： 在推进序列前要求现场设备确认
• 报警和跳闸处理： 在异常条件下强制执行安全响应
• 模式隔离： 防止在本地、维护或故障模式下执行远程或 AI 请求的操作

如果 AI 请求 150% 的驱动速度，而 PLC 将其钳制在配置的最大值并发出报警，那么否决逻辑就生效了。如果 AI 可以直接写入输出映像，那么架构就是错误的。

重要的操作定义

这些术语经常被随意使用，但不应如此。

• 确定性否决逻辑 (Deterministic veto)： PLC 逻辑，在每个扫描周期评估外部或 AI 生成的请求，并通过明确的边界、许可条件和故障规则拦截不安全的执行。
• 分层防御 (Layered defense)： AI/IT 功能（建议或优化）与 PLC/OT 功能（验证、执行和强制执行安全边界）之间的架构分离。
• 仿真就绪 (Simulation-Ready)： 在接触物理硬件之前，在虚拟环境中追踪 I/O 因果关系、观察异常行为、注入故障案例、诊断控制响应并修订逻辑的能力。

“仿真就绪”不是“会写梯形图语法”的缩写。它意味着工程师可以在压力下证明行为。语法很廉价，但可部署性并不廉价。

正确的分层防御架构赋予 AI 影响力，但不赋予其不受限制的权威。

这种分离应该是明确的：

第 1 层：用于感知或优化的 AI 代理

该层可以：

• 估算需求，
• 建议设定点，
• 推荐路由，
• 分类操作条件，
• 生成逻辑草稿或操作员指导。

该层应仅写入中间内存标签、消息结构或监控请求变量。它不应直接写入物理输出或安全内存。

第 2 层：PLC 中的确定性否决逻辑

该层根据固定的工程规则评估 AI 请求，例如：

• 最大/最小允许值，
• 有效的机器状态，
• 联锁，
• 许可条件，
• 序列步骤要求，
• 报警和跳闸条件，
• 变化率限制。

这是指令被接受、修改或拒绝的地方。

第 3 层：硬连线或认证的安全执行路径

该层包括（视情况而定）：

• 急停链，
• 安全继电器，
• 安全 PLC 任务，
• 接触器，
• STO 电路，
• 防护联锁，
• 独立的停机功能。

该层必须保持在 AI 内存映射之外，并处于任何软监控优化之外。硬连线安全的存在是因为软件偶尔会产生“主见”。

通过在 AI 请求的指令影响最终控制变量之前，强制其通过明确的验证逻辑来编程否决逻辑。

关键设计原则很简单：AI 请求是建议，而非输出。

实现设定点钳制

边界钳制可防止不可能或不安全的数值到达执行器指令。

使用如下结构：

结构化文本 / 梯形图逻辑翻译示例：

IF AI_Requested_Speed > Max_Allowable_Speed THEN Actual_Drive_Speed := Max_Allowable_Speed; Set Alarm_AI_Hallucination_Over_Speed; ELSIF AI_Requested_Speed < Min_Allowable_Speed THEN Actual_Drive_Speed := Min_Allowable_Speed; Set Alarm_AI_Hallucination_Under_Speed; ELSE Actual_Drive_Speed := AI_Requested_Speed; END_IF;

这是最小模式，而非最终架构。

生产级的实现通常会增加：

• 模式检查： 仅在自动模式下接受 AI 请求
• 状态许可条件： 仅在机器处于有效序列状态时接受请求
• ROC 钳制： 限制每个扫描周期或每秒的变化量
• 质量位： 拒绝陈旧、无效或不可信的上游数据
• 超时处理： 如果请求流中断，则恢复为回退值
• 报警锁存和操作员可见性： 使拒绝行为可见且可审查

更完整的控制路径通常如下所示：

1. 接收 `AI_Requested_Speed`
2. 验证源质量和新鲜度
3. 确认 `System_Auto = TRUE`
4. 确认所有许可条件为真
5. 钳制至工程最小值/最大值
6. 应用 ROC 限制
7. 写入 `Actual_Drive_Speed_Command`
8. 如果安全链断开，则跳闸或禁止

在传递 AI 指令前，梯形图逻辑应强制执行什么？

PLC 应强制执行谨慎的调试工程师在给设备通电前会询问的相同事项：

• 机器是否处于正确的模式？
• 序列是否处于正确的步骤？
• 所有许可条件是否满足？
• 反馈是否健康？
• 请求的数值是否在物理限值内？
• 请求的变更对于此过程是否合理？
• 是否存在任何活动的跳闸或安全条件？

最后一个问题往往比架构图更重要。

主急停链

主急停链必须位于 AI 权威边界之外，因为急停行为不能依赖于推理质量、网络时序或监控软件状态。

在实践中：

• 急停路径应根据应用要求进行硬连线或在认证的安全功能中处理。
• AI 系统既不应写入也不应抑制急停状态。
• 标准控制任务可以观察急停状态，但不应是其唯一的守护者。
• 当急停链断开时，任何 AI 请求的指令都必须无害地失效。

一个有用的规则是：如果网络故障、模型错误或解析器故障可以保持运动使能，那么设计就没有完成。

通过注入异常指令并证明 PLC 的响应在这些条件下保持有界、可观察且正确，来进行测试。

这是许多团队过早停止的地方。干净的额定运行几乎证明不了什么。

至少要测试以下案例：

• AI 请求超过最大允许值
• AI 请求低于最小允许值
• 超出安全斜坡速率的突变
• 在错误的机器状态下发出的指令
• 在许可条件为假时发出的指令
• 陈旧或冻结的上游数值
• 振荡或嘈杂的请求信号
• 在 AI 请求活动期间触发急停或跳闸

对于每个案例，验证：

• 最终执行器指令，
• 报警行为，
• 序列行为，
• 操作员可见性，
• 故障清除后的恢复行为。

一个钳制正确但使序列陷入混乱状态的否决逻辑，只是半个解决方案。

OLLA Lab 在这里非常有用，它是一个有界的验证环境，工程师可以在其中注入错误指令、观察设备响应，并在涉及任何实际硬件之前修订梯形图逻辑。

这种定位很重要。OLLA Lab 不是安全认证机构，也不能替代目标平台上的正式验证。它是一个在受控方式下排练高风险调试逻辑的实用环境。

在 OLLA Lab 中，工程师可以：

• 在基于 Web 的编辑器中构建梯形图逻辑，
• 在没有物理硬件的情况下运行仿真，
• 监控标签、I/O、模拟值和 PID 相关变量，
• 使用基于场景的设备模型，
• 比较梯形图状态与模拟机器行为，
• 在观察到故障案例后修订逻辑。

对于本文的用例，相关工作流很简单：

1. 创建一个中间标签，例如 `AI_Requested_Speed`
2. 通过钳制和许可逻辑路由该标签
3. 观察生成的 `Actual_Drive_Speed_Command`
4. 注入异常数值或不稳定模式
5. 确认模拟的电机、泵或阀门模型永远不会超过安全限值
6. 审查报警并修订逻辑

这就是 OLLA Lab 变得具有操作价值的地方。你不能为了看会发生什么，就在实际的过程撬装设备上负责任地测试 200% 阀门开启的幻觉指令。好奇心是有价值的，但损坏的硬件是昂贵的。

“仿真就绪”在实践中是什么样子的？

当工程师可以在虚拟环境中完成以下所有操作时，即为仿真就绪：

• 追踪从输入到输出的因果关系，
• 观察许可条件或联锁是否阻止了执行，
• 识别产生该响应的确切梯级或条件，
• 比较控制逻辑状态与模拟设备状态，
• 注入故障并解释由此产生的行为，
• 修订逻辑并重新测试，直到响应是有界的且可重复的。

这是调试准备工作的门槛。不是“会放置一个定时器指令”，而是“能证明机器为什么移动或为什么没有移动”。

正确的工件是一份紧凑的工程证据，而不是截图库。

使用此结构：

1. 系统描述 定义机器或过程单元、受控变量、操作模式以及相关的安全边界。
2. “正确”的操作定义 用可观察的术语说明可接受的行为意味着什么：允许范围、有效状态、预期的报警响应、跳闸行为和恢复行为。
3. 梯形图逻辑和模拟设备状态 展示控制逻辑以及模拟的执行器或过程响应，以便因果链清晰可见。
4. 注入的故障案例 记录确切的异常输入：超速请求、无效状态指令、陈旧标签、嘈杂信号或运动期间的急停。
5. 所做的修订 记录逻辑中的变更：增加了钳制、收紧了许可条件、引入了超时、锁存了报警、调整了 ROC 限制。
6. 经验教训 说明故障暴露了什么，以及由此得出了什么设计规则。

这会产生其他工程师可以审查、质疑和复现的证据。这就是值得追求的标准。

最常见的错误是允许 AI 绕过验证层。

其他反复出现的错误包括：

• 将 AI 输出直接写入执行器指令标签，
• 将平均 AI 性能视为安全论据，
• 忘记陈旧数据检测，
• 省略基于状态的许可条件，
• 依赖 HMI 报警而不是硬执行块，
• 在没有特定平台最终验证的情况下过度信任仿真，
• 混淆生成的梯形图与经过验证的梯形图。

生成的梯级不是经过验证的梯级。工业控制仍然由机器实际执行的操作所支配。

正确的模式不是“AI 控制工厂”。正确的模式是“AI 可以建议，但 PLC 决定，且安全层仍然可以说不。”

确定性否决逻辑是使该边界成为现实的工程机制。它通过钳制、许可条件、联锁和独立安全功能，将无界的请求转换为有界的控制行为。这就是防止概率性软件演变成物理事故的方法。

OLLA Lab 作为排练和验证环境适合此工作流。它允许工程师练习那些令人不安的案例——错误的设定点、无效的状态、嘈杂的信号、失败的许可条件、紧急停止——而无需将实际设备作为测试台。与死记硬背语法并祈祷第一次真正的故障是温和的相比，这通往调试判断的路径更为可靠。

- IEC 61131-3: 可编程控制器 — 第 3 部分：编程语言 - IEC 61508 概述（功能安全） - NIST AI 风险管理框架 (AI RMF 1.0) - 制造业中的数字孪生：分类文献综述与分类 (IFAC, DOI) - 工业中的数字孪生：最先进技术 (IEEE, DOI)

[此处插入作者信息]

[此处插入事实核查信息]