Qué es
El Device Twin es un documento JSON almacenado en Azure IoT Hub que actúa como representación persistente de cada dispositivo IoT del sistema. No es un flujo de mensajes, sino un estado: existe aunque el dispositivo esté desconectado, y se sincroniza automáticamente en el momento en que el CM4 recupera conectividad.
Cada Pod IoT de IN-SIGHT tiene su propio Device Twin con tres secciones independientes: tags (metadatos de flota), desired properties (configuración enviada por la nube) y reported properties (estado reportado por el dispositivo). La divergencia entre desired y reported indica exactamente qué cambios están pendientes de aplicarse en el dispositivo.
Principio de diseño: El Device Twin desacopla el canal de configuración del canal de telemetría. Los parámetros del EKF, los umbrales de alerta y la versión de firmware no viajan en el flujo de datos: se gestionan de forma independiente, con confirmación explícita de aplicación por parte del dispositivo.
Estructura del Device Twin en IN-SIGHT
Cada Pod IoT dispone de un twin estructurado con las siguientes secciones:
{
"tags": {
"vehicleId": "TMB-5000-04",
"subsystem": "bogie-delantero",
"installDate": "2025-11-12",
"firmwareGroup": "stable"
},
"properties": {
"desired": {
"ekf": {
"processNoise": 0.001,
"measurementNoise": 0.05,
"alertThresholdSigma": 3.5
},
"sampling": {
"rateHz": 6667,
"batchSeconds": 30
},
"firmware": {
"version": "2.4.1",
"url": "https://ota.in3-insight.cloud/fw/2.4.1.bin",
"sha256": "e3b0c44298fc..."
},
"$version": 47
},
"reported": {
"firmware": { "version": "2.4.0" },
"sensors": {
"imu": "ok",
"temperature": "ok",
"lastCalibration": "2025-12-01T08:30:00Z"
},
"connectivity": {
"rssi": -67,
"lastSeen": "2026-06-19T14:22:10Z"
},
"$version": 46
}
}
}
La diferencia de $version entre desired (47) y reported (46) indica que hay un cambio de firmware pendiente de confirmar. El Portal IN-SIGHT muestra este estado como «actualización en progreso».
Flujo OTA — Actualización de firmware
Las actualizaciones de firmware se coordinan íntegramente a través del Device Twin, sin canal adicional:
- Publicación: El Portal IN-SIGHT escribe la nueva versión, URL y hash SHA-256 en
desired.firmware.
- Notificación: IoT Hub notifica al CM4 del cambio en desired properties vía MQTT en tiempo real.
- Descarga y verificación: El CM4 descarga el binario desde la URL firmada, verifica el hash SHA-256 y lo almacena en una partición alternativa.
- Aplicación: Al siguiente ciclo de mantenimiento programado (o inmediatamente si la versión es crítica), el CM4 hace swap de partición y reinicia.
- Confirmación: Tras el reinicio, el CM4 actualiza
reported.firmware.version. El Portal detecta la convergencia y marca la actualización como completada.
Rollback automático: Si el CM4 no confirma la nueva versión en el plazo configurado (por defecto 30 minutos), el sistema restaura automáticamente la partición anterior y registra el evento como fallo de OTA en el historial del vehículo.