1. 项目整体设计与需求拆解前阵子我复盘手头一个编号叫“ax”的项目也就是一套区域供水管网的智能调度系统。当初接到这个活儿对方就给了两个关键词ax调度。说白了就是要把一个水司辖区里分散的泵站、水厂、管网压力监测点串起来用一套算法代替老师傅“看压力调泵”的经验实现按需供水、按时段调压。这事的价值挺直接降电耗、降漏损、减少爆管风险。1.1 核心问题拆解ax调度到底调什么供水调度不是简单地“水不够就加压”它本质上是在管三个互相打架的指标服务压力、运行能耗、管网漏损。压力太低远端用户高峰期可能接不到水压力太高管网承受的压力大漏损率和爆管风险直线上升。传统的做法是恒压供水泵站按一个固定的出口压力跑不管城市里现在是凌晨三点还是晚上八点压力都保持同一水平。这样做的最大问题是“高不成低不就”——高峰期压力不够低峰期压力又富余太多。ax调度的核心就是把这个静态目标改成动态目标根据天气预报、历史用水规律、重大活动安排提前算出未来24小时每个时段城市大概需要多少水然后反过来推算出最合适的泵站出口压力曲线和泵组组合方案。控制逻辑不再是“压力低了就加泵”而是“预测到两小时后用水量上升提前把压力和泵组调整到位”。我当时画了一张逻辑图给客户看底层是SCADA采集的实时数据中间层是用水预测模型最上层是优化决策模块输出直接给到泵站的PLC执行。整个链路里预测是大脑优化是决策SCADA是手脚。1.2 技术路线选型为什么是“预测滚动优化”这个项目当初不是没有别的方案可选。市场上现成的供水调度产品不少但大多是厂家的“黑盒策略”你只能设定压力值内部怎么调泵、怎么轮换完全看不到出了问题厂家远程看一眼也说不清楚。我们也评估过纯靠老师傅经验做规则引擎把“高峰加两台泵、夜间停一台”写死成逻辑但供水系统的时变性和地域性太强规则稍微复杂一点就互相冲突根本维护不住。最终定下来的路线是**“数据驱动预测 滚动优化反馈”**。与其试图用规则覆盖所有工况不如让模型从历史数据里学规律再让优化算法在每15分钟重新算一次最优解。这个架构最大的好处是预测错了能靠滚动修正兜底系统暂时跑飞了也有SCADA的硬保护兜底。比纯粹的黑盒机器学习方案更稳比纯规则方案更灵活属于工业现场能接受、能验收的折中路线。2. 数据底座与特征工程模型跑得准不准七成看这里很多团队做这类项目上来就调模型其实大错特错。供水调度建模特征工程和数据质量远比算法本身重要。我甚至跟客户说过一句话数据清洗的时间至少要占整个项目周期的四成否则后面全是补窟窿。2.1 数据采集层PLC点表和时序库的搭建ax项目的现场数据来自各个泵站和水厂的中控系统标准做法是通过OPC-UA协议从PLC采集实时数据。需要采集的关键点位有这么几类泵站进出口压力、瞬时流量、泵转速、运行状态、电流、功率清水池液位、进水流量管网关键节点的压力监测值特别是最不利控制点离泵站最远、地势最高、历史压力最低的点气象数据温度、降雨量从第三方气象接口获取。采集周期我们定的是5秒一次原始数据入库但在建模时聚合到5分钟粒度。时序库选型用的TDengine读写性能好压缩率高一套下来十几个站点每天数据量也就几个GB完全扛得住。PLC点位表梳理是最容易踩坑的环节现场不少老设备的测点命名混乱有的压力和液位信号接反了有的仪表量程设置错误这类问题在数据采集阶段不解决后面模型训练时全是脏特征。2.2 特征清洗的四个坑这里分享几个现场实际遇到的坑全是常规文档里不会写的细节。第一个坑是零漂。压力变送器用久了零点会漂夜间流量为零时压力读数却不是零通常会比真实值高一点或低一点。处理办法是定期做仪表校零同时在特征工程里对压力做基线修正——取过去7天同一时刻的中位数做对照超过3倍标准差的读数直接剔除。第二个坑是跳变值。泵切换瞬间压力会出现瞬间的尖峰或掉零这是物理过程正常现象但喂给模型会导致预测异常。我采用的方法是对压力做滑动窗口滤波窗口宽度取5个采样点超过窗口内中位数2个标准差的点视为瞬态值用线性插值替换。第三个坑是停泵数据段。供水调度有一个特性夜间用水少时泵组会低频运行甚至短时停机保压。这些停机段的数据如果直接拿去训练模型会学到“压力一直掉也没关系”的错误模式。我们把调度指令中的“停机”状态做成一个独立标签特征训练时对停泵段做专门的加权处理不直接屏蔽因为停泵本身是调度策略的一部分包含了老师傅的操作经验。第四个坑是节假日与天气特征。供水量的周期性很强工作日早晚两个高峰周末高峰后移且更平缓节假日则完全变化。天气的影响更直接——大热天用水量明显上升连续降雨后用水量会短暂下降。所以特征列表里必须包含星期几、是否节假日、最高气温、最低气温、24小时累计降雨量、前一天的同期用水量。这些特征看起来简单但直接决定了模型能不能在节假日正确预测出尖峰。3. 用水量预测模型核心算法与参数确定ax调度的第一个核心是用水量预测。预测对象不是总用水量而是泵站出口未来24小时逐15分钟的流量曲线。这条曲线是后续一切优化决策的依据。3.1 为什么选XGBoost而不是LSTM算法选型上我们做过真实的横向对比。当时一起测试了LSTM、XGBoost和Prophet三个候选LSTM在数据量足够大、序列足够长时理论上最准但它有两个问题一是训练和调参成本高二是可解释性差客户现场工程师根本不敢完全信任模型的输出出了异常也没法追溯Prophet在处理节假日效应上确实方便但我们对它的多变量支持不满意尤其是把泵站运行状态、温度等额外变量纳入模型时比较别扭XGBoost在结构化表格数据上表现稳定支持特征灵活组合训练速度快且能输出特征重要性便于向客户解释模型的依据。最终选XGBoost还有一个现实考虑单站点一年的数据量其实不大按15分钟粒度算下来也就3.5万个点LSTM在这种中等数据规模下的优势发挥不出来反而是树模型更能稳定收敛。这不是说深度模型不好而是在工业场景里稳定和可解释远比模型的纸面精度重要。3.2 关键参数选择过程模型采用多步预测策略用过去7天、每天96个点15分钟间隔的历史数据作为输入特征预测未来24小时96个点的用水量。实现方式不是一次输出96维而是滚动预测——先预测未来第一个15分钟然后把它拼入历史窗口再预测下一个15分钟。这个方案的好处是预测结果不会出现不合理的跳变。关键参数是经过多轮实验敲定的max_depth树深度 6太浅欠拟合压不住夜间低流量平滑段太深过拟合节假日这种异常点的干扰会被放大learning_rate 0.05配合n_estimators300在训练时间和精度之间取平衡。0.1的初始版本训练速度快但验证集误差明显偏大min_child_weight 5这个参数当时调了很久。设得太小模型会过度关注个别极端用水日比如水管爆裂后的大流量段设成5之后模型更关注普遍规律训练集/验证集划分方式用的是按时间切分而不是随机切分——前9个月训练后3个月验证。这个细节很重要因为用水量时序数据相邻时间段高度相关随机切分会严重高估模型表现。验证集上的指标最终落在RMSE约12立方米/小时MAPE约8%。单看MAPE不算惊艳但供水预测里夜间小流量时段占比大绝对误差其实控制得很理想。模型产出的预测曲线会作为优化的输入完全够用。4. 调度策略与泵组优化核心调度逻辑的实现预测做完真正的硬骨头在调度策略。预测曲线告诉系统“未来需要多少水”泵组优化要回答的问题是“怎么用最少的电把这些水送出去同时保证最不利点压力达标”。4.1 两级调度框架日前计划与实时修正ax调度采用的是两级框架这个在工业界比较常用也比较稳妥。日前计划每天凌晨4点运行一次以上一天24小时的历史数据为基准加上未来24小时的天气预报生成当天的压力控制曲线和泵组开停机计划表。输出给调度员审核确认。实时修正执行层面每15分钟滚动一次采集最近15分钟的实际流量和压力对比日前计划做偏差修正。如果实际用水和预测偏差超过阈值我们设的是5%就局部调整泵组组合而不是推翻整个计划重新算。两级框架的好处是既保留了预测的提前量又吸收了实时波动的随机性。现场执行的时候最怕的就是让算法频繁干预执行层。泵和阀门的动作是有物理寿命的一天启停几十次机械上扛不住老师傅看到也会觉得系统在乱来。所以实时修正层我们加了一个死区只有当压力偏差连续超过0.02MPa并持续10分钟才触发调整单次的偶发波动直接忽略。4.2 泵组组合优化目标函数与约束条件泵组优化的目标函数是电耗最小同时要满足一系列约束minimize P_total Σ(P_i × S_i × η_i) 约束条件 1. 最不利控制点压力 ≥ 服务压力下限通常0.28MPa 2. 泵站出口压力 ≤ 管网承压上限通常0.60MPa 3. 清水池液位保持在允许范围内 4. 每台泵的累计运行时间相对平均避免个别泵过度磨损 5. 同一时间最多运行N台泵其中P_i是第i台泵的额定功率S_i是转速比变频泵的可调量η_i是泵的效率。这个目标函数看起来简单但工程里有几个麻烦第一泵的效率不是固定值。它跟流量、转速都有关系实际效率曲线要现场实测。我们做了个简化处理用泵厂家提供的特性曲线结合现场功率和流量的实测数据回归出一个二维效率表。这个表做出来以后优化计算的精度明显上了一个台阶。第二多泵并联时效率不是简单相加。两台同型号泵并联运行时各自的工作点会移动效率需要按并联曲线重新算。所以泵组优化本质上是离散变量开哪几台泵连续变量变频泵的转速混合的优化问题。第三泵的工况点必须避开“驼峰区”。离心泵的流量—扬程曲线存在效率急降区间如果调度指令让泵运行在驼峰区附近电耗上升明显但流量反而上不去。实际求解方法采用的是离散枚举动态规划。先根据预测流量枚举所有泵组合的可能性一台、两台、三台、哪些台每个组合用一个内层动态规划来分配变频泵的转速算代价函数值取全局最小的方案。因为单站点泵数量最多6台组合数有限求解速度在秒级完全满足实时修正15分钟的周期要求。这里我加了一个很实用的小技巧给每台泵维护一个“累计运行时长”计数器。优化计算时如果两个方案的电耗差距小于5%就选择累计运行时间更短的那台泵。这样可以让泵组磨损更均匀减少单台泵故障概率。这个细节客户非常认可因为它直接关系到设备全生命周期成本。4.3 参数计算过程示例拿一个具体场景算给你看。假设预测下一个15分钟的场景是流量需求600立方米/小时最不利点压力当前0.25MPa目标下限0.28MPa。现场有3台变频泵单台额定流量350立方米/小时额定扬程60米。单台泵已经不够用350600所以至少开2台。方案A开1号和2号泵每台300立方米/小时方案B开1号和3号泵每台300立方米/小时。这时算法会去查效率表方案A1号泵在300流量点效率72%2号泵在300流量点效率74%方案B1号泵效率72%3号泵效率69%。光看电耗方案A更好但如果1号泵已经累计运行了2800小时而2号泵才1200小时在电耗差距2.5%的情况下算法会选择方案B让1号泵休息一下。这就是“经济性、可靠性、寿命”三者之间的微妙平衡。5. 常见问题与排查技巧实录项目上线运行后真正考验人的不是算法本身而是现场各种意想不到的工程问题。我把几个记忆深刻的坑整理一下这些都是常规文档和算法书里完全不会提的。5.1 预测漂移管网改造导致模型失效上线三个月后客户反馈某个片区的用水预测误差从8%恶化到了20%。查了一圈发现原因很朴素那片区域新接了两个大型商业综合体夜间空调用水量对比之前有巨大变化。模型的训练数据里没有这类模式预测自然跟实际对不上。解决办法除了定期用新数据增量训练之外还加了一个模式标记机制把“管网拓扑发生变化”的事件做成特征标签一旦标记了这类时期模型自动降低旧数据的权重加速学习新规律。客户后来反馈说这段代码是他们认为整个项目最值钱的部分因为管网改造在快速发展城市里太频繁了。5.2 通讯中断与数据空窗工业现场总有网络不稳定的阶段。PLC和上位机之间的通讯一旦中断时序库就会出现数据空洞。每次中断三五分钟靠线性插值还能撑但如果断了一个小时插值就完全失真了。我们的方案是用泵运行状态估计水量当实时流量数据缺失时用泵的转速和效率表反推流量再用清水池液位变化率来做交叉校核。这个方法运行时很稳比单纯依赖通讯恢复后的补传可靠得多。通讯恢复后还要处理乱序写入的问题时序库处理乱序数据要小心否则会把一段时间内的最新值覆盖成旧值。5.3 阀组动作频繁系统刚上线时电动阀和调节阀动作极其频繁。压力波动稍微超过死区系统就触发调节。几天下来客户反馈阀门执行机构温度过高甚至有一个阀的电机烧了。排查后确认是死区和动作间隔设得太小。我们把调节死区从0.01MPa放大到0.02MPa同时增加了最小动作间隔——同一个阀门两次动作之间至少隔10分钟把所有快速波动的调节需求都滤掉。改动上线后阀组动作频次下降80%。这个问题的本质是控制系统设计时不能只盯着监测数据的精确性要尊重执行机构的机械物理约束。5.4 泵效率曲线不准前面提到效率表是用实测数据回归的但第一次用厂家离线数据做的表其实不准。厂家的特性曲线是在恒定转速下测的而现场变频泵在不同转速下效率曲线整体下移。我们后来做了一轮持续三周的实测采样记录不同流量、不同转速下的实际输入功率再把数据拟合到效率表里。效果立竿见影——优化算法给出的泵组合方案电耗比之前平均低了3%。这件事的教训是任何数学模型都必须用现场实际数据校验不要迷信厂家的铭牌参数。6. 经验总结与扩展想法个人体会最深的是这个项目的成功不完全归功于算法先进而是渐进式落地策略赢得的信任。如果一开始就直接上复杂的深度强化学习调度客户看不懂、不敢用项目大概率会卡壳。我们是先用“时段定压”模式跑通——按一天4个时段给压力设定值——把系统跑稳定了再逐步切换到预测滚动优化模式。这个过渡策略值得所有同类项目借鉴。另外有一个特别实用的小技巧用夜间最小流量法快速定位漏损。系统跑起来后每天凌晨2点到4点用水量最低的时段通过分析各分区的进水量曲线哪条曲线出现明显抬升就怀疑哪片区域存在异常漏损。这个技巧成本极低效果好到可以直接推广到任何管网系统。如果后续这个系统要继续扩展我建议往两个方向走一是把DMA分区计量数据接入模型做分区级的精细化调度和漏损预警二是接入更多在线水质仪表数据把水质约束加入调度目标。供水调度这件事做到最后你会发现它是一个“信息越完整优化空间越大”的系统工程数据接入的颗粒度决定了系统的天花板。但不管怎么扩展底层的逻辑始终不变用预测争取时间用滚动修正应对变化用约束条件守住安全底线。把这三点想透了任何供水调度项目都能稳稳落地。