工业自动化中的 AI

文章指南

如何在 PLC 安全逻辑中选择自保持(Seal-In)与锁存(Latch)逻辑

自保持逻辑和锁存逻辑都能保持输出接通,但在扫描中断、断电和重启期间的行为截然不同。本文解释了二者的区别,以及如何在 OLLA Lab 中验证重启行为。

直接回答

在 PLC 逻辑中选择自保持电路还是锁存指令时,应首先评估断电恢复情况。自保持电路在断电或梯级导通中断时会丢失状态,这有助于防止意外重启。锁存指令则会保持状态直到被明确清除,因此需要周密的复位策略和验证。

本文回答的问题

文章摘要

在 PLC 逻辑中选择自保持电路还是锁存指令时,应首先评估断电恢复情况。自保持电路在断电或梯级导通中断时会丢失状态,这有助于防止意外重启。锁存指令则会保持状态直到被明确清除,因此需要周密的复位策略和验证。

一个常见的误区是认为自保持逻辑和锁存逻辑可以互换,因为两者都能保持输出接通。但在涉及重启行为的场景中,它们并不可互换。真正的区别在于扫描中断、断电和重启过程中的内存保持特性。

Ampergon Vallis 指标: 在对 OLLA Lab 仿真练习中 500 个用户自编电机控制程序进行的内部审查中,68% 使用了保持性锁存模式的程序未包含完整的首次扫描复位或等效的重启清除程序。方法论: 样本量 = 500 个用户生成的电机控制练习;任务定义 = 在模拟断电测试期间审查保持性输出/状态处理;基准比较器 = 是否存在明确的重启清除逻辑;时间窗口 = 2026 年 1 月 1 日至 2026 年 3 月 15 日。这仅支持一个狭窄的观点:初级逻辑中往往对重启处理的定义不足。它并不支持任何关于行业整体编程质量的更广泛主张。

自保持逻辑与锁存逻辑的根本区别是什么?

根本区别在于状态保持(State Retention)

自保持电路(Seal-in circuit)通过在梯级中反馈一条非保持性的确认路径来保持输出接通,通常使用标准的输出指令(如 OTE)并在启动条件周围并联一个分支。如果梯级变为假(False),控制器内存会在下一次扫描时清除该输出。如果断电,除非在其他地方添加了单独的保持处理,否则输出不会记住之前的真(True)状态。

锁存指令(Latch instruction)(如 OTL/OTU 或特定平台的 SET/RESET)会存储一个位,直到明确的解锁或复位指令将其清除。该存储状态可以在扫描中断中存活,并且根据控制器内存配置和平台行为,可能会作为保持状态在断电重启后存活。

一言以蔽之:自保持逻辑依赖于当前条件;锁存逻辑依赖于存储的历史。

自保持与锁存执行矩阵

| 属性 | 自保持电路 | 锁存逻辑 | |---|---|---| | 典型指令模式 | OTE 配合并联保持分支 | OTL/OTU 或 SET/RESET | | 状态来源 | 当前梯级导通性 | 已存储的位状态 | | 扫描周期行为 | 必须通过有效的梯级路径保持为真 | 在触发条件消失后仍可保持为真 | | 断电行为 | 通常在断电或重启时掉电 | 若为保持性且未明确复位,则可能保持置位 | | 复位方法 | 梯级假条件、停止条件、允许信号丢失 | 明确的解锁或复位指令 | | 最佳用例 | 电机运行指令、自保持命令路径、对重启敏感的输出 | 报警捕获、状态内存、明确的顺序控制、已确认事件 | | 主要风险 | 允许信号设计不完整 | 陷阱状态,若复位策略薄弱会导致意外重启 |

IEC 61131-3 在此有何帮助?

IEC 61131-3 标准化了 PLC 编程语言和指令概念,但它并未消除明确定义内存行为的必要性。实际工程中的区别仍然在于实现方式是保持性(Retentive)还是非保持性(Non-retentive),以及在启动、停机和故障恢复期间如何处理这些行为。

换句话说,语法不是难点,启动行为才是。

NFPA 79 如何影响自保持与锁存逻辑的选择?

NFPA 79 将重启行为视为安全问题,而非风格偏好。

相关的设计原则很简单:如果重启可能造成危险情况,则机器在恢复供电时不得自动重启。ISO 13849-1 通过预防危险的机器行为以及对复位、联锁和控制系统响应的妥善处理,与这一更广泛的安全逻辑保持一致。

这就是为什么传统的 3 线电机控制模式依然经久不衰的原因。启动按钮使命令得电,停止设备断开它,断电则使运行命令掉电。当电力恢复时,机器保持停止状态,直到发出明确的重启命令。

为什么自保持梯级自然符合防止重启的要求?

自保持梯级通常反映了 3 线控制电路的操作逻辑:

  • 启动(Start)条件瞬间变为真
  • 并联的保持触点在启动信号释放后保持梯级为真
  • 停止(Stop)、故障或允许信号丢失会断开梯级
  • 控制器断电会清除激活的输出状态
  • 重启时,输出保持断开,直到再次发出命令

这种行为并非在所有情况下都自动安全,但通常更容易进行逻辑推理,也更容易验证其是否符合防止重启的要求。

为什么锁存逻辑需要更谨慎的安全设计?

锁存可以绕过命令路径的自然掉电行为。

如果运行位被锁存且不存在启动清除逻辑,控制器在断电重启后该位可能仍为真。如果下游的允许条件也满足,机器可能会在没有操作员发出新命令的情况下恢复运动。这正是防止重启规则旨在阻止的行为。

在对重启敏感的功能中使用锁存逻辑时,工程师通常需要:

  • 首次扫描复位(First-scan reset)或启动清除程序
  • 命令内存输出通电明确分离
  • 在任何输出重新通电前,重新验证所有允许条件
  • 复位行为必须符合机器风险评估

锁存逻辑本身没有错,未经审视的锁存逻辑才有错。

为什么锁存指令会在扫描中断期间产生陷阱状态?

锁存指令会产生陷阱状态,因为它们不需要原始的使能条件保持为真。

一旦锁存位被置位,它就会保持置位,直到执行解锁操作。如果本应清除它的顺序从未完成,该位就会保持高电平。这种情况可能发生在:

  • 在 OTU 或复位梯级被扫描前断电
  • 顺序执行中途从自动模式切换到手动模式
  • 紧急停止恢复时状态清除不完整
  • 跳过正常顺序退出路径的故障中止
  • 调试期间的部分下载或测试编辑
  • 操作员导航重置了顺序的一部分,但未重置保持状态

这就是为什么初级代码往往在“理想路径”演示中有效,但在异常恢复时失败的原因之一。

什么是实际意义上的陷阱状态?

陷阱状态(Trapped state)是指在证明其合理性的过程上下文消失后,仍然保持为真的已保留命令或顺序位。

示例包括:

  • 在模拟断电循环后依然存在的传送带运行请求
  • HOA 模式切换后依然保持的泵运行命令
  • 故障中止后依然激活的顺序步进位
  • 重启后因复位路径是条件性的且从未被扫描,而重新出现的故障执行器命令

工程问题不在于该位被保留,而在于保留的状态对于当前的工厂状况已不再有效。

锁存指令何时适用?

当保留内存是有意为之、有界限且经过审慎复位时,锁存指令是适用的。

安全且常见的用例包括:

  • 报警捕获: 保持瞬态故障直到操作员确认
  • 配方或批次状态保持: 在计划停顿期间保留受控的过程上下文
  • 明确的状态机: 管理步进状态内存,且启动和中止处理已完全定义
  • 维护事件: 记录需要服务的状况,直到经过审查和复位

模式很简单:使用锁存是为了记忆,而不是为了假装命令路径依然存在。

PLC 工程师应如何决定使用 OTE 还是 OTL/OTU?

对于在命令连续性、允许条件或电源丢失时必须掉电的输出,请选择 基于 OTE 的自保持逻辑

仅在操作上必须保留状态,且启动清除、中止清除和故障恢复行为经过明确设计和测试时,才选择 OTL/OTU 式的锁存逻辑

一个实用的决策规则是:

  • 如果该位代表当前的运行授权,优先选择非保持性模式
  • 如果该位代表已记住的历史或已确认的状态,则保持性模式可能是合理的
  • 如果重启后可能恢复危险运动,则在证明安全之前,将保持性逻辑视为可疑

一个简明的工程测试

问一个问题:如果电源在最糟糕的时刻消失,当控制器恢复时,我希望确切的位状态是什么?

如果答案是“在重新发出命令前保持关闭”,那么自保持模式通常是更清晰的起点。

如果答案是“记住这个状态,但在启动逻辑验证条件之前不要给任何东西通电”,那么锁存可能是可以接受的,前提是这种分离实现得当。

“仿真就绪(Simulation-Ready)”对于自保持与锁存验证意味着什么?

仿真就绪意味着工程师可以在逻辑进入实际生产过程之前,证明、观察、诊断并强化重启行为。

对于本文,该术语的定义是操作性的。当工程师能够做到以下几点时,即为仿真就绪:

  • 在梯形图中追踪从输入到输出的因果路径
  • 诱发模拟断电事件
  • 观察哪些位、输出和过程状态掉电或保持
  • 验证危险运动或过程动作不会在重启时意外恢复
  • 修改逻辑并重新测试,直到重启行为是确定性的且有据可查

这与“我能写梯形图语法”有着本质的区别。

满足定义的观察行为

重启验证练习只有在工程师能够展示以下内容时才是仿真就绪的:

  1. 哪些标签是非保持性的,哪些是保持性
  2. 机器或过程模型在断电期间的表现
  3. 重启后在任何操作员动作之前的表现
  4. 过程变量 (PV)、执行器状态或运动命令是否恢复到危险状态
  5. 为防止该结果采取了什么逻辑修订

这里的标准是证据,而不是信心。

如何在 OLLA Lab 中模拟断电循环行为?

在任何人尝试在机器上进行测试之前,应先在仿真中测试断电循环行为。

OLLA Lab 在此作为有界验证环境非常有用。它允许工程师构建梯形图逻辑,在仿真中运行,检查变量和 I/O 状态,并将梯形图状态行为与模拟的机器或过程上下文进行比较。

OLLA Lab 重启验证的实用工作流

使用此顺序:

  • 版本 A:使用非保持性输出模式的标准自保持梯级
  • 版本 B:针对同一命令的保持性锁存或解锁模式
  • 启动命令
  • 停止命令
  • 运行允许信号
  • 电机运行输出
  • 锁存运行请求位
  • 故障位
  • 任何相关的模拟量 PV 或反馈
  • 启动机器或模拟单元
  • 确认预期的输出通电
  • 确认反馈和状态标签
  • 在仿真工作流中切换相关的总电源或控制器状态
  • 如果场景需要,停止逻辑执行
  • 观察哪些位被清除,哪些位保持置位
  • 不要发出新的启动命令
  • 观察重启后立即的输出状态、顺序状态和过程状态
  • 输出是否保持断电?
  • 是否有任何保留位重新断言了命令?
  • 模拟设备是否恢复了运动或过程动作?
  • 在需要的地方添加首次扫描解锁逻辑或启动清除处理
  • 重新运行相同的断电循环测试
  • 验证确定性的安全状态恢复
  1. 构建两个版本的命令逻辑
  2. 定义受监控的标签
  3. 运行正常顺序
  4. 注入模拟断电事件
  5. 恢复供电并重启执行
  6. 记录结果
  7. 修订并重新测试

在变量面板中应该观察什么?

变量面板应同时用于观察逻辑状态过程后果

观察:

  • 重启后依然为真的命令位
  • 在没有新启动命令的情况下通电的输出
  • 过早重新验证的允许条件
  • 在中间状态恢复的顺序步进
  • 暗示过程活动恢复的模拟值或反馈
  • 在没有受控重启处理的情况下返回到先前需求的 PID 相关输出

一个位保持高电平并不自动意味着危险。一个位保持高电平并且重新激活了物理动作路径,才是风险增加的地方。

安全的自保持梯级和有风险的锁存模式应该是什么样的?

最安全的比较是概念上的,因为确切的指令名称因 PLC 系列而异。但区别依然存在。

示例:自保持电机命令模式

典型的自保持模式使用停止条件、故障条件、启动条件,并在启动输入周围并联一个保持分支,以便在有效条件保持为真时维持非保持性的电机运行命令。

行为:

  • 启动瞬间使 `Motor_Run` 通电
  • `Motor_Run` 触点将梯级自保持
  • 停止、故障或允许信号丢失会断开梯级
  • 断电或重启时,`Motor_Run` 不会仅靠内存保持断言

示例:保持性锁存模式

典型的保持性模式使用启动条件来置位一个保留的运行位,使用单独的停止或故障条件来清除它,并使用一个下游梯级从保留位驱动电机输出。

风险:

  • 如果解锁路径在中断前未执行,`Run_Latch` 可能保持置位
  • 重启时,如果 `Run_Latch` 仍为真且允许条件通过,`Motor_Run` 可能会重新通电

更安全的启动清除策略是什么样的?

如果保持性逻辑是合理的,启动处理必须是明确的。

一种常见的模式是使用首次扫描条件在启动期间清除保留的运行位和顺序位。确切的实现取决于平台和风险评估,但原则是稳定的:除非明确需要且有单独的治理,否则在启动时清除保留的命令状态

如何证明断电恢复是正确的?

证明断电恢复正确的方法是根据定义的正确性标准记录行为,而不是说仿真看起来没问题。

使用此工程证据结构:

  1. 系统描述 识别机器或过程功能、主要 I/O、操作模式和重启危险。
  2. 正确的操作定义 说明恢复供电后的确切预期行为。例如:“重启后,在发出新的启动命令之前,不得有电机输出通电。”
  3. 梯形图逻辑和模拟设备状态 捕获事件发生前后的相关梯级逻辑、标签状态和模拟设备状况。
  4. 注入的故障案例 指定中断类型:控制器断电、顺序中止、模式切换、故障跳闸或通信丢失。
  5. 所做的修订 展示逻辑修正:启动清除程序、允许条件重构、状态机复位或输出门控。
  6. 经验教训 记录失败的内容、失败的原因以及修订后的逻辑如何改变了重启行为。

工程师在使用锁存逻辑时最常犯的错误是什么?

最常见的错误是使用锁存来解决顺序控制的不便,而没有同等用心地设计复位路径。

其他反复出现的错误包括:

  • 锁存运行命令而不是状态内存位
  • 假设解锁梯级总是会执行
  • 仅在一种操作模式下清除保留位
  • 忘记断电恢复后的启动清除行为
  • 将操作员复位、故障复位和启动复位混合到一个模糊的路径中
  • 允许保留状态直接驱动输出
  • 只测试正常停机,而不测试异常中断

这些错误之所以常见,是因为锁存逻辑感觉很高效。它确实往往很高效,但如果审查不仔细,它也可能隐藏重启风险。

何时应在此工作流中使用 OLLA Lab?

每当需要在没有工厂风险的情况下演练重启行为、顺序持久性、故障恢复或 I/O 因果关系时,都应在现场调试前使用 OLLA Lab。

这种定位应保持在界限内。OLLA Lab 不能替代正式的现场验收、机器风险评估、功能安全验证或工厂特定的启动程序。它是一个受控环境,用于练习和验证那些在实际设备上首次学习风险过大、破坏性过强或成本过高的逻辑行为。

在此用例中,OLLA Lab 在操作上很有用,因为它允许工程师:

  • 构建并比较自保持和锁存模式
  • 观察标签级的状态保持
  • 注入重启和故障场景
  • 将梯形图状态与模拟设备行为进行比较
  • 在现场暴露前修订逻辑

结论

当命令仅在当前条件证明其合理时才应存在,请选择自保持逻辑。仅在保留状态是必要的且复位行为经过明确工程设计时,才选择锁存逻辑。

安全问题不在于梯级是否有效。安全问题在于什么在中断后存活,什么在重启时重新启动,以及该行为对于机器是否可接受。NFPA 79 和稳健的控制实践都指向同一个方向:应通过设计防止危险的重启

一个有用的最终对比是:自保持逻辑表达连续性;锁存逻辑表达记忆。混淆这两者正是陷阱状态演变成调试难题的原因。

继续探索

相关链接

继续学习

- Up (Pillar Hub): 探索支柱指南 - Across: 相关文章 1 - Across: 相关文章 2 - Down (Commercial/CTA): 在 OLLA Lab 中构建你的下一个项目

References

编辑透明度

本博客文章由人类作者撰写,核心结构、内容和原创观点均由作者本人创建。但本文部分文本在 ChatGPT 和 Gemini 的协助下进行了润色。AI 仅用于语法与句法修正,以及将英文原文翻译为西班牙语、法语、爱沙尼亚语、中文、俄语、葡萄牙语、德语和意大利语。最终内容已由作者进行严格审阅、编辑与验证,作者对其准确性承担全部责任。

作者简介:PhD. Jose NERI, Lead Engineer at Ampergon Vallis

事实核验: 技术有效性已于 2026-03-23 由 Ampergon Vallis 实验室 QA 团队确认。

可直接实施

使用仿真支撑的工作流,将这些洞见转化为可衡量的工厂成果。

© 2026 Ampergon Vallis. All rights reserved.
|