如何诊断 PLC 逻辑中的“双线圈综合征”以及为何 AI 会忽略扫描周期

“双线圈综合征”是指 PLC 程序在多个梯级中向同一个输出地址写入数据，导致最后执行的梯级在扫描周期内覆盖了之前的逻辑。由于通用 AI 助手往往忽略 PLC 的执行顺序和延迟输出更新，因此需要基于仿真的验证来检测并纠正这些确定性的覆盖故障。

一个常见的误区是认为双线圈行为是一种竞态条件（Race Condition）。在大多数 PLC 中，这并非竞态条件，而是一种确定性的覆盖故障，其起因是在多个地方写入同一个地址位，却忽略了控制器是按扫描顺序而非程序员意图来解析状态的。

在 Ampergon Vallis Lab 最近的一项基准测试中，针对标准传送带分拣任务生成的 500 个 AI 梯形图逻辑脚本中，有 14% 包含重复的输出线圈寻址，从而产生了破坏性的覆盖 [方法论：n=500 个针对单一传送带分拣场景生成的脚本，与人工审核的单线圈基准模式进行对比，数据收集于 2026 年第一季度内部测试]。这支持了一个狭义的结论：通用 AI 在受限的梯形图任务中频繁输出扫描周期无效的输出模式。这并不支持关于所有 AI 工具、所有 PLC 方言或所有自动化工作负载的结论。

PLC 扫描周期是一种确定性的执行模型，其中物理 I/O 更新与逻辑评估是分离的。这种分离是核心问题所在。

在 IEC 61131-3 编程模型下，梯形图逻辑按可重复的顺序进行评估。确切的时序因控制器和任务配置而异，但核心模式在操作上足够稳定：

• 读取输入：控制器将物理输入状态复制到内存中。
• 执行逻辑：梯级按顺序求解，通常是从上到下、从左到右。
• 写入输出：最终的内存映像被推送到物理输出端子。

重要的区别很简单：内部状态可能会在逻辑执行期间发生变化，但物理输出通常在执行完成后才更新。如果两个梯级向同一个输出位写入数据，则后一个梯级在该扫描周期中胜出。

3 阶段执行顺序并非风格偏好

扫描周期不仅仅是一个教学模型。它是确定性控制行为、故障排除和调试判断的基础。

这一点很重要，因为通用大语言模型（LLM）主要是在异步或事件驱动的软件模式上训练的。在这些环境中，一条语句通常意味着立即生效，回调函数可能独立触发，并发错误源于线程、任务或进程之间的时序交互。而在普通的单任务情况下，PLC 梯形图逻辑通常并非如此工作。

为何通用 AI 默认采用错误的思维模型

通用 AI 助手倾向于将梯形图指令视为事件处理程序。它们推断：如果该条件变为真，则立即激励该输出。这是一种应用于 OT（运营技术）机器的 IT 思维假设。

在 PLC 中，输出线圈最好理解为对内存位置的写入，该位置稍后将参与输出映像更新。一旦忽略了这种区别，重复线圈对模型来说可能看起来无害。但它们并非无害，而是延迟的矛盾。

不是。在标准的 PLC 梯形图执行中，“双线圈综合征”通常是确定性的覆盖，而非竞态条件。

IT 中的竞态条件是指并发操作之间的时间依赖性故障，其结果取决于哪个线程或进程先达到共享状态。该定义在软件工程中很有用，但在控制领域常被误用。

典型 PLC 扫描中的双线圈故障则不同：

• 控制器按定义的顺序执行。
• 同一个寻址位被写入多次。
• 执行顺序中的最后一次写入决定了该扫描周期的最终状态。
• 除非任务调度、跳转或异步服务使程序结构复杂化，否则结果是可重复的。

正确的对比是“覆盖”与“并发”

在审查 AI 生成的梯形图逻辑时，请使用以下区别：

• IT 竞态条件：并发操作之间的时序异常
• OT 覆盖故障：确定性的“最后梯级胜出”状态解析

这种区别很重要，因为修复方法不同。确定性覆盖故障应通过整合输出权限来解决，而不是应用线程安全概念。

“双线圈综合征”表现为可见逻辑条件与实际机器行为之间的不匹配。程序的一部分看起来正确，而设备却在执行其他操作。

常见症状包括：

• “死”梯级：某个梯级为真、高亮显示，且显然正在指令电机或阀门动作，但设备未动作，因为后续梯级将同一个输出写为假。
• 逻辑与设备之间的状态分歧：HMI 命令被接受，内部允许条件看起来已满足，但扫描解析后物理输出仍保持关闭。
• 间歇性抖动或卡顿：在涉及跳转、顺序器或管理不善的中间位的复杂结构中，重复覆盖可能导致设备行为不稳定或继电器磨损。
• 调试困惑：技术人员验证了现场接线、I/O 卡和接触器路径，但负载仍拒绝一致响应。故障在于状态所有权，而非硬件连接。

为何这在调试阶段比在编码阶段更重要

调试会迅速暴露状态冲突，因为过程会给出反馈。代码审查中的重复线圈是一种糟糕的模式。而带电泵允许回路上的重复线圈可能导致错误的“无法启动”、滋扰性跳闸，或在排查面板故障时浪费整个班次。

这就是为什么语法正确与可部署性不是一回事。

AI 生成的双线圈错误通常源于局部模式补全，而非全程序状态设计。模型看到了两个应该激励同一个执行器的合法条件，并输出了两个独立的输出线圈，而不是一个整合的命令路径。

典型原因包括：

• 按条件生成代码：模型为每个需求编写一个梯级，而没有协调共享输出的所有权。
• 扫描周期意识薄弱：模型无法可靠地推断延迟输出更新。
• 将 IT 习惯用语引入 OT 逻辑：它将输出视为立即动作，而非内存支持的状态赋值。
• 命令位与物理输出区分不清：AI 经常直接写入硬件输出，而人类工程师通常会先构建一个内部命令位，然后在一个地方应用联锁和最终输出映射。

更深层的问题是架构性的，而非语法性的

梯形图看起来语法有效，但在操作上可能是错误的。AI 通常擅长指令词汇，但在权限结构上较弱。

一个有用的审查问题是：谁拥有这个输出位？如果答案是多个梯级，那么根据提示的要求，程序已经开始偏离正轨。

正确的修复方法是确保每个物理输出都有一个单一的、明确的状态解析点，或者在行为合理且可审查的情况下，使用明确管理的置位/复位（Latch/Unlatch）模式。

模式 1：将条件整合到一个输出梯级中

这是最简单且通常也是最好的修正方法。

AI 错误：重复输出线圈

梯级 1： [ Sensor_A ] --------------------( Motor_Run ) 梯级 2： [ Sensor_B ] --------------------( Motor_Run ) // 覆盖梯级 1

人工修复：并联分支到一个输出线圈

梯级 1： [ Sensor_A ] --+-----------------( Motor_Run ) | [ Sensor_B ] --+

这保留了 `Motor_Run` 的单一权限点。多个有效的启动条件在写入发生前被合并。

模式 2：使用内部命令位，然后映射到输出一次

这种模式在实际项目中通常更整洁，因为它将过程逻辑与硬件驱动分离开来。

梯级 1： [ Sensor_A ] --+-----------------( Motor_Run_Cmd ) | [ Sensor_B ] --+

梯级 2： [ Motor_Run_Cmd ] [ All_Permissives_OK ] ----( Motor_Run_Output )

这种结构提高了可审查性和故障追踪能力：

• 命令意图清晰可见，
• 联锁集中化，
• 物理输出映射唯一，
• 仿真更容易解释。

模式 3：仅在状态模型需要时使用置位/复位

当过程需要保持命令状态、顺序存储或操作员确认行为时，`OTL/OTU` 对或等效的置位/复位结构可能是正确的。它不是针对糟糕梯级结构的通用补丁。

仅在能回答以下所有问题时使用置位/复位：

• 什么事件设置状态？
• 什么事件清除它？
• 什么异常条件必须强制复位？
• 保持的状态在启动和重启期间将如何验证？

如果这些答案模糊不清，那么使用锁存器可能是不合理的。

最快的诊断方法是追踪一个完整扫描周期内的输出权限，并验证最终位状态是否与之前的梯级指示相符。

请按以下顺序操作：

1. 查找对该输出位的所有写入。搜索程序中该线圈地址或映射标签的所有实例。
2. 确定梯级顺序。确定哪个写入在相关任务或例程中最后执行。
3. 检查输出是物理的还是内部的。对内部位的重复写入同样危险，但对物理输出的重复写入通常更紧急。
4. 测试真/假组合。强制或模拟每个输入条件，观察之前的“真”逻辑是否在后续被否定。
5. 验证最终输出映像行为。不要停留在梯级高亮显示上。确认逻辑执行后的解析标签状态。
6. 重构为单一权限点。合并分支、使用命令位或重新设计顺序所有权。

记录什么作为工程证据

如果您正在审查生成的逻辑，请构建一个紧凑的证据集，而不是截图库。实用的结构是：

1. 系统描述
2. 正确行为的操作定义
3. 梯形图逻辑和仿真设备状态
4. 注入的故障案例
5. 所做的修订
6. 经验教训

这种格式展示的是推理过程，而不仅仅是工具使用。

OLLA Lab 在此处可用作诊断沙箱，因为它允许工程师在不涉及任何实际硬件的情况下观察梯形图状态、I/O 行为和仿真设备响应。

在仿真模式下，您可以运行逻辑、切换输入，并实时观察输出和变量的变化。在变量面板中，您可以在逻辑执行时检查标签状态、I/O 值、模拟行为和场景条件。这种可见性正是暴露双线圈故障的关键：一个梯级可能看起来有效，但最终的位状态显示了后续的覆盖。

在此背景下“仿真就绪”意味着什么

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

在操作上，这包括以下能力：

• 通过扫描周期追踪因果关系，
• 将梯形图状态与仿真设备状态进行比较，
• 测试异常条件和允许条件失效，
• 在故障后修改逻辑，
• 验证最终输出权限是单一且有意的。

该定义比单纯了解梯形图语法更狭窄，也比仅依赖信心更有用。

OLLA Lab 双线圈诊断的实用工作流

按以下方式使用 OLLA Lab：

1. 在编辑器中加载或构建梯形图逻辑。
2. 进入仿真模式。
3. 逐个或组合切换相关输入。
4. 在变量面板中观察寻址的输出标签。
5. 比较梯级真值与最终标签状态。
6. 观察仿真机器行为与解析后的输出是否一致。
7. 将逻辑重构为单一输出权限路径。
8. 重新测试相同的故障案例并记录修正结果。

OLLA Lab 不会自动修复程序。它提供了一个受控场所，在涉及真实的执行器、泵、传送带或阀门之前捕获状态分歧。

Yaga 的适用范围与局限

GeniAI（OLLA Lab 的 AI 实验室指南）可以在平台内支持入门引导、纠正性指导和梯形图逻辑辅助。在此背景下，其价值是有限的：它可以帮助引导学习者关注可审查的逻辑问题和平台特定的验证步骤。

它不应被视为工程判断、功能审查或现场特定批准的替代品。通用 AI 可以生成故障；在受限验证环境中的引导式 AI 可以帮助发现它。这两者不是一回事。

数字孪生验证之所以重要，是因为扫描周期故障不仅仅是符号错误；它们造成了预期控制状态与观察到的机器行为之间的不匹配。

当梯形图逻辑针对真实的机器模型或过程场景进行测试时，工程师可以比较：

• 指令状态，
• 实际仿真设备响应，
• 报警和允许条件行为，
• 异常输入下的故障处理。

这是从代码正确性到调试判断的实用桥梁。一个梯级可以是合法的，但对过程而言可能是错误的。数字孪生验证有助于在现场测试之前暴露这种差异。

这与更广泛的工程文献基础相一致，即仿真和数字孪生辅助验证可以在使用明确的模型边界和真实的测试案例时，提高故障发现、操作员理解和预调试验证的水平。文献并不支持广泛的结论，但它支持一个较窄的命题：当失效模式依赖于动态系统行为而非仅仅是静态语法时，真实的仿真是有效的。

工程师在考虑部署 AI 生成的梯形图逻辑之前，应审查其状态所有权、扫描顺序效应、允许条件结构和故障行为。

实用的审查清单：

• 每个物理输出是否有明确的权限点？
• 命令位是否在适当的情况下与硬件输出分离？
• 联锁和跳闸是否集中且可审查？
• 逻辑在整个扫描周期内表现是否正确，而不仅仅是在一个梯级上？
• 异常条件是否可以安全地模拟和观察？
• 正确行为是否以过程术语定义，而不仅仅是代码术语？

最后一点常被忽视。“梯级变为真”并不是成功的操作定义。“泵仅在允许条件满足时启动，在跳闸时停止，在验证失败时报警，并在重启期间保持稳定”才更接近。

“双线圈综合征”是一种确定性的 PLC 状态覆盖故障，通常不是竞态条件。通用 AI 倾向于产生此类问题，因为它在完成局部逻辑模式时，没有可靠地建模扫描周期状态解析和延迟输出更新。

修复方法在原则上很简单，在实践中需要纪律：整合输出权限，验证最终标签状态，并在调试前针对真实的机器行为测试逻辑。OLLA Lab 作为基于 Web 的梯形图逻辑和数字孪生仿真器，非常适合这一工作流，工程师可以在其中安全地观察、诊断并修正这些故障。这是仿真环境的可靠角色，也是将看似合理的代码与能够经受过程考验的逻辑区分开来的实用方法。

- IEC 61131-3: 可编程控制器 — 第 3 部分：编程语言 - IEC 61508 功能安全标准系列 - NIST AI 风险管理框架 (AI RMF 1.0) - 欧盟工业 5.0 政策背景 - 数字孪生概述 (NIST)

本文由 OLLA Lab 工业自动化工程团队编写，专注于 PLC 逻辑验证、数字孪生仿真及 AI 在工业控制系统中的安全应用。

本文所述的“双线圈综合征”及其在 PLC 扫描周期中的确定性覆盖行为，已通过 Ampergon Vallis Lab 的仿真基准测试验证。文中关于 AI 生成代码的局限性分析基于 2026 年第一季度的内部测试数据。