简介《城市水务智慧排水系统规划与建设方案》是一份面向智慧城市与水务行业从业者、方案设计师及管理人员的PPT规划资料系统梳理了智慧水务背景下排水系统的建设思路与落地路径。方案从智慧城市“智能水务”政策切入定义智慧排水内涵明确企业、员工、用户、社会四类服务对象并划分数字化、智能化、智慧化三个建设阶段同时提炼“更全面感知、更主动服务、更自动控制、更及时应对、更科学决策”五大特点内容体系较为完整。资源为1个pptx文件共25页压缩包大小11.58MB便于直接阅读与二次修改。PPT中包含主要系统功能介绍如生产调度、生产管理、营业管理、民生服务等模块并涵盖GIS地理信息系统、手机巡检、排水管线模型、爆管辅助决策、数据监控与分析等典型应用场景可作为水务企业“一网统管”及智慧排水项目立项规划、方案汇报时的参考模板。目前已有193人学习浏览适合需要开展城市排水数字化、智慧化规划的建设单位、设计院及集成商借鉴使用。1. 一场暴雨过后排水系统的问题从来不在天上城市内涝的根子大多不在雨大在于管网底数不清、液位不明、泵站各自为战。管网图纸在档案室里井盖下面是实时的水位却没人知道泵站该开几台机组全凭老师傅经验排水口有没有晴天污水混流要等环保督察上门才发现。智慧排水系统的价值就是把管网从“不可见”变成“可监测、可调度、可推演”。这篇博文面向水务信息化工程师、智慧城市方案架构师以及从给排水专业转做信息化的从业者讲清楚一套排水系统规划的完整技术链条从感知层设备选型、传输网络设计、数据平台搭建到内涝预警算法和泵站联调规则最后落到一份 25 页方案该怎么组织内容才能通过评审——把“规划”二字做实而不是画一堆架构图交差。2. 感知层选型先行液位、流量、雨量三类监测怎么配2.1 四层架构先立住感知层是一切规则的地基任何一份智慧排水方案开篇最先要定的不是平台功能而是总体架构。常见做法是分成四层感知层液位计、流量计、雨量计、水质监测、井盖状态监测传输层NB-IoT / 4G / LoRa 混合组网平台层数据接入、清洗、存储、GIS 一张图应用层内涝预警、泵站联调、巡检养护、排水户监管感知层决定整个系统的数据质量上限。很多项目把预算大头花在平台软件上传感器却选最便宜的最后内涝预警模型因为液位数据跳变和断档成了一个摆设。感知层的原则是宁可少装不可装错参数留足余量后期维护才省心。2.2 布点密度怎么定先易涝点再主干管最后覆盖排放口传感器的布点不是均匀撒网而是按“风险等级 × 数据价值”排序。排水管网监测的优先序列是历史易涝点道路积水点、下穿隧道、地下车库入口泵站前池和出水口——这里液位直接决定水泵启停逻辑主干管网的关键节点管径变化处、坡降突变处、交汇井雨水排放口、污水处理厂进水口关注晴天流量异常城市河道的上中下游水位站布点密度上我一般按“每 23 公里主干管一个监测点”做初设易涝点加密到 500 米一个泵站前池必装。例如一个建成区面积 50 平方公里的城市从零搭建一期系统感知点位通常在 200400 个之间。2.2.1 感知设备选型的 3 个关键参数设备类型核心参数量程供电方式通讯方式安装位置数据频率压力式液位计05 m / 010 m精度 ±0.5% FS电池供电35 年NB-IoT检查井底部避开淤泥15 分钟一报告警 5 分钟雷达液位计010 m盲区 20 cm 以内太阳能 电池4G / NB-IoT明渠、泵站前池、下穿隧道10 分钟一报多普勒流量计流速 0.025 m/s市电 / 太阳能4G管底安装需要满管或恒定流10 分钟一报翻斗式雨量计0.1 mm 分辨率电池NB-IoT开阔无遮挡逐分钟累积电子水尺量程按现场高差定太阳能4G易涝点立杆5 分钟一报液位计量程的选择要留出 1.5 倍余量。如果管顶高程为 5 米选 010 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(timespecseconds), 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 怎么选先算流量和功耗账感知层数据传到平台传输链路按数据量和实时性需求选择。参考下面这张对比表通讯制式单点成本功耗单点日数据量15分钟一报200字节/条适用场景NB-IoT较低极低2 节电池用 35 年约 230 KB/月液位计、雨量计、井盖监测4G较高中需市电或太阳能无限制泵站视频、流量计、电子水尺LoRa需自建网关低约 230 KB/月园区、厂区内局部密集布点选型的边界条件有三个一是运营商 NB-IoT 覆盖是否到了检查井所在的市政道路上项目进场前必须拿测试终端实测信号强度RSRP 应大于 -110 dBm二是泵站和易涝点通常靠近供电点位优先 4G省去电池更换成本三是 LoRa 适合厂区、园区内部几十个点位的场景市政道路上的分散点位不建议自建网关运维成本大于节省的流量费。3.2 统一接入协议一个 JSON 报文样本胜过一页架构图平台接入层要屏蔽不同厂家的报文差异内部统一成标准 JSON 报文。下面是一个液位数据进入平台的标准格式{ device_id: LV-2024-0317, type: level, ts: 2024-07-22T14:30:0008: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(dropTrue) # 规则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(window6, min_periods6) .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 米就报警”结果汛期每小时弹几十条告警值班人员直接关掉通知。要做一个有效可用的积水预警至少叠加三个维度液位绝对值超过管顶满管的 80% 即进入警戒状态液位变化速率15 分钟内上涨超过 0.4 米说明短时强降雨正在快速汇聚雨量联动过去 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 m 启 / 1.0 m 停降雨初期提前 30 分钟预降水位同步预降暴雨预警信号发布降雨峰值全机组运行全机组运行 溢流闸门状态上报S1 级预警确认下游顶托降频运行 / 暂停满负荷强排下游河道水位超过泵站出水口 0.5 m泵站联调的报警规则里要注意防震荡水泵启停频率不能太高通常设一个液位死区比如启动液位 2.5 米、停止液位 1.0 米中间 1.5 米不做动作。如果没有死区液位在启停阈值附近波动会导致水泵频繁启停电机损坏是小事电网冲击才是大事。4.3 调度指令的闭环不能停在“下发成功”泵站远程控制必须走工单闭环控制指令发起 → 泵站 PLC 接受 → 执行反馈电流、流量、闸门开度→ 复核确认 → 归档。很多项目只做到第二步就停了没有执行反馈中控室发出“开启 2 号泵”的指令后到底开没开全靠打电话确认。设计数据表时至少要有一张 pump_command_log 表记录 command_id、device_id、cmd_typestart/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 页”意味着评审对象是决策层他们要看到的是问题、方法、投资和效果。推荐的页面分配如下页码区间内容板块页数每一页必须给出13现状问题与需求分析3 页一张内涝点位分布图 一张管网问题清单表47总体架构设计4 页架构分层图 一张数据流说明表812感知与网络方案5 页点位布设表 一张通讯组网拓扑1316平台与数据方案4 页功能清单表 数据表结构说明1720应用场景与调度规则4 页内涝预警流程 泵站联调规则表2123实施计划与概算3 页里程碑甘特表 分项概算表2425效益分析与风险对策2 页一张效益对比表 一张风险应对表每一页的负责人和技术要点都很明确。比如第 812 页的点位布设表里必须写清楚设备类型、量程、安装位置、供电方式——评审专家最反感那种只写了“安装液位计 200 套”却没有参数说明的配置表。5.2 每页标题写成一句结论而不是名词短语方案 PPT 和写代码一样命名要见文知义。“感知层建设方案”这种标题就没信息量改成“液位计 雨量计双网覆盖易涝点 500 米一个监测断面”就直观得多。25 页每页标题都是一句技术判断评审翻完目录就能复述出你的整体思路这一版方案就算立住了。技术细节的取舍上方案里至少要有一个可验证的关键指标比如“系统建成后易涝点监测覆盖率 100%内涝预警提前量不小于 30 分钟”。这类指标要写得可考核不要写“提升排水智能化水平”这种没法验收的词。概算页同理要按感知设备、网络通讯、平台软件、系统集成、运维费五类分项列示运维费按每年 8%12% 的初投资估算这是业主最关心也最容易漏算的一笔钱。5.3 汇报顺序的建议先讲数据闭环再讲功能清单到一个容易踩的坑是前 10 页都在讲后台功能菜单评审问“这些功能解决什么实际问题”时又翻回前面讲痛点。对 25 页这种紧凑体量建议把“数据怎么采 → 怎么传 → 怎么算 → 怎么用”这条链路讲完整功能只是链路每个环节上的落点。表达时多用“监测数据驱动”“预降预排”“工单闭环”这类明确动词少用“赋能”“助力”“智慧化升级”这类虚词。方案最后停在风险对策页上很合适——把“数据断传、设备被淹、通讯拥堵”三类风险摆到桌面上对应给出备用频段和本地存储策略这比任何“展望未来”都更能让评审信服。本文还有配套的精品资源点击获取 智慧排水系统规划全链路解析：从感知层选型到泵站联调
简介《城市水务智慧排水系统规划与建设方案》是一份面向智慧城市与水务行业从业者、方案设计师及管理人员的PPT规划资料系统梳理了智慧水务背景下排水系统的建设思路与落地路径。方案从智慧城市“智能水务”政策切入定义智慧排水内涵明确企业、员工、用户、社会四类服务对象并划分数字化、智能化、智慧化三个建设阶段同时提炼“更全面感知、更主动服务、更自动控制、更及时应对、更科学决策”五大特点内容体系较为完整。资源为1个pptx文件共25页压缩包大小11.58MB便于直接阅读与二次修改。PPT中包含主要系统功能介绍如生产调度、生产管理、营业管理、民生服务等模块并涵盖GIS地理信息系统、手机巡检、排水管线模型、爆管辅助决策、数据监控与分析等典型应用场景可作为水务企业“一网统管”及智慧排水项目立项规划、方案汇报时的参考模板。目前已有193人学习浏览适合需要开展城市排水数字化、智慧化规划的建设单位、设计院及集成商借鉴使用。1. 一场暴雨过后排水系统的问题从来不在天上城市内涝的根子大多不在雨大在于管网底数不清、液位不明、泵站各自为战。管网图纸在档案室里井盖下面是实时的水位却没人知道泵站该开几台机组全凭老师傅经验排水口有没有晴天污水混流要等环保督察上门才发现。智慧排水系统的价值就是把管网从“不可见”变成“可监测、可调度、可推演”。这篇博文面向水务信息化工程师、智慧城市方案架构师以及从给排水专业转做信息化的从业者讲清楚一套排水系统规划的完整技术链条从感知层设备选型、传输网络设计、数据平台搭建到内涝预警算法和泵站联调规则最后落到一份 25 页方案该怎么组织内容才能通过评审——把“规划”二字做实而不是画一堆架构图交差。2. 感知层选型先行液位、流量、雨量三类监测怎么配2.1 四层架构先立住感知层是一切规则的地基任何一份智慧排水方案开篇最先要定的不是平台功能而是总体架构。常见做法是分成四层感知层液位计、流量计、雨量计、水质监测、井盖状态监测传输层NB-IoT / 4G / LoRa 混合组网平台层数据接入、清洗、存储、GIS 一张图应用层内涝预警、泵站联调、巡检养护、排水户监管感知层决定整个系统的数据质量上限。很多项目把预算大头花在平台软件上传感器却选最便宜的最后内涝预警模型因为液位数据跳变和断档成了一个摆设。感知层的原则是宁可少装不可装错参数留足余量后期维护才省心。2.2 布点密度怎么定先易涝点再主干管最后覆盖排放口传感器的布点不是均匀撒网而是按“风险等级 × 数据价值”排序。排水管网监测的优先序列是历史易涝点道路积水点、下穿隧道、地下车库入口泵站前池和出水口——这里液位直接决定水泵启停逻辑主干管网的关键节点管径变化处、坡降突变处、交汇井雨水排放口、污水处理厂进水口关注晴天流量异常城市河道的上中下游水位站布点密度上我一般按“每 23 公里主干管一个监测点”做初设易涝点加密到 500 米一个泵站前池必装。例如一个建成区面积 50 平方公里的城市从零搭建一期系统感知点位通常在 200400 个之间。2.2.1 感知设备选型的 3 个关键参数设备类型核心参数量程供电方式通讯方式安装位置数据频率压力式液位计05 m / 010 m精度 ±0.5% FS电池供电35 年NB-IoT检查井底部避开淤泥15 分钟一报告警 5 分钟雷达液位计010 m盲区 20 cm 以内太阳能 电池4G / NB-IoT明渠、泵站前池、下穿隧道10 分钟一报多普勒流量计流速 0.025 m/s市电 / 太阳能4G管底安装需要满管或恒定流10 分钟一报翻斗式雨量计0.1 mm 分辨率电池NB-IoT开阔无遮挡逐分钟累积电子水尺量程按现场高差定太阳能4G易涝点立杆5 分钟一报液位计量程的选择要留出 1.5 倍余量。如果管顶高程为 5 米选 010 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(timespecseconds), 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 怎么选先算流量和功耗账感知层数据传到平台传输链路按数据量和实时性需求选择。参考下面这张对比表通讯制式单点成本功耗单点日数据量15分钟一报200字节/条适用场景NB-IoT较低极低2 节电池用 35 年约 230 KB/月液位计、雨量计、井盖监测4G较高中需市电或太阳能无限制泵站视频、流量计、电子水尺LoRa需自建网关低约 230 KB/月园区、厂区内局部密集布点选型的边界条件有三个一是运营商 NB-IoT 覆盖是否到了检查井所在的市政道路上项目进场前必须拿测试终端实测信号强度RSRP 应大于 -110 dBm二是泵站和易涝点通常靠近供电点位优先 4G省去电池更换成本三是 LoRa 适合厂区、园区内部几十个点位的场景市政道路上的分散点位不建议自建网关运维成本大于节省的流量费。3.2 统一接入协议一个 JSON 报文样本胜过一页架构图平台接入层要屏蔽不同厂家的报文差异内部统一成标准 JSON 报文。下面是一个液位数据进入平台的标准格式{ device_id: LV-2024-0317, type: level, ts: 2024-07-22T14:30:0008: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(dropTrue) # 规则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(window6, min_periods6) .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 米就报警”结果汛期每小时弹几十条告警值班人员直接关掉通知。要做一个有效可用的积水预警至少叠加三个维度液位绝对值超过管顶满管的 80% 即进入警戒状态液位变化速率15 分钟内上涨超过 0.4 米说明短时强降雨正在快速汇聚雨量联动过去 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 m 启 / 1.0 m 停降雨初期提前 30 分钟预降水位同步预降暴雨预警信号发布降雨峰值全机组运行全机组运行 溢流闸门状态上报S1 级预警确认下游顶托降频运行 / 暂停满负荷强排下游河道水位超过泵站出水口 0.5 m泵站联调的报警规则里要注意防震荡水泵启停频率不能太高通常设一个液位死区比如启动液位 2.5 米、停止液位 1.0 米中间 1.5 米不做动作。如果没有死区液位在启停阈值附近波动会导致水泵频繁启停电机损坏是小事电网冲击才是大事。4.3 调度指令的闭环不能停在“下发成功”泵站远程控制必须走工单闭环控制指令发起 → 泵站 PLC 接受 → 执行反馈电流、流量、闸门开度→ 复核确认 → 归档。很多项目只做到第二步就停了没有执行反馈中控室发出“开启 2 号泵”的指令后到底开没开全靠打电话确认。设计数据表时至少要有一张 pump_command_log 表记录 command_id、device_id、cmd_typestart/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 页”意味着评审对象是决策层他们要看到的是问题、方法、投资和效果。推荐的页面分配如下页码区间内容板块页数每一页必须给出13现状问题与需求分析3 页一张内涝点位分布图 一张管网问题清单表47总体架构设计4 页架构分层图 一张数据流说明表812感知与网络方案5 页点位布设表 一张通讯组网拓扑1316平台与数据方案4 页功能清单表 数据表结构说明1720应用场景与调度规则4 页内涝预警流程 泵站联调规则表2123实施计划与概算3 页里程碑甘特表 分项概算表2425效益分析与风险对策2 页一张效益对比表 一张风险应对表每一页的负责人和技术要点都很明确。比如第 812 页的点位布设表里必须写清楚设备类型、量程、安装位置、供电方式——评审专家最反感那种只写了“安装液位计 200 套”却没有参数说明的配置表。5.2 每页标题写成一句结论而不是名词短语方案 PPT 和写代码一样命名要见文知义。“感知层建设方案”这种标题就没信息量改成“液位计 雨量计双网覆盖易涝点 500 米一个监测断面”就直观得多。25 页每页标题都是一句技术判断评审翻完目录就能复述出你的整体思路这一版方案就算立住了。技术细节的取舍上方案里至少要有一个可验证的关键指标比如“系统建成后易涝点监测覆盖率 100%内涝预警提前量不小于 30 分钟”。这类指标要写得可考核不要写“提升排水智能化水平”这种没法验收的词。概算页同理要按感知设备、网络通讯、平台软件、系统集成、运维费五类分项列示运维费按每年 8%12% 的初投资估算这是业主最关心也最容易漏算的一笔钱。5.3 汇报顺序的建议先讲数据闭环再讲功能清单到一个容易踩的坑是前 10 页都在讲后台功能菜单评审问“这些功能解决什么实际问题”时又翻回前面讲痛点。对 25 页这种紧凑体量建议把“数据怎么采 → 怎么传 → 怎么算 → 怎么用”这条链路讲完整功能只是链路每个环节上的落点。表达时多用“监测数据驱动”“预降预排”“工单闭环”这类明确动词少用“赋能”“助力”“智慧化升级”这类虚词。方案最后停在风险对策页上很合适——把“数据断传、设备被淹、通讯拥堵”三类风险摆到桌面上对应给出备用频段和本地存储策略这比任何“展望未来”都更能让评审信服。本文还有配套的精品资源点击获取