如何通过仿真排查 AI 生成的梯形图逻辑“代码垃圾” (Workslop)

AI 生成的 PLC “代码垃圾”(Workslop) 是指语法有效但操作上不安全的逻辑，在进行任何物理部署之前，必须在确定性的仿真环境中进行测试。OLLA Lab 的仿真模式 (Simulation Mode) 和变量面板 (Variables Panel) 可帮助工程师安全地暴露扫描周期错误、冲突的状态分配和定时故障。

AI 在 PLC 工作中的失败，主要不是因为产生乱码，而是因为它生成的代码看起来合情合理，能够顺利编译，但一旦涉及扫描顺序、I/O 定时和机器状态时，就会表现糟糕。语法是廉价的，而确定性行为则不然。

Ampergon Vallis 最近的一项内部基准测试支持这一观点。在对 500 个 AI 生成的电机启动序列进行的基准测试中，68% 的序列在仿真执行过程中表现出隐含的竞争条件或状态冲突，最常见的是双线圈分配和置位/复位 (latch/unlatch) 失败 [方法论：n=500 个生成的电机启动任务，与资深工程师的审查基准进行对比，并在 2026 年第一季度于 Ampergon Vallis Lab 测试中评估]。这一指标支持一个狭义的结论：AI 生成的梯形图逻辑经常能通过文本层面的“嗅探测试”，但在执行时却会失败。它并不支持关于所有 PLC 任务、所有模型或所有供应商的更广泛结论。

工业自动化中的 AI “代码垃圾”是指语法有效但操作上具有危险性的控制逻辑。其核心问题不在于格式质量，而在于该逻辑无法可靠地遵循扫描周期确定性、物理 I/O 行为或控制状态的一致性。

在 PLC 工作中，这种区别是决定性的。一段梯形图可能符合 IEC 61131-3 的语法要求，但由于它会导致输出冲突、序列不稳定或在异常条件下崩溃的故障处理，因此不适合部署。“看起来正确”并不是工程标准。

在操作上，AI 代码垃圾通常以几种可重复的形式出现：

• “看起来正确”谬误：逻辑读起来通顺，使用了熟悉的指令模式，但忽略了机器约束、允许条件 (permissives) 或故障安全行为。
• 状态机失忆：模型在多个梯级、转换和复位条件之间，无法保持对当前机器状态的一致性认知。
• 冗余路由：模型将简单的互锁逻辑扩展为许多包含冗余条件的梯级，使得审查变得困难，故障路径也不明显。
• 冲突的状态分配：同一个输出或内部位在多个地方被写入，且没有明确的所有权模式。
• 缺乏去抖动或信号调节：机械输入、噪声转换和异步反馈被视为理想的布尔值。
• 异常状态处理薄弱：跳闸、验证失败、超时条件和重启行为要么缺失，要么被当作事后补救措施添加。

这就是为什么资深工程师越来越多地将时间花在验证 AI 输出上，而不是自己编写第一版逻辑。瓶颈已经从起草转移到了验证。

LLM 在处理 PLC 扫描周期时遇到困难，是因为它们是异步的文本预测器，而 PLC 是同步的执行引擎。语言模型根据训练数据中的统计模式预测下一个标记 (token)，而 PLC 则按固定顺序执行逻辑，通常是读取输入、从上到下从左到右求解逻辑，然后写入输出。

这种差异是操作性的。

PLC 扫描周期会产生确定性的覆盖行为。如果 AI 生成的程序在一个梯级上接通了一个输出线圈，随后在扫描的后续部分又断开了同一个地址的线圈，那么输出映像中的最终状态是由执行顺序决定的，而不是由哪个梯级在文本上看起来更合理决定的。

一个简单的例子说明了这一点：

|----[ XIC Start_PB ]----[ XIO Stop_PB ]----------------( OTE Motor_Run )----|

|----[ XIC Fault_Active ]--------------------------------( OTU Motor_Run )----|

如果标签结构和平台语义允许这种模式，人类审查员可能一眼就能看出意图：除非按下停止键，否则启动电机；如果出现故障，则清除运行状态。但根据指令类型、标签使用、保持性预期以及其他状态逻辑在何处写入 `Motor_Run`，执行行为可能仍然是错误的或与平台不一致。AI 经常在不注意的情况下混合使用输出所有权风格。

仿真通过强制逻辑针对不断变化的状态执行，而不是让其保持为静态文本工件，从而检测竞争条件。静态审查可以捕捉到一些结构性错误，但对于暴露动态定时故障、覆盖行为和边缘情况序列却无能为力。

这就是 OLLA Lab 在操作上发挥作用的地方。其仿真模式允许工程师运行逻辑、停止逻辑、切换输入并观察输出和变量状态，而无需接触物理硬件。这一点至关重要，因为 AI 生成的逻辑往往只在条件按特定顺序变化时才会失败：例如在验证前发出启动命令、在允许条件前进行验证、模拟阈值在跳闸点附近振荡，或在超时分支期间按下复位键。

变量面板 (Variables Panel) 作为诊断层。它使标签状态、I/O 值、模拟信号和控制变量在执行过程中可见，因此工程师可以将预期行为与实际状态转换进行比较。

在实际排查中，仿真有助于暴露至少四种常见的 AI 故障模式：

• 竞争条件
• 置位失败
• 互锁缺失
• 定时不稳定

有界数字孪生环境进一步加强了这一工作流程。在这里，数字孪生验证应在操作层面理解：工程师将梯形图行为与真实的虚拟设备模型进行比较，以确定控制序列在部署前是否产生预期的机器状态、故障响应和恢复路径。这并不是说每个模型都能完美复现工厂行为。

这种“仿真优先”的方法也符合功能安全实践的逻辑。IEC 61508 的范围比 PLC 调试更广，但它强调了在危险行为进入现场之前进行验证、确认和风险降低的必要性 (IEC, 2010)。

首先应检查输出所有权错误、缺乏状态规范以及不切实际的 I/O 假设。这些故障导致了很大比例的早期失败，且通常比细微的优化问题更容易检测。

以下是一个实用的初步检查清单：

• 双线圈或多重写入输出
• 混合保持性和非保持性行为
• 缺失允许条件和验证信号
• 无超时路径
• 无去抖动或边缘处理
• 报警逻辑与序列逻辑混杂
• 阈值附近的比较器抖动
• 不安全的重启行为

这些不是高级的边缘情况，而是机器逻辑工程审查的第一层。

不要逐行重构代码垃圾。将其精简为核心状态模型，验证序列，然后围绕该已验证的核心重建互锁、报警和模拟行为。编辑 AI 发明的每一个装饰性梯级，通常比恢复架构本身更慢。

一个实用的三步法效果很好。

1. 隔离核心序列

将逻辑简化为机器或过程运行所需的最小状态和转换集。对于电机启动器，这可能简单到仅包含命令、允许条件、验证、停止和故障复位。

使用 OLLA Lab 的仿真环境首先测试该简化序列。如果核心序列无法保持，周围的报警逻辑只是伪装。

在此阶段，用可观察的术语定义操作上的正确行为：

• 什么输入启动序列，
• 哪些条件必须已经为真，
• 哪个输出应该接通，
• 必须返回什么验证信号，
• 如果验证信号未及时返回，应该发生什么故障，
• 以及什么样的复位路径是可以接受的。

2. 整合互锁和故障安全行为

将分散的允许条件移动到清晰的互锁结构中。急停链、模式条件、安全相关的禁止条件和跳闸条件不应分布在不相关的梯级中。

更清晰的模式通常包括：

• 单个运行允许汇总位或等效的互锁表达式，
• 明确的故障汇总逻辑，
• 清晰的验证和超时处理，
• 以及文档化的复位理念。

如果序列涉及安全功能，培训或验证环境可以帮助工程师演练故障感知逻辑并观察行为，但这本身并不构成 SIL 认证、安全验证或现场验收。

3. 注入模拟噪声和异常条件

AI 生成的逻辑在额定条件下通常表现良好，但一旦现实变得复杂就会失败。这就是为什么异常状态测试至关重要。

使用模拟工具和变量控制来模拟：

• 传感器漂移，
• 阈值抖动，
• 延迟反馈，
• 验证信号失败，
• 输入卡死，
• 运行期间的模式切换，
• 以及故障后的重启。

在 OLLA Lab 中，模拟和 PID 学习工具可以通过在执行期间使模拟值、比较器行为和循环相关变量可见，来支持这种有界测试。这使工程师能够观察控制逻辑是否振荡、重复跳闸或以受控方式恢复。

工程师应记录一份精炼的工程证据，而不是截图库。目的是证明逻辑已经过定义、测试、压力测试、修订和理解。

使用以下结构：

1. 系统描述 定义被控制的机器、撬装设备或过程单元。说明控制目标和涉及的主要 I/O。
2. “正确”的操作定义 指定可观察的成功标准：所需的允许条件、预期的序列顺序、验证定时、跳闸行为和复位行为。
3. 梯形图逻辑和仿真设备状态 包含相关的梯形图部分，以及相应的仿真机器状态或数字孪生状态。
4. 注入的故障案例 准确说明引入了什么异常条件：验证失败、液位开关噪声、阀门反馈延迟、模拟阈值振荡等。
5. 所做的修订 展示逻辑中发生了什么变化以及原因。
6. 经验教训 记录工程收获：输出所有权、超时规范、迟滞要求、序列状态清晰度或报警分离。

数字孪生验证更安全，因为它在保持可观察性的同时控制了故障。在实际设备上测试未经审查的 AI 生成逻辑，会将人员、资产和过程连续性暴露给尚未在现实转换中得到验证的行为。

在本文中，数字孪生验证是指根据真实的虚拟机器或过程模型验证梯形图逻辑，以便工程师在部署前比较预期的设备行为与实际的控制状态行为。这并不是说该模型能完美复现每一个工厂细节。

这在经济和技术上都很重要。调试时间昂贵，在生命周期后期发现故障通常比在软件在环 (SIL) 环境中早期纠正更昂贵。这一通用原则在各个工程领域都得到广泛支持，即使确切的成本乘数因来源和背景而异。

实际的观点很简单：如果你能让逻辑在仿真中安全地失败，你就应该这样做。

OLLA Lab 应作为有界验证和演练环境使用，而不是作为 AI 生成 PLC 代码的自动修复工具。其价值在于它让工程师能够构建梯形图逻辑、在仿真中运行、检查实时变量和 I/O，并在接触物理资产之前将逻辑行为与现实场景和虚拟设备状态进行比较。

在此工作流程中，OLLA Lab 支持三项具体任务：

• 执行层面的验证
• 诊断可见性
• 基于场景的演练

这种定位是经过深思熟虑的。OLLA Lab 并不会使 AI 代码本身变得可信。它为工程师提供了一个观察其安全失败、追踪因果关系并将逻辑强化为更接近可部署架构的地方。

- 向下： 在 OLLA Lab 开始实践练习。

• 向上： 探索完整的 AI + 工业自动化中心。
• 横向： 相关文章 1。
• 横向： 相关文章 2。
• 横向： 相关文章 3。

- IEC 61131-3: 可编程控制器 — 第 3 部分 - IEC 61508 功能安全标准系列 - NIST AI 风险管理框架 (AI RMF 1.0) - 欧盟 AI 法案：监管框架 - ISA/IEC 62443 工业网络安全概述