智慧排水系统规划全链路解析：从感知层选型到泵站联调

简介：《城市水务智慧排水系统规划与建设方案》是一份面向智慧城市与水务行业从业者、方案设计师及管理人员的PPT规划资料，系统梳理了智慧水务背景下排水系统的建设思路与落地路径。方案从智慧城市“智能水务”政策切入，定义智慧排水内涵，明确企业、员工、用户、社会四类服务对象，并划分数字化、智能化、智慧化三个建设阶段，同时提炼“更全面感知、更主动服务、更自动控制、更及时应对、更科学决策”五大特点，内容体系较为完整。资源为1个pptx文件，共25页，压缩包大小11.58MB，便于直接阅读与二次修改。PPT中包含主要系统功能介绍，如生产调度、生产管理、营业管理、民生服务等模块，并涵盖GIS地理信息系统、手机巡检、排水管线模型、爆管辅助决策、数据监控与分析等典型应用场景，可作为水务企业“一网统管”及智慧排水项目立项规划、方案汇报时的参考模板。目前已有193人学习浏览，适合需要开展城市排水数字化、智慧化规划的建设单位、设计院及集成商借鉴使用。

1. 一场暴雨过后，排水系统的问题从来不在天上

城市内涝的根子大多不在雨大，在于管网底数不清、液位不明、泵站各自为战。管网图纸在档案室里，井盖下面是实时的水位却没人知道；泵站该开几台机组全凭老师傅经验；排水口有没有晴天污水混流，要等环保督察上门才发现。智慧排水系统的价值，就是把管网从“不可见”变成“可监测、可调度、可推演”。这篇博文面向水务信息化工程师、智慧城市方案架构师，以及从给排水专业转做信息化的从业者，讲清楚一套排水系统规划的完整技术链条：从感知层设备选型、传输网络设计、数据平台搭建，到内涝预警算法和泵站联调规则，最后落到一份 25 页方案该怎么组织内容才能通过评审——把“规划”二字做实，而不是画一堆架构图交差。

2. 感知层选型先行：液位、流量、雨量三类监测怎么配

2.1 四层架构先立住，感知层是一切规则的地基

任何一份智慧排水方案，开篇最先要定的不是平台功能，而是总体架构。常见做法是分成四层：

• 感知层：液位计、流量计、雨量计、水质监测、井盖状态监测
• 传输层：NB-IoT / 4G / LoRa 混合组网
• 平台层：数据接入、清洗、存储、GIS 一张图
• 应用层：内涝预警、泵站联调、巡检养护、排水户监管

感知层决定整个系统的数据质量上限。很多项目把预算大头花在平台软件上，传感器却选最便宜的，最后内涝预警模型因为液位数据跳变和断档，成了一个摆设。感知层的原则是：宁可少装，不可装错；参数留足余量，后期维护才省心。

2.2 布点密度怎么定：先易涝点，再主干管，最后覆盖排放口

传感器的布点不是均匀撒网，而是按“风险等级 × 数据价值”排序。排水管网监测的优先序列是：

1. 历史易涝点（道路积水点）、下穿隧道、地下车库入口
2. 泵站前池和出水口——这里液位直接决定水泵启停逻辑
3. 主干管网的关键节点（管径变化处、坡降突变处、交汇井）
4. 雨水排放口、污水处理厂进水口（关注晴天流量异常）
5. 城市河道的上中下游水位站

布点密度上，我一般按“每 2～3 公里主干管一个监测点”做初设，易涝点加密到 500 米一个，泵站前池必装。例如一个建成区面积 50 平方公里的城市，从零搭建一期系统，感知点位通常在 200～400 个之间。

2.2.1 感知设备选型的 3 个关键参数

液位计量程的选择要留出 1.5 倍余量。如果管顶高程为 5 米，选 0～10 m 的雷达或压力式液位计，既覆盖满管溢流测值，又防止汛期高水位顶满量程。量程选小了的典型后果：汛期液位曲线触顶平头，内涝判定算法直接失效。

2.2.2 NB-IoT 液位计报文解析的最小 Python 脚本

感知设备采购时最容易被忽略的是数据报文协议不统一，有的走 JSON，有的是十六进制字节流。下面这段代码用于解析某类压力式液位计上报的十六进制报文，提取液位和电池电压：

import struct import datetime def parse_level_report(hex_str: str) -> dict: """ 解析液位计NB-IoT上报报文（十六进制字符串） 报文格式示例：AA 55 01 0C 1F 4B 03 E8 0A 2C 其中 byte[0:2] 为帧头，byte[2] 为设备状态， byte[3:5] 为液位原始值，byte[5:7] 为电池电压，byte[8] 为CRC """ raw = bytes.fromhex(hex_str.replace(" ", "")) if len(raw) < 9: raise ValueError(f"报文长度异常: {len(raw)}") head = raw[0:2] if head != b"\xaa\x55": raise ValueError("帧头校验失败") status = raw[2] # 0x00 正常, 0x01 低电压, 0x02 传感器故障 level_raw = struct.unpack(">H", raw[3:5])[0] # 2字节大端无符号整数 voltage_raw = struct.unpack(">H", raw[5:7])[0] # 量程0~5米，ADC精度12位（0~4095） level_m = round(level_raw / 4095 * 5.0, 2) voltage = round(voltage_raw / 1000.0, 2) return { "ts": datetime.datetime.now().isoformat(timespec="seconds"), "level_m": level_m, "voltage": voltage, "status_code": status, "normal": status == 0x00 and 0.0 <= level_m <= 5.0 } if __name__ == "__main__": sample = "AA 55 01 0C 1F 4B 03 E8 0A 2C" print(parse_level_report(sample))

这段代码把设备上报的十六进制帧拆成液位和电压两个物理量。逻辑说明：帧头 0xAA55 用于同步和过滤噪声；液位用大端无符号整数解析，除以 12 位 ADC 满量程 4095，再乘量程 5 米得到实际液位。参数说明：status_code 的 0x01 低电压要接入告警工单；level_m 超出量程上限或为负数时，置 normal 为 False，后续数据清洗环节直接剔除。接入 Kafka 或 EMQX 后，把这个解析函数做成消费者即可。

3. 从传感器到数据平台：传输组网与清洗入库的落地细节

3.1 NB-IoT、4G、LoRa 怎么选：先算流量和功耗账

感知层数据传到平台，传输链路按数据量和实时性需求选择。参考下面这张对比表：

选型的边界条件有三个：一是运营商 NB-IoT 覆盖是否到了检查井所在的市政道路上，项目进场前必须拿测试终端实测信号强度（RSRP 应大于 -110 dBm）；二是泵站和易涝点通常靠近供电点位，优先 4G，省去电池更换成本；三是 LoRa 适合厂区、园区内部几十个点位的场景，市政道路上的分散点位不建议自建网关，运维成本大于节省的流量费。

3.2 统一接入协议：一个 JSON 报文样本胜过一页架构图

平台接入层要屏蔽不同厂家的报文差异，内部统一成标准 JSON 报文。下面是一个液位数据进入平台的标准格式：

{ "device_id": "LV-2024-0317", "type": "level", "ts": "2024-07-22T14:30:00+08:00", "value": 3.42, "unit": "m", "battery": 3.71, "rssi": -87, "geo": { "lon": 113.26438, "lat": 23.12918 } }

字段说明：device_id 是设备资产编码，对应 GIS 里的井盖编号和管网拓扑节点；ts 使用 ISO8601 本地时区格式，避免多系统间时区错乱；rssi 信号强度用于判断点位是否需要调整天线或改换通讯制式。接入层收到该报文后，按 device_id + ts 做去重索引，防止网络重传导致的重复数据。

3.3 数据清洗的三个必写规则：负值、突跳和恒值

管网监测数据常见三类脏数据：传感器故障产生的负值（比如压力式液位计断线返回 -9999）、瞬时突跳（漂浮物遮挡雷达波）、长时间恒值（传感器堵死或淤泥掩埋）。下面给出一个清洗函数的最小实现：

import pandas as pd def clean_level_series(df: pd.DataFrame, max_delta: float = 0.5) -> pd.DataFrame: """ df 必须包含列: ts, device_id, level_m, status_code max_delta: 相邻两条记录允许的最大液位变化, 单位米 """ df = df.sort_values("ts").reset_index(drop=True) # 规则1: 剔除负值和超过量程的值 df = df[(df["level_m"] >= 0.0) & (df["level_m"] <= 8.0)] # 规则2: 突跳过滤——相邻液位差值超过阈值时, 用前值填充 delta = df["level_m"].diff().abs() df["level_m"] = df["level_m"].mask(delta > max_delta).ffill() # 规则3: 恒值检测——连续6条(90分钟)数值完全不变且非0, 标记为故障 df["is_stuck"] = ( (df["level_m"] == df["level_m"].shift()) .rolling(window=6, min_periods=6) .sum() >= 5 ) return df

逻辑说明：突跳过滤用的是前后差分法，一次跳变超过 0.5 米（参数可调），视为雷达波受干扰，用前值前向填充；恒值检测用滚动窗口统计连续不变的数量，标记后推送工单让巡检人员去现场疏通传感器。参数说明：max_delta 在泵站前池的出入口管道场景要调到 1.0 米，因为水泵启停瞬间液位确实可以在 30 秒内变化很大；而在居民区市政管网的检查井里，0.3 米更合理。清洗后的数据落到 ClickHouse 或 TimescaleDB，按设备 ID 和时间分区。

3.4 GIS 一张图：坐标偏差 0.5 米以上就要返工

排水系统平台的地图底图，建议叠加三类数据：市政管网普查数据（管径、材质、埋深、流向）、遥感影像或倾斜摄影实景、实时监测点位。常见问题是管网普查数据在 CAD 里转出来的坐标系统和在线地图不一致，导致管线偏移到建筑物里。处理办法：在集成前做一个坐标转换校验脚本，随机抽取 30 个检查井，用 RTK 实测坐标与 GIS 显示坐标比对，偏差大于 0.5 米的一律返工，不允许直接上系统。

一张能用的排水 GIS 图，核心图层至少包括：管网管段（按管径着色）、检查井（按液位状态分级）、泵站（显示运行状态和启停记录）、易涝点（关联历史积水深度）、排放口（关联水质监测）。液位状态的分级显示规则是：低于管底 1 米为正常（绿色）、管底以上至管顶 80% 为关注（黄色）、超过管顶 80% 为告警（红色）、满管溢流为严重（深红）。

4. 内涝预警和泵站联调：监测数据怎么变成调度指令

4.1 积水事件判定别只盯一个阈值：复合判断的三层规则

很多项目的内涝预警就是“液位超过 2 米就报警”，结果汛期每小时弹几十条告警，值班人员直接关掉通知。要做一个有效可用的积水预警，至少叠加三个维度：

1. 液位绝对值：超过管顶（满管）的 80% 即进入警戒状态
2. 液位变化速率：15 分钟内上涨超过 0.4 米，说明短时强降雨正在快速汇聚
3. 雨量联动：过去 10 分钟雨量超过 3 毫米，确认是降雨导致，排除管道施工回水等误报

下面给出一个基于规则引擎的判定代码：

def judge_flood_risk(level: float, delta_15min: float, rain_10min: float, pipe_crown_m: float) -> str: """ 积水风险等级判定 level: 当前液位(米) delta_15min: 最近15分钟液位涨幅(米) rain_10min: 最近10分钟降雨量(毫米) pipe_crown_m: 该点位管顶高程(米) """ fill_ratio = level / pipe_crown_m if fill_ratio >= 1.0 and rain_10min >= 1.0: return "S1_严重积水_立即处置" if fill_ratio >= 0.8 or (delta_15min >= 0.4 and rain_10min >= 3.0): return "S2_警戒_加强关注" if delta_15min >= 0.2 and rain_10min >= 1.0: return "S3_关注_通报巡检" return "正常"

这段代码的关键在于避免单一阈值误报。S1 级别的判定要求“满管 + 有降雨”两个条件同时成立，避免管道回水或下游顶托造成的短暂满管触发最高级别告警。S2 级别把“15 分钟涨 0.4 米”作为速率条件，相当于抓住了陡涨特征。注意，每个易涝点的 pipe_crown_m 要从 GIS 管网普查数据里取，不能统一设置——同样是 2 米液位，在 1.8 米管径的节点已经溢流，在 2.5 米管径的节点还在安全范围。

4.1.1 告警去重的幂等设计

告警推送要设计成幂等的，不能 5 分钟上报一次就推一次短信。常见做法是引入一个状态机：当 judge_flood_risk 返回值为 S1/S2 时，向消息队列发送一条告警事件；后续 30 分钟内同一 device_id 如果仍处于同一级别，不再重复推送，只在状态升级时（如 S2 → S1）再次提醒。这个去重可以在 Flink 里用状态变量实现，也可以在 ClickHouse 里查最近一条同级别记录的时间来简化实现。

4.2 泵站联调逻辑：前池液位做主控，管网液位做反馈

泵站调度是排水系统里最直接产生价值的场景。传统泵站靠人工看液位开停机，智慧化之后要做的不是全自动，而是“建议 + 远程确认”的闭环。联调规则一般分三级：

• 单泵控制：前池液位超过启泵液位（比如 2.5 米）自动建议开 1 台泵
• 多泵轮换：连续运行超过 2 小时的泵优先切换到备用泵，均衡磨损
• 区域联调：下游泵站前池液位持续偏高时，同步调高上游泵站排水量，防止“上游拼命排、下游吃不下”

泵站联调的报警规则里要注意防震荡：水泵启停频率不能太高，通常设一个液位死区，比如启动液位 2.5 米、停止液位 1.0 米，中间 1.5 米不做动作。如果没有死区，液位在启停阈值附近波动会导致水泵频繁启停，电机损坏是小事，电网冲击才是大事。

4.3 调度指令的闭环不能停在“下发成功”

泵站远程控制必须走工单闭环：控制指令发起 → 泵站 PLC 接受 → 执行反馈（电流、流量、闸门开度）→ 复核确认 → 归档。很多项目只做到第二步就停了，没有执行反馈，中控室发出“开启 2 号泵”的指令后，到底开没开全靠打电话确认。设计数据表时，至少要有一张 pump_command_log 表，记录 command_id、device_id、cmd_type（start/stop/remote/local）、send_time、ack_time、result_code、operator。这里的 ack_time 和 result_code 就是闭环的凭证，也是日后复盘系统调度的依据。

4.4 管网水力模型的位置：监测数据用于率定，不是替代模型

内涝预警做到一定阶段，要引入管网水力模型（InfoWorks ICM、MIKE URBAN、SWMM 都常见），但模型的作用不是替代实时监测，而是做两件事：

第一，率定。用液位计和流量计的历史数据调整模型的糙率系数、局部水头损失系数，让模型模拟结果和实测曲线贴合（纳什效率系数 NSE 大于 0.7 可以认为合格）。没有真实监测数据，模型参数就是拍脑袋，推演结果没人敢信。

第二，推演。输入设计暴雨情景（比如 50 年一遇 24 小时降雨），模拟管网哪些节点先满管、哪些路段先积水、淹多大范围，用于评估改造方案和排涝预案。这个场景监测数据反而是配角，模型是主角。在方案里表达清楚“监测服务于运行，模型服务于规划”，评审专家就不会挑你逻辑上的刺。

5. 25 页方案 PPT 的三条主线：页面分配与每页的必含要素

5.1 25 页的黄金分配表：按评审逻辑排，不按技术模块排

一份完整规划的页数不是越多越好，“共 25 页”意味着评审对象是决策层，他们要看到的是问题、方法、投资和效果。推荐的页面分配如下：

每一页的负责人和技术要点都很明确。比如第 8～12 页的点位布设表里，必须写清楚设备类型、量程、安装位置、供电方式——评审专家最反感那种只写了“安装液位计 200 套”却没有参数说明的配置表。

5.2 每页标题写成一句结论，而不是名词短语

方案 PPT 和写代码一样，命名要见文知义。“感知层建设方案”这种标题就没信息量，改成“液位计 + 雨量计双网覆盖，易涝点 500 米一个监测断面”就直观得多。25 页每页标题都是一句技术判断，评审翻完目录就能复述出你的整体思路，这一版方案就算立住了。

技术细节的取舍上，方案里至少要有一个可验证的关键指标，比如“系统建成后，易涝点监测覆盖率 100%，内涝预警提前量不小于 30 分钟”。这类指标要写得可考核，不要写“提升排水智能化水平”这种没法验收的词。概算页同理，要按感知设备、网络通讯、平台软件、系统集成、运维费五类分项列示，运维费按每年 8%～12% 的初投资估算，这是业主最关心也最容易漏算的一笔钱。

5.3 汇报顺序的建议：先讲数据闭环，再讲功能清单

到一个容易踩的坑是前 10 页都在讲后台功能菜单，评审问“这些功能解决什么实际问题”时又翻回前面讲痛点。对 25 页这种紧凑体量，建议把“数据怎么采 → 怎么传 → 怎么算 → 怎么用”这条链路讲完整，功能只是链路每个环节上的落点。表达时多用“监测数据驱动”“预降预排”“工单闭环”这类明确动词，少用“赋能”“助力”“智慧化升级”这类虚词。方案最后停在风险对策页上很合适——把“数据断传、设备被淹、通讯拥堵”三类风险摆到桌面上，对应给出备用频段和本地存储策略，这比任何“展望未来”都更能让评审信服。

本文还有配套的精品资源，点击获取