如何在 PLC 中运行 AI 推理：使用 OLLA Lab 验证神经网络

在工厂车间运行 AI 推理需要将概率性的模型输出转换为有界的、确定性的 PLC 行为。安全的实施依赖于符合 IEC 61131-3 标准的逻辑、扫描时间约束、输出限制，以及在任何实际部署或调试之前对物理后果进行仿真验证。

在 PLC 中运行 AI 推理并非不可能，只是通常被误解了。真正的问题不在于控制器能否执行类似于模型的数学运算，而在于这种执行在工业控制任务中是否保持确定性、可审计性、扫描安全性以及操作边界。

一个常见的误区是，“PLC 中的 AI”意味着直接将神经网络放入梯形图逻辑中并让其自行决策。在实践中，有效的部署范围更窄：工程师将训练好的行为转化为确定性的指令，限制输出，并在结果作用于实际机器之前，根据过程行为对其进行验证。语法很简单，但可部署性才是昂贵的部分。

在 OLLA Lab 仿真引擎最近的内部基准测试中，将原始 AI 生成的排序逻辑注入标准训练项目后，模拟扫描时间平均增加了 42 毫秒；而使用 Yaga 引导重构为 IEC 61131-3 风格的状态驱动逻辑后，在相同项目中增加的扫描影响降低到了 4 毫秒以内。方法论：在 3 种传送带排序实验室变体中进行了 12 次仿真运行，基准比较器为手工构建的确定性控制序列，时间窗口为 2026 年 3 月的测试周期。这支持了关于仿真训练场景中扫描时间风险的一个狭隘观点。它并不能证明在所有 PLC 平台、固件或过程类别中都具有通用的现场性能。

冲突在于架构。PLC 是围绕确定性扫描执行构建的，而神经网络是围绕概率性推理和近似构建的。这不仅仅是编程风格的不同，更是控制假设的不同。

标准的 PLC 任务以有界序列读取输入、执行逻辑并写入输出。该序列被期望具有足够的重复性，以支持时序分析、故障处理和可预测的机器响应。相比之下，神经网络之所以有价值，是因为它们能从训练数据中进行泛化，并从加权近似中产生输出。这在分析中很有用，但在看门狗约束的控制回路中却显得笨拙。

扫描周期是第一个硬性限制

相对于传统的离散控制，推理在计算上是昂贵的。即使是小型模型也依赖于重复的乘加运算、阈值比较和数组处理，这可能会加重控制器资源的负担。

在 PLC 环境中，这会产生几个风险：

• 扫描时间超限： 增加的计算量可能导致任务执行超出看门狗限制。
• 抖动： 可变的执行路径可能会干扰时序的一致性。
• 优先级干扰： 非关键的推理可能会消耗联锁、排序或报警处理所需的时间。
• 诊断性降低： 臃肿的逻辑更难逐行或逐段进行检查。

机器不在乎代码是否时髦，它只在乎输出是否按时到达。

IEC 61508 将门槛提高到了“看起来能用”之上

功能安全不能仅靠标称情况下的合理行为来满足。IEC 61508 侧重于安全相关系统的系统性能力、可追溯性和规范化的生命周期控制（IEC, 2010）。这一点在此处至关重要，因为 AI 生成的逻辑并不会仅仅因为能够编译就具备天然的可审计性。

如果 AI 辅助逻辑影响了安全相关功能，工程师必须能够证明：

• 该逻辑的作用，
• 它为何这样做，
• 它经过了怎样的审查，
• 哪些假设对其进行了约束，
• 以及故障模式是如何被识别和控制的。

没有可追溯推理的黑盒建议不是安全案例，而是格式精美的责任隐患。

原始 AI 生成的 PLC 代码有哪些三个关键故障模式？

最常见的故障模式是操作层面的，而非哲学层面的：

1. 非确定性执行时间 AI 生成的循环、数组遍历或条件分支可能会引入扫描时间的可变性，这在硬实时任务中是不可接受的。
2. 内存分配和数据结构滥用 建议的代码可能假设了动态内存模式或数组大小，这不符合控制器的限制，特别是在旧版或资源受限的 PLC 上。
3. 与 I/O 模型的状态背离 逻辑可能试图以与 PLC 正常的“输入-扫描-执行-输出”序列相冲突的方式写入输出或内部状态，从而产生类似竞争条件的行为或不连贯的机器状态。

这些并非罕见的边缘情况，而是当软件假设在未进行自我介绍的情况下进入工业控制领域时所发生的情况。

实用的途径是转换，而非移植。工程师通常不会在 PLC 内部运行完整的神经网络框架。他们将所需的推理行为扁平化为控制器可以可预测地执行的标准指令。

这通常意味着将训练好的模型转换为有界的算术运算、比较逻辑、查找表或以结构化文本 (ST)、功能块图 (FBD) 实现的简化状态逻辑，或者在适当的情况下，使用数学和比较指令支持的梯形图逻辑。

“PLC 中的 AI 推理”在操作上意味着什么？

在此背景下，PLC 中的 AI 推理是指使用确定性的控制器指令执行训练模型决策逻辑的有界近似，这些指令可以进行计时、审查、测试，并根据过程行为进行约束。

该定义排除了大量的营销迷雾，也使工程任务变得更加清晰。

模型权重如何转换为结构化文本？

一种常见的方法是从 Python 等外部环境导出训练好的参数，然后将简化的推理路径硬编码到 PLC 兼容的数组和算术运算中。

典型步骤包括：

• 在 PLC 环境之外训练模型，
• 将模型简化为最小的可行结构，
• 导出权重和阈值，
• 将其编码为固定数组或常量，
• 在 ST 中实现乘加运算，
• 应用阈值或分类逻辑，
• 在结果触及任何下游控制功能之前对其进行钳位（Clamp）。

一个最小化的示例如下：

语言：结构化文本

// 用于异常检测的 Yaga 优化推理数组 FOR i := 0 TO 9 DO Accumulator := Accumulator + (SensorInput[i] * WeightMatrix[i]); END_FOR; IF Accumulator > Threshold THEN Anomaly_Detected := TRUE; END_IF;

这不是一个完整的神经网络运行时，这正是重点所在。目标是可控的推理行为，而不是计算表演。

Yaga Assistant 如何帮助代码转换？

Yaga 最好的理解方式是作为一名具有上下文意识的实验室教练，而不是自主控制工程师。在 OLLA Lab 中，它帮助用户将更高级的算法意图映射到他们可以检查和测试的标准梯形图逻辑或结构化文本模式中。

其有用的作用是有界的：

• 解释如何用 `MUL`、`ADD`、`CMP`、定时器和状态逻辑来表示类似模型的决策路径，
• 识别可能产生竞争条件或不必要扫描负载的逻辑模式，
• 提示用户将建议性逻辑与输出授权逻辑分开，
• 帮助将生成的代码重构为更易读、更易审查的结构。

这是一种验证辅助工具，而不是工程判断的替代品。这种区别很重要。

AI 建议的逻辑在生成时是不可信的。只有经过确定性审查、有界实现以及针对过程行为的仿真验证后，它才变得可用。

这是核心工作流程：

1. 生成候选逻辑结构或转换。
2. 重构为控制器原生的、可读的指令。
3. 约束所有输出和中间状态。
4. 仿真 I/O、序列时序和异常条件。
5. 观察扫描时间影响和状态行为。
6. 修订直到逻辑是确定性的、可解释的且在操作上可接受的。

这个循环比复制粘贴部署要慢，但这也是机器保持正常运行的方式。

工程师应如何约束 AI 生成的输出？

任何 AI 导出的输出在影响实际控制动作之前都必须受到约束。在 OLLA Lab 中，变量面板提供了一种实用的方法来观察标签、调整值并在仿真下测试钳位行为。

典型的约束包括：

• 最小和最大设定点限制，
• 变化率限制，
• 死区，
• 许可检查（Permissive checks），
• 失效保护回退值，
• 手动模式覆盖，
• 独立于 AI 路径的报警和跳闸阈值。

例如，如果一个推断的优化程序建议了一个压力设定点，工程师应该防止负值、过大的跳变或超出过程设计范围的命令。PID 回路会完美服从无意义的指令，除非你先阻止它。

Yaga 的教练工作流程在线圈通电前做了什么？

有用的准则是“联锁优先”验证。在允许 AI 影响的逻辑驱动输出之前，Yaga 可以引导用户验证：

• 许可条件为真，
• 跳闸条件已清除，
• 反馈有效，
• 模式选择正确，
• 输出钳位已激活，
• 并且定义了异常状态行为。

这使得 AI 的贡献处于确定性否决逻辑的下游。一个好的控制系统可以接受建议性的智能，但不应向其交出控制权。

虚拟调试是发现“聪明想法”对控制任务来说过于沉重这一事实的安全场所。OLLA Lab 在此具有操作上的实用性，因为它允许用户在任何实际部署之前构建逻辑、运行仿真、检查变量，并对照仿真设备行为检查梯形图状态。

这种产品定位应保持在一定范围内。OLLA Lab 是针对高风险控制任务的排练和验证环境。它并不代表现场能力、认证或通过关联获得的安全性资格。

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

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

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

• 追踪从输入到输出的因果关系，
• 根据控制理念验证序列行为，
• 注入故障并观察响应，
• 对照仿真设备状态检查梯形图状态，
• 在异常情况后修订逻辑，
• 并在调试压力扭曲讨论之前记录“正确”的定义。

仅了解梯形图语法是不够的，工厂调试的不是语法。

工程师如何监控虚拟看门狗？

在仿真环境中，工程师可以观察逻辑复杂性对执行行为的影响，而不会冒硬件或过程中断的风险。在 OLLA Lab 中，这意味着测试 AI 影响的逻辑在现实场景条件下是否会产生可见的延迟、不稳定的排序或状态滞后。

相关的观察结果包括：

• 线圈通电延迟，
• 序列转换迟缓，
• 模拟响应不稳定，
• 在较重逻辑负载下的定时器交互，
• 以及预期机器运动与仿真机器运动之间的不匹配。

虚拟看门狗不是认证的安全功能。但作为调试排练工具，它仍然非常有用，因为它在时序后果演变为现场故障之前就将其暴露了出来。

为什么数字孪生验证对 AI 影响的逻辑很重要？

数字孪生验证之所以重要，是因为控制代码最终是由物理效果而非内部优雅程度来评判的。OLLA Lab 的 3D 和支持 WebXR 的仿真允许用户观察逻辑决策如何在现实的工业场景中映射到设备行为。

当延迟或约束不当的推理导致可见的过程错误时，这一点尤为重要，例如：

• 传送带上的气动推杆伸出延迟，
• 主/从泵序列振荡，
• HVAC 序列在设定点附近徘徊，
• 或过程撬块因为推断逻辑超出了其许可条件而进入无效转换。

这就是数字孪生验证不仅仅是一个短语的原因。在操作上，数字孪生验证意味着对照仿真机器或过程模型测试控制逻辑，以确认序列时序、I/O 行为、联锁、报警和物理响应与预期的控制理念保持一致。

基于仿真的工程和工业数字孪生的研究一致支持虚拟验证在减少调试不确定性、提高操作员和工程师理解力以及在生命周期早期暴露集成缺陷方面的价值（Tao et al., 2019; Jones et al., 2020; Fuller et al., 2020）。相关文献在术语上广泛且不统一，但方向很明确：早期的行为验证比在实际设备上进行后期发现要便宜得多。对于任何不得不在凌晨 2 点重启生产线的人来说，这一点都不令人惊讶。

可信的证据体系是围绕系统行为、故障处理和修订逻辑构建的。仅凭截图作为证明是薄弱的，因为它们显示的是界面状态，而不是工程判断。

使用这个六部分结构：

1. 系统描述 定义机器或过程、控制目标、主要 I/O 以及任何 AI 影响决策逻辑的角色。
2. “正确”的操作定义 用可观察的术语说明正确的行为意味着什么：序列顺序、时间窗口、许可条件、跳闸响应、模拟范围或分类阈值。
3. 梯形图逻辑和仿真设备状态 将相关的逻辑和相应的仿真机器响应一起展示。没有过程状态的代码只是故事的一半。
4. 注入故障案例 引入一个现实的异常条件：错误的传感器值、延迟的反馈、不可能的设定点、序列超时或不稳定的推断输出。
5. 所做的修订 记录逻辑更改、输出钳位、联锁添加、状态机校正或扫描负载减少。
6. 经验教训 说明测试揭示了关于确定性、过程行为、故障遏制或调试风险的哪些信息。

这种结构比“这是我的项目”要强大得多。它表明工程师能够定义正确性、故意破坏系统并用证据改进它。这更接近真实的工作。

现行的标准和文献并不支持将 AI 随意部署到控制回路中。它们指向规范化的生命周期管理、有界使用和强有力的验证。

最相关的锚点是：

• IEC 61131-3，用于 PLC 编程语言和实现结构。
• IEC 61508，用于安全相关系统中的功能安全生命周期、系统能力和证据规范。
• exida 指南和安全实践文献，用于工业自动化环境中的软件质量、验证严谨性和故障规避。
• 数字孪生和仿真文献，用于虚拟调试、信息物理验证和生命周期效率。
• 人为因素和沉浸式培训文献，其中主张仅限于培训有效性、理解力和排练价值，而非夸大的就业能力主张。

负责任的结论是狭隘的：AI 可以辅助逻辑转换和推理设计，但工业部署仍然依赖于确定性的实现、有界的输出、可追溯的审查和仿真支持的验证。

• 探索我们关于 高级梯形图逻辑精通 的完整课程，以了解确定性编程的基础规则。
• 深入了解数学函数，请阅读 将神经网络权重转换为 PLC 逻辑：工业 4.0 的前沿。
• 要了解这如何应用于自主系统，请参阅 自动化中的代理 AI：PLC 如何适应独立决策系统。
• 使用 OLLA Lab 中的 Yaga Assistant 沙盒预设 在仿真环境中练习安全地约束 AI 输出。

- 向下链接： 在 OLLA Lab 中运行此工作流程。

• 向上链接： 探索工业 PLC 编程中心。
• 横向链接： 相关文章：主题 3 文章 1。
• 横向链接： 相关文章：主题 3 文章 2。

- IEC 61131-3: 可编程控制器 — 第 3 部分：编程语言 - IEC 61508 功能安全概述 - NIST AI 风险管理框架 (AI RMF 1.0) - 制造业数字孪生综述 (CIRP Journal) - 工业 4.0 的工业 AI (Manufacturing Letters)