企业官网建设流程全解析

简介：这份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', port=502) client.connect() # 读取保持寄存器，地址和数量按设备手册改 rr = client.read_holding_registers(address=0, count=10, slave=1) 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(f"oilfield/well/J-023/data", payload, qos=1) except Exception: # 发布失败写入本地缓存，后台线程定时补传 conn.execute('INSERT INTO cache VALUES (?, ?)', (data["ts"], payload)) conn.commit() client.close()

这段代码的关键参数有三个：address和count必须对照设备点表，不同厂家寄存器映射完全不同；slave是 Modbus 从站地址，现场经常一台网关挂多个从站；qos=1保证消息至少送达一次，油气生产数据丢一个点可能影响功图诊断。断网缓存用 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_ANONYMOUS=false volumes: - ./emqx_data:/opt/emqx/data tdengine: image: tdengine/tdengine:3.2 ports: - "6030:6030" # 客户端连接端口 - "6041:6041" # REST端口 environment: - TAOS_FQDN=tdengine 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, qos=1) 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(f"adjust report interval to {new_interval}s") client = mqtt.Client(client_id=DEVICE_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), qos=1) 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 的数据流转规则换成自己的数据桥接服务。

我一般会在边缘网关上做一个配置开关，platform=onenet或platform=self，切换时只改配置不改代码。这样选型阶段用 Onenet 快速验证，生产环境切自建平台，两边都能跑。

5.4 一个容易忽略的细节：时间同步

设备上报的数据带时间戳，如果边缘网关的时间不准，云端存储的时序数据就会错乱。我遇到过网关重启后时间回到 1970 年，导致 TDengine 写入报错。解决办法是在边缘网关上配 NTP 客户端，启动时先同步时间再开始采集。如果现场没有 NTP 服务器，可以用云端下发时间同步命令，网关收到后校准本地时钟。

这个细节看起来小，但油气生产数据的时间戳直接影响功图对齐和产量计算，翻车成本很高。我现在做新项目，边缘网关上线第一件事就是检查时间同步，确认无误再开采集。希望这些经验帮到你。

本文还有配套的精品资源，点击获取