MQTT para Monitoramento Remoto em Petróleo e Gás via Celular e Satélite

As implantações de MQTT em petróleo e gás se tornaram uma forma padrão de monitorar cabeças de poço, dutos, estações de compressão e parques de tanques localizados longe de qualquer fibra óptica, como campos terrestres no interior do Nordeste brasileiro. O modelo de report by exception, os pacotes pequenos e a tolerância a links instáveis combinam com a realidade do backhaul celular e via satélite. Neste guia você vai aprender a arquitetar o monitoramento remoto com MQTT, quais configurações de keep alive, sessão e QoS funcionam em links caros e como construir um publicador de borda que mantém a largura de banda baixa sem perder eventos importantes.

Por que ativos remotos de petróleo e gás combinam com MQTT

Os ativos de upstream e midstream compartilham um conjunto de restrições que torna o polling tradicional penoso:

• Largura de banda cara ou limitada. Satélite e alguns planos celulares cobram por byte ou têm franquias apertadas. Fazer polling de valores inalterados a cada poucos segundos é desperdício de dinheiro.
• Alta latência. As idas e voltas por satélite geoestacionário são longas, então um mestre que consulta centenas de sites em sequência acaba com ciclos de varredura muito lentos.
• Conectividade intermitente. Clima, energia e cobertura causam quedas que o sistema de telemetria precisa superar sem perder alarmes.
• Orçamento de energia. RTUs e gateways alimentados por energia solar querem o rádio ocioso o máximo possível.
• Exposição de segurança. Sites remotos são fisicamente acessíveis e se conectam por redes públicas.

O MQTT ataca esses pontos diretamente. Os dispositivos de campo abrem uma única conexão TLS de saída e a mantêm, publicam apenas mudanças significativas e deixam o broker distribuir os dados para SCADA, historiadores, ferramentas de análise e até um gêmeo digital do ativo. O guia de MQTT em sistemas SCADA explica essa transição do polling com mais profundidade.

Arquitetura de referência

Uma arquitetura típica de MQTT para petróleo e gás tem quatro camadas:

1. Instrumentos e controladores de campo. Computadores de vazão, transmissores de pressão e temperatura, radares de nível de tanque, controladores de bombas e sistemas de ESD, geralmente falando Modbus ou um protocolo proprietário localmente.
2. Gateway de borda ou RTU. Lê os dispositivos locais, aplica bandas mortas, registra timestamps, armazena em buffer durante quedas e publica MQTT. Muitas vezes em Sparkplug B, por compatibilidade com o SCADA.
3. Backhaul. Celular (LTE, LTE-M), rádio licenciado ou não licenciado, ou satélite (geoestacionário ou de órbita baixa).
4. Broker e consumidores. Um broker central, com hosts SCADA, historiadores, contabilidade de produção e sistemas de detecção de vazamentos como assinantes.

Mantenha as funções de segurança locais. O desligamento de emergência e a proteção contra sobrepressão nunca devem depender do link ou do broker; o MQTT transporta dados de monitoramento e, quando aprovado, apenas comandos supervisórios.

Ajustando o MQTT para links celulares e de satélite

As configurações padrão da maioria das bibliotecas MQTT pressupõem uma LAN. Em links remotos, alguns parâmetros fazem a diferença entre um sistema confiável e um sistema ruidoso e caro.

Keep alive e timeouts de NAT

As operadoras celulares colocam os dispositivos atrás de NAT de nível de operadora (CGNAT), que derruba fluxos TCP ociosos após um período definido pela operadora. Se o seu keep alive for maior que isso, a conexão morre silenciosamente e o dispositivo só descobre quando a próxima publicação falha. Meça: comece com 120 segundos, observe reconexões inexplicadas no log de conexões do broker e encurte até que parem. Em links de satélite, considere também as idas e voltas longas ao escolher o timeout de ping do cliente.

Report by exception para dados de cabeça de poço

Uma pressão de tubing que varia 0,1 por cento não precisa atravessar um satélite. Defina bandas mortas por tag a partir da precisão do instrumento e da relevância operacional, publique estados digitais e alarmes a cada mudança e envie uma atualização completa a cada 15 a 60 minutos como prova de vida. O guia de report by exception aborda a escolha da banda morta, e store-and-forward para MQTT explica como armazenar e reenviar dados ao longo das quedas.

Exemplo: um publicador de borda que economiza largura de banda

Este publicador em Python usa MQTT 5 com sessão persistente, chaves JSON curtas, bandas mortas por tag, um heartbeat, message expiry em dados de baixo valor e backoff exponencial de reconexão. Substitua read_instruments() pelas suas leituras Modbus ou do computador de vazão.

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

# Broker público de testes para o laboratório: pode ser lido por todos, então use apenas dados simulados.
BROKER, PORT, USE_TLS = "broker.connectmq.com", 1883, False
USERNAME, PASSWORD = None, None                     # produção: "YOUR_USERNAME", "YOUR_PASSWORD"
CLIENT_ID = f"wellpad-{uuid.uuid4().hex[:8]}"       # produção: "YOUR_CLIENT_ID"
BASE = f"connectmq/demo/{uuid.uuid4().hex[:6]}/basin1/pad12/well3"

KEEPALIVE = 120
HEARTBEAT = 900                                     # atualização completa a cada 15 minutos
DEADBANDS = {"tp": 2.0, "cp": 2.0, "ft": 0.5, "lv": 0.02}   # psi, psi, degF, m


def read_instruments():
    """Valores simulados; substitua por leituras reais via Modbus ou do computador de vazão."""
    return {
        "tp": round(850 + random.uniform(-3, 3), 1),    # pressão de tubing, psi
        "cp": round(420 + random.uniform(-3, 3), 1),    # pressão de revestimento, psi
        "ft": round(96 + random.uniform(-1, 1), 1),     # temperatura da linha de fluxo, degF
        "lv": round(2.41 + random.uniform(-0.03, 0.03), 3),  # nível do tanque, m
        "esd": False,                                   # ESD disparado
    }


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)   # backoff exponencial
client.on_connect = on_connect
client.on_disconnect = on_disconnect

connect_props = Properties(PacketTypes.CONNECT)
connect_props.SessionExpiryInterval = 1800          # mantém a sessão por 30 minutos
client.connect(BROKER, PORT, keepalive=KEEPALIVE, clean_start=False,
               properties=connect_props)
client.loop_start()

expiring = Properties(PacketTypes.PUBLISH)
expiring.MessageExpiryInterval = 3600               # valores analógicos com mais de 1 h são inúteis

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):
                # alarmes e estados: QoS 1, topic próprio, sem expiração
                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)                     # segundos desde a época: curto e sem ambiguidade
        client.publish(f"{BASE}/v", json.dumps(changed, separators=(",", ":")),
                       qos=1, properties=expiring)
    if full:
        last_full = now
    time.sleep(10)

Uma mensagem de valores alterados fica como {"tp":853.4,"t":1792139421}, dezenas de bytes em vez de um snapshot completo a cada varredura. Acompanhe da sua mesa:

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

O servidor MQTT público (gratuito), pensado apenas para testes com dados simulados, mantém sessões por até 30 minutos, o que corresponde ao session expiry acima; é nos brokers de produção do seu próprio plano que você ajusta isso ao seu perfil real de quedas.

Segurança para sites remotos

Sites remotos ficam expostos de formas que os equipamentos do chão de fábrica não ficam. Aplique no mínimo estes controles:

1. TLS na porta 8883 em toda conexão por rede pública, com validação de certificado habilitada.
2. Usuário, senha e client ID únicos por site, para que um gateway roubado possa ser revogado isoladamente.
3. Conectividade apenas de saída; nenhuma porta de entrada no modem celular ou no terminal de satélite.
4. Somente leitura por padrão. Comandos remotos, como mudanças de choke, precisam de fluxos de aprovação, intertravamentos e message expiry.
5. Gateways protegidos: serviços não utilizados desabilitados, secure boot onde disponível e proteção física contra violação.
6. Alertas para desconexões inesperadas, que podem indicar violação além de problemas de link.

Operando o broker

O broker central é o componente compartilhado mais importante e precisa ser acessível a partir de todos os sites. O ConnectMQ oferece um broker MQTT gerenciado com MQTT 3.1.1 e 5.0, TLS, session expiry e message expiry, além de credenciais por cliente. O portal inclui um explorador de topics ao vivo, uma visualização de dispositivos ISA-95 que agrupa sites e ativos e regras de alerta por limite, por exemplo para nível de tanque ou pressão de revestimento, com um log de alertas para revisão. Gateways de borda que usam Sparkplug B podem ter seus dados decodificados e republicados em topics ISA-95 legíveis para consumidores que não falam Sparkplug. Para frotas maiores, os planos pagos e dedicados aumentam a quantidade de conexões e o tamanho das mensagens, e o BYOC coloca o broker MQTT gerenciado na sua própria conta de nuvem.

Para mais sobre escolhas de link e comportamento de modems, veja MQTT via rede celular e, para a arquitetura mais ampla, o guia de IoT industrial com MQTT.

Monitore ativos remotos com o ConnectMQ

Comece com uma locação de poço ou uma estação de compressão. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, conecte um gateway de borda via TLS e configure seu primeiro alerta por limite em uma pressão ou nível. Quando o piloto se provar, escale no mesmo broker MQTT na nuvem do ConnectMQ.

Perguntas frequentes

O MQTT funciona em links de satélite?

Sim. As conexões persistentes, os cabeçalhos pequenos e a publicação por report by exception do MQTT combinam com links de satélite de alta latência. Ajuste o keep alive, use sessões persistentes e mantenha os payloads compactos.

Qual keep alive devo usar em rede celular?

Comece com cerca de 120 segundos e mantenha-o abaixo do timeout de inatividade do NAT da operadora. Se aparecerem reconexões inexplicadas, encurte-o.

Sparkplug B ou JSON: qual é melhor para telemetria de petróleo e gás?

O Sparkplug B é mais compacto e se integra bem a hosts SCADA. JSON com chaves curtas é mais fácil de inspecionar e funciona bem quando os payloads são pequenos e as mudanças, pouco frequentes.

Comandos de desligamento devem ser enviados via MQTT?

Não. As funções de segurança devem permanecer locais e independentes da rede. O MQTT é adequado para monitoramento e, com as salvaguardas adequadas, para comandos supervisórios.