本文回答的问题
文章摘要
将神经网络权重转换为 PLC 结构化文本(Structured Text),意味着导出训练好的模型的权重和偏置,将其重写为 IEC 61131-3 数组,并在 PLC 扫描周期内确定性地执行前馈数学运算。工程目标不是将“AI 引入控制”作为口号,而是实现无需依赖边缘网络的、有界且可测试的推理。
神经网络仅仅因为在 Python 中能很好地分类数据,并不代表它们在工业上就有用。只有当它们的执行路径对于依赖扫描时间、看门狗限制和故障行为的控制系统来说足够可预测时,它们才具有实用价值。
对于高速异常检测,将过程数据发送到外部边缘 PC 可能会在信号和动作之间引入延迟、抖动以及额外的故障点。这种架构对于咨询类分析或许可以接受,但当模型输出与允许条件、跳闸或联锁挂钩时,它就不那么适用了。OT(运营技术)领域对于那些失效时表现不佳的优雅架构几乎没有耐心。
一种有界的替代方案是将轻量级训练模型(通常是浅层多层感知器)导出为 IEC 61131-3 结构化文本,并直接在控制器中运行推理。
Ampergon Vallis 指标: 在一次内部 OLLA Lab 仿真中,一个使用 16x16 浮点隐藏层矩阵的 3 层 MLP 在重复推理测试期间,为模拟扫描执行增加了 1.2 ms 的时间。方法论:对同一前馈任务进行 n=25 次仿真运行,基准比较器 = 无矩阵执行的相同逻辑状态,时间窗口 = 2026 年 3 月的一次验证会话。 这支持了小型神经网络推理块可以在 PLC 类环境中进行确定性可行性测试的观点。但这并不证明其适用于所有控制器、所有扫描预算或任何安全功能。
为什么要直接在 PLC 中运行神经网络,而不是在边缘 PC 上运行?
在 PLC 内部运行推理消除了关键执行路径上的网络传输。这是核心的工程原因。
边缘 PC 可能足以满足非关键监控、历史数据分析或维护仪表板的需求。但当模型输出必须参与确定性控制决策时,情况就不同了。如果网络链路中断,推理路径也会随之中断。问题不在于边缘计算是错误的,而在于控制逻辑比分析架构更不容错。
区别很简单:
- 边缘推理通常是异步的、依赖网络的,并且在 PLC 扫描之外调度。
- PLC 常驻推理只有在控制器任务内对执行时间、内存使用和故障行为进行限制时,才是确定性的。
对于与电机允许条件、阀门禁止或顺序保持相关的异常检测,确定性的局部性至关重要。一个迟到的结果在功能上通常等同于没有结果。
这里涉及哪些标准背景?
功能安全标准不支持随意的时序假设。IEC 61508 关注的是可预测的行为、经过验证的执行和已知的故障响应,而不是模型在笔记本电脑中看起来是否令人印象深刻。
这需要一个明确的界限:
- 将神经网络嵌入结构化文本中,默认情况下并不会使其成为安全功能。
- 如果其执行经过验证、有界且进行了适当的隔离,它可以支持确定性的过程监控逻辑。
- 如果输出影响安全相关动作,验证的负担会急剧增加。“它在仿真中运行良好”并不能构成安全案例。
一个普遍的误解是,将 AI 放入 PLC 会自动使其更具工业性。它只是使其更接近扫描周期。困难的部分仍然是证明。
什么样的神经网络可以切实地转换为 PLC 结构化文本?
在大多数 PLC 环境中,只有小型前馈模型是实用的。这就是有用的界限。
最常见的候选者是离线在 MATLAB、Python 或类似环境中训练的浅层多层感知器 (MLP),然后作为静态权重和偏置导出。这之所以可行,是因为固定 MLP 的推理只是算术运算:
- 矩阵乘法
- 偏置加法
- 激活函数评估
- 阈值或分类逻辑
这些算术运算虽然繁琐,但却是确定性的。
最适合的模型包括:
- 单隐藏层或浅层 MLP
- 小型输入向量
- 有限的隐藏节点数
- 简单的激活函数,如 ReLU 或有界线性近似
最不适合干净转换的模型包括:
- 循环神经网络
- 大型卷积模型
- Transformer 架构
- 任何需要动态内存行为、不支持的库或大量浮点吞吐量的模型
这不是关于 AI 能力的总体陈述,而是关于控制器经济性和扫描纪律的陈述。
将 MATLAB 或 Python 权重导出为 IEC 61131-3 的流程是什么?
转换过程在概念上很简单,但在细节上却毫不留情。大多数失败不是数学上的,而是索引、缩放、数据类型或任务时间上的失败。
第 1 步:离线训练轻量级模型
使用历史过程数据或标记的事件数据,在 MATLAB、Python 或其他 ML 环境中训练模型。
适合 PLC 部署的模型通常具有:
- 归一化的数值输入
- 有限的特征数量
- 稳定的运行范围
- 清晰的异常标签或阈值逻辑
- 可以解释和有界的推理路径
如果模型需要桌面级 GPU 才能舒适运行,它通常不属于标准的控制器任务。
第 2 步:导出权重和偏置
从模型中提取训练好的参数:
- 输入到隐藏层的权重矩阵
- 隐藏层偏置向量
- 隐藏层到输出层的权重矩阵
- 输出层偏置向量
典型的导出格式包括:
- CSV
- JSON
- MATLAB 数组
- 写入文本的 Python NumPy 数组
在此阶段,请保留:
- 数组维度
- 行/列顺序
- 数值精度
- 输入归一化常数
- 输出阈值
令人惊讶的是,许多部署问题实际上只是矩阵转置错误。
第 3 步:将参数转换为符合 IEC 61131-3 的数组
使用控制器支持的数据类型(通常是 `REAL` 或 `LREAL`,具体取决于平台能力和扫描预算)将模型参数重写为结构化文本数组。
示例形状映射:
- `W1[HiddenNodes, InputNodes]`
- `B1[HiddenNodes]`
- `W2[OutputNodes, HiddenNodes]`
- `B2[OutputNodes]`
同时定义:
- 输入向量数组
- 中间节点和数组
- 激活输出数组
- 最终推理输出数组
数据类型的选择很重要。`LREAL` 可能会提高数值保真度,但也可能根据控制器架构增加执行成本。
第 4 步:在结构化文本中重建前馈传递
将模型实现为显式的算术运算:
- 用偏置初始化每个节点和
- 累加加权输入乘积
- 应用激活函数
- 将激活后的输出传递到下一层
- 将最终输出与阈值或分类规则进行比较
这就是模型成为确定性算术块的地方。
第 5 步:重建预处理和输出逻辑
在归一化输入上训练的模型必须在 PLC 中接收归一化输入。否则,推理在数学上是正确的,但在操作上是错误的。
你必须实现:
- 缩放
- 偏移校正
- 必要时的钳位(Clamping)
- 缺失信号处理
- 输出阈值
- 如果推理块接收到无效数据时的故障状态行为
没有预处理路径的模型不是已部署的模型,它只是被复制了而已。
如何在结构化文本中编写矩阵乘法?
结构化文本中的矩阵乘法通常通过嵌套的 `FOR` 循环和显式累加到节点和数组中来实现。目标是正确性、确定性和扫描时间的可视性。
示例:隐藏层加权和
语言:结构化文本
// 隐藏层加权和 FOR i := 0 TO HiddenNodes - 1 DO NodeSum[i] := Bias1[i]; FOR j := 0 TO InputNodes - 1 DO NodeSum[i] := NodeSum[i] + (InputArray[j] * Weight1[i, j]); END_FOR; END_FOR;
此代码执行输入向量与每个隐藏层神经元权重行之间的点积,然后加上相应的偏置。
重要的实现检查:
- 确认你的 PLC 使用的是从零开始还是从一开始的数组约定
- 保持数组维度明确
- 在累加前初始化总和
- 避免隐藏的类型转换
- 测试最坏情况下的执行时间,而不仅仅是标称执行时间
能运行一次的循环只是演示。能在噪声输入下以任务速率运行的循环才是工程。
如何计算输出层?
输出层是应用于隐藏层激活的相同模式。
语言:结构化文本
// 输出层加权和 FOR i := 0 TO OutputNodes - 1 DO OutputSum[i] := Bias2[i]; FOR j := 0 TO HiddenNodes - 1 DO OutputSum[i] := OutputSum[i] + (HiddenOutput[j] * Weight2[i, j]); END_FOR; END_FOR;
对于单个异常分数,`OutputNodes` 可以为 `1`,最终分数与阈值进行比较。
如何在 PLC 中实现 ReLU 激活函数?
ReLU 是最容易转换的激活函数之一,因为它是分段线性的。在结构化文本中,它变成了一个简单的条件判断。
语言:结构化文本
// ReLU 激活 FOR i := 0 TO HiddenNodes - 1 DO IF NodeSum[i] < 0.0 THEN HiddenOutput[i] := 0.0; ELSE HiddenOutput[i] := NodeSum[i]; END_IF; END_FOR;
这保留了基本的 ReLU 规则:
- 如果输入 < 0,输出 = 0
- 否则输出 = 输入
这种简单性在 PLC 中非常有用,因为它避免了更昂贵的非线性函数。
还有哪些激活方法是实用的?
实用的选择取决于控制器的能力,但常见的方法包括:
- ReLU: 最简单的直接实现
- 线性激活: 对回归类输出很有用
- 分段近似: 有时在需要平滑非线性函数但原生数学支持有限时使用
在许多 PLC 中不太实用的选项包括:
- 使用昂贵的指数运算进行精确的 Sigmoid 或 Tanh 计算
- 需要不支持的库的动态激活方案
- 依赖运行时图行为的架构
在控制工作中,有界行为通常优于优雅但不可测试的行为。
如何将神经网络输出转化为异常检测逻辑?
只有当输出与定义的控制动作挂钩时,异常检测才具有操作意义。“模型产生了 0.83”还不是一个工程结果。
可用的实现需要:
- 定义的异常分数
- 阈值或分类规则
- 如果预期有噪声,则需要去抖动或持久性规则
- 清晰的控制响应
例如:
- 设置 `AnomalyDetected := TRUE` - 丢弃 `MotorRunPermissive := FALSE`
- 如果异常分数 > 阈值持续 500 ms
- 锁定报警
- 根据理念要求操作员或主管重置
该逻辑必须用控制术语而非 ML 术语来记录。
异常检测的操作定义
在本文中,异常检测意味着:
> 读取一组有界的输入过程,在 PLC 任务内执行确定性的前馈推理块,将所得分数与定义的阈值进行比较,并在满足阈值条件时更改控制状态变量(如允许条件、报警或顺序保持)。
这个定义是有意缩小的。它是可观察、可测试且适合验证的。
将神经网络转换为 PLC 逻辑时,主要的工程风险是什么?
主要风险是扫描溢出、数值不匹配和虚假信心。
1. 扫描时间和看门狗风险
矩阵算术会消耗任务时间。如果推理块太大或结构不合理,可能会触发看门狗故障或降低控制响应能力。
风险因素包括:
- 大型矩阵
- 在快速任务中频繁执行
- 大量使用浮点运算
- 在同一周期内重复归一化和缩放
- 不必要的重复计算
缓解措施包括:
- 减小模型尺寸
- 在适当的情况下将推理移动到较慢的周期性任务中
- 预计算常数
- 使用有界执行测试
- 在部署前验证最坏情况下的扫描影响
2. 数据类型和精度不匹配
在 `float64` 中训练并在 `REAL` 中部署的模型在阈值处表现可能不同。这种差异在数值上可能很小,但在操作上可能很大。
检查:
- 数值范围
- 缩放一致性
- 阈值敏感度
- 控制器特定的浮点行为
3. 索引和矩阵方向错误
转置的矩阵、偏移的索引或错误的偏置映射可能会产生看起来合理但完全错误的结果。
这就是为什么确定性验证很重要。算术错误通常“礼貌”到足以通过编译。
4. 无效输入行为
缺失的传感器、陈旧的值、饱和的变送器或错误的模拟量缩放都可能破坏推理。
定义:
- 在质量不佳时会发生什么
- 块是否自我禁止
- 输出是故障安全、故障中性还是仅报警
- 在维护或启动状态下是否忽略结果
5. 在安全上下文中的误用
神经网络推理块不应仅仅因为它在 PLC 内部就被描述为安全等级。如果它影响安全相关功能,设计、验证和生命周期义务将变得更加苛刻。
OLLA Lab 如何帮助在实时部署前验证这一点?
OLLA Lab 在这里作为高风险调试任务的有界验证环境非常有用。它不是绕过控制器测试的捷径,也不是现场验收的替代品。它是你在硬件和过程时间变得昂贵之前排练故障模式的地方。
在此用例中,OLLA Lab 可以通过以下方式支持工程师:
- 用于构建和审查控制逻辑的基于浏览器的逻辑环境
- 用于在没有物理硬件的情况下运行、停止和观察行为的仿真模式
- 用于跟踪中间值的变量和 I/O 可视性
- 针对模拟设备行为的基于场景的真实测试
- 数字孪生风格的验证工作流,可以将逻辑与预期的机器响应进行比较
对于本文的工作流,其实际价值很明确:
- 编写推理逻辑
- 将输入绑定到模拟的过程变量
- 注入干扰或异常条件
- 观察输出状态变化
- 检查控制响应是否符合预期的理念
这就是 Simulation-Ready 在操作术语中应有的含义:工程师可以在控制逻辑到达实际过程之前,证明、观察、诊断并强化其针对真实过程行为的控制逻辑。
这里的数字孪生验证意味着什么?
在这个有界的上下文中,数字孪生验证意味着针对真实的模拟设备模型测试控制逻辑,以便工程师可以比较:
- 梯形图或结构化文本状态
- I/O 状态
- 过程响应
- 异常条件处理
- 产生的控制动作
这并不意味着模拟模型自动成为现场行为的完美复制品。这意味着逻辑可以在现场部署前针对代表性的机器或过程动态进行排练。
如何在 OLLA Lab 中模拟 AI 驱动的异常检测?
一个实用的工作流是将神经网络视为更大控制叙事中的一个块,而不是作为一个新奇的对象。
一个典型的验证序列是:
- 构建推理块 在结构化文本或支持的控制逻辑工作流中实现导出的权重、偏置、归一化和阈值逻辑。
- 将输入绑定到模拟的过程信号 将模型输入映射到振动、电机电流、温升、压力波动或流量不稳定等变量。
- 定义预期的正常状态 确认模型输出在健康运行期间保持在阈值以下。
- 注入异常条件 引入干扰,如振动振荡、传感器尖峰、漂移或不稳定的负载行为。
- 观察推理输出和控制响应 验证异常分数仅在预期时才超过阈值,并且允许条件、报警或顺序状态正确更改。
- 测量逻辑负担 审查增加的算术运算是否造成了不可接受的执行成本或不稳定行为。
该序列很重要,因为异常检测只有在与过程后果挂钩时才有用。没有动作路径的分数只是一个数字。
你应该从这项工作中保留哪些工程证据?
截图库是薄弱的证据。一份紧凑的验证记录对审查者、指导者和雇主更有用,因为它展示了推理过程,而不仅仅是界面熟悉度。
使用此结构:
- 系统描述 描述设备、过程目标、相关输入以及异常检测块在控制理念中的位置。
- 正确行为的操作定义 准确说明逻辑在正常和异常条件下必须做什么,包括阈值、时序和预期的输出状态。
- 逻辑和模拟设备状态 展示实现的逻辑以及测试期间相应的模拟机器或过程行为。
- 注入的故障案例 记录引入的干扰,如传感器噪声、漂移、振荡或异常负载。
- 所做的修订 记录第一次测试后发生了什么变化——阈值调整、去抖动逻辑、缩放校正、任务放置或矩阵优化。
- 经验教训 总结测试揭示的关于可部署性、误报、扫描负担或控制理念的内容。
这些证据比精美的截图更接近调试判断。
工程师在部署 PLC 常驻神经网络推理前应该验证什么?
部署应由有界验证而非热情来把关。
使用部署前检查清单:
- 模型尺寸适合控制器和任务速率
- 输入缩放匹配训练条件
- 权重和偏置映射正确
- 激活逻辑实现完全符合预期
- 阈值行为已记录
- 定义了不良输入处理
- 测试了最坏情况下的执行时间
- 验证了对异常的控制响应
- 定义了推理块无效时的回退行为
- 计划了特定于现场的调试测试
如果模型无法通过此检查清单,则它尚未准备好进入 PLC。它可能在其他地方仍然有用。
这种方法解决了什么,又没有解决什么?
这种方法解决了一个具体的 OT 问题:如何在不依赖外部推理基础设施的情况下,在 PLC 类控制环境中确定性地执行小型训练模型。
它可以帮助:
- 低延迟异常评分
- 有界局部推理
- 减少控制决策中的网络依赖
- 针对真实过程行为验证模型算术
它不能解决:
- 隐含的安全认证
- 模型治理本身
- 仅通过仿真进行的工厂特定调试
- 大型或复杂神经网络架构对标准 PLC 硬件的适用性
这个界限值得保持清晰。
结论
当模型较小、算术路径明确且执行负担已根据控制器约束进行验证时,将神经网络权重转换为 PLC 结构化文本在技术上是可行的。重点不是让 PLC 模仿 Python 环境,而是将有界的推理功能放置在确定性响应最重要的地方。
工程序列很明确:
- 离线训练
- 导出权重和偏置
- 将其重写为 IEC 61131-3 数组
- 实现前馈数学和激活逻辑
- 验证扫描影响和故障行为
- 针对真实的模拟过程条件测试控制后果
这就是 OLLA Lab 变得具有操作价值的地方。它提供了一个排练矩阵密集型逻辑、观察 I/O 和变量行为、注入异常条件并在现场调试前强化设计的场所。这是仿真的一种可信用法:不是取代现场证明,而是使现场证明不那么鲁莽。
继续探索
相关链接
互联
- 向下链接: 在 OLLA Lab 中运行此工作流。
- 向上链接: 探索工业 PLC 编程中心。
- 横向链接: 相关文章:主题 2 文章 1。
- 横向链接: 相关文章:主题 2 文章 2。