水务泵站 SCADA：溢流、内涝、通信中断怎么报，调度才跟得上

水务报警和工厂报警，差在发现路径，不在画面颜色

工厂里液位越限，操作员通常还在控制室，几分钟内能走到现场。水务泵站分散在城区各处，夜间常常只留少量值班或无人在站。如果只按工厂那套「停机 / 质量 / 安全」来分，会漏掉水务真正要处理的事：污水溢流、道路内涝，以及「站点失联」本身。

更关键的差别是发现路径。许多水务单位至今仍是投诉驱动：热线接到积水、异味或冒溢，调度再派人去站。SCADA 要解决的，不是把工厂报警清单搬到泵站，而是让溢流和内涝在投诉之前从站点报出来。

• 地理分散：报警来自城区各处的提升站、污水站、加压站，调度员看不见现场，只能靠信号判断要不要派车
• 公共影响先于产量：溢流和内涝影响的是市政环境和居民，不是产线停机分钟数
• 投诉仍是一条发现通道：热线工单与现场信号对不上时，往往说明漏点或通信已经中断
• 降雨会让多站同时告警：同一场雨让多座泵站液位一起上涨，工厂那种单机连锁模型套不上
• 通信中断本身就是事件：工厂里网断了可以走到现场；水务失联的站点，调度无法确认是否已经在溢流

所以水务报警设计的第一问不是「分几级」，而是：这条信号能不能在居民打电话之前，让调度判断要不要派人。

溢流、内涝、通信中断、机组故障：按后果分级，而不是按点位数量

颜色、声音和死区怎么配，工厂场景里已经有专文。水务这边更需要先按事件后果排优先级：溢流和内涝一旦发生，处置窗口按分钟计；机组故障要看是否还有备用泵、当时是不是雨天；通信中断在晴天和暴雨里的含义完全不同。

下面四类是调度日常真正会碰到的，建议各自写成独立事件类型，而不是全部塞进「液位高」这一条。

• 溢流：集水井高高液位、溢流堰、出水口异常——一旦成立，按需立即派抢修，并同步排水调度；这是公共环境影响，不是设备保养提醒
• 内涝：站外积水、雨量与泵站停机同时出现、道路监测点越限——要和降雨过程对照，判断是本站抽排不足还是上游来水超过站的额定流量
• 通信中断：网关心跳丢失、MQTT 上云中断——晴天可按巡检安排核线；降雨过程中应按「未知是否溢流」升级，先确认供电和链路，而不是等投诉
• 机组故障：过载、变频器跳闸、出口压力异常——有备用泵时先切备用并安排检修；末台泵停且液位在涨，按溢流风险升级，而不是按单台设备故障关闭

分散站点怎么推送、谁值班：目标价值须在项目中验证

站点分散以后，不可能每座站都留全班人员。推送和值班要一起设计：哪些事件进调度大屏，哪些同时发到值班手机，雨天和晴天是否同一套名单。值守模式（少人值守或无人值守）以及从告警到派单的时效，都属于目标价值，须在具体项目中验证，不能写成已经普遍达成的结果。

• 按事件类型分流：溢流、内涝进值班即时通道；机组故障在有备用时进运维班组；通信中断按是否降雨切换通道
• 按时段换名单：夜间、节假日只保留能出门的抢修负责人，避免把所有事件推给同一部手机
• 未确认要升级：超时未复位、未派单的溢流和失联，向值班长或备班升级，而不是反复响同一条
• 投诉工单回流：热线已经报了积水，但 SCADA 无对应信号，应记为覆盖缺口，回头补传感器或查通信，而不是只关工单

推送通道可以是短信、即时通讯或语音，具体选哪种取决于当地值班习惯和运营商条件。通道多不等于响应快：没有按事件分流的群发，值班手机会很快被静音。

事件类型、信号来源、调度侧动作对照

调度真正要用的不是一张颜色表，而是「这条事件从哪来、调度该做什么」。下表按水务现场常见事件列出，可作为单站试点时核对信号与职责的底稿，不是通用标准。

目前已确认的现场范围是单一泵站的 IoT 网关接入、ModbusTCP 采集与 MQTT 上云。表中的派单时效、多通道推送和少人值守，属于目标价值，须在具体项目中按站型、通信条件和值班编制验证。

和群控模板怎么衔接：先把事件定义进单站，再谈跨站

多站点群控另有专文讲标准站模板、地址表导出、网关接入、平台汇聚这条复制思路。本篇只强调一点：溢流、内涝、通信中断、机组故障这四类事件，以及投诉回流规则，应写进单站模板的报警定义里，而不是等站点多了再在调度中心临时拼。

模板能继承的是事件类型、信号来源约定和调度动作口径，这样后一座站不会把「液位高」定义成和前一座完全不同的东西。模板不能替代的是逐站核对：溢流堰有没有信号、站外有没有积水监测、热线工单能不能回到同一条事件。

能力边界需要写清楚。已确认的交付范围是单一泵站网关接入、ModbusTCP、MQTT 上云与地址表规划。群控模板、跨站汇聚属于工程资产与方案能力，不等于已经在多个城市落地。把归档线索说成多城均已部署，会误导采购判断。