Los proyectos IoT de ciudad inteligente suelen empezar como pilotos separados, uno para el alumbrado público, otro para los contenedores y otro para la calidad del aire, y después tienen dificultades para compartir datos. Esta guía explica una arquitectura a escala de ciudad en la que cada dominio publica en una capa de mensajería MQTT común, de modo que puedas añadir servicios sin construir un nuevo silo cada vez. Verás las capas, una jerarquía de topics práctica, las opciones de conectividad y las decisiones de seguridad y escalado que importan.
El problema de los pilotos urbanos en silos
Una ciudad típica acaba con un portal del proveedor de alumbrado, un panel de recogida de residuos y una plataforma de monitorización ambiental, cada uno con su propio modelo de datos, inicio de sesión y formato de exportación. Combinarlos, por ejemplo para atenuar las luces cuando la calidad del aire es mala o desviar los camiones de recogida alrededor de unas obras, se convierte cada vez en un proyecto de integración.
Una capa de mensajería compartida cambia el punto de partida. Si cada sistema publica sus eventos y estados en un broker bajo un espacio de nombres común, cualquier aplicación nueva puede suscribirse a lo que necesite. Los proveedores siguen suministrando dispositivos y software especializado; simplemente acuerdan publicar en el backbone de la ciudad y leer de él. Si necesitas repasar el papel del broker, lee qué hace un broker MQTT.
Arquitectura IoT de ciudad inteligente en cinco capas
| Capa | Qué contiene | Tecnologías típicas |
|---|---|---|
| Dispositivos | Controladores de farola, sensores de llenado de contenedores, estaciones de calidad del aire, discos de aparcamiento | Microcontroladores, nodos de luminaria NEMA/Zhaga, sensores ultrasónicos y ópticos |
| Redes de campo | Enlaces de radio de bajo consumo y celulares | LoRaWAN, NB-IoT, LTE-M, Wi-Fi en edificios, fibra hasta los armarios |
| Gateways y servidores de red | Decodifican los payloads de radio, traducen protocolos | Servidores de red LoRaWAN, gateways edge, conversores de protocolo |
| Backbone de mensajería | Enruta eventos entre productores y consumidores | Broker MQTT con TLS, topics estructurados |
| Aplicaciones | Paneles, analítica, lógica de control, datos abiertos | Node-RED, bases de datos de series temporales, mapas SIG, servicios a medida |
Una capa de aplicación cada vez más habitual es un gemelo digital 3D del distrito, en el que farolas, contenedores y estaciones cambian de color según los mismos topics MQTT que leen los paneles.
El broker se sitúa en el centro a propósito. Las redes de campo y las aplicaciones cambian a ritmos distintos; desacoplarlas mediante publicación/suscripción significa que una nueva herramienta de analítica de calidad del aire no exige ningún cambio en los sensores.
Tres dominios de ejemplo
Alumbrado público inteligente
Los controladores de farola informan del consumo, las horas de funcionamiento y las averías, y aceptan órdenes de atenuación. Los topics típicos incluyen un state retenido con el nivel de atenuación actual y un topic de órdenes set que usa el servicio de programación. Los eventos de avería, como un driver averiado, se convierten automáticamente en órdenes de mantenimiento cuando un suscriptor los recoge. Nuestro artículo sobre iluminación inteligente con MQTT cubre en detalle los patrones de órdenes y estado.
Nivel de llenado de los contenedores
Sensores ultrasónicos o de radar dentro de los contenedores informan del porcentaje de llenado unas cuantas veces al día por LoRaWAN o NB-IoT. Un servicio de planificación de rutas se suscribe a todos los contenedores de un distrito y programa la recogida de los que superan un umbral. Aquí el valor de MQTT tiene menos que ver con la latencia y más con el desacoplamiento: el planificador de rutas, el portal de datos abiertos y el panel de limpieza leen los mismos niveles de llenado retenidos.
Monitorización de la calidad del aire
Las estaciones miden partículas, dióxido de nitrógeno, temperatura y humedad. Los datos alimentan mapas públicos, alertas sanitarias e investigación, algo especialmente relevante en ciudades como Santiago, Bogotá o Ciudad de México. El mismo enfoque de medición y publicación que se usa en interiores en un monitor de calidad del aire interior escala al nivel de la calle, con más atención a la calibración, la calefacción de la carcasa y la validación de datos.
El aparcamiento es un cuarto dominio habitual, descrito de principio a fin en nuestro plano de aparcamiento inteligente IoT.
Una jerarquía de topics para toda la ciudad
Un espacio de nombres compartido es el acuerdo más valioso de todo el proyecto. Una estructura que ha funcionado bien sigue el patrón: primero el dominio, después la geografía y por último el activo:
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 qué el dominio primero? Porque la responsabilidad sigue a los dominios. El departamento de alumbrado es responsable de city/lighting/#, lo que facilita razonar sobre el alcance de las credenciales, las auditorías y los contratos con proveedores. Las aplicaciones que necesitan la geografía pueden suscribirse igualmente a varios dominios: city/+/harbour/# devuelve todo lo del distrito del puerto.
Reglas que conviene dejar por escrito desde el principio:
- Cada payload es JSON con una marca de tiempo y unidades explícitas en los nombres de las claves.
- Los estados se retienen; los eventos y las órdenes no.
- Los ID de activo coinciden con el inventario de activos de la ciudad, no con los números de serie del proveedor.
- Las órdenes usan siempre el sufijo
/sety solo las publican los servicios designados.
Conectividad: cómo llevar los datos al broker
La mayoría de los sensores urbanos funcionan con batería y están lejos de cualquier Wi-Fi, así que la red de campo suele ser LoRaWAN o IoT celular. Ninguna de las dos exige que cada sensor hable MQTT por sí mismo:
- Los sensores LoRaWAN envían pequeños payloads binarios a gateways situados en azoteas; un servidor de red los decodifica y los publica en MQTT. Operar el tuyo propio con ChirpStack y MQTT es una opción habitual para los ayuntamientos que quieren controlar su red.
- Los dispositivos NB-IoT y LTE-M pueden abrir una conexión MQTT directamente sobre TLS, lo que encaja con activos alimentados por red, como los controladores de farola o las estaciones de aire.
- Los activos cableados en armarios y edificios se conectan mediante gateways edge que traducen Modbus o protocolos del proveedor.
En cualquier caso, el broker recibe datos limpios y decodificados. Un efecto secundario útil es que el número de conexiones se mantiene moderado: miles de sensores LoRaWAN pueden llegar a través de un puñado de conexiones del servidor de red.
Consumir los datos de la ciudad: un pequeño ejemplo
Cualquier aplicación es simplemente otro cliente MQTT. Este suscriptor en Python, con paho-mqtt 2.x, vigila todas las estaciones de calidad del aire y señala las lecturas que superan un umbral. Pruébalo contra el servidor MQTT público gratuito con tu propio prefijo; recuerda que es solo para pruebas y prototipos, no para datos de producción:
import json
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/c9d1e4" # tu propio id aleatorio
LIMIT = 25.0 # umbral de ejemplo para PM2.5 en 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}'
El prefijo de demostración ya ocupa tres niveles, así que el ejemplo prescinde de la raíz city para no superar el límite de ocho niveles del servidor público; en un broker privado usarías la ruta completa city/air/.... En producción, los umbrales de alerta también pueden residir en el portal del broker: ConnectMQ ofrece reglas de alerta por umbral y un registro de alertas, mientras que la lógica más elaborada corresponde a Node-RED o a tus propios servicios conectados como clientes.
Seguridad y gobernanza
La infraestructura urbana es infraestructura crítica, y la capa de mensajería debe tratarse como tal:
- TLS en todas partes. Puerto 8883 para dispositivos y gateways, 8084 de WebSocket seguro para los paneles en el navegador.
- Credenciales únicas por gateway o servicio. Nunca compartas un mismo inicio de sesión entre proveedores. Los client ID vinculados a credenciales dificultan la suplantación.
- Rutas de órdenes separadas. Solo el servicio de programación debe publicar órdenes de alumbrado; los proveedores y los paneles deben limitarse a leer el estado.
- Aislamiento cuando sea necesario. Los dominios sensibles pueden residir en un broker separado o en un clúster dedicado en lugar de compartirlo con datos públicos.
- Datos abiertos mediante publicación, no mediante acceso. Publica conjuntos de datos depurados en el portal de datos abiertos en lugar de repartir credenciales del broker.
Nuestra guía de buenas prácticas de seguridad MQTT profundiza en credenciales, TLS y monitorización.
Decisiones de escalado y alojamiento
Los proyectos urbanos crecen durante años desde un distrito piloto hasta toda la ciudad, así que elige un modelo de alojamiento que crezca con ellos. Operar tu propio clúster de brokers es posible, pero convierte a la ciudad en responsable de los parches, los certificados, la monitorización y la capacidad. Un broker MQTT gestionado traslada ese trabajo al proveedor. ConnectMQ ofrece planes serverless compartidos para los pilotos, clústeres dedicados aislados para producción y despliegues BYOC que se ejecutan en la propia cuenta cloud de la ciudad cuando las normas de residencia de datos lo exigen. Para una comparativa más amplia de modelos de alojamiento, consulta la guía de broker MQTT en la nube.
Casos de uso relacionados, como la monitorización de la cadena de frío para la logística municipal de alimentos y vacunas, siguen el mismo patrón, y la guía de automatización IoT reúne proyectos para edificios, explotaciones agrícolas y energía.
Lista de preparación para el IoT de ciudad inteligente
- Un espacio de nombres de topics documentado con dominio, distrito, tipo de activo e ID.
- Una convención de payload con marcas de tiempo y unidades.
- Un inventario de activos que asocie los ID con ubicaciones y responsables.
- Redes de campo elegidas por dominio y puenteadas a MQTT mediante gateways.
- Credenciales por gateway y servicio, TLS en cada conexión.
- Una lista clara de qué servicios pueden publicar órdenes.
- Monitorización de la disponibilidad de los dispositivos y de los niveles de batería.
- Un plan de alojamiento que escale del piloto a toda la ciudad.
Construye el backbone de datos de tu ciudad en ConnectMQ
Arranca un distrito piloto en un broker Serverless gratuito, valida el modelo de topics con sensores reales y después pasa a un despliegue Dedicated o BYOC para producción. Regístrate en app.connectmq.com, sin tarjeta de crédito, y observa cómo aparecen tus primeros topics urbanos en el explorador de topics en vivo.
Preguntas frecuentes
¿Los sensores de una ciudad inteligente tienen que admitir MQTT directamente?
No. La mayoría de los sensores de batería usan LoRaWAN o NB-IoT, y un servidor de red o un gateway decodifica sus payloads y los publica en el broker MQTT en su nombre.
¿Por qué poner el dominio antes que el distrito en el topic?
La responsabilidad y el acceso suelen seguir a los dominios, como el alumbrado o los residuos. Los topics con el dominio primero facilitan asignar responsabilidades sin impedir las suscripciones con comodín a escala de distrito.
¿Puede un solo broker dar servicio a todos los departamentos municipales?
Sí, siempre que cada departamento use sus propias credenciales y su propio subárbol de topics. Los sistemas muy sensibles pueden seguir ubicándose en un broker separado o en un clúster dedicado.
¿Cómo debe publicar una ciudad los datos abiertos de sus sensores?
Ejecuta un suscriptor que depure, agregue y publique conjuntos de datos en el portal de datos abiertos. No repartas credenciales del broker al público.
