Arquitectura

Arquitectura MQTT del Index AMI: telemetría y telegestión de medidores en tiempo real

3 de junio de 2026·7 min lectura

MQTT es el protocolo de mensajería que el Index AMI utiliza para publicar lecturas de medidores y recibir comandos de las Plataformas AMI (HES/MDMS), reguladas en Colombia por la CREG 038. El Index AMI nunca se comunica directamente con las Plataformas AMI: siempre lo hace a través de un broker MQTT que desacopla ambos extremos. Esta guía explica la arquitectura completa: desde cómo los datos salen del medidor hasta cómo llegan a la plataforma de gestión, y cómo las Plataformas AMI pueden telegestionar el dispositivo en tiempo real.

¿Para qué MQTT en el Index AMI?

MQTT no mueve datos: mueve eventos. No es un canal de transferencia masiva ni un protocolo de descarga — es un bus de mensajería donde cada lectura, alarma o cambio de estado se publica como un evento discreto en el momento en que ocurre. En el contexto AMI, MQTT es el mecanismo que permite al Index AMI publicar esos eventos desde el dispositivo hacia cualquier suscriptor MQTT, sin necesidad de una IP fija ni pública. El módem abre la conexión saliente hacia el broker a través de la red celular 4G; por eso funciona detrás del NAT del operador y nunca requiere puertos abiertos ni una dirección estática. Cualquier plataforma suscrita al topic recibe el evento en tiempo real.

MQTT como capa de mensajería

MQTT no reemplaza a TCP — corre sobre él. El Index AMI publica mensajes MQTT que viajan por TCP a través de la red celular 4G LTE. Si el túnel WireGuard VPN está activo, ese TCP circula dentro del túnel cifrado antes de salir a internet. El resultado es una capa de mensajería asíncrona, liviana y confiable sobre una red móvil.

Arquitectura MQTT del Index AMI: el broker interconecta al gateway y a las Plataformas AMI. Ningún extremo se conecta directamente con el otro — todo el tráfico pasa por el broker.

Roles en la arquitectura

La arquitectura MQTT del Index AMI tiene tres actores:

  • Publicador — Index AMI: Publica lecturas del medidor, eventos y estado del dispositivo en los topics configurados. También suscribe topics de comandos para recibir las instrucciones que las Plataformas AMI publican en el broker.
  • Intermediario — Broker MQTT: Recibe y distribuye los mensajes entre publicadores y suscriptores. Puede ser el broker Noatec incluido en el plan de datos eSIM, o un broker propio del cliente (Mosquitto, HiveMQ, EMQX, etc.). Opera en puerto 1883 (TCP) o 8883 (TLS).
  • Suscriptor / Publicador — Plataformas AMI: Suscriben los topics de telemetría para recibir lecturas en tiempo real. También publican comandos (solicitudes de lectura, reinicio, actualización OTA) en los topics del Index AMI.

Flujo de telemetría: del medidor a las Plataformas AMI

Cada vez que el Index AMI realiza una lectura al medidor, publica el resultado en el broker. Las Plataformas AMI, suscritas a ese topic, reciben el dato en tiempo real sin necesidad de solicitarlo activamente.

  1. El Index AMI interroga al medidor vía RS485/RS232 según el intervalo configurado.
  2. Obtiene la lectura (energía activa, reactiva, potencia, tensión, etc.) en formato DLMS/COSEM o Modbus.
  3. Serializa el dato y lo publica en el topic de telemetría del broker.
  4. El broker distribuye el mensaje a todos los suscriptores (Plataformas AMI, HES, MDMS, etc.).
  5. Las Plataformas AMI almacenan, procesan o alarman según las reglas de negocio configuradas.

Telegestión: comandos de las Plataformas AMI al medidor

A través del broker, MQTT permite a las Plataformas AMI enviar instrucciones al Index AMI sin visita técnica. Las Plataformas AMI nunca se conectan directamente al dispositivo: publican los comandos en el broker, y el Index AMI —suscrito a su topic de comandos— los recibe y ejecuta sobre el medidor o sobre sí mismo.

  1. Las Plataformas AMI publican un comando en el topic de comandos del Index AMI (solicitud de lectura inmediata, corte/reconexión, cambio de intervalo, reinicio del dispositivo, actualización de firmware OTA).
  2. El broker MQTT entrega el mensaje al Index AMI.
  3. El Index AMI ejecuta la instrucción: interroga al medidor, activa el relé de corte/reconexión o actualiza su firmware.
  4. El Index AMI publica el resultado de la operación en el topic de respuesta.
  5. Las Plataformas AMI confirman la ejecución sin haber enviado a nadie al sitio.

Estructura de topics MQTT

Los topics organizan el flujo de mensajes. Una convención típica con el Index AMI:

  • Telemetría de lecturas: Lecturas periódicas del medidor (energía, potencia, tensión, corriente).
  • Eventos y alertas: Eventos del dispositivo: Last Gasp (último aliento), temperatura alta y baja (según configuración) y switch de gabinete (según configuración).
  • Estado del dispositivo: Señal LTE (RSSI, RSRP), estado VPN, versión de firmware, uptime.
  • Comandos y respuestas: Comandos desde las Plataformas AMI y respuestas del Index AMI.

Seguridad del canal MQTT

El nivel de seguridad depende de la configuración del transporte:

  • MQTT sobre TLS (puerto 8883) — recomendado: El canal TCP está cifrado con TLS. Requiere certificados CA, cliente y clave privada cargados en el Index AMI. Protege los datos en tránsito incluso si no hay VPN.
  • MQTT sobre TCP + WireGuard VPN: El TCP viaja dentro del túnel VPN cifrado con ChaCha20-Poly1305. Mayor seguridad de extremo a extremo — el broker solo es accesible desde dentro del túnel. Recomendado para infraestructura crítica.

Integración con plataformas de gestión

El broker MQTT actúa como bus de datos entre el Index AMI y cualquier plataforma que soporte el protocolo:

  • HES (Head-End System) — recibe lecturas en tiempo real para almacenamiento y validación.
  • MDMS (Meter Data Management System) — procesa, consolida y distribuye los datos de medición.
  • SCADA / EMS — supervisión operativa y control de la red energética.
  • CIS (Customer Information System) — facturación basada en lecturas automatizadas.
  • EAMS — correlación de eventos y alarmas del medidor.
  • Plataformas BI y analítica — consumo de topics vía MQTT para dashboards y modelos predictivos.

Resumen

  1. MQTT es la capa de mensajería; TCP es el transporte; WireGuard VPN es la capa de cifrado opcional.
  2. El Index AMI publica lecturas y eventos; las Plataformas AMI suscriben y actúan sobre ellos.
  3. Los comandos de las Plataformas AMI viajan por MQTT a través del broker hasta el Index AMI, que los ejecuta sobre el medidor sin visita técnica.
  4. El broker desacopla al Index AMI de la plataforma — cualquier sistema compatible con MQTT puede integrarse.
  5. Se recomienda MQTT sobre TLS (8883) o sobre WireGuard para entornos de infraestructura crítica.