Uma boa arquitetura IIoT divide um sistema industrial em quatro camadas: dispositivos que medem e controlam, gateways de borda que traduzem e filtram, um broker que distribui as mensagens e aplicações que transformam dados em decisões. Nesta referência você vai entender pelo que cada camada é responsável, quais regras de projeto mantêm as camadas independentes e como executar um pequeno exemplo de ponta a ponta que passa pelas quatro.
Por que as camadas importam na IoT industrial
Muitos dos primeiros projetos de IIoT foram construídos como canos diretos: um script lê um CLP e grava em um banco de dados consultado por um único dashboard. Funciona na demo. Depois, um segundo consumidor precisa dos dados, o CLP é substituído ou o banco de dados vai para a nuvem, e cada mudança se propaga pela cadeia inteira.
Uma arquitetura em camadas contém essas ondas. Cada camada tem uma única função e um contrato claro com suas vizinhas. Troque um CLP e só a configuração da borda muda. Adicione uma ferramenta de analytics e só aparece um novo subscriber. Migre do on-premises para a nuvem e a borda simplesmente se conecta a outro endereço de broker. O modelo publish/subscribe é o que torna esse desacoplamento possível, e é por isso que um broker MQTT fica no centro da maioria dos projetos modernos de IIoT.
As quatro camadas da arquitetura IIoT
| Camada | Responsabilidade | Componentes típicos | Fala | Responsável |
|---|---|---|---|---|
| Dispositivo | Medir, atuar, controlar o processo | Sensores, CLPs, inversores, CNCs, robôs | Fieldbus, Modbus, OPC UA, E/S analógicas e digitais | Engenharia de automação |
| Borda | Coletar, normalizar, armazenar em buffer, filtrar, proteger o uplink | PCs industriais, gateways, Node-RED, conversores de protocolo | Protocolos de dispositivo para baixo, MQTT para cima | TO, às vezes em conjunto com a TI |
| Broker | Rotear mensagens, manter o estado atual, autenticar clients | Broker MQTT gerenciado ou auto-hospedado | MQTT 3.1.1 e 5.0 sobre TLS e WebSocket | Equipe de plataforma ou provedor gerenciado |
| Aplicação | Visualizar, armazenar, analisar, integrar, decidir | Dashboards, historiadores, MES, conectores de ERP, analytics | Subscribe e publish MQTT | TI, equipes de dados, operação |
Camada de dispositivo
Este é o mundo físico: sondas de temperatura, medidores de vazão, CLPs, inversores, comandos CNC e robôs. Os dispositivos são otimizados para controle determinístico, não para compartilhar dados. Muitos falam apenas protocolos de fieldbus ou seriais, e alguns não têm nenhuma interface de comunicação. A regra de arquitetura nesta camada é simples: não altere a lógica de controle para atender a necessidades de TI. Leia os dados de forma não invasiva e deixe segurança e controle onde eles devem ficar.
Camada de borda
A borda é o tradutor e o guarda. Um gateway de borda lê tags de CLP, registradores Modbus ou entradas de sensores, converte-os para um formato comum e os publica via MQTT. Ele também faz o trabalho que nunca deveria trafegar por uma WAN: filtrar ruído, reportar por exceção, acrescentar timestamps e unidades e armazenar dados em buffer quando o uplink cai. Nossos guias sobre como escolher um gateway de borda IIoT e sobre edge computing vs cloud computing na IIoT aprofundam o que pertence a esta camada.
Principais responsabilidades da borda:
- Conversão dos protocolos de dispositivo para MQTT.
- Normalização de nomes, unidades e timestamps.
- Report by exception com bandas mortas para reduzir o tráfego.
- Store and forward durante quedas de rede.
- Conexões somente de saída até o broker via TLS.
- Publicação da própria saúde: status online via last will, firmware, horário da última leitura.
Camada de broker
O broker é o hub. Todos os gateways de borda publicam nele e todas as aplicações assinam a partir dele. Nenhum dos lados conhece o outro, e é exatamente essa a ideia. Além de rotear, o broker guarda retained messages para que novas aplicações vejam o estado atual na hora, mantém sessões para clients que se reconectam, aplica autenticação e cotas e publica last will messages quando gateways caem. Se quiser os fundamentos, leia sobre o que um broker MQTT faz.
O broker também é onde mora o namespace. Um Unified Namespace organiza os topics pela hierarquia ISA-95, por exemplo connectmq/acme/plant1/packaging/line4/filler02/telemetry, para que qualquer aplicação encontre os dados pela localização e não por uma lista de tags. As regras para projetar essa árvore estão no nosso guia de estrutura de topics do UNS.
Camada de aplicação
As aplicações são onde os dados viram valor: dashboards ao vivo, cálculos de OEE, notificação de alarmes, historiadores, integração com MES e ERP, machine learning e gêmeos digitais. Cada aplicação é apenas mais um client MQTT. Ela assina a parte do namespace de que precisa e pode publicar resultados de volta, como um OEE calculado ou uma falha prevista, que outras aplicações podem então consumir. O armazenamento de longo prazo normalmente é um subscriber dedicado que grava em um banco de dados de séries temporais, tema do nosso artigo sobre historiador MQTT.
Regras de projeto que mantêm a arquitetura limpa
- Toda seta aponta para o broker. Dispositivos nunca falam diretamente com aplicações, e aplicações nunca fazem polling em dispositivos.
- As conexões vão para fora. A borda e as aplicações abrem conexões até o broker; nada abre conexões para dentro da planta.
- Um namespace, documentado. A hierarquia de topics e o formato de payload são registrados por escrito e versionados.
- Retenha estado, não retenha eventos. Valores atuais são retidos; alarmes e conclusões de peças, não.
- Cada client tem sua própria identidade. Credenciais separadas por gateway e por aplicação, para que uma possa ser revogada sem afetar as outras.
- Inteligência na camada certa. A lógica crítica em tempo fica no dispositivo ou na borda; analytics entre plantas pertence à camada de aplicação.
- Observe o próprio sistema. Status dos gateways, estado das conexões e taxas de mensagens também são dados.
Exemplo de ponta a ponta pelas quatro camadas
O exemplo a seguir usa o servidor MQTT público (gratuito) do ConnectMQ, pensado para testes e protótipos. O comando bash faz o papel da camada de borda, publicando leituras de dispositivo. O script Python é uma aplicação: um pequeno historiador que armazena cada leitura em SQLite e publica um alerta quando um limite é ultrapassado.
Camada de borda (simulada), publicando uma leitura a cada dois segundos:
ID=arch-$RANDOM
echo "Use prefix connectmq/demo/$ID"
while true; do
T=$(awk -v r=$RANDOM 'BEGIN{printf "%.1f", 60 + (r % 300) / 10}')
mosquitto_pub -h broker.connectmq.com -p 1883 -i "$ID-edge" -q 1 \
-t "connectmq/demo/$ID/plant1/heat/furnace1/temperature" \
-m "{\"value\":$T,\"unit\":\"C\"}"
sleep 2
done
Camada de aplicação, armazenando dados e publicando alertas:
import json
import sqlite3
import sys
import time
import paho.mqtt.client as mqtt
PREFIX = sys.argv[1] # ex.: connectmq/demo/arch-12345
LIMIT_C = 85.0
db = sqlite3.connect("historian.db", check_same_thread=False)
db.execute("CREATE TABLE IF NOT EXISTS readings (ts REAL, topic TEXT, value REAL)")
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(f"{PREFIX}/plant1/+/+/temperature", qos=1)
def on_message(client, userdata, msg):
data = json.loads(msg.payload)
value = float(data["value"])
db.execute("INSERT INTO readings VALUES (?, ?, ?)", (time.time(), msg.topic, value))
db.commit()
print(f"{msg.topic} = {value}")
if value > LIMIT_C:
alert_topic = msg.topic.rsplit("/", 1)[0] + "/alert"
client.publish(alert_topic, json.dumps({"reason": "over_limit", "value": value}), qos=1)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"{PREFIX.split('/')[-1]}-historian")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
Execute-o com o prefixo impresso pelo loop da borda, por exemplo python historian.py connectmq/demo/arch-12345. Repare no que nunca acontece: o historiador não conhece o endereço IP do forno, e o loop da borda não sabe que o historiador existe. Você poderia adicionar um dashboard, um segundo historiador ou um modelo de ML como novos subscribers sem tocar em nenhum dos dois. Em produção, leve os dois lados para a porta 8883 com TLS e credenciais do ConnectMQ obtidas no portal, e mantenha os dados reais da planta fora do servidor MQTT público, que qualquer pessoa pode ler.
Escolhendo onde o broker roda
A camada de broker pode rodar on-premises, em uma DMZ, na nuvem ou em uma combinação desses lugares. Uma planta única com isolamento rígido pode manter um broker local. Organizações com várias plantas, como uma indústria com unidades em Campinas, Joinville e Manaus, normalmente querem um broker central que todas as plantas alcancem com conexões de saída. Rodá-lo por conta própria significa patches, renovação de certificados, monitoramento e planejamento de capacidade. Um broker MQTT gerenciado elimina esse trabalho, e nosso guia de broker MQTT na nuvem compara os modelos de hospedagem.
O ConnectMQ foi projetado para ser a camada de broker nessa arquitetura. Ele suporta MQTT 3.1.1 e 5.0 sobre TCP 1883, TLS 8883, WebSocket 8083 e WebSocket seguro 8084, para que gateways de borda e aplicações de navegador se conectem ao mesmo namespace. Ele detecta topics ISA-95 e de Unified Namespace, decodifica Sparkplug B e o republica em topics ISA-95, e oferece uma visão de dispositivos por nível ISA-95, um explorador de topics ao vivo e regras de alerta por limite. As integrações com historiadores, bancos de dados e dashboards seguem o padrão acima: ferramentas como Node-RED, Telegraf ou seus próprios subscribers se conectam ao ConnectMQ como clients MQTT. As opções de implantação vão do Serverless gratuito a clusters Dedicated e BYOC na sua própria conta de nuvem. Para o panorama industrial completo, leia o guia de IoT Industrial com MQTT.
Comece com o ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Aponte um gateway de borda e uma aplicação para ele e você terá as quatro camadas da sua arquitetura IIoT funcionando em uma tarde.
Perguntas frequentes
Quais são as camadas de uma arquitetura IIoT?
Uma referência prática usa quatro camadas: dispositivos que medem e controlam, gateways de borda que coletam e convertem dados, um broker que roteia mensagens e mantém o estado, e aplicações que visualizam, armazenam e analisam.
Por que o MQTT é usado como camada de mensageria na IIoT?
O MQTT é leve, orientado a eventos e usa conexões de saída, por isso funciona bem em redes de planta segmentadas. Seu modelo publish/subscribe permite que muitas aplicações usem os mesmos dados sem integrações ponto a ponto.
O processamento deve acontecer na borda ou na nuvem?
Filtragem crítica em tempo, conversão de protocolo e buffer pertencem à borda. Analytics entre máquinas e entre plantas, armazenamento de longo prazo e integração com o negócio normalmente pertencem à camada de aplicação, muitas vezes na nuvem.
Como o modelo Purdue se relaciona com esta arquitetura IIoT?
O modelo Purdue descreve níveis de segurança de rede, enquanto esta arquitetura descreve o fluxo de dados. Eles se complementam: os dispositivos ficam nos níveis inferiores do Purdue, os gateways de borda no nível da planta e o broker na DMZ ou na nuvem.
