1. 从一条产线改造的纠结说起AI PLC到底解决什么问题去年冬天我去一家做精密冲压的厂子看现场。车间里三台老设备还在跑控制柜里是十几年前的三菱FX系列程序是当年设备厂留下的梯形图注释全是日文连图纸都找不全。老板跟我说想上MES、想做数据采集、想搞预测性维护但一算账光把这三台老设备的控制系统换掉加上停机损失够买半台新冲床了。他问我一句话能不能不换硬件让这些老家伙也“智能”起来这个问题其实代表了当下工业自控领域最真实的需求。新设备出厂就带网口、带OPC UA、带边缘计算网关智能化是顺水推舟的事真正难啃的骨头是那些还在用RS-232、RS-485、甚至只有IO硬接线的存量设备。而AI PLC这个概念恰恰是冲着这个痛点来的——它不是简单地把PLC换成一台工控机而是在保留原有控制逻辑可靠性的前提下给控制系统叠加一层“可编程的智能”。先把概念说清楚。所谓AI PLC目前行业里并没有一个统一的国标定义但从业者普遍认可的理解是在传统PLC的确定性控制循环之上引入AI推理能力、代码生成能力或自适应优化能力的一类控制器或控制方案。它可能表现为三种形态第一种是硬件形态比如带NPU的PLC主控模块能在扫描周期内跑轻量级神经网络第二种是软件形态比如在Codesys或TwinCAT环境里嵌入AI Agent用自然语言生成梯形图或ST代码第三种是边缘形态PLC负责实时控制旁边挂一台边缘盒子跑AI模型两者通过EtherCAT或Modbus TCP交换数据。这三种形态对应的是完全不同的改造路径和成本结构。新设备适合第一种因为出厂就可以选配存量设备适合第二和第三种因为不动原有控制核心改造风险可控。我见过太多项目一上来就说“全部换新”结果预算批不下来项目拖了两年最后不了了之。真正落地的方案往往是“新设备选智能主控老设备加边缘智能”的混合架构。这篇文章想聊的就是这两条路具体怎么走。我会把新设备智能升级的选型逻辑、存量设备改造的通信打通方法、AI代码生成在PLC编程里的实际边界、以及调试阶段最容易踩的坑一条一条拆开讲。不管你是刚入行的PLC编程新手还是做了十几年自控的老工程师只要手头有设备要升级这里面的思路和参数应该都能直接拿去用。2. 新设备智能升级从选型到落地的完整决策链2.1 先分清“智能”是加在控制层还是信息层很多项目一开始就搞混了一件事把AI放在PLC的扫描周期里和把AI放在上位机或边缘层是完全不同的两件事。PLC的扫描周期通常是毫秒级而且要求确定性——也就是说每个周期必须在固定时间内完成不能因为AI推理慢了就导致输出延迟。如果你把一个大模型塞进PLC主循环扫描周期抖动会直接反映到执行机构上轻则产品不良重则设备损坏。所以新设备选型的第一步是判断你的AI需求属于哪一类。如果是实时性要求极高的场景比如高速贴片机的视觉纠偏、伺服压装的力控曲线实时调整那AI推理必须放在控制层而且模型必须经过量化剪枝小到能在1到5毫秒内跑完。这类场景目前主流做法是用带NPU的PLC主控比如某些支持ONNX Runtime的控制器模型大小控制在几MB以内输入输出直接映射到PLC的IO变量。如果是非实时或准实时的场景比如设备健康度评估、能耗优化、工艺参数推荐那AI完全可以放在边缘层或信息层。PLC只负责把关键数据通过Modbus TCP或OPC UA推上去边缘盒子跑模型结果再写回PLC的设定值寄存器。这种架构的好处是模型可以做得很大更新也方便不影响控制确定性。我一般建议客户在选型前先填一张表把每个AI功能按“响应时间要求”“模型大小”“是否影响安全”三个维度打分。响应时间在10毫秒以内的走控制层100毫秒以上的走边缘层介于两者之间的看模型大小超过50MB的一律走边缘层。这张表填完架构基本就定了。2.2 控制层AI的硬件门槛不是所有PLC都能跑模型如果你确定要把AI放在控制层那选型时第一个要看的不是CPU主频而是内存带宽和NPU算力。传统PLC的CPU是为逻辑运算和PID控制设计的内存通常只有几MB到几十MB跑一个稍微像样的神经网络就爆了。带AI能力的PLC主控内存至少要在512MB以上最好有独立的NPU或GPU核。第二个要看的是实时操作系统的支持程度。目前主流方案有两类一类是基于RTOS的硬实时系统比如VxWorks或RT-Linux扫描周期可以稳定在1毫秒以内另一类是基于Linux的软实时系统比如Codesys Runtime on Linux扫描周期通常在5到10毫秒。如果你做的是运动控制必须选硬实时如果只是逻辑控制和数据采集软实时够用。第三个容易被忽略的是模型部署工具链。有些PLC厂商宣传支持AI但只支持自家训练框架导出的模型你想用PyTorch训练的模型还得转好几道精度损失不说调试周期也长。选型时一定要问清楚支持不支持ONNX标准格式有没有Python API可以远程更新模型模型更新时需不需要停机我去年帮一个做包装机械的客户选型他们要在控制层做视觉检测要求扫描周期2毫秒模型大小8MB。对比了三家最后选了一家支持ONNX Runtime、带1TOPS NPU、内存1GB的控制器。实测下来模型推理耗时1.2毫秒加上IO刷新和逻辑运算整个周期稳定在1.8毫秒满足要求。如果当时选了只有CPU没有NPU的方案推理就要8毫秒以上根本没法用。2.3 信息层AI的通信选型OPC UA和Modbus TCP怎么选新设备如果走边缘智能路线通信协议的选择直接决定了后期数据采集的便利性。目前工业现场最常用的两种是OPC UA和Modbus TCP。Modbus TCP简单、轻量、几乎所有PLC都支持但它的数据模型是扁平的只有寄存器地址没有语义信息。OPC UA复杂、有完善的信息模型可以带数据类型、单位、描述但需要PLC端有对应的服务器支持。我的经验是如果只是采集几十个变量做趋势分析Modbus TCP足够了配置快调试简单。但如果要做设备模型化管理比如把一台设备的所有参数组织成对象支持浏览和订阅那必须上OPC UA。现在很多新PLC出厂就带OPC UA服务器选型时优先选这类。还有一个实际问题是通信负载。Modbus TCP是轮询机制采集频率高了会占用PLC的通信资源。OPC UA支持订阅和发布数据变化时才上报对PLC的负担小很多。我见过一个项目用Modbus TCP以100毫秒周期采集200个变量PLC的通信负载到了40%扫描周期开始抖动。后来换成OPC UA订阅模式负载降到8%问题解决。2.4 新设备升级的预算分配别把钱全花在硬件上很多项目预算批下来80%花在买新控制器和传感器上留给软件和调试的钱不到20%。这是典型的误区。AI PLC的升级硬件只是载体真正的价值在模型训练、数据清洗、逻辑重构和现场调试上。我一般建议预算按“硬件40%、软件30%、调试30%”来分。软件部分包括AI模型的训练和优化、PLC程序的改造、通信中间件的配置、上位机或MES的接口开发。调试部分包括现场联调、模型精度验证、异常工况测试、操作人员培训。这两块如果预算不够项目上线后问题会层出不穷。还有一个隐性成本是停机窗口。新设备升级可以在出厂前完成但如果是产线中间的设备停机一天可能就是几十万的产值损失。所以升级方案要尽量设计成“离线预调试、在线快速切换”把现场停机时间压缩到最短。3. 存量设备改造不换PLC也能接上AI的三条路3.1 第一条路利用原有通信口做数据旁路存量设备最宝贵的资产是它还能正常干活。改造的第一原则是不动原有控制逻辑只做数据旁路。具体做法是找到PLC上闲置的通信口或者用通信扩展模块增加一个口把关键数据读出来送到边缘网关AI模型在网关上跑结果通过另一个通道写回PLC的设定值寄存器。这里的关键是通信口的选择和参数匹配。以三菱FX系列为例圆头8针口是RS-422可以同时接编程口和触摸屏但通信速率和协议是固定的。如果要加Modbus RTU需要加一块FX3U-485ADP模块设置好站号、波特率、数据位、停止位、校验方式。这些参数必须和边缘网关侧完全一致否则通信不上。我踩过的一个坑是通信超时设置。老PLC的通信处理能力有限如果边缘网关轮询太快PLC来不及响应就会丢包。后来把轮询周期从100毫秒改成500毫秒超时时间从200毫秒改成1秒通信就稳定了。这个参数没有标准值要根据PLC的型号和负载现场试。还有一个细节是数据地址的映射。老设备的程序注释可能不全你需要通过监控PLC的寄存器值结合设备动作来反推每个地址的含义。比如D100是设定速度D101是实际速度M50是运行标志。这个过程很费时间但必须做否则采上来的数据没法用。3.2 第二条路IO硬接线加装智能采集模块有些更老的设备PLC连通信口都没有只有IO硬接线。这种情况下可以在不改变原有IO回路的前提下并联一套智能采集模块。具体做法是用高阻抗的采集端子并联在原有IO线上采集模块把开关量或模拟量转换成数字信号通过以太网或无线传到边缘层。这种方案的优点是完全不影响原有控制采集模块故障了也不影响设备运行。缺点是接线工作量大而且模拟量采集需要校准。我做过一个项目一台老式注塑机没有通信口只有继电器输出。我们在每个电磁阀的线圈上并联了一个电流传感器通过电流波形判断阀门动作状态。采集模块用24V供电信号走RS-485到网关。整个改造花了三天没有停机设备照常生产。需要注意的是并联采集的阻抗匹配。如果采集模块的输入阻抗不够高会分流原有IO信号导致PLC误判。一般要求采集模块的输入阻抗在1兆欧以上。另外模拟量采集要加隔离否则地环路会引入干扰。3.3 第三条路软PLC替换原有控制核心如果原有PLC已经停产、备件买不到、程序也改不动那可以考虑用软PLC替换。软PLC是跑在工控机或边缘盒子上的PLC Runtime比如Codesys Control Win或TwinCAT支持IEC 61131-3标准编程同时可以跑AI模型。这种方案的优势是算力不受限、扩展性强一台工控机可以同时跑多个PLC实例和AI模型。劣势是实时性不如硬PLC而且工控机的可靠性需要额外保障比如看门狗、冗余电源、无风扇设计。替换时最大的风险是IO接线和原有程序的移植。原有PLC的IO点需要接到工控机的IO卡上原有梯形图需要重新编译或转换。如果程序复杂移植工作量很大。我一般建议先做小规模验证选一台非关键设备试跑三个月稳定了再推广。还有一个实际问题是操作习惯。老设备的操作工习惯了原来的按钮和指示灯换成软PLC后如果HMI界面变化太大会引发抵触。所以HMI设计要尽量保留原有布局只增加必要的智能功能入口。4. AI代码生成在PLC编程里的真实边界4.1 自然语言生成梯形图能省多少事最近一年AI Agent与PLC编程的结合成了热门话题。很多工具宣称可以用自然语言描述逻辑自动生成梯形图或ST代码。我实测过几个结论是能省掉重复劳动但省不掉核心设计。比如一个典型的自锁程序你输入“按下启动按钮电机运行按下停止按钮电机停止电机运行时再按启动无效”AI可以生成一个标准的自锁梯形图包含启动、停止、自锁触点。这个生成结果基本可用但需要人工检查触点编号和变量名是否和实际IO对应。再复杂一点比如“润滑电动机开始运行3秒后主轴电机运行系统停止时主轴电机先停4秒后润滑电机停”AI也能生成带定时器的顺序控制逻辑。但定时器的预设值、时间基准、以及停止时的优先级处理需要根据实际工艺调整。我的经验是AI代码生成适合标准逻辑片段不适合整机程序。一个完整的设备程序包含模式切换、报警处理、安全连锁、手动自动切换、参数配方等这些逻辑之间有复杂的耦合关系AI目前很难理解全局意图。所以实际用法是用AI生成基础片段人工组装和调试。4.2 代码生成的质量取决于输入描述的精度AI生成PLC代码的质量和你的描述精度直接相关。如果你只说“做一个电机正反转”生成的结果可能缺少互锁、缺少过载保护、缺少启动延时。但如果你说“做一个电机正反转正转和反转之间要有1秒死区过载信号触发时立即停止并报警启动前需要确认安全门关闭”生成的结果就完整得多。我一般建议用结构化描述先写IO分配表再写状态机最后写每个状态的转移条件。比如输入X0启动、X1停止、X2过载、X3安全门输出Y0正转、Y1反转、Y2报警状态待机、正转、反转、报警转移待机且X0且X3→正转正转且X1→待机正转且X2→报警报警且X1→待机把这张表喂给AI生成的代码质量会高很多。但即使这样生成的代码也需要人工审查特别是安全相关的逻辑不能完全依赖AI。4.3 代码生成工具和传统编程环境的集成目前AI代码生成工具和传统PLC编程环境的集成方式主要有三种第一种是插件式比如在Codesys或TIA Portal里装一个AI助手插件选中一段描述生成代码插入到当前POU第二种是独立工具在网页或桌面应用里生成代码然后复制粘贴到编程软件第三种是API式通过Python脚本调用AI接口批量生成代码片段。插件式最方便但受限于编程软件的开放程度。目前Codesys的开放度较高支持脚本和插件西门子的TIA Portal相对封闭第三方插件少。独立工具最灵活但复制粘贴容易出错特别是变量名和数据类型。API式适合批量处理比如一次性生成几十个设备的相同逻辑但需要一定的编程能力。我目前用得最多的是独立工具加人工校对。生成一段逻辑后先在小号字体下通读一遍检查触点编号、定时器预设值、互锁关系然后在仿真环境里跑一遍。确认无误后再下载到实际PLC。4.4 代码生成不能替代的几件事有三件事AI代码生成目前做不了或者做不好。第一是安全逻辑。安全连锁、急停、安全门、光幕这些涉及人身安全的逻辑必须由人工设计并经过安全评估不能由AI生成。第二是工艺参数。比如PID的整定参数、伺服的速度加速度、温控的加热曲线这些需要根据实际设备和工艺试验确定AI给不出准确值。第三是异常处理。设备运行中的卡料、堵转、传感器失效等异常工况处理逻辑往往需要结合现场经验AI很难穷举。所以我的建议是把AI代码生成当成一个“高级代码补全工具”用它处理重复性的、标准化的逻辑片段把省下来的时间用在安全设计、工艺调试和异常处理上。这样既提高了效率又不牺牲可靠性。5. 调试阶段最容易踩的五个坑5.1 通信通了但数据不对字节序和数据类型陷阱通信调试最常见的问题是“能通但数据不对”。比如PLC里D100的值是1000边缘网关读上来是59392或者变成0.001。这通常是字节序和数据类型的问题。Modbus协议本身是大端序但不同PLC厂商的实现可能不同。三菱PLC的32位数据是低字在前西门子是高字在前。浮点数的格式也有差异。解决方法是先用已知值测试。在PLC里给D100写一个已知的整数比如1234然后在网关侧读看读上来是什么。如果不对调整字节序设置。浮点数更麻烦需要确认是IEEE 754单精度还是双精度以及字序。我一般会在网关侧写一个转换脚本把原始寄存器值按正确的字节序和数据类型解析。还有一个坑是数据刷新不同步。PLC的寄存器是连续刷新的如果网关在PLC刷新到一半时读取可能读到一半新值一半旧值。对于32位数据这个问题尤其明显。解决方法是要么用PLC的通信同步机制要么在网关侧做两次读取比对不一致就重读。5.2 AI模型在实验室好用到现场就飘AI模型在实验室的测试集上精度95%到现场跑了一周精度掉到70%。这是很常见的问题原因通常是数据分布漂移。实验室的数据是特定工况下采集的现场的环境温度、物料批次、设备磨损都会导致数据分布变化。解决方法有三个第一是在线学习模型在现场持续采集数据定期更新。但工业现场对模型更新的安全性要求高不能随便更新。第二是域适应在训练时加入多种工况的数据让模型见过更多变化。第三是异常检测当模型置信度低于阈值时自动切换到传统控制逻辑并报警提示人工介入。我一般建议客户在模型上线前先做影子模式运行。也就是模型只推理不控制把推理结果和实际结果对比跑够一个月确认精度稳定了再接入控制。这个阶段虽然不产生直接价值但能避免很多现场事故。5.3 扫描周期抖动AI推理和控制的资源竞争如果AI推理和控制逻辑跑在同一个控制器上资源竞争会导致扫描周期抖动。我见过一个案例PLC的扫描周期原本稳定在2毫秒加了AI推理后周期在2到15毫秒之间跳。原因是AI推理占用了CPU和内存带宽导致控制任务被延迟。解决方法是任务隔离。如果控制器支持多核把AI推理绑到单独的核上控制任务绑到另一个核。如果不支持多核至少要把AI推理放在低优先级任务里控制任务保持高优先级。另外AI推理的输入输出要用双缓冲避免读写冲突。还有一个技巧是限制AI推理的频率。不是每个扫描周期都需要跑AI可以每10个周期跑一次或者数据变化超过阈值时才跑。这样能大幅降低资源占用。5.4 老设备的电磁干扰AI采集模块的接地和屏蔽存量设备改造时AI采集模块往往加装在原有的控制柜里而老控制柜的电磁环境通常很差。变频器、接触器、伺服驱动器都在里面干扰很强。我遇到过采集模块的模拟量输入跳变开关量误触发通信丢包。解决方法是第一采集模块单独供电不要和变频器共用24V电源。第二信号线用屏蔽双绞线屏蔽层单端接地。第三采集模块远离变频器至少保持20厘米距离。第四模拟量输入加RC滤波截止频率根据信号带宽设定。第五通信线用隔离型转换器避免地环路。这些措施看起来简单但现场往往因为空间限制或赶工期被忽略。我一般会在改造方案里专门留一页写接地和屏蔽要求施工时逐项检查。5.5 操作人员不买账智能功能的人机界面设计技术再先进操作人员不用就是白搭。我见过一个项目AI优化功能上线后操作工还是按老方法手动调参数问为什么说“那个智能按钮点了之后不知道会发生什么不敢用”。所以智能功能的人机界面设计要遵循三个原则第一透明让操作工看到AI在做什么比如显示当前推荐参数和实际参数的对比。第二可控AI推荐后由操作工确认才生效不要自动改。第三可回退一键切回手动模式让操作工有安全感。另外培训很重要。不要只发操作手册要在现场手把手教让操作工自己试几次看到效果。我一般会在调试阶段就邀请操作工参与让他们提意见这样上线后接受度会高很多。6. 从现场经验里攒出来的几条实用建议先说选型。如果你手头是新设备项目预算允许的话优先选带OPC UA和ONNX Runtime支持的控制器。这两个特性决定了后期做智能升级时你是“顺水推舟”还是“从头造轮子”。OPC UA让数据采集标准化ONNX让模型部署标准化省下的调试时间远超硬件差价。再说存量改造。老设备改造的第一原则是“最小侵入”。能旁路采集就不要动原有程序能加通信模块就不要换PLC。我见过太多项目为了追求“技术先进”把还能用的老PLC换掉结果新PLC的IO接线和原有设备不匹配停机了一周才恢复。改造方案要按“风险从低到高”排序先做数据采集再做边缘分析最后才考虑控制优化。关于AI代码生成我的态度是“用但不依赖”。用它生成标准逻辑片段比如自锁、互锁、定时器、计数器能省不少时间。但安全逻辑、工艺参数、异常处理必须人工做。另外生成的代码一定要在仿真环境里跑一遍确认无误再下载。调试阶段通信参数要留足余量。轮询周期不要设得太快超时时间不要设得太短给老设备留出响应时间。AI模型的置信度阈值不要设得太高否则频繁报警也不要设得太低否则误动作。我一般建议初始阈值设0.8运行一周后根据误报率调整。最后说一个容易被忽略的点文档。改造过程中所有的通信参数、数据地址、模型版本、调试记录都要整理成文档。我吃过亏一个项目做完半年后客户打电话说数据不对结果发现当时调试的笔记找不到了只能重新排查。现在我会在项目结束时出一份《智能升级配置手册》包含所有关键参数和排查步骤客户和自己都省事。工业自控的智能升级说到底不是把最先进的技术堆上去而是找到可靠性、成本和效果之间的平衡点。新设备有新的做法老设备有老的办法关键是先想清楚要解决什么问题再选合适的路径。上面这些经验都是我在现场一点一点攒出来的希望能帮你少走点弯路。