如何用 PLC 状态机取代脆弱的“洋葱式逻辑”

为了取代 PLC 程序中脆弱的“洋葱逻辑”，工程师应使用显式有限状态机。状态机架构可以减少扫描顺序的歧义，隔离故障处理，并使异常情况的测试在逻辑进入实际生产流程之前即可在仿真中被观察到。

一个常见的误区是：当梯形图变得密集时，它就变得“高级”了。实际上，这种密集往往只是戴着安全帽的歧义。机器故障并非因为梯形图看起来复杂，而是因为当真实的输入信号在错误的时间点发生变化时，程序序列缺乏确定性。

在 OLLA Lab 最近对 200 个用户提交的混合序列练习进行的内部基准测试中，82% 深度嵌套的“洋葱逻辑”程序在遭遇 100 毫秒的间歇性传感器丢失事件时，进入了无法恢复的序列锁定状态；而重构后的显式状态版本在 100% 的相同场景测试中均实现了确定性恢复 [方法论：n=200 个提交的混合序列任务，比较对象 = 原始嵌套锁存实现与重构后的显式状态实现，时间窗口 = Ampergon Vallis Lab 内部评审周期，于 2026 年第一季度完成]。该内部基准测试支持一个狭义的架构观点：在测试条件下，显式状态模型具有更好的故障恢复能力。它并不支持关于所有 PLC 代码、所有行业或操作员能力的广泛主张。

实际的区别很简单：语法不等于可部署性。一个在理想路径下运行良好，但在闪烁的许可信号下就会冻结的程序，无论梯形图看起来多么整洁，都尚未达到调试标准。

洋葱逻辑是一种梯形图反模式，在这种模式下，机器行为通过层层相互依赖的布尔值、分散的锁存器和嵌套的许可条件来控制，其组合执行路径在异常情况下极难推断。

这个名称虽然非正式，但其故障模式却是真实的。每一个新的条件都包裹在前一个条件之上，直到序列变得依赖于梯形图顺序、锁存历史和瞬态输入之间的隐藏交互。它通常在演示时运行良好，但在调试时却不那么“客气”。

洋葱逻辑的 3 个症状

序列进度依赖于分布在多个梯级中的多个 `(S)/(R)` 或 `(OTL)/(OTU)` 指令，且通常缺乏单一的权威机器状态源。

• 相互依赖的锁存器

程序行为取决于梯级顺序、单次扫描时序，或者许可条件是在解锁条件评估之前还是之后消失。

• 扫描周期脆弱性

当每个传感器都表现良好时，序列运行正确；但一旦出现中途打断，就会发生卡死、半锁存或需要手动复位的情况。

• 理想路径偏差

为什么洋葱逻辑会变得脆弱

洋葱逻辑增加了有效的圈复杂度（cyclomatic complexity）。简单来说，可能执行路径的数量增长速度超过了初级工程师在故障条件下可靠追踪的能力，尤其是当多个布尔值可能在之前的扫描中保持为真时。

这一点很重要，因为 PLC 故障排除不是在真空中进行的。它通常发生在输送机停止、泵不可用或批处理步骤正在等待一个“理应为真”的许可信号时。“理应”不是一种诊断方法。

显式状态机能提供更好的故障恢复能力，因为它们使机器意图变得单一、可观察且具有确定性。在任何给定时间，机器都处于一个定义明确的状态，且只有在满足显式条件时才会发生转换。

这是至关重要的架构差异。洋葱逻辑问的是：“当前哪一组位暗示了我所处的位置？”而状态机问的是：“我处于什么状态，什么条件允许进入下一个状态？”后一个问题在凌晨 3 点时要容易回答得多。

操作定义：梯形图中的显式状态机是什么？

显式状态机是一种控制架构，其中：

• 机器的序列状态由一个单一的权威状态变量（通常是整数）表示；
• 每个状态与其他状态互斥；
• 转换由可观察的条件显式定义；
• 异常条件将机器引导至定义的故障或保持状态；
• 物理输出由活动状态导出，而不是分散在不相关的序列梯级中。

一个简单的例子可能使用：

• `0 = 空闲 (Idle)`
• `10 = 启动中 (Starting)`
• `20 = 运行中 (Running)`
• `30 = 停止中 (Stopping)`
• `99 = 故障 (Fault)`

这种方法符合 IEC 61131-3 下已建立的软件结构原则，该标准支持结构化的程序组织、清晰的执行行为和可维护的控制逻辑。该标准并未为每台机器规定一种通用的序列模式，但对显式、可读架构的偏好是毋庸置疑的。

显式状态与洋葱逻辑对比

| 工程维度 | 显式状态机 | 洋葱逻辑 | |---|---|---| | 状态表示 | 一个权威状态变量，通常基于整数 | 许多重叠的布尔值和锁存器 | | 序列可见性 | 当前机器阶段可直接观察 | 必须推断序列位置 | | 故障处理 | 显式跳转到定义的故障或保持状态 | 故障恢复取决于解锁正确的条件 | | 输出映射 | 输出在专用例程中根据活动状态导出 | 输出通常分散在序列梯级中 | | 故障排除 | 问：“为什么状态 X 没有转换到 Y？” | 问：“哪个位未能置位或复位？” | | 扫描顺序敏感性 | 当转换被清晰分区时降低 | 通常对梯级顺序高度敏感 | | 可维护性 | 更易于审查、测试和修改 | 随着条件累积迅速退化 |

洋葱逻辑在真实的扫描周期行为下会失效，因为 PLC 不会评估意图；它们按顺序评估指令，每次扫描一个，并使用内存和输入的当前状态。

这听起来很明显，但许多序列错误仅仅是因为对这一事实的认识滞后。传感器可能会丢失 50 毫秒。反馈信号可能会比预期晚一个扫描周期到达。锁存器可能会保持置位，因为在发生的精确事件序列下，解锁梯级从未被置为真。

典型的故障机制

转换位在相邻逻辑中置位和复位，使下游序列逻辑处于不确定状态。

• 单扫描竞争

序列步骤保持为真，因为复位路径依赖于在故障期间消失的许可条件。

• 锁存内存持久性

为了可读性移动一个梯级会改变行为，因为逻辑依赖于隐式执行顺序而非显式状态转换。

• 梯级顺序依赖

嘈杂或短暂丢失的现场信号导致机器部分前进，然后失去了继续运行或恢复所需的条件。

• 传感器抖动或间歇性丢失

这些不是罕见的边缘情况，而是工厂车间常见的事件。硬件没有义务去迎合你的序列设计。

在梯形图中构建有限状态机的方法是将状态转换逻辑与输出动作逻辑分离。转换例程决定机器何时改变状态，输出例程决定机器在处于该状态时做什么。

这种分离是核心准则。如果转换和输出在各处混合，架构就会漂移回洋葱逻辑。

第 1 步：定义机器状态

首先分配互斥的状态值。

• `0 = 空闲`
• `10 = 启动请求`
• `20 = 启动中`
• `30 = 运行中`
• `40 = 停止中`
• `99 = 故障`

使用留有插入空间的编号。那些将每个状态编号为 1、2、3 的工程师通常最终会遇到状态 2.5 的需求。

第 2 步：定义转换条件

每个转换都应回答一个狭窄的问题：

• 什么条件允许进入下一个状态？
• 什么条件阻碍了进度？
• 什么条件强制进入故障或保持状态？
• 什么条件允许复位或恢复？

转换应该是显式的且可测试的。避免对不相关梯级的副作用产生隐藏依赖。

第 3 步：优先编写转换逻辑

以下是一个紧凑的梯形图风格转换逻辑示例：

语言：梯形图 - 状态转换逻辑

梯级 1：空闲 (0) -> 启动中 (10) EQU(Machine_State, 0) --- XIC(Start_PB) --- XIC(System_Ready) --- MOV(10, Machine_State)

梯级 2：启动中 (10) -> 运行中 (20) EQU(Machine_State, 10) --- XIC(Motor_Run_Fdbk) --- MOV(20, Machine_State)

梯级 3：任何活动状态 -> 跳闸时故障 (99) NEQ(Machine_State, 0) --- XIC(Trip_Active) --- MOV(99, Machine_State)

梯级 4：故障 (99) -> 复位及安全条件满足后空闲 (0) EQU(Machine_State, 99) --- XIC(Reset_PB) --- XIO(Trip_Active) --- XIC(System_Ready) --- MOV(0, Machine_State)

重点不在于确切的语法，而在于当前状态和转换条件是可见的、单一的且可审查的。

第 4 步：根据状态而非序列片段映射输出

应使用单独的例程根据活动状态导出输出。

例如：

• 如果 `Machine_State = 20`，命令 `Motor_Run = 1`
• 如果 `Machine_State = 40`，命令 `Motor_Run = 0`
• 如果 `Machine_State = 99`，切断非安全输出并断言故障指示

这减少了分散的输出线圈，并使机器行为更易于审计。

第 5 步：审慎定义故障行为

故障状态不应是一个模糊的“出错了”的容器。它应该定义：

• 哪些输出断电，
• 哪些报警被触发，
• 重启是自动还是手动的，
• 需要什么复位条件，
• 以及操作员或工程师可以观察到什么证据。

确定性在出错时最为重要。正常运行往往会掩盖薄弱的架构。

“仿真就绪”意味着工程师可以在逻辑进入实际生产流程之前，在一个风险受控的环境中证明、观察、诊断并强化控制逻辑以应对真实的工艺行为。

这是一个操作定义，而非赞美。它并不意味着“熟悉梯形图语法”、“准备好进行无人监督的调试”或“自动具备就业能力”。它意味着工程师能够让序列经受异常条件的考验，检查结果行为，并根据证据修改逻辑。

仿真就绪工程师的可观察行为

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

• 强制并监控离散和模拟量 I/O；
• 将预期的序列行为与观察到的机器响应进行比较；
• 注入故障，例如间歇性传感器丢失或反馈缺失；
• 验证逻辑是否转换到安全、定义明确的状态；
• 修改转换许可条件或故障处理；
• 重新运行场景并证明确定性行为得到改善。

这就是编写代码与验证控制行为之间的区别。这种差距代价高昂。

OLLA Lab 通过为工程师提供基于浏览器的梯形图环境、仿真控制、可见变量和 I/O，以及基于场景的数字孪生，允许在没有实际设备风险的情况下进行故障注入，从而模拟状态转换故障。

这就是该产品在操作层面变得有用的地方。其价值不在于它能在浏览器中绘制梯形图（许多工具都能做到），而在于逻辑可以针对模拟的设备行为和异常条件在受控环境中进行演练。

OLLA Lab 用于状态机验证的相关功能

工程师可以使用触点、线圈、定时器、计数器、比较器、数学运算、逻辑和 PID 相关指令构建状态转换。

• 基于 Web 的梯形图编辑器

逻辑可以在没有物理硬件的情况下运行、停止和观察。

• 仿真模式

标签、输入、输出、模拟值和状态变量可以直接监控和调整。

• 变量面板和 I/O 可见性

梯形图逻辑可以在真实的机器或工艺背景下与模拟的设备行为进行对比。

• 3D / WebXR / VR 仿真

工程师可以在进行任何现场部署讨论之前，测试序列逻辑是否产生预期的设备行为。

• 数字孪生验证工作流

涵盖制造、水处理、暖通空调、化工、制药、仓储、食品饮料和公用事业等领域的 50 多个命名预设，提供了特定于上下文的序列、危险和联锁。

• 基于场景的工业预设

一个实用的 OLLA Lab 测试案例

在输送机卡死场景中，工程师可以：

1. 设置 `Machine_State = 20` 以表示运行；
2. 观察数字孪生输送机的运行；
3. 使用变量面板在序列中途丢弃一个许可或反馈输入；
4. 验证状态是转换到 `99 = 故障` 还是挂起在不一致的状态；
5. 修改转换逻辑；
6. 重新运行场景以确认确定性恢复。

这是一个可靠的演练任务，因为它反映了一个真实的调试问题：当机器没有获得原始作者假设的干净信号序列时，会发生什么？

工程师应将状态机技能记录为紧凑的工程证据集，而不是截图库。

截图只能证明屏幕存在，不能证明逻辑是正确的、经过测试的，或在失败后经过了修改。

所需的证据结构

使用以下六部分结构：

1. 系统描述 定义机器或工艺、其目的及其序列边界。
2. “正确”的操作定义 用可观察的术语说明成功行为的含义：启动条件、输出、转换、报警、安全停止行为和复位要求。
3. 梯形图逻辑和模拟设备状态 展示状态架构、关键标签以及相应的模拟设备响应。
4. 注入的故障案例 识别引入的异常条件：传感器丢失、反馈失败、模拟量超限、超时、卡死、急停链中断等。
5. 所做的修改 记录确切的逻辑变更：增加超时、修改许可、显式故障转换、去抖动处理、输出重映射或复位条件。
6. 经验教训 解释故障揭示了关于原始架构的什么信息，以及为什么修改提高了确定性或可恢复性。

这种结构很有用，因为它使工程推理变得可审查。雇主和高级评审员不需要精美界面的作品集，他们需要的是你能思考故障的证据。

显式状态架构受到已建立的控制软件和安全工程原则的间接支持，即使标准并未规定某种确切的梯形图模式。

相关标准和技术基础

支持工业控制软件的结构化编程方法，以及逻辑、功能和执行行为的清晰组织。

• IEC 61131-3

强调系统完整性、故障响应以及在安全相关系统中减少危险设计歧义的重要性。

• IEC 61508

强化了控制系统设计中对确定性行为、可追溯性和可测试故障处理的需求。

• exida 指南和功能安全实践

近期的工业文献一致支持将仿真作为验证行为、降低调试风险和在部署前暴露序列故障的手段，同时也警告称仿真质量取决于模型保真度和测试设计。

• 数字孪生和仿真文献

工程培训环境的研究表明，交互式仿真可以提高程序理解和故障识别能力，特别是当学习者可以测试因果关系而不仅仅是阅读静态示例时。

• 沉浸式和交互式培训文献

结论很明确：仿真不能取代现场经验，但它是一个可辩护的场所，用于演练在实际生产流程中不安全、昂贵或不切实际的故障逻辑。

状态机不是魔法。它们仍然可能设计不佳、过度复杂，或者在实施时对安全状态行为、模式处理或操作员恢复关注不足。

常见的状态机错误

• 状态过多且缺乏清晰的层次结构；
• 模式、状态和故障之间的区别不明确；
• 由嘈杂信号触发且没有去抖动或验证的转换；
• 未定义输出行为的故障状态；
• 允许不安全或意外重启的恢复路径；
• 悄悄重新引入分散依赖的输出逻辑。

糟糕的状态机仍然比糟糕的洋葱逻辑更容易诊断，但这并不意味着它就是好的。架构可以提高你的胜算，但不能取代工程准则。

实用的建议是：当序列清晰度、故障恢复和调试可见性很重要时，显式状态机通常是更好的架构。

如果机器具有多个阶段、联锁、异常条件或恢复要求，单一的权威状态模型在可维护性和可诊断性方面通常会优于分层锁存逻辑。对于需要在压力下进行逻辑推理的初级和中级工程师来说，这一点尤为重要。

OLLA Lab 作为一种受限的验证环境融入了这一工作流。它允许工程师构建梯形图、观察 I/O、将状态与模拟设备行为进行比较、注入故障并在存在任何实际部署环境之前修改序列。这是一个严肃的用例，无需花哨的包装。

• 掌握状态架构是我们“梯形图逻辑精通中心 (Ladder Logic Mastery Hub)”的核心能力。
• 如需深入了解锁存行为，请参阅“自保持 (Seal-In)”与“锁存 (Latch)：为什么专业工程师会谨慎选择”。
• 要查看此架构在连续工艺中的应用，请跟随“分步构建：自动化混合器状态机”。
• 停止猜测你的逻辑将如何处理传感器故障。在 OLLA Lab 中打开“输送机卡死场景”。

• 向上 (Pillar Hub)： 探索 Pillar 指南
• 横向： 相关文章 1
• 横向： 相关文章 2
• 向下 (商业/CTA)： 在 OLLA Lab 构建你的下一个项目

- IEC 61131-3 编程语言 - Kritzinger 等人 (2018) 制造业中的数字孪生 - Tao 等人 (2019) 工业中的数字孪生 - IEC 61508 功能安全标准系列