2026年再聊AI工业控制系统圈子里其实已经很少人还在质疑“AI到底能不能用在工控上”大家见面聊得最多的是“产线上那么多PLC、DCS我到底应该从哪一条线开始切AI切进去之后又怎么保证不出事”。我自己在这个行业摸爬滚打了十几年从早期的组态软件、DCS逻辑编程到后来的边缘计算和模型部署都踩过不少坑所以这篇东西我不打算堆学术名词而是想把一套真正可落地的搭建思路完整讲清楚先建什么、再建什么、每一步怎么做、哪些地方容易翻车。不管你是工厂里的自动化工程师、搞IT想往OT侧走的程序员还是负责项目立项的管理者这篇都能帮你建立一张比较清晰的施工图。1. 先想清楚这张图再动手整体架构怎么设计AI工控项目最容易犯的错误就是一上来就买服务器、招算法工程师、跑模型结果发现现场的传感器数据根本接不上或者模型训练完了不知道怎么部署到车间里。我见过不少项目死在这个环节算法团队在办公室用理想数据集跑出了很高的准确率一到现场就失灵因为数据源头、通讯链路、控制边界全都是一笔糊涂账。所以我的建议是先把架构图画出来把AI在整个控制系统中的位置定死再谈其他。架构不清晰后面每一步都会打架。1.1 一套能落地的AI工控参考架构我习惯把AI工控系统分为四层现场设备层、边缘AI层、数据平台层和应用层。这四层不是随便分的每一层承担的任务完全不同对硬件、网络、安全的要求也完全不同。现场设备层是控制系统原有的“手脚”包括PLC、DCS、CNC、各类传感器和执行机构。这一层是控制逻辑真正执行的地方也是AI系统最依赖的数据源头。很多老产线的设备控制器型号繁杂通讯协议五花八门这一层的工作重点不是更换设备而是把数据“接得出来、传得上去”。边缘AI层是整个AI工控的核心。它由工业网关、AI推理盒、带NPU或GPU的工控机组成直接部署在车间现场和PLC/DCS通过OPC UA、Modbus TCP等工业协议实时交互。这一层承担两个任务一是毫秒级甚至更低延时的实时推理比如振动异常识别、视觉缺陷检测二是在断网情况下依然能独立工作。工业现场不比写字楼网络抖动是常态AI系统如果把命运全押在云端那生产安全就一点保障都没有。我做过一个设备预测性维护项目边缘盒子部署在高温车间里只有一路千兆工业网和一台老旧的交换机网络偶尔闪断但系统靠边缘本地推理硬是没影响生产节奏。数据平台层负责历史数据的存储和模型训练。工业现场产生的时序数据量非常大一台压缩机每秒可能产生几十个点位的数据传统关系型数据库根本扛不住一般用时序数据库比如TDengine、IotDB来存储。这一层通常放在工厂的信息中心或者私有云上和办公网做隔离负责把边缘层上传的数据沉淀成训练集定期更新模型再下发给边缘设备。应用层是面向最终用户的界面和业务逻辑预测性维护看板、质量检测报表、工艺参数推荐助手、设备健康画像等。这一层不需要在性能上做太多优化但必须解决一个问题让操作员、设备工程师、车间主任都看得懂、愿意用。再准的算法如果呈现方式违背了工人的操作习惯项目也活不长。1.2 切入现有控制系统时先选好层级有了整体架构下一步是确定AI在哪个层级切入。很多人一上来就想做“整厂AI优化”这基本是坑。正确的做法是从设备级、单元级、车间级三个层级里选一个起步点做出效果后再复制推广。设备级切入是针对单台关键设备做AI增强比如压缩机、风机、泵、电机这类旋转机械。典型应用是预测性维护和健康评估。采集振动、温度、电流信号在边缘侧建模型输出“设备当前健康度”和“建议维护时间”。这一层级不动原有控制回路AI只是“建议者”风险最低最适合第一个项目练手。单元级切入是围绕一个工艺段做优化比如锅炉燃烧优化、窑炉温度控制。这类项目要同时看多台设备的协同状态AI的输出往往是一个控制建议比如调整某个阀门的开度范围。这种场景就必须考虑和DCS的联动逻辑了不能只做展示。车间级和工厂级切入主要解决调度、排产、能源管理这类问题时间尺度从秒级拉长到分钟级甚至小时级对实时性要求低但对数据完整性和业务理解的要求高。我个人的经验是第一个AI工控项目坚决不做单元级以上的闭环控制先选一台故障损失最大的关键设备做预测性维护或者选一条视觉检测压力最大的产线做质检这类项目见效快、边界清晰、不容易出安全事故。2. 数据底座没搭好AI就是空中楼阁AI模型的本质是从数据里学规律数据质量决定了模型的上限。工控AI和互联网AI最大的不同在于互联网有海量用户行为数据而工业现场往往是“数据量看着很大有用的样本凤毛麟角”。你连续采集三个月产线天天正常运行故障样本可能一个都没有。这时候模型只能学会“正常长什么样”对于“异常长什么样”一无所知。所以我想强调一句实在话工控AI项目的头两个月百分之八十的时间应该花在数据采集和数据治理上而不是调模型。这个顺序一旦搞反后面全盘皆输。2.1 三种主流采集方式按设备年头选数据采集没有统一标准完全取决于现有设备的接口情况。我梳理了三种最主流的采集方式你在规划时可以按设备年头对号入座。第一种是OPC UA采集。这是近十年新建产线和新一代PLC/DCS的主流通讯协议支持加密认证、语义建模和复杂数据类型。OPC UA最大的优点是自描述性点位带单位、量程、设备上下文不用再去翻图纸猜测数据类型。如果现场是西门子、倍福、罗克韦尔的新一代控制系统优先走OPC UA采集周期可以根据场景设到10毫秒到1秒之间。第二种是Modbus TCP/RTU采集。老设备里大量存在尤其是2010年前后投产的产线。Modbus简单、成熟、兼容性好但存在两个痛点一是点位表往往依赖原始图纸和工程师经验换个人可能就看不懂二是轮询机制下点位多了之后更新频率上不去。针对老设备我建议采集周期设置在100毫秒到1秒左右不要贪快稳定可靠更重要。第三种是加装传感器直采。现有系统实在接不出数据或者需要新增维度比如新增振动传感器监测轴承状态时就用独立的数据采集终端直接采集通过MQTT、Modbus TCP等协议接入边缘AI层。这种方式灵活性最高但施工量也最大需要考虑传感器选型、安装位置、信号干扰、布线和防护等级。不管用哪种方式我都建议先做一张点位规划表列清楚设备编号、信号名称、信号类型、量程范围、采样频率、通讯协议、数据用途。这张表就是后面所有工作的“宪法”数据缺失、标签混乱、口径不一致根本原因都是前期没做这张表。2.2 数据治理里最容易翻车的五个细节采集只是第一步让数据可用才是真正的难点。以下五个细节是我在多个项目里反复踩过的坑写出来希望你能绕开。第一个是脏数据清洗。工业现场的信号干扰、传感器漂移、通讯偶发中断都会产生异常数据。最常见的表现是数据出现毛刺尖峰压缩机振动值平时稳定在2.3毫米每秒突然蹦出一个45下一拍又恢复正常。如果不做处理模型会把毛刺当故障学进去误报率飙升。常规做法是阈值过滤加中值滤波配合设备的启停状态做工况切片只分析设备运行工况下的数据。第二个是标签缺失。预测性维护模型需要知道“哪个时间段设备处于异常状态”这就是标签。但工厂往往没有维护记录系统维修人员换完轴承就走了没有人把故障时间、原因、更换部件记下来。没有标签监督学习就无从谈起。我建议的做法是前期用规则初标设定振动超限阈值、温度超限阈值等简单规则把明显异常的时间段标出来再由设备工程师复核确认。这个过程虽然枯燥但标签质量直接决定模型上限。第三个是时间同步。多台设备的时钟如果不一致采集到的数据在时间轴上就对不齐做相关性分析时会出现“张冠李戴”。解决方式是在工厂内部架设NTP时间服务器所有采集终端统一对时误差控制在50毫秒以内。第四个是历史数据留存。很多时候项目刚启动时数据只在边缘设备上临时存着没有同步到平台侧。等到模型训练发现样本不够想追补历史数据发现早就被循环覆盖了。我强调一个原则数据先留存模型慢慢调。哪怕前期不知道怎么用也先把原始数据一股脑存下来存储成本远远低于以后想用却没有的代价。第五个是数据安全这个看起来是管理问题但在架构上要提前预留。生产数据属于工厂核心资产数据平台和办公网要做物理或逻辑隔离边缘设备要限定只开放必要的采集端口防止外部网络问题倒灌进生产网。3. 模型选型不同场景用不同武器很多刚接触AI工控的朋友会问用什么模型比较好这个问题其实没法直接回答因为不同场景的数据形态、业务目标、容错要求完全不同。我在实际项目里会把工控AI场景分成四类预测性维护、视觉质检、工艺参数寻优、大模型辅助诊断。每一类都有自己的成熟方法论不要指望一个模型打天下。3.1 预测性维护少样本场景怎么建模预测性维护的目标是“设备还没坏算法告诉你它可能要坏”。这是一个典型的时间序列异常检测问题。工业场景下手头数据往往是正常工况占绝大部分故障样本极少直接训练一个“故障分类器”不太现实。比较务实的方案是“无监督初筛加有监督细判”的两段式结构。先用无监督模型比如Isolation Forest或Autoencoder学习正常数据的分布把偏离正常范围的片段筛出来再把筛出来的候选片段让人工标记用LightGBM这类可解释性强的模型做第二阶段分类判断是哪种具体故障类型比如轴承磨损还是不对中。特征工程在预测性维护里比模型选择更重要。对旋转机械我常用的特征有振动速度的均方根值RMS、峰值因子、峭度、频域包络谱特征以及温度、电流的变化趋势。RMS反映整体振动能量峰值因子对早期冲击类故障敏感峭度对轴承缺陷敏感。每台设备的工况不同特征阈值也会有差异所以模型需要做到“一机一模型”或者至少按设备类型分组训练。这里还涉及一个关键点预测性维护的报警阈值不能纯靠算法定。我见过一个案例模型自动算出的阈值过紧导致每天弹几十条报警操作员直接把系统关掉了。正确的做法是结合维修策略来设定阈值先放宽宁可漏报也要保证精准再根据实际维修反馈逐步收紧。3.2 机器视觉质检缺陷检测的选型与标注视觉质检是AI工控里落地最快、ROI最直观的场景核心任务是把产品表面的缺陷从良品里找出来。选型方面如果业务只需要知道“有没有缺陷、缺陷在哪个位置”用目标检测模型YOLO系列就够了如果要精确分割出缺陷轮廓则需要用语义分割模型比如SegFormer、U-Net。视觉模型的成败取决于三点成像方案、标注质量和过杀控制。成像方案上光源角度、相机分辨率、拍摄频率都很关键——很多缺陷人眼看得见但工业相机拍不清问题往往出在打光不均匀。标注质量上缺陷类型定义要明确比如划痕和压痕容易混淆标注规范里要配上典型图例。过杀控制上算法倾向于把可疑样本都标为缺陷以保证召回率但工厂里过杀意味着良品被误判为次品带来的损失和漏检一样大。所以上线前一定要做“误杀率”评估宁可精度优先、召回率低一点也不要让现场天天被误报警淹没。视觉模型部署时还有一个容易被忽略的坑产品换型。不同型号的产品外观差异可能很大同一个模型可能直接失效。要做好模型版本管理和快速切换机制让产线换型时能够一键切换到对应模型。3.3 工艺参数寻优与大模型辅助诊断工艺参数寻优比如PID参数自整定、燃烧效率优化、配方参数推荐是AI工控里技术门槛最高但价值也最大的方向。这类问题通常会用到贝叶斯优化或强化学习但最大的难点不是算法而是安全边界。AI寻优算法天然会在空间中探索更好的参数组合而探索就意味着可能踩进危险区域。所以在设计阶段必须设置硬约束所有AI推荐的参数必须落在工程师指定的安全区间内超出区间直接丢弃并且所有寻优结果必须先经过仿真验证再以建议形式推送给操作员。我个人的意见是新工厂不要一上来就做这类项目先积累正常工况数据和调试经验把模型在仿真环境里跑上半年再说。至于大模型在工控中的应用2026年已经有不少工厂开始尝试把大模型作为“老师傅平替”来使用。典型做法是搭一套RAG检索增强生成系统把设备手册、历史维修记录、故障处理SOP整理成知识库让操作员用自然语言提问比如“压缩机振动偏高同时温度也高可能是什么问题”。大模型根据知识库内容生成排查建议。这类应用有效规避了大模型“一本正经胡说八道”的问题因为答案有据可查。但我必须强调大模型只能做辅助诊断和知识问答绝对不能直接接到控制回路上。做过工控的人都知道控制回路的事故往往不是单一原因任何脱离现场实时状态直接给控制指令的做法都是在玩火。4. 部署与联动从“算法能跑”到“现场敢用”模型训练出来只是万里长征走了一半部署到现场、和现有控制系统安全联动才是真正考验工程能力的地方。我见过太多项目卡在这一步实验室里准确率98%一上产线就各种幺蛾子推理延迟超标、内存溢出、和PLC通讯抢线、操作员不敢点确认。这些问题都可以通过规范的部署方案和联动策略来规避。4.1 边缘算力怎么选、模型怎么部署边缘算力的选型没有统一标准主要看三点模型复杂度、推理延迟要求和现场环境。我提供一个快速参考场景算力配置适用模型轻量预测性维护X86工控机CPU推理即可LightGBM、Isolation Forest、小规模Autoencoder中量实时状态识别带NPU的AI推理盒如瑞芯微、地平线系列轻量化卷积神经网络复杂视觉检测GPU工控机NVIDIA Jetson或独立显卡方案YOLO系列、分割模型选硬件时不要只看算力峰值还要看散热、防尘、宽温能力。车间环境往往40度以上普通办公级设备根本撑不住。我有个项目前期图省事直接用了普通台式机放在电控柜里夏天连续高温报警后来换了工业宽温工控机才算消停。模型部署层面建议全部容器化。用Docker把推理服务、依赖库、配置文件打包好这样后续更新版本不需要在现场折腾环境依赖。推理框架方面NVIDIA平台用TensorRTIntel平台用OpenVINO如果模型来自PyTorch或TensorFlow先转成ONNX再做推理加速。模型量化也很关键INT8量化在视觉模型上通常能带来2到3倍的性能提升而精度损失控制在可接受范围内。模型更新机制要从第一天就设计好。不能每次更新模型都让工程师背着U盘跑现场。比较成熟的做法是平台侧保留模型版本库边缘设备从平台拉取新模型先加载到内存做灰度验证确认推理结果正常后在业务低峰期切换。模型回滚也要做成自动化一键回到上一版本。4.2 与DCS/PLC安全联动的三条铁律AI系统一旦从“建议者”变成“控制参与者”安全问题就是头等大事。下面三条铁律是我自己项目的硬性底线建议任何人都不要绕开。第一先旁路后闭环。AI系统上线初期只做监测和推荐输出结果展示在操作员界面上由人来决定是否执行。运行一两个月积累了足够多的对比数据确认AI的建议在绝大多数情况下是合理的再考虑把AI输出接入控制回路做闭环。即使到了闭环阶段每次AI指令执行前也要经过操作员确认按钮。全自动闭环不是不能做但那是极少数经过充分验证、且有多重冗余的场景才敢考虑的事。第二软联锁加硬联锁双层保护。软联锁是在AI输出到执行器之前加一道逻辑判断AI推荐的控制量必须落在预设的安全区间内任何越界的数值一律拦截并告警。硬联锁则是利用独立的硬件回路比如安全继电器、独立的急停逻辑保护关键设备它的动作不依赖AI系统、不依赖DCS逻辑只认物理信号。软硬联锁必须独立不能共用同一套逻辑和电源否则一个环节故障整个保护都失效了。第三AI故障要自动降级。AI节点必须和DCS/PLC之间有心跳信号。AI节点一旦发生故障、网络中断或推理超时系统要能在毫秒级自动把控制权交还给原有DCS/PLC控制逻辑并弹出提示。操作原则是AI没信号系统自动切回原控制策略绝不能用AI节点故障前的最后值继续输出。这个“最后值保持”的陷阱非常隐蔽很多项目调试时抓耳挠腮的问题就出在这里。5. 一线实施最常见的五个坑最后这部分我把自己在一线实施中反复看到的坑整理成清单。这些问题在书本和论文里很少出现但现实中几乎每个项目都会遇到而且多数是隐性成本的大头。5.1 数据质量比模型算法更致命不少项目团队在启动后优先招算法工程师把大量精力花在模型调参上最后发现数据标签混乱、时间不同步、工况切片错误辛辛苦苦调的模型一换现场数据就崩溃。我见过一个项目数据采集程序在部分工位上跑了三个月后来一查其中三分之一的工位因为PLC网关配置错误采集到的是恒值假数据等于模型白训。所以项目启动前一定要先用一两周时间做数据摸底把点位逐个核对清楚确认数据的真实性、完整性和一致性再谈算法。5.2 网络规划不当引发生产事故工业现场的网络环境远没有IT机房那么规整。IP地址规划混乱、交换机带宽不足、广播风暴、办公网和生产网互相干扰都是常见问题。有一次我在现场调试时AI系统刚上线车间就出现了网络卡顿排查半天发现是办公区的视频监控流量和工业数据流混在同一个交换机上结果办公网一个监控探头故障导致生产网通讯都受影响。后来在接入AI系统之前我会先要求工厂梳理整个网络架构把生产网和办公网严格分离给AI分配独立VLAN并对带宽占用做一个整体评估。5.3 模型漂移与季节变化工业模型最怕的是环境变了模型没跟上。同一个预测性维护模型夏天和冬天的误报率可能差异巨大因为环境温度、湿度、原材料批次都在变化。这不是模型质量问题而是场景漂移。解决方式是建立模型定期重训机制例如每月或每季度用最新积累的数据重新训练一次并对模型效果做持续监控。当模型的报警准确率明显下降时自动触发告警提醒工程师介入。5.4 操作员的信任危机很多AI系统项目技术上做得很漂亮最后死于操作员不用。最常见的原因是报警阈值设置不合理系统刚上线时误报太多操作员频繁被“狼来了”折腾几天后整个系统就被当成噪音无视了。我在这方面的经验是两个原则第一前期少报、报准。哪怕漏掉一些小问题也要保证每条预警都有价值第二所有的AI判断都要有解释比如报警卡片上直接显示“振动RMS连续超限2小时同期轴承温度上升8摄氏度怀疑润滑不良”操作员看到有理有据的判断才会逐渐建立信任。5.5 验收标准要在立项时写清楚预测性维护项目的验收尤其容易扯皮。准确率怎么算漏报率多少算合格误报率多少算合理这些指标如果不提前写清楚到验收阶段就变成双方互相抬杠。我建议在项目合同里就写清楚业界常用的做法是定义故障检测准确率、误报率、平均提前预警时间、模型在线运行率等指标并且用一段连续生产的运行数据作为考核基线。视觉质检项目还要单独定义误杀率因为工程上漏检和误杀往往此消彼长这需要在验收标准里做出明确的取舍。最后分享一点实战心得做了这么多年工控AI我越来越觉得这行真正难的不是算法而是工程耐心。再先进的模型只要数据基础不扎实、边界条件不清晰在现场一定翻车。我的建议很简单第一个项目宁可小也要完整打通“数据采集、边缘推理、联动保护、人机交互”这整条链路。完整性的价值远大于算法的先进性。把人工智能当作一个刚进车间的新员工先让他看、让他建议、让他跟着老师傅学再慢慢把更重要的任务交给它。这个过程没有捷径但一旦跑通复制到下一台设备、下一条产线就是很自然的事了。