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

1. 工业控制器的新物种为什么要把PLC、HMI和边缘AI塞进一个盒子第一次看到宏集DC-Pi这个产品定位的时候我的反应是这不就是把三台设备硬凑到一起吗。但仔细拆解之后发现这个思路其实解决了一个困扰自动化行业很多年的老问题数据在PLC、HMI和上位机之间的来回搬运既费时又容易丢。传统方案是什么样的一条产线上PLC负责逻辑控制HMI负责本地显示和操作如果要跑AI推理或者做数据上云还得再加一台工控机或者边缘网关。三台设备各跑各的通过Modbus、OPC UA或者私有协议互相通信。这套架构能跑但问题也很明显延迟叠加、故障点增多、现场布线复杂、维护成本高。尤其是当你想在产线端做实时质量检测或者预测性维护的时候数据从PLC到工控机再传到云端一来一回可能几百毫秒就过去了对于高速产线来说根本来不及。DC-Pi的思路是把这三件事整合到一个硬件平台上。它本质上是一台基于ARM架构或者x86架构的工业级计算机但做了大量工业现场的适配宽温设计、DIN导轨安装、多路DI/DO、RS485/RS232、以太网口同时支持IEC 61131-3标准的PLC编程环境内置HMI组态工具还能直接跑容器化的AI推理服务。你可以理解为它是一台能写梯形图的边缘服务器也是一台能跑神经网络的HMI。这个定位适合谁我梳理了一下大概三类人最需要关注产线自动化工程师手头有大量PLC编程和HMI组态的经验但现在被要求做智能化升级不想再额外学一套边缘计算的架构。设备制造商的技术负责人希望把AI能力直接嵌入到设备里卖智能设备而不是设备外挂盒子降低客户的部署门槛。做工业AI落地的开发者模型训好了但部署到现场总是遇到环境不兼容、算力不够、接口对不上的问题需要一个开箱即用的边缘平台。下面我会从架构设计、PLC编程实操、HMI组态、边缘AI部署、常见问题排查几个维度把这个平台的核心细节拆开讲。不是产品说明书式的罗列而是从一个实际做项目的人的角度说清楚哪些地方好用、哪些地方有坑、怎么配置最稳。2. 架构拆解一个盒子跑三套系统的底层逻辑2.1 硬件层面的取舍与设计DC-Pi这类工业控制器硬件上最核心的取舍在于算力与功耗的平衡。工业现场不像数据中心没有空调、没有稳定的市电、空间也有限。你不能塞一块功耗300W的GPU进去散热和供电都扛不住。目前这类产品常见的硬件配置路线有两条路线典型芯片算力范围功耗适用场景ARM架构瑞芯微RK3588、NXP i.MX8系列1-6 TOPSNPU5-15W中低速视觉检测、振动分析、简单预测模型x86架构Intel N100/N305、Atom系列依赖CPU推理可选配低功耗GPU10-30W复杂逻辑控制、多路视频接入、中等规模AI推理我实测过RK3588平台的NPU推理跑YOLOv5s做缺陷检测输入640x640的图像单帧推理大概在30-50ms左右。这个速度对于传送带速度不超过1m/s的产线来说完全够用。但如果你要做多路视频同时推理或者模型参数量超过10M那就得考虑x86加独立GPU的方案了。接口方面DC-Pi通常标配2-4路千兆以太网口其中至少一路支持EtherCAT或Profinet2路RS485、1-2路RS232多路DI/DO通常8进8出起步USB 3.0、HDMI调试用可选4G/5G模块、WiFi宽压输入9-36V DC常见注意不同型号的DI/DO是源型还是漏型接线前一定要确认。我见过有人把源型输出直接接漏型输入结果信号一直为高查了半天以为是程序问题。2.2 软件架构实时任务与非实时任务怎么共存这是整个平台最核心的技术难点。PLC控制要求确定性——扫描周期必须稳定不能因为AI推理占了CPU就导致控制逻辑延迟。而AI推理是非确定性的——模型加载、内存分配、推理时间都有波动。DC-Pi这类平台通常采用实时内核通用内核的混合架构或者通过CPU核心隔离来实现核心隔离方案把CPU的物理核心分成两组一组专门跑实时任务PLC运行时、EtherCAT主站另一组跑通用任务HMI、AI推理、通信。通过内核参数isolcpus把通用任务隔离到指定核心上避免它们抢占实时核心的资源。实时补丁方案在Linux内核上打PREEMPT_RT补丁把PLC运行时作为最高优先级的实时线程AI推理作为普通优先级线程。当实时任务需要CPU时可以抢占AI推理。实际操作中这两种方案往往会结合使用。比如在启动脚本里设置# 将CPU 2和3隔离出来给实时任务使用 # 在GRUB配置中添加 isolcpus2,3 nohz_full2,3 rcu_nocbs2,3 # 启动PLC运行时绑定到CPU 2 taskset -c 2 ./plc_runtime --priority99 # 启动AI推理服务绑定到CPU 0和1 taskset -c 0,1 ./ai_inference_server这样配置之后PLC的扫描周期抖动可以控制在100微秒以内而AI推理即使偶尔卡顿也不会影响控制逻辑。2.3 通信总线三套系统怎么交换数据PLC、HMI和AI模块之间的数据交换通常走共享内存消息队列的方式而不是通过网络协议。原因很简单同一台设备内部走网络协议栈的开销太大了。具体来说PLC运行时维护一个过程映像区Process Image所有I/O状态和内部变量都映射在这块内存里。HMI通过共享内存直接读取过程映像区刷新周期可以做到10ms以内。AI模块通过消息队列订阅它关心的变量比如当触发信号为高时读取当前相机图像和PLC的编码器位置。对外通信则走标准协议Modbus TCP/RTU、OPC UA、MQTT。这样上位的SCADA或者MES系统不需要知道内部是怎么组织的按标准协议来就行。3. PLC编程实操从梯形图到AI触发逻辑3.1 编程环境的选择与配置DC-Pi支持的PLC编程环境通常有两种路线路线一CODESYS Runtime这是目前最主流的方案。CODESYS提供了完整的IEC 61131-3编程环境支持梯形图LD、功能块图FBD、结构化文本ST、指令表IL、顺序功能图SFC五种语言。你可以在Windows上装CODESYS开发环境通过以太网把程序下载到DC-Pi上运行。配置步骤大致如下在CODESYS中新建项目选择对应的设备描述文件DC-Pi的厂商会提供。配置通信通道需要知道DC-Pi的IP地址和端口号。CODESYS默认用1217端口做网关通信。在设备树中扫描网络找到DC-Pi设备设置好AMS NetID如果是支持ADS协议的话或者直接走以太网。编写程序编译下载。实操心得CODESYS的网关有时候会抽风扫描不到设备。我的经验是先把Windows防火墙关掉试一下如果还不行直接在CODESYS的网关配置里手动添加DC-Pi的IP不要依赖自动扫描。路线二厂商自研编程工具有些厂商会基于CODESYS做二次封装或者用自己的编程环境。这种方案的好处是跟硬件的适配更紧密坏处是生态相对封闭遇到问题查资料不如CODESYS方便。3.2 一个典型的AI触发逻辑怎么写假设我们要做一个场景传送带上的产品经过相机时PLC触发相机拍照AI推理判断是否合格结果通过PLC输出到分拣机构。PLC端的逻辑大概是这样的用ST语言写PROGRAM MAIN VAR xTrigger : BOOL; // 触发信号 xResult : BOOL; // AI推理结果 xReject : BOOL; // 剔除信号 tonDelay : TON; // 延时定时器 nEncoderPos : DINT; // 编码器位置 END_VAR // 当产品到达检测位置时触发相机 IF xTrigger THEN // 通过共享内存或消息队列发送触发命令给AI模块 SendTriggerToAI(nEncoderPos); xTrigger : FALSE; END_IF // 接收AI推理结果 xResult : ReceiveAIResult(); // 如果不合格延时后触发剔除 IF NOT xResult THEN tonDelay(IN : TRUE, PT : T#200MS); IF tonDelay.Q THEN xReject : TRUE; tonDelay(IN : FALSE); END_IF ELSE xReject : FALSE; END_IF END_PROGRAM这里的关键点是触发时机和结果同步。触发太早产品还没完全进入视野触发太晚产品已经过去了。通常需要用编码器位置或者光电传感器来做精确触发。结果同步更麻烦。AI推理需要时间如果推理还没完成产品就到分拣位置了那就来不及剔除。解决办法有两个提前触发在检测位置之前就触发相机给AI留出推理时间。缓存结果把推理结果和产品ID绑定等产品到分拣位置时再查表。我一般推荐第二种因为更灵活。具体做法是在PLC里维护一个FIFO队列每个产品进队列时分配一个IDAI结果回来时按ID匹配。3.3 常见PLC编程坑点坑点一扫描周期设置不合理CODESYS默认的扫描周期是10ms但如果你有EtherCAT从站可能需要设到1ms甚至更低。设置太短会导致CPU占用率飙升设置太长会导致控制精度不够。我的经验是先设10ms跑起来然后用CODESYS自带的任务监视器看实际执行时间再逐步调整。坑点二变量映射错误PLC的输入输出变量需要跟硬件接口正确映射。比如DI通道0对应的是%IX0.0还是%IX1.0不同厂商的定义可能不一样。接线之前一定要对照手册确认否则程序逻辑写得再对也没用。坑点三浮点数运算精度PLC里的REAL类型是32位浮点数在做PID运算或者位置计算时可能会有精度损失。如果精度要求高建议用LREAL64位或者把浮点数转成整数运算。4. HMI组态在同一个盒子里做界面是什么体验4.1 HMI方案的选型DC-Pi上的HMI通常有三种实现方式方式一本地HDMI输出触摸屏直接通过HDMI接口接一块工业触摸屏HMI软件跑在DC-Pi上全屏显示。这种方式延迟最低体验最接近传统HMI。缺点是屏幕和控制器之间的距离受HDMI线长度限制一般不超过5米。方式二Web-based HMIHMI以Web应用的形式运行通过浏览器访问。DC-Pi上跑一个Web服务器任何带浏览器的设备平板、手机、电脑都可以访问。这种方式灵活但实时性取决于网络状况。方式三远程桌面在DC-Pi上跑一个VNC或者RDP服务远程客户端连接后操作。这种方式适合调试不适合生产环境长期使用。我一般推荐方式一或方式二。如果现场环境固定用方式一如果需要多终端访问或者远程监控用方式二。4.2 组态工具的实际操作以常见的HMI组态软件为例比如基于Qt的或者Web-based的基本流程是创建画面拖拽控件按钮、指示灯、数值显示、趋势图到画面上。绑定变量把控件跟PLC变量关联起来。比如一个指示灯绑定到MAIN.xRunning当变量为TRUE时显示绿色。设置交互按钮的点击事件绑定到PLC的某个变量或者函数块。配置通信设置HMI跟PLC运行时的通信方式。同一台设备内部通常走共享内存不需要配置IP和端口。下载运行把组态好的画面部署到DC-Pi上启动HMI服务。注意HMI的刷新周期不要设得太短。我见过有人设成10ms结果CPU占用率直接拉满。一般50-100ms就够了人眼根本感觉不到差别。4.3 HMI与AI的联动这是DC-Pi比较有意思的地方HMI不仅可以显示PLC的数据还可以显示AI推理的结果。比如实时显示相机画面和检测结果OK/NG显示AI模型的置信度分数统计当班次的合格率、缺陷类型分布提供AI模型的切换按钮比如换产品型号时切换不同的检测模型实现方式通常是HMI通过API调用AI模块的接口获取推理结果和统计数据。这部分需要AI模块暴露RESTful API或者WebSocket接口。5. 边缘AI部署从模型训练到产线落地5.1 模型选择与优化工业场景的AI模型跟互联网场景有很大不同。互联网场景追求精度工业场景追求精度和速度的平衡而且对误检率、漏检率有严格要求。常见的模型选型思路任务类型推荐模型输入尺寸推理时间RK3588 NPU缺陷检测YOLOv5s/YOLOv8n640x64030-50ms分类MobileNetV3224x2245-10ms异常检测AutoEncoder256x25610-20ms时序预测LSTM/TCN窗口长度1005-15ms模型优化的关键步骤量化把FP32模型转成INT8推理速度可以提升2-4倍精度损失通常在1%以内。用RKNN Toolkit或者ONNX Runtime的量化工具都可以做。剪枝去掉模型中不重要的通道减小模型体积。对于工业场景通常剪掉30-50%的通道对精度影响不大。算子融合把ConvBNReLU融合成一个算子减少内存访问次数。5.2 部署流程以RK3588平台为例完整的部署流程是# 1. 在PC上训练模型导出ONNX格式 python train.py --epochs 100 --export onnx # 2. 用RKNN Toolkit转换模型 from rknn.api import RKNN rknn RKNN() rknn.config(target_platformrk3588) rknn.load_onnx(modelmodel.onnx) rknn.build(do_quantizationTrue, datasetcalibration.txt) rknn.export_rknn(model.rknn) # 3. 把rknn模型拷贝到DC-Pi上 scp model.rknn root192.168.1.100:/opt/ai/models/ # 4. 在DC-Pi上启动推理服务 cd /opt/ai ./inference_server --model models/model.rknn --port 8080推理服务通常用Python或者C写暴露一个HTTP接口或者gRPC接口。PLC通过共享内存或者消息队列跟推理服务通信。5.3 AI与PLC的同步问题这是实际项目中最容易出问题的地方。AI推理是异步的PLC控制是同步的两者怎么配合我的做法是PLC在触发相机的同时把当前的产品ID和编码器位置写入共享内存。AI模块从共享内存读取触发信息执行推理把结果写回共享内存的另一个区域。PLC在分拣位置读取结果根据产品ID匹配。这里的关键是共享内存的读写要加锁否则可能出现PLC读到一半数据被AI模块改写的情况。通常用信号量或者互斥锁来保护。实操心得共享内存的大小要提前规划好。我见过有人只分配了1KB结果产品ID队列一满就溢出导致数据错乱。建议至少分配64KB留足余量。6. 常见问题与排查技巧实录6.1 PLC相关问题CODESYS扫描不到DC-Pi设备排查步骤确认DC-Pi的IP地址和PC在同一网段。关闭Windows防火墙和杀毒软件。在CODESYS网关配置中手动添加设备IP。检查DC-Pi上的CODESYS运行时是否已启动systemctl status codesys。问题PLC程序下载后不运行可能原因程序中有编译错误但被忽略了。重新编译看输出窗口有没有警告。目标设备处于STOP状态。在CODESYS中点击启动按钮。授权过期。CODESYS Runtime需要授权检查授权文件是否有效。问题EtherCAT从站不响应排查思路检查网线是否插对端口EtherCAT主站通常需要专用网口。用ethercat master命令查看主站状态。确认从站的ESI文件已正确安装。检查从站的供电和拨码开关设置。6.2 HMI相关问题HMI画面刷新卡顿优化方向降低刷新周期从10ms调到100ms。减少画面上同时刷新的控件数量。把趋势图的数据采样周期调长。检查CPU占用率如果AI推理占了太多资源考虑做核心隔离。问题HMI按钮点击无反应常见原因按钮的变量绑定错误。PLC程序中没有处理该变量的逻辑。HMI服务跟PLC运行时的通信中断。检查共享内存是否正常。6.3 边缘AI相关问题模型推理结果不稳定排查方向输入图像的质量是否稳定光照、焦距、曝光。模型是否做了充分的量化校准。推理服务的输入预处理是否跟训练时一致。是否存在内存泄漏导致推理结果异常。问题AI推理影响PLC扫描周期解决方案做CPU核心隔离把AI推理绑定到非实时核心。降低AI推理的频率比如从每帧推理改成每3帧推理一次。使用NPU而不是CPU做推理释放CPU资源。如果以上都不行考虑把AI推理放到独立的边缘网关通过以太网跟DC-Pi通信。6.4 系统级问题问题DC-Pi频繁重启可能原因供电电压不稳定。用万用表测量输入电压确认在9-36V范围内。散热不良。检查散热片和风扇是否正常工作环境温度是否超过规格。看门狗触发。检查系统日志dmesg和journalctl看有没有内核panic或者硬件错误。问题网络通信时断时续排查步骤用ping测试基础连通性。用ethtool检查网口状态和错误计数。检查网线是否屏蔽层接地良好。确认没有IP地址冲突。7. 项目落地的几点个人体会做工业控制器边缘AI的项目技术只是一部分更多时候是在跟现场环境、客户需求、成本预算做博弈。我踩过的几个坑分享出来供参考。第一不要追求一步到位。很多客户一上来就说要做黑灯工厂要全自动AI检测。我的建议是先做单点验证选一个工位把AI检测跑通稳定运行一个月再考虑推广。否则一旦出问题整条线停摆压力全在你身上。第二留好手动切换的退路。AI模型再准也有出错的时候。HMI上一定要有一个切换到人工模式的按钮让操作工可以在AI异常时接管。这不是技术问题是生产管理的要求。第三日志和监控比模型精度更重要。我见过太多项目模型精度做到99.5%但一出问题就抓瞎因为不知道是图像质量的问题、模型的问题还是通信的问题。建议从第一天就把日志系统建好每张图像的推理结果、置信度、耗时都记录下来方便回溯。第四跟现场操作工搞好关系。他们是最了解产线实际情况的人。有时候模型检测不出来的缺陷操作工一眼就能看出来。多跟他们聊了解他们的判断标准对优化模型很有帮助。第五成本要算清楚。DC-Pi这类一体化方案单台设备的价格可能比PLC工控机网关的组合贵一些但省了布线、省了调试时间、省了故障点。如果算总拥有成本TCO通常还是划算的。但如果项目预算特别紧张也可以考虑分步实施先上PLCHMIAI功能后续再加。最后说一个实际的小技巧DC-Pi的固件和软件栈建议在项目开始前就锁定版本不要中途升级。我吃过这个亏——项目做到一半厂商发布了新固件升级之后AI推理的接口变了所有调用代码都得改。后来学乖了项目启动时就把版本号记下来整个项目周期内不升级等交付后再统一评估。