Este checklist de conectividade IIoT reúne as perguntas que decidem se um projeto de conexão da planta entra no ar em uma semana ou fica travado por meses. Percorra-o antes de o primeiro gateway chegar e você saberá exatamente quais regras de firewall solicitar, quais protocolos precisa converter, como nomear os seus dados e a qual broker se conectar.
O checklist está dividido em seis áreas. Cada item é algo que você consegue verificar, não um princípio vago, e vários vêm com um comando que você pode rodar hoje.
1. Escopo e Responsabilidades
A maioria dos projetos travados falha por causa de pessoas, não de pacotes. Resolva estes pontos antes de qualquer discussão sobre hardware.
- Nomeie um responsável do lado OT e um do lado TI, cada um com autoridade para aprovar mudanças no seu domínio.
- Escreva o primeiro caso de uso em uma frase, por exemplo "mostrar o estado ao vivo e a contagem de peças das seis máquinas CNC da célula 4 da planta de Campinas".
- Liste as máquinas no escopo, seus controladores e suas localizações físicas.
- Combine o que fica fora do escopo da fase um. Escrever nos CLPs é o item mais comum a adiar.
- Defina como vai medir o sucesso: latência dos dados, completude e se as pessoas que pediram os dados realmente os usam.
Se essas respostas estiverem nebulosas, o nosso plano de prova de conceito IIoT oferece uma estrutura de 30 dias para torná-las mais claras.
2. Checklist de Acesso de Rede
Os seus dados precisam de um caminho da máquina até o broker. Mapeie-o salto a salto.
- Identifique a zona de rede de cada máquina e gateway: rede isolada da célula, rede OT da planta, DMZ ou rede corporativa.
- Confirme se o gateway vai se conectar diretamente à internet, por um broker na DMZ ou por um proxy. O nosso guia sobre como posicionar o MQTT em uma DMZ industrial compara essas opções.
- Solicite TCP 8883 de saída (MQTT sobre TLS) para o hostname do broker. Evite a 1883 em texto puro em qualquer fronteira de zona.
- Se navegadores ou dashboards web precisarem de dados ao vivo, solicite também TCP 8084 (MQTT sobre WebSocket seguro).
- Confirme a resolução DNS a partir da rede do gateway.
- Pergunte se há um proxy com inspeção TLS no caminho. Se houver, solicite uma exceção para o hostname do broker.
- Verifique o timeout de ociosidade do firewall e configure o keepalive do MQTT abaixo dele.
- Confirme que o gateway alcança um servidor NTP. Relógios errados quebram a validação TLS e os timestamps.
Verifique o caminho a partir do próprio gateway, não do seu notebook. Os comandos abaixo usam o servidor MQTT público (gratuito), adequado apenas para testes de conectividade e protótipos, nunca para dados de produção:
# Gateway Linux: DNS, TCP e TLS de uma só vez
getent hosts broker.connectmq.com
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null \
| grep -E "subject=|issuer=|Verify return code"
# Teste MQTT de ponta a ponta com client ID e topic únicos
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i gw-test-$RANDOM -t connectmq/demo/gw-test-$RANDOM/ping -m hello -d
Em um gateway baseado em Windows ou em um PC de IHM, o equivalente rápido é:
powershell -Command "Test-NetConnection broker.connectmq.com -Port 8883"
Um Verify return code: 0 (ok) do OpenSSL e um CONNACK (0) do mosquitto_pub -d significam que o lado da rede está resolvido.
3. Checklist de Protocolos e Fontes de Dados
As suas máquinas falam o que vieram falando de fábrica. Faça o inventário.
| Fonte | Interface típica | Conversão necessária | O que providenciar |
|---|---|---|---|
| CLP moderno | OPC UA, S7, Ethernet/IP | Gateway para MQTT | Acesso somente leitura às tags |
| CLP ou inversor mais antigo | Modbus TCP ou RTU | Gateway para MQTT | Mapa de registradores do fabricante |
| Controlador CNC | MTConnect, OPC UA, API do fabricante | Adaptador para MQTT | Adaptador ou licença do fabricante |
| Máquina com lógica a relé | Nenhuma | Sensores adicionais | Eletricista para alicates e contatos |
| Sensores novos | MQTT nativo, LoRaWAN, Wi-Fi | Muitas vezes nenhuma | Credenciais por dispositivo |
- Registre o protocolo, o endereço IP e a porta ou a configuração serial de cada fonte.
- Confirme que o acesso somente leitura é possível e obtenha aprovação por escrito do responsável pelo controle.
- Exporte a lista de tags ou registradores e marque as tags de que você realmente precisa. Vinte tags boas valem mais que duas mil sem uso.
- Anote os limites de polling. Alguns controladores mais antigos sofrem quando consultados mais de uma vez por segundo.
- Decida se o gateway vai usar MQTT simples com JSON ou Sparkplug B. Os dois funcionam; misturá-los sem um plano, não.
4. Checklist de Modelagem de Dados
Dados que chegam com nomes enigmáticos são dados que ninguém usa, e um gêmeo digital construído sobre eles herda a mesma confusão.
- Escolha uma hierarquia de topics, de preferência alinhada ao ISA-95: empresa, site, área, linha, célula e, então, a máquina.
- Documente as regras de nomenclatura: minúsculas, sem espaços, hifens ou underscores, unidades consistentes.
- Defina o formato do payload, por exemplo
{"value": 72.4, "unit": "C", "ts": "2026-10-16T08:00:00Z"}. - Decida quais topics são retidos (estado atual) e quais são eventos (alarmes, conclusões de peças).
- Combine as regras de report by exception: que variação de valor justifica uma nova mensagem.
- Reserve uma subárvore separada para a saúde de gateways e dispositivos: status online, última comunicação, versão de firmware.
O guia de topics MQTT ISA-95 tem exemplos práticos que você pode adaptar.
5. Checklist de Segurança
- Todo cliente se autentica com seu próprio nome de usuário e senha. Nada de credenciais compartilhadas entre gateways.
- TLS em toda conexão que cruza uma fronteira de zona.
- Na fase um, os gateways só publicam para cima. Qualquer caminho de comando é projetado e revisado explicitamente.
- As credenciais ficam guardadas no gateway em um arquivo protegido, não fixas no código de scripts que acabam no controle de versão.
- Uma mensagem last will marca cada gateway como offline quando ele se desconecta inesperadamente.
- Existe um processo para revogar uma credencial quando um gateway é substituído ou roubado.
- Nada sensível é publicado em um servidor MQTT público, nunca.
Trate estes itens como o mínimo: um gateway que falhe em qualquer um deles não deve ser conectado, nem mesmo em um piloto.
6. Checklist de Escolha do Broker
O broker é o hub do qual todo o resto depende. Avalie-o pelas necessidades da sua planta, não apenas por uma lista de recursos.
- Suporta MQTT 3.1.1 e 5.0, para que tanto gateways antigos quanto clientes modernos se conectem.
- Oferece TLS na 8883 e WebSocket seguro para dashboards no navegador.
- Suporta a sua quantidade de conexões e tamanhos de mensagem, com folga para crescer.
- Suporta QoS 1 no mínimo, e QoS 2 se algum consumidor precisar de entrega exatamente uma vez.
- Suporta retained messages e sessões persistentes, para que o estado sobreviva às reconexões.
- Entende payloads industriais como Sparkplug B, ou pelo menos permite inspecioná-los.
- Dá visibilidade: quem está conectado, quais topics estão ativos e alertas por limite.
- Tem uma resposta clara sobre quem o atualiza e monitora. Um broker auto-hospedado é mais um servidor para a equipe de OT cuidar.
Para uma comparação mais aprofundada, veja como escolher um broker MQTT para IoT e o nosso guia sobre o modelo de broker MQTT na nuvem. Para entender como todas essas peças se encaixam em uma planta, leia o guia de IoT industrial com MQTT.
Como a ConnectMQ Atende ao Checklist
A ConnectMQ é um broker MQTT gerenciado projetado pensando na conexão de plantas. Suporta MQTT 3.1.1 e 5.0 em TCP 1883, TLS 8883, WebSocket 8083 e WebSocket seguro 8084, usa um certificado Let's Encrypt em que os repositórios de CAs padrão já confiam e vincula os client IDs às credenciais emitidas. Detecta topics ISA-95 e de Unified Namespace, decodifica payloads Sparkplug B e consegue republicar dados Sparkplug em topics ISA-95 legíveis. O portal inclui um cliente MQTT no navegador, um explorador de topics ao vivo e regras de alerta por limite, o que facilita verificar os itens das seções 4 e 6 durante o comissionamento.
Comece a Usar a ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Em minutos você terá credenciais e poderá rodar os testes de rede da seção 2 contra o seu próprio endpoint ConnectMQ, marcando hoje mesmo a primeira metade deste checklist.
Perguntas frequentes
Quais portas um gateway IIoT precisa para alcançar um broker MQTT?
Normalmente apenas TCP 8883 de saída, para MQTT sobre TLS. Acrescente TCP 8084 se dashboards no navegador se conectarem por WebSocket seguro. Nenhuma porta de entrada na planta é necessária.
Quem deve ser responsável por um projeto de conectividade IIoT?
OT e TI juntos. Nomeie um responsável de cada lado com autoridade para aprovar mudanças, porque a maioria dos atrasos vem de aprovações pouco claras, e não de problemas técnicos.
Devo usar Sparkplug B ou JSON para os dados da planta?
Os dois funcionam. O Sparkplug B acrescenta um modelo rígido de sessão e estado que as ferramentas SCADA entendem, enquanto JSON com uma árvore de topics ISA-95 é mais fácil de ler e integrar. Escolha um por fonte de dados e documente a escolha.
Como testo a conectividade antes de instalar qualquer software de gateway?
Rode os testes de DNS, OpenSSL e mosquitto_pub a partir de uma máquina na mesma zona de rede do futuro gateway. Se os três funcionarem contra a porta 8883, o caminho de rede está pronto.
