MQTT für die Fernüberwachung in Öl und Gas über Mobilfunk und Satellit

MQTT ist in Öl und Gas zu einem Standardweg geworden, Bohrlochköpfe, Pipelines, Verdichterstationen und Tanklager zu überwachen, die weit entfernt von jeder Glasfaser liegen. Sein Report-by-Exception-Modell, kleine Pakete und die Toleranz gegenüber unzuverlässigen Verbindungen passen zu den Realitäten von Mobilfunk- und Satelliten-Backhaul. In diesem Leitfaden erfahren Sie, wie Sie eine Fernüberwachung mit MQTT aufbauen, welche Einstellungen für Keep Alive, Session und QoS auf teuren Strecken funktionieren und wie Sie einen Edge-Publisher bauen, der die Bandbreite niedrig hält, ohne wichtige Ereignisse zu verlieren.

Warum entlegene Öl- und Gasanlagen zu MQTT passen

Upstream- und Midstream-Anlagen teilen eine Reihe von Einschränkungen, die klassisches Polling mühsam machen:

• Teure oder begrenzte Bandbreite. Satelliten- und manche Mobilfunktarife rechnen pro Byte ab oder haben enge Datenvolumen. Unveränderte Werte alle paar Sekunden zu pollen, verschwendet Geld.
• Hohe Latenz. Round-Trips über geostationäre Satelliten sind lang, sodass ein Master, der Hunderte Standorte nacheinander pollt, sehr langsame Scanzyklen erreicht.
• Unterbrochene Konnektivität. Wetter, Stromversorgung und Netzabdeckung verursachen Ausfälle, die das Telemetriesystem überstehen muss, ohne Alarme zu verlieren.
• Energiebudgets. Solarbetriebene RTUs und Gateways wollen das Funkmodul so oft wie möglich im Ruhezustand halten.
• Sicherheitsrisiken. Entlegene Standorte sind physisch zugänglich und verbinden sich über öffentliche Netze.

MQTT adressiert diese Punkte direkt. Feldgeräte öffnen eine ausgehende TLS-Verbindung und halten sie, veröffentlichen nur relevante Änderungen und überlassen dem Broker die Verteilung an SCADA, Historians und Analysen. Der Leitfaden zu MQTT in SCADA-Systemen erklärt diesen Wechsel weg vom Polling ausführlicher.

Referenzarchitektur

Eine typische MQTT-Architektur für Öl und Gas hat vier Schichten:

1. Feldinstrumente und Steuerungen. Durchflussrechner, Druck- und Temperaturtransmitter, Radar-Füllstandsmessung, Pumpensteuerungen, ESD-Systeme, die lokal meist Modbus oder ein Herstellerprotokoll sprechen.
2. Edge-Gateway oder RTU. Liest lokale Geräte, wendet Totbänder an, versieht Werte mit Zeitstempeln, puffert bei Ausfällen und veröffentlicht per MQTT. Oft als Sparkplug B für die SCADA-Kompatibilität.
3. Backhaul. Mobilfunk (LTE, LTE-M), lizenzierter oder lizenzfreier Funk oder Satellit (geostationär oder im erdnahen Orbit).
4. Broker und Konsumenten. Ein zentraler Broker mit SCADA-Hosts, Historians, Produktionsabrechnung und Leckerkennungssystemen als Abonnenten.

Strukturieren Sie die Topics auf dem zentralen Broker von Anfang an als Unified Namespace (UNS). Die ISA-95-Hierarchie (Enterprise, Site, Area, Line, Cell) lässt sich direkt auf Feld, Bohrplatz, Bohrung und Messstelle übertragen, etwa acme/feld-nord/bohrplatz-12/bohrung-3/steigrohrdruck. So finden SCADA, Historian und Abrechnung jeden Wert an einer vorhersehbaren Stelle, und neue Standorte fügen sich ohne Umbau ein. Wie Sparkplug B und UNS zusammenspielen, zeigt der Beitrag zu Sparkplug B und Unified Namespace.

Halten Sie Sicherheitsfunktionen lokal. Notabschaltung und Druckabsicherung dürfen niemals von der Verbindung oder dem Broker abhängen; MQTT transportiert Überwachungsdaten und, wo genehmigt, ausschließlich überwachende Befehle.

MQTT für Mobilfunk- und Satellitenstrecken abstimmen

Die Standardeinstellungen der meisten MQTT-Bibliotheken gehen von einem LAN aus. Auf entlegenen Strecken entscheiden einige Parameter über ein zuverlässiges oder ein unruhiges, teures System.

Keep Alive und NAT-Timeouts

Mobilfunkprovider setzen Geräte hinter Carrier-Grade-NAT, das untätige TCP-Verbindungen nach einer vom Provider festgelegten Zeit verwirft. Ist Ihr Keep Alive länger, stirbt die Verbindung stillschweigend, und das Gerät merkt es erst, wenn sein nächstes Publish fehlschlägt. Messen Sie es: Beginnen Sie mit 120 Sekunden, achten Sie im Verbindungsprotokoll des Brokers auf unerklärliche Wiederverbindungen und verkürzen Sie, bis sie aufhören. Berücksichtigen Sie auf Satellitenstrecken außerdem die langen Round-Trips bei der Wahl des Ping-Timeouts des Clients.

Report by Exception für Bohrlochkopfdaten

Ein Steigrohrdruck, der um 0,1 Prozent schwankt, muss nicht über einen Satelliten. Legen Sie Totbänder pro Tag anhand der Messgenauigkeit und der betrieblichen Relevanz fest, veröffentlichen Sie digitale Zustände und Alarme bei jeder Änderung und senden Sie alle 15 bis 60 Minuten eine vollständige Aktualisierung als Lebenszeichen. Der Leitfaden zu Report by Exception behandelt die Wahl der Totbänder, und Store-and-Forward für MQTT erklärt, wie Sie Daten über Ausfälle hinweg puffern und nachsenden.

Beispiel: Ein bandbreitenbewusster Edge-Publisher

Dieser Python-Publisher nutzt MQTT 5 mit persistenter Session, kurzen JSON-Schlüsseln, Totbändern pro Tag, einem Heartbeat, Message Expiry für weniger wichtige Daten und exponentiellem Reconnect-Backoff. Ersetzen Sie read_instruments() durch Ihre Lesezugriffe auf Modbus oder den Durchflussrechner.

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties

# Öffentlicher MQTT-Broker für das Labor: für jeden lesbar, daher nur simulierte Daten verwenden.
BROKER, PORT, USE_TLS = "broker.connectmq.com", 1883, False
USERNAME, PASSWORD = None, None                     # Produktion: "YOUR_USERNAME", "YOUR_PASSWORD"
CLIENT_ID = f"wellpad-{uuid.uuid4().hex[:8]}"       # Produktion: "YOUR_CLIENT_ID"
BASE = f"connectmq/demo/{uuid.uuid4().hex[:6]}/basin1/pad12/well3"

KEEPALIVE = 120
HEARTBEAT = 900                                     # vollständige Aktualisierung alle 15 Minuten
DEADBANDS = {"tp": 2.0, "cp": 2.0, "ft": 0.5, "lv": 0.02}   # psi, psi, degF, m


def read_instruments():
    """Simulierte Werte; durch echte Modbus- oder Durchflussrechner-Lesezugriffe ersetzen."""
    return {
        "tp": round(850 + random.uniform(-3, 3), 1),    # Steigrohrdruck, psi
        "cp": round(420 + random.uniform(-3, 3), 1),    # Ringraumdruck, psi
        "ft": round(96 + random.uniform(-1, 1), 1),     # Temperatur der Fließleitung, degF
        "lv": round(2.41 + random.uniform(-0.03, 0.03), 3),  # Tankfüllstand, m
        "esd": False,                                   # ESD ausgelöst
    }


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code, "session present:", flags.session_present)
    client.publish(f"{BASE}/st", "online", qos=1, retain=True)


def on_disconnect(client, userdata, flags, reason_code, properties):
    print("Disconnected:", reason_code)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
                     protocol=mqtt.MQTTv5)
if USERNAME:
    client.username_pw_set(USERNAME, PASSWORD)
if USE_TLS:
    client.tls_set()
client.will_set(f"{BASE}/st", "offline", qos=1, retain=True)
client.reconnect_delay_set(min_delay=5, max_delay=300)   # exponentielles Backoff
client.on_connect = on_connect
client.on_disconnect = on_disconnect

connect_props = Properties(PacketTypes.CONNECT)
connect_props.SessionExpiryInterval = 1800          # Session 30 Minuten lang behalten
client.connect(BROKER, PORT, keepalive=KEEPALIVE, clean_start=False,
               properties=connect_props)
client.loop_start()

expiring = Properties(PacketTypes.PUBLISH)
expiring.MessageExpiryInterval = 3600               # Analogwerte älter als 1 h sind nutzlos

last, last_full = {}, 0.0
print("Publishing under", BASE)

while True:
    values = read_instruments()
    now = time.time()
    full = now - last_full >= HEARTBEAT
    changed = {}
    for key, value in values.items():
        if isinstance(value, bool):
            if full or value != last.get(key):
                # Alarme und Zustände: QoS 1, eigenes Topic, kein Ablauf
                client.publish(f"{BASE}/alm/{key}", json.dumps(value), qos=1, retain=True)
                last[key] = value
        elif full or key not in last or abs(value - last[key]) >= DEADBANDS[key]:
            changed[key] = value
            last[key] = value
    if changed:
        changed["t"] = int(now)                     # Epoch-Sekunden: kurz und eindeutig
        client.publish(f"{BASE}/v", json.dumps(changed, separators=(",", ":")),
                       qos=1, properties=expiring)
    if full:
        last_full = now
    time.sleep(10)

Eine Nachricht mit geänderten Werten sieht aus wie {"tp":853.4,"t":1792139421}, also einige Dutzend Bytes statt eines vollständigen Snapshots in jedem Scan. Beobachten Sie sie von Ihrem Schreibtisch aus:

mosquitto_sub -h broker.connectmq.com -p 1883 -i wellpad-watch-01 \
  -t 'connectmq/demo/+/basin1/#' -v

Der kostenlose öffentliche MQTT-Broker ist für Tests und Prototypen gedacht, nicht für Produktionsdaten, und hält Sessions bis zu 30 Minuten, passend zur obigen Session Expiry; auf produktiven Brokern in Ihrem eigenen Plan stimmen Sie sie auf Ihr reales Ausfallprofil ab.

Sicherheit für entlegene Standorte

Entlegene Standorte sind auf eine Weise exponiert, wie es Anlagen in der Werkshalle nicht sind. Setzen Sie mindestens diese Maßnahmen um:

1. TLS auf Port 8883 für jede Verbindung über ein öffentliches Netz, mit aktivierter Zertifikatsvalidierung.
2. Eindeutiger Benutzername, eigenes Passwort und eigene Client-ID pro Standort, damit ein gestohlenes Gateway einzeln gesperrt werden kann.
3. Nur ausgehende Konnektivität; keine eingehenden Ports am Mobilfunkmodem oder Satellitenterminal.
4. Standardmäßig nur lesend. Fernbefehle wie Drosseländerungen benötigen Freigabe-Workflows, Verriegelungen und Message Expiry.
5. Gehärtete Gateways: ungenutzte Dienste deaktiviert, Secure Boot wo verfügbar und physischer Manipulationsschutz.
6. Alarmierung bei unerwarteten Verbindungsabbrüchen, die sowohl auf Manipulation als auch auf Verbindungsprobleme hinweisen können.

Betreiber in der EU sollten diese Maßnahmen zudem mit ihren regulatorischen Pflichten abgleichen: Der Energiesektor fällt unter NIS2, und IEC 62443 liefert einen etablierten Rahmen für Zonen, Conduits und Sicherheitsstufen in der Leittechnik.

Den Broker betreiben

Der zentrale Broker ist die wichtigste gemeinsam genutzte Komponente und muss von jedem Standort aus erreichbar sein. ConnectMQ bietet einen verwalteten MQTT-Broker mit MQTT 3.1.1 und 5.0, TLS, Session Expiry und Message Expiry sowie Zugangsdaten pro Client. Sein Portal umfasst einen Live-Topic-Explorer, eine ISA-95-Geräteansicht, die Standorte und Anlagen gruppiert, und Schwellwert-Alarmregeln, zum Beispiel für Tankfüllstand oder Ringraumdruck, mit einem Alarmprotokoll zur Auswertung. Sparkplug-B-Daten von Edge-Gateways lassen sich dekodieren und in lesbare ISA-95-Topics des UNS zurückveröffentlichen, für Konsumenten, die kein Sparkplug sprechen. Für größere Flotten erhöhen kostenpflichtige und Dedicated-Pläne Verbindungsanzahl und Nachrichtengrößen, und BYOC platziert den verwalteten Broker in Ihrem eigenen Cloud-Konto.

Mehr zur Wahl der Verbindung und zum Modemverhalten finden Sie unter MQTT über Mobilfunk, die übergreifende Architektur im Leitfaden zu Industrial IoT mit MQTT.

Überwachen Sie entlegene Anlagen mit ConnectMQ

Beginnen Sie mit einem Bohrplatz oder einer Verdichterstation. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, verbinden Sie ein Edge-Gateway per TLS und legen Sie Ihren ersten Schwellwert-Alarm für einen Druck oder Füllstand an. Wenn sich der Pilot bewährt, skalieren Sie auf demselben ConnectMQ-Cloud-MQTT-Broker.

Häufig gestellte Fragen

Funktioniert MQTT über Satellitenverbindungen?

Ja. Persistente Verbindungen, kleine Header und Veröffentlichung per Report by Exception machen MQTT gut geeignet für Satellitenstrecken mit hoher Latenz. Stimmen Sie das Keep Alive ab, nutzen Sie persistente Sessions und halten Sie Payloads kompakt.

Welches Keep Alive sollte ich im Mobilfunk verwenden?

Beginnen Sie bei etwa 120 Sekunden und bleiben Sie unterhalb des NAT-Idle-Timeouts des Providers. Wenn Sie unerklärliche Wiederverbindungen sehen, verkürzen Sie es.

Ist Sparkplug B oder JSON besser für Telemetrie in Öl und Gas?

Sparkplug B ist kompakter und integriert sich gut in SCADA-Hosts. JSON mit kurzen Schlüsseln ist leichter zu inspizieren und funktioniert gut, wenn Payloads klein sind und Änderungen selten auftreten.

Sollten Abschaltbefehle über MQTT gesendet werden?

Nein. Sicherheitsfunktionen müssen lokal und unabhängig vom Netzwerk bleiben. MQTT eignet sich für die Überwachung und, mit angemessenen Schutzmaßnahmen, für überwachende Befehle.