Projetos de cidade inteligente IoT geralmente começam como pilotos separados, um para a iluminação pública, um para as lixeiras, um para a qualidade do ar, e depois têm dificuldade para compartilhar dados. Este guia explica uma arquitetura em escala municipal na qual cada domínio publica em uma camada de mensageria MQTT comum, para que você possa adicionar serviços sem criar um novo silo a cada vez. Você verá as camadas, uma hierarquia de topics prática, as opções de conectividade e as decisões de segurança e escala que importam.
O Problema dos Pilotos Municipais em Silos
Uma prefeitura típica, seja em uma capital ou em um município do interior, acaba com um portal do fornecedor de iluminação, um dashboard de coleta de lixo e uma plataforma de monitoramento ambiental, cada um com seu próprio modelo de dados, login e formato de exportação. Combiná-los, por exemplo, para reduzir a intensidade da iluminação quando a qualidade do ar está ruim ou desviar os caminhões de coleta de obras viárias, vira um projeto de integração toda vez.
Uma camada de mensageria compartilhada muda o padrão. Se cada sistema publica seus eventos e estados em um broker sob um namespace comum, qualquer nova aplicação pode assinar aquilo de que precisa, inclusive um gêmeo digital da cidade que espelhe iluminação, resíduos e qualidade do ar em tempo real. Os fornecedores continuam fornecendo dispositivos e software especializado; eles apenas concordam em publicar no backbone da cidade e ler dele. Se precisar relembrar o papel do broker, leia o que faz um broker MQTT.
Arquitetura IoT de Cidade Inteligente em Cinco Camadas
| Camada | O que fica nela | Tecnologias típicas |
|---|---|---|
| Dispositivos | Controladores de luminárias, sensores de enchimento de lixeiras, estações de qualidade do ar, discos de estacionamento | Microcontroladores, nós de luminária NEMA/Zhaga, sensores ultrassônicos e ópticos |
| Redes de campo | Enlaces de rádio de baixo consumo e celulares | LoRaWAN, NB-IoT, LTE-M, Wi-Fi em edifícios, fibra até os armários |
| Gateways e network servers | Decodificam payloads de rádio, traduzem protocolos | Network servers LoRaWAN, gateways de borda, conversores de protocolo |
| Backbone de mensageria | Roteia eventos entre produtores e consumidores | Broker MQTT com TLS, topics estruturados |
| Aplicações | Dashboards, análises, lógica de controle, dados abertos | Node-RED, bancos de dados de séries temporais, mapas GIS, serviços próprios |
O broker fica no meio de propósito. Redes de campo e aplicações mudam em ritmos diferentes; desacoplá-las por publish/subscribe significa que uma nova ferramenta de análise da qualidade do ar não exige nenhuma alteração nos sensores.
Três Domínios de Exemplo
Iluminação pública inteligente
Os controladores das luminárias reportam consumo de energia, horas de funcionamento e falhas, e aceitam comandos de dimerização. Os topics típicos incluem um state retido com o nível de dimerização atual e um topic de comando set usado pelo serviço de agendamento. Eventos de falha, como um driver queimado, viram chamados de manutenção automaticamente quando um subscriber os captura. Nosso artigo sobre iluminação inteligente com MQTT cobre em detalhes os padrões de comando e estado.
Nível de enchimento das lixeiras
Sensores ultrassônicos ou de radar dentro das lixeiras reportam o percentual de enchimento algumas vezes por dia via LoRaWAN ou NB-IoT. Um serviço de planejamento de rotas assina todas as lixeiras de um distrito e programa a coleta das que estão acima de um limite. Aqui, o valor do MQTT tem menos a ver com latência e mais com desacoplamento: o planejador de rotas, o portal de dados abertos e o dashboard de limpeza urbana leem os mesmos níveis de enchimento retidos.
Monitoramento da qualidade do ar
As estações medem material particulado, dióxido de nitrogênio, temperatura e umidade. Os dados alimentam mapas públicos, alertas de saúde e pesquisas. A mesma abordagem de medição e publicação usada em ambientes internos em um monitor de qualidade do ar interno escala para o nível da rua, com mais atenção à calibração, ao aquecimento do invólucro e à validação dos dados.
O estacionamento é um quarto domínio comum, descrito de ponta a ponta em nosso roteiro de estacionamento inteligente IoT.
Uma Hierarquia de Topics para Toda a Cidade
Um namespace compartilhado é o acordo mais valioso de todo o projeto. Um layout que tem funcionado bem segue o padrão: primeiro o domínio, depois a geografia, depois o ativo:
city/<domain>/<district>/<asset-type>/<asset-id>/<signal>
city/lighting/north/lamp/L-10442/state retained {"on":true,"dim":60,"watts":38}
city/lighting/north/lamp/L-10442/state/set {"dim":30}
city/lighting/north/lamp/L-10442/fault {"code":"DRIVER_FAIL","ts":1760600000}
city/waste/centre/bin/B-2210/fill retained {"pct":82,"ts":1760600000}
city/air/harbour/station/AQ-07/pm25 retained {"ugm3":14.2,"ts":1760600000}
city/parking/old-town/summary retained {"free":112,"total":420}
Por que o domínio primeiro? Porque a responsabilidade segue os domínios. O departamento de iluminação é responsável por city/lighting/#, o que facilita raciocinar sobre o escopo de credenciais, auditorias e contratos com fornecedores. Aplicações que precisam de geografia ainda podem assinar entre domínios: city/+/harbour/# retorna tudo do distrito do porto.
Regras que vale registrar por escrito desde o início:
- Todo payload é JSON com um timestamp e unidades explícitas nos nomes das chaves.
- Estados são retidos; eventos e comandos não.
- Os IDs de ativos correspondem ao cadastro de ativos da cidade, não aos números de série dos fornecedores.
- Comandos sempre usam o sufixo
/sete somente serviços designados os publicam.
Conectividade: Levando os Dados ao Broker
A maioria dos sensores urbanos é alimentada por bateria e fica longe do Wi-Fi, então a rede de campo costuma ser LoRaWAN ou IoT celular. Nenhuma delas exige que cada sensor fale MQTT por conta própria:
- Sensores LoRaWAN enviam pequenos payloads binários para gateways nos telhados; um network server os decodifica e publica no MQTT. Operar o seu próprio com ChirpStack e MQTT é uma escolha comum para prefeituras que querem controle sobre sua rede.
- Dispositivos NB-IoT e LTE-M podem abrir uma conexão MQTT diretamente sobre TLS, o que combina com ativos ligados à rede elétrica, como controladores de luminárias ou estações de ar.
- Ativos cabeados em armários e edifícios se conectam por gateways de borda que traduzem Modbus ou protocolos proprietários.
De qualquer forma, o broker recebe dados limpos e decodificados. Um efeito colateral útil é que o número de conexões continua modesto: milhares de sensores LoRaWAN podem chegar por um punhado de conexões de network servers.
Consumindo Dados da Cidade: Um Pequeno Exemplo
Qualquer aplicação é apenas mais um cliente MQTT. Este subscriber em Python, usando paho-mqtt 2.x, observa todas as estações de qualidade do ar e sinaliza leituras acima de um limite. Teste-o no servidor MQTT público (gratuito) com seu próprio prefixo, lembrando que ele serve para testes e protótipos, nunca para dados de produção:
import json
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/c9d1e4" # seu próprio id aleatório
LIMIT = 25.0 # limite de exemplo para PM2.5 em ug/m3
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{PREFIX}/air/+/station/+/pm25", qos=1)
def on_message(client, userdata, msg):
parts = msg.topic.split("/")
district, station = parts[-4], parts[-2]
reading = json.loads(msg.payload)
if reading["ugm3"] > LIMIT:
print(f"High PM2.5 in {district} at {station}: {reading['ugm3']}")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="air-watch-c9d1e4")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
mosquitto_pub -h broker.connectmq.com -p 1883 -i aq-c9d1e4 -r -q 1 \
-t connectmq/demo/c9d1e4/air/harbour/station/AQ-07/pm25 -m '{"ugm3":31.5,"ts":1760600000}'
O prefixo de demonstração já usa três níveis, então o exemplo descarta a raiz city para ficar dentro do limite de oito níveis do servidor MQTT público; em um broker privado você usaria o caminho completo city/air/.... Em produção, os limites de alerta também podem ficar no portal do broker: o ConnectMQ oferece regras de alerta por limite e um log de alertas, enquanto lógicas mais elaboradas pertencem ao Node-RED ou aos seus próprios serviços conectados como clientes.
Segurança e Governança
A infraestrutura urbana é infraestrutura crítica, e a camada de mensageria precisa ser tratada assim:
- TLS em todo lugar. Porta 8883 para dispositivos e gateways, 8084 com WebSocket seguro para dashboards no navegador.
- Credenciais únicas por gateway ou serviço. Nunca compartilhe um login entre fornecedores. Client IDs vinculados às credenciais dificultam a falsificação de identidade.
- Caminhos de comando separados. Somente o serviço de agendamento deve publicar comandos de iluminação; fornecedores e dashboards devem apenas ler o estado.
- Isolamento quando necessário. Domínios sensíveis podem ficar em um broker separado ou em um cluster dedicado, em vez de compartilhar um com dados públicos.
- Dados abertos por publicação, não por acesso. Publique conjuntos de dados selecionados no portal de dados abertos em vez de distribuir credenciais do broker, e remova dados pessoais, como placas de veículos, em conformidade com a LGPD.
Nosso guia de boas práticas de segurança MQTT aprofunda credenciais, TLS e monitoramento.
Decisões de Escala e Hospedagem
Projetos municipais crescem de um distrito piloto para a cidade inteira ao longo de anos, então escolha um modelo de hospedagem que cresça junto. Operar seu próprio cluster de brokers é possível, mas torna a cidade responsável por patches, certificados, monitoramento e capacidade. Um broker MQTT gerenciado transfere esse trabalho para o provedor. O ConnectMQ oferece planos serverless compartilhados para pilotos, clusters dedicados e isolados para produção e implantações BYOC que rodam na própria conta de nuvem da cidade quando regras de residência de dados exigem. Para uma comparação mais ampla dos modelos de hospedagem, veja o guia de broker MQTT na nuvem.
Casos de uso relacionados, como o monitoramento da cadeia de frio para a logística municipal de alimentos e vacinas, seguem o mesmo padrão, e o guia de automação IoT reúne projetos para edifícios, fazendas e energia.
Checklist de Prontidão para Cidade Inteligente IoT
- Um namespace de topics documentado com domínio, distrito, tipo de ativo e ID.
- Uma convenção de payload com timestamps e unidades.
- Um cadastro de ativos que associe IDs a localizações e responsáveis.
- Redes de campo escolhidas por domínio e conectadas ao MQTT por gateways.
- Credenciais por gateway e serviço, TLS em todas as conexões.
- Uma lista clara de quais serviços podem publicar comandos.
- Monitoramento da disponibilidade dos dispositivos e dos níveis de bateria.
- Um plano de hospedagem que escale do piloto para a cidade inteira.
Construa o Backbone de Dados da Sua Cidade no ConnectMQ
Comece um distrito piloto em um broker Serverless gratuito, comprove o modelo de topics com sensores reais e depois migre para uma implantação dedicada ou BYOC em produção. Cadastre-se em app.connectmq.com, sem cartão de crédito, e veja os primeiros topics da sua cidade surgirem no explorador de topics ao vivo.
Perguntas frequentes
Os sensores de cidade inteligente precisam suportar MQTT diretamente?
Não. A maioria dos sensores a bateria usa LoRaWAN ou NB-IoT, e um network server ou gateway decodifica seus payloads e os publica no broker MQTT em nome deles.
Por que colocar o domínio antes do distrito no topic?
A responsabilidade e o acesso geralmente seguem os domínios, como iluminação ou resíduos. Topics com o domínio primeiro facilitam atribuir responsabilidades e ainda permitem assinaturas com wildcard por distrito.
Um único broker pode atender todos os departamentos da cidade?
Sim, desde que cada departamento use suas próprias credenciais e sua própria subárvore de topics. Sistemas altamente sensíveis ainda podem ficar em um broker separado ou em um cluster dedicado.
Como uma cidade deve publicar dados abertos de seus sensores?
Execute um subscriber que selecione, agregue e publique os conjuntos de dados no portal de dados abertos. Não distribua credenciais do broker ao público.
