如何利用数字孪生验证 AI 生成的梯形图逻辑

AI 生成的梯形图逻辑必须针对虚拟过程行为进行验证，而不能仅进行语法检查。其核心失效模式在于时间维度：在静态审查中看似正确的代码，在受到扫描周期时序、执行器滞后和真实 I/O 因果关系的影响时，仍可能产生竞态条件、互锁缺失和状态偏离。

AI 生成的 PLC 代码通常不是因为语法错误而失败。它失败的原因在于物理控制是基于时间的，而语言模型则不然。一段梯形图逻辑在纸面上看起来可能非常规范，但一旦实际的顺序逻辑依赖于扫描顺序、设备延迟或确认反馈时，它就可能崩溃。

在 Ampergon Vallis 最近进行的一项评估 AI 辅助电机排序逻辑的基准测试中，78% 包含嵌套定时器的生成程序在 OLLA Lab 的 100 毫秒扫描周期模拟中表现出至少一个可观测的时序故障，尽管它们在 IEC 61131-3 风格的梯形图结构上是语法合规的。方法论：n=32 个包含启动/停止、许可条件和定时器交互的电机排序任务；基准比较器为针对语法和结构完整性的人工审查；时间窗口为 2026 年 1 月至 3 月。该指标支持一个狭义的观点：静态合理性是衡量执行可靠性的糟糕指标。它并不支持所有 AI 生成的 PLC 逻辑都是不安全或不可用的这一更广泛的观点。

AI 生成的 PLC 代码在物理负载下失败，是因为大语言模型（LLM）预测的是合理的代码标记，而 PLC 执行的是确定性的时间状态转换。这种架构上的不匹配比大多数讨论所承认的更为重要。

PLC 并不像代码助手所表现的那样“理解”梯形图。它执行的是扫描周期：读取输入 -> 执行逻辑 -> 写入输出。IEC 61131-3 定义了工业控制器的编程语言和执行行为，但符合语言形式并不能证明一个序列在运行中是时序正确的 (IEC, 2013)。语法是廉价的，而确定性不是。

三个脱节解释了大多数故障。

LLM 与物理 PLC 之间的 3 个脱节

AI 编写逻辑时往往假设状态变化是瞬时且全局可见的。但在 PLC 中，事实并非如此。输入被采样，逻辑被求解，输出被更新，且顺序至关重要。一个在纸面上看起来有效的自保持逻辑，当确认输入在同一扫描周期内尚未变为真时，可能会失效。

• 对扫描周期的无知

物理设备的移动速度比逻辑慢。阀门需要行程时间，气缸需要冲程时间。接触器会抖动，传感器会产生噪声，过载保护在跳闸前不会征求许可。AI 生成的序列往往在设备实际达到所需条件之前就推进了状态。

• 执行器惯性与反馈延迟

模拟量模块、网络化 I/O 和 PID 回路并非以相同的速率更新。AI 生成的控制逻辑可能假设存在平滑、即时的数值流，当实际的轮询间隔、滤波或死区产生滞后时，其表现就会很差。积分饱和是一个常见结果。该回路在时间因素介入之前看起来是“正常”的。

• I/O 轮询与模拟量时序不匹配

这就是实际的区别：文本概率与时间因果关系。前者编写的是合理的结构，后者则必须运行工厂。

“在负载下失败”并不主要意味着软件崩溃。它意味着当引入时序、状态保持和设备响应时，控制逻辑会产生不正确或不稳定的物理行为。

这种区别很重要，因为许多危险的漏洞在静态审查中无法被发现。在工业控制中，故障通常首先体现在机器行为上：

• 气缸在同一序列步骤中伸出又缩回，
• 输送机在没有有效许可的情况下重启，
• 泵的主/备切换发生振荡，
• 剔除门在生产线速度下漏掉产品，
• 混合器序列因为状态位从未锁存而停滞，
• 报警在逻辑中清除，但过程实际上尚未恢复。

这些不是抽象的软件缺陷，而是因果关系中可观测的异常。在实际生产过程中，这就是调试成本变得高昂的时候。

从操作层面看，当出现以下一种或多种情况时，梯形图程序即被视为在负载下失败：

• 命令与确认之间的竞态条件
• 梯形图状态与设备状态之间的状态偏离
• 由扫描时间或任务顺序假设导致的互锁缺失
• 对同一执行器的重复或冲突的输出写入
• 由于时序、滤波或回路整定不匹配导致的模拟量控制行为不稳定

IEC 61508 在此具有相关性，因为功能安全不仅取决于硬件可靠性，还取决于规范、实施和验证中的系统性完整性 (IEC, 2010)。AI 生成的代码并不通过断言就具备系统性能力。它必须在工程流程中进行审查和验证。

AI 生成的梯形图逻辑中最常见的非确定性漏洞是与时序相关的逻辑错误，这些错误在静态审查中看起来正确，但在引入扫描顺序、任务时序或物理反馈时会失败。

AI 生成的梯形图逻辑中的症状与根本原因

| 可观测症状 | 可能的根本原因 | 为什么静态审查会漏掉它 | |---|---|---| | 气缸动作后立即缩回 | 双线圈综合征或在不同例程中存在竞争性输出写入 | 每个梯级看起来局部有效；冲突仅在执行顺序中出现 | | 序列在一步后随机停滞 | 未锁存的状态机或缺失持久状态位 | 转换条件可见，但跨扫描周期的状态保持不稳健 | | 电机在许可条件建立前启动 | 在反馈确认前发出命令 | 梯级逻辑读起来通顺，但审查中缺乏执行器和传感器延迟 | | 剔除门间歇性漏掉产品 | 扫描时间混叠或逻辑放置在任务执行的太靠后位置 | 在低速测试中，故障可能永远不会出现 | | 泵切换行为异常 | 不正确的复位条件或同时进行主/备仲裁 | 序列边缘情况未在静态通过中得到验证 | | PID 回路在模式切换后严重超调 | 积分饱和或对模拟量更新时序处理不当 | 指令块存在，但回路行为从未受到压力测试 |

为什么这些故障能逃过代码审查

静态审查擅长发现结构性错误，但不擅长揭示时序错误。经验丰富的控制工程师通常能嗅出问题的味道，但即使是优秀的审查员也会错过那些依赖于精确扫描时序、延迟反馈或异常状态恢复的故障。

这就是为什么“看起来正确”是一个危险的标准。它奖励整洁的图表，却忽略了过程真正关心的东西：行为。

扫描周期、任务顺序和反馈确认之所以重要，是因为 PLC 逻辑不仅仅是声明性的。它是按严格顺序执行的，且物理设备在自己的时间线上做出响应。

一个常见的误解是梯形图逻辑因为直观所以简单。视觉语法并不是难点。难点在于证明状态变化在跨扫描周期和跨机器运行时保持一致。

三个工程现实驱动了这一点：

1. 扫描顺序决定了控制器在特定时刻“知道”什么

如果输入是在扫描开始时读取的，那么逻辑在下一次扫描之前无法对后续的物理变化做出反应。这会产生微小但至关重要的窗口，导致命令和确认不同步。

2. 任务调度改变行为

连续任务、周期性任务、事件任务和通信更新都会改变逻辑读取数据和写入输出的时间。在一个任务安排下工作的告诉剔除门，在另一个安排下可能会失败。

3. 反馈不是装饰

开到位证明、关到位证明、电机运行、过载健康、压力可用、液位达到——这些不是“有则更好”的位。它们是序列与猜测之间的区别。

这就是为什么调试工程师坚持要求许可条件、互锁和状态确认。他们是在试图阻止机器变得“有创造力”。

在此背景下，数字孪生验证意味着将控制逻辑绑定到模拟设备模型，以便工程师在部署前观察 I/O 因果关系、序列行为、互锁和故障恢复。

该定义需要保持可操作性。“数字孪生”一词常被滥用。在这里，它意味着更具体的内容：

• PLC 标签映射到模拟输入、输出和过程变量
• 设备行为以模拟的延迟、运动或过程变化进行响应
• 工程师可以观察命令、反馈和序列状态是否保持一致
• 可以注入故障以测试异常条件和恢复逻辑

这实际上是一个软件在环（SIL）验证层。逻辑不再仅凭外观判断，而是通过与虚拟过程的交互来判断。

虚拟调试和工业仿真领域的研究支持了仿真在物理部署前暴露集成和序列缺陷的价值，特别是在复杂的自动化系统中 (Bär et al., 2018; Oppelt et al., 2020)。所需的精确保真度取决于任务。并非每个训练模型都是完整的工厂模型，也并非每个数字孪生都适用于安全声明。

在这一有限框架内，OLLA Lab 可作为高风险调试任务的验证和演练环境。它允许工程师在基于浏览器的环境中构建梯形图逻辑、模拟行为、检查变量和 I/O，并针对基于场景的设备行为测试逻辑。它不能替代现场验收测试、正式安全验证或特定工厂的危险审查。

OLLA Lab 通过强制生成的梯形图逻辑与模拟设备状态、I/O 时序和可观测的过程行为进行交互，而不是将其停留在文本合理性的层面，从而充当了真值层。

这一点很重要，因为 AI 辅助在草稿生成方面最强，而在确定性否决方面最弱。OLLA Lab 不会修复代码，它为工程师提供了一个暴露代码实际运行情况的场所。

具体而言，OLLA Lab 提供：

• 用于构建或粘贴梯形图程序的基于 Web 的梯形图编辑器，
• 无需物理硬件即可运行、停止和测试逻辑的仿真模式，
• 用于监控标签、模拟量数值、输出和控制行为的变量面板，
• 可用的 3D/WebXR/VR 工业仿真，以便根据设备行为观察逻辑，
• 包含目标、危险、互锁、序列需求和调试说明的基于场景的练习，
• 用于离散逻辑之外的过程导向测试的模拟量和 PID 工具，
• 通过 Yaga（旨在协助入职和纠正性指导的 AI 实验室教练）提供的引导支持。

其有限的声明很简单：OLLA Lab 是在接触实际设备之前，针对真实行为验证逻辑的场所。

工程师可以通过将生成的程序映射到场景、观察设备响应、注入故障并根据状态偏离或互锁失败修改逻辑，在 OLLA Lab 中测试 AI 生成的梯形图逻辑。

分步验证工作流程

• 重复的输出线圈，
• 缺失的锁存，
• 缺失的许可条件，
• 没有状态保持的定时器链，
• 没有模式管理的模拟量块。

• 命令位，
• 反馈位，
• 步骤位，
• 定时器完成位，
• 报警状态，
• 适用的 PID 相关变量。

• 启动前必须具备哪些许可条件，
• 需要什么顺序，
• 什么反馈确认每个转换，
• 哪些报警或跳闸必须禁止操作，
• 系统在故障后应如何恢复。

• 快速切换离散输入，
• 延迟反馈确认，
• 模拟噪声模拟量信号，
• 强制许可条件在序列中间断开，
• 引入过载或卡死条件，
• 测试故障复位后的重启。

1. 导入并检查生成的逻辑 在 OLLA Lab 梯形图编辑器中粘贴或重新创建 AI 生成的逻辑。在运行任何内容之前，检查明显的结构性问题：
2. 将标签映射到可观测的 I/O 和变量 使用变量面板绑定输入、输出、模拟量数值和相关的内部标签。目标不仅仅是运行代码，而是使状态可见：
3. 将逻辑绑定到真实的场景预设 将程序连接到工业场景，如输送机、混合器、泵站、HVAC 序列或过程撬块。场景背景很重要，因为不同的系统会教导不同的故障模式。电机启动器不是批处理序列，批处理序列也不是主/备泵送问题。
4. 在测试前定义“正确”的操作含义 写下逻辑被视为正确必须满足的条件：
5. 首先运行正常操作 测试“快乐路径”（Happy Path）。启动、停止、复位和正常序列进度都应按预期进行。这还不够，但这是必要的。
6. 注入时序压力和异常条件 使用仿真控件来：
7. 观察因果关系，而不仅仅是梯级状态 观察模拟设备状态是否与梯形图状态匹配。如果梯级显示“电机开启”，而设备模型处于故障、延迟或阻塞状态，则说明发现了状态偏离。
8. 修改逻辑并重新测试 添加缺失的许可条件，正确锁存状态，将命令与确认分开，消除噪声输入的抖动，或重构序列。然后再次运行相同的故障案例。单次通过证明不了什么。

这就是 OLLA Lab 具有操作价值的地方。它将生成的代码转化为可测试的控制假设。

典型的 AI 生成的竞态条件出现在逻辑在物理确认发生之前就取消锁存或推进状态时，导致控制器的内部状态先于机器移动。

以下是该模式的简化示例。

| 梯级 1：启动命令锁存气缸伸出请求 | |----[ Start_PB ]----[/ EStop ]----[/ Fault ]----------------(OTL Extend_Cmd)----|

| 梯级 2：AI 生成的基于定时器而非反馈的过早取消锁存 | |----[ Extend_Cmd ]----[TON T4:0 1.0s]-----------------------(OTU Extend_Cmd)----|

| 梯级 3：由命令位驱动的输出 | |----[ Extend_Cmd ]------------------------------------------(OTE Sol_Extend)----|

| 梯级 4：在没有伸出证明的情况下推进序列 | |----[/ Extend_Cmd ]-----------------------------------------(OTL Step_Complete)--|

该故障并不隐蔽。逻辑假设气缸会在定时器窗口内伸出，并在不要求物理 Extended_LS 或等效证明信号的情况下移除了命令。如果执行器缓慢、粘滞、供气不足或受阻，序列仍会推进。

更稳健的模式应该区分：

• 命令发出，
• 输出驱动，
• 物理确认，
• 超时故障处理，以及
• 仅在确认后进行状态转换。

这就是序列图形与序列工程之间的区别。

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

它并不意味着“以前见过梯形图逻辑”，也不意味着“能提示 AI 助手生成一个合理的梯级”。操作行为的要求更高。

一名“仿真就绪”的工程师能够：

• 以可观测的术语定义控制序列的“正确”含义，
• 将梯形图逻辑映射到 I/O、标签和设备状态，
• 测试正常和异常的操作条件，
• 识别控制逻辑与模拟设备之间的状态偏离，
• 在故障后修改逻辑并证明修改为何有效，
• 将结果记录为工程证据，而不是截图集合。

所需的工程证据结构

1. 系统描述 正在控制什么过程或机器？
2. “正确”的操作定义 必须发生什么，按什么顺序，具备什么许可条件和故障响应？
3. 梯形图逻辑与模拟设备状态 逻辑命令了什么，模拟系统实际上做了什么？
4. 注入的故障案例 引入了什么异常条件？
5. 所做的修改 什么逻辑更改纠正或改进了行为？
6. 经验教训 暴露了什么时序、互锁或状态管理问题？

这些证据比一堆精美的截图更具可信度。

AI 生成的梯形图逻辑应被视为草稿工程材料，需遵循与任何其他未经证实的控制逻辑相同的验证准则，并特别注意执行行为、故障处理和安全边界。

几个边界很重要。

IEC 61131-3 的相关性

IEC 61131-3 规范了 PLC 编程语言及相关的软件模型约定。它有助于定义有效的程序结构和语言行为，但它并不证明给定的序列是安全、稳健或可供调试的 (IEC, 2013)。

IEC 61508 的相关性

IEC 61508 涉及功能安全和系统性能力。对于安全相关系统，软件必须通过严格的生命周期流程进行开发和验证。AI 生成的代码不会通过以梯形图格式存在而自动继承合规性。审查、可追溯性、测试和验证仍然是必要的 (IEC, 2010; exida, 2023)。

实际审查问题

审查 AI 生成的梯形图逻辑的工程师应询问：

• 所有输出是否都由单一明确的权限控制？
• 许可条件和跳闸是否明确且完整？
• 序列状态是否在跨扫描周期中正确保留？
• 命令和反馈是否分开？
• 是否定义了超时和异常状态路径？
• 是否处理了模拟量更新速率、滤波和模式切换？
• 逻辑在许可条件丢失或周期中断后是否能安全恢复？

如果其中几个问题的答案是“可能”，那么代码尚未准备好。

数字孪生验证对于暴露时序和行为缺陷非常有效，但它不能取代特定工厂的测试、硬件验证或正式的安全评估。

仿真环境可以揭示：

• 序列错误，
• 时序假设，
• 互锁遗漏，
• 状态偏离，
• 薄弱的故障恢复，
• 模拟条件下较差的模拟量行为。

它本身无法保证：

• 最终硬件兼容性，
• 部署架构上的网络确定性，
• 现场接线的正确性，
• 传感器校准的完整性，
• 安全完整性等级（SIL）的实现，
• 对特定现场操作规程的合规性。

换句话说，数字孪生验证减少了不确定性，但并没有消除它。

AI 生成的梯形图逻辑最好被视为草稿，而非定论。其核心失效模式是时间性的：在静态审查中看起来正确的代码，在引入扫描周期、执行器滞后、I/O 时序和异常条件时仍可能失败。

数字孪生验证通过强制逻辑与模拟过程交互来解决这一差距。这使得竞态条件、缺失的互锁和状态偏离在成为调试故障之前变得可见。在该工作流程中，OLLA Lab 被可靠地定位为一种软件在环环境，用于针对真实的工业场景构建、观察、压力测试和修改梯形图逻辑。

有用的区别很简单：语法与可部署性。AI 可以帮助完成前者，而工程师仍然必须证明后者。

Ampergon Vallis Lab 专注于工业自动化中的 AI 验证与仿真技术，致力于弥合生成式 AI 与确定性控制系统之间的鸿沟。

本文内容基于 IEC 61131-3 编程标准、IEC 61508 功能安全指南以及 OLLA Lab 在工业仿真环境下的基准测试数据。

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