PLC、HMI与边缘AI三合一：融合控制器架构与实操

1. 工业控制器的新物种当PLC、HMI和边缘AI挤进同一个盒子第一次看到宏集DC-Pi这个产品定位的时候我脑子里蹦出来的画面是一个配电柜里原本要塞三台设备——PLC负责逻辑控制HMI负责人机交互工控机负责跑视觉算法——现在一台巴掌大的控制器全包了。这不是简单的“三合一”硬件堆叠而是把工业控制最核心的三条技术路线在架构层面做了融合。传统产线升级AI能力是什么流程PLC管设备HMI做界面然后单独加一台工控机跑推理中间用OPC UA或者Modbus TCP来回传数据。这套方案我做过不下十个项目每次最头疼的不是算法本身而是数据从PLC到工控机这一跳的延迟和稳定性。产线节拍快的时候视觉检测结果传到PLC再执行分拣中间多出50到100毫秒是常有的事遇到网络抖动直接丢包产线就得停。DC-Pi这类产品的核心价值就在这里把AI推理直接放在控制层。PLC的实时控制周期和AI推理共享同一个计算平台数据不需要跨设备传输推理结果直接写入控制逻辑的寄存器。从“PLC→工控机→PLC”变成“PLC内部闭环”延迟从几十毫秒压到个位数毫秒级别。这个产品适合谁看如果你是做非标自动化集成的手头项目开始出现“视觉引导定位”“缺陷检测”“预测性维护”这类需求但客户预算和柜内空间都有限那这类融合控制器就是你要重点评估的方案。如果你是PLC编程出身想往AI方向靠但不想从头学工控机那一套DC-Pi这种形态能让你在熟悉的IEC 61131-3环境里调用AI能力。如果你是做边缘计算方案的想理解工业现场对“边缘AI”的真实需求边界在哪里这个案例也值得拆解。我下面会从架构设计、核心细节、实操落地和踩坑经验四个维度把这类融合控制器讲透。不是产品说明书是我自己上手和跟同行交流后整理出来的实战认知。2. 架构拆解为什么要把三样东西塞进一个盒子2.1 传统方案的三个断点先讲清楚传统方案到底哪里疼才能理解融合架构的价值。第一个断点是数据链路。PLC通过现场总线采集传感器数据工控机通过OPC UA或Modbus TCP从PLC读数据推理完再写回去。这条链路里PLC的扫描周期通常是1到10毫秒OPC UA的通信周期最快也要10毫秒起步加上工控机上的推理时间整个闭环跑下来50毫秒算快的。对于高速产线比如每分钟300件的包装线50毫秒意味着每件产品之间只有20毫秒的处理窗口根本不够。第二个断点是时间同步。PLC有自己的时钟工控机有系统时钟两者之间的时间戳对齐一直是个麻烦事。做预测性维护的时候振动传感器数据在PLC侧温度数据在另一个模块AI模型需要多源数据对齐后才能判断设备状态。跨设备的时间同步精度能做到1毫秒就算不错了但有些场景需要微秒级对齐。第三个断点是运维复杂度。三台设备三套系统PLC用博图或CODESYSHMI用组态软件工控机跑Linux或Windows。每次改一个逻辑可能要动三个地方。现场调试的时候电气工程师、HMI工程师、算法工程师各管一摊沟通成本极高。2.2 融合架构的技术选择DC-Pi这类产品的架构选择本质上是在回答一个问题实时控制内核和通用计算内核怎么共存。目前主流方案有两种。一种是双核异构一颗芯片里跑两个独立内核一个负责实时控制类似PLC的RTOS一个负责通用计算跑Linux和AI推理两者通过共享内存或高速总线通信。另一种是单核虚拟化在一个高性能处理器上用Hypervisor跑两个虚拟机一个实时域一个非实时域。DC-Pi走的是第一条路。实时域跑IEC 61131-3运行时保证PLC逻辑的确定性扫描周期典型值可以做到1毫秒甚至更低。非实时域跑Linux上面部署AI推理引擎通常是ONNX Runtime或TensorRT、HMI渲染、数据记录等服务。两个域之间通过内部高速通道交换数据延迟在微秒级。这个设计的关键在于隔离。AI推理再重也不会影响PLC的扫描周期。我实测过一个场景在非实时域跑YOLOv5s做缺陷检测CPU占用率飙到80%但实时域的PLC扫描周期波动不超过50微秒。这就是硬实时和软实时的边界划分带来的好处。2.3 HMI的角色变化传统HMI就是个显示终端通过串口或以太网跟PLC通信刷新率低交互简单。但在DC-Pi架构里HMI跑在Linux域上可以直接访问AI推理的中间结果和最终输出。这意味着什么以前HMI只能显示“合格/不合格”这种最终结果现在可以显示缺陷的置信度热力图、检测框位置、甚至实时推理耗时。操作工能看到AI“在想什么”调试阶段特别有用。而且HMI可以直接调用Linux域上的数据库和Web服务做数据看板和远程推送都方便很多。我见过一个包装行业的案例HMI上直接显示每个产品的缺陷类型分布饼图数据来自AI推理结果的实时统计。这在传统架构里需要额外加一台服务器做数据聚合现在控制器内部就完成了。2.4 边缘AI的算力边界说到边缘AI很多人第一反应是“算力够不够”。DC-Pi这类控制器通常搭载的是ARM Cortex-A系列或x86低功耗处理器算力在1到10 TOPS之间如果带NPU的话。这个算力能跑什么模型实测数据YOLOv5s在ARM A72四核上输入640x640推理时间大约80到120毫秒。如果带NPU可以压到20到30毫秒。MobileNetV3分类模型224x224输入CPU推理10到15毫秒NPU上3到5毫秒。对于大多数工业视觉场景——缺陷分类、有无检测、简单定位——这个算力是够用的。但如果你想跑ResNet50做细粒度分类或者做多路视频流同时推理那就得考虑更高算力的边缘服务器了。DC-Pi的定位很明确单路或双路轻量级AI推理与实时控制紧耦合。不是替代工控机做复杂视觉而是把简单AI能力下沉到控制层。3. 核心细节PLC、HMI、AI三线并行的实操要点3.1 PLC编程环境的融合逻辑DC-Pi的PLC编程通常基于CODESYS或类似的IEC 61131-3运行时。如果你之前用惯了西门子博图或三菱GX Works切换到CODESYS需要适应一下但核心概念是通的。关键差异在于AI功能的调用方式。传统PLC编程里你要读一个AI推理结果得通过通信协议从外部设备读。在DC-Pi里AI推理结果被映射成PLC的输入变量就像读一个普通的模拟量输入模块一样。具体怎么映射通常有两种方式。一种是共享内存映射Linux域的推理进程把结果写入指定的共享内存区域PLC运行时通过系统调用读取。另一种是内部通信协议比如用MQTT或自定义的IPC机制PLC侧用功能块订阅。我推荐第一种延迟更低。配置的时候需要注意数据格式对齐AI输出的浮点数置信度映射到PLC的REAL类型检测框坐标映射到INT或DINT数组。字节序和对齐方式要在Linux侧和PLC侧保持一致否则读出来的数据是乱的。注意共享内存映射的地址和大小通常在设备树或启动配置里定义改的时候要同步改PLC侧的变量声明两边对不上会导致PLC运行时崩溃。3.2 HMI组态的关键参数DC-Pi上的HMI通常基于Web技术栈比如Node-RED Dashboard、Grafana或者厂商自研的组态工具。跟传统HMI组态软件比灵活度高很多但实时性需要额外关注。刷新率怎么定PLC变量刷新到HMI显示中间经过Linux域的通信服务。如果HMI刷新率设成100毫秒但通信服务轮询PLC变量的周期是200毫秒那实际刷新率就是200毫秒。这两个参数要匹配。我的经验值状态指示类变量通信轮询周期200到500毫秒足够实时曲线类变量轮询周期100毫秒HMI刷新率100毫秒报警类变量用事件触发而不是轮询PLC侧变量变化时主动推送。HMI上显示AI推理结果的时候有个细节容易忽略推理耗时是波动的。如果HMI每100毫秒刷新一次检测结果但推理有时候要150毫秒才出结果那HMI上会出现“结果跳变”或者“旧结果残留”。解决办法是在PLC侧加一个“结果有效”标志位HMI只在标志位为真时更新显示。3.3 AI模型部署的工程化细节在DC-Pi上部署AI模型不是把训练好的模型文件拷进去就完事。工业现场的约束条件比实验室多得多。模型格式选择。训练通常用PyTorch或TensorFlow部署要转成ONNX。转的时候注意算子兼容性有些自定义算子ONNX不支持得替换成标准算子。转完用ONNX Runtime或TensorRT加载做一次推理验证确保输出跟训练框架一致。输入预处理放在哪。图像预处理缩放、归一化、颜色空间转换可以放在PLC侧用梯形图做也可以放在Linux侧用OpenCV做。我建议放Linux侧PLC侧做图像处理效率太低。PLC只需要触发拍照信号然后把图像数据通过共享内存传给Linux侧。推理线程的优先级。Linux域上跑推理线程优先级要设对。如果推理线程优先级太高会抢占HMI渲染和通信服务的CPU时间太低又会导致推理延迟波动大。通常设成SCHED_FIFO优先级50到70之间具体值要在现场调。模型热更新。产线换型的时候可能需要切换AI模型。DC-Pi支持在Linux域上动态加载新模型但要注意加载新模型期间PLC侧读到的推理结果可能是旧的或者无效的。稳妥做法是PLC侧加一个“模型切换中”的状态位切换期间用默认逻辑兜底。3.4 实时域与非实时域的通信机制这是整个架构里最技术性的部分也是出问题最多的地方。两个域之间的通信通常基于共享内存加中断的机制。Linux侧写完推理结果触发一个中断或信号量PLC侧的实时任务在下一个扫描周期读取。反过来PLC侧要发图像采集触发信号给Linux侧也是类似机制。关键参数是共享内存区域的大小和布局。假设AI输出包括1个置信度浮点数4字节、4个检测框坐标整数16字节、1个类别ID2字节、1个时间戳8字节总共30字节。但实际分配的时候要留余量通常分配4KB或8KB一页的大小方便扩展。通信频率也要考虑。如果PLC扫描周期是1毫秒每个周期都去读共享内存那Linux侧写数据的频率必须跟上。如果Linux侧推理要100毫秒才出一次结果PLC侧每1毫秒读一次就是浪费。更好的做法是PLC侧用事件触发读取Linux侧写完数据后置一个标志位PLC侧检测到标志位变化才读。实操心得共享内存的读写要用原子操作或互斥锁保护。我见过一个案例Linux侧正在写检测框坐标的时候PLC侧同时读读到了半新半旧的数据导致机械臂定位偏移。后来加了双缓冲机制——Linux侧写缓冲区A写完后切换指针指向APLC侧读指针指向的缓冲区——问题解决。4. 实操落地从零搭建一个视觉分拣Demo4.1 硬件准备与接线先列一下我搭Demo用的硬件清单组件型号/规格数量备注融合控制器DC-Pi系列带NPU1核心设备工业相机GigE接口500万像素1触发拍照光源环形LED24V1常亮或频闪传送带小型直流调速1模拟产线气缸分拣机构双作用气缸电磁阀1执行分拣光电传感器对射式NPN输出1触发拍照24V开关电源5A1供电接线逻辑光电传感器检测到产品到位信号接入DC-Pi的数字量输入。PLC逻辑检测到上升沿触发相机拍照同时启动一个定时器做超时保护。相机通过GigE接口连接DC-Pi的网口图像数据通过共享内存传给Linux域的推理进程。推理结果写回共享内存PLC逻辑读取后判断是否合格不合格则驱动电磁阀动作。4.2 PLC侧逻辑编写用CODESYS写这段逻辑核心是一个状态机状态0等待光电传感器触发 状态1触发拍照启动超时定时器500ms 状态2等待推理结果有效标志 状态3读取推理结果判断合格/不合格 状态4驱动分拣机构延时200ms 状态5复位回到状态0超时保护很重要。如果相机没拍到或者推理进程挂了状态机会卡在状态2。超时定时器到时间后强制跳到状态5复位同时置一个报警位HMI上显示“推理超时”。变量映射方面PLC侧声明一个结构体变量AI_Result包含ConfidenceREAL、BBoxARRAY[0..3] OF INT、ClassIDINT、TimestampDINT、ValidBOOL。这个结构体的内存布局要和Linux侧共享内存的布局完全一致。4.3 Linux侧推理服务搭建Linux域上跑一个Python服务用ONNX Runtime加载模型。核心流程import onnxruntime as ort import numpy as np import cv2 import mmap import struct import time # 加载模型 session ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) # 打开共享内存 shm mmap.mmap(-1, 4096, tagnameai_result_shm) def preprocess(image): img cv2.resize(image, (640, 640)) img img.astype(np.float32) / 255.0 img np.transpose(img, (2, 0, 1)) return np.expand_dims(img, axis0) def infer(image): input_data preprocess(image) outputs session.run(None, {images: input_data}) # 后处理提取置信度最高的检测框 # ... 省略NMS等步骤 return confidence, bbox, class_id while True: # 等待PLC触发信号通过共享内存标志位或GPIO if trigger_flag: image capture_image() confidence, bbox, class_id infer(image) # 写入共享内存 shm.seek(0) shm.write(struct.pack(f, confidence)) shm.write(struct.pack(4i, *bbox)) shm.write(struct.pack(i, class_id)) shm.write(struct.pack(i, int(time.time() * 1000))) shm.write(struct.pack(?, True)) # Valid标志这段代码里struct.pack的格式要和PLC侧的结构体对齐。浮点数是4字节整数是4字节布尔是1字节但通常按4字节对齐。对齐问题不处理好PLC读出来的数据全是乱的。4.4 HMI界面组态HMI用Node-RED Dashboard搭主要显示几个区域实时图像区显示相机拍到的原图叠加检测框和类别标签状态指示区当前状态机状态、推理耗时、合格率统计报警区超时报警、推理异常报警参数设置区置信度阈值、分拣延时时间图像显示有个技巧不要在HMI上直接传原始图像数据量太大。Linux侧把图像缩放到640x480编码成JPEG通过WebSocket推给HMI。刷新率控制在5到10帧每秒足够操作工看清检测结果。推理耗时显示用滑动平均不要显示瞬时值。瞬时值波动大操作工看了会紧张。滑动窗口取最近20次的平均值显示出来稳定很多。4.5 联调步骤与验证方法联调分四步走第一步单独验证PLC逻辑。不接相机和AI用模拟信号触发状态机确认分拣机构动作正常超时保护有效。第二步单独验证AI推理。在Linux域上用测试图片跑推理确认模型加载正常输出格式正确。可以用ONNX Runtime的profiling工具看各层耗时。第三步验证共享内存通信。PLC侧写一个测试值到共享内存Linux侧读出来打印反过来Linux侧写PLC侧读。确认数据对齐和字节序没问题。第四步全链路联调。放实物到传送带上观察从触发到分拣的完整流程。用示波器或者逻辑分析仪抓光电传感器信号和电磁阀驱动信号测量端到端延迟。我实测的端到端延迟光电触发到电磁阀动作平均45毫秒。其中相机曝光和传输占15毫秒推理占20毫秒PLC逻辑和输出占10毫秒。这个延迟对于每分钟200件以下的产线是够用的。5. 常见问题与排查技巧实录5.1 推理结果读出来是乱码这是最常见的问题九成是内存对齐没搞对。PLC侧的结构体编译器可能会做对齐填充。比如REAL后面跟INTINT后面可能填充2字节再跟下一个DINT。Linux侧的struct.pack默认不做对齐两边布局就不一致了。解决办法在Linux侧用struct.pack的时候显式指定对齐方式。或者在PLC侧用{attribute pack_mode : 1}取消对齐填充。我通常选后者PLC侧取消填充Linux侧按紧凑格式打包两边约定好每个字段的偏移量。排查方法PLC侧写一个已知值比如置信度写0.5类别ID写3Linux侧读出来打印十六进制看字节分布对不对。5.2 推理延迟波动大原因可能有三个CPU被其他进程抢占、模型输入尺寸不固定、内存交换。先看CPU占用。Linux域上跑top或htop看推理进程的CPU占用率。如果接近100%说明算力不够要么换更小的模型要么加NPU。如果CPU占用不高但延迟波动大看是不是有其他进程在抢CPU比如HMI渲染或者数据记录服务。模型输入尺寸不固定也会导致延迟波动。有些模型支持动态输入尺寸但每次推理都要重新分配内存耗时不稳定。固定成640x640延迟就稳了。内存交换是最隐蔽的。Linux域的内存如果不够推理时会发生swap延迟直接飙到几百毫秒。用free -h看内存使用确保有足够余量。DC-Pi这类设备通常内存不大2GB到4GB跑Linux加推理服务要精打细算。5.3 HMI显示卡顿HMI卡顿通常是通信瓶颈或者渲染瓶颈。通信瓶颈HMI刷新率设太高比如50毫秒刷新一次但通信服务轮询PLC变量的周期是200毫秒那HMI就是在做无用功。把HMI刷新率降到跟通信周期匹配卡顿就消失了。渲染瓶颈HMI上显示图像或者复杂图表Linux域的GPU性能不够。解决办法是降低图像分辨率或者用Canvas而不是DOM来渲染。Node-RED Dashboard默认用DOM图像多了会卡换成uPlot或者ECharts的Canvas模式会好很多。还有一个坑HMI的Web服务跟推理服务抢CPU。如果推理服务把CPU占满了HMI的Node.js进程得不到时间片页面就卡。用cgroups给HMI进程留至少20%的CPU配额。5.4 模型更新后PLC读不到新结果模型热更新的时候Linux侧的推理进程会重启或者重新加载模型。这期间共享内存的Valid标志位可能还是True但数据是旧的。PLC侧读到旧数据用旧模型的结果做判断就出错了。解决办法模型更新前Linux侧先把Valid置False更新完再置True。PLC侧检测到Valid从True变False再变True就知道模型更新过了可以复位一些状态。更稳妥的做法是加一个模型版本号字段。PLC侧记录当前使用的模型版本如果发现共享内存里的版本号变了就重新初始化相关逻辑。5.5 常见问题速查表现象可能原因排查方法解决措施推理结果乱码内存对齐不一致写已知值对比十六进制统一对齐方式或取消填充推理延迟波动大CPU抢占/内存swaptop查看CPU和内存限制其他进程CPU/加内存HMI卡顿刷新率不匹配/渲染瓶颈降低刷新率测试匹配通信周期/换Canvas渲染模型更新后数据旧Valid标志未复位检查更新流程更新前后复位ValidPLC扫描周期波动Linux域干扰示波器测扫描周期隔离CPU核心/提高实时优先级相机触发丢帧触发信号太短逻辑分析仪抓信号加脉冲展宽或改用软触发独家避坑DC-Pi这类设备的网口通常是共享的相机、HMI、远程调试都走同一个网口。如果相机图像传输占满带宽HMI的WebSocket就会断连。解决办法是给相机单独走一个网口或者用VLAN做流量隔离。我吃过这个亏现场调试的时候HMI一直掉线查了半天才发现是相机在抢带宽。6. 选型与扩展这类方案适合什么场景6.1 适合的场景特征不是所有项目都适合上融合控制器。我总结下来满足以下三个特征的项目最适合第一AI需求轻量但实时性要求高。比如视觉有无检测、简单分类、定位引导模型不大但要求推理结果快速反馈到控制逻辑。延迟敏感度在50毫秒以内的场景融合架构优势明显。第二柜内空间紧张。小型设备、移动机器人、分布式产线节点没有空间放工控机。DC-Pi这种巴掌大的控制器可以直接装在设备内部。第三预算有限但想尝试AI。单独买工控机加PLC加HMI成本至少一万起步。融合控制器通常几千块对于小批量项目或者教学科研场景性价比很高。6.2 不适合的场景多路高分辨率视频流分析。比如8路1080P同时做人脸识别算力根本不够。这种场景还是得用工控机加独立GPU。复杂模型训练或微调。边缘设备只做推理训练还是在服务器上做。DC-Pi的算力跑训练不现实。对PLC品牌有强绑定的项目。如果客户指定必须用西门子S7-1500或者三菱iQ-R那融合控制器就进不去。这类产品通常基于CODESYS生态跟主流PLC品牌是竞争关系。6.3 扩展方向DC-Pi这类产品后续可以往几个方向扩展多控制器协同。产线上多个工位各有一个DC-Pi通过实时以太网同步。一个工位的AI检测结果可以广播给下游工位做协同控制。云端模型管理。控制器通过MQTT把推理统计数据和模型性能指标上传到云端云端做模型迭代后下发新模型。这个方向适合大规模部署的场景。AI Agent集成。最近AI Agent很火工业场景里可以用Agent做自然语言交互的HMI。操作工说“把检测阈值调到0.8”Agent解析后直接改PLC变量。DC-Pi的Linux域跑一个轻量级Agent框架是可行的但实时性要求高的操作还是得走传统HMI。我在实际项目里发现融合控制器最大的价值不是省了多少钱或者省了多少空间而是改变了做方案时的思维模式。以前做AI控制的方案第一反应是“怎么把AI结果传给PLC”现在第一反应是“这个AI逻辑能不能直接写在PLC里”。思维模式变了方案架构就变了很多以前觉得麻烦的事情变得简单了。最后分享一个小技巧调试DC-Pi的时候在Linux域上开一个SSH服务用watch -n 0.5 cat /proc/plc_scan_time实时看PLC扫描周期。如果扫描周期波动超过10%说明Linux域有进程在干扰实时域用cgroups把推理进程绑到特定CPU核心上实时域独占另外的核心扫描周期就稳了。这个技巧帮我省了很多现场调试时间。