簡介智慧燃氣大數(shù)據(jù)云平臺整體解決方案PPT面向燃氣企業(yè)管理者、信息化建設(shè)人員及行業(yè)方案規(guī)劃者重點解決傳統(tǒng)燃氣行業(yè)建網(wǎng)難、維護難、網(wǎng)絡(luò)覆蓋差、規(guī)模復(fù)制難等突出問題。方案引入NB-IoT技術(shù)構(gòu)建“云、管、端”一體化架構(gòu)覆蓋生產(chǎn)運營管理、智能調(diào)度、安全監(jiān)測、GIS管網(wǎng)監(jiān)測、設(shè)備全生命周期管理等核心平臺并給出費用后臺化、兼容原有收費系統(tǒng)、GPS智能定位等設(shè)計原則。壓縮包內(nèi)共1個PPT文件大小4.07MB適合用于項目匯報、技術(shù)交流與方案宣講。當(dāng)前已有67人學(xué)習(xí)這份PPT不僅梳理了行業(yè)面臨的問題與解決路徑還詳細展示了平臺組成、功能亮點及應(yīng)用價值尤其對安全監(jiān)測中的壓力、流量、泄露報警等場景有具體說明可幫助讀者系統(tǒng)性理解智慧燃氣綜合管控平臺的架構(gòu)設(shè)計與運營思路。1. 從兩跳式組網(wǎng)到NB-IoT智慧燃氣平臺為什么先解決通信層燃氣行業(yè)做數(shù)字化最容易被低估的是通信層。我拆過幾個燃氣項目早期用 LoRa、RF 自組網(wǎng)集中器要現(xiàn)場選址、拉電、做網(wǎng)絡(luò)規(guī)劃換一個場景就得重新來一遍很難復(fù)制。設(shè)備暴露在戶外雷擊、雨雪、市電故障都要安排人跑現(xiàn)場維護成本比想象中高。更麻煩的是免授權(quán)頻譜里燃氣、水務(wù)、路燈、停車各自占頻段互相干擾出了問題要扯皮。這也是很多人覺得智慧燃氣喊了很多年卻一直沒規(guī)?；脑?。后面轉(zhuǎn)向 NB-IoT 方案以后事情簡單了不少智能燃氣表內(nèi)置 NB-IoT 通訊模組每天自動把用氣量、電量、信號強度、閥門狀態(tài)、異常告警傳到云平臺平臺負責(zé)校驗、計費和分析用戶通過 APP、微信、支付寶完成繳費和查詢。整套架構(gòu)按“云、管、端”三層設(shè)計正好對應(yīng)燃氣公司對安全、收費、運維最關(guān)心的三件事。這篇文章把云管端數(shù)據(jù)鏈路、生產(chǎn)運營與安全監(jiān)測平臺、大數(shù)據(jù)分析怎么做、存量系統(tǒng)怎么兼容拆開講適合正在做燃氣信息化選型的工程師也適合剛接手智慧燃氣項目的同學(xué)參考落地。2. 云管端架構(gòu)與數(shù)據(jù)鏈路NB-IoT表計接入、報文解析與計費結(jié)算2.1 云管端三層劃分哪些邏輯放在端哪些放在云云管端架構(gòu)的核心原則是“表計不存錢后臺算費用”。燃氣表端只做采集、存儲、上報和閥門控制不在本地計算金額。原因很好理解表計放在用戶家里存在被拆解、被磁干擾、電池不夠換的風(fēng)險而且燃氣公司的價格模型復(fù)雜有階梯氣價、調(diào)價、補貼放在端上根本升級不過來。云平臺統(tǒng)一維護價格版本遠程調(diào)價后立刻生效舊賬單也不受影響。端側(cè)上報的數(shù)據(jù)字段比多數(shù)人想的多累計用氣量、電池電壓、NB-IoT信號強度、閥門狀態(tài)、異常告警碼。其中累計用氣量是核心其他字段用來做故障診斷和信號質(zhì)量分析。管側(cè)是 NB-IoT 網(wǎng)絡(luò)表計通過運營商核心網(wǎng)進入 IoT 連接管理平臺再轉(zhuǎn)發(fā)到燃氣公司的業(yè)務(wù)系統(tǒng)。這個過程中關(guān)鍵是數(shù)據(jù)格式的標(biāo)準(zhǔn)化越早定下來后續(xù)接表具廠商、接運營商平臺、接收費系統(tǒng)就越省事。2.2 上行報文設(shè)計從表具事件到云平臺校驗生產(chǎn)環(huán)境里 NB-IoT 表計通常走 CoAP 或 LwM2M 協(xié)議這里為了演示解析邏輯用 MQTT 格式模擬一個最小可讀的上報數(shù)據(jù)包。核心字段如下# table_event.py - 模擬NB-IoT表具上報最小數(shù)據(jù)包 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, # 累計用氣量單位 m3 battery: battery, # 電池電壓單位 mV signal: signal, # NB-IoT 信號強度dBm valve_state: valve_state, # 0關(guān) 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 格式校驗、字段范圍檢查、時間戳防重放、序列號白名單校驗。浮點數(shù)據(jù)要特別注意累計用氣量在數(shù)據(jù)庫里建議用DECIMAL(12,3)存儲不要用double否則金額累計會出現(xiàn)誤差。信號強度signal低于 -110 dBm 的記錄單獨標(biāo)記用于判斷小區(qū) NB-IoT 覆蓋質(zhì)量這一點經(jīng)常被忽略。平臺側(cè)拿到原始事件后還需要把本次讀數(shù)與上次讀數(shù)做差值得到本次周期用氣量。這里有個常用 T1 策略每天凌晨統(tǒng)一處理昨日數(shù)據(jù)避免一天多次上報導(dǎo)致重復(fù)計算。處理完的數(shù)據(jù)落到計量明細表再接入計費模塊。2.3 計費結(jié)算與遠程調(diào)價金額為什么在后臺算階梯氣價是后臺計算不放在表端。地方燃氣公司通常把年用氣量或月用氣量分三檔每個價格段的邊界和單價都不同。下面是一個按階梯單價累計賬單的 Python 函數(shù)參數(shù)可以根據(jù)實際燃氣公司定價快速調(diào)整# gas_billing.py - 階梯氣價計算示例 TIERS [(120, 2.68), (240, 3.25), (None, 4.10)] def calc_bill(total_usage): total_usage: 當(dāng)月累計用氣量 (m3) 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)參數(shù)TIERS中每一項是“階梯上限和單價”limitNone表示超出部分無限量。實際項目中價格版本和用戶類型要分開維護因為居民用戶和工商業(yè)用戶的階梯完全不同調(diào)價時不能直接改這個常量而是插入新的價格版本號。每個用戶當(dāng)期賬單要記錄當(dāng)時生效的版本號這樣后續(xù)對賬才能追溯。對應(yīng)的月用量匯總 SQL 也很直觀需要注意meter_delta必須是經(jīng)過補抄和估算之后的調(diào)整值不能簡單拿兩個抄表值直接減否則會漏掉換表、通訊中斷、表具倒走等異常場景-- 按戶號匯總當(dāng)月用氣量用于階梯氣價計費 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. 生產(chǎn)運營與安全監(jiān)測平臺GIS、SCADA、巡檢與報警的參數(shù)化配置3.1 燃氣管網(wǎng)GIS地形圖同步與管線數(shù)據(jù)更新燃氣管網(wǎng) GIS 系統(tǒng)解決的問題是把地下管線從紙質(zhì)圖紙變成一套可持續(xù)更新的空間數(shù)據(jù)底座。PPT 里提到的“與地下綜合管線系統(tǒng)中的地形圖數(shù)據(jù)同步更新”是重點因為燃氣公司通常不是測繪單位依賴外部單位提供地形圖如果兩邊更新節(jié)奏不一致地面施工挖斷管道的風(fēng)險會成倍上升。實操中外部管線數(shù)據(jù)會定期以 Shapefile、CAD 或中間庫表的形式同步過來。常見做法是用 PostGIS 做空間數(shù)據(jù)庫通過管道編號pipe_id作為唯一關(guān)聯(lián)鍵進行更新。這樣即使管線的圖形坐標(biāo)發(fā)生變化也能準(zhǔn)確落到對應(yīng)管段上。我一般會寫下面這類更新 SQL注意只更新幾何不一致的管段-- 將地下綜合管線系統(tǒng)同步過來的管線段更新到燃氣管網(wǎng)圖層 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;更新完成后不要急著提交發(fā)布先做拓撲檢查用ST_IsSimple和ST_IsValid找出自相交、重復(fù)點、懸掛點再用ST_Within判斷管線是否穿越場站邊界。這些檢查寫成定時任務(wù)每天跑一次把異常幾何記錄到單獨表里由 GIS 管理員人工確認。這里最容易踩的坑是用管線名稱作為關(guān)聯(lián)鍵實際業(yè)務(wù)中同名管線太多必須用全局唯一編號。3.2 SCADA場站監(jiān)測壓力、差壓、流量、泄漏的四類信號場站安全監(jiān)測是安全監(jiān)測平臺里最依賴實時數(shù)據(jù)的一部分。燃氣門站、儲配站、調(diào)壓站、加氣站會裝壓力變送器、差壓變送器、流量計、泄漏報警探頭。這些信號通過 RTU 接入調(diào)度中心主站軟件再上傳到統(tǒng)一平臺。下面是常見監(jiān)控參數(shù)的采集頻率和報警閾值經(jīng)驗值監(jiān)控項目傳感器類型采集頻率典型報警閾值進站/出站壓力壓力變送器每5秒低于0.3MPa或高于1.2MPa持續(xù)10秒儲罐差壓差壓變送器每5秒差壓超設(shè)計值80%進站/出站流量流量計每1分鐘瞬時流量波動超均值30%燃氣泄漏泄漏報警探頭每1秒濃度超20%LEL閾值不能只看瞬時值要加持續(xù)時間去抖。比如壓力瞬時降到 0.15MPa 可能只是信號毛刺持續(xù) 10 秒才需要觸發(fā)報警。下面是一個最小示例# scada_alarm.py - 場站參數(shù)越限報警最小實現(xiàn) THRESHOLDS { pressure_in: (0.3, 1.2), # MPa delta_p: (0.0, 0.8), # 差壓上限按設(shè)計值比例 flow: (None, 3000), # m3/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報警的類型要比這個豐富得多。調(diào)度畫面里常見的是參數(shù)越限報警、硬件設(shè)備故障報警、系統(tǒng)自診斷報警、電源故障報警、通信故障報警、網(wǎng)絡(luò)故障報警。這些報警要分優(yōu)先級泄漏和壓力驟降最高通信故障和電池低電次之。報警產(chǎn)生后除了彈窗還要寫事件表記錄報警開始時間、恢復(fù)時間、確認人、處理措施否則后續(xù)事故追溯時查不到原始數(shù)據(jù)。3.3 巡檢管理與泄漏監(jiān)測從人工登記到移動化閉環(huán)管網(wǎng)安全不能只靠 SCADA 點上的傳感器巡檢還是要走人。平臺做巡檢管理重點不是把紙質(zhì)表單電子化而是把“誰在什么時候巡了哪個點、發(fā)現(xiàn)了什么問題、怎么處理”這件事閉環(huán)起來。巡線人員、車載檢測設(shè)備、小區(qū)手持巡檢設(shè)備都會產(chǎn)生 GPS 軌跡和現(xiàn)場記錄平臺利用 GPS 智能定位做抄表路徑回放也能對漏巡、超時、偏離路線給出提示。日常排班中巡檢任務(wù)生成規(guī)則是“風(fēng)險等級越高巡檢間隔越短”。下面的 SQL 按風(fēng)險等級和上次巡檢時間篩選出今日必須執(zhí)行的點位-- 根據(jù)上次巡檢時間和風(fēng)險等級生成今日任務(wù) 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表示高風(fēng)險點HAVING后面篩選出 7 天內(nèi)沒巡過的點位。實際生產(chǎn)中還應(yīng)該帶上區(qū)域劃分避免任務(wù)跨區(qū)分配。燃氣巡檢不能只看地上還要覆蓋工商業(yè)用戶、居民小區(qū)、地下密閉空間、管網(wǎng)連接處這些容易漏氣的位置。陰極保護監(jiān)測則是通過外加電流讓金屬管道做陰極抑制電化學(xué)腐蝕這里的關(guān)鍵參數(shù)是電位值要按管道材料設(shè)定正常范圍低于保護電位就要檢查恒電位儀。4. 大數(shù)據(jù)分析與供銷差治理用氣負荷預(yù)測、壓力調(diào)配與異常檢測4.1 多節(jié)點氣量數(shù)據(jù)匯聚門站、管線、表具的數(shù)據(jù)粒度與存儲智慧燃氣平臺真正有價值的部分是把門站供應(yīng)量、管線節(jié)點壓力、用戶表計用氣量拉到一起做分析。三類數(shù)據(jù)粒度差別很大SCADA 數(shù)據(jù)是分鐘級甚至秒級用戶表計是每日凍結(jié)值門站和調(diào)壓站則按小時匯總。直接混在一起算會造成口徑混亂所以建議分三層存儲明細層、匯總層、指標(biāo)層。明細層適合用 ClickHouse 這類列式數(shù)據(jù)庫做歸檔查詢尤其適合按用戶、按日期聚合。下面以分布式表為例分布鍵用user_id保證同一個表計的數(shù)據(jù)落到同一個分片查詢時不需要跨節(jié)點合并-- ClickHouse 分布式表按天分區(qū)氣量明細 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); -- 創(chuàng)建分布式視圖集群名按實際環(huán)境調(diào)整 CREATE TABLE gas.meter_readings AS SELECT * FROM gas.meter_readings_local ENGINE Distributed(cluster_name, gas, meter_readings_local, cityHash64(user_id));建表時要注意delta字段是當(dāng)日用氣量不是累計值否則聚合時會把同一個分區(qū)內(nèi)的累計值疊加。數(shù)據(jù)導(dǎo)入鏈路一般走 Kafka表具平臺或 IoT 平臺上報的消息直接進 Kafka topic再由寫入程序消費到 ClickHouse。大數(shù)據(jù)集群部署策略上先保證分片數(shù)和副本數(shù)的倍數(shù)關(guān)系不要盲目擴大分片否則小查詢也要走分布式節(jié)點反而變慢。4.2 高峰低谷統(tǒng)計與輸配管線壓力調(diào)配調(diào)度中心關(guān)注的不是單塊表而是整個城市或區(qū)域的負荷曲線。用氣高峰通常出現(xiàn)在早晚做飯時段冬季采暖期還會疊加低溫和節(jié)假日效應(yīng)。平臺后臺通過高峰低谷統(tǒng)計可以提前發(fā)現(xiàn)某個片區(qū)的用氣量是否逼近管網(wǎng)輸配能力然后安排調(diào)整調(diào)壓站出口壓力或啟用儲氣設(shè)施調(diào)峰。負荷預(yù)測不一定要上很復(fù)雜的深度學(xué)習(xí)模型很多場景用歷史同期均值就夠用。我一般先用 28 天的小時級數(shù)據(jù)做基線預(yù)測再根據(jù)氣溫修正如果效果不夠再上 LSTM 或 Prophet。下面是基線預(yù)測的最小實現(xiàn)# load_forecast.py - 基于歷史同時段均值的用氣高峰預(yù)測 import pandas as pd def forecast_hourly_usage(history: pd.DataFrame, target_date: str, hour: int) - float: # history 至少包含 4 周的小時級數(shù)據(jù)字段: date, hour, usage sample history[ (history[hour] hour) (history[date] target_date) ].tail(28) return float(sample[usage].mean())這個函數(shù)只預(yù)測了單小時值實際調(diào)度系統(tǒng)需要連續(xù)預(yù)測未來 24 小時曲線并且每個預(yù)測值都附帶置信區(qū)間。當(dāng)預(yù)測值超過調(diào)壓站額定輸氣能力 90% 時系統(tǒng)應(yīng)生成預(yù)報警調(diào)度員可以提前下級調(diào)壓指令。預(yù)測模型上線后要保留預(yù)測值和實際值的對比日志定期計算平均絕對誤差模型效果差就回滾到基線。4.3 供氣平衡與跑冒滴漏偷排查供銷差分析與異常檢測供銷差率是燃氣公司的核心經(jīng)營指標(biāo)之一。簡單說就是門站購入的總氣量和通過用戶表計賣出去的氣量之差。正常誤差包括管道降壓、溫度壓力補償、表具計量偏差異常原因包括管線泄漏、偷氣、表具故障、抄表不及時。供銷差率持續(xù)偏高平臺就需要從空間和時間兩個維度定位異常區(qū)域。設(shè)計上先按日計算區(qū)域供銷差率再對比周邊區(qū)域和自身歷史值。下面是按日匯總的 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必須使用同一時間口徑否則會出現(xiàn)虛假的供銷差。理想狀態(tài)是門站的日指定量和用戶日凍結(jié)抄表數(shù)據(jù)都按當(dāng)?shù)亓泓c結(jié)算。發(fā)現(xiàn)某一區(qū)域連續(xù) 3 天供銷差率超過閾值就自動生成異常工單派巡檢車巡線排查結(jié)合 GIS 定位還能優(yōu)先檢查異常區(qū)域內(nèi)的老舊管線、第三方施工點、廢棄管段。5. 平臺兼容性與部署技巧存量收費系統(tǒng)對接、調(diào)價預(yù)案與可視化驗收5.1 與原有收費系統(tǒng)兼容接口冪等與對賬燃氣公司已經(jīng)有收費系統(tǒng)智慧燃氣數(shù)據(jù)云平臺不能完全替代它更多時候要雙向同步。對接時最容易出問題的是重復(fù)計費所以要保證接口冪等。常見做法是增加“請求唯一鍵”比如賬單月用戶ID收到重復(fù)請求直接返回已處理app.post(/api/v1/billing/sync) def sync_billing(): payload request.json # 冪等鍵月賬單號用戶ID重復(fù)請求不重復(fù)入賬 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實現(xiàn)防重ex3600表示一小時內(nèi)重復(fù)請求不會再次創(chuàng)建賬單。每天凌晨還需要跑一次對賬任務(wù)比較智慧燃氣平臺的應(yīng)收金額和原收費系統(tǒng)的實收金額差異記錄寫入對賬差異表由財務(wù)人工查看。5.2 遠程調(diào)價與階梯氣價設(shè)置的運維預(yù)案政府調(diào)價公告發(fā)布后平臺要在當(dāng)天完成價格切換。遠程調(diào)價不能只改一個單價字段要按下面的方式操作并保留回滾手段操作步驟回滾調(diào)價維護新價格版本 - 設(shè)置生效時間 - 試算典型用戶賬單 - 發(fā)布停用新版本舊版本立即生效階梯氣價設(shè)置配置階梯邊界和單價 - 按戶測算法生成模擬賬單 - 發(fā)布重新生成賬單并沖銷試算步驟尤其重要。發(fā)布前從用戶表里抽取居民、工商業(yè)、混合用氣三類典型用戶用新價格跑一次賬單確認金額沒有躍變。歷史賬單不能回算只能記錄價格版本號后續(xù)審計時按版本號追溯。5.3 可視化大屏與驗收指標(biāo)項目上線前數(shù)據(jù)可視化大屏是領(lǐng)導(dǎo)最直觀的感受來源但驗收不能只看大屏好看。我一般把下面幾項作為驗收硬指標(biāo)GIS 圖層能正確加載管線段、閥井、場站圖標(biāo)SCADA 壓力、流量刷新延遲小于 5 秒斷開某個表具通訊后1 分鐘內(nèi)產(chǎn)生告警隨機抽取 100 個用戶自動抄表成功率不低于 98%智慧燃氣平臺與舊收費系統(tǒng)當(dāng)日對賬金額差異為 0。還有一個容易忽略的點大屏的數(shù)據(jù)刷新接口要和業(yè)務(wù)系統(tǒng)分離避免大屏高頻輪詢把生產(chǎn)數(shù)據(jù)庫拖垮前端直接用 Redis 緩存或獨立的查詢庫。本文還有配套的精品資源點擊獲取