Da SCADA ao Dashboard: Desenhar a Ingestão de Telemetria Sem Afogar a Base de Dados | Blog

# Da SCADA ao Dashboard: Desenhar a Ingestão de Telemetria Sem Afogar a Base de Dados

TL;DR: um poço, uma FPSO ou uma estação de bombagem geram telemetria a uma cadência que nenhuma base de dados relacional de ERP foi feita para absorver directamente; a arquitectura certa separa a captação (OPC UA, MQTT, Modbus), o armazenamento em série temporal com agregação/retenção em camadas, e só depois expõe ao ERP um resumo já tratado — nunca a leitura crua, e nunca com a rede OT acessível a partir da rede de TI.

O problema, dito em números

Um único sensor de pressão a reportar a 1 Hz produz 86 400 leituras por dia. Uma plataforma com algumas centenas de tags SCADA (pressões, temperaturas, caudais, vibração, estados de válvulas) facilmente ultrapassa dezenas de milhões de leituras por dia, só nessa unidade. Multiplique isso por vários poços, um FPSO e uma rede de oleodutos, e está a falar de um volume de escrita que nenhuma tabela SensorReading dentro da mesma base de dados Postgres que guarda facturas, propostas e leads vai aguentar sem degradar tudo o resto.

Daí a regra que este artigo defende: a ingestão de telemetria industrial é um problema de arquitectura à parte, com o seu próprio motor de armazenamento, e não "mais uma tabela" no ERP. O erro mais comum é exactamente o oposto — ligar o PLC ou o gateway SCADA directamente à base de dados transaccional da aplicação de gestão. Funciona numa demonstração com dez sensores. Não sobrevive à produção real.

Três protocolos reais — e o que cada um faz de facto

Antes de desenhar qualquer pipeline, vale a pena ser preciso sobre o que cada protocolo é, porque cada um resolve um problema diferente e nenhum substitui os outros por completo.

OPC UA (IEC 62541)

OPC UA (OPC Unified Architecture) é uma especificação de arquitectura orientada a serviços, independente de plataforma, que sucede ao OPC Classic e está normalizada como IEC 62541 pela OPC Foundation. Corre sobre Windows, Linux e sistemas embebidos, define um modelo de informação estruturado (não só valores soltos, mas um espaço de endereços com tipos, relações e metadados) e inclui segurança (autenticação, cifragem, assinatura de mensagens) como parte da especificação — não como extensão posterior. Na prática industrial, é o protocolo que se usa para expor de forma rica e semanticamente descrita o que está a acontecer num PLC, DCS ou historian moderno.

MQTT

MQTT é um protocolo de mensagens publish/subscribe, extremamente leve, normalizado pela OASIS (a versão 5.0 é a actual, com a 3.1.1 ainda amplamente usada). Um broker MQTT faz de intermediário: dispositivos publicam mensagens num "tópico" e quem estiver subscrito a esse tópico recebe-as, sem que o publicador precise de saber quem está a ouvir. Foi desenhado para ligações instáveis e dispositivos com pouca capacidade de processamento — exactamente o perfil de um sensor IoT remoto num poço isolado ou de um gateway a comunicar por rádio ou satélite quando a fibra não chega. MQTT não define, por si, um modelo de dados rico como o OPC UA; define o transporte e a semântica de entrega (QoS 0/1/2, retenção de última mensagem, "last will").

Modbus

Modbus é um protocolo de mensagens mais antigo (Modicon, 1979), aberto e de uso livre, historicamente descrito em arquitectura mestre/escravo — terminologia que a Modbus Organization actualizou para cliente/servidor na versão 1.1b3 da especificação, mantendo o mesmo modelo de dados e códigos de função. Expõe um espaço de endereços simples de registos de 16 bits e bobinas (bits), lidos e escritos por um cliente que interroga cada dispositivo individualmente. É o protocolo que ainda domina uma enorme quantidade de instrumentação de campo mais antiga — muitos PLCs, medidores e RTUs em instalações petrolíferas angolanas mais antigas só falam Modbus RTU (série) ou Modbus TCP.

Vale ainda referir o DNP3, que não estava no âmbito original deste artigo mas aparece com frequência ao lado destes três: é o protocolo dominante em SCADA de electricidade, água e também em oil & gas para comunicação entre uma estação mestre e RTUs/IEDs em grandes distâncias — mantido hoje pelo DNP Users Group. Se o seu campo tem estações de bombagem ou subestações eléctricas associadas, é provável que o encontre a par do Modbus.

Comparação rápida

Protocolo	Tipo de comunicação	Ponto forte	Onde aparece tipicamente
OPC UA	Cliente/servidor + pub/sub, modelo de informação rico	Segurança nativa, semântica estruturada, interoperabilidade entre fornecedores	PLCs e DCS modernos, historians, MES
MQTT	Publish/subscribe via broker	Leveza, tolerância a ligações fracas, escala para milhares de dispositivos	Sensores IoT remotos, gateways de campo, satélite/rádio
Modbus	Cliente/servidor, registos de 16 bits	Simplicidade, omnipresença em equipamento mais antigo	PLCs legados, medidores, RTUs de geração anterior
DNP3	Mestre/RTU, orientado a eventos	Fiabilidade em ligações longas e pouco fiáveis	Subestações, estações de bombagem, electricidade

Nenhum destes é "melhor" em absoluto — a escolha depende do que já está instalado no terreno. Um gateway de borda (edge gateway) bem desenhado normalmente fala Modbus ou OPC UA para dentro (para os equipamentos), e publica por MQTT para fora (para o pipeline de ingestão), fazendo essa tradução de protocolo — que é, no fundo, o mesmo problema de integração entre sistemas heterogéneos que resolvemos em qualquer projecto de API, só que aqui um dos lados fala um protocolo industrial em vez de REST ou GraphQL.

Por que não se escreve cada leitura crua na base de dados do ERP

Há três razões técnicas concretas, não apenas uma questão de "boas práticas":

1. Padrão de escrita incompatível. Uma base de dados relacional optimizada para transacções (leads, propostas, facturas — o padrão de um Postgres a suportar um ERP) é desenhada para poucas escritas por segundo com muitos índices e integridade referencial forte. Telemetria é o oposto: milhares de escritas por segundo, quase sem necessidade de índices tradicionais, quase nunca actualizadas depois de escritas (append-only). Forçar os dois padrões na mesma tabela satura o WAL, infla índices e degrada consultas que nada têm a ver com sensores — as facturas começam a demorar porque um sensor de vibração está a escrever a 10 Hz.

2. Crescimento descontrolado. Sem uma estratégia de retenção específica para série temporal, a tabela cresce indefinidamente. Um ERP não tem, por definição, mecanismos nativos de expiração automática de dados por antiguidade e agregação — isso é uma funcionalidade de bases de dados de série temporal (TimescaleDB, InfluxDB e semelhantes), não de um esquema relacional genérico.

3. Acoplamento operacional. Se o histórico de sensores vive na mesma base de dados do ERP, uma manutenção, um pico de carga ou uma falha na ingestão de telemetria pode arrastar consigo o sistema de facturação e CRM — dois domínios que não deviam partilhar risco operacional.

A separação correcta é: um motor de série temporal dedicado guarda a leitura crua (ou quase crua) durante uma janela curta e as agregações durante muito mais tempo; o ERP só recebe, via API, os indicadores já processados que interessam ao negócio — produção diária por poço, horas de paragem de um equipamento, alertas de desvio face a limites operacionais.

O contexto angolano: onde a largura de banda decide a arquitectura

Em Angola, a distância entre o sensor e a base de dados não é só lógica, é geográfica. Uma operação offshore no Bloco 17 ou 32 liga-se por satélite; uma base de apoio no Soyo ou em Cabinda liga-se por fibra ou por rádio; e o centro de dados pode estar em Luanda ou fora do país. Isso muda o desenho, não apenas o custo.

A infraestrutura melhorou de forma relevante — a Angola Cables opera o AngoNAP em Luanda e o ponto de troca de tráfego Angonix, o país tem milhares de quilómetros de fibra nacional e liga-se a cabos submarinos internacionais — mas nada disso resolve o problema de origem: um FPSO continua a depender de um link com latência e largura de banda limitadas, e é sobre esse link que a telemetria tem de passar.

A consequência prática é simples e determina tudo o resto: agregue na origem. Enviar 1 Hz de cada tag para terra e decidir depois o que interessa é desperdiçar o recurso mais escasso da operação. O que sobe deve ser aquilo que já foi reduzido, priorizado e — quando o link cai — enfileirado localmente para reenvio.

Agregação e downsampling: o que ficar, o que resumir, o que expirar

"Downsampling" é o processo de reduzir a resolução temporal de dados históricos, substituindo muitas leituras por um resumo estatístico (média, mínimo, máximo, último valor) por intervalo. É a técnica padrão em bases de dados de série temporal como TimescaleDB (via continuous aggregates, que podem ser combinados com uma política de retenção para apagar os dados brutos mantendo os agregados) ou InfluxDB (via políticas de retenção associadas a tarefas de downsampling, mantendo os dados de alta resolução por pouco tempo e os dados sumarizados por muito mais tempo).

Uma política razoável para telemetria de campo em oil & gas costuma ter três a quatro camadas:

Bruto (segundos a minutos): retido dias a poucas semanas, para diagnóstico imediato e investigação de incidentes recentes.
Agregado de 1 minuto ou 5 minutos: retido vários meses, suficiente para análise operacional de curto/médio prazo.
Agregado horário: retido um a vários anos, para tendências e planeamento de manutenção.
Agregado diário: retido indefinidamente (ou por prazos definidos por regulação/auditoria), para relatórios de produção, ESG e comparação ano a ano.

Isto não é uma escolha estética — é o que torna a base de dados sustentável a longo prazo sem perder a capacidade de responder à pergunta "o que aconteceu à pressão do poço 12 na madrugada de terça-feira", que continua a precisar de dados com granularidade fina, só que apenas para uma janela recente.

Retenção: decidir antes de acumular

A retenção não deve ser decidida ex-post, quando o disco está cheio — deve ser definida como parte do desenho inicial, tag a tag, porque nem todo o sensor tem o mesmo valor histórico. Um sensor de vibração de uma bomba crítica pode justificar retenção bruta mais longa para análise preditiva de falha; um sensor de temperatura ambiente de um contentor provavelmente não. Definir isto cedo evita duas armadilhas: pagar armazenamento caro por dados sem valor analítico, ou descobrir tarde demais que se apagou exactamente o período que a equipa de engenharia precisava para investigar uma paragem.

A fronteira de segurança: a rede OT não se expõe pela camada de TI

Este é o ponto onde a arquitectura de ingestão de dados se cruza directamente com segurança industrial, e onde vemos mais projectos falharem por pressa. O modelo de referência usado pela indústria — o modelo de Purdue, hoje incorporado na estrutura de zonas e condutas da norma IEC 62443 — separa explicitamente os níveis de controlo (PLCs, RTUs, sistemas SCADA/DCS) dos níveis de TI corporativa, com zonas de segurança definidas por avaliação de risco e "condutas" controladas entre elas, em vez de uma rede plana.

Na prática, isto traduz-se em regras concretas para qualquer pipeline de ingestão:

O sentido do fluxo de dados deve ser de dentro para fora. O gateway de borda na rede OT publica dados para um broker ou serviço na DMZ/rede de TI; a rede de TI não deve ter capacidade de iniciar ligações directas para dentro da rede OT.
Nenhum sistema de TI (incluindo o próprio ERP) deve ter acesso de rede directo a um PLC, RTU ou historian de controlo. Se o dashboard de gestão precisa de um valor, vai buscá-lo à camada de série temporal ou à API intermediária — nunca directamente ao equipamento de campo.
A tradução de protocolo acontece na fronteira, não depois dela. É o gateway/edge device, fisicamente e logicamente na zona OT ou numa DMZ dedicada, que fala Modbus/OPC UA para dentro e MQTT/HTTPS para fora — e é aí, nessa fronteira, que devem estar os controlos de autenticação, cifragem e filtragem, não confiados a "a rede corporativa tem firewall".
Credenciais e certificados da rede OT não devem ser partilhados com sistemas de TI, mesmo administrativos — um comprometimento no ERP ou no CRM não deve, por desenho, dar a ninguém um caminho de volta ao sistema de controlo de um poço ou de uma unidade de processo.

Isto não é paranoia regulatória — é o motivo pelo qual incidentes de segurança em ambientes industriais tendem a começar exactamente onde a fronteira OT/TI foi tratada como um detalhe de rede em vez de um requisito de arquitectura desde o primeiro desenho.

Uma arquitectura de referência, em texto

1. Campo: PLCs, RTUs e sensores falam Modbus, OPC UA ou DNP3 conforme o equipamento instalado.

2. Borda (edge, dentro da zona OT): um gateway agrega e traduz protocolo, aplica filtragem básica (ex.: descartar leituras fora de gama física antes de as enviar), e publica por MQTT (ou OPC UA sobre um proxy seguro) para fora da zona OT, através de uma conduta controlada.

3. Ingestão (DMZ ou zona de dados): um broker MQTT ou serviço de ingestão recebe as mensagens e escreve na base de dados de série temporal.

4. Armazenamento de série temporal: dados brutos de curto prazo + agregações em camadas, com retenção definida por tag.

5. Camada de integração: uma API (autenticada, com o mesmo rigor de qualquer integração de sistemas que se exponha a um sistema de gestão) expõe ao ERP apenas os indicadores já tratados — produção, disponibilidade, alertas — nunca a leitura bruta em tempo real.

6. ERP/dashboard: consome a API, mostra tendências, gera alertas de negócio, alimenta relatórios de produção e manutenção.

Perguntas frequentes

MQTT substitui o OPC UA?

Não. Resolvem problemas diferentes. MQTT é um transporte leve de mensagens publish/subscribe, sem modelo de informação próprio rico; o OPC UA define tanto o transporte como um modelo de dados estruturado com segurança nativa. É comum um gateway falar OPC UA para o PLC e publicar por MQTT para o pipeline de ingestão — não são mutuamente exclusivos.

Ainda vale a pena investir em Modbus se já é um protocolo dos anos 1970?

Sim, quando o equipamento instalado só fala Modbus — e em muitas instalações mais antigas em Angola, isso ainda é a realidade da maior parte da instrumentação de campo. O objectivo não é substituir o Modbus no equipamento, é garantir que o gateway de borda o traduz de forma segura para um protocolo mais adequado à ingestão em escala.

Uma base de dados de série temporal é sempre necessária, mesmo para volumes pequenos?

Se o volume real é baixo (dezenas de sensores, poucas leituras por minuto), uma tabela dedicada e bem indexada numa base de dados relacional separada da do ERP pode bastar durante algum tempo. O ponto de viragem chega mais depressa do que se espera assim que se adicionam poços, equipamento de vibração de alta frequência ou vários locais — e nessa altura a migração já com dados acumulados é bem mais cara do que desenhar com a arquitectura certa desde o início.

Quem deve ficar com o histórico bruto: o historian industrial ou a camada de ingestão da aplicação de gestão?

O historian industrial (quando existe) é normalmente a fonte de verdade operacional para engenharia e manutenção, com retenção e ferramentas próprias. A camada de ingestão que alimenta o ERP não precisa de duplicar essa função — precisa de captar, agregar e expor o que é relevante para decisões de negócio, evitando construir um segundo historian informal dentro de uma base de dados que não foi desenhada para isso.