工业自动化中的 AI

文章指南

如何将 AI 感知与 PLC 安全分离:“延髓”架构

本文阐述了为何 AI 应保持在确定性 PLC 控制的上游,以及看门狗、限幅器、允许条件和故障安全逻辑如何帮助在设备执行前验证 AI 发出的请求。

直接回答

“延髓”(Medulla Oblongata)架构将非确定性的 AI 感知与确定性的 PLC 控制分离开来。在这种模型中,AI 可以提出设定值或分类建议,但 PLC 始终是硬实时验证和执行层,在任何指令到达设备之前,由其强制执行限制、允许条件、看门狗和安全状态行为。

本文回答的问题

文章摘要

“延髓”(Medulla Oblongata)架构将非确定性的 AI 感知与确定性的 PLC 控制分离开来。在这种模型中,AI 可以提出设定值或分类建议,但 PLC 始终是硬实时验证和执行层,在任何指令到达设备之前,由其强制执行限制、允许条件、看门狗和安全状态行为。

AI 不是安全控制器,将其视为安全控制器在调试错误发生之前,就已经是一个架构错误。其区别很简单:AI 擅长感知、估计和优化;PLC 擅长确定性执行、互锁和边界控制。

这种区别至关重要,因为工业控制系统不会在抽象层面发生故障。它们的故障表现为心跳丢失、数值陈旧、竞争条件以及不该动作时产生的输出。机器很少会被聪明的模型所打动。

Ampergon Vallis 最近的一项内部基准测试支持了这种分离的实际价值。在 100 小时的 OLLA Lab 仿真练习中,将异步外部设定值更新注入闭环控制场景,导致积分饱和故障事件比采用限幅和速率限制的 PLC 验证路径增加了 14%,而 PLC 管理路径将响应偏差保持在验证梯级序列 3 毫秒的确定性执行范围内。[方法论:100 小时模拟测试运行;任务 = 将外部设定值移交给边界控制场景;基准比较器 = 无限幅和看门狗验证的直接异步设定值注入;时间窗口 = 单次连续 100 小时运行。] 该指标支持在仿真中进行防御性 PLC 验证的价值。它并不支持关于所有 AI 系统、所有工厂或正式安全认证的任何广泛声明。

为什么 AI 驱动的自动化需要确定性的 PLC 执行?

需要确定性执行是因为安全和主要控制决策必须在已知的时间范围内发生。AI 推理引擎(无论是本地还是远程)都无法保证这一特性。

PLC 在有界的扫描周期内执行其程序。读取输入、求解逻辑、写入输出,然后循环以定义的间隔重复。该间隔可能会因平台和程序负载而略有不同,但其设计目的是保持可预测性和可观测性。可预测性才是关键所在。

AI 系统的运行方式不同。它们的响应时间会随处理器负载、内存压力、调度程序行为、模型大小、热节流、中间件延迟或网络延迟而变化。即使平均推理速度很快,当设备可能移动、碰撞、过量填充、过热或无法跳闸时,最坏情况下的时序才是最重要的。

扫描周期与异步推理的数学关系

工程上的区别不是哲学上的,而是时间上的。

  • PLC 控制路径
  • 在重复的扫描周期内执行
  • 支持有界逻辑评估
  • 专为确定性 I/O 处理而设计
  • 可针对时序和故障行为进行审计
  • AI 计算路径
  • 异步执行
  • 可能以不规则的时间间隔返回结果
  • 可能停滞、超时、抖动或产生陈旧的输出
  • 通常依赖于未被设计为主要安全逻辑的软件栈

在实际操作中,PLC 可以被信任在每个扫描周期评估一个允许条件。AI 服务可能很有用,但不能以同样的方式被信任。“有用”和“值得信赖”不是同义词。工厂在忘记这一点时,往往会付出昂贵的代价。

标准对确定性控制的规定

IEC 61508 为电气、电子和可编程电子安全相关系统建立了功能安全框架。对于本次讨论,一个核心含义很明确:安全相关行为需要可证明、有界且经过验证的执行特性。

这并不意味着每个 PLC 程序都是自动安全的。这意味着安全功能需要确定性的设计、验证和生命周期准则,而异步 AI 系统本身并不提供这些。exida 及相关功能安全指南在工业术语中表达了同样的实际观点:如果一个功能是安全关键的,那么时序不确定性和不可验证的行为就不是小麻烦。

这里有一个简洁的修正:AI 可以辅助安全相关系统,但不应被视为主要的确定性安全层。 你不能把光幕接到大语言模型(LLM)上并称之为架构。

什么是过程控制中的“延髓”架构?

“延髓”架构是一种分层控制模型,其中 AI 提出建议,PLC 进行处置。AI 执行高级感知或优化;PLC 始终是硬实时权威,在硬件动作之前验证、限幅、排序或拒绝这些请求。

这个生物学类比之所以令人难忘,是因为它在结构上足够准确,具有实用价值。大脑皮层负责解释和规划,而延髓负责自主生存功能。在自动化术语中,AI 可能估计产品质量、检测物体或建议进料速度调整;但 PLC 仍然拥有互锁、停止链、允许条件和有界驱动的控制权。

控制层级

  • 解释图像、趋势或多变量过程上下文
  • 生成分类、建议或请求的设定值
  • 异步运行,可能出错、延迟或陈旧
  • 根据硬性限制检查请求
  • 验证机器状态、允许条件和互锁
  • 通过心跳或看门狗逻辑确认新鲜度
  • 应用变化率限制、限幅和故障安全行为
  • 仅接收经 PLC 批准的指令
  • 包括驱动器、阀门、接触器、执行器和报警器
  • 如果验证失败,则移动到安全或有界状态
  1. 感知层 (AI)
  2. 验证层 (PLC)
  3. 执行层 (硬件)

这并非反 AI 立场,而是支持边界的立场。好的架构大多是纪律严明的拒绝。

PLC 必须始终保留的权限

PLC 必须对需要确定性响应和有界故障行为的功能保留绝对权威。

这通常包括:

  • 紧急停止处理
  • 安全互锁评估
  • 运动允许条件
  • 碰撞避免逻辑
  • 硬行程或速度限制
  • 通信丢失时的安全状态回退
  • 危险转换的序列门控
  • 对执行器的最终指令仲裁

如果 AI 请求提高速度,PLC 可能会允许、降低、延迟或拒绝它。最终决定权属于确定性层。

如何在梯形图中编程硬实时安全限制?

通过将 AI 输出视为不可信的外部输入,可以编程硬实时安全限制。这意味着每个 AI 发出的数值在影响机器或过程之前,必须通过明确的防御性逻辑。

这就是梯形图不再仅仅是语法练习,而成为调试判断的地方。仅仅“能运行”的梯级是不够的。该梯级还必须以受控方式失败。

AI 与 PLC 握手的必要防御梯级

#### 1. 用于心跳监控的看门狗定时器

看门狗定时器验证 AI 或上游计算系统是否仍在可接受的时间间隔内进行通信。

  • AI 发送心跳位或递增值
  • 当心跳改变时,PLC 重置 TON 或等效定时器
  • 如果定时器超时,PLC 将:
  • 使 AI 请求无效,
  • 强制执行安全默认值,
  • 触发故障或报警,
  • 并阻止进一步执行,直到满足恢复条件

死掉的上游服务不应留下活动的输出路径。那不是智能,那是残留物。

#### 2. 用于硬限幅的限制块

限制指令将请求的数值约束在物理上安全的运行范围内。

示例用例:

  • 将请求的电机速度限制在最小冷却速度和最大安全转速之间
  • 将阀门需求限制在避免水锤效应的范围内
  • 将温度设定值限制在设备设计范围内

梯形图结构示例:

  • 指令:LIM(限制测试)
  • 下限:15.0 Hz
  • 测试:`AI_Requested_Speed`
  • 上限:45.0 Hz
  • 输出:`Safe_Speed_Permissive`

重点不在于优雅,而在于任何上游的乐观情绪都不能指挥超速。

#### 3. 变化率限制

变化率限制器可防止在数值上有效但在转换过程中不安全的突发指令变化。

示例:

  • 防止阀门在一次更新中从 10% 移动到 100%
  • 将变频器(VFD)速度增加限制在定义的斜坡内
  • 限制每次扫描或每秒的设定值移动

这一点很重要,因为许多故障发生在转换过程中,而不是终点。最终数值可能是合法的,但达到该数值的路径可能是鲁莽的。

#### 4. 陈旧性检测和序列有效性

一个数值在数值上可能是合理的,但在操作上却是无效的。

PLC 应验证:

  • 时间戳新鲜度或序列计数
  • 机器模式兼容性
  • 当前操作阶段
  • 应用请求前的允许条件状态
  • 请求是否属于当前活动的配方、批次步骤或序列状态

在错误的序列阶段使用陈旧的设定值,只是一种礼貌形式的坏数据。

在此架构中“正确”意味着什么

正确性必须在操作层面定义,而不是在表面层面。在这种背景下,正确的 AI 与 PLC 集成意味着:

  • PLC 仅接受新鲜且有界的请求,
  • 机器仅在允许条件为真时移动,
  • 不安全的转换被阻止,
  • 通信丢失产生定义的故障安全状态,
  • 且每个拒绝路径在标签、报警或事件逻辑中都是可观测的。

这个定义比“梯级编译通过”更有用。编译只是一个低门槛,设备损坏经常会跨越这个门槛。

如何在现场调试前验证 AI 与 PLC 的握手?

通过故意模拟异常行为,然后证明 PLC 逻辑拒绝或包含了这些行为,来验证 AI 与 PLC 的握手。验证不是展示“快乐路径”能工作,而是展示错误输入能安全且可观测地失败。

这就是“仿真就绪”(Simulation-Ready)需要严格定义的地方。一名“仿真就绪”的工程师是指能够在逻辑到达实际过程之前,证明、观察、诊断并强化控制逻辑以应对现实过程行为的人。这比了解梯形图语法标准更高。这是绘制逻辑与调试逻辑之间的区别。

在接触硬件前应测试的内容

至少,工程师应测试:

  • AI 服务的心跳丢失
  • 延迟更新和陈旧数值
  • 超出范围的设定值
  • 合理范围内但不可信的数值
  • 快速振荡的请求
  • AI 请求与机器状态之间的模式不匹配
  • 错误的启动序列时序
  • 通信恢复后的回退行为

如果这些情况没有经过演练,架构就没有经过验证,仅仅是充满希望而已。

工程师如何在 OLLA Lab 中验证 AI 与 PLC 的握手?

OLLA Lab 在这里很有用,它是一个有界的验证环境,用于演练 AI 集成风险的 PLC 端。它不是 AI 安全认证器,也不能替代正式的现场验收、危险审查或功能安全评估。它是一个练习那些在实际设备上即兴发挥风险太大或成本太高的控制强化任务的地方。

实际优势很简单:工程师可以安全且反复地注入错误行为。

OLLA Lab 允许工程师演练的内容

使用基于 Web 的梯形图编辑器、仿真模式和变量面板,工程师可以:

  • 构建监督外部请求值的梯形图逻辑,
  • 实时切换输入和内部标签,
  • 观察输出和中间允许条件,
  • 测试定时器、计数器、比较器、数学运算和 PID 相关行为,
  • 对比梯形图状态与模拟设备响应,
  • 并在观察到故障路径后修改逻辑。

该工作流程很重要,因为 AI 集成故障通常表现为时序和状态问题,而不仅仅是错误的数字。OLLA Lab 为这些问题提供了可见的场所。

OLLA Lab 中的实用验证工作流程

一个可靠的演练序列如下:

  • 构建一个接收外部请求速度、流量或位置值的梯级序列
  • 添加允许条件、模式检查和最终执行条件
  • 插入看门狗定时器
  • 使用限制逻辑添加限幅器
  • 添加变化率限制器或阶梯式斜坡
  • 定义超时或数据无效时的回退行为
  • 使用变量面板强制输入超出范围的数值
  • 暂停或停止心跳信号
  • 引入突发的指令变化
  • 在指令执行期间切换过程状态
  • 确认输出保持在有界范围内
  • 验证超时逻辑是否正确跳闸
  • 检查报警或故障位是否可见
  • 将模拟的机器行为与预期的控制理念进行比较
  • 调整定时器值、限制和序列条件
  • 重新测试相同的故障,直到拒绝路径是确定且清晰的
  1. 创建控制路径
  2. 添加防御性逻辑
  3. 注入异常情况
  4. 观察因果关系
  5. 修改并重新运行

这就是 OLLA Lab 具有操作价值的地方。它让工程师演练否决逻辑,而不仅仅是欣赏它。

你应该提供什么工程证据来展示这项技能?

你应该提供一套紧凑的工程证据,证明在故障下的控制推理,而不是编辑器截图库。截图只能证明屏幕存在,不能证明逻辑在压力下保持稳定。

使用以下结构:

  1. 系统描述 描述机器或过程单元、控制目标、AI 提供的输入以及 PLC 拥有的安全或验证角色。
  2. “正确”的操作定义 说明确切的验收标准:允许的运行范围、超时间隔、允许条件、回退状态和预期的报警行为。
  3. 梯形图逻辑和模拟设备状态 展示相关的梯级、标签以及这些梯级所管理的模拟机器或过程状态。
  4. 注入的故障案例 记录引入的异常情况:陈旧心跳、超速请求、模式不匹配、振荡指令或无效的序列时序。
  5. 所做的修改 解释逻辑中改变的内容:添加了限幅器、更改了看门狗间隔、插入了互锁、添加了变化率限制或修改了序列门控。
  6. 经验教训 说明故障揭示了关于控制理念、机器假设或数据有效性路径的什么信息。

这种证据结构比精美的演示剪辑更有说服力。调试风险需要证明,而不是美学。

AI 在工业自动化栈中到底属于哪里?

AI 属于确定性控制的上游,而不是取代它。其有用的角色是从传统逻辑难以处理的复杂数据中生成建议或候选值。

示例包括:

  • 基于视觉的分类
  • 异常检测
  • 质量估计
  • 预测性维护评分
  • 多变量优化建议

然后,PLC 决定这些输出在当前机器上下文中是否可接受。

一个清晰的架构规则

一个实用的规则是:AI 可以建议;PLC 必须授权。

该规则保留了两层的优势:

  • AI 处理歧义、模式识别和优化
  • PLC 逻辑处理时序、允许条件、限制和确定性执行

结果并不华丽,这在控制领域通常是一个好迹象。良好的工厂架构通常看起来有点枯燥,直到它阻止了一次昂贵的错误。

结合 AI 和 PLC 控制时的常见设计错误是什么?

最常见的错误是允许 AI 输出绕过明确的验证逻辑。一旦发生这种情况,架构就已经失去了边界准则。

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

  • 将网络时间戳视为等同于确定性的新鲜度
  • 假设在范围内的数值自动是安全的
  • 忘记序列状态验证
  • 省略心跳丢失时的回退行为
  • 允许建议性输出随时间演变为直接指令
  • 只测试标称行为,而不测试异常转换
  • 将仿真成功与现场就绪混为一谈

最后一点值得强调。仿真是一个验证环境,而不是现场能力的声明。它是工程师在实际接触前学习观察、诊断和强化逻辑的地方。有用、必要,但仍然不等同于凌晨 2 点站在运行的生产线旁,等待维护人员的到来。

结论

将 AI 集成到工业自动化中的安全方法是将感知与权威分离。AI 可以分类、估计和推荐。PLC 必须保持为硬实时核心,负责验证、限幅、排序和否决。

这就是“延髓”架构的一句话总结:AI 思考,PLC 维持生命。

对于工程师来说,实际任务不是赞美 AI 的输出,而是围绕它们强化控制路径。看门狗、限制、允许条件、变化率检查、陈旧数据检测和安全状态回退不是可选的细节,它们就是架构本身。

如果这听起来不如营销材料那么具有未来感,那很好。机器通常更喜欢成年人。

相关阅读

References

编辑透明度

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

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

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

可直接实施

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

© 2026 Ampergon Vallis. All rights reserved.
|