Internet de las cosas (IoT)
Dispositivo IoT sin datos: ¿cuándo el silencio debe generar una alerta?
Un panel sigue mostrando la última temperatura recibida de un sensor. La pantalla parece normal, el valor está dentro del rango esperado y no se abrió ninguna alerta. Sin embargo, hay una pregunta que cambia por completo la interpretación de esa información: ¿cuándo se produjo esa medición?
Si el dispositivo debía transmitir cada cinco minutos y lleva dos horas en silencio, el problema no es el valor mostrado. Es la ausencia de una nueva lectura.
Este escenario es común en operaciones de Internet de las cosas (IoT). El último dato conocido puede seguir disponible incluso después de que el sensor, el enlace, la puerta de enlace o el servicio de ingesta dejó de funcionar. Sin un criterio de actualidad, la interfaz presenta la historia como si fuera el estado actual.
El reto no consiste solo en detectar que un dispositivo dejó de enviar datos. La operación debe diferenciar un período normal de silencio, un retraso tolerable, una interrupción de comunicación y una falla que exige respuesta inmediata.
Una alerta por ausencia de datos solo es útil cuando conoce el comportamiento esperado del dispositivo.
El silencio no significa lo mismo en todos los dispositivos
Algunos equipos envían mediciones de forma continua. Otros publican en intervalos de minutos u horas. Hay dispositivos que permanecen en modo de bajo consumo y solo se despiertan para medir y transmitir. También existen equipos que solo comunican un cambio de estado o un evento.
Aplicar el mismo límite de tiempo a todos estos casos produce dos problemas.
El primero es la falsa alarma. Si un medidor transmite una vez por hora, marcarlo como no disponible a los diez minutos genera un evento durante el funcionamiento normal.
El segundo es el retraso. Si un sensor crítico debe publicar cada minuto, esperar varias horas antes de señalar su ausencia puede dejar a la operación sin la información necesaria.
La frecuencia de transmisión debe tratarse como una característica operativa del activo. Debe estar asociada al modelo, a la aplicación, al modo de funcionamiento y a la criticidad de la información.
Conexión, mensaje y medición son estados distintos
Tres condiciones suelen confundirse en una arquitectura IoT.
El dispositivo está conectado
El broker, la puerta de enlace o el servicio de comunicación mantiene una sesión activa con el equipo. Eso indica que existe un canal disponible, pero no prueba que se estén publicando nuevas mediciones.
El dispositivo está enviando mensajes
Los mensajes siguen llegando a la plataforma. Pueden representar mediciones, eventos, señales de control o confirmaciones. La presencia de tráfico no garantiza que la variable necesaria para la operación se esté actualizando.
La medición está actualizada
Se realizó una nueva observación en el intervalo previsto y llegó a la plataforma dentro de la latencia aceptada. Esta es la condición más cercana a la pregunta que el usuario de los datos quiere responder.
MQTT ofrece mecanismos importantes para acompañar la comunicación. Keep Alive define el intervalo máximo entre paquetes de control de una conexión. El mensaje de última voluntad puede informar a otros consumidores cuando una sesión termina de forma anormal [1]. Esos mecanismos ayudan a identificar problemas de conexión.
No sustituyen una regla de actualidad del dato. Un cliente puede mantener la sesión activa y seguir enviando paquetes de control sin publicar la medición esperada. También puede publicar otros temas mientras una variable específica permanece desactualizada.
Por eso, el monitoreo debe observar la sesión y la antigüedad de cada información relevante.
El primer paso es definir el ciclo esperado
Una regla de ausencia de datos comienza con una definición simple: ¿cuándo debería llegar la siguiente información?
Esa respuesta exige al menos cinco elementos.
Frecuencia prevista
Es el intervalo normal entre mediciones o eventos. Puede ser fijo, variar según el modo de operación o depender de un cambio en el proceso monitoreado.
Tolerancia
Es el margen aceptado para retrasos de red, procesamiento, colas, retransmisiones y variaciones del reloj del dispositivo. Una regla exactamente igual al ciclo nominal tiende a generar alertas innecesarias.
Edad máxima del dato
Es el tiempo durante el cual la última medición aún puede utilizarse en la operación. Esta definición depende del proceso, no solo del equipo.
Criticidad
Una lectura ambiental usada para análisis histórico puede admitir un retraso mayor. Un sensor ligado a la protección de un activo puede exigir reacción rápida. El mismo tiempo de silencio puede ser informativo en un caso y crítico en otro.
Comportamiento de recuperación
El dispositivo puede reanudar la transmisión con una nueva lectura o reenviar datos almacenados durante la interrupción. La plataforma debe distinguir la hora de la medición de la hora de recepción.
La ontología SOSA/SSN del W3C diferencia el tiempo al que se aplica una observación del momento en que su resultado quedó disponible [2]. Esa separación es particularmente útil en IoT. Un mensaje recibido ahora puede llevar una medición realizada mucho antes.
Una regla práctica debe considerar más de un reloj
Una estrategia sencilla puede seguir tres marcas de tiempo:
El momento de la medición en el dispositivo. El momento de publicación o paso por la puerta de enlace. El momento de recepción por la plataforma.
Cuando solo existe el tercer horario, el equipo sabe que llegó un mensaje, pero no puede determinar con seguridad cuándo se observó la condición física.
Cuando los tres horarios están disponibles y sincronizados, la investigación puede separar problemas distintos. Una medición antigua recibida ahora sugiere almacenamiento y reenvío. Una medición reciente que tardó en llegar indica latencia en la comunicación o en el procesamiento. La ausencia completa apunta a otra parte de la cadena.
Este análisis también evita que un lote de mensajes retrasados cierre automáticamente un incidente de actualidad. El dispositivo volvió a transmitir, pero la operación tal vez aún no haya recibido una observación reciente.
Cómo convertir el silencio en una alerta útil
Una buena regla no necesita abrir un incidente crítico en el primer retraso. Puede trabajar con etapas.
Estado normal
La última medición permanece dentro del ciclo esperado y la tolerancia definida.
Atención
El dato superó el intervalo nominal, pero aún está dentro de un margen compatible con retrasos conocidos. Este estado puede usarse para seguimiento sin activar toda la cadena de atención.
Alerta
La edad de la medición superó el límite operacional. El incidente debe indicar el dispositivo, la variable afectada, la última hora conocida, la frecuencia esperada y las dependencias relevantes.
Recuperación
Se recibió una nueva medición actual y la condición se mantuvo estable según el criterio definido. Exigir más de una observación válida puede ayudar a evitar aperturas y cierres repetidos en conexiones inestables.
Los límites deben configurarse según cada familia de dispositivos y aplicación. El ejemplo siguiente es solo ilustrativo.
Esos valores no deben copiarse a una operación real. El fabricante, la arquitectura, la conectividad, el proceso y la criticidad deben orientar la configuración.
Los dispositivos que duermen exigen reglas propias
Los dispositivos restringidos pueden operar con poca memoria, procesamiento limitado y energía disponible por un período definido. El RFC 7228 de la Internet Engineering Task Force (IETF) describe distintas clases de limitación energética y reconoce dispositivos que entran temporalmente en modo de bajo consumo [3].
En ese contexto, permanecer desconectado puede ser una elección de diseño.
El monitoreo debe conocer el calendario de actividad. Un dispositivo puede despertar, medir, transmitir y volver a dormir. Durante el intervalo, la plataforma no debe esperar el mismo comportamiento que de un servidor encendido de forma continua.
También es necesario considerar cambios de configuración. Si la frecuencia de transmisión pasa de cinco minutos a una hora para preservar la batería, la regla de ausencia debe acompañar ese cambio. De lo contrario, el ahorro de energía se interpretará como indisponibilidad.
Qué investigar cuando el dato deja de llegar
La alerta de silencio identifica un síntoma. No determina automáticamente la causa.
La investigación puede comenzar con preguntas objetivas:
¿El dispositivo mantiene una sesión activa con el broker o la puerta de enlace? ¿Otros temas o variables del mismo equipo siguen actualizándose? ¿Otros dispositivos ligados a la misma puerta de enlace también quedaron en silencio? ¿La plataforma sigue recibiendo mensajes de otros equipos? ¿Hubo cambio de configuración, firmware o frecuencia de transmisión? ¿Existe indicación de batería baja o falla de alimentación antes del silencio? ¿Hay mensajes almacenados para reenvío cuando vuelve la conexión? ¿El reloj del dispositivo es correcto?
Las respuestas ayudan a separar una falla local de un problema compartido. Si varios sensores conectados a la misma puerta de enlace se detienen al mismo tiempo, debe investigarse la infraestructura común antes de asumir fallas independientes.
Errores comunes en la configuración
Un error frecuente es crear un único límite para todo el parque. Ese enfoque ignora ciclos de transmisión, aplicaciones y criticidades distintas.
Otro error es usar solo el estado de la conexión. Una sesión activa no prueba que llegue la medición necesaria.
También es arriesgado cerrar el incidente con cualquier mensaje recibido. El mensaje puede ser antiguo, pertenecer a otro tema o representar solo un intento de reconexión.
Por último, límites excesivamente sensibles generan fatiga de alertas. Cuando la operación recibe incidentes durante comportamientos normales, pierde confianza en el sistema y puede ignorar un evento relevante.
La actualidad debe formar parte de la calidad del dato
El silencio de un dispositivo no debe tratarse solo como un tema de conectividad. Representa la ausencia de una información dentro del período en que debería estar disponible.
Una estrategia coherente combina frecuencia esperada, tolerancia, criticidad, edad de la medición y comportamiento de recuperación. También separa el estado de la conexión de la actualización de las variables usadas por la operación.
Esta profundización complementa el artículo sobre monitoreo de dispositivos IoT y la comparación entre monitoreo IoT y monitoreo de TI.
Para gestores de TI, telecomunicaciones, infraestructura y operaciones, la pregunta central debe ser específica: ¿qué información debía haber llegado, en qué momento y cuánto tiempo puede aceptarse su ausencia?
El silencio se convierte en una señal operativa cuando la plataforma conoce el ritmo esperado de cada dispositivo.
Sobre Target Solutions
Target Solutions lleva más de 15 años apoyando a organizaciones en la evolución de sus operaciones de infraestructura, monitoreo, observabilidad, automatización e inteligencia operacional. A lo largo de esa trayectoria, participó en proyectos en entornos complejos de telecomunicaciones, tecnología, gobierno, energía y grandes empresas, contribuyendo a aumentar la eficiencia operacional y la confiabilidad de los servicios.
Esa experiencia también incluye proyectos relacionados con Internet de las cosas (IoT), donde la conectividad, la integración tecnológica y el acompañamiento operacional son importantes para transformar dispositivos conectados en soluciones útiles para las organizaciones.
Sobre el autor
Paulo Florêncio de Menezes es cofundador de Target Solutions y lleva más de 15 años en proyectos relacionados con infraestructura, monitoreo, observabilidad, automatización y operaciones de TI y telecomunicaciones.
Se graduó en Procesamiento de Datos por la Universidad Federal de Amazonas (UFAM), tiene un MBA en Gestión Empresarial por la Fundación Dom Cabral (FDC) y un Máster Profesional en Economía por la Fundación Getulio Vargas (FGV).
En su investigación de Máster, desarrolló el IBEOP-IA (Índice Brasileño de Exposición Ocupacional Potencial a la Inteligencia Artificial), investigando la exposición potencial de las ocupaciones brasileñas a las capacidades de la IA mediante la combinación de datos ocupacionales, patentes de inteligencia artificial y técnicas de procesamiento de lenguaje natural.
Referencias
[1] OASIS. MQTT Version 5.0. OASIS Standard, 7 mar. 2019.
[2] W3C. Semantic Sensor Network Ontology. W3C Recommendation, 19 oct. 2017.
[3] BORMANN, Carsten; ERSUE, Mehmet; KERANEN, Ari. Terminology for Constrained-Node Networks. RFC 7228. Internet Engineering Task Force, may. 2014.