MQTT / TLS 1.3 — IN-SIGHT

Qué es MQTT

MQTT (Message Queuing Telemetry Transport, ISO/IEC 20922) es un protocolo de mensajería publish-subscribe diseñado en 1999 por Andy Stanford-Clark (IBM) para telemetría en oleoductos con conexiones satelitales de alta latencia y bajo ancho de banda. Hoy es el estándar de facto para comunicación IoT.

Su diseño es deliberadamente minimalista: un mensaje MQTT ocupa como mínimo 2 bytes de cabecera, frente a los cientos de bytes de HTTP/REST. Un broker central (en IN-SIGHT, Azure IoT Hub actúa como broker) distribuye los mensajes a los suscriptores del topic correspondiente.

MQTT define tres niveles de Quality of Service (QoS): QoS 0 (at-most-once, dispara y olvida), QoS 1 (at-least-once, confirmación de recepción) y QoS 2 (exactly-once, handshake de 4 pasos). IN-SIGHT usa QoS 1 para telemetría: acepta duplicados ocasionales a cambio de garantizar que ningún paquete de datos se pierde en una desconexión.

Qué es TLS 1.3

TLS 1.3 (RFC 8446, 2018) es la versión actual del protocolo de seguridad de la capa de transporte. Respecto a TLS 1.2, introduce mejoras críticas: el handshake se completa en 1 round-trip (vs. 2 en TLS 1.2), todos los cipher suites débiles están eliminados, y el forward secrecy (ECDHE) es obligatorio — lo que significa que aunque la clave privada de un dispositivo se comprometa en el futuro, los datos pasados no pueden descifrarse.

En combinación con mTLS (mutual TLS), tanto el servidor (IoT Hub) como el cliente (Pod CM4) se autentican mutuamente con certificados X.509, eliminando la posibilidad de ataques man-in-the-middle.

Rol en IN-SIGHT

Telemetría periódica: Cada 30 s el CM4 publica un paquete JSON compacto (< 512 bytes) con las métricas de salud agregadas del intervalo. En condición normal, el Pod consume ~2–4 Kbps.
Alertas inmediatas: Cuando el EKF detecta una anomalía, el Pod publica un mensaje de alerta al instante, sin esperar el ciclo de 30 s. Las propiedades del mensaje activan el enrutamiento a la cola de alertas de Azure IoT Hub.
Resiliencia en túneles: Si la conexión se pierde (túnel, zona sin cobertura), el broker guarda los mensajes pendientes (QoS 1, sesión persistente). El Pod los retransmite en cuanto se restaura la conexión.
Nomenclatura de topics: in3/{fleet-id}/{vehicle-id}/{pod-id}/{metric-type} — la estructura jerárquica permite suscripción selectiva desde el portal de operaciones sin procesar telemetría de toda la flota.

Seguridad por diseño: Cada Pod tiene su propio par de claves X.509 generado en fábrica y almacenado en un TPM (Trusted Platform Module) soldado al CM4. Las claves nunca salen del dispositivo. La revocación de un Pod compromisado no afecta al resto de la flota.

── Topic estructura IN-SIGHT ───────────────────────────
in3/TMB/5042/pod-a/vibration     ← métricas bogie
in3/TMB/5042/pod-b/door-cycle    ← métricas puertas
in3/TMB/5042/pod-a/alert         ← alertas EKF
in3/TMB/5042/$twin               ← Device Twin sync

── Payload telemetría normal (ejemplo) ─────────────────
{
  "ts": "2026-06-17T10:22:05.412Z",
  "v":  "1.4.2",
  "rms": 0.42,
  "peak_freq": 87.3,
  "temp_c": 38.1,
  "ekf_innov": 0.031
}