监督控制与数据采集（SCADA）的实战迷思：从崩溃边缘到预测性维护

半夜两点，电话响了——产线停摆，因为 SCADA 服务器莫名离线。我盯着天花板骂了句脏话。

那种感觉，你懂的。几千吨的注塑机趴窝，每秒钟都在烧钱。而那个该死的数据采集程序，偏偏这时候崩了。

说实话，搞了十五年自控，我越来越觉得，监督控制与数据采集这八个字，压在每个工程师身上的分量，远比它字面上要重得多。尤其是当你意识到，市面上八成的 SCADA 部署，其实根本没有发挥出它真正的潜力。

别把 HMI 当成 SCADA 的全部

很多人——也包括很多老板——都有一个根深蒂固的错觉：只要中控室的大屏上花花绿绿的流程图能跑，所有的泵、电机、阀门状态能闪烁，SCADA 就算搞定了。

大错特错。这充其量就是个 HMI，还是个没灵魂的 HMI。

真正的 SCADA，核心在那个 ‘A’ 和 ‘D’：采集与控制。但数据采集不是读个数就完事了。你得考虑时间戳对齐吧？得处理断点续传吧？得过滤掉那些野蛮的电磁干扰造成的高频振荡信号吧？我曾在某个化工厂，就因为一个模拟量通道没做软件滤波，导致 SIS 系统误判，差点把整个反应釜的料给排了——现在想起来都后怕！

而且，控制也不是说你在画面上点个‘启动’，plc 接到指令就完事。互锁条件、安全联锁、权限管理，这些如果不在 SCADA 层面做第二道防护，迟早会出事。特别是现在很多项目，为了赶工期，把上位机程序写得像麻花一样拧在一起，完全没有模块化，后期维护简直是地狱。

协议之痛：Modbus 还没死，OPC UA 就已经老了？

干了这么多年，最烦的就是现场总线协议不统一。西门子的 Profibus、罗克韦尔的 EtherNet/IP、施耐德的 Modbus TCP，还有那些老旧家伙还跑着串口 Modbus RTU。你想把它们统一到一个平台？

问：老系统改造，PLC 是十几年前的 S7-300，能接入现代的 SCADA 平台吗？

答：能，但说实话，挺费劲的。那种带以太网口的还好，如果只有 MPI/DP，你得加个网关，比如赫斯曼或者万可的转换器，先把协议转成 OPC UA 或者 MQTT。但也别高兴太早——这些网关的配置软件有时候能让你崩溃，授权还死贵。我个人的经验是，如果点数不多，直接换个带网口的新 CPU，可能比折腾网关更划算，因为后面维护省心多了！而且很多老 PLC 内存小，根本扛不住高频采集，通讯一频繁就死机。你这边 SCADA 疯狂轮询，那边设备直接罢工，这种惨案我见过三次了。

这几年工业界猛吹 OPC UA，好像它就是万能药。没错，信息建模、安全通道，确实功能强大。但实施起来呢？tags 结构搞得极其复杂，客户端和服务器的配置一步错步步错。更郁闷的是，现在 MQTT，尤其是 Sparkplug B 规范，在边缘计算场景里越来越吃香。轻量、双向、断线重连机制好，简直是为云端而生。

可你敢说 OPC UA 就老了吗？也不敢。它背后有工控巨头撑腰，在大型流程行业，还是绝对的主流。现在又有 TSN（时间敏感网络）加持，延迟能做到微秒级。所以现在是个乱世——Modbus 老当益壮，OPC UA 盘踞重地，MQTT 攻城略地，5G 还在一旁虎视眈眈。

我们这些搞集成的，只能像八爪鱼一样什么都得会，还得在项目里判断：用哪种？别给自己挖坑。比如，如果现场有很多无线振动传感器，用 MQTT 直接上云就比特意去建一个 OPC UA 服务器明智得多。

预测性维护：听起来很美，直到你掉进数据质量的泥潭

这几年工业 AI 火得不行，所有搞 SCADA 的厂家都在吆喝预测性维护。给泵装上加速度传感器，拉根网线到 IOT 网关，数据扔到云端，AI 模型嘎嘎一算——‘您的轴承预计在 72 小时后失效。’完美！

我呸。现实是，你首先得面对数据质量问题。劣质的安装导致传感器信号漂移，随便打个雷还能把采集器打坏了。然后你收集了半年的振动数据，发现轴承早就坏了三个，但模型要么瞎报警，要么屁都不放一个。

问：上了 SCADA 以及预测性维护功能，真的能大幅减少人工巡检吗？

答：能，但也可能把人坑得更惨。比如，仪表本身出现零点漂移，但没超出量程，系统不报警，巡检人员一看屏幕上显示正常，就信了。结果储罐液位慢慢就溢了。血的教训啊！人工巡检其实是在交叉验证传感器的有效性。我现在的做法是，核心设备，视觉、温度、振动多个维度同时上，而且必须做冗余校验。比如，一个罐子，既要有雷达液位计，也要有压差变送器，两个数据的趋势曲线在 SCADA 里一比对，如果偏差突然增大，哪怕数值都在正常范围内，就要触发预警。这才是真正有用的数据融合。不然，AI 就是个黑盒子笑话。

另外，很多 SCADA 的历史数据库，归档策略粗放得很。为了省存储空间，把高频信号压缩成一分钟一个平均值，把故障特征活生生过滤掉了。等你发现问题回头追查，历史曲线平滑得像婴儿屁股，什么异常都看不出来。所以，死区压缩和旋转门算法的参数，一定要结合工艺特性反复调试，不能一味求压缩率高。

云边协同，或者叫‘别把鸡蛋都放在 AWS 上’

现在的潮流是上云。但全上云？那是灾难。想象一下，你的 SCADA 画面点一个按钮，指令要绕地球半圈才下到 PLC，光延迟就几百毫秒，更别提断网了。

所以边缘计算必须搞起来。在车间放一台边缘服务器，运行轻量化的 SCADA runtime，比如 Ignition 或者 zenon，承担实时监控和本地报警。然后筛选后的数据、KPI 指标、报警摘要异步传送到云端做驾驶舱和远程分析。

这里有个巨大的坑：时标统一。边缘端的数据带的是本地时钟，云端服务器又是 NTP 同步的，中间那个 IoT 网关的更可能是晶振乱飘。如果不用 GPS 或者精确的 NTP 协议校正，所有跨站点的事件序列分析全是乱的。我就碰到过一次，事故追忆时，两个厂区的 SOE 时间差了三秒，责任根本分不清。

还有安全。别觉得工控网络隔离就万事大吉。我见过很多厂，PLC、上位机、摄像头全在一个 VLAN 里裸奔。万一哪个心怀不满的员工插个树莓派，或者 U 盘病毒进来了，SCADA 系统瞬间沦陷。基于 IEC 62443 标准的网络分段、最小权限原则、白名单机制，这些基础安全防护，必须从一开始就嵌入到 SCADA 架构里。不然，你就是个光着身子在战场上跑的士兵。

说到底，监督控制与数据采集这件事，技术迭代再快，底层的工程逻辑没变过：可靠、准确、安全。新名词包装得再花哨，如果连基本的接线都整不利索，连个干扰信号都处理不好，一切都是空中楼阁。

干了这么多年，我依然在路上。每当解决一个棘手的通讯故障，或者从一大堆曲线里揪出一个隐蔽的设备早期故障，那种成就感，还是挺让人上瘾的。就这样吧，继续干活去，下一个现场还在等着我。