工业自控这行干了十几年我见过太多厂里的设备“新旧混杂”的场面一边是刚上的自动化产线一边是跑了十来年的老继电器柜。老板们嘴上说着要搞智能升级真到掏钱的时候又犯嘀咕——新设备好办直接选带AI能力的控制器就行可那些存量设备怎么办全换掉成本太高不换又跟不上数据采集和远程运维的需求。这两年AI PLC这个概念热起来之后我陆续在几个项目里试了不同的路子有踩坑的也有跑得挺稳的。这篇就把新设备和存量设备两条线的升级思路拆开讲从选型逻辑到实操配置再到现场调试的坑尽量说透。1. 先搞清楚AI PLC到底是个什么东西1.1 从传统PLC到AI PLC的演进逻辑传统PLC的核心任务是“确定性控制”——输入信号进来按照梯形图或ST语言写好的逻辑输出对应的动作。它不关心这个动作是不是最优只关心是不是按程序执行。这套逻辑在稳定生产上没问题但遇到工况变化、参数漂移、能耗优化这类需求传统PLC就抓瞎了因为它没有“学习”和“推理”的能力。AI PLC不是把PLC换掉而是在传统PLC的确定性控制层之上叠加了一层“推理与优化层”。这层通常跑在边缘侧可以是PLC本体集成了NPU也可以是PLC旁边挂一个边缘计算盒子。它的工作方式是从PLC采集实时数据用训练好的模型做推理输出优化后的设定值或控制策略再写回PLC执行。整个过程对原有控制逻辑是“旁路”的不破坏原有的安全联锁。我个人的判断是现阶段真正落地的AI PLC项目八成以上都是这种“PLC边缘推理”的架构而不是把AI模型直接塞进PLC的扫描周期里。原因很简单——PLC的扫描周期是毫秒级的AI推理再快也有几十毫秒的延迟直接串在控制回路里风险太大。1.2 AI PLC能解决的三类实际问题第一类是参数自整定。比如注塑机的温度控制、挤出机的压力控制传统PID参数是工程师凭经验调的换一批原料或者环境温度变了控制效果就下降。AI PLC可以基于历史数据在线辨识对象特性自动调整PID参数把超调量和稳态误差压下去。第二类是异常检测与预测性维护。电机的电流波形、轴承的振动频谱、阀门的动作时间这些数据在传统PLC里只是被采集不会被分析。AI PLC可以在边缘侧跑异常检测模型提前几小时甚至几天发现设备劣化趋势把非计划停机变成计划检修。第三类是多目标优化。比如中央空调系统既要保证温湿度达标又要让能耗最低。传统做法是人工设定几个工况点AI PLC可以基于实时负荷预测动态调整冷冻水出水温度、水泵频率、冷却塔风机转速把能耗压下来。这类场景在商业综合体和数据中心已经有不少案例。1.3 新设备与存量设备的升级路径差异新设备上AI PLC本质是“从设计阶段就按智能架构来”。选型时直接选支持边缘计算扩展的PLC平台通信协议走OPC UA或者MQTT数据模型从第一天就建好。这条路相对顺因为没有任何历史包袱。存量设备的升级就麻烦得多。老设备可能用的是西门子S7-300、三菱FX系列、欧姆龙CPM系列通信口只有RS-485或者MPI连以太网都没有。这种情况下升级路径通常是“先解决数据采集再叠加AI推理”。数据采集这一关过不去后面全是空谈。2. 新设备选型从第一天就按智能架构来2.1 控制器选型的三个硬指标选AI PLC第一个指标是算力冗余。不要只看当前项目需要多少IO点要看未来三年内可能接入的AI模型规模。一个轻量级的异常检测模型推理一次大概需要几十兆的算力如果要做视觉检测或者多变量优化算力需求会翻几倍。我一般建议选型时留出至少50%的算力余量。第二个指标是通信开放性。必须支持OPC UA、MQTT、Modbus TCP这三种协议。OPC UA用于和上层MES/SCADA对接MQTT用于和云平台通信Modbus TCP用于和第三方设备集成。如果PLC只支持私有协议后面做数据集成会非常痛苦。第三个指标是实时性与AI推理的隔离机制。好的AI PLC平台会把实时控制任务和非实时推理任务跑在不同的核上或者用实时操作系统做任务调度确保AI推理不会阻塞控制扫描。这一点在选型时一定要问清楚很多厂商的宣传材料里不会写。2.2 通信架构设计别让数据堵在路上新设备的通信架构我推荐“三层两网”的结构。三层是设备层、边缘层、平台层两网是控制网和信息网。设备层用EtherCAT或者Profinet保证控制指令的实时性。边缘层用OPC UA做数据汇聚把不同协议的数据统一成标准模型。平台层用MQTT上云做长期存储和大数据分析。这里有个容易忽略的点边缘层到平台层的带宽规划。如果每台设备每秒上传100个测点一个车间50台设备就是每秒5000个数据点。按每个点50字节算每秒250KB一天就是20GB。这个量级如果不做本地预处理和压缩云端的存储成本会很高。我的做法是在边缘侧做“变化上报”和“死区压缩”只上传有意义的数据变化。2.3 数据模型设计从第一天就建好字典新设备的最大优势是可以从第一天就按标准建数据模型。我一般用ISA-95的设备层级来组织企业、工厂、车间、产线、设备、部件、测点。每个测点定义好名称、单位、量程、采样频率、数据类型。这个工作看起来繁琐但后面做AI训练和数据分析时省下来的时间是以周计的。我见过太多项目数据采集上来之后发现测点命名混乱同一个物理量在不同设备上叫不同名字清洗数据花了一个月。提示数据模型设计阶段一定要让工艺工程师参与不能只让IT部门拍脑袋。测点的物理含义、正常范围、关联关系只有工艺人员最清楚。3. 存量设备升级先解决“连得上”再谈“算得动”3.1 存量设备的数据采集方案选型存量设备升级的第一步是数据采集。根据设备的新旧程度和通信能力我把它分成三类设备类型通信能力推荐采集方案成本区间近十年设备有以太网口支持Modbus TCP或OPC UA直接通过以太网采集低十到二十年设备有RS-485/RS-232支持Modbus RTU串口服务器转以太网中二十年以上设备无通信口只有继电器和模拟量加装传感器IO模块高第一类设备最省事直接在PLC里开一个Modbus TCP服务端边缘网关作为客户端去读就行。第二类设备需要串口服务器把RS-485转成以太网。这里要注意串口服务器的轮询周期如果一条RS-485总线上挂了多台设备轮询周期会线性增加。我一般建议单条总线不超过8台设备轮询周期控制在500ms以内。第三类设备最麻烦需要加装传感器。比如老式注塑机没有通信口要采集它的能耗数据就得在配电柜里加电流互感器和电压变送器再通过IO模块接入边缘网关。这种方案的改造成本最高但也是存量设备里数量最多的一类。3.2 协议转换与数据归一化实操存量设备采集上来的数据协议五花八门。Modbus RTU、Modbus TCP、Profibus、MPI、CC-Link每种协议的寄存器地址定义都不一样。这时候需要一个边缘网关做协议转换和数据归一化。以西门子S7-200通过Modbus RTU接入为例实操步骤如下在S7-200里配置Modbus主站或从站模式。如果S7-200作为从站需要设置站号、波特率、数据位、停止位、校验方式。确定要采集的寄存器地址。S7-200的V存储区可以映射到Modbus的保持寄存器比如VW100映射到40001。在边缘网关里配置Modbus RTU客户端设置轮询周期和超时时间。把采集到的原始数据做归一化处理比如把0-27648的模拟量值转换成0-100%的工程量。这里有个坑不同厂商的Modbus寄存器地址偏移量不一样。有的从0开始有的从1开始。配置的时候一定要用Modbus调试工具先确认一遍不然采集上来的数据全是错的。3.3 边缘计算节点的部署与配置存量设备升级的AI推理层通常是一个独立的边缘计算节点。选型时关注三点算力、接口、防护等级。算力方面如果只做异常检测和参数优化一个四核ARM处理器加2GB内存就够了。如果要做视觉检测需要带GPU或者NPU的节点。接口方面至少要有两个以太网口一个接设备网一个接信息网、两个RS-485口、四个DI/DO。防护等级方面如果装在配电柜里IP20就够了如果装在车间现场至少要IP54。部署位置我一般选在车间的电气柜里靠近被采集的设备。这样走线短信号衰减小。边缘节点和云端之间走MQTTQoS等级设为1保证消息至少送达一次。配置流程大致是先装操作系统通常是Linux再装容器运行时Docker或者containerd然后把AI推理服务打包成容器镜像部署上去。这样做的好处是环境隔离升级的时候不会影响其他服务。4. AI推理层落地模型怎么来怎么跑怎么迭代4.1 模型来源自研、开源还是采购AI PLC的推理模型来源无非三种自己训练、用开源模型、买厂商的成品模型。自己训练适合有数据积累的场景。比如某个化工厂的反应釜温度控制历史数据存了五年工艺工程师对反应机理很清楚这种就可以自己训练一个预测模型。训练工具用Python的scikit-learn或者PyTorch都行关键是要有标注好的数据。开源模型适合通用场景。比如电机异常检测网上有现成的振动分析模型拿过来微调一下就能用。但要注意开源模型的许可证有些只允许非商业用途。买厂商的成品模型最省事但灵活性差。厂商的模型通常是针对特定设备类型训练的换一个品牌或者型号可能就不准了。而且模型是黑盒出了问题不好排查。我的建议是核心工艺环节自己训练通用设备用开源模型非关键环节可以买成品。4.2 模型部署从训练环境到边缘节点的完整链路模型训练通常在服务器或者云端完成训练好的模型需要转换成边缘节点能跑的格式。常见的转换路径是PyTorch模型转ONNX再用ONNX Runtime或者TensorRT做推理。以ONNX Runtime为例部署步骤如下# 在边缘节点上安装ONNX Runtime pip install onnxruntime # 加载模型并推理 import onnxruntime as ort import numpy as np session ort.InferenceSession(model.onnx) input_data np.array([[1.0, 2.0, 3.0]], dtypenp.float32) outputs session.run(None, {input: input_data}) print(outputs)这段代码看起来简单但实际部署时有几个坑。第一是输入数据的维度要和训练时一致差一个维度就会报错。第二是数据类型要匹配训练时用float32推理时也要用float32。第三是模型的输入输出名称要和代码里的一致用Netron打开模型文件可以查看。4.3 推理结果如何写回PLC推理结果写回PLC通常有两种方式一种是边缘节点作为Modbus客户端直接写PLC的寄存器另一种是通过OPC UA的写服务把结果写到PLC的变量节点。第一种方式简单直接但要注意写操作的频率。如果推理周期是1秒一次写操作也是1秒一次对PLC的通信负荷不大。但如果推理周期是100毫秒写操作就要做限幅和滤波避免频繁写导致PLC扫描周期抖动。第二种方式更规范但配置复杂一些。需要在PLC里建好OPC UA的变量节点边缘节点通过UA的Write服务写入。这种方式的好处是数据类型和语义清晰不会出现寄存器地址对不上的问题。我一般推荐第二种方式虽然前期配置麻烦但后期维护省心。5. 现场调试与常见问题排查5.1 通信不通的排查思路通信不通是存量设备升级里最常见的问题。排查思路我总结成“从物理层往上查”先查物理层网线通不通串口线接对没有终端电阻有没有。再查链路层波特率、数据位、停止位、校验方式是否一致。再查网络层IP地址、子网掩码、网关是否配置正确。最后查应用层寄存器地址、数据类型、字节序是否正确。这个顺序不能乱因为上层的问题往往被下层的问题掩盖。我见过一个项目调试了两天发现是RS-485的A/B线接反了。5.2 数据采集不稳定的典型原因数据采集不稳定表现为时断时续或者数据跳变。常见原因有轮询周期太短RS-485总线上设备多轮询周期设得太短导致超时。解决方法是延长轮询周期或者减少单条总线上的设备数量。电磁干扰变频器、伺服驱动器附近的信号线没有屏蔽或者屏蔽层没有接地。解决方法是换屏蔽线屏蔽层单端接地。电源纹波边缘节点的电源和变频器共用一路导致电压波动。解决方法是给边缘节点加装隔离电源或者UPS。5.3 AI推理结果异常的处理AI推理结果异常表现为输出值超出合理范围或者频繁跳变。处理思路检查输入数据推理模型的输入数据是否在训练时的分布范围内。如果输入数据超出范围模型输出会不可靠。检查模型版本边缘节点上跑的模型版本是否和训练时一致。我遇到过升级模型后忘记更新边缘节点的情况。检查写回逻辑推理结果写回PLC时是否做了限幅和变化率限制。如果没有模型输出的噪声会被直接放大。注意AI推理结果写回PLC之前一定要在边缘侧做限幅和变化率限制。这是安全底线不能省。6. 几个实操心得和避坑建议6.1 存量设备升级的优先级排序存量设备升级不要贪大求全建议按“先易后难、先关键后一般”的顺序来。先把有以太网口、通信协议标准的设备接进来快速出效果让老板看到数据价值。然后再啃那些只有RS-485的老设备。最后再考虑加装传感器的无通信口设备。这个顺序的好处是前期投入小、见效快后面推进的时候阻力小。6.2 边缘节点的运维管理边缘节点部署下去之后运维是个大问题。几十个节点分散在车间里不可能每个都去现场维护。我的做法是所有边缘节点统一装SSH服务通过跳板机远程登录。推理服务用容器部署升级的时候只换镜像不换系统。每个节点上跑一个健康检查脚本定期上报CPU、内存、磁盘、网络状态。关键节点配置双机热备一台挂了另一台自动接管。6.3 数据安全与访问控制工业数据的安全重点在访问控制。我的做法是边缘节点和云端之间的通信走TLS加密。每个边缘节点分配独立的证书证书过期前自动续期。PLC的写操作做权限分级AI推理只能写设定值不能写安全联锁相关的寄存器。所有写操作记录审计日志保留至少半年。这些措施看起来繁琐但真出了安全问题追责的时候能说清楚。6.4 成本控制的几个关键点存量设备升级的成本大头在采集侧不在AI侧。一个边缘节点的硬件成本可能就几千块但加装传感器、改造配电柜、重新布线这些才是花钱的地方。控制成本的思路优先利用设备已有的通信口能不装传感器就不装。串口服务器和IO模块选国产的性价比高功能够用。边缘节点不要追求高算力按实际推理需求选型留50%余量就行。云端存储用冷热分层近期数据放热存储历史数据放冷存储。我在实际项目里算过一笔账一个中等规模的车间50台存量设备如果全部加装传感器改造成本大概在80到100万。如果只对有通信口的设备做采集成本能压到20万以内。所以前期一定要做设备普查把设备的通信能力摸清楚。最后再分享一个小技巧存量设备升级项目建议先做一个“最小可行验证”选一台设备、一个测点、一个推理场景跑通全链路。这个验证可能只花一周时间但能暴露80%的集成问题。验证跑通了再批量复制风险可控得多。