老旧SCADA系统无损新增告警：旁路加装边缘计算网关的完整实践

干了这么多年工控项目，我最怕听到领导轻描淡写来一句：“系统跑得好好的，你敢动吗？”尤其当对象是一套用了十几年、连原厂都找不到人的老旧SCADA系统——中控室大屏还是老组态画面，运行记录贴着泛黄的停机登记表，可眼前的需求却白纸黑字写着“新增告警功能”。听起来不复杂，落地全是刺：产线不能停、PLC程序不能改、组态软件厂家早已退出市场，连从SCADA里导出一份完整点位表都要翻半天历史归档。后来我在多个这样的项目里反复验证了一条可行路径——在原有SCADA系统旁边加装一台边缘计算网关，用旁路方式把现场数据复制一份出来，告警计算、规则判断、通知推送全部交给独立网关完成，不动原系统一根线、不碰原逻辑一个字节。这套方案能做到“原系统零改动、上线零中断、异常可一键摘除”，正是标题里说的“无损增加告警”。

1. 老旧SCADA系统“加个告警”到底难在哪

1.1 SCADA、HMI和PLC的分工，先说清楚

这几年经常有人问“SCADA、HMI和PLC到底有什么区别和关系”，放到这个题目里，三者分工不搞清楚，后面旁路方案的设计思路也说不明白。简单类比：PLC是现场干活的手脚，负责执行逻辑、采传感器、输出执行器动作；HMI是现场的操作面板，给操作员看当前数值、按键启停；SCADA则是中控室层面的集中调度平台，它把几十个PLC、几百台仪表的数据汇聚到一张大网上，让值班员在电脑前就能看到整个车间的运行态势。

老系统的问题恰恰出在“耦合太深”。十几年前做项目的思路是PLC、HMI、上位机组态一套打包，点位表写死在程序里，告警画面做死在组态工程里。现在你想往里面加一个“新告警”，第一反应是改组态工程的告警配置，第二反应是让PLC把新状态位传到上位机。这两种操作都要动原系统，就像给一颗跳动了二十年的心脏装支架——没人敢保证不出问题。

1.2 常规改造方案的三座大山：停机、改逻辑、碰协议

先说停机窗口。连续生产线的停机不是简单按个暂停键，投料、升温、联动都是整套流程，误停一次的直接损失可能就能买几台网关。老旧系统改造要有停机窗口，但生产部门通常给不出这个窗口，或者给的窗口只有两三个小时，根本不够改完再回退。

再说改逻辑。老PLC里的程序可能是梯形图、语句表，甚至当年外包公司自己写的非标块，原代码不一定留有完整注释。现场很多PLC程序是“只读”的，技术上能上载，但上线新逻辑后如果出现时序问题，轻则设备抖一下，重则触发联锁停车。没人愿意为一个告警功能去背这个雷。

最后是碰协议。早期SCADA普遍用OPC DA、Modbus等老通信协议，OPC DA依赖Windows老系统的DCOM配置，安全性和兼容性一言难尽。即便PLC支持Modbus TCP，很多老工程师也不敢轻易在PLC上新增通信块，因为通信负载增加可能导致本就吃紧的控制器周期变长，原本跑得好好的逻辑反而变得不稳定。

1.3 旁路加装的核心逻辑：复制数据，而不是接管系统

“旁路”这个词在工控里很容易被误解，有人以为是在链路中间插一个设备做转发，还有人以为是做网关冗余。实际上这里的旁路是“数据旁听”：不改变原数据流向，不插入任何链路中间环节，而是把现场通信中的数据复制一份给边缘计算网关。

这就好比在一个会议室外放一个录音笔，会议室里的人正常开会，录音笔把声音录下来做二次分析。会议室不会因为多了个录音笔就开不了会，也不存在录音笔坏了会议就要停的问题。旁路加装边缘计算网关的价值在于：原SCADA该怎么跑还怎么跑，新增的告警能力完全由网关这个“录音笔”来提供。

三种方案放一起对比会更直观：

我见过太多项目在方案评审阶段反复横跳，最后选旁路方案的关键理由其实就一条：它把“改造”变成了“叠加”，把高风险手术变成了可回退的外挂装备。

2. 旁路取数方式的选型与安全边界设计

2.1 三种旁路取数方式的具体做法与适用场景

确定了“旁路”的大方向，接下来最核心的问题是数据从哪来、怎么拿。根据现场实际，我总结出三种主流取数方式，它们各有适用边界。

第一种，串口T型分接。很多老仪表和老PLC只有RS485/RS232串口，一上下位机之间就一根通信线。这时可以在线路上加一个T型分接头，一路保持原链路走向SCADA，另一路引到边缘计算网关。优点是不动原通信链路，缺点是RS485总线带负载能力有限，加一路监听可能影响总线电平；分接头质量不好还会引入干扰。这个方案适合没有网络接口、实在没得选的老仪表场景。

第二种，交换机端口镜像（SPAN/RSPAN）。这是我最推荐也是用得最多的方式。PLC通过以太网和上位机通信，中间的交换机如果支持端口镜像，那就把PLC所在的交换机端口配置为镜像源，把数据复制一份到网关所在端口。网关在物理层面完全是“被动接收”，就算网关断电、网线被拔，原SCADA通信没有任何感知。这种方式对Modbus TCP、Profinet、EtherNet/IP这类基于以太网的协议都适用。

第三种，协议主动采集。网关以Modbus Master、OPC UA Client等身份，主动去读取PLC或仪表里的寄存器数据。这种方式的本质是“在原通信链路上新增了一个通信伙伴”，严格意义上不算纯旁路，因为PLC要分出通信资源来响应网关。但只要轮询周期设置合理，对PLC的影响可以控制在很低的水平。

我在实际项目中遇到过这样一个情况：车间网络里的交换机是一个老旧二层百兆交换机，本身不支持端口镜像，而PLC又支持Modbus TCP。这时我直接选第三种方式，让网关做Modbus主站，每2秒轮询一批关键寄存器。实测下来PLC的通信负载只增加了一两个百分点，完全在可接受范围内。

2.2 网络拓扑与安全隔离：怎么做到“拔掉网关不影响原系统”

旁路方案承诺的“无损”，最终要靠网络设计和物理隔离来兑现，不能停留在口头上。我在工程实施中会守住三条硬边界。

第一，网关只能“读”，不能“写”。边缘网关统一部署为数据采集和数据监听角色。能走只读就只读，必须主动采集的场景下，网关发出的也仅仅是读请求报文，不包含任何写寄存器、写线圈、下发控制命令的指令。

第二，网络层做隔离。网关如果接在交换机镜像口，建议把网关单独划到一个VLAN，在防火墙上限定它只能访问告警平台/消息服务器，不能横向访问其他设备。很多老系统本身没有安全防护概念，中控室交换机上插一个设备就能扫到全车间，这种事我见过太多，加旁路设备绝不能顺手把安全底线也“旁路”掉。

第三，物理回退原则。实施前先在方案里写清楚：如果网关出故障，现场人员只需拔掉一根网线，业务立即恢复原状。为此，网关与交换机的连接要单独走一个物理口，不能和原SCADA上位机混在同一个接口上。我在验收文档里甚至会附一张“回退操作卡”，写着“拔网线、确认原系统正常、提Ticket”三步流程。

2.3 边缘计算网关选型时该盯住哪些参数

旁路网关不是买一台普通电脑扔机柜里就行，选型参数直接决定后续规则引擎跑得顺不顺、现场环境扛不扛得住。

软件层面我建议选支持Linux系统、可运行Docker容器的网关。Docker的好处在于：协议采集、规则引擎、消息推送可以拆成独立容器，各自升级互不影响，出问题回滚也方便。我自己习惯用Node-RED快速搭数据流，再叠加Python处理复杂告警算法，这套组合对工控场景非常顺手。

3. 从采集到告警：边缘端规则引擎的落地过程

3.1 点位核对、量程转换与数据质量治理

旁路网关把数据拿回来之后，第一件事不是写告警规则，而是先做数据治理。这个环节最容易被人忽略，但绕过它，后面告警全都会变成垃圾信息。

点位核对是最基础的一步。从老系统拿到的点位表经常和PLC程序实际地址对不上，我做过一个项目，点位表上写的是“冷却水温度40001”，实际对应寄存器是40021，中间差了20个地址，直接把规则按表抄上去，告警条件永远触发不了。实施时一定要先用Modbus扫描工具或协议分析工具，把网关上读到的原始值与现场仪表数显逐一对一对，确认地址、数据类型、字节序完全一致后再进告警规则。

量程转换也是老生常谈但反复出错的点。PLC寄存器里存的往往不是实际工程量，比如一个16位整数，满量程65535对应的可能是0到200摄氏度的工程范围。我在规则引擎里统一做一个“模拟量处理”管道：原始值 → 量程转换 → 死区处理 → 归档。任何一个环节不对，告警阈值设置就会失真。

数据质量判断更是直接影响告警可信度。现场常见的坏数据有几种：NaN（非数值）、4095（满码值代表传感器断线）、死值（连续多轮不变化）、跳变值（瞬间超出物理极限）等。规则引擎必须能识别这些状态，否则传感器断线本身就该触发告警，结果因为断线带来一个虚假的“超高值”告警，把真正的问题全部掩盖了。

3.2 五种告警规则的写法与适用场景

数据干净了，才开始真正写告警。我总结下来，老旧SCADA场景下最常用的告警规则有五类。

阈值告警是最基础的一种，判定简单：数值高于上限或低于下限，保持一段时间后触发。适合油温、水压、液位这类模拟量的越限监测。阈值不能直接取报警值本身，要留一点回差，否则数值在报警值附近抖动时会反复触发、恢复、再触发。

变化率告警解决“慢刀子割肉”类问题。比如冷却水温度从35℃到60℃用了三小时，单看阈值可能还没到80℃的报警线，但1分钟内上升超过5℃的这个趋势本身就是异常。变化率告警的计算公式是：(当前值 - 前N秒值) / N秒，做成滑动窗口更稳健。

累计量告警适合瞬时值不敏感、但总量异常的场景。比如气体流量正常波动在每秒几立方米，瞬时超限很难触发，但如果一段时间内的累计流量远超同周期历史值，说明可能存在泄漏或者计量异常。

状态位告警针对PLC里的故障字、运行状态字。这类数据通常是一个寄存器的某一位，0和1代表不同含义。哪些位是紧急停机、哪些位是轻故障，需要和工艺人员逐位确认。规则引擎里把位解析和状态值映射做好，比看一串十六进制数直观得多。

心跳告警是最容易被忽略但最实用的一类。旁路网关每N秒从现场采一次数据，如果某个点位连续M个周期没有任何新数据到达，说明通信链路断了、PLC停机了或者采集程序挂了。心跳告警本质上监控的是“监控系统本身的健康状态”，它不告诉你现场哪里坏了，但告诉你“系统失明了”。失明本身就是最严重的告警。

3.3 去抖、分级与恢复：别让告警变成噪音

告警系统的最大风险不是告警太少，而是告警太多。一线值班员如果一天被几百条垃圾告警轰炸，真正重要的告警来了反而没人当回事，这就是著名的“狼来了”效应。

去抖机制是第一步。规则判定不能单靠一个周期超限就触发，我惯用的做法是：连续N个扫描周期都超限才正式触发告警，N根据轮询间隔调整。比如轮询间隔2秒，N取5，相当于确认系统持续异常10秒才告警，这个时间量级能过滤掉绝大多数通信毛刺和传感器干扰。

分级策略决定通知方式。我一般会把告警分成三级：一般告警通过电子邮件汇总发送，重要的通过钉钉/企业微信群机器人实时推送给值班长，紧急的除了推送消息还直接拨打电话。分级不是拍脑袋定的，要和工艺人员一起梳理，明确哪些问题发生后30分钟内处理即可，哪些需要立即介入。

告警恢复是很多方案的盲区。一个告警触发后，现场恢复正常，如果没人去关，第二天值班人员看到的还是满屏红色。我在边缘网关里做了一个状态机：告警判定 → 持续确认 → 触发通知 → (可选)人工确认 → 恢复判定脉冲 → 自动生成“恢复通知”。其中是否要人工确认要看场景：像“紧急停机”这类必须人工复核的告警，设置为需要在告警平台上点确认；像“液位偏高已回落”这类能自动判定恢复的，系统自动关闭并发送恢复消息，形成闭环。

4. 告警分发实战：钉钉Webhook与告警平台的取舍

4.1 常见通知渠道对比：钉钉、企业微信、飞书、邮件、短信

做一个监控告警系统，不做IT监控的朋友可能觉得不就是发个通知嘛，但真落地时，渠道选型的坑比想象中多。做运维监控的前辈都知道，zabbix配置钉钉Webhook、vCenter证书状态告警手动确认这类问题常年有人踩，核心原因是“指标+规则+通知”这套模型人人都懂，具体到某一个渠道的细节就总是记不住。

单就“老旧SCADA旁路加告警”这个场景，我最常用的是钉钉Webhook做日常推送，邮件做日报汇总，紧急告警用短信/电话兜底。原因很简单：现场值班人员手机里最好找的群就是钉钉群或企业微信群，报数目的就是“群里弹一条红色消息并@相关负责人”，这个诉求用Webhook就能满足，完全不需要引入重型平台。

4.2 钉钉群机器人Webhook配置全过程（含加签与限流）

钉钉群机器人配置本身不复杂，但有几个细节不处理干净就会让告警推送时灵时不灵。我把完整步骤列一下。

第一步，在钉钉群里添加自定义机器人。群设置 → 智能群助手 → 添加机器人 → 自定义，选择“自定义关键字”或“加签”作为安全设置。我强烈建议选加签，自定义关键字太容易被误触发，而且消息内容里强制要带某一关键字，很容易让规则引擎的推送逻辑写得别扭。

第二步，生成加签URL。加签逻辑是把时间戳和密钥拼起来做HMAC-SHA256，再Base64编码作为sign参数拼到Webhook地址上。签名有效期只有60秒，有效避免陌生请求伪装告警。

第三步是消息内容格式。钉钉机器人支持text和markdown两种消息体。我做告警推送一般用markdown格式，写法如下（HTTP body中不需要写全钥匙，只需要结构对即可）：

{ "msgtype": "markdown", "markdown": { "title": "SCADA告警：1号冷却泵温度高", "text": "### 告警通知\n\n**设备**：1号冷却泵\n\n**点位**：泵体温度\n\n**当前值**：86.5℃\n\n**触发时间**：2025-01-15 14:32:18\n\n**级别**：紧急\n\n---\n请立即到中控室确认工况。" } }

在Node-RED里用HTTP Request节点就能很方便地推送消息。唯一要记住的坑是：rule引擎里生成的JSON字符串如果携带了换行和引号，必须做转义，很多推送失败都是因为消息文本里的引号没处理好，把那句“java报raw use param”的报错都引了出来——本质就是把本应是一个字符串的参数当做原始对象序列化导致的问题。

第四步，注意限流。钉钉群机器人官方限制每机器人每分钟最多20条消息，SCADA告警一旦发生风暴，很容易触限。所以我在网关侧还会做一层限速和汇总：同一点位同一告警级别在10分钟内最多推送一条，或把同一分钟内触发的多条告警合并成一条群消息发送。

4.3 告警确认、屏蔽机制里的那些坑

告警触发了，怎么“关掉”是另一个大坑。zabbix7版本的告警手动确认关闭问题、FlashDuty告警屏蔽不生效问题，本质都指向同一件事：告警平台的消息历史、确认动作、屏蔽规则三者之间的状态机没对清楚。

我遇到过最典型的“屏蔽不生效”案例：现场做例检，设备要停一小时，值班人员在告警平台上屏蔽了“1号泵温度高”这条规则，结果停机检修时，1号泵温度上升的告警照样推送出来。排查发现，屏蔽条件是写对了，但边缘网关推送消息时设备名写成了“1号PUMP”，而屏蔽规则里的设备名写的是“1号泵”，两边名字不匹配，屏蔽自然不生效。这类问题不是平台bug，而是告警平台做静默/屏蔽判断时，依赖的字段必须和实际推送字段完全一致。接入前务必把设备名、点位名、级别字段做一次全量对齐。

手动确认关闭的问题也有讲究。zabbix7里告警确认和关闭是两个动作，很多新手以为确认就代表关闭了，实际上确认只是“我知道了”，告警项在满足恢复条件之前仍处于触发状态。SCADA这边也一样，我的建议是：确认与恢复分离。人工确认表示有人看到这条告警了，系统记录确认人和确认时间；只有检测到现场数值恢复或状态位回转，网关才发出恢复消息并把这个告警关闭。这种半自动闭环方式避免了“误关告警导致故障没人管”的责任模糊问题。

如果项目告警来源多、值班团队大，确实值得上FlashDuty这类统一告警平台来聚合事件、做值班排班和升级策略。但要注意，上统一平台的前提是先把通道和字段规则定义好，尤其是屏蔽与抑制策略，不然后面和自建规则引擎一样会踩同样的坑。

4.4 自建规则推送 vs 接入统一告警平台，怎么选

这个选择题我一般按项目体量来定。

小规模场景，比如一台边缘计算网关管一个车间、几十个告警点，完全没必要上统一告警平台，直接在Node-RED里写判断、调Webhook推送到钉钉群就够了，简单直观，改起来也快。

中等规模场景，比如多台网关、多车间、百级以上告警点位，就要考虑告警的聚合、去重、值班轮换问题。此时在FlashDuty或自建Prometheus + Alertmanager这类体系里做统一管理，会比每台网关各推各的清晰得多。

大规模企业级场景，告警要跟ITSM流程对接、要做年度审计报表，那就必须上正规告警管理平台。不过这类项目的重点已经从“怎么告警”变成了“告警怎么治理”，属于另一篇文章的范畴了。

5. 旁路网关上线后的实测感受与避坑记录

5.1 时间同步与轮询延迟，告警时效卡在哪

旁路系统上线后，我遇到的第一类问题是时间戳。边缘网关如果没做NTP同步，跑几天后时钟漂移几十秒很正常。告警消息上的时间戳比实际事件发生时间晚一分钟，值班人员排查时会对不上工艺曲线，非常容易产生误判。网关必须配置NTP对时，且不能在告警消息里用本地时区不带偏移的量。我配置的告警时间戳统一用东八区带偏移格式，方便对接任何平台都不乱套。

轮询延迟是另一道坎。某项目里PLC通信周期较快，但网关走Modbus轮询2秒一圈，某些点位恰好是每条周期末才写入，导致网关读到的值存在最多2秒的滞后。在告警场景里，这个延迟完全可以接受——SCADA告警的目标是分钟级响应，不是PLC停机联锁的毫秒级响应。我实测过整套链路：从现场数值越限到钉钉群弹出消息，最慢的一次约6秒，其中采集轮询2秒、规则判定5次确认约10秒、HTTP推送约1秒。6秒的延迟水平，对于“操作员看上位机发现异常”的传统模式来说，已经是质的飞跃。

5.2 断线、重启、大修期间的数据容错处理

旁路网关就像外挂设备，也会遇到自己的“生存危机”。比如车间大修，PLC断电重启期间，网关一直采不到数据，如果不做处理，几十个点位会在同一时刻触发心跳告警，瞬间刷屏。

我采用的策略是“通信中断静默+恢复后补报”。网关检测到某个点位连续多轮采集失败时，只产生一条“点位通信中断”的汇总告警，而不是每轮都告警一次。等通信恢复后，网关检查中断期间是否有数据需要补采，同时对中断时间段做一个“数据空洞”标记，规则引擎对空洞期间不做任何告警判定，因为这段时间本来就没有可靠数据。这个机制上线后，大修期间钉钉群安静了很多，维修人员的反馈也正面了不少。

还有一个细节：边缘网关自身断电重启后，要保证规则引擎和通信组件自动拉起，千万不要等人工去机柜重启。我一般在部署时配好systemd服务和容器自启动策略，并在网关上加硬件看门狗，确保死机后30秒内自动恢复。

5.3 用数据验证“零影响”：改造前后的对比方法

“无损”不能光靠解释，得用数据说话。我在旁路网关上线前后会做一轮系统影响对比，既做给自己看，也做给业主看，更是给将来验收审计留底。

带上线前的数据：记录原SCADA上位机从发出读请求到收到PLC响应的时间延迟、PLC通信错误计数、上位机CPU占用率等指标，持续采集一周作为基线。

带上线后的数据：同样指标再采一周，对比变化。实测中，端口镜像方式下，SCADA响应延迟变化小于5%，通信错误率没有明显上升；Modbus主动采集方式下，PLC通信负载小幅上升但CPU占用率仍在健康范围。

最后做一次“拔线灰度测试”：找一个允许短暂操作的窗口，拔掉网关接入交换机的网线，观察原SCADA是否正常，5分钟后恢复。这一步验证的是物理层面的故障隔离，也是整套旁路方案安全性的最后一道保险。

5.4 这套方案的适配边界：哪些项目适合，哪些别碰

从我的经验看，旁路加装边缘计算网关尤其适合下面这几类场景：控制层通信链路本身是标准协议（Modbus、OPC UA为主）的系统；生产不能长时间停机、非改造窗口期不可得的老旧系统；历史数据缺失严重、但业主希望“花小钱提升监控能力”的项目；以及集团要求统一告警到中控平台但原系统又不开放接口的情况。

也有不适合硬套旁路方案的情形。如果项目要求毫秒级响应，比如设备联锁保护，边缘网关旁路数据经过采集、轮询、判断再到推送，这个时延链路就满足不了，这类需求必须写在PLC程序里，绝不能外挂。如果项目需要反向控制，比如根据告警自动调节阀门开度，旁路网关只读模式也做不了，需要专门的控制链路设计。另外，涉及到极严格的行业认证许可场景，比如部分流程行业的系统完整性规定，旁路设备是否符合认证要求需要提前跟审核组确认，不要等上线后再被卡。

做过几轮这类项目后，我越来越确信一个判断：很多老旧SCADA系统并不是功能真的不够，而是被人为切断了与现代化运维体系的连接。旁路加装边缘计算网关，用一种近乎“偷师”的方式让老系统重新拥有告警能力，这不仅是技术选型问题，更是一种工程思维：当无法改变系统时，就在它旁边构建一套平行能力。这套方法论放到其它“老而不死”的工业系统上，同样值得复制。