这两年“AI PLC”在工业自控圈里的讨论热度明显上涨，技术会议上几乎每个专场都有人问：PLC到底能不能被AI改造，新项目怎么一步到位，仓库里那一堆还在跑的老设备又该怎么办。我自己从传统PLC项目转到AI赋能方向，前后做了几条产线的升级改造，踩了不少坑，也沉淀出一套还算完整的思路，这篇就把从设备选型到存量改造的完整路径聊透。
先说结论：AI不会取代PLC，PLC也不会消失。AI能干的是那些传统PLC不擅长的事——处理模糊工况、预测故障、自动生成程序骨架。所谓智能升级，不是把PLC换掉，而是在它旁边加一个“会思考的助手”，并且用工程手段保证这个助手绝对动不了控制安全。这篇文章适合三类人看：正在做新产线选型的自动化工程师、手上有存量设备想改造的运维团队、以及准备用AI辅助编程但还没找到切入点的开发者。
1. AI PLC到底是什么，以及这一轮为什么不一样
1.1 传统PLC的强项与边界
传统PLC之所以在工业自控领域扎根几十年，靠的是它的确定性。扫描周期固定、程序执行顺序可预测、故障诊断机制成熟，这些特性让它在电机启停、温度控制、逻辑联锁这些场景里几乎不可替代。你去任何一家工厂的控制室，看到的还是那套东西：机柜里的PLC、触摸屏上的工艺流程、抽屉里的备份程序，这套体系本身是可靠的，也是成熟的。
但它的边界也很明显。第一，它本质上是规则引擎，所有逻辑都要人工写成梯形图或ST语句，遇到振动、声音、图像这类无法用简单阈值描述的信号，传统PLC基本无能为力。比如一个空压机的异响，老师傅听得出问题，PLC听不出，因为声音特征不是几个开关量能表达的。第二，数据是离散的，每个扫描周期只保留当前值，历史趋势要么靠上位机SCADA补，要么干脆没有。很多老旧产线的数据，PLC里根本没存，想回头分析某次故障，翻遍日志都找不到原始波形。第三，编程调试周期长，一条产线有几百个I/O点，工程师花在写逻辑和查逻辑上的时间远超想象。AI的引入正是冲着这三个痛点来的。
1.2 AI PLC不是换血，是加脑
我个人的理解，AI PLC并不是一种全新的PLC，而是分三个层面给传统PLC赋能。
硬件层上，新一代PLC开始集成更高算力的CPU、NPU或GPU模块，能直接在设备端跑轻量级推理模型，不需要把所有信号都送到云端再拿结果，延迟可控、网络断了也能用。工具链层上，大模型和AI Agent被引入到编程环境，能根据自然语言描述自动生成PLC程序骨架，甚至帮你审查逻辑漏洞。应用层上，预测性维护、质量预测、能效优化这些算法开始以软组件的形式部署到控制系统里。
这一轮为什么比之前热闹，关键在于三个条件同时成熟：边缘算力成本降到了工业设备能接受的范围；模型轻量化技术让推理可以在几瓦功耗的芯片上完成；大模型代码生成能力达到了能处理结构化语言的水平。PLC工程师和AI模型之间的鸿沟，第一次被从两端同时拉近。之前我们聊AI落地总说要“上云”，现在设备端自己就能算，这才是AI能真正进工厂的前提。
1.3 工业自控里AI能落地的四个方向
我用一个表来归纳目前验证过、确实能落地的方向，后面章节会围绕新设备和存量设备展开展开。
| 方向 | 典型场景 | AI的角色 | PLC的角色 |
|---|---|---|---|
| AI辅助编程 | 功能块生成、逻辑审查 | 根据需求生成代码骨架 | 执行编译、下载与仿真 |
| 预测性维护 | 电机振动、轴承温度 | 判断异常趋势并预测剩余寿命 | 采集信号、执行报警与停机 |
| 质量预测 | 连续工艺参数与成品抽检 | 实时预测质量指标 | 读取参数并回写调节指令 |
| 控制参数自整定 | PID参数随工况变化 | 根据工况推荐Kp/Ti/Td | 校验参数并按需切换 |
这四个方向有共同点：AI都在做“感知、预测、建议”，PLC始终掌握“执行、联锁、安全”。搞清楚这条边界，后面的架构设计就顺了。很多人一上来就问“AI能不能直接控制这台泵”，我一般都劝他先缓一缓，AI直接替代控制的位置扯得太远了，先让AI把“什么时候该停、什么时候该调”判断出来，让PLC去执行，风险低得多，效果也容易验证。
2. 新设备智能升级：选型、架构与一次落地实操
2.1 新项目选型时真正要看的关键指标
新上一条产线，选型阶段最容易犯的错是只看CPU快不快，不看AI能力能不能用、实时性有没有被稀释。我总结了几个硬指标，选型时对着表格过一遍，比听销售吹半天空泛的“AI-ready”靠谱。
| 评估项 | 关键指标 | 判断逻辑 |
|---|---|---|
| 控制实时性 | 扫描周期、中断响应时间 | 基础扫描周期做到1ms-10ms级别，AI模块不能挤占控制任务 |
| AI算力 | CPU性能、NPU TOPS、内存容量 | 轻量模型推理至少需要1-2 TOPS，复杂视觉需独立AI模块 |
| 软件生态 | 是否支持Linux/容器、ONNX Runtime、Node-RED | 生态决定算法工程师能不能直接参与部署 |
| 通信能力 | OPC UA、MQTT、EtherCAT、TSN | 决定数据能不能顺畅流出来，也是AI拿到数据的前提 |
选型的底层逻辑是：不要买一台“控制很强但AI很弱”的PLC，也不要买一台“AI很强但实时控制不可靠”的盒子。真正合理的是双模架构——控制器保证硬实时，AI模块负责复杂计算，两者通过确定性网络通信。所以我看到有些厂商把AI算力直接做成一个扩展模块插在背板上，这个思路是对的，它让用户可以根据项目需要决定要不要加AI，而不是每台设备都为用不上的算力买单。
另外还要看一个容易被忽视的细节：AI模块上跑的是什么系统。有的PLC自带AI算力但系统封闭，算法工程师想装个Python环境都没办法，这种产品再强也是摆设。我倾向于选支持容器化部署的平台，这样模型打包、回滚都方便，不会出现“模型更新一次要停线半天”的尴尬局面。
2.2 控制闭环不动，AI走旁路
这是整篇文章最重要的一张图，可惜这里画不了图，我用文字把逻辑讲透。新设备智能升级的架构，本质上是两条环路。
第一条是控制闭环：传感器信号进入PLC，PLC按扫描周期执行控制逻辑，输出到执行器。这条路是毫秒级的、确定性的、绝对不能断的。第二条是AI环路：PLC把关键数据周期性地送到AI模块，AI模块跑模型、做预测、算优化建议，然后把结果回传。AI环路是百毫秒级甚至秒级的，它给出的不是硬控制信号，而是建议值或预测结果。
为什么非要这么分？因为AI推理的延迟是不确定的，模型大小不同、算力负载不同、输入数据量不同，推理时间都有波动。如果让AI直接串在控制回路上，一个推理卡顿，整条产线就跟着抖，这在工业现场完全不可接受。旁路架构的好处就是：AI模块挂了、推理超时了、模型算错了，最多建议失效，控制闭环照跑，产线不会停。
实现这个架构时，我建议给AI模块单独设一个数据区，PLC侧用异步读写的方式和它交换数据，而不是在主循环里同步等待AI结果。实际操作中，我会把AI结果放到PLC的一个结构体变量里，带时间戳和质量戳，控制逻辑只有在质量戳有效时才使用这个值，否则走默认参数。这个设计虽然简单，但能挡住很多隐患。
2.3 用AI Agent辅助编程的真实体验
辅助编程是AI PLC应用里门槛最低、见效最快的一环。之前大家觉得大模型写代码离工业很远，但试过之后你会发现，PLC的结构化文本ST语言和功能块FBD，本身语法规则很固定，反而是大模型最容易学会的编程语言之一。
我举一个自己调试过的例子。现场需求是：三台水泵自动轮换，每隔8小时切换一次，切换时先启动备用泵、确认出口压力正常后再停当前泵。这类逻辑用梯形图写要一两个小时，还要反复检查有没有漏联锁。我把需求原话丢给AI Agent，它在几十秒内生成了一个ST程序框架，包含轮换计数器、切换步序、压力确认条件，基本结构是能用的。我拿到之后重点补了三件事：泵的启动联锁条件、变频器故障位处理、手动自动模式切换归属。
这里要提醒一句：AI生成的代码只能当草稿，绝不能直接下载到PLC里跑。安全回路、急停逻辑、工艺联锁这些必须由工程师亲自确认，还要在仿真环境里做完整的逻辑测试。我见过有人拿AI生成的代码直接上线，结果一个互锁条件漏了，差点把泵憋住，这个风险不值得冒。AI Agent在项目里应该定位成“一个随叫随到的编程助手”，帮你把重复性的骨架活干了，把关键回路留给人工。
我给读者一个可以直接用的思路：把AI Agent生成ST代码的流程拆成四步——需求描述输入、生成代码骨架、人工补充联锁与异常分支、仿真验证后下载。每一步的产出物要明确，尤其是第二步和第三步之间的交接，这是代码质量的关键分水岭。
3. 存量设备智能升级：不改硬件怎么接入AI
3.1 先给存量设备做一次摸底
现场大多数情况不是新项目，而是二三十年的老产线还在跑。很多设备连网口都没有，或者走的是RS485串口和Modbus RTU协议，更别提AI推理能力了。干这行的都知道，让老板把还能用的产线整个换掉，基本不可能。所以存量设备的升级路径，核心是在“不改原有控制系统”的前提下，把AI能力嫁接进去。
嫁接之前必须先做摸底，看四件事：第一，PLC到底带不带以太网口或通讯扩展模块，能不能把数据传出来；第二，现有CPU负载还有多少余量，如果扫描周期已经很紧张，就别在PLC本体里塞计算任务；第三，有没有上位机SCADA系统在跑，历史数据有没有沉淀，这决定了模型训练的数据基础；第四，工艺侧能不能接受在关键设备上增加一个网关类的旁路设备。摸底结果基本决定了改造路径：有网口的走协议采集，没网口的加协议转换网关，连串口都困难的，只能加传感器做独立旁路。
我个人做过的改造里，大约六成是加网关的方案，两成是走OPC UA直接从PLC读数据，剩下两成是传感器旁路。网关方案最通用，因为它既不改变PLC程序，也不影响原有监控系统，风险最小。凡是那种“原来运行得好好的、你一碰就出问题”的产线，优先考虑旁路方案，这个经验值很多钱。
3.2 网关采集与反向控制的安全设计
网关方案的链路长这样：PLC的RS485或以太网口接边缘网关，网关按设定周期轮询或订阅PLC里的寄存器区，拿到数据后缓存到本地边缘计算节点，跑AI模型，产出的预测结果和优化建议再回写到PLC的指定寄存器。采数不难，难的是回写。
回写这个动作，在工业现场是敏感操作。正向控制的思路是：AI只写“建议值”到一个专用数据区，PLC里的联锁逻辑负责校验，确认没问题再真正执行。我做的项目里，PLC侧会加三个保险：一是写许可位，AI只有在一段时间内持续置位写许可，PLC才接受它的数据；二是数据新鲜度校验，AI结果的时戳超过设定阈值，PLC直接判无效；三是变化限幅，AI建议值和当前运行值偏差过大时，PLC拒绝使用并报警。这三条看起来简单，但能拦住绝大多数“模型抽风”带来的风险。
网关本身的选择也要注意，别买那种只能采集上传、不能本地算的“透传盒子”。我建议选支持Python或Node-RED的网关，能把数据清洗、特征计算放在边缘侧，原始数据不用全量上云，带宽和存储压力小很多。采集周期怎么定，要看工艺变化的速度，温度变化慢，1到2秒足够；压力变化快，200到500毫秒；振动信号则要在PLC或传感器侧先做特征值提取，不要把几十kHz的原始波形全部搬运走。这个设置直接决定了数据质量和通信负载，值得现场多花点时间实测。
3.3 数据闭环：从采集到模型迭代
存量设备改造最容易翻车的点，不是设备连不上，而是模型没有好数据可喂。很多工厂连历史数据库都没有，或者有数据但标签不全、时间戳对不上。我用一个很通俗的比喻：AI模型像个新来的技术员，你给它看不完整的图纸、错位的记录，它给出的方案自然靠不住。所以数据闭环要先于模型部署，这是个顺序问题。
闭环的完整链路是：PLC点位采集、数据清洗与对齐、特征提取、模型训练、模型评估、边缘部署、在线推理、结果反馈、再用新数据迭代。每个环节都要有明确的负责人和交付物。施工时我习惯从单点开始，选一台故障率最高的电机或一条质量波动最大的产线做试点，把数据采全、把标签补准，先跑出第一个版本的预测模型，让现场看到效果，再逐步扩展到更多设备。
模型训练阶段还要注意工况覆盖问题。只采集某一个季节、某一批原料的数据，换季之后模型预测就会偏。我的经验是至少覆盖一个完整生产周期的数据，包含正常工况、异常工况和中间状态，模型评估的时候除了看准确率，还要看误报率和漏报率，这两个指标在工业现场比准确率更关键——误报太多，操作员会把报警当成狼来了；漏报一次，可能就是设备事故。
4. 实战中踩过的坑与排查实录
4.1 AI推理延迟与PLC扫描周期的冲突
第一个大坑，也是最容易遇到的：AI推理的延迟波动导致控制周期抖动。症状是现场反馈“设备运行不稳了”，但看PLC程序又没改过。排查到后面发现，问题出在AI推理任务和实时控制任务抢CPU资源，推理慢的时候，控制周期被拉长，原本10ms的扫尾周期变成了几十毫秒，伺服和变频器都能感觉到。
解决思路有两条，可以同时用。第一条是物理隔离，把AI推理放到独立的CPU核心、独立AI模块或独立网关里跑，不和实时控制共用一套资源；第二条是异步化，PLC侧采用异步读写的方式和AI侧交互，控制循环不等待AI结果，AI有新结果就更新数据区，没有就沿用上一次有效值。这两条配合起来，基本可以把AI对控制周期的影响降到零。我后来在方案评审时都会强调一句：AI不能作为控制闭环的一个环节存在，只能作为旁路建议者存在，这句话能省掉很多麻烦。
4.2 数据质量才是最大的坑
第二个坑是数据质量。我接手过一个项目，传感器数据都在，但时间戳对不齐——温度是1秒采一次、压力是500毫秒采一次，到了训练阶段才发现特征对齐全乱了，模型效果可想而知。后来我把采集逻辑统一改成按工艺批次对齐，时间戳统一用PLC时钟源分发，才把问题压下去。
还有一种常见情况是数据缺测。通信偶发断线、传感器漂移、维护时把信号线拆了没恢复，都会在数据里留下空洞。如果用带空洞的数据直接训练，模型会把“缺测”本身当成一种特征，线上部署反而容易误判。我的处理办法是在采集网关里做数据质量标记，缺值、超限、跳变都要打标签，训练时把质量不合格的样本剔除或插补，绝不让脏数据混进模型。
4.3 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 |
|---|---|---|
| 控制周期抖动 | 推理任务抢占CPU | 隔离核心、异步推理、AI任务限流 |
| 回写参数不生效 | 写许可未置位、点位映射错误 | 检查PLC侧写许可与寄存器映射表 |
| 模型预测值漂移 | 工况变化、数据分布偏移 | 重新采集近期数据、做模型微调 |
| 网关采集丢点 | 轮询周期过短、从站响应慢 | 增大轮询间隔、改用主动上报机制 |
| 数据时间戳不对齐 | 各采集通道延迟不一致 | 统一时钟源、按批次对齐数据 |
| AI建议被PLC拒绝 | 限幅条件触发、时戳超阈值 | 检查限幅参数、确认AI侧数据新鲜度 |
这份表格是我从多个项目里提炼出来的，基本覆盖了存量设备改造上线后三个月内最常碰到的问题。遇到问题先别急着改程序，按表格里的排查方向一步步来，大多数情况都能定位到根因。
5. 一些经验沉淀
从新设备选型到存量设备改造，我最大的体会是：AI PLC项目成功的关键不在AI模型多厉害，而在工程边界划得多清楚。控制归控制、AI归AI，两个世界可以对话，但不要混在一起。这条原则理解透了，方案评审和现场调试都会顺畅很多。
我给准备上手的朋友三条建议。第一，从试点开始，选一台设备、一条产线，把数据、模型、回写、验证整个流程跑通，比一上来就规划“全厂AI升级”要实际得多，试点成功后的推广阻力会小很多；第二，自动化工程师要主动补一点数据思维，不一定要会训练模型，但至少要知道什么叫特征、什么叫标签、什么叫过拟合，因为你才是那个给算法工程师提需求的人；第三，交付时要给客户讲清楚AI模型的边界——它能干什么、不能干什么、数据分布变化后需要重新训练。把预期管理好，AI这个工具才能用得长远。
最后再分享一个小技巧：设计阶段就给AI结果留一个手动/自动切换旋钮。哪怕前期对模型很有信心，也一定保留人工接管的可能性。这个旋钮看起来不起眼，但现场操作员信任AI的速度，往往取决于他们手里有没有那个“不行我就切回去”的开关。
