一、排水管网数据为什么必须"先处理再上传"？
排水管网监测点位分散于井下、河道、易涝区，数据上传面临三重现实约束：
| 约束条件 | 具体表现 | 直接后果 |
|---|---|---|
| 网络条件差 | 井下4G信号弱、金属井盖屏蔽 | 原始数据频繁丢包、延迟 |
| 流量成本高 | 液位等高频采集点数量多 | 常年4G费用累积可观 |
| 平台压力大 | 上千点位全量上报 | 服务器存储与算力被无效数据占满 |
核心矛盾 ：液位秒级波动中99%是无效平稳数据，而暴雨异常恰恰只发生在其中1%的时刻。若全量上传，成本高、响应慢；若简单降频，又会漏掉关键变化。本地预处理正是解决这一矛盾的折中方案：数据在网关侧完成清洗与判断，仅将"有价值的结论"上传。
二、本地预处理的完整流程包含哪些环节？
边缘计算网关在本地按"五步流水线"处理数据，每一步都有明确的过滤与加工目标：
① 采集标准化
通过RS485/Modbus接入液位计、流量计、井盖传感器，统一寄存器点表，按分场景频率采集：常态下液位1分钟/次，超阈值时自动加密至10秒/次。
② 数据清洗
剔除三类无效数据：
- 野值：如液位瞬间跳变5米（传感器受干扰），用滑动窗口中位数滤波剔除；
- 重复值：数据未变化时不重复上报；
- 无效值：传感器离线、断线返回的空值标记为设备异常而非水位数据。
③ 边缘判断
在本地执行两级研判：
- 阈值判断：液位超警戒线，立即生成本地报警事件；
- 变化率计算：液位上涨速率>设定值（如5cm/min），即使未达警戒线也判定为"快速上涨"异常。
④ 数据聚合
对平稳期数据做窗口聚合（如每5分钟计算均值、最大值），一条记录替代60条原始数据。
⑤ 分级上传
按数据重要性决定上传策略，与QoS机制联动。
三、预处理前后，数据量与价值差异有多大？
以一个液位监测点为例（常态采集频率1分钟/次）：
| 指标 | 无预处理（全量上传） | 边缘预处理后 |
|---|---|---|
| 日上传数据量 | 1440条 | 聚合288条+异常事件若干 |
| 流量成本 | 100% | 降至约20-30% |
| 异常响应 | 依赖平台轮询研判 | 本地秒级触发报警 |
| 断网期间 | 数据全丢 | 本地缓存，恢复后补传 |
| 平台负载 | 高（全量入库） | 低（仅结论与特征值） |
关键价值 ：预处理不是简单"少传数据"，而是把研判能力下沉到现场，平台收到的是"已判断过的报警"而非"待判断的原始流"，防汛响应从分钟级压缩至秒级。
四、断网期间数据如何保证不丢？
暴雨天气常伴随通信中断，预处理与存储机制形成三级韧性保障：
- 本地缓存：网关Flash存储≥7天数据，容量按"极端暴雨+最长断网"场景设计；
- 断点续传：网络恢复后按时间戳自动补传，配合MQTT持久会话（cleanSession=false），Broker侧同步补发缓存消息；
- 本地自治：断网期间阈值报警仍由网关本地触发，通过预留的无线通道（如LoRa直连就近节点）先行通知，避免"断网即失明"。
五、边缘规则如何配置与远程更新？
预处理规则不是固化的，需支持远程配置下发以适应汛期/非汛期差异：
- 阈值动态调整：汛期警戒线自动下调、采集频率自动加密；
- 规则热更新：平台通过MQTT下发配置指令（QoS 1保障必达），网关本地生效并回执确认；
- 版本管理：规则变更留痕，支持回滚，避免"改错规则无人知"。
配置原则 ：边缘规则做"快判断"（秒级阈值、变化率），平台模型做"慢研判"（多源耦合、趋势预测），两端分工而非重复建设。
六、选型部署时需关注哪些工程要素？
结合井下恶劣工况，四项要素直接决定预处理方案能否长期运行：
- 算力匹配：边缘算法（滤波、变化率计算）需在低功耗MCU上实时完成，选型时验证处理时延<采集周期；
- 防护等级：网关本体IP68+防腐灌封，适应潮湿、积水、腐蚀性气体环境；
- 供电续航：预处理本身消耗算力与电量，需验证"低功耗芯片+分级采集"模式下的实际续航年限；
- 协议兼容：同时支持Modbus、MQTT等多种协议，避免前端设备品牌锁定。
排水管网监测的价值，不在于采集了多少原始数据，而在于异常能否被第一时间发现并上报。边缘计算网关的本地预处理，本质上是把"数据搬运工"升级为"现场研判员"------清洗在井下完成、判断在井口触发、结论在平台呈现。当"边缘快判断+平台深研判"形成分工闭环，排水管网才真正实现从"事后查数据"到"事前防风险"的转变。