简介智慧燃气大数据云平台整体解决方案PPT面向燃气企业管理者、信息化建设人员及行业方案规划者重点解决传统燃气行业建网难、维护难、网络覆盖差、规模复制难等突出问题。方案引入NB-IoT技术构建“云、管、端”一体化架构覆盖生产运营管理、智能调度、安全监测、GIS管网监测、设备全生命周期管理等核心平台并给出费用后台化、兼容原有收费系统、GPS智能定位等设计原则。压缩包内共1个PPT文件大小4.07MB适合用于项目汇报、技术交流与方案宣讲。当前已有67人学习这份PPT不仅梳理了行业面临的问题与解决路径还详细展示了平台组成、功能亮点及应用价值尤其对安全监测中的压力、流量、泄露报警等场景有具体说明可帮助读者系统性理解智慧燃气综合管控平台的架构设计与运营思路。1. 从两跳式组网到NB-IoT智慧燃气平台为什么先解决通信层燃气行业做数字化最容易被低估的是通信层。我拆过几个燃气项目早期用 LoRa、RF 自组网集中器要现场选址、拉电、做网络规划换一个场景就得重新来一遍很难复制。设备暴露在户外雷击、雨雪、市电故障都要安排人跑现场维护成本比想象中高。更麻烦的是免授权频谱里燃气、水务、路灯、停车各自占频段互相干扰出了问题要扯皮。这也是很多人觉得智慧燃气喊了很多年却一直没规模化的原因。后面转向 NB-IoT 方案以后事情简单了不少智能燃气表内置 NB-IoT 通讯模组每天自动把用气量、电量、信号强度、阀门状态、异常告警传到云平台平台负责校验、计费和分析用户通过 APP、微信、支付宝完成缴费和查询。整套架构按“云、管、端”三层设计正好对应燃气公司对安全、收费、运维最关心的三件事。这篇文章把云管端数据链路、生产运营与安全监测平台、大数据分析怎么做、存量系统怎么兼容拆开讲适合正在做燃气信息化选型的工程师也适合刚接手智慧燃气项目的同学参考落地。2. 云管端架构与数据链路NB-IoT表计接入、报文解析与计费结算2.1 云管端三层划分哪些逻辑放在端哪些放在云云管端架构的核心原则是“表计不存钱后台算费用”。燃气表端只做采集、存储、上报和阀门控制不在本地计算金额。原因很好理解表计放在用户家里存在被拆解、被磁干扰、电池不够换的风险而且燃气公司的价格模型复杂有阶梯气价、调价、补贴放在端上根本升级不过来。云平台统一维护价格版本远程调价后立刻生效旧账单也不受影响。端侧上报的数据字段比多数人想的多累计用气量、电池电压、NB-IoT信号强度、阀门状态、异常告警码。其中累计用气量是核心其他字段用来做故障诊断和信号质量分析。管侧是 NB-IoT 网络表计通过运营商核心网进入 IoT 连接管理平台再转发到燃气公司的业务系统。这个过程中关键是数据格式的标准化越早定下来后续接表具厂商、接运营商平台、接收费系统就越省事。2.2 上行报文设计从表具事件到云平台校验生产环境里 NB-IoT 表计通常走 CoAP 或 LwM2M 协议这里为了演示解析逻辑用 MQTT 格式模拟一个最小可读的上报数据包。核心字段如下# table_event.py - 模拟NB-IoT表具上报最小数据包 import json import time def build_payload(serial_no, meter_value, battery, signal, valve_state, alert_code): payload { serial_no: serial_no, # 表具唯一编号 ts: int(time.time()), # 上报时间戳秒 meter_value: meter_value, # 累计用气量单位 m³ battery: battery, # 电池电压单位 mV signal: signal, # NB-IoT 信号强度dBm valve_state: valve_state, # 0关 1开 alert_code: alert_code # 0正常 1磁干扰 2阀门异常 } return json.dumps(payload) # 模拟每日凌晨 2:00 定时上报 if __name__ __main__: msg build_payload(G20260001, 1234.567, 3600, -85, 1, 0) print(msg)上报的 JSON 到平台后先做四件事JSON 格式校验、字段范围检查、时间戳防重放、序列号白名单校验。浮点数据要特别注意累计用气量在数据库里建议用DECIMAL(12,3)存储不要用double否则金额累计会出现误差。信号强度signal低于 -110 dBm 的记录单独标记用于判断小区 NB-IoT 覆盖质量这一点经常被忽略。平台侧拿到原始事件后还需要把本次读数与上次读数做差值得到本次周期用气量。这里有个常用 T1 策略每天凌晨统一处理昨日数据避免一天多次上报导致重复计算。处理完的数据落到计量明细表再接入计费模块。2.3 计费结算与远程调价金额为什么在后台算阶梯气价是后台计算不放在表端。地方燃气公司通常把年用气量或月用气量分三档每个价格段的边界和单价都不同。下面是一个按阶梯单价累计账单的 Python 函数参数可以根据实际燃气公司定价快速调整# gas_billing.py - 阶梯气价计算示例 TIERS [(120, 2.68), (240, 3.25), (None, 4.10)] def calc_bill(total_usage): total_usage: 当月累计用气量 (m³) cost 0.0 remaining total_usage prev_limit 0 for limit, price in TIERS: if limit is None: cost remaining * price break tier_usage min(remaining, limit - prev_limit) if tier_usage 0: prev_limit limit continue cost tier_usage * price remaining - tier_usage prev_limit limit if remaining 0: break return round(cost, 2)参数TIERS中每一项是“阶梯上限和单价”limitNone表示超出部分无限量。实际项目中价格版本和用户类型要分开维护因为居民用户和工商业用户的阶梯完全不同调价时不能直接改这个常量而是插入新的价格版本号。每个用户当期账单要记录当时生效的版本号这样后续对账才能追溯。对应的月用量汇总 SQL 也很直观需要注意meter_delta必须是经过补抄和估算之后的调整值不能简单拿两个抄表值直接减否则会漏掉换表、通讯中断、表具倒走等异常场景-- 按户号汇总当月用气量用于阶梯气价计费 SELECT user_id, SUM(meter_delta) AS month_usage FROM meter_readings WHERE reading_date BETWEEN 2026-06-01 AND 2026-06-30 GROUP BY user_id;3. 生产运营与安全监测平台GIS、SCADA、巡检与报警的参数化配置3.1 燃气管网GIS地形图同步与管线数据更新燃气管网 GIS 系统解决的问题是把地下管线从纸质图纸变成一套可持续更新的空间数据底座。PPT 里提到的“与地下综合管线系统中的地形图数据同步更新”是重点因为燃气公司通常不是测绘单位依赖外部单位提供地形图如果两边更新节奏不一致地面施工挖断管道的风险会成倍上升。实操中外部管线数据会定期以 Shapefile、CAD 或中间库表的形式同步过来。常见做法是用 PostGIS 做空间数据库通过管道编号pipe_id作为唯一关联键进行更新。这样即使管线的图形坐标发生变化也能准确落到对应管段上。我一般会写下面这类更新 SQL注意只更新几何不一致的管段-- 将地下综合管线系统同步过来的管线段更新到燃气管网图层 UPDATE gas_pipeline g SET geom p.geom, last_sync_at now() FROM external_pipeline p WHERE g.pipe_id p.pipe_id AND ST_Equals(g.geom, p.geom) false;更新完成后不要急着提交发布先做拓扑检查用ST_IsSimple和ST_IsValid找出自相交、重复点、悬挂点再用ST_Within判断管线是否穿越场站边界。这些检查写成定时任务每天跑一次把异常几何记录到单独表里由 GIS 管理员人工确认。这里最容易踩的坑是用管线名称作为关联键实际业务中同名管线太多必须用全局唯一编号。3.2 SCADA场站监测压力、差压、流量、泄漏的四类信号场站安全监测是安全监测平台里最依赖实时数据的一部分。燃气门站、储配站、调压站、加气站会装压力变送器、差压变送器、流量计、泄漏报警探头。这些信号通过 RTU 接入调度中心主站软件再上传到统一平台。下面是常见监控参数的采集频率和报警阈值经验值监控项目传感器类型采集频率典型报警阈值进站/出站压力压力变送器每5秒低于0.3MPa或高于1.2MPa持续10秒储罐差压差压变送器每5秒差压超设计值80%进站/出站流量流量计每1分钟瞬时流量波动超均值30%燃气泄漏泄漏报警探头每1秒浓度超20%LEL阈值不能只看瞬时值要加持续时间去抖。比如压力瞬时降到 0.15MPa 可能只是信号毛刺持续 10 秒才需要触发报警。下面是一个最小示例# scada_alarm.py - 场站参数越限报警最小实现 THRESHOLDS { pressure_in: (0.3, 1.2), # MPa delta_p: (0.0, 0.8), # 差压上限按设计值比例 flow: (None, 3000), # m³/h } def check_scada(reading): alarms [] if reading[pressure_in] THRESHOLDS[pressure_in][0]: alarms.append(P_IN_LOW) if reading[pressure_in] THRESHOLDS[pressure_in][1]: alarms.append(P_IN_HIGH) if reading[delta_p] THRESHOLDS[delta_p][1]: alarms.append(DP_HIGH) if reading[flow] THRESHOLDS[flow][1]: alarms.append(FLOW_OVER) return alarms报警的类型要比这个丰富得多。调度画面里常见的是参数越限报警、硬件设备故障报警、系统自诊断报警、电源故障报警、通信故障报警、网络故障报警。这些报警要分优先级泄漏和压力骤降最高通信故障和电池低电次之。报警产生后除了弹窗还要写事件表记录报警开始时间、恢复时间、确认人、处理措施否则后续事故追溯时查不到原始数据。3.3 巡检管理与泄漏监测从人工登记到移动化闭环管网安全不能只靠 SCADA 点上的传感器巡检还是要走人。平台做巡检管理重点不是把纸质表单电子化而是把“谁在什么时候巡了哪个点、发现了什么问题、怎么处理”这件事闭环起来。巡线人员、车载检测设备、小区手持巡检设备都会产生 GPS 轨迹和现场记录平台利用 GPS 智能定位做抄表路径回放也能对漏巡、超时、偏离路线给出提示。日常排班中巡检任务生成规则是“风险等级越高巡检间隔越短”。下面的 SQL 按风险等级和上次巡检时间筛选出今日必须执行的点位-- 根据上次巡检时间和风险等级生成今日任务 SELECT r.point_id, r.geom, r.risk_level, COALESCE(MAX(t.inspect_time), 1970-01-01) AS last_inspect FROM inspection_point r LEFT JOIN inspection_record t ON r.point_id t.point_id WHERE r.is_active true AND r.risk_level 3 GROUP BY r.point_id, r.geom, r.risk_level HAVING COALESCE(MAX(t.inspect_time), 1970-01-01) now() - interval 7 days;这里risk_level 3表示高风险点HAVING后面筛选出 7 天内没巡过的点位。实际生产中还应该带上区域划分避免任务跨区分配。燃气巡检不能只看地上还要覆盖工商业用户、居民小区、地下密闭空间、管网连接处这些容易漏气的位置。阴极保护监测则是通过外加电流让金属管道做阴极抑制电化学腐蚀这里的关键参数是电位值要按管道材料设定正常范围低于保护电位就要检查恒电位仪。4. 大数据分析与供销差治理用气负荷预测、压力调配与异常检测4.1 多节点气量数据汇聚门站、管线、表具的数据粒度与存储智慧燃气平台真正有价值的部分是把门站供应量、管线节点压力、用户表计用气量拉到一起做分析。三类数据粒度差别很大SCADA 数据是分钟级甚至秒级用户表计是每日冻结值门站和调压站则按小时汇总。直接混在一起算会造成口径混乱所以建议分三层存储明细层、汇总层、指标层。明细层适合用 ClickHouse 这类列式数据库做归档查询尤其适合按用户、按日期聚合。下面以分布式表为例分布键用user_id保证同一个表计的数据落到同一个分片查询时不需要跨节点合并-- ClickHouse 分布式表按天分区气量明细 CREATE TABLE gas.meter_readings_local ( user_id UInt64, read_date Date, read_value Decimal(12,3), delta Decimal(12,3), signal Int8, alert_code UInt8 ) ENGINE MergeTree() PARTITION BY toYYYYMM(read_date) ORDER BY (user_id, read_date); -- 创建分布式视图集群名按实际环境调整 CREATE TABLE gas.meter_readings AS SELECT * FROM gas.meter_readings_local ENGINE Distributed(cluster_name, gas, meter_readings_local, cityHash64(user_id));建表时要注意delta字段是当日用气量不是累计值否则聚合时会把同一个分区内的累计值叠加。数据导入链路一般走 Kafka表具平台或 IoT 平台上报的消息直接进 Kafka topic再由写入程序消费到 ClickHouse。大数据集群部署策略上先保证分片数和副本数的倍数关系不要盲目扩大分片否则小查询也要走分布式节点反而变慢。4.2 高峰低谷统计与输配管线压力调配调度中心关注的不是单块表而是整个城市或区域的负荷曲线。用气高峰通常出现在早晚做饭时段冬季采暖期还会叠加低温和节假日效应。平台后台通过高峰低谷统计可以提前发现某个片区的用气量是否逼近管网输配能力然后安排调整调压站出口压力或启用储气设施调峰。负荷预测不一定要上很复杂的深度学习模型很多场景用历史同期均值就够用。我一般先用 28 天的小时级数据做基线预测再根据气温修正如果效果不够再上 LSTM 或 Prophet。下面是基线预测的最小实现# load_forecast.py - 基于历史同时段均值的用气高峰预测 import pandas as pd def forecast_hourly_usage(history: pd.DataFrame, target_date: str, hour: int) - float: # history 至少包含 4 周的小时级数据字段: date, hour, usage sample history[ (history[hour] hour) (history[date] target_date) ].tail(28) return float(sample[usage].mean())这个函数只预测了单小时值实际调度系统需要连续预测未来 24 小时曲线并且每个预测值都附带置信区间。当预测值超过调压站额定输气能力 90% 时系统应生成预报警调度员可以提前下级调压指令。预测模型上线后要保留预测值和实际值的对比日志定期计算平均绝对误差模型效果差就回滚到基线。4.3 供气平衡与跑冒滴漏偷排查供销差分析与异常检测供销差率是燃气公司的核心经营指标之一。简单说就是门站购入的总气量和通过用户表计卖出去的气量之差。正常误差包括管道降压、温度压力补偿、表具计量偏差异常原因包括管线泄漏、偷气、表具故障、抄表不及时。供销差率持续偏高平台就需要从空间和时间两个维度定位异常区域。设计上先按日计算区域供销差率再对比周边区域和自身历史值。下面是按日汇总的 SQL-- 计算每日供销差率 SELECT d.day, d.supply_total, m.meter_total, ROUND((d.supply_total - m.meter_total) / d.supply_total * 100, 2) AS loss_rate FROM daily_supply d JOIN ( SELECT read_date AS day, SUM(delta) AS meter_total FROM meter_readings GROUP BY read_date ) m ON d.day m.day ORDER BY d.day DESC;这里的daily_supply.supply_total和meter_readings.delta必须使用同一时间口径否则会出现虚假的供销差。理想状态是门站的日指定量和用户日冻结抄表数据都按当地零点结算。发现某一区域连续 3 天供销差率超过阈值就自动生成异常工单派巡检车巡线排查结合 GIS 定位还能优先检查异常区域内的老旧管线、第三方施工点、废弃管段。5. 平台兼容性与部署技巧存量收费系统对接、调价预案与可视化验收5.1 与原有收费系统兼容接口幂等与对账燃气公司已经有收费系统智慧燃气数据云平台不能完全替代它更多时候要双向同步。对接时最容易出问题的是重复计费所以要保证接口幂等。常见做法是增加“请求唯一键”比如账单月用户ID收到重复请求直接返回已处理app.post(/api/v1/billing/sync) def sync_billing(): payload request.json # 幂等键月账单号用户ID重复请求不重复入账 key f{payload[bill_month]}:{payload[user_id]} if redis.setnx(key, 1, ex3600): billing_service.create(payload) return {code: 0, msg: created} return {code: 1, msg: duplicated}这里用 Redis 的setnx实现防重ex3600表示一小时内重复请求不会再次创建账单。每天凌晨还需要跑一次对账任务比较智慧燃气平台的应收金额和原收费系统的实收金额差异记录写入对账差异表由财务人工查看。5.2 远程调价与阶梯气价设置的运维预案政府调价公告发布后平台要在当天完成价格切换。远程调价不能只改一个单价字段要按下面的方式操作并保留回滚手段操作步骤回滚调价维护新价格版本 - 设置生效时间 - 试算典型用户账单 - 发布停用新版本旧版本立即生效阶梯气价设置配置阶梯边界和单价 - 按户测算法生成模拟账单 - 发布重新生成账单并冲销试算步骤尤其重要。发布前从用户表里抽取居民、工商业、混合用气三类典型用户用新价格跑一次账单确认金额没有跃变。历史账单不能回算只能记录价格版本号后续审计时按版本号追溯。5.3 可视化大屏与验收指标项目上线前数据可视化大屏是领导最直观的感受来源但验收不能只看大屏好看。我一般把下面几项作为验收硬指标GIS 图层能正确加载管线段、阀井、场站图标SCADA 压力、流量刷新延迟小于 5 秒断开某个表具通讯后1 分钟内产生告警随机抽取 100 个用户自动抄表成功率不低于 98%智慧燃气平台与旧收费系统当日对账金额差异为 0。还有一个容易忽略的点大屏的数据刷新接口要和业务系统分离避免大屏高频轮询把生产数据库拖垮前端直接用 Redis 缓存或独立的查询库。本文还有配套的精品资源点击获取
智慧燃气平台技术架构：从NB-IoT云管端到大数据治理实践
简介智慧燃气大数据云平台整体解决方案PPT面向燃气企业管理者、信息化建设人员及行业方案规划者重点解决传统燃气行业建网难、维护难、网络覆盖差、规模复制难等突出问题。方案引入NB-IoT技术构建“云、管、端”一体化架构覆盖生产运营管理、智能调度、安全监测、GIS管网监测、设备全生命周期管理等核心平台并给出费用后台化、兼容原有收费系统、GPS智能定位等设计原则。压缩包内共1个PPT文件大小4.07MB适合用于项目汇报、技术交流与方案宣讲。当前已有67人学习这份PPT不仅梳理了行业面临的问题与解决路径还详细展示了平台组成、功能亮点及应用价值尤其对安全监测中的压力、流量、泄露报警等场景有具体说明可帮助读者系统性理解智慧燃气综合管控平台的架构设计与运营思路。1. 从两跳式组网到NB-IoT智慧燃气平台为什么先解决通信层燃气行业做数字化最容易被低估的是通信层。我拆过几个燃气项目早期用 LoRa、RF 自组网集中器要现场选址、拉电、做网络规划换一个场景就得重新来一遍很难复制。设备暴露在户外雷击、雨雪、市电故障都要安排人跑现场维护成本比想象中高。更麻烦的是免授权频谱里燃气、水务、路灯、停车各自占频段互相干扰出了问题要扯皮。这也是很多人觉得智慧燃气喊了很多年却一直没规模化的原因。后面转向 NB-IoT 方案以后事情简单了不少智能燃气表内置 NB-IoT 通讯模组每天自动把用气量、电量、信号强度、阀门状态、异常告警传到云平台平台负责校验、计费和分析用户通过 APP、微信、支付宝完成缴费和查询。整套架构按“云、管、端”三层设计正好对应燃气公司对安全、收费、运维最关心的三件事。这篇文章把云管端数据链路、生产运营与安全监测平台、大数据分析怎么做、存量系统怎么兼容拆开讲适合正在做燃气信息化选型的工程师也适合刚接手智慧燃气项目的同学参考落地。2. 云管端架构与数据链路NB-IoT表计接入、报文解析与计费结算2.1 云管端三层划分哪些逻辑放在端哪些放在云云管端架构的核心原则是“表计不存钱后台算费用”。燃气表端只做采集、存储、上报和阀门控制不在本地计算金额。原因很好理解表计放在用户家里存在被拆解、被磁干扰、电池不够换的风险而且燃气公司的价格模型复杂有阶梯气价、调价、补贴放在端上根本升级不过来。云平台统一维护价格版本远程调价后立刻生效旧账单也不受影响。端侧上报的数据字段比多数人想的多累计用气量、电池电压、NB-IoT信号强度、阀门状态、异常告警码。其中累计用气量是核心其他字段用来做故障诊断和信号质量分析。管侧是 NB-IoT 网络表计通过运营商核心网进入 IoT 连接管理平台再转发到燃气公司的业务系统。这个过程中关键是数据格式的标准化越早定下来后续接表具厂商、接运营商平台、接收费系统就越省事。2.2 上行报文设计从表具事件到云平台校验生产环境里 NB-IoT 表计通常走 CoAP 或 LwM2M 协议这里为了演示解析逻辑用 MQTT 格式模拟一个最小可读的上报数据包。核心字段如下# table_event.py - 模拟NB-IoT表具上报最小数据包 import json import time def build_payload(serial_no, meter_value, battery, signal, valve_state, alert_code): payload { serial_no: serial_no, # 表具唯一编号 ts: int(time.time()), # 上报时间戳秒 meter_value: meter_value, # 累计用气量单位 m³ battery: battery, # 电池电压单位 mV signal: signal, # NB-IoT 信号强度dBm valve_state: valve_state, # 0关 1开 alert_code: alert_code # 0正常 1磁干扰 2阀门异常 } return json.dumps(payload) # 模拟每日凌晨 2:00 定时上报 if __name__ __main__: msg build_payload(G20260001, 1234.567, 3600, -85, 1, 0) print(msg)上报的 JSON 到平台后先做四件事JSON 格式校验、字段范围检查、时间戳防重放、序列号白名单校验。浮点数据要特别注意累计用气量在数据库里建议用DECIMAL(12,3)存储不要用double否则金额累计会出现误差。信号强度signal低于 -110 dBm 的记录单独标记用于判断小区 NB-IoT 覆盖质量这一点经常被忽略。平台侧拿到原始事件后还需要把本次读数与上次读数做差值得到本次周期用气量。这里有个常用 T1 策略每天凌晨统一处理昨日数据避免一天多次上报导致重复计算。处理完的数据落到计量明细表再接入计费模块。2.3 计费结算与远程调价金额为什么在后台算阶梯气价是后台计算不放在表端。地方燃气公司通常把年用气量或月用气量分三档每个价格段的边界和单价都不同。下面是一个按阶梯单价累计账单的 Python 函数参数可以根据实际燃气公司定价快速调整# gas_billing.py - 阶梯气价计算示例 TIERS [(120, 2.68), (240, 3.25), (None, 4.10)] def calc_bill(total_usage): total_usage: 当月累计用气量 (m³) cost 0.0 remaining total_usage prev_limit 0 for limit, price in TIERS: if limit is None: cost remaining * price break tier_usage min(remaining, limit - prev_limit) if tier_usage 0: prev_limit limit continue cost tier_usage * price remaining - tier_usage prev_limit limit if remaining 0: break return round(cost, 2)参数TIERS中每一项是“阶梯上限和单价”limitNone表示超出部分无限量。实际项目中价格版本和用户类型要分开维护因为居民用户和工商业用户的阶梯完全不同调价时不能直接改这个常量而是插入新的价格版本号。每个用户当期账单要记录当时生效的版本号这样后续对账才能追溯。对应的月用量汇总 SQL 也很直观需要注意meter_delta必须是经过补抄和估算之后的调整值不能简单拿两个抄表值直接减否则会漏掉换表、通讯中断、表具倒走等异常场景-- 按户号汇总当月用气量用于阶梯气价计费 SELECT user_id, SUM(meter_delta) AS month_usage FROM meter_readings WHERE reading_date BETWEEN 2026-06-01 AND 2026-06-30 GROUP BY user_id;3. 生产运营与安全监测平台GIS、SCADA、巡检与报警的参数化配置3.1 燃气管网GIS地形图同步与管线数据更新燃气管网 GIS 系统解决的问题是把地下管线从纸质图纸变成一套可持续更新的空间数据底座。PPT 里提到的“与地下综合管线系统中的地形图数据同步更新”是重点因为燃气公司通常不是测绘单位依赖外部单位提供地形图如果两边更新节奏不一致地面施工挖断管道的风险会成倍上升。实操中外部管线数据会定期以 Shapefile、CAD 或中间库表的形式同步过来。常见做法是用 PostGIS 做空间数据库通过管道编号pipe_id作为唯一关联键进行更新。这样即使管线的图形坐标发生变化也能准确落到对应管段上。我一般会写下面这类更新 SQL注意只更新几何不一致的管段-- 将地下综合管线系统同步过来的管线段更新到燃气管网图层 UPDATE gas_pipeline g SET geom p.geom, last_sync_at now() FROM external_pipeline p WHERE g.pipe_id p.pipe_id AND ST_Equals(g.geom, p.geom) false;更新完成后不要急着提交发布先做拓扑检查用ST_IsSimple和ST_IsValid找出自相交、重复点、悬挂点再用ST_Within判断管线是否穿越场站边界。这些检查写成定时任务每天跑一次把异常几何记录到单独表里由 GIS 管理员人工确认。这里最容易踩的坑是用管线名称作为关联键实际业务中同名管线太多必须用全局唯一编号。3.2 SCADA场站监测压力、差压、流量、泄漏的四类信号场站安全监测是安全监测平台里最依赖实时数据的一部分。燃气门站、储配站、调压站、加气站会装压力变送器、差压变送器、流量计、泄漏报警探头。这些信号通过 RTU 接入调度中心主站软件再上传到统一平台。下面是常见监控参数的采集频率和报警阈值经验值监控项目传感器类型采集频率典型报警阈值进站/出站压力压力变送器每5秒低于0.3MPa或高于1.2MPa持续10秒储罐差压差压变送器每5秒差压超设计值80%进站/出站流量流量计每1分钟瞬时流量波动超均值30%燃气泄漏泄漏报警探头每1秒浓度超20%LEL阈值不能只看瞬时值要加持续时间去抖。比如压力瞬时降到 0.15MPa 可能只是信号毛刺持续 10 秒才需要触发报警。下面是一个最小示例# scada_alarm.py - 场站参数越限报警最小实现 THRESHOLDS { pressure_in: (0.3, 1.2), # MPa delta_p: (0.0, 0.8), # 差压上限按设计值比例 flow: (None, 3000), # m³/h } def check_scada(reading): alarms [] if reading[pressure_in] THRESHOLDS[pressure_in][0]: alarms.append(P_IN_LOW) if reading[pressure_in] THRESHOLDS[pressure_in][1]: alarms.append(P_IN_HIGH) if reading[delta_p] THRESHOLDS[delta_p][1]: alarms.append(DP_HIGH) if reading[flow] THRESHOLDS[flow][1]: alarms.append(FLOW_OVER) return alarms报警的类型要比这个丰富得多。调度画面里常见的是参数越限报警、硬件设备故障报警、系统自诊断报警、电源故障报警、通信故障报警、网络故障报警。这些报警要分优先级泄漏和压力骤降最高通信故障和电池低电次之。报警产生后除了弹窗还要写事件表记录报警开始时间、恢复时间、确认人、处理措施否则后续事故追溯时查不到原始数据。3.3 巡检管理与泄漏监测从人工登记到移动化闭环管网安全不能只靠 SCADA 点上的传感器巡检还是要走人。平台做巡检管理重点不是把纸质表单电子化而是把“谁在什么时候巡了哪个点、发现了什么问题、怎么处理”这件事闭环起来。巡线人员、车载检测设备、小区手持巡检设备都会产生 GPS 轨迹和现场记录平台利用 GPS 智能定位做抄表路径回放也能对漏巡、超时、偏离路线给出提示。日常排班中巡检任务生成规则是“风险等级越高巡检间隔越短”。下面的 SQL 按风险等级和上次巡检时间筛选出今日必须执行的点位-- 根据上次巡检时间和风险等级生成今日任务 SELECT r.point_id, r.geom, r.risk_level, COALESCE(MAX(t.inspect_time), 1970-01-01) AS last_inspect FROM inspection_point r LEFT JOIN inspection_record t ON r.point_id t.point_id WHERE r.is_active true AND r.risk_level 3 GROUP BY r.point_id, r.geom, r.risk_level HAVING COALESCE(MAX(t.inspect_time), 1970-01-01) now() - interval 7 days;这里risk_level 3表示高风险点HAVING后面筛选出 7 天内没巡过的点位。实际生产中还应该带上区域划分避免任务跨区分配。燃气巡检不能只看地上还要覆盖工商业用户、居民小区、地下密闭空间、管网连接处这些容易漏气的位置。阴极保护监测则是通过外加电流让金属管道做阴极抑制电化学腐蚀这里的关键参数是电位值要按管道材料设定正常范围低于保护电位就要检查恒电位仪。4. 大数据分析与供销差治理用气负荷预测、压力调配与异常检测4.1 多节点气量数据汇聚门站、管线、表具的数据粒度与存储智慧燃气平台真正有价值的部分是把门站供应量、管线节点压力、用户表计用气量拉到一起做分析。三类数据粒度差别很大SCADA 数据是分钟级甚至秒级用户表计是每日冻结值门站和调压站则按小时汇总。直接混在一起算会造成口径混乱所以建议分三层存储明细层、汇总层、指标层。明细层适合用 ClickHouse 这类列式数据库做归档查询尤其适合按用户、按日期聚合。下面以分布式表为例分布键用user_id保证同一个表计的数据落到同一个分片查询时不需要跨节点合并-- ClickHouse 分布式表按天分区气量明细 CREATE TABLE gas.meter_readings_local ( user_id UInt64, read_date Date, read_value Decimal(12,3), delta Decimal(12,3), signal Int8, alert_code UInt8 ) ENGINE MergeTree() PARTITION BY toYYYYMM(read_date) ORDER BY (user_id, read_date); -- 创建分布式视图集群名按实际环境调整 CREATE TABLE gas.meter_readings AS SELECT * FROM gas.meter_readings_local ENGINE Distributed(cluster_name, gas, meter_readings_local, cityHash64(user_id));建表时要注意delta字段是当日用气量不是累计值否则聚合时会把同一个分区内的累计值叠加。数据导入链路一般走 Kafka表具平台或 IoT 平台上报的消息直接进 Kafka topic再由写入程序消费到 ClickHouse。大数据集群部署策略上先保证分片数和副本数的倍数关系不要盲目扩大分片否则小查询也要走分布式节点反而变慢。4.2 高峰低谷统计与输配管线压力调配调度中心关注的不是单块表而是整个城市或区域的负荷曲线。用气高峰通常出现在早晚做饭时段冬季采暖期还会叠加低温和节假日效应。平台后台通过高峰低谷统计可以提前发现某个片区的用气量是否逼近管网输配能力然后安排调整调压站出口压力或启用储气设施调峰。负荷预测不一定要上很复杂的深度学习模型很多场景用历史同期均值就够用。我一般先用 28 天的小时级数据做基线预测再根据气温修正如果效果不够再上 LSTM 或 Prophet。下面是基线预测的最小实现# load_forecast.py - 基于历史同时段均值的用气高峰预测 import pandas as pd def forecast_hourly_usage(history: pd.DataFrame, target_date: str, hour: int) - float: # history 至少包含 4 周的小时级数据字段: date, hour, usage sample history[ (history[hour] hour) (history[date] target_date) ].tail(28) return float(sample[usage].mean())这个函数只预测了单小时值实际调度系统需要连续预测未来 24 小时曲线并且每个预测值都附带置信区间。当预测值超过调压站额定输气能力 90% 时系统应生成预报警调度员可以提前下级调压指令。预测模型上线后要保留预测值和实际值的对比日志定期计算平均绝对误差模型效果差就回滚到基线。4.3 供气平衡与跑冒滴漏偷排查供销差分析与异常检测供销差率是燃气公司的核心经营指标之一。简单说就是门站购入的总气量和通过用户表计卖出去的气量之差。正常误差包括管道降压、温度压力补偿、表具计量偏差异常原因包括管线泄漏、偷气、表具故障、抄表不及时。供销差率持续偏高平台就需要从空间和时间两个维度定位异常区域。设计上先按日计算区域供销差率再对比周边区域和自身历史值。下面是按日汇总的 SQL-- 计算每日供销差率 SELECT d.day, d.supply_total, m.meter_total, ROUND((d.supply_total - m.meter_total) / d.supply_total * 100, 2) AS loss_rate FROM daily_supply d JOIN ( SELECT read_date AS day, SUM(delta) AS meter_total FROM meter_readings GROUP BY read_date ) m ON d.day m.day ORDER BY d.day DESC;这里的daily_supply.supply_total和meter_readings.delta必须使用同一时间口径否则会出现虚假的供销差。理想状态是门站的日指定量和用户日冻结抄表数据都按当地零点结算。发现某一区域连续 3 天供销差率超过阈值就自动生成异常工单派巡检车巡线排查结合 GIS 定位还能优先检查异常区域内的老旧管线、第三方施工点、废弃管段。5. 平台兼容性与部署技巧存量收费系统对接、调价预案与可视化验收5.1 与原有收费系统兼容接口幂等与对账燃气公司已经有收费系统智慧燃气数据云平台不能完全替代它更多时候要双向同步。对接时最容易出问题的是重复计费所以要保证接口幂等。常见做法是增加“请求唯一键”比如账单月用户ID收到重复请求直接返回已处理app.post(/api/v1/billing/sync) def sync_billing(): payload request.json # 幂等键月账单号用户ID重复请求不重复入账 key f{payload[bill_month]}:{payload[user_id]} if redis.setnx(key, 1, ex3600): billing_service.create(payload) return {code: 0, msg: created} return {code: 1, msg: duplicated}这里用 Redis 的setnx实现防重ex3600表示一小时内重复请求不会再次创建账单。每天凌晨还需要跑一次对账任务比较智慧燃气平台的应收金额和原收费系统的实收金额差异记录写入对账差异表由财务人工查看。5.2 远程调价与阶梯气价设置的运维预案政府调价公告发布后平台要在当天完成价格切换。远程调价不能只改一个单价字段要按下面的方式操作并保留回滚手段操作步骤回滚调价维护新价格版本 - 设置生效时间 - 试算典型用户账单 - 发布停用新版本旧版本立即生效阶梯气价设置配置阶梯边界和单价 - 按户测算法生成模拟账单 - 发布重新生成账单并冲销试算步骤尤其重要。发布前从用户表里抽取居民、工商业、混合用气三类典型用户用新价格跑一次账单确认金额没有跃变。历史账单不能回算只能记录价格版本号后续审计时按版本号追溯。5.3 可视化大屏与验收指标项目上线前数据可视化大屏是领导最直观的感受来源但验收不能只看大屏好看。我一般把下面几项作为验收硬指标GIS 图层能正确加载管线段、阀井、场站图标SCADA 压力、流量刷新延迟小于 5 秒断开某个表具通讯后1 分钟内产生告警随机抽取 100 个用户自动抄表成功率不低于 98%智慧燃气平台与旧收费系统当日对账金额差异为 0。还有一个容易忽略的点大屏的数据刷新接口要和业务系统分离避免大屏高频轮询把生产数据库拖垮前端直接用 Redis 缓存或独立的查询库。本文还有配套的精品资源点击获取
