Um gateway de borda IIoT é o dispositivo que transforma uma fábrica, uma usina ou uma mineradora cheia de CLPs, medidores e inversores em um fluxo de mensagens MQTT estruturadas que o resto da empresa consegue usar. Este artigo explica as quatro tarefas que todo gateway executa (tradução de protocolos, buffer, segurança e processamento na borda), apresenta uma arquitetura de referência e traz um checklist prático para escolher o seu.
Por Que Plantas Industriais Precisam de Gateways de Borda
Os equipamentos industriais foram feitos para conversar com outros equipamentos na mesma rede, não com a nuvem. Um chão de fábrica típico mistura Modbus RTU sobre RS485, Modbus TCP, OPC UA, EtherNet/IP, PROFINET e protocolos específicos de fabricantes, muitas vezes em redes deliberadamente isoladas do escritório e da internet. Esses protocolos são, em sua maioria, de requisição e resposta: um cliente precisa consultar cada dispositivo para cada valor.
Sistemas em nuvem, dashboards, analytics e um gêmeo digital da planta esperam outra coisa: dados seguros, de saída, orientados a eventos, com nomes e unidades consistentes. O gateway é o tradutor e a guarita entre esses dois mundos. Sem ele, cada aplicação que quisesse dados das máquinas precisaria de seus próprios drivers, do seu próprio caminho de rede até a rede OT e geraria sua própria carga de polling sobre controladores sensíveis.
As Quatro Funções Principais de um Gateway de Borda IIoT
1. Tradução de Protocolos e Modelagem de Dados
O gateway consulta ou assina os dispositivos em seus protocolos nativos e republica os dados via MQTT. Bons gateways fazem mais do que copiar registradores: aplicam escala, unidades e nomes, de modo que 40001 = 2351 vire {"temperature_c": 23.51} em um topic com significado, como acme/plant1/packaging/line2/filler/temperature.
Essa etapa de nomenclatura é onde o gateway contribui para um Unified Namespace. Se cada gateway publica em uma hierarquia compartilhada no estilo ISA-95 (empresa, site, área, linha, célula), os consumidores encontram os dados sem precisar saber qual gateway ou protocolo os produziu. Caminhos de tradução específicos são abordados nos guias de Modbus TCP para MQTT e de gateway OPC UA para MQTT.
2. Buffer e Store-and-Forward
Redes de planta e links de WAN falham. Um gateway que simplesmente descarta os dados enquanto o broker está inacessível deixa lacunas no histórico que muitas vezes não podem ser preenchidas depois. Gateways industriais enfileiram as mensagens localmente, em disco e não apenas em memória, e as reenviam em ordem quando a conexão volta. Os detalhes de projeto (tamanho do buffer, timestamps, taxa de reenvio) estão em store and forward para MQTT.
3. Fronteira de Segurança
O gateway geralmente é o único dispositivo que toca tanto a rede OT quanto uma rede externa. Isso faz dele o lugar certo para aplicar várias regras:
- Somente conexões de saída. O gateway abre uma conexão TLS com o broker; nada na internet inicia conexões para dentro da planta.
- Isolamento de credenciais. Apenas o gateway guarda as credenciais do broker. Os CLPs nunca.
- Somente leitura por padrão. Escrever setpoints a partir da nuvem deve ser habilitado explicitamente por tag, se for o caso.
- Segmentação de rede. Duas interfaces de rede, uma por zona, sem roteamento entre elas, ou posicionamento em uma DMZ industrial.
4. Processamento na Borda
Parte da lógica deve ficar junto à máquina: filtrar ruído, calcular médias, detectar cruzamentos de limites ou executar alarmes que precisam funcionar mesmo com a nuvem inacessível. O processamento na borda mais valioso costuma ser também o mais simples: report by exception, que publica um valor apenas quando ele muda de forma significativa e pode reduzir drasticamente o tráfego em comparação com o polling em intervalo fixo.
Arquitetura de Referência
Shop floor (OT network) Edge Cloud / IT
------------------------ ----------------- ------------------
PLC (EtherNet/IP) ---\ | IIoT edge | TLS | MQTT broker |
Energy meter (Modbus) ----+----> | gateway | -----> | (8883) | --> dashboards
CNC (OPC UA / MTConnect) --/ | - drivers | outbound| | --> historian
| - modeling | only | | --> analytics
| - buffer | | |
| - RBE / rules | ------------------
-----------------
O gateway publica em topics que seguem a hierarquia da planta. Um payload típico se parece com isto:
{
"ts": "2026-10-16T08:14:03.512Z",
"values": {
"spindle_speed_rpm": 11980,
"spindle_load_pct": 41.5,
"program": "O1234",
"state": "RUNNING"
},
"quality": "GOOD",
"source": "gw-plant1-02"
}
Incluir em toda mensagem um timestamp de origem, um indicador de qualidade e o ID do gateway torna os reenvios do buffer e o diagnóstico muito mais fáceis.
Escolhendo um Gateway de Borda IIoT: Checklist de Seleção
| Critério | Perguntas a fazer |
|---|---|
| Drivers de protocolo | Ele suporta todos os protocolos do seu chão de fábrica hoje, inclusive seriais legados? Os drivers são licenciados por protocolo ou por tag? |
| Qualidade do cliente MQTT | MQTT 3.1.1 e 5? TLS com CA personalizada? QoS, retained messages, Last Will e keep alive configuráveis? |
| Opções de payload | JSON simples, Sparkplug B ou ambos? Você controla totalmente a estrutura de topics? |
| Store-and-forward | Em disco? Quanto espaço? Reenvio ordenado? Reenvio com limitação de taxa? |
| Lógica na borda | Bandas mortas, escala, scripts ou containers para código próprio? |
| Hardware | Trilho DIN, ampla faixa de temperatura, sem ventoinha, entrada de alimentação industrial, portas seriais? |
| Gerenciamento | Configuração e atualização de firmware remotas sem abrir portas de entrada no firewall? |
| Segurança | Secure boot, atualizações assinadas, acesso local baseado em papéis, interfaces de rede separadas? |
| Ciclo de vida | Por quanto tempo o fabricante dará suporte, e é possível exportar a configuração se você o substituir? |
Tipos Comuns de Gateway
- Gateways industriais dedicados. Unidades para trilho DIN feitas sob medida, com ferramenta de configuração do fabricante. Rápidos de implantar, limitados aos protocolos e à lógica que o fabricante oferece.
- PCs industriais com software de gateway. Mais flexíveis: rodam uma plataforma comercial de conectividade, Node-RED ou seus próprios containers. Exigem mais manutenção no estilo TI.
- CLPs e controladores com MQTT integrado. Muitos controladores modernos publicam MQTT diretamente. Isso elimina uma caixa, mas coloca responsabilidades de rede sobre o controlador, algo com que nem toda planta se sente confortável.
- Gateways com microcontrolador. Em pequenos retrofits, um microcontrolador pode ligar alguns dispositivos Modbus ao MQTT, como no tutorial de ESP32 Modbus RS485 para MQTT. Bom para pilotos e monitoramento não crítico.
Sparkplug B ou JSON Simples?
Cada vez mais gateways oferecem Sparkplug B, que acrescenta um namespace de topics padronizado, certificados de birth e death para consciência de estado e payloads compactos em Protobuf. JSON simples é mais fácil de ler e de consumir em qualquer ferramenta. Muitas plantas usam os dois: Sparkplug B nos gateways e uma visão JSON legível em ISA-95 para os consumidores. A ConnectMQ consegue decodificar payloads Sparkplug B e republicá-los em topics ISA-95, por exemplo transformando spBv1.0/factory1/DDATA/line1/cnc1 em connectmq/factory1/production/line1/cnc1/telemetry, para que os dois estilos convivam no mesmo broker. O panorama geral está no guia de IoT industrial com MQTT.
Testando um Gateway Antes da Implantação
Antes de conectar um gateway a dados de produção, aponte-o para um broker de testes e verifique topics, payloads e o comportamento de reconexão:
mosquitto_sub -h broker.connectmq.com -p 1883 -i gw-test-viewer-81 -t "connectmq/demo/gw-test-81/#" -v
Configure o gateway para publicar valores simulados ou não sensíveis em connectmq/demo/gw-test-81/... no servidor MQTT público (gratuito), depois desconecte o cabo de rede por alguns minutos e confirme que as mensagens do buffer chegam em ordem quando você reconecta. Lembre-se de que o servidor MQTT público pode ser lido por qualquer pessoa e serve apenas para testes e protótipos, então nunca envie dados reais da planta para lá.
Onde Entra o Broker
O gateway é apenas metade do sistema. O broker para o qual ele publica precisa lidar com TLS, autenticação, muitos assinantes simultâneos e estado retido para cada tag. Manter essa infraestrutura por conta própria significa aplicar patches, renovar certificados e monitorar. Um broker MQTT gerenciado elimina esse fardo, e as opções vão de brokers serverless compartilhados para pilotos até clusters dedicados ou brokers implantados na sua própria conta de nuvem para requisitos mais rígidos. Se quiser entender antes as contrapartidas da hospedagem, veja o guia para escolher um broker MQTT na nuvem e, para decidir quanta lógica deve ficar na borda e quanta na nuvem, leia computação de borda vs computação em nuvem na IIoT.
Coloque Seus Gateways para Conversar com a ConnectMQ
A ConnectMQ dá a cada gateway um endpoint TLS na porta 8883, credenciais emitidas e vinculadas ao seu client ID, um explorador de topics ao vivo e uma visão de dispositivos organizada por níveis ISA-95. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e aponte o seu primeiro gateway para ele.
Perguntas frequentes
Qual a diferença entre um gateway de borda IIoT e um roteador?
Um roteador encaminha pacotes de rede sem entendê-los. Um gateway de borda entende protocolos industriais, lê valores, converte-os em mensagens com significado e os publica via MQTT.
Preciso de um gateway se o meu CLP suporta MQTT?
Nem sempre. Um gateway ainda ajuda quando você tem muitos dispositivos legados, precisa de buffer em disco ou quer manter as credenciais do broker e o acesso à internet fora dos seus controladores.
O gateway deve usar Sparkplug B?
Use Sparkplug B se as aplicações consumidoras o suportam e você quer gerenciamento de estado padronizado. Use JSON simples se muitas ferramentas simples precisam ler os dados diretamente; algumas plantas publicam os dois.
Quantos dados um gateway deve guardar em buffer?
Dimensione o buffer para a maior queda que você quer suportar na sua taxa normal de dados, com folga. O report by exception reduz tanto o tráfego normal quanto a necessidade de buffer.
