简介这份PPT面向油气行业信息化建设者、油田数字化项目负责人及物联网方案设计人员系统梳理了智慧油气物联云平台的整体架构与落地路径帮助解决井场、厂站、管线到车船各环节数据采集分散、远程通信不畅、生产管理粗放等实际问题。资源包为单一PPT文件压缩包约40.93MB内容以方案架构图、设备清单与案例说明为主便于直接用于项目汇报或技术选型参考。目前已有47人学习下载。方案按系统、集成、可选三层展开系统层覆盖采油、注入、采气、水源井等井型与各类场站并给出光缆、无线网桥、公网等远程通信建设原则集成层聚焦电功图、地面功图与电功图综合应用配合无线角位移、载荷、压力、温度传感器及RTU实现工况诊断、产量计算与能源管理可选层强调软硬分离、集成简单、安装方便并延伸至液面测试、变频控制、可燃气体监测与视频联动。成功案例进一步说明该平台既适用于新建项目也可用于既有设施升级改造为提升生产效率、保障作业安全与降低运营成本提供可落地的技术支撑。1. 智慧油气物联云平台到底在解决什么问题如果你在油田现场待过大概见过这样的场景采油树上的压力变送器还在用 4-20mA 硬线往 RTU 里接示功图靠人工抄录注水间的流量计各报各的数生产调度会上三个部门拿出来的产量数据对不上。智慧油气物联云平台要干的事就是把这些散落在井口、计量间、联合站的设备统一接进来让数据自动流转、让异常主动报警、让生产指标能在一个屏幕上对齐。它和通用工业物联网平台的区别在于油气场景的协议特别杂Modbus、OPC UA、IEC 104、MQTT、甚至私有串口协议同时存在现场网络条件差很多井场只有 4G 或微波安全等级要求高生产数据不能随便出内网。所以一套能落地的智慧油田云平台核心不是把数据堆到云上而是解决边缘侧怎么采、网络断了怎么办、云端怎么建模、业务怎么用起来这条链路。这篇内容适合正在做油气数字化选型的架构师、负责井场数据采集的自动化工程师以及想把现有 SCADA 往云平台迁移的运维团队。2. 从井口到云端智慧油田云平台的四层架构怎么搭2.1 边缘采集层协议转换和断网续传是硬需求井场的设备不会因为你上了云平台就统一协议。我见过一个区块抽油机控制器走 Modbus RTU注水流量计走 Modbus TCP变频柜走 Profibus还有一个老站的 RTU 只支持 IEC 104。边缘网关的第一件事就是把这些协议统一成 MQTT 往上送。常见做法是在井场部署一台工业边缘网关跑协议转换和本地缓存。下面是一个用 Python 写的 Modbus 采集转 MQTT 的最小示例跑在边缘网关上from pymodbus.client import ModbusTcpClient import paho.mqtt.client as mqtt import json, time, sqlite3 # 本地 SQLite 做断网缓存网络恢复后补传 conn sqlite3.connect(/data/cache.db) conn.execute(CREATE TABLE IF NOT EXISTS cache (ts INTEGER, payload TEXT)) def read_and_publish(): client ModbusTcpClient(192.168.1.10, port502) client.connect() # 读取保持寄存器地址和数量按设备手册改 rr client.read_holding_registers(address0, count10, slave1) data { well_id: J-023, oil_pressure: rr.registers[0] / 100.0, # 寄存器值除以100得MPa casing_pressure: rr.registers[1] / 100.0, temperature: rr.registers[2] / 10.0, # 除以10得摄氏度 ts: int(time.time()) } payload json.dumps(data) try: mqtt_client.publish(foilfield/well/J-023/data, payload, qos1) except Exception: # 发布失败写入本地缓存后台线程定时补传 conn.execute(INSERT INTO cache VALUES (?, ?), (data[ts], payload)) conn.commit() client.close()这段代码的关键参数有三个address和count必须对照设备点表不同厂家寄存器映射完全不同slave是 Modbus 从站地址现场经常一台网关挂多个从站qos1保证消息至少送达一次油气生产数据丢一个点可能影响功图诊断。断网缓存用 SQLite 而不是内存队列是因为井场断电重启后内存数据全丢SQLite 能扛住。2.2 网络传输层4G、微波和光纤怎么选井场到站控中心的链路选择直接决定云平台能不能用。光纤最稳但铺设成本高适合联合站到中心机房4G 覆盖好但延迟抖动大适合单井数据回传微波适合偏远区块但受天气影响。我的经验是单井用 4G计量间用光纤偏远区块用微波加 4G 双链路备份。MQTT Broker 的部署位置也有讲究。如果所有数据都往公有云送井场 4G 流量费用会很高而且生产数据出内网有合规风险。常见做法是在站控中心部署一套 EMQX 或 Mosquitto 做本地 Broker边缘网关先发到本地再由本地 Broker 桥接到云端。这样即使云端断了本地生产监控不受影响。2.3 平台服务层设备模型和时序数据怎么组织数据到了云端第一件事不是存是建模。智慧油气云平台的设备模型一般分三层产品如抽油机、设备如 J-023 井、测点如油压、套压、温度。这个模型决定了后面数据怎么查、告警怎么配、报表怎么出。时序数据存储选型上InfluxDB 和 TDengine 是油气场景用得比较多的。TDengine 的优势是自带超级表概念按井号建子表查询某口井某段时间的数据很快。下面是一个建库建表的 SQL 示例-- 创建数据库保留365天副本数1单节点测试环境 CREATE DATABASE oilfield KEEP 365 DAYS 1; -- 创建超级表按井号做标签 USE oilfield; CREATE STABLE well_data ( ts TIMESTAMP, oil_pressure FLOAT, casing_pressure FLOAT, temperature FLOAT, current FLOAT ) TAGS ( well_id NCHAR(32), block NCHAR(32) ); -- 为J-023井创建子表 CREATE TABLE well_j023 USING well_data TAGS (J-023, block_a);KEEP 365 DAYS表示数据保留一年油气生产数据通常要求至少存一年有些区块要求三年。TAGS里的well_id和block是标签查询时按标签过滤比按时间过滤快得多。子表按井号自动创建边缘网关上报数据时 TDengine 会自动建表不用手工维护。2.4 业务应用层从数据到产量的最后一公里平台搭好了业务人员不会直接查数据库。智慧油田云平台最终要输出的是实时生产监控大屏、功图诊断、产量计量、报警推送、报表导出。这些应用不用从零写常见做法是基于平台提供的 API 做二次开发。比如功图诊断边缘侧采集位移和载荷数据云端用深度学习模型判断泵况。这里就涉及热词里提到的深度学习云平台——模型训练可以在 GPU 云平台上做推理部署到边缘或云端。但要注意油气场景的样本量通常不大一个区块几百口井标注数据更少直接用大模型容易过拟合我一般先用传统方法做特征提取再用轻量模型分类。3. 智慧油气云平台部署从单机测试到生产环境的参数怎么调3.1 用 Docker Compose 在本地跑通最小平台选型阶段不建议直接上 Kubernetes先用 Docker Compose 把核心组件跑起来验证数据链路通不通。下面是一个最小化的 compose 文件包含 MQTT Broker、TDengine 和一个简单的数据写入服务version: 3.8 services: emqx: image: emqx/emqx:5.3 ports: - 1883:1883 # MQTT端口 - 18083:18083 # 管理后台 environment: - EMQX_ALLOW_ANONYMOUSfalse volumes: - ./emqx_data:/opt/emqx/data tdengine: image: tdengine/tdengine:3.2 ports: - 6030:6030 # 客户端连接端口 - 6041:6041 # REST端口 environment: - TAOS_FQDNtdengine volumes: - ./taos_data:/var/lib/taos >import paho.mqtt.client as mqtt import json, time # Onenet MQTT 接入参数产品ID和设备密钥在控制台获取 PRODUCT_ID your_product_id DEVICE_NAME J-023 DEVICE_KEY your_device_key MQTT_HOST mqtts.heclouds.com MQTT_PORT 1883 # 上报主题格式$sys/{pid}/{device}/dp/post/json pub_topic f$sys/{PRODUCT_ID}/{DEVICE_NAME}/dp/post/json # 命令下发订阅主题 sub_topic f$sys/{PRODUCT_ID}/{DEVICE_NAME}/cmd/request/# def on_connect(client, userdata, flags, rc): print(connected with result code, rc) client.subscribe(sub_topic, qos1) def on_message(client, userdata, msg): # 收到云端下发命令解析后执行 print(command received:, msg.payload.decode()) cmd json.loads(msg.payload.decode()) if cmd.get(action) set_report_interval: new_interval cmd.get(value, 60) print(fadjust report interval to {new_interval}s) client mqtt.Client(client_idDEVICE_NAME) client.username_pw_set(PRODUCT_ID, DEVICE_KEY) client.on_connect on_connect client.on_message on_message client.connect(MQTT_HOST, MQTT_PORT, 60) client.loop_start() while True: payload { oil_pressure: 2.35, casing_pressure: 1.80, temperature: 45.2 } client.publish(pub_topic, json.dumps(payload), qos1) time.sleep(10)client_id用设备名Onenet 要求设备名唯一。username_pw_set的第一个参数是产品 ID第二个是设备密钥不是账号密码。上报主题里的dp/post/json是 Onenet 的数据点上报格式换成自建 EMQX 时主题可以自定义比如oilfield/well/J-023/data。命令下发订阅主题用通配符#接收所有命令实际部署时要按命令类型细分。5.3 从 Onenet 迁移到自建平台要改什么验证通过后迁移到自建平台设备侧只需要改三个地方Broker 地址从mqtts.heclouds.com改成自己的 EMQX 地址认证方式从产品 ID 设备密钥改成用户名密码或证书主题格式从 Onenet 的$sys/前缀改成自定义格式。云端侧要把 Onenet 的数据流转规则换成自己的数据桥接服务。我一般会在边缘网关上做一个配置开关platformonenet或platformself切换时只改配置不改代码。这样选型阶段用 Onenet 快速验证生产环境切自建平台两边都能跑。5.4 一个容易忽略的细节时间同步设备上报的数据带时间戳如果边缘网关的时间不准云端存储的时序数据就会错乱。我遇到过网关重启后时间回到 1970 年导致 TDengine 写入报错。解决办法是在边缘网关上配 NTP 客户端启动时先同步时间再开始采集。如果现场没有 NTP 服务器可以用云端下发时间同步命令网关收到后校准本地时钟。这个细节看起来小但油气生产数据的时间戳直接影响功图对齐和产量计算翻车成本很高。我现在做新项目边缘网关上线第一件事就是检查时间同步确认无误再开采集。希望这些经验帮到你。本文还有配套的精品资源点击获取