尧图网站建设 
简介这份PPT资源面向城市水务管理、市政信息化建设及智慧城市解决方案从业人员围绕城市智慧排水信息化管控平台的建设方案展开。内容涵盖平台建设目标与意义、核心技术选型、主要功能设计与实施路径等模块可帮助读者理解如何借助物联网、3SGIS、遥感、GPS及嵌入式技术构建覆盖城市排水系统的监测网络并据此形成排水设施在线监测、排水业务管理、排水数据分析、决策支持与公共服务的一体化解决思路。资源为1个pptx演示文档压缩包约10.93MB属于方案汇报型材料页面对应应用背景、设计思路、系统架构、系统功能与运行环境等章节便于直接用于方案讲解或二次改编。目前已有132人学习下载适合需要快速搭建智慧排水平台整体框架、明确功能边界与实施步骤的读者参考借鉴。1. 城市智慧排水信息化管控平台建设方案先解决看不见再谈管得住暴雨夜里调度中心大屏上只有几座泵站的启停状态马路上积水多深、哪个检查井正在冒溢还得靠巡查员打电话回来。城市智慧排水信息化管控平台建设方案要回答的其实就三个问题水现在在哪、接下来会不会淹、谁来动手处置。前两个靠感知和数据第三个靠流程和联动。这类方案通常先以 PPT 的形式在评审会上过一遍真正决定成败的不是页数而是四张清单上的数字监测点位表、通信协议表、数据模型表和预警阈值表。PPT 做得再漂亮点位选错、协议不通、阈值拍脑袋上线三个月后平台就只剩一块看板。需要这份方案的人很具体市政排水主管单位与水务集团的信息中心、承担总集成的工程商、做二次开发的软件团队以及汛期值守的调度班组。下面的架构、代码和参数做招标技术需求或者评估一份现成方案时都能直接对号入座。2. 智慧排水信息化管控平台的分层架构与关键选型架构图谁都会画难的是每一层选什么、为什么选它、后面能不能扩。我一般按感知—传输—数据—平台—应用五层来拆先把每层的输入输出定死再谈产品选型。这样做的直接好处是设备厂商换一家数据层不用改应用换个界面底层不用动。下面按层说明边界并给出协议、存储和部署上的具体判断依据。2.1 从液位计到一张图五层架构怎么切层级典型组件关键指标常见坑感知层雷达/压力液位计、多普勒流量计、翻斗雨量计、泵站 PLC液位精度 ±1cm采样 15 min井内潮湿结露超声波易失效传输层遥测终端 RTU、4G/NB-IoT 模组上报成功率 ≥99%掉线自动重连井下信号弱需外置天线数据层时序库、关系库、空间库、消息队列分钟级写入原始报文可回溯只存解析后数据出错查不到源平台层设备管理、规则引擎、工单、权限规则热更新不影响采集阈值写死在代码里应用层一张图、预警发布、调度指挥、报表端到端时延 ≤30 s大屏刷新慢值班员不信感知层最容易低估的是环境。检查井内湿度长期在 90% 以上还有硫化氢腐蚀选型时宁可多花一点预算上雷达式也别用超声波硬扛。传输层要区分设备在线和数据有效RTU 心跳正常但传感器卡死在同一个值这种情况只能靠数据层做平值检测才能发现。2.2 数据底座选型时序库、关系库、空间库的分工排水数据天然是三类高频数值液位、流量、雨量、业务台账设备、工单、预案、空间对象管线、检查井、汇水分区。硬塞进一个库里查询和维护都会难受。数据类型存储选择依据典型查询分钟级测点值TimescaleDB / InfluxDB按时间分区压缩比高聚合快某点近 24h 液位曲线设备与工单PostgreSQL / MySQL事务与外键完整某泵站本月维修记录管网空间数据PostGIS拓扑与缓冲区分析某易涝点上游 500m 内的井最新值与去重Redis内存读写带过期策略实时大屏取值、告警抑制我通常把时序库和关系库放在同一个 PostgreSQL 实例里用 TimescaleDB 扩展把测点值做成超表跨库关联直接在 SQL 里完成。空间分析交给 PostGIS管网拓扑和汇水分区算完的结果回写关系库前端只查结果不实时算。2.3 通信协议选型MQTT、Modbus、HJ212 的边界协议选错的代价是后期每接一家设备就写一套解析代码。我的划分原则是看链路井下的短距离和 PLC 用 Modbus广域上行用 MQTT对接上级监管平台用 HJ212视频单独走 GB/T 28181。协议用在哪优点注意点Modbus RTU/TCPRTU 与传感器、泵站 PLC设备支持广实现简单寄存器地址需现场核对字节序常搞错MQTTRTU 到平台上行长连接、QoS 可控、省流量别用 QoS 0 传告警数据HJ212与监管平台数据交换行业通用字段规范编码与校验位容易被改写错GB/T 28181易涝点视频平台级联方便码流带宽要提前算上表里最容易被忽略的是字节序和寄存器地址。同一批液位计不同批次固件的浮点字序可能不一样现场调试时先用 Modbus 调试工具读一遍原始寄存器对照说明书确认再写进平台的解析配置表不要直接猜。2.4 一套可落地的容器化部署清单平台早期不建议上 Kubernetes用 Docker Compose 足够一台 16 核 32G 的服务器能扛住几千个测点。下面这份清单是我常用的起点。# docker-compose.yml 智慧排水平台最小可运行栈 services: emqx: # MQTT 接入所有 RTU 上行到这里 image: emqx/emqx:5.6 ports: [1883:1883, 18083:18083] environment: - EMQX_LISTENERS__TCP__DEFAULT__MAX_CONNECTIONS20000 - EMQX_MQTT__SESSION__EXPIRY_INTERVAL2h # 会话保留弱网重连不丢订阅 timescaledb: # 时序数据水位/流量/雨量落库 image: timescale/timescaledb:latest-pg15 environment: POSTGRES_PASSWORD: drainage_2024 volumes: [./pgdata:/var/lib/postgresql/data] redis: # 最新值缓存 告警去重 image: redis:7-alpine command: [redis-server, --maxmemory, 2gb, --maxmemory-policy, allkeys-lru]参数说明MAX_CONNECTIONS按实际点位数的 1.5 倍留余量遥测终端在弱网下会反复重连连接数会短时冲高SESSION__EXPIRY_INTERVAL决定设备断网后订阅关系保留多久设成 2 小时能覆盖多数基站切换场景Redis 的allkeys-lru保证内存打满时淘汰旧的最新值而不是直接拒绝写入。./pgdata必须挂到独立数据盘时序数据增长比想象中快一个月几百个测点就能到几十 GB。3. 排水管网监测点位接入从遥测终端到智慧排水管控平台入库点位布得对不对直接决定预警有没有用。常见错误是雨量站和易涝点离得太远用全城平均雨量去判断某个下穿隧道的积水报出来永远是狼来了。这一章讲三件事点位布在哪、数据表怎么建、报文怎么可靠收上来。3.1 四类必布点位与布设密度场景监测内容建议密度采样间隔历史易涝点/下穿隧道液位 视频每点必布隧道取最低点1 min主干管关键节点液位 流量每 12 km 一个汇流点必设5 min泵站前池与出水液位、泵状态、电流每站必布1 min排口液位 流量 视频重点排口5 min雨量翻斗雨量计每 24 km² 一站1 min分辨率 0.2 mm布点还要看汇水分区。做方案时我会先把管网 GIS 按汇水区切块每块保证至少一个液位点加一个雨量点这样规则引擎里本地雨量才有意义而不是拿全市雨量去套。3.2 统一数据模型设备、测点、原始报文三张表-- 设备台账一个遥测终端可能带多个测点 CREATE TABLE t_device ( device_id VARCHAR(32) PRIMARY KEY, device_name VARCHAR(64) NOT NULL, site_type VARCHAR(16) NOT NULL, -- manhole/pump/outfall/rain lon NUMERIC(10,6), lat NUMERIC(10,6), online_timeout INT DEFAULT 900 -- 秒超过未上报判离线 ); -- 测点液位/流量/雨量/泵状态 CREATE TABLE t_point ( point_id BIGSERIAL PRIMARY KEY, device_id VARCHAR(32) REFERENCES t_device(device_id), metric VARCHAR(16) NOT NULL, -- level/flow/rain/pump_state unit VARCHAR(8), scale NUMERIC(8,3) DEFAULT 1, -- 原始值换算系数 offset_val NUMERIC(8,3) DEFAULT 0, -- 零点偏移 well_depth NUMERIC(6,2) -- 井深用于百分比告警 ); -- 原始报文先落库再解析出问题能回溯 CREATE TABLE t_raw_message ( id BIGSERIAL PRIMARY KEY, device_id VARCHAR(32), topic VARCHAR(128), payload TEXT, recv_time TIMESTAMPTZ DEFAULT now() ); CREATE INDEX idx_raw_device_time ON t_raw_message(device_id, recv_time DESC);scale和offset_val是现场标定的落点投入式液位计装在井底读数是相对压力换算的水深井口高程和零点偏移必须写进配置否则不同井的水位 1 米根本不可比。well_depth单独存一列是为了支持液位达到井深 60%这类相对阈值避免每加一个点位就改一次规则代码。t_raw_message建议只保留 30 天并做定期清理它的价值在于排查期——解析逻辑改版后可以直接用历史报文重放。3.3 MQTT 上行与断点续传的最小实现遥测终端上行走 MQTTQoS 至少 1。平台侧的网关进程要做三件事解析、换算、失败不丢。import json, sqlite3, paho.mqtt.client as mqtt # 本地缓冲表解析失败的报文先进这里人工排查后重放 BUF sqlite3.connect(buffer.db, check_same_threadFalse) BUF.execute(CREATE TABLE IF NOT EXISTS pending(id INTEGER PRIMARY KEY, topic TEXT, payload TEXT)) def on_message(client, userdata, msg): raw msg.payload.decode(utf-8, ignore) try: # 上行格式 {device_id:YL0231,value:1.86,ts:1730000000} data json.loads(raw) point MAPPING[data[device_id]] # 设备到测点启动时全量加载 value data[value] * point[scale] point[offset_val] tsdb.execute( INSERT INTO ts_metric(point_id, ts, value) VALUES(%s, %s, %s), (point[point_id], data[ts], value)) except Exception: BUF.execute(INSERT INTO pending(topic, payload) VALUES(?, ?), (msg.topic, raw)) BUF.commit() def flush_pending(): for pid, topic, payload in BUF.execute(SELECT id, topic, payload FROM pending LIMIT 500): if retry_parse(payload): # 重放成功才删除 BUF.execute(DELETE FROM pending WHERE id?, (pid,)) BUF.commit() client mqtt.Client(client_iddrain-gw-01, clean_sessionFalse) client.on_message on_message client.connect(emqx, 1883, 60) client.subscribe(drain//up, qos1) # 通配符订阅所有设备上行 client.loop_forever()逻辑说明clean_sessionFalse让 broker 保留会话网关重启后订阅关系还在不用等设备重新注册qos1保证至少送达一次重复报文靠point_id ts建唯一索引做幂等解析异常进缓冲区而不是直接丢弃因为现场最常见的失败原因是格式改版和字段缺失原始报文留着就能批量补。参数上flush_pending每 30 秒跑一次单批 500 条避免长时间占用数据库连接。3.4 接入联调的三步校验第一步用mosquitto_pub打一条模拟报文确认平台入库重点核对时间戳是设备时间还是网关时间两者混用会导致曲线错位。第二步做点位映射核对把设备编号、测点、井深、安装高程做成一张对照表让现场人员签字确认这套表后面验收要用。第三步做弱网测试拔掉天线两小时再恢复检查补传数据是否连续、有没有出现时间乱序。三步都过才算这个点位真正接入。4. 内涝预警与泵站联动智慧排水管控平台的规则引擎实现阈值拍脑袋是这类平台最普遍的问题定高了汛期不报定低了天天误报值班员三天就把告警静音。合理的做法是把规则做成配置加滑动窗口并用历史降雨回放验证。4.1 预警分级阈值怎么定等级触发条件示例联动动作解除条件蓝色单点液位 ≥ 井深 60%持续 10 min短信通知值守低于 50% 持续 15 min黄色易涝点液位 ≥ 15 cm 且 1h 雨量 ≥ 30 mm泵站预降水位液位 10 cm橙色液位 ≥ 25 cm 或涨幅 ≥ 3 cm/5min启动泵组、推送交管提示液位连续 20 min 下降红色液位 ≥ 40 cm 且 1h 雨量 ≥ 50 mm全泵运行、封路联动、上报人工确认表里的数值只是起点真正要现场标定的是井深百分比和涨幅。同样 15 cm在一条 3 米深的干管里什么都不是在只有 50 cm 深的雨水口就是严重积水。4.2 规则表达式用滑动窗口替代单点阈值单点阈值最怕的就是瞬时抖动和车速带起的水花干扰。加一个短窗口的涨幅判断能提前 5 到 10 分钟发现问题。from collections import deque from datetime import datetime, timedelta WINDOW timedelta(minutes5) def level_rise_rate(history, now): history: deque[(ts, value)]返回 mm/min 涨幅 recent [v for t, v in history if now - t WINDOW] if len(recent) 2: return 0.0 return (recent[-1] - recent[0]) / (WINDOW.total_seconds() / 60) * 1000 def eval_rule(point, history, now, rain_1h): level_cm history[-1][1] * 100 # 统一换算到厘米 rise level_rise_rate(history, now) if level_cm 40 and rain_1h 50: return RED, all_pump_on if level_cm 25 or rise 30: # 30 mm/min ≈ 3 cm/5min return ORANGE, start_pump_group if level_cm 15 and rain_1h 30: return YELLOW, pre_drain if level_cm 0.6 * point[well_depth] * 100: return BLUE, notify return None, None逻辑说明rain_1h由就近雨量站的分钟值滚动累加得到必须是本汇水区的雨量不能取全城平均。rise的单位统一成 mm/min是为了让不同口径的井用同一套阈值。规则函数的返回值是等级加动作标识与具体下发协议解耦后面换成 HTTP 或 OPC UA 下发都不用改判断逻辑。4.3 泵站联动指令下发与防抖泵组最怕频繁启停一台 55 kW 的泵五分钟内来回启动三次电机保护很快就会动作。所以下发前必须过一道防抖闸门。import time class LinkageGuard: def __init__(self, min_interval300): # 同一目标同一动作5 分钟内不重复下发 self.last {} self.min_interval min_interval def allow(self, target, action): key (target, action) now time.time() if now - self.last.get(key, 0) self.min_interval: return False self.last[key] now return True下发之后要看回执指令写入t_command表并记录sent_timePLC 返回确认才置为成功超时 20 秒重发一次最多重发两次仍失败就转人工电话。参数说明min_interval按泵组容量设小泵 180 秒大泵 300 秒以上重发上限不能设太大否则在网络抖动时会把同一条启动指令刷进 PLC 队列。4.4 误报排查四个日志字段定位问题字段含义排查价值rule_id命中的规则版本确认是否改过阈值window_values窗口内原始值序列看是真实上涨还是单点跳变raw_value未经换算的报文值判断标定参数是否配错action_ack联动回执状态区分报了没动和动了没报多数误报出在标定参数上scale配错一位小数液位就会整体偏移十倍。把raw_value与window_values一起打出来五分钟就能判断是数据问题还是规则问题。5. 城市智慧排水信息化管控平台的验收指标、费用测算与汛期调参技巧上线只是开始能不能通过验收、钱怎么算、汛期怎么调是方案落地的最后一公里。5.1 验收看板上的五个硬指标指标建议门槛统计方式设备在线率≥ 95%月在线时长 / 应在线时长分钟数据完整率≥ 98%实收条数 / 应收条数预警准确率≥ 90%人工确认有效告警 / 总告警指令成功率≥ 99%回执成功数 / 下发数端到端时延≤ 30 s设备上报到界面刷新这五个指标里最容易被糊弄的是预警准确率统计口径要写清人工确认由谁做、什么算有效。我一般要求在汛期结束后组织一次回溯评审把每条红色告警和现场积水记录对上。5.2 信息化项目费用测算人月法与设备清单法费用部分通常分四块感知设备与安装、软件开发、系统集成、运维。不少省份如四川省已发布信息化项目费用测算标准其中软件开发费的思路是按功能点或人月工作量乘以人月单价硬件按清单计价运维按年费率计提。费用项计价方式常见比例容易遗漏感知设备与安装设备清单 × 单价 安装费占总投资 40%55%井盖开孔、恢复、占道审批软件开发人月工作量 × 人月单价25%35%数据治理与接口开发常被漏算系统集成按设备与软件费比例8%12%第三方平台对接工作量运维按年计提每年 8%12%流量卡与云资源费写方案时把人月工作量拆到模块级比写一个总数更容易过评审采集接入、数据治理、规则引擎、一张图、移动端、对接上级平台各给一个人月区间并注明依据。5.3 汛期前用历史降雨回放做规则回测阈值改完不能直接等下一场雨来验证。把上一年的降雨和液位数据回放一遍是最省成本的调参手段。# 用历史数据回放统计各等级命中次数与疑似误报 def replay(rows, rule_fn): hit {RED: 0, ORANGE: 0, YELLOW: 0, BLUE: 0} false_alarm 0 for row in rows: level, action rule_fn(row[point], row[history], row[ts], row[rain_1h]) if level: hit[level] 1 # 回放中若 30 分钟内液位回落且无人工确认的积水上报记为疑似误报 if row[fell_back] and not row[confirmed]: false_alarm 1 return hit, false_alarm调参时一次只动一个阈值先把橙色从 25 cm 降到 23 cm 跑一遍看命中增加多少、误报增加多少再把涨幅阈值从 30 mm/min 调到 25 mm/min 跑一遍对比两次结果。回测结果写回rule_backtest表按场次降雨而不是按月份统计这样同一场雨前后不同阈值的效果可以直接对比汛期值守时拿真实降雨去核对预测阈值调整才有据可依。本文还有配套的精品资源点击获取 城市智慧排水信息化管控平台建设：从感知接入到内涝预警联动
简介这份PPT资源面向城市水务管理、市政信息化建设及智慧城市解决方案从业人员围绕城市智慧排水信息化管控平台的建设方案展开。内容涵盖平台建设目标与意义、核心技术选型、主要功能设计与实施路径等模块可帮助读者理解如何借助物联网、3SGIS、遥感、GPS及嵌入式技术构建覆盖城市排水系统的监测网络并据此形成排水设施在线监测、排水业务管理、排水数据分析、决策支持与公共服务的一体化解决思路。资源为1个pptx演示文档压缩包约10.93MB属于方案汇报型材料页面对应应用背景、设计思路、系统架构、系统功能与运行环境等章节便于直接用于方案讲解或二次改编。目前已有132人学习下载适合需要快速搭建智慧排水平台整体框架、明确功能边界与实施步骤的读者参考借鉴。1. 城市智慧排水信息化管控平台建设方案先解决看不见再谈管得住暴雨夜里调度中心大屏上只有几座泵站的启停状态马路上积水多深、哪个检查井正在冒溢还得靠巡查员打电话回来。城市智慧排水信息化管控平台建设方案要回答的其实就三个问题水现在在哪、接下来会不会淹、谁来动手处置。前两个靠感知和数据第三个靠流程和联动。这类方案通常先以 PPT 的形式在评审会上过一遍真正决定成败的不是页数而是四张清单上的数字监测点位表、通信协议表、数据模型表和预警阈值表。PPT 做得再漂亮点位选错、协议不通、阈值拍脑袋上线三个月后平台就只剩一块看板。需要这份方案的人很具体市政排水主管单位与水务集团的信息中心、承担总集成的工程商、做二次开发的软件团队以及汛期值守的调度班组。下面的架构、代码和参数做招标技术需求或者评估一份现成方案时都能直接对号入座。2. 智慧排水信息化管控平台的分层架构与关键选型架构图谁都会画难的是每一层选什么、为什么选它、后面能不能扩。我一般按感知—传输—数据—平台—应用五层来拆先把每层的输入输出定死再谈产品选型。这样做的直接好处是设备厂商换一家数据层不用改应用换个界面底层不用动。下面按层说明边界并给出协议、存储和部署上的具体判断依据。2.1 从液位计到一张图五层架构怎么切层级典型组件关键指标常见坑感知层雷达/压力液位计、多普勒流量计、翻斗雨量计、泵站 PLC液位精度 ±1cm采样 15 min井内潮湿结露超声波易失效传输层遥测终端 RTU、4G/NB-IoT 模组上报成功率 ≥99%掉线自动重连井下信号弱需外置天线数据层时序库、关系库、空间库、消息队列分钟级写入原始报文可回溯只存解析后数据出错查不到源平台层设备管理、规则引擎、工单、权限规则热更新不影响采集阈值写死在代码里应用层一张图、预警发布、调度指挥、报表端到端时延 ≤30 s大屏刷新慢值班员不信感知层最容易低估的是环境。检查井内湿度长期在 90% 以上还有硫化氢腐蚀选型时宁可多花一点预算上雷达式也别用超声波硬扛。传输层要区分设备在线和数据有效RTU 心跳正常但传感器卡死在同一个值这种情况只能靠数据层做平值检测才能发现。2.2 数据底座选型时序库、关系库、空间库的分工排水数据天然是三类高频数值液位、流量、雨量、业务台账设备、工单、预案、空间对象管线、检查井、汇水分区。硬塞进一个库里查询和维护都会难受。数据类型存储选择依据典型查询分钟级测点值TimescaleDB / InfluxDB按时间分区压缩比高聚合快某点近 24h 液位曲线设备与工单PostgreSQL / MySQL事务与外键完整某泵站本月维修记录管网空间数据PostGIS拓扑与缓冲区分析某易涝点上游 500m 内的井最新值与去重Redis内存读写带过期策略实时大屏取值、告警抑制我通常把时序库和关系库放在同一个 PostgreSQL 实例里用 TimescaleDB 扩展把测点值做成超表跨库关联直接在 SQL 里完成。空间分析交给 PostGIS管网拓扑和汇水分区算完的结果回写关系库前端只查结果不实时算。2.3 通信协议选型MQTT、Modbus、HJ212 的边界协议选错的代价是后期每接一家设备就写一套解析代码。我的划分原则是看链路井下的短距离和 PLC 用 Modbus广域上行用 MQTT对接上级监管平台用 HJ212视频单独走 GB/T 28181。协议用在哪优点注意点Modbus RTU/TCPRTU 与传感器、泵站 PLC设备支持广实现简单寄存器地址需现场核对字节序常搞错MQTTRTU 到平台上行长连接、QoS 可控、省流量别用 QoS 0 传告警数据HJ212与监管平台数据交换行业通用字段规范编码与校验位容易被改写错GB/T 28181易涝点视频平台级联方便码流带宽要提前算上表里最容易被忽略的是字节序和寄存器地址。同一批液位计不同批次固件的浮点字序可能不一样现场调试时先用 Modbus 调试工具读一遍原始寄存器对照说明书确认再写进平台的解析配置表不要直接猜。2.4 一套可落地的容器化部署清单平台早期不建议上 Kubernetes用 Docker Compose 足够一台 16 核 32G 的服务器能扛住几千个测点。下面这份清单是我常用的起点。# docker-compose.yml 智慧排水平台最小可运行栈 services: emqx: # MQTT 接入所有 RTU 上行到这里 image: emqx/emqx:5.6 ports: [1883:1883, 18083:18083] environment: - EMQX_LISTENERS__TCP__DEFAULT__MAX_CONNECTIONS20000 - EMQX_MQTT__SESSION__EXPIRY_INTERVAL2h # 会话保留弱网重连不丢订阅 timescaledb: # 时序数据水位/流量/雨量落库 image: timescale/timescaledb:latest-pg15 environment: POSTGRES_PASSWORD: drainage_2024 volumes: [./pgdata:/var/lib/postgresql/data] redis: # 最新值缓存 告警去重 image: redis:7-alpine command: [redis-server, --maxmemory, 2gb, --maxmemory-policy, allkeys-lru]参数说明MAX_CONNECTIONS按实际点位数的 1.5 倍留余量遥测终端在弱网下会反复重连连接数会短时冲高SESSION__EXPIRY_INTERVAL决定设备断网后订阅关系保留多久设成 2 小时能覆盖多数基站切换场景Redis 的allkeys-lru保证内存打满时淘汰旧的最新值而不是直接拒绝写入。./pgdata必须挂到独立数据盘时序数据增长比想象中快一个月几百个测点就能到几十 GB。3. 排水管网监测点位接入从遥测终端到智慧排水管控平台入库点位布得对不对直接决定预警有没有用。常见错误是雨量站和易涝点离得太远用全城平均雨量去判断某个下穿隧道的积水报出来永远是狼来了。这一章讲三件事点位布在哪、数据表怎么建、报文怎么可靠收上来。3.1 四类必布点位与布设密度场景监测内容建议密度采样间隔历史易涝点/下穿隧道液位 视频每点必布隧道取最低点1 min主干管关键节点液位 流量每 12 km 一个汇流点必设5 min泵站前池与出水液位、泵状态、电流每站必布1 min排口液位 流量 视频重点排口5 min雨量翻斗雨量计每 24 km² 一站1 min分辨率 0.2 mm布点还要看汇水分区。做方案时我会先把管网 GIS 按汇水区切块每块保证至少一个液位点加一个雨量点这样规则引擎里本地雨量才有意义而不是拿全市雨量去套。3.2 统一数据模型设备、测点、原始报文三张表-- 设备台账一个遥测终端可能带多个测点 CREATE TABLE t_device ( device_id VARCHAR(32) PRIMARY KEY, device_name VARCHAR(64) NOT NULL, site_type VARCHAR(16) NOT NULL, -- manhole/pump/outfall/rain lon NUMERIC(10,6), lat NUMERIC(10,6), online_timeout INT DEFAULT 900 -- 秒超过未上报判离线 ); -- 测点液位/流量/雨量/泵状态 CREATE TABLE t_point ( point_id BIGSERIAL PRIMARY KEY, device_id VARCHAR(32) REFERENCES t_device(device_id), metric VARCHAR(16) NOT NULL, -- level/flow/rain/pump_state unit VARCHAR(8), scale NUMERIC(8,3) DEFAULT 1, -- 原始值换算系数 offset_val NUMERIC(8,3) DEFAULT 0, -- 零点偏移 well_depth NUMERIC(6,2) -- 井深用于百分比告警 ); -- 原始报文先落库再解析出问题能回溯 CREATE TABLE t_raw_message ( id BIGSERIAL PRIMARY KEY, device_id VARCHAR(32), topic VARCHAR(128), payload TEXT, recv_time TIMESTAMPTZ DEFAULT now() ); CREATE INDEX idx_raw_device_time ON t_raw_message(device_id, recv_time DESC);scale和offset_val是现场标定的落点投入式液位计装在井底读数是相对压力换算的水深井口高程和零点偏移必须写进配置否则不同井的水位 1 米根本不可比。well_depth单独存一列是为了支持液位达到井深 60%这类相对阈值避免每加一个点位就改一次规则代码。t_raw_message建议只保留 30 天并做定期清理它的价值在于排查期——解析逻辑改版后可以直接用历史报文重放。3.3 MQTT 上行与断点续传的最小实现遥测终端上行走 MQTTQoS 至少 1。平台侧的网关进程要做三件事解析、换算、失败不丢。import json, sqlite3, paho.mqtt.client as mqtt # 本地缓冲表解析失败的报文先进这里人工排查后重放 BUF sqlite3.connect(buffer.db, check_same_threadFalse) BUF.execute(CREATE TABLE IF NOT EXISTS pending(id INTEGER PRIMARY KEY, topic TEXT, payload TEXT)) def on_message(client, userdata, msg): raw msg.payload.decode(utf-8, ignore) try: # 上行格式 {device_id:YL0231,value:1.86,ts:1730000000} data json.loads(raw) point MAPPING[data[device_id]] # 设备到测点启动时全量加载 value data[value] * point[scale] point[offset_val] tsdb.execute( INSERT INTO ts_metric(point_id, ts, value) VALUES(%s, %s, %s), (point[point_id], data[ts], value)) except Exception: BUF.execute(INSERT INTO pending(topic, payload) VALUES(?, ?), (msg.topic, raw)) BUF.commit() def flush_pending(): for pid, topic, payload in BUF.execute(SELECT id, topic, payload FROM pending LIMIT 500): if retry_parse(payload): # 重放成功才删除 BUF.execute(DELETE FROM pending WHERE id?, (pid,)) BUF.commit() client mqtt.Client(client_iddrain-gw-01, clean_sessionFalse) client.on_message on_message client.connect(emqx, 1883, 60) client.subscribe(drain//up, qos1) # 通配符订阅所有设备上行 client.loop_forever()逻辑说明clean_sessionFalse让 broker 保留会话网关重启后订阅关系还在不用等设备重新注册qos1保证至少送达一次重复报文靠point_id ts建唯一索引做幂等解析异常进缓冲区而不是直接丢弃因为现场最常见的失败原因是格式改版和字段缺失原始报文留着就能批量补。参数上flush_pending每 30 秒跑一次单批 500 条避免长时间占用数据库连接。3.4 接入联调的三步校验第一步用mosquitto_pub打一条模拟报文确认平台入库重点核对时间戳是设备时间还是网关时间两者混用会导致曲线错位。第二步做点位映射核对把设备编号、测点、井深、安装高程做成一张对照表让现场人员签字确认这套表后面验收要用。第三步做弱网测试拔掉天线两小时再恢复检查补传数据是否连续、有没有出现时间乱序。三步都过才算这个点位真正接入。4. 内涝预警与泵站联动智慧排水管控平台的规则引擎实现阈值拍脑袋是这类平台最普遍的问题定高了汛期不报定低了天天误报值班员三天就把告警静音。合理的做法是把规则做成配置加滑动窗口并用历史降雨回放验证。4.1 预警分级阈值怎么定等级触发条件示例联动动作解除条件蓝色单点液位 ≥ 井深 60%持续 10 min短信通知值守低于 50% 持续 15 min黄色易涝点液位 ≥ 15 cm 且 1h 雨量 ≥ 30 mm泵站预降水位液位 10 cm橙色液位 ≥ 25 cm 或涨幅 ≥ 3 cm/5min启动泵组、推送交管提示液位连续 20 min 下降红色液位 ≥ 40 cm 且 1h 雨量 ≥ 50 mm全泵运行、封路联动、上报人工确认表里的数值只是起点真正要现场标定的是井深百分比和涨幅。同样 15 cm在一条 3 米深的干管里什么都不是在只有 50 cm 深的雨水口就是严重积水。4.2 规则表达式用滑动窗口替代单点阈值单点阈值最怕的就是瞬时抖动和车速带起的水花干扰。加一个短窗口的涨幅判断能提前 5 到 10 分钟发现问题。from collections import deque from datetime import datetime, timedelta WINDOW timedelta(minutes5) def level_rise_rate(history, now): history: deque[(ts, value)]返回 mm/min 涨幅 recent [v for t, v in history if now - t WINDOW] if len(recent) 2: return 0.0 return (recent[-1] - recent[0]) / (WINDOW.total_seconds() / 60) * 1000 def eval_rule(point, history, now, rain_1h): level_cm history[-1][1] * 100 # 统一换算到厘米 rise level_rise_rate(history, now) if level_cm 40 and rain_1h 50: return RED, all_pump_on if level_cm 25 or rise 30: # 30 mm/min ≈ 3 cm/5min return ORANGE, start_pump_group if level_cm 15 and rain_1h 30: return YELLOW, pre_drain if level_cm 0.6 * point[well_depth] * 100: return BLUE, notify return None, None逻辑说明rain_1h由就近雨量站的分钟值滚动累加得到必须是本汇水区的雨量不能取全城平均。rise的单位统一成 mm/min是为了让不同口径的井用同一套阈值。规则函数的返回值是等级加动作标识与具体下发协议解耦后面换成 HTTP 或 OPC UA 下发都不用改判断逻辑。4.3 泵站联动指令下发与防抖泵组最怕频繁启停一台 55 kW 的泵五分钟内来回启动三次电机保护很快就会动作。所以下发前必须过一道防抖闸门。import time class LinkageGuard: def __init__(self, min_interval300): # 同一目标同一动作5 分钟内不重复下发 self.last {} self.min_interval min_interval def allow(self, target, action): key (target, action) now time.time() if now - self.last.get(key, 0) self.min_interval: return False self.last[key] now return True下发之后要看回执指令写入t_command表并记录sent_timePLC 返回确认才置为成功超时 20 秒重发一次最多重发两次仍失败就转人工电话。参数说明min_interval按泵组容量设小泵 180 秒大泵 300 秒以上重发上限不能设太大否则在网络抖动时会把同一条启动指令刷进 PLC 队列。4.4 误报排查四个日志字段定位问题字段含义排查价值rule_id命中的规则版本确认是否改过阈值window_values窗口内原始值序列看是真实上涨还是单点跳变raw_value未经换算的报文值判断标定参数是否配错action_ack联动回执状态区分报了没动和动了没报多数误报出在标定参数上scale配错一位小数液位就会整体偏移十倍。把raw_value与window_values一起打出来五分钟就能判断是数据问题还是规则问题。5. 城市智慧排水信息化管控平台的验收指标、费用测算与汛期调参技巧上线只是开始能不能通过验收、钱怎么算、汛期怎么调是方案落地的最后一公里。5.1 验收看板上的五个硬指标指标建议门槛统计方式设备在线率≥ 95%月在线时长 / 应在线时长分钟数据完整率≥ 98%实收条数 / 应收条数预警准确率≥ 90%人工确认有效告警 / 总告警指令成功率≥ 99%回执成功数 / 下发数端到端时延≤ 30 s设备上报到界面刷新这五个指标里最容易被糊弄的是预警准确率统计口径要写清人工确认由谁做、什么算有效。我一般要求在汛期结束后组织一次回溯评审把每条红色告警和现场积水记录对上。5.2 信息化项目费用测算人月法与设备清单法费用部分通常分四块感知设备与安装、软件开发、系统集成、运维。不少省份如四川省已发布信息化项目费用测算标准其中软件开发费的思路是按功能点或人月工作量乘以人月单价硬件按清单计价运维按年费率计提。费用项计价方式常见比例容易遗漏感知设备与安装设备清单 × 单价 安装费占总投资 40%55%井盖开孔、恢复、占道审批软件开发人月工作量 × 人月单价25%35%数据治理与接口开发常被漏算系统集成按设备与软件费比例8%12%第三方平台对接工作量运维按年计提每年 8%12%流量卡与云资源费写方案时把人月工作量拆到模块级比写一个总数更容易过评审采集接入、数据治理、规则引擎、一张图、移动端、对接上级平台各给一个人月区间并注明依据。5.3 汛期前用历史降雨回放做规则回测阈值改完不能直接等下一场雨来验证。把上一年的降雨和液位数据回放一遍是最省成本的调参手段。# 用历史数据回放统计各等级命中次数与疑似误报 def replay(rows, rule_fn): hit {RED: 0, ORANGE: 0, YELLOW: 0, BLUE: 0} false_alarm 0 for row in rows: level, action rule_fn(row[point], row[history], row[ts], row[rain_1h]) if level: hit[level] 1 # 回放中若 30 分钟内液位回落且无人工确认的积水上报记为疑似误报 if row[fell_back] and not row[confirmed]: false_alarm 1 return hit, false_alarm调参时一次只动一个阈值先把橙色从 25 cm 降到 23 cm 跑一遍看命中增加多少、误报增加多少再把涨幅阈值从 30 mm/min 调到 25 mm/min 跑一遍对比两次结果。回测结果写回rule_backtest表按场次降雨而不是按月份统计这样同一场雨前后不同阈值的效果可以直接对比汛期值守时拿真实降雨去核对预测阈值调整才有据可依。本文还有配套的精品资源点击获取