摘要：很多工厂做产线实时监控，砸了大价钱却达不到预期，要么延迟飘上天算不上实时，要么误报满天飞没人愿意用。本文结合落地项目经验，梳理需求梳理、架构搭建到预警逻辑里的常见坑，给一线工程师做参考。
上次去佛山勒流的3C电池厂调试新线，进门就见甲方设备主管愁得蹲门口抽烟。他们半年前刚上了新的实时监控系统，花了一百八十多万，现在还是隔三差五掉数据，报警还不准，工人干脆把报警音关了。
说实话，这种情况我见得太多了。很多人觉得产线实时监控不就是装几个传感器，把数据传到服务器上画个曲线？哪有这么简单。
别上来就堆传感器：先搞清楚你要监控什么
进去一看我就乐了。整条组装线一百多米，光振动传感器就装了16个，连末端放成品的料架都装了一个。问甲方为什么装，说既然做实时监控，那就要全采集，不能漏。
什么叫全采集？全采集就是全浪费。
按照ISA-SP18.01工业实时系统标准，产线监控的实时性分三个等级：硬实时要求端到端延迟不超过100ms，对应核心工艺参数，比如激光焊接的电流、温度，卷绕的张力，出了问题立马出废品，必须毫秒级响应；软实时要求延迟在100ms到1s之间，对应设备运行参数，比如电机转速、减速器温度，用来预判故障；1s以上的就是非实时，用来做月度统计的，比如车间环境温湿度、日产量，你十分钟更一次都没人说你。
这家厂倒好，把料架振动这种八竿子打不着的参数，也按100ms一次的频率采集上传。带宽直接被占了三分之一，核心的焊接温度数据反而经常堵在路上，延迟最高冲到3秒，出了不良都已经流到下一站了。
正确的做法是什么？先拉上工艺、生产、维护三个部门一起拉清单，把所有要监控的参数按影响分级，核心工艺参数优先保障，非核心的降采样率。我给这家厂重新梳理之后，砍掉了11个没用的传感器，核心参数的延迟直接降到了70ms以内，成本先砍了三分之一。
不过话说回来，也不是说非核心参数就不用采，只是别跟核心抢资源对吧？你把环境温湿度一分钟采一次，一点不影响，还省带宽。
传输与存储：实时性的杀手往往藏在这里
很多人把注意力都放在前端传感器上，传输层随便对付，这是第二个大坑。
这家厂原来用的是普通百兆非管理型交换机，所有PLC、传感器的数据都往核心服务器怼，高峰的时候一百多台设备同时发包，交换机直接堵成停车场，丢包率最高到4%。你传感器采得再准，传不到服务器都是白搭。
我给他们改的架构其实很简单，加了一层边缘预处理，每条线配一个边缘网关，先在本地做数据清洗：正常运行的时候，只需要每2秒上传一次汇总数据就行，只有参数超过阈值、触发异常的时候，才全量上传原始数据。就这么一改，核心服务器的带宽占用直接降了72%，平均延迟从原来的1.2s降到了50ms以内。
交换机也换成了千兆工业管理型交换机，给核心工艺数据开了VLAN优先级，哪怕整个车间都满负载，核心数据的传输也不会被挤占。别贪便宜用普通商用交换机，车间里的焊机、变频器电磁干扰大得很，商用交换机扛不住，夏天温度一高丢包率蹭蹭往上涨。
存储也有坑，很多人把所有原始数据都存在云端，调用的时候延迟高得离谱，存储成本还高。其实按照GB/T 39116-2020智能制造能力成熟度模型的要求，三年以内的运行数据存边缘层，三年以上的历史数据归档存对象存储就行，既省钱调用还快。
异常预警：别做只会喊狼来了的稻草人
监控的核心目的是什么？不是画曲线给领导看，是提前发现异常，减少停机。我见过太多监控系统，预警准确率不到30%，一天误报几十次，工人被搞烦了直接关报警，系统彻底成了摆设。
这家厂原来的预警逻辑就是简单的固定阈值，电机温度超过70℃就报警，冬天还好，夏天车间环境温度本身就35℃，电机连续开四个小时，温度稳定在72℃，其实完全正常，结果一小时报三次警。
我给他们改了自适应阈值逻辑：阈值不是固定的，是结合开机时长、环境温度、生产负荷动态计算的，同样是70℃，冬天开机一小时报，夏天开机四小时可能75℃才报。改完之后，预警准确率从原来的28%升到了93%，误报一天最多一两起，工人也愿意用了。
还有一点，预警一定要分级。一级异常直接触发停线，比如焊接电流超出范围20%，再焊就是废品，立马停；二级异常触发推送，通知维护人员趁换班的时候处理，比如振动偏了0.2mm，还能跑两小时，不用当场停线耽误产量。别什么都直接停线，也别什么都只发个提醒，分寸要对。
最后说两句，产线实时监控不是数字化改造的门面活，是真能落地降本的东西。这家厂改完之后运行了三个月，非计划停机时间降了27%，不良品率降了4.1%，算下来半年就收回了改造成本。
别追求花里胡哨的概念，适合自己产线的，才是好用的。
