如何利用“生成-验证循环”防止 PLC 逻辑中的 AI 幻觉

为了防止 PLC 编程中的 AI 幻觉，工程师应采用“生成-验证循环”：即边界 AI 生成、针对 IEC 61131-3 预期的语法和结构检查，以及针对模拟设备行为的动态测试。在 OLLA Lab 中，这意味着 AI 的建议会在基于 Web 的梯形图环境中进行审查，并在做出任何实际部署决策之前，针对场景逻辑、I/O 状态和数字孪生行为进行验证。

AI 在工业自动化中失败，并不是因为它“代码写得不好”。失败的原因在于 PLC 逻辑不仅仅是代码；它是与物理设备、扫描时序和故障后果紧密相关的确定性控制行为。

这种区别至关重要。一个梯形图梯级看起来可能合乎逻辑，但在操作上却是错误的。

在 Ampergon Vallis 的一项内部基准测试中，开放式的 AI 辅助梯形图生成在 42% 的复杂电机控制序列任务中产生了关键的控制缺陷。这些缺陷包括双重破坏性位分配、无效的允许条件处理以及序列状态歧义。方法论： 涉及电机启停、自保持、主/从控制和故障复位模式的 31 项边界生成任务；基准比较器为场景规范中经工程师审查的预期控制行为；时间窗口为 2026 年 1 月至 3 月。该指标仅支持一个狭窄的观点：在没有验证的情况下，盲目信任无限制的生成是不安全的。它并不支持关于所有 AI 工具、所有 PLC 任务或所有供应商的普遍性结论。

实际的答案不是“永远不要使用 AI”，而是强迫 AI 进入验证工作流。用工业术语来说，这意味着在任何逻辑接近物理 I/O 之前，必须先经过语法防护栏、场景上下文和动态仿真。盲目乐观不是一种控制哲学。

大语言模型（LLM）之所以会在梯形图逻辑中产生幻觉，是因为它们生成的是统计学上可能的模式，而 PLC 则是在严格的扫描周期和状态约束下执行确定性逻辑。

LLM 根据训练数据预测什么样的指令序列看起来合理。但 PLC 并不关心什么看起来合理。它按照定义的执行顺序，使用真实的标签、真实的时序和真实的后果来评估逻辑。这就是核心的不匹配之处。

IEC 61131-3 定义了标准化的 PLC 编程语言和结构预期，但它无法挽救模型对工厂行为、供应商方言边界或序列意图的误解。一个生成的梯级在语法上可能很熟悉，但仍然违反了控制哲学。语法并不等同于可部署性。

PLC 工作中常见的 AI 逻辑故障

模型假设了一种类似软件的事件模型，而不是循环执行。这通常表现为竞争条件、不当的锁存，或依赖于 PLC 实际上并不提供的执行顺序的输出行为。

• 忽视扫描周期：

模型混合了不同供应商的指令风格、寻址约定或功能语义。仅仅因为梯级“看起来正确”，并不意味着 Rockwell、Siemens、基于 Codesys 的环境等可以互换。

• 方言混合：

除非明确建模并测试了阀门行程时间、泵惯性滑行、传感器抖动、触点反弹或执行器迟滞等约束，否则模型无法从本质上推理这些因素。

• 物理盲区：

模型创建了控制叙述中不存在的地址、联锁或状态位。当提示词过于宽松且系统被允许即兴发挥时，这种情况很常见。

• 虚构的 I/O 或标签：

模型处理了“理想路径”，却忽略了跳闸、复位、验证反馈、超时行为或重启条件。对于那些只有在一切正常时才能工作的逻辑，工厂环境是非常严苛的。

• 故障路径缺失：

为什么确定性执行改变了证明标准

确定性控制逻辑必须通过可观察的行为来证明，而不是通过风格上的自信来接受。

在工业自动化中，“正确”意味着序列在正常、异常、启动、停机和恢复状态下都能按预期运行。这种证明需要的不仅仅是通过编译器检查。它需要随时间推移的状态观察。

这也是为什么开放式 AI 生成无法满足 IEC 61508 等标准下功能安全工作所要求的可追溯性和验证预期的原因。安全生命周期义务要求规范、验证和记录在案的证据。模型给出的一段自信的文字并不是证据。充其量，它只是一个草稿。

“生成-验证循环”是一种边界工程工作流，其中 AI 可以提出控制逻辑，但只有在经过结构检查并针对预期机器行为进行动态验证后，该逻辑才会被接受。

这不是一种哲学偏好，而是一种控制风险遏制方法。

在实践中，该循环将通常被草率合并的三件事分离开来：

• 草稿生成，
• 确定性审查，
• 以及行为验证。

这种分离是健康的。同样，不让概率模型假装自己是调试工程师也是健康的。

三步验证架构

1. 上下文生成 AI 受到定义的控制哲学、I/O 映射、标签字典、序列目标和危险上下文的约束。如果缺少这些输入，模型会用概率填补空白。概率在语言中很有用，但在电机启动器中就不那么讨喜了。
2. 语法和结构防护栏 检查输出是否符合语言规范、指令兼容性、标签有效性，以及是否存在冲突分配、歧义锁存或无效序列转换等结构缺陷。IEC 61131-3 在此作为语言框架具有相关性，尽管供应商特定的实现细节仍然很重要。
3. 动态仿真 逻辑针对模拟的过程或机器模型进行执行，以便工程师可以观察 I/O 转换、时序行为、报警条件、联锁和故障响应。这是“看起来正确”转变为“表现正确”（或在尝试中失败）的关键点。

“仿真就绪（Simulation-Ready）”在操作上的含义

“仿真就绪”的工程师不仅仅是能编写梯形图语法的人。他们能够证明、观察、诊断并加固控制逻辑，使其在接触实际过程之前就能抵御现实的过程行为。

这个定义是行为导向的，而不是理想化的。

在实际操作中，“仿真就绪”的工作包括：

• 定义正确的序列行为是什么样的，
• 追踪标签状态与设备状态的对应关系，
• 注入故障和异常条件，
• 在观察到故障后修改逻辑，
• 并记录为什么修改后的行为更稳健。

这就是 OLLA Lab 发挥操作价值的地方。它提供了一个基于 Web 的环境来构建梯形图逻辑、运行仿真、检查变量和 I/O，并在受控设置中将梯形图状态与场景行为进行比较。这是一个用于验证任务的排练环境，而不是绕过现场经验的捷径。

OLLA Lab 将 AI 辅助定位为定义明确的仿真工作流中的边界化辅导和建议层，而不是控制设计的自主权威。

这种区别至关重要，因为无限制的生成正是幻觉滋生的地方。

在 OLLA Lab 中，GeniAI 助手旨在支持结构化环境内的入职培训、解释、纠正建议和梯形图逻辑辅助，该环境已经包含了场景框架、标签可见性和仿真工具。其实际价值不在于 GeniAI 能“写出完美的代码”（它做不到），而在于建议可以针对已知的场景条件进行审查，而不是作为自由浮动的文本被接受。

防护栏在实践中的作用

在边界化的 OLLA Lab 工作流中，AI 建议可以通过以下方式受到约束：

例如，电机控制、泵序列、暖通空调（HVAC）或过程撬块场景定义了逻辑应实现的目标。

• 场景特定目标

输入、输出、模拟量值和状态标签是可见的，并与场景绑定，而不是按需虚构。

• 已知的 I/O 映射

工程师基于明确的标签含义、联锁、允许条件和预期序列行为进行工作。

• 标签字典和控制哲学

场景可以包含异常状态预期，如急停链、验证反馈、超时逻辑、报警阈值和复位行为。

• 危险和调试说明

建议的逻辑可以运行、暂停、切换和观察，而不是在安全距离外盲目欣赏。

• 仿真模式和变量检查

这是一种更狭窄、更可信的 AI 使用方式。当模型被迫在初级工程师应遵守的相同约束下运行时，它才是有用的。

一个简明的例子：虚构的允许条件与边界生成

假设要求 AI“编写一个带故障处理的泵启动序列”。在开放式环境中，它可能会虚构一个允许条件（如 `PUMP_READY_FB`），假设一个复位路径，并创建一个设计基础中不存在的超时位。

而在边界化的 OLLA Lab 场景中，工程师可以将该建议与以下内容进行比较：

• 实际可用的标签，
• 记录在案的序列目标，
• 预期的验证反馈，
• 以及模拟的设备响应。

纠正通常很简单。而不纠正的后果却很严重。

工程师通过在仿真中运行建议的控制序列、观察随时间推移的状态变化，并将梯形图行为与正常和异常条件下的预期机器或过程行为进行比较，来针对数字孪生测试 AI 生成的逻辑。

数字孪生不是装饰性的 3D 外壳。在这种背景下，它是一个动态仿真层，用于测试控制逻辑在接触过程现实时是否稳健。

这种操作定义很重要，因为“数字孪生”经常被用作提升格调的词汇。在这里，它意味着可观察的事物：逻辑驱动一个建模系统，而建模系统揭示了逻辑是否真正有效。

验证期间需要观察的内容

在 OLLA Lab 中验证 AI 辅助逻辑时，工程师应检查：

输出是否仅在允许条件真正满足时才通电？

• 输入到输出的因果关系

定时器、转换和复位在扫描周期和状态变化中是否表现正确？

• 序列时序

逻辑是确认了设备状态，还是仅仅假设了它？

• 验证反馈行为

异常条件是否以受控方式锁存、报警并复位？

• 报警和跳闸处理

如果 AI 建议了比较器、模拟量阈值或 PID 行为，这些响应在过程值变化时是否保持稳定？

• 模拟量和 PID 响应

故障发生后，系统是返回到安全且预期的状态，还是在混乱中重启？

• 恢复逻辑

使用变量面板追踪因果关系

OLLA Lab 中的变量面板非常有用，因为它将梯形图逻辑转化为可观察的状态模型。

工程师不仅可以询问梯级是否为真，还可以检查：

• 标签值，
• 输入转换，
• 输出状态，
• 模拟量值，
• PID 相关变量，
• 以及仿真运行时的场景行为。

这种可见性对于调试 AI 生成的逻辑至关重要。大多数幻觉只有在序列被迫随时间推移进行解释时才会变得明显。

测试异常条件，而不仅仅是标称行为

AI 生成的逻辑应在故障注入下进行测试，而不仅仅是在理想的启动条件下。

在 OLLA Lab 中，这意味着使用仿真控制和场景状态变化来激发逻辑：

• 丢弃一个允许条件，
• 延迟验证反馈，
• 强制改变传感器状态，
• 改变模拟量输入，
• 或在跳闸后创建重启条件。

如果序列在轻微的异常条件下崩溃，问题不在于模拟器太严苛。模拟器是在代表工厂表现得“礼貌”。

AI 幻觉产生的梯形图错误通常看起来结构很熟悉，但包含确定性审查会拒绝的冲突状态逻辑。

一个常见的例子是双线圈或冲突分配问题，即同一个输出或内存位在多个地方被驱动，而没有受控的排序策略。

示例：冲突的电机指令与已验证的自保持逻辑

AI 幻觉模式：冲突分配

语言：梯形图 (Ladder Diagram)

梯级 1： | START_PB STOP_PB OL_OK MOTOR_RUN | |----] [-------]/[------] [--------------------( )-----|

梯级 2： | FAULT_RESET MOTOR_RUN | |----] [----------------------------------------( )-----|

为什么会失败： 同一个输出在多个梯级中被分配了不同的意图。根据扫描顺序和周围逻辑，第二个梯级可能会覆盖第一个梯级的状态。结果是行为模糊，特别是在复位和重启条件下。

已验证模式：带受控复位路径的显式自保持

语言：梯形图 (Ladder Diagram)

梯级 1： | STOP_PB OL_OK FAULT_CLEAR START_PB MOTOR_RUN | |----]/[------] [------] [----------] [----------------------( )-----| | MOTOR_RUN | |----------------------------] [----------------------------------|

梯级 2： | FAULT_ACTIVE MOTOR_RUN_LATCH_RST | |----] [----------------------------------------------------( )-------------|

为什么更好： 运行指令通过显式的自保持路径保持，而故障处理被分离为定义的复位或禁止策略。具体的实现会因平台和控制哲学而异，但原则是稳定的：一个状态意图，一个受控路径。

重点不在于每个双重分配在每个供应商环境中总是无效的。重点在于 AI 经常在不了解扫描后果的情况下引入冲突的状态逻辑。这正是工程师必须捕捉的部分。

工程师应记录一份精简的工程证据，证明逻辑经过了规范、测试、在适当情况下失败、修改，并针对可观察的行为进行了重新测试。

截图库是不够的。它只能证明屏幕存在过。

请使用以下结构：

1. 系统描述 定义过程单元、机器或场景。说明设备、序列目标和相关的 I/O。
2. “正确”的操作定义 以可观察的术语说明正确行为的含义：启动条件、允许条件、序列转换、报警、跳闸和恢复行为。
3. 梯形图逻辑和模拟设备状态 包括梯形图实现以及执行期间相应的模拟机器或过程状态。
4. 注入的故障案例 记录引入的异常条件：延迟反馈、失败的允许条件、模拟量偏移、急停事件、抖动或超时。
5. 所做的修改 准确展示逻辑中发生了什么变化以及原因。
6. 经验教训 说明测试揭示了关于序列设计、故障处理、时序假设或 AI 生成缺陷的哪些信息。

这种文档风格比精美的视觉效果更有价值，因为它展示了工程判断力。雇主和审查人员不需要另一张梯级的截图。他们需要证据证明该梯级经受住了质询。

“生成-验证循环”是由工业控制、功能安全和基于仿真的验证中已建立的区分所支持的，而不是由单一的“银弹”标准支持的。

相关的支持来自多个层面：

标准和技术基础

• IEC 61131-3 支持 PLC 编程中语言纪律的必要性，包括跨工业控制器的定义编程模型和实现预期。
• IEC 61508 支持在安全相关的电气、电子和可编程系统中进行可追溯性、验证和生命周期严谨性的必要性。
• exida 指南和安全实践文献始终强调，验证、审查的独立性和记录在案的验证比表面的编码流畅度更重要。
• 工业工程、过程系统和信息物理系统中的数字孪生和仿真文献支持在部署前使用动态模型来测试控制行为。
• 人因工程和沉浸式培训文献支持将仿真作为排练复杂操作任务的有用环境，特别是在现场系统练习昂贵、不安全或受操作限制的情况下。

这证明了什么，又没有证明什么

这些证据支持将仿真和边界化的 AI 辅助作为控制验证的风险降低工作流。

它并不支持声称：

• AI 生成的 PLC 逻辑本质上是安全的，
• 仿真可以取代调试，
• 数字孪生保证现场成功，
• 或者培训环境通过关联赋予认证、现场能力或正式合规性。

这些是不同的主张。其中一些是代价高昂的错误。

工程师应将 OLLA Lab 作为高风险控制任务的排练和验证环境，这些任务在实际设备上很难安全地进行练习。

这是可信的产品定位。

OLLA Lab 在一个环境中结合了基于浏览器的梯形图编辑器、仿真模式、变量和 I/O 可见性、基于场景的练习、数字孪生式机器交互、模拟量和 PID 工具以及 AI 辅导支持。实际的好处是工程师可以从编写逻辑转向观察后果。

如果使用得当，OLLA Lab 支持以下工作：

• 验证电机和泵序列，
• 测试联锁和允许条件，
• 观察报警和跳闸行为，
• 追踪模拟量和 PID 响应，
• 比较梯形图状态与模拟设备状态，
• 以及在故障注入后修改逻辑。

这对于初级工程师和培训项目尤其有用，因为雇主无法廉价地将现场调试风险交给新手。工厂不是未经验证逻辑的实习场所。

OLLA Lab 不应被定位为：

• 现场调试的替代品，
• 就业保证，
• 安全认证途径，
• 或证明生成的代码默认即为生产就绪。

它是一个在现场接触之前学习和验证工程行为的边界化环境。这已经是一个严肃的用例了。

PLC 逻辑中的 AI 幻觉最好被视为一个控制风险问题，而不是提示词编写的不便。

补救措施是“生成-验证循环”：约束生成上下文，强制执行结构纪律，并针对模拟的过程现实测试行为。在该工作流中，AI 可以很有用。在工作流之外，AI 通常只是戴着安全帽、口若悬河的猜测者。

对于工业自动化，标准很简单：如果逻辑在部署前无法被观察、故障测试、修改和重新证明，那么它就没有准备好。工厂最终还是会进行审查，通常耐心会更少。

- NIST AI 风险管理框架 (AI RMF 1.0) - IEC 61131-3 标准概述 (PLCopen) - ISO/IEC 42001 AI 管理系统标准页面 - IEC 61508 功能安全概述 - ACM 数字图书馆（软件验证文献）