## 1. 为什么AI PLC的落地路径比大多数人想象的窄上个月我去一家汽车零部件厂交流设备科长跟我抱怨产线上那台用了八年的注塑机程序早就没人敢动了现在想优化一个保压参数老师傅得蹲在机台前试一整天改一次就要停机验证一次。这段话其实把工业自控的真实困境说透了——PLC这套体系强在确定性程序写死之后每个扫描周期都按同一套逻辑执行可问题也出在这份确定性上它不会根据物料批次、环境温度、设备磨损的细微差别主动调整策略一切变化都只能等人去干预。AI和PLC结合最核心的价值就是把AI的“感知、预测、优化决策”能力嫁接到PLC的“实时执行、安全保护”能力上。但这个落地路径行业里喊得很响实际能走通的比厂商宣传的窄得多。原因很简单多数工厂既没有干净的数据也没有算法团队更不敢随随便便让AI直接去拧阀门。AI PLC跟“用自然语言帮你生成一段梯形图”不是一回事。后者只是效率工具帮你把代码写快点前者要解决的是控制逻辑之上的智能决策问题——比如通过电流曲线预判主轴轴承磨损通过压力波动预测空压机组负荷变化通过视觉检测结果动态调节贴标机的速度。这些任务有一个共同特点现场的操作工和工程师本来能判断但24小时盯不住、算不准、反应不够快AI来做这件事才叫真正的智能升级。先别急着上大模型。我见过不少项目死在“先搭一套大数据平台”这个起点上。工业现场的AI落地路径其实就那么两三条要么在云端做决策下发到PLC要么在边缘网关上做推理要么直接让模型跑到支持AI能力的PLC或软PLC里。表格里这四类路径的差异决定了你后面所有选型路径响应级别对原系统侵入性数据在哪跑典型场景云侧AIPLC秒级到分钟级低通过接口下发设定值工厂专有云/私有化部署集团级调度、多产线能耗优化边缘网关PLC百毫秒到秒级低旁路采集最多写回设定值厂区边缘一体机或工业网关存量设备改造、预测性维护PLC内嵌AI/软PLC毫秒级中高需在控制器层集成控制器运行时内新设备、节拍内实时调整独立AI子系统PLC联动毫秒到百毫秒级极低通过IO或总线握手专用AI一体机/视觉控制器机器视觉检测、振动异常报警这四类路径里真正能快速见效的是最后一类——独立AI子系统通过IO信号与PLC联动因为它完全不碰原程序把AI判断结果变成一个简单的OK/NG信号或者一个脉冲PLC只要按普通数字量处理就行。而吹得最狠的“AI直接融入PLC程序”反而对数据质量、模型鲁棒性、控制安全的要求最高最适合新建产线时从零规划。## 2. 前提认知PLC的确定性与AI的概率性怎么分工才不打架聊AI PLC之前得先把PLC到底是个什么东西讲清楚否则后面所有步骤都是空中楼阁。PLC的核心优势从来不是“会编程”而是由硬件和操作系统共同保证的确定性程序循环扫描IO刷新有固定周期哪怕CPU忙到满负荷看门狗也能在毫秒级把系统拉回安全态。这种“每一毫秒都知道自己在干什么”的特性是工业现场敢把安全继电器、急停回路交给它的根本原因。AI恰恰相反。模型输出的是一个概率分布比如“预测这台泵未来两小时出现气蚀的概率为0.87”。0.87这个数很有用但你不可能拿它直接去驱动执行机构——你不可能让阀门开87%然后又关一点再开一点。工业控制需要的最终指令必须是确定性的布尔量或者规范的浮点设定值。所以在AI PLC体系里正确的分工是这样的AI负责感知和决策建议PLC负责执行、保护和兜底AI的输出要么经过规则校验以后变成“建议”给人看要么经过限幅、速率限制和互锁校验后变成“有限度的自动调节量”。我自己做项目时的原则是AI永远不能绕过安全回路永远不能直接控制急停、互锁、保护类逻辑它最多能调节的参数是那些本来操作员就可以在HMI上手动修改的工艺设定值比如温度设定、速度微调、压力阈值。这个认知特别重要。很多工厂第一次上AI项目就翻车往往是因为厂商把AI包装成“能替代PLC里的核心控制逻辑”现场老师傅一听就炸毛——让AI去管安全联锁出事了谁负责正确的做法是把AI定位成“一个坐在你旁边、24小时不眨眼的高级参谋”前期只说话、不动手等你说的话被验证靠谱了再允许你小范围微调参数而且永远保留一个“我不听你的”开关。说到微调就涉及到AI和PLC之间最敏感的接口——写回。AI要改变PLC里的设定值或者运行模式一般通过两种方式一种是AI边缘网关通过Modbus TCP/OPC UA等协议把数值写成PLC的寄存器或DB块另一种是PLC作为OPC UA服务器AI系统以客户端身份订阅数据并写入。这中间最容易出事的倒不是通信协议本身而是权限和优先级的管理——后面第六章我会专门讲这个坑。## 3. 新设备方案如何在产线规划阶段就为AI预留“可读的语言”新建产线有存量改造没有的奢侈条件你可以把AI接口能力直接设计进设备选型里。很多设备采购部门以为“预留AI接口”就是多买个高端CPU、多加点内存结果新设备到了现场AI项目启动时才发现——PLC程序里变量命名毫无规律OPC UA地址空间根本没开放历史数据只有趋势图没有结构化存储等于买了一台“能力很强但说不了人话”的设备。3.1 从数据架构开始规划而不是从硬件堆料开始我给新设备项目定的标准动作是先把数据架构画出来现场层是传感器和执行机构控制层是PLC再往上是边缘采集层最后是AI分析层。规划时要明确每一个数据从产生到被AI消费需要经过哪些环节以及每个环节的采样周期、数据格式、时延要求。举个例子一条锂电池涂布生产线AI要做涂布厚度的闭环微调。厚度传感器数据是10Hz采样PLC扫描周期是2msAI模型需要的是每分钟均值。这三者之间怎么衔接如果直接让AI去读PLC的原始DB块数据量巨大且时间戳对不齐根本没法建模。正确的做法是让边缘网关在本地做滑动窗口聚合把2ms的原始数据压缩成1分钟一条的特征值再喂给AI模型。这一步叫“数据升维”大部分项目80%的工程量其实不是在建模而是在做数据从OT到IT的翻译。3.2 硬件选型重点不是算力是接口和时间同步新设备选PLC时几个关键点必须写进技术协议控制器的通信接口必须支持主流工业协议最好原生支持OPC UA Server避免将来被私有协议绑死现场总线尽量统一PROFINET就全上PROFINETEtherCAT就全上EtherCAT别搞成串口、DP、总线混搭的大杂烩需要毫秒级AI实时控制的项目考虑支持软PLC的工业PC把AI模型以ONNX形式部署在同一个实时运行时里省去跨设备通信延迟如果计划在控制层跑AI推理优先选带AI加速单元或支持CODESYS Machine Learning这类生态的中大型PLC国产PLC品牌近年也在跟进这条路线。这里多说一句时间同步AI系统分析数据时时间戳错乱是个搞笑但致命的坑。如果边缘网关取数用的是网关本地时钟HMI历史数据用的是PLC时间两边差了两分钟模型训练时标签一错位准确率直接崩掉。新设备规划时必须要让所有采集节点通过NTP或其他机制同步到一个时钟源这是我在每个项目启动会都会强调的第三句话——前两句是“先搞懂数据从哪来的”和“甲方的组织架构里谁说了算”。3.3 变量规范化比买高端PLC划算十倍的投资新设备只要做一件事——变量命名和数据结构标准化后面AI实施能省一半时间。很多存量项目最后卡死就是因为PLC程序里变量叫DB3符点型、地址为MD200的“神秘变量”注释还是十年前的德文缩写。新设备不用这么憋屈在出厂前就要求供应商按统一规范做变量命名比如“产线-设备-子系统-数据类型-用途”温度测点就叫Line1_Oven_Temp_AI1电机状态就叫Line1_Oven_Motor_Run_DI一眼看过去就知道是谁、是什么、干什么用。变量规范化还必须包含单位、量程、上下限。AI模型读到的电流值到底是安培还是毫安量程是4-20mA还是0-10V这些元数据比字段本身更重要。我把点位规划表当作设备验收的一部分表格里至少包含点位编号、变量名称、数据类型、单位、采样周期、读写权限、用途说明。这张表做完设备才算是真正“AI ready”的。## 4. 存量设备改造不碰原程序也能接上AI的三条旁路存量设备是AI PLC落地最大的市场也是最多人栽跟头的地方。存量设备的普病我在开头提到过程序作者离职了、注释不全、逻辑文档丢失、设备经过安全认证、产线24小时运转停不下来。这种状态下谁敢去改PLC程序所以我的原则是存量改造的第一原则是旁路优先原程序能不动就不动。4.1 旁路一边缘智能网关数据采集开环AI建议这是我最推荐的第一步也是理论上适用范围最广的方案。硬件接法不复杂如果PLC有网口就把边缘网关的网口接到PLC所在的交换机上通过S7协议、Modbus TCP或OPC UA去读数据如果老PLC只有串口比如早期三菱FX系列或西门子S7-200的RS485口就用带串口的工业网关转一下。网关把数据转发给AI一体机或者边缘计算盒子模型在盒子本地跑推理结果推送到现场看板、操作台触摸屏或者手机小程序上。这个方案的好处是原PLC程序完全不碰AI系统只取数、不写数即使AI盒子死机、断网、模型跑飞产线照跑顶多是看板没数据。我经手的第一个存量改造项目就是这么干的——一台老空压机通过MODBUS RTU读它的压力、电流、温度数据在边缘盒子上做了一个能耗异常预警模型运行了三个月准确率稳定在能用的水平后才进入下一阶段。这条旁路的本质是先让AI“做人”再让它“做事”。4.2 旁路二软PLC方案适合毫秒级响应的现场有些工艺环节AI的建议必须在下个控制周期生效比如注塑机锁模力的实时补偿、精确张力控制这种场景下边缘网关“采集-推理-写回”的链路延迟受不了。可选的路是软PLC在一台高性能工业PC上跑CODESYS Runtime或者其他软PLC环境把原控制逻辑和AI模型放到同一个运行时里AI推理结果直接在控制任务内部用延迟可以压到几毫秒以内。但这套方案的代价是为了毫秒级响应基本上得把原控制程序重写一遍或者在保留原PLC的同时另搭一套“AI协同控制器”做接力。有些产线的主控制器本身就是基于PC的那改造代价小很多如果原设备是专用PLC软PLC大概率还要解决I/O映射、现场总线从站的迁移问题。所以旁路二适合那些“确实需要毫秒级闭环”而且“停产窗口能挤出来”的场景不适合一上来就搞。4.3 旁路三独立AI子系统与PLC通过IO或总线联动这是目前工厂里落地数量最多、看起来最简单但最稳妥的一条路AI子系统根本不进PLC的控制程序它像一个“智能传感器”把判断结果转成干接点信号普通开关量或者标准总线报文发给PLC当成普通输入信号处理。典型场景是机器视觉质检AI视觉相机对产线上的产品拍照识别出缺陷后通过硬接线给PLC一个“剔除”信号PLC里原本就有一段处理剔除气缸的逻辑照常执行即可。对PLC来说AI视觉摄像头和一个普通的对射光电传感器没有本质区别——无非是背后的大脑复杂了一点。再比如振动分析盒子检测到电机异常时输出一个警报位PLC把这个位点亮到HMI上逻辑照旧。这个方案里AI承担的是感知和分类任务控制决策完全还在PLC手里安全边界非常干净。三条旁路我按执行成本和侵入性排了个序方案是否碰原程序响应时间改造周期最适合的场景旁路一边缘采集开环建议不碰秒级1-2周先验证价值、积累信任的起步项目旁路二软PLC混合控制重写或新增控制逻辑毫秒级1-3个月需要实时闭环的复杂控制旁路三AI子系统IO联动不碰PLC只处理新输入毫秒到百毫秒级1-4周质检、振动监测、安全类附加判断## 5. 存量升级的完整落地链条数据盘点、单点验证到闭环切换从旁路一跑通到真正实现智能闭环中间有一条完整的落地链条。很多项目死在“模型效果看着不错但一直不敢切闭环”这个尴尬阶段就是因为链条缺了中间几环。我按自己实操经验拆成四步每一步都有明确的验收标准没有达标就不许走下一步。5.1 第一步存量设备数据资产盘点开工前先花半天做数据普查不是写PPT那种普查而是拿着点位表到设备旁一个一个对。盘点内容包括PLC品牌型号和固件版本、通信协议和可用接口、寄存器/DB块地址表、已有SCADA或MES系统的数据接口、设备历史报警记录是否存在、操作员有没有靠经验记录工艺参数的表格。我见过一个工厂型号标识上支持OPC UA的PLC实际上固件版本老到连以太网口都不好用最后全靠加一个MODBUS RTU转以太网网关才把数据抠出来。这种信息不摸底后面方案全是空中楼阁。数据盘点阶段还要做一件事——把“老师傅的经验”变成结构化数据他们平时靠看什么参数判断设备异常异常出现前哪些数值会变化、变化多快这些信息决定了AI模型该选什么特征而不是靠算法工程师闭门造车。5.2 第二步单点模型先行用报表验证价值不要试图一次解决三个问题先从能耗异常、设备故障预警、节拍优化这种单点问题入手。以空压机组举例先采一台机器一个月的数据记录电压、电流、排气压力、冷却水温度、加卸载状态。训练一个简单的压力波动预测模型目标是提前三分钟预测到管网压力异常把结果做成一张日报表每天早上推给设备主管。这里有个容易被忽略的原则模型上线初期卖给业务方的不是“自动调节能力”而是“预测的准确性”。如果模型说“未来三小时这台机组要报警”结果十次里五次不准现场就再也没人看你的看板了。所以单点验证阶段的KPI不是节能率、不是故障减少率而是误报率和漏报率要低到现场愿意看先让AI成为一个值得信赖的“预报员”拿到信任度再说下一句话。5.3 第三步三级切换级别不到不许自动我永远推荐按“开环建议→限幅闭环→全闭环”三级走每一级都有硬性退出条件。开环阶段AI只通过看板或短信给操作员提建议比如“建议将2号机组加载压力从7.2公斤下调至7.0公斤”操作员自己判断是否执行。这一阶段至少跑两到四周积累足够多的“建议-执行-结果”对照数据。它验证的不只是模型准确率还有现场的接受度。限幅闭环阶段AI被允许直接写PLC里的工艺设定值但必须加上两个限制数值边界和变化率限制。比如AI可以把温度设定值在上下浮动5%的范围内调整每次改变量不能超过0.5度同一方向连续调节不能超过三次。这样即使模型给出一个离谱的输出物理世界受到的冲击也不大。全闭环阶段才允许AI全权接管一个参数回路前提是前两个阶段的准确率、稳定性达到预设标准并且设备部门、工艺部门签确认文件。无论在哪一级PLC侧都必须保留两个权限HMI上的“AI自动/手动”切换开关要物理存在且默认切在手动一旦AI通信超时、模型置信度跌破阈值或PLC检测到异常工况系统自动退出闭环并恢复原设定值——这是安全底线。5.4 第四步AI输出的四道防线与老设备的“三不原则”AI的输出值写入PLC之前我认为至少要经过四道防线值域检查AI输出的设定值是否在工艺允许的上下限内超限直接拒绝变化率限制每次写值的变化量不能超过安全范围防止“AI抽风”导致参数抖动使能开关只有确认AI系统状态健康、通信正常时才允许AI写值生效硬互锁设备处于停机、急停、检修、手动模式时AI写入通道必须物理隔离。对存量设备额外守三条纪律“不覆盖原保护逻辑、不隐身躲过检修、不偷偷自动。”AI要能调整参数必须在HMI上让操作员看得到当前是谁在控制AI改了哪个值改成了多少。透明度在工厂现场是信任的基础信任没了技术再好也推不动。## 6. 这一轮改造中最容易翻车的三个细节项目做多了我发现翻车点往往不在算法本身而在现场集成那几个不起眼的细节。专门开一章说是想让看到这篇文章的同行少走点弯路。6.1 通信轮询周期与数据时间粒度不匹配AI模型说要“预测未来15分钟的能耗趋势”边缘网关于是每15分钟才去PLC读一次数据。可PLC内部那个累计能耗值可能每秒都在变化15分钟读一次中间的电耗归谁模型训练的时候根本没法打标签。反过来有些项目把采样频率设成100毫秒数据存了一堆模型根本不消费那么细的粒度存储和带宽白白浪费。我的做法是AI需要什么时间尺度的特征网关就用多大的采样窗口同时做高频率原始统计均值、峰值、谷值、积分备在本地让模型能随时调取中间统计量——这个设计既能兼顾毫秒级事件的捕获又不会拖垮数据库。6.2 人机操作权限没理顺AI和操作员“互相打架”这个坑我在不止一个现场见过AI在边缘端写了个设定值两分钟后操作员在HMI上把它改回来了再过两分钟AI又写回去操作员直接崩溃最后把这套系统定性为“人工智障”。本质上是没定义好人机优先级。我后来定的规矩是只要HMI上有最近的人工操作记录AI自动暂停写入该点位并进入等待期等待期过了再评估是否重试——宁可让AI“等一下”也不要让现场操作员觉得自己的控制权被系统一步步拆掉。信任是反向建立的系统先尊重人人才会尊重系统。6.3 模型置信度被当成准确率现场一次误报就崩塌工业场景下误报的代价远高于漏报。一个预测性维护系统连续三天误报第四天就算真报操作员也大概率选择无视这就是“狼来了”效应。所以模型输出不能只给一个阈值判断更不能拿置信度当准确率——模型给出0.6和0.98都触发同一个报警等于把概率信息全丢了。我的方案是给模型设置三个区间高置信区直接提示或动作低置信区维持现状且不打扰区间中间地带只做“观察性提示”并在后台记录不推送给现场。比如模型对“主轴轴承异常”的判定概率在0.5-0.8之间系统不报警只给维护工程师在日报里加一行“该设备存在疑似征兆请留意下次点检”。这样既不会让现场被报警刷屏又能把值得关注的信息留下来。6.4 关于“AI直接生成PLC代码”的现实看法热搜词里高频出现“AI PLC代码生成”我也实际用了一段时间。坦白讲AI在生成结构化文本ST、梯形图框架、变量声明、重复性功能块方面确实能提效能减少不少重复劳动。但以我眼下做项目的经验拿AI生成的代码直接上产线还是很冒险的事——工业控制代码的价值90%不在“写出来”而在边界条件处理、异常分支、安全冗余。大模型生成的是“常见情况下看起来正确的代码”而产线真正要命的往往是那些不常见的情况。我把AI代码生成定位成“高级补全和模板工具”让它写功能块的骨架和注释让它帮忙生成规范化的变量声明让它对已有程序做注释和说明——这些场景既安全又实用。真正需要上线的控制逻辑哪怕速度慢一点我也会要求工程师逐行审查、在仿真环境跑透边界条件越到关键时刻越不能图快。做AI PLC这块时间不短了我个人的体会是项目能不能成三分之一靠算法三分之二靠工程。算法模型再强现场数据采集是乱的、点位表是糊的、人机权限是对抗的一样白搭。所以无论你做的是新设备规划还是存量改造提前几天把设备所有变量的采样周期、读写权限、时序关系列成一张表跟老师傅确认一遍“哪些参数能自动、哪些永远不能自动”后面可以省掉一大半连带麻烦。先把AI放在一个“可靠参谋”的位置上让它先用报表和提示赢得现场信任再一步一步给它交自动化的钥匙——这条路径慢但每一步都走得扎实。
