简介这份行业报告聚焦城市燃气领域的数字化运营实践面向燃气企业管理者、公共事业研究者及数字化转型从业者以北京市燃气集团为样本梳理从战略规划到落地执行的完整路径。内容涵盖数字化转型的演进阶段、企业面临的客户服务与运营管理挑战、分布式云端架构对传统集中式分层架构的替代以及智能决策、智慧运营、智能管网、智能服务四大方向的构建逻辑并延伸至行业云平台的SaaS、PaaS、IaaS服务能力与物联网平台架构。资源包为1个PDF文件约4MB结构清晰、图文并茂便于按目录模块快速检索与研读。目前已有109人学习下载。读者可从中获取燃气企业数字化转型模型、业务模式创新思路与平台建设参考框架适合作为战略研讨、方案撰写与项目立项的案头资料。1. 城市燃气数字化运营实践从SCADA孤岛到调度闭环中间隔着什么很多燃气公司的数字化起点是一张画得很漂亮的管网GIS图外加几套各自为政的SCADA、巡检、客服系统。调度中心大屏上数据在跳但真到了冬季用气高峰、某条中压管线压力异常波动的时候值班人员还是得靠电话挨个问场站、翻微信群里的巡检照片。问题不在于没有数据而在于数据没有连成一条能支撑决策的链路。城市燃气数字化运营实践这件事核心不是买一套新平台而是把「采集—传输—存储—分析—调度指令—执行反馈」这条闭环打通让压力、流量、温度、报警这些量从孤立的测点变成可追溯、可联动、可回算的运营资产。它适合管网规模在几百到几千公里、已有一定自动化基础但数据利用率低的城燃运营团队也适合刚接手调度信息化、需要判断从哪切入的工程师。下面按我实际趟过的路径把选型、落地、参数和坑讲清楚。2. 先想清楚数据从哪来城燃数字化的采集层选型与接入2.1 三类数据源的优先级排序城燃运营的数据源看着杂其实按「对调度决策的贡献度」能排出明确优先级。第一类是场站和调压站的SCADA实时量包括进出口压力、瞬时流量、温度、阀位状态这类数据采样周期通常在1到5秒是调度的主依据。第二类是管网沿线的压力监测点很多是后来加装的无线压力变送器采样周期从1分钟到15分钟不等用来做区域压力分布和泄漏辅助判断。第三类是巡检、维修、安检产生的业务数据本质是事件流时间戳精度到分钟就够但必须和空间位置绑定。我一般建议先接第一类因为它的接口最规范多数场站RTU支持Modbus TCP或IEC 104接进来就能用。第二类要看无线变送器的通信协议常见的是MQTT上报到某个物联网平台再通过订阅拿数据。第三类最容易被忽略但它决定了报警之后能不能追到「谁在什么时候到过现场」是闭环的最后一环。提示不要一上来就追求全量接入。先把一个调压站群和一个区域压力监测网接进来跑通比铺开二十个站但数据质量失控要值。2.2 用Python写一个Modbus TCP采集的最小可跑脚本下面这段代码是我在验证场站数据接入时常用的最小骨架基于pymodbus把保持寄存器的值读出来并按工程单位换算。实际部署时会把它包成常驻服务这里先保证能跑通。from pymodbus.client import ModbusTcpClient import time import struct # 场站RTU的IP和端口实际按现场配置改 RTU_IP 192.168.10.21 RTU_PORT 502 UNIT_ID 1 # 寄存器地址映射不同厂家差异很大必须对照点表 # 这里假设 40001 起为压力40003 起为流量均为32位浮点占两个寄存器 REG_PRESSURE 0 REG_FLOW 2 def read_float(client, addr): # 读两个保持寄存器大端拼接成float rr client.read_holding_registers(addr, 2, slaveUNIT_ID) if rr.isError(): return None raw struct.pack(HH, rr.registers[0], rr.registers[1]) return struct.unpack(f, raw)[0] def main(): client ModbusTcpClient(RTU_IP, portRTU_PORT, timeout3) if not client.connect(): print(连接失败检查网络和端口) return while True: p read_float(client, REG_PRESSURE) f read_float(client, REG_FLOW) # 压力单位按点表可能是MPa或kPa这里假设原始为MPa print(f压力{p:.3f} MPa 流量{f:.2f} Nm3/h) time.sleep(5) client.close() if __name__ __main__: main()逻辑上read_holding_registers的第二个参数是寄存器数量32位浮点必须读2个少读一个会拿到半个数。struct.pack(HH, ...)里的表示大端很多RTU默认大端但西门子部分设备是小端接上后数值明显离谱就要换。slaveUNIT_ID对应从站地址现场如果经过网关从站号可能被网关改写要以网关配置为准。超时设3秒是经验值太短会在网络抖动时频繁断连太长会让采集循环卡住。2.3 无线压力监测点走MQTT接入的注意点无线压力变送器一般通过NB-IoT或4G上报到物联网平台平台再以MQTT主题推给应用。接入时最容易翻车的是主题层级设计。常见做法是gas/{region}/{device_id}/telemetryregion用区域编码device_id用设备序列号。订阅时用通配符gas///telemetry能一次拿全但要注意消息体里的时间戳是设备本地时间还是UTC很多设备默认本地时间且不带时区入库前必须统一。参数上QoS建议用1保证至少一次送达代价是可能重复所以入库时要按device_id timestamp做去重。心跳间隔和上报间隔要分开配置心跳可以30秒上报按压力变化触发或固定5分钟纯固定间隔在夜间会浪费大量流量。3. 数据存下来只是第一步时序库选型与管网拓扑建模3.1 时序数据库选型别用关系库硬扛场站按5秒一个点一个站20个测点100个站一天就是三千多万条记录。用MySQL存单表很快到亿级查询最近一小时的压力曲线都要几秒。常见做法是上时序库InfluxDB和TDengine是城燃场景里出现频率较高的两个。InfluxDB生态好、查询语言Flux功能强但集群版是商业授权TDengine单机性能好、对SQL友好建库建表逻辑贴近传统习惯中小规模城燃用单机加副本就够。选型时看三个指标写入吞吐、按时间范围加标签的查询延迟、降采样能力。写入吞吐决定你能不能全量存原始点查询延迟决定调度大屏刷不刷得动降采样决定你能不能把一年前的秒级数据压成分钟级长期保留。我一般会先拿一周的真实数据做压测别信厂商标称值。3.2 管网拓扑建模把「谁连着谁」说清楚时序数据只回答「某个点在某时刻是多少」调度还需要「这个点在上游还是下游、关了哪个阀会影响哪些区域」。这就是拓扑建模。城燃管网拓扑的核心元素是节点和管段节点包括场站、调压站、阀室、用户接入点管段连接两个节点带管径、材质、长度属性。建模时最容易偷懒的是把GIS里的折线直接当管段结果一条管线被切成几百段拓扑关系碎得没法用。正确做法是按「两个可操作阀门之间」为一段来抽象段内不再细分。这样一段就是一个可独立隔离的单元调度指令下发时目标明确。-- TDengine中建一张管段表记录拓扑和属性 CREATE TABLE pipe_segment ( seg_id NCHAR(32), from_node NCHAR(32), to_node NCHAR(32), diameter_mm INT, material NCHAR(16), length_m FLOAT, create_time TIMESTAMP ); -- 建一张节点表 CREATE TABLE node ( node_id NCHAR(32), node_type NCHAR(16), -- station/regulator/valve/user region_code NCHAR(16), geom NCHAR(64) );seg_id用有意义的编码而不是自增方便和GIS对账。node_type决定这个节点在调度里能不能下发指令阀室和调压站可以普通用户接入点不行。region_code是后面做区域压力聚合的分组键一定要在建模阶段就填对后期补数据非常痛苦。3.3 用连续查询做分钟级降采样原始秒级数据保留30天分钟级保留2年是城燃比较务实的策略。TDengine里可以用流计算或定时任务做降采样。-- 每5分钟把原始压力点聚合成均值、最大、最小 CREATE STREAM pressure_5min INTO pressure_5min_stb AS SELECT _wstart, AVG(pressure) AS avg_p, MAX(pressure) AS max_p, MIN(pressure) AS min_p FROM telemetry WHERE type pressure PARTITION BY device_id INTERVAL(5m);INTERVAL(5m)是窗口大小PARTITION BY device_id保证每个设备独立聚合。_wstart是窗口起始时间作为降采样表的时间戳。注意流计算是持续运行的如果原始数据有迟到网络补传窗口已经关闭的数据不会自动重算所以补传数据要走单独的修正流程不能指望流计算兜底。4. 从数据到调度指令报警规则与工单闭环怎么搭4.1 报警规则不能只设阈值最朴素的报警是「压力低于0.2MPa就报」但城燃管网压力本身随用气量波动夜间普遍偏高、饭点偏低固定阈值要么误报要么漏报。常见做法是引入动态基线用过去7天同一时段的压力均值加减两倍标准差作为上下限超出才报。这样能过滤掉正常的日周期波动。规则引擎选型上轻量场景用Python加规则表就能跑复杂场景上Flink CEP。我一般先用规则表验证逻辑规则表结构大概是规则ID、测点匹配表达式、条件表达式、持续时间、报警等级、通知对象。持续时间这个字段很关键压力瞬间抖动0.5秒不该报持续30秒才报能砍掉大量噪声。# 简化的动态基线报警判断 import statistics def check_pressure(device_id, current, history_7d): # history_7d 是过去7天同一时段的历史值列表 if len(history_7d) 10: return None # 样本不足不判断 mu statistics.mean(history_7d) sigma statistics.pstdev(history_7d) upper mu 2 * sigma lower mu - 2 * sigma if current upper: return (HIGH, upper, lower) if current lower: return (LOW, upper, lower) return Nonehistory_7d的取法要注意不是取过去7天全部数据而是取「同一时段」比如当前是周二上午10点就取过去7个周二9点到11点的数据。样本少于10个时不判断避免新装设备一上来就误报。两倍标准差是经验值误报多就放宽到2.5倍漏报多就收紧到1.5倍按现场反馈调。4.2 工单闭环报警之后必须有人接报警发出去没人处理等于没报。工单闭环要解决三件事派给谁、多久响应、处理结果怎么回填。派单规则按区域加专业分组比如A区域调压站报警派给A区域运维组管网压力异常派给调度加巡线。响应时限按等级分一级报警15分钟响应二级1小时三级4小时。工单状态机建议用「待接单—处理中—待复核—已关闭」四态不要搞太多状态现场人员记不住。回填时强制要求填处理措施和现场照片照片带GPS水印这样调度能确认人确实到了现场。这一步是很多项目翻车的地方系统上线了工单也派了但现场用微信回系统里状态永远停在处理中闭环断在最后一米。4.3 调度指令下发与执行反馈对于有远程控制能力的调压站调度可以直接下发阀位调整指令。指令下发必须走「预下发—确认—执行—回读」四步不能一键直达。预下发是把目标值和当前值展示给调度确认确认后写入指令队列执行后回读实际阀位和目本文还有配套的精品资源点击获取