工业控制器新物种：PLC、HMI与边缘AI一体化部署实战

1. 工业控制器的新物种为什么要把PLC、HMI和边缘AI塞进一个盒子第一次看到宏集DC-Pi这个产品定义的时候我的反应是终于有人把这事想明白了。过去十几年做产线改造最头疼的不是PLC编程本身而是三层架构之间的数据搬运底层PLC负责逻辑控制中间HMI做本地交互上层要么工控机要么网关再往云端传数据。一个简单的检测到异常就弹窗报警并记录特征值需求往往要跨三个硬件平台、两套通信协议、一堆中间件才能跑通。DC-Pi的思路很直接把这三层揉进一台导轨式控制器里。它底层跑的是实时Linux内核上面同时承载IEC 61131-3标准的PLC运行时、基于Web技术的HMI渲染引擎以及一个可以调用NPU或GPU算力的边缘AI推理框架。你可以理解为它把过去需要一台PLC加一块触摸屏再加一台工控机才能干的事压缩到了一个巴掌大的金属壳子里。这东西适合谁我梳理了三类人。第一类是产线设备工程师手头有大量老旧设备要改造但控制柜里已经没有空间再塞新硬件第二类是自动化集成商客户要求设备要能自己判断产品好坏传统PLC做不了视觉推理加视觉盒子又太贵第三类是做预测性维护的团队他们需要在高频振动的现场直接跑FFT和异常检测模型数据不能出设备。这三类人的共同痛点是算力要靠近数据源但传统工控硬件要么没算力要么算力和控制是割裂的。注意边缘AI在工业场景里不是要把大模型塞进控制器而是把轻量级推理任务分类、回归、异常检测下沉到数据产生的地方。DC-Pi的定位是控制推理一体不是替代服务器。我实测过用传统方案做电机轴承故障预警振动传感器接PLC高速计数模块PLC通过Modbus TCP把原始波形传给工控机工控机跑Python脚本做FFT和阈值判断再通过OPC UA把结果写回PLC触发停机。整条链路延迟在200ms以上而且工控机一死整个预警就瘫了。DC-Pi的做法是振动信号直接进它的AI通道推理结果通过内部共享内存直接给PLC运行时延迟压到20ms以内而且没有中间环节。这个产品定义背后有一个关键判断工业现场的数据正在从少量慢速变成大量高速。以前一个温度传感器一秒采一次就够了现在一个振动传感器一秒采几万次一个相机一秒出几十帧图像。这些数据如果全部传到云端或工控机带宽和延迟都受不了。边缘AI的核心价值不是AI本身而是在数据产生的地方完成决策闭环。2. 拆开看门道DC-Pi的硬件架构与软件栈到底怎么搭的2.1 硬件层面的取舍逻辑DC-Pi的硬件配置我拿到手第一件事就是拆机看板子。核心是一颗多核ARM处理器具体型号不同版本有差异但共同点是都带NPU或者至少带一个能跑浮点运算的GPU核。内存配置从2GB起步存储用eMMC加TF卡扩展。接口方面双网口是标配一路千兆做控制网一路百兆做设备网还有RS485、CAN、USB这些工业现场必备的物理层。为什么选ARM而不是x86我一开始也有疑问。后来跟做硬件的朋友聊他给我算了一笔账x86方案要跑实时Linux功耗至少15W起步散热片得加大导轨安装的盒子体积压不下来。ARM方案整机功耗可以控制在5W以内无风扇设计MTBF平均无故障时间能做得更高。工业现场最怕的就是风扇积灰停转然后CPU过热降频产线莫名其妙停机。提示选边缘控制器时功耗和散热往往比绝对算力更重要。一个算力翻倍但需要风扇的盒子在粉尘环境里的实际寿命可能只有无风扇方案的三分之一。存储方面有个细节值得说DC-Pi把系统分区和用户数据分区做了物理隔离。系统分区是只读的用户程序和数据放在独立分区。这个设计的好处是即使你的AI模型把存储写满了系统也不会崩。我见过太多工控机因为日志文件把根分区写满导致无法启动的案例。2.2 软件栈的分层设计DC-Pi的软件栈从下往上我把它分成四层。最底层是实时Linux内核打了PREEMPT_RT补丁任务调度抖动控制在微秒级。这一层决定了PLC逻辑执行的确定性没有这个底子上面跑什么都是空中楼阁。第二层是PLC运行时支持IEC 61131-3的五大语言梯形图、功能块图、顺序功能图、结构化文本、指令表。这意味着你原来在西门子、三菱、汇川上写的逻辑大部分可以迁移过来。我试过把一个西门子S7-200 SMART的梯形图程序手动翻译成结构化文本在DC-Pi上跑扫描周期稳定在1ms以内。第三层是HMI引擎。这里有个关键选择DC-Pi没有用传统的组态软件方案而是用了基于Web技术的渲染引擎。什么意思你的HMI画面本质是一个本地Web应用通过浏览器或者专用客户端访问。好处是画面开发可以用HTML/CSS/JavaScript做出来的效果比传统组态软件灵活得多。坏处是如果你习惯了拖拽式组态需要适应一下代码化的开发方式。第四层是AI推理框架。支持ONNX Runtime和TensorFlow Lite模型可以量化成INT8在NPU上跑。我实测过一个MobileNetV2的图像分类模型输入224x224在NPU上单帧推理时间约8msCPU占用不到15%。这个性能对于大部分工业视觉分拣场景够用了。2.3 三层数据流的内部通路DC-Pi最让我感兴趣的设计是内部数据总线的打通方式。传统方案里PLC变量、HMI标签、AI推理结果分属三个不同的地址空间要交换数据必须走通信协议。DC-Pi的做法是维护一个全局变量表PLC可以直接读写AI推理的输出缓冲区HMI可以直接绑定PLC的变量地址AI推理也可以直接读取PLC采集的原始数据。这个设计带来的直接好处是延迟极低。我写了一个测试程序PLC每1ms采集一次模拟量AI模型每10ms做一次异常检测检测结果通过共享内存直接写回PLC的报警变量HMI每100ms刷新一次显示。整个链路没有任何网络通信全部在单机内完成。用示波器抓PLC输出点的响应波形从异常发生到报警输出总延迟约12ms。注意共享内存方案虽然快但要注意数据一致性。DC-Pi的运行时提供了原子操作和互斥锁的API在结构化文本里可以用__atomic_exchange这类函数保证读写安全。如果你直接裸写内存地址可能会读到半更新的数据。3. 从零搭建一个AI质检PLC分拣的完整实例3.1 场景定义与硬件接线我拿一个典型的零件表面缺陷检测场景来演示。传送带送过来金属零件相机拍照AI判断表面是否有划痕有划痕的零件由气缸推入废品箱合格的继续往前走。这个场景在五金、注塑、电子组装行业非常普遍。硬件清单DC-Pi一台、工业相机USB3.0或GigE接口、光电传感器一个检测零件到位、电磁阀一个控制气缸、24V开关电源。接线逻辑是光电传感器接DC-Pi的数字输入DI0电磁阀接数字输出DO0相机通过USB或网口连接。这里有个坑我踩过工业相机的触发方式。如果用软触发PLC检测到光电信号后通过程序触发相机拍照延迟不稳定。正确做法是用硬触发光电传感器的信号同时接PLC的DI和相机的触发输入相机收到上升沿立刻曝光PLC在同一个扫描周期里记录零件位置。DC-Pi的数字输入响应时间在微秒级硬触发方案下拍照时刻的抖动小于50微秒。3.2 PLC逻辑的编写要点PLC程序用结构化文本写核心逻辑分三段。第一段是零件到位检测和相机触发计数第二段是AI推理结果的读取和分拣决策第三段是气缸动作和超时报警。PROGRAM Main VAR PartDetected : BOOL; PartCount : INT; DefectResult : BOOL; CylinderCmd : BOOL; CylinderTimer : TON; END_VAR // 第一段零件到位计数加一 IF PartDetected AND NOT PartDetected_prev THEN PartCount : PartCount 1; TriggerCamera : TRUE; END_IF // 第二段读取AI推理结果 // AI_Result是共享内存映射的全局变量 IF AI_Result_Valid THEN DefectResult : AI_Result_Class 1; // 1表示有缺陷 AI_Result_Valid : FALSE; END_IF // 第三段分拣动作 IF DefectResult AND PartCount CurrentPartIndex THEN CylinderCmd : TRUE; CylinderTimer(IN : TRUE, PT : T#500ms); IF CylinderTimer.Q THEN CylinderCmd : FALSE; CylinderTimer(IN : FALSE); END_IF END_IF这段代码的关键在于AI_Result_Valid这个握手信号。AI推理是异步的PLC扫描是周期性的必须有一个标志位告诉PLC新结果到了。DC-Pi的运行时支持在AI推理脚本里直接写这个标志位不需要走通信协议。3.3 AI模型的部署与调优模型训练部分我不展开假设你已经有一个训练好的ONNX模型。重点讲部署。DC-Pi提供了一个模型转换工具把ONNX转成它NPU能加速的格式。转换命令大概是这样dcpi-model-convert --input defect_model.onnx \ --output defect_model.nb \ --quantize int8 \ --calibration-data ./calib_images/量化这一步很关键。FP32模型直接跑NPU利用率低延迟高。INT8量化后模型体积缩小到四分之一推理速度提升三到五倍。但量化会带来精度损失必须用校准数据集做后训练量化。我一般准备200到500张现场采集的图片做校准覆盖不同光照条件和零件姿态。推理脚本用Python写DC-Pi的运行时提供了Python绑定import dcpi_runtime as dr import numpy as np model dr.load_model(defect_model.nb) cam dr.Camera(0) while True: frame cam.capture() input_tensor preprocess(frame) output model.infer(input_tensor) defect_prob softmax(output)[1] # 写回PLC共享变量 dr.write_shared(AI_Result_Class, 1 if defect_prob 0.85 else 0) dr.write_shared(AI_Result_Valid, True)阈值0.85是我根据产线误判成本调的。漏判一个缺陷品的成本远高于误判一个合格品所以阈值往高了设宁可错杀不可放过。这个阈值没有标准答案要根据你的质量要求和成本结构来定。3.4 HMI画面的快速开发HMI部分我用DC-Pi的Web HMI框架做了一个简单的监控页面。核心是三个区域实时视频流显示、当前零件检测结果、当日统计总数、合格数、缺陷数、缺陷率。视频流通过WebSocket推送到浏览器延迟在200ms左右对于监控够用了。检测结果用颜色块显示绿色合格红色缺陷操作工一眼就能看出状态。统计数据从PLC变量读取每500ms刷新一次。这里有个实用技巧HMI画面里加一个模型置信度的实时曲线。当置信度持续偏低时说明现场光照或零件批次可能变了模型需要重新校准。这个曲线帮我提前发现过好几次相机镜头被粉尘污染的问题。4. 实际部署中绕不开的坑与排查手册4.1 实时性被破坏的典型原因DC-Pi标称的PLC扫描周期是1ms但实际部署中我遇到过扫描周期抖动到10ms以上的情况。排查下来主要有三个原因。第一个是AI推理线程抢占了CPU。默认配置下AI推理和PLC运行时共享CPU核心。当推理任务负载高时PLC线程被调度器延迟。解决办法是在DC-Pi的运行时配置里把PLC线程绑定到独立核心AI推理绑定到另外的核心。DC-Pi一般是四核处理器我通常分配核心0和1给PLC和系统核心2和3给AI推理。第二个是日志写入阻塞。Python脚本里如果每帧都写日志到eMMC存储I/O会成为瓶颈。改成内存缓冲、批量写入后扫描周期恢复稳定。第三个是网络中断处理。千兆网口在大量数据吞吐时会产生中断风暴如果中断处理线程和PLC线程在同一个核心就会互相干扰。把网口中断绑定到AI核心上可以缓解。提示部署后一定要用DC-Pi自带的实时性监测工具跑至少24小时记录扫描周期的最大值、最小值和抖动分布。标称值只是理想情况实际值才是你产线能接受的依据。4.2 AI模型在现场水土不服的应对实验室训练集准确率99%到现场掉到70%这是边缘AI部署最常见的问题。原因无非三个光照变化、零件批次差异、相机参数漂移。我的应对策略是在线难例挖掘。在推理脚本里加一个逻辑当置信度在0.4到0.6之间时模型拿不准的样本自动保存图片到指定目录。这些难例积累到一定数量后人工标注加入训练集重新训练模型。DC-Pi的存储空间有限我一般设置最多保存5000张满了就覆盖最旧的。另一个技巧是在HMI上做一个模型切换按钮。不同批次的零件用不同的模型文件操作工根据工单切换。这个功能在换线频繁的产线上特别实用。4.3 常见问题速查表现象可能原因排查步骤解决方案PLC扫描周期抖动大AI推理抢占CPU查看CPU占用和线程调度绑定核心隔离PLC线程AI推理延迟突然增大模型被换出内存检查内存占用和swap锁定模型内存禁止swapHMI画面卡顿WebSocket数据量过大查看网络带宽和浏览器性能降低视频分辨率或帧率相机触发不稳定软触发延迟抖动示波器抓触发信号改用硬触发模型准确率下降现场光照变化对比训练集和现场图片重新采集数据微调模型系统启动失败存储写满检查分区使用率清理日志设置日志轮转数字输出无响应输出点过流保护测量负载电流加中间继电器隔离4.4 一个真实的排查案例有一次客户反馈设备运行两小时后AI检测全部失效。我到现场复现发现运行初期正常两小时后推理结果全部变成同一类别。排查过程先看CPU和内存正常再看模型输入发现图像数据全是黑的。顺着查相机发现相机USB连接在运行两小时后断开重连重连后曝光参数被重置为默认值而默认曝光时间太短在车间光照下拍出来就是全黑。根因是USB相机的电源管理策略。DC-Pi的USB口在系统空闲时会进入省电模式导致相机掉线。解决办法是在系统配置里禁用USB自动挂起或者在推理脚本里加相机心跳检测掉线后自动重新初始化并恢复曝光参数。这个问题花了我整整一天但后来成了我部署每台设备的标准检查项。5. 这套方案还能怎么扩展DC-Pi的潜力不止于单机质检。我最近在试的一个方向是多台DC-Pi协同。产线上五台设备各管一段每台都有自己的AI模型但通过内部网络共享推理结果和统计数据。比如第一台检测到来料异常可以提前通知下游设备调整参数。这个架构不需要中心服务器每台DC-Pi既是从节点也是主节点去中心化的思路。另一个方向是把PLC逻辑和AI推理做更深的耦合。现在的做法是AI出结果、PLC做决策两步是分离的。我在想能不能让AI模型直接输出控制参数比如根据缺陷类型自动调整气缸推力。这需要模型输出连续值而不是分类标签对模型的解释性要求更高但值得尝试。还有个实用扩展是模型热更新。产线不能停但模型需要迭代。DC-Pi支持双模型分区一个在跑一个在更新更新完切换。我测试过切换时间在200ms以内对产线节拍没有影响。这个功能让模型的持续优化成为可能而不是像以前那样上线即冻结。最后分享一个我在实际部署中总结的小经验DC-Pi的散热设计是无风扇被动散热安装时一定要保证导轨上下留出至少5cm的空间让空气自然对流。我见过把控制器塞在密封电控柜最底层、周围全是线缆的安装方式夏天机壳温度能到70度以上虽然没死机但NPU会降频推理延迟翻倍。工业现场的环境温度每升高10度电子设备的寿命大约减半这个账要算清楚。