Internet de las cosas (IoT)
Sensor conectado, lectura incorrecta: cómo evaluar la calidad de los datos IoT
Un sensor sigue conectado, publica mensajes en el intervalo previsto y aparece como disponible en el panel. Aun así, la información puede estar equivocada.
Una lectura puede permanecer congelada durante horas, cambiar lentamente por un desvío, llegar con unidad incorrecta o representar un instante muy anterior a la hora mostrada por la plataforma. En todos esos casos, la comunicación funciona. El problema está en la calidad del dato.
Esa diferencia importa porque muchas decisiones operativas dependen de las mediciones producidas en campo. Si la plataforma solo verifica la llegada de los mensajes, una falla silenciosa puede seguir activa sin generar ninguna indicación.
La disponibilidad de la comunicación no prueba la validez de la medición.
Dato recibido y dato útil no son sinónimos
Un mensaje puede llegar al destino y aún presentar problemas en distintos puntos de la cadena.
El sensor puede medir incorrectamente. El firmware puede aplicar una conversión inadecuada. La puerta de enlace puede asociar el valor al equipo equivocado. La integración puede interpretar una unidad de forma distinta. La plataforma puede mostrar una lectura antigua como si fuera actual.
Por eso, la calidad debe evaluarse en capas.
¿El mensaje tiene la estructura esperada? ¿El dispositivo y la variable están identificados correctamente? ¿Se conoce la unidad de medida? ¿El horario de la observación está disponible y es coherente? ¿El valor está dentro de límites físicamente posibles? ¿La variación es compatible con el proceso? ¿La lectura acompaña o contradice otras evidencias del entorno?
Una respuesta positiva en una etapa no elimina las siguientes. Un valor puede respetar el formato y estar dentro del rango, pero permanecer congelado durante un período incompatible con el comportamiento del proceso.
Principales patrones de falla
Las fallas de sensores no aparecen siempre como ausencia total de datos. Una revisión de Sharma et al. organiza distintos tipos de error y técnicas de detección aplicadas a entornos inteligentes [1]. En la práctica operativa, algunos patrones merecen atención especial.
Lectura congelada
El sensor repite exactamente el mismo valor durante un período prolongado. Eso puede indicar bloqueo, falla de actualización o pérdida de comunicación interna.
Sin embargo, la repetición no significa automáticamente defecto. Una variable puede permanecer estable. La regla debe considerar la resolución del instrumento, el comportamiento esperado del proceso y otras mediciones relacionadas.
Desvío gradual
La lectura se aleja lentamente de la condición real. Este comportamiento puede surgir por envejecimiento, cambio de calibración, contaminación o cambio en las condiciones de instalación.
Como el valor sigue variando y puede permanecer dentro de límites amplios, una regla simple por rango puede no detectar el problema.
Valor brusco o pico
Una medición cambia de forma repentina y vuelve poco después. El evento puede ser ruido, falla momentánea, interferencia o una condición física real.
Descartar todo pico elimina evidencias importantes. El monitoreo debe señalar el comportamiento y reunir contexto para la investigación.
Ruido excesivo
Las lecturas oscilan más de lo esperado. La causa puede estar en el sensor, la alimentación, la instalación, la interferencia o el propio proceso medido.
Error de escala o unidad
El valor puede estar correcto en el dispositivo e interpretarse mal en la integración. Celsius y Fahrenheit, voltios y milivoltios, porcentaje y fracción decimal son ejemplos de diferencias capaces de producir resultados plausibles pero equivocados.
Dato antiguo presentado como actual
Un mensaje almacenado durante una interrupción puede llegar después de recuperar la conectividad. Si la plataforma usa solo la hora de recepción, la lectura parece reciente.
La ontología SOSA/SSN del W3C diferencia el tiempo al que se aplica la observación del momento en que su resultado quedó disponible [2]. Esa distinción ayuda a preservar la historia correcta de la medición.
La calidad comienza con un contrato de datos
Antes de configurar alertas, la organización debe definir el significado de cada información.
Ese contrato puede incluir:
Identificador del dispositivo. Variable observada. Unidad de medida. Tipo y precisión del valor. Rango físico posible. Rango operativo esperado. Frecuencia de actualización. Horario de la medición. Indicadores de calidad provistos por el equipo. Tratamiento previsto para valores ausentes o inválidos.
Sin esas definiciones, la plataforma recibe números sin contexto suficiente para evaluar su utilidad.
El protocolo de transporte no resuelve esto solo. La especificación MQTT establece cómo se publican y entregan los mensajes, pero el contenido y el formato del payload los define la aplicación [3]. Dos dispositivos pueden usar MQTT y representar la misma variable con nombres, unidades y estructuras distintas.
Normalizar esos datos exige mapeos explícitos y pruebas por modelo de equipo.
Una verificación en capas reduce conclusiones apresuradas
No existe una única técnica capaz de detectar todos los problemas. Un enfoque práctico combina verificaciones simples y evidencias del proceso.
Validación estructural
Confirma si existen los campos obligatorios, si los tipos son correctos y si el valor puede interpretarse. Los mensajes inválidos deben separarse de las mediciones válidas.
Actualidad
Verifica la edad de la observación. Un valor coherente pero antiguo no representa necesariamente el estado actual.
Rango físico
Compara la lectura con límites imposibles de superar en las condiciones conocidas. Una humedad bajo cero o un porcentaje por encima de cien puede indicar error de escala, unidad o procesamiento.
Rango operativo
Compara el valor con el rango esperado para ese proceso. Salir de ese rango puede representar falla del sensor o un evento real. La alerta debe mantener visible esa ambigüedad.
Tasa de variación
Evalúa cuánto cambió la medición en un intervalo determinado. Un cambio físicamente improbable puede indicar ruido, error de conversión o problema de instrumentación.
Lectura congelada
Observa la repetición del mismo valor. El criterio debe considerar la resolución del equipo y la estabilidad natural de la variable.
Comparación con otras evidencias
Relaciona sensores cercanos, variables dependientes, estados del equipo y datos históricos. Una lectura de temperatura puede analizarse junto con carga, ventilación u otros sensores del mismo entorno.
Estas verificaciones deben producir evidencias, no veredictos automáticos. Sharma et al. muestran que las técnicas de detección tienen requisitos, ventajas y limitaciones distintas [1]. La elección depende del tipo de falla, de los datos disponibles y del contexto de la aplicación.
Una anomalía no significa sensor defectuoso
Un valor inusual puede ser exactamente la información que el sensor debe revelar.
Considere un equipo que normalmente opera a temperatura estable. Un ascenso rápido puede indicar falla del sensor, pero también puede representar un sobrecalentamiento real. Reemplazar o ignorar la lectura sin investigar el contexto puede ocultar el evento más importante de la operación.
Por eso, la plataforma debe distinguir tres conceptos:
Valor inválido: no puede interpretarse o viola una regla física clara. Valor sospechoso: presenta comportamiento inusual y necesita contexto. Evento operacional: representa un cambio real que exige respuesta.
Esta clasificación mejora la comunicación con el equipo. En lugar de afirmar que el sensor falló, la alerta puede informar que la lectura está congelada, que la tasa de variación superó el comportamiento histórico o que hay divergencia entre sensores relacionados.
Las lecturas congeladas exigen contexto
Detectar un valor congelado parece simple: basta comprobar si cambió. En la práctica, la regla debe responder varias preguntas.
¿Cuál es la resolución del sensor? ¿Con qué frecuencia suele variar el proceso? ¿El equipo publica el valor completo o solo cuando hay cambio? ¿Existe redondeo? ¿Otros indicadores del dispositivo siguen actualizándose?
Un sensor de presencia puede permanecer en el mismo estado durante horas sin problema. Un contador que debería crecer en cada ciclo puede resultar sospechoso después de pocos minutos sin cambio. La temperatura ambiente puede variar poco, mientras que la temperatura de un componente bajo carga debería acompañar cambios operativos.
Una regla confiable combina tiempo, variación esperada y actividad de otras métricas del mismo activo.
El horario debe acompañar al valor
Una arquitectura IoT puede tener varios relojes: en el sensor, la puerta de enlace, el broker y la plataforma.
Si esos horarios no se preservan, el equipo pierde parte de la historia del dato. También puede interpretar el retraso de transmisión como un cambio tardío del proceso.
Lo ideal es registrar el momento de la observación y el momento de recepción. Cuando sea posible, debe existir una política para sincronización de relojes y tratamiento de dispositivos que envían horarios inválidos.
Ese cuidado es especialmente importante cuando hay almacenamiento local. Después de que vuelve la conectividad, varias mediciones pueden llegar en secuencia. La plataforma debe insertarlas en la línea de tiempo correcta sin presentarlas como estado actual.
Cómo organizar el tratamiento de una lectura sospechosa
Un incidente de calidad debe aportar elementos para la investigación.
Dispositivo y variable afectada. Valor actual y unidad. Horario de medición y de recepción. Regla que clasificó el dato como sospechoso. Historial reciente. Estado de la comunicación. Indicadores de energía y de la puerta de enlace cuando estén disponibles. Comparación con sensores o variables relacionadas. Cambios recientes de configuración o firmware.
El equipo puede confirmar el proceso, comparar instrumentos, verificar la instalación y decidir si hace falta recalibrar, reemplazar o solo monitorear el sensor.
El historial también permite descubrir patrones. Una lectura puede volverse inestable solo a cierta temperatura, durante pérdida de señal o después de cambios en la alimentación. Esas relaciones ayudan a orientar la investigación, pero no deben tratarse como causalidad comprobada sin evidencia adicional.
La inteligencia artificial no elimina la necesidad de reglas básicas
Modelos estadísticos y técnicas de aprendizaje automático pueden apoyar la detección de comportamientos complejos. Microsoft Research, por ejemplo, presentó un enfoque de telemetría verificada para detectar fallas en sensores IoT mediante señales auxiliares y modelos del comportamiento físico [4].
Esas técnicas no sustituyen la identificación correcta, unidades, marcas de tiempo, rangos físicos y conocimiento del proceso. Si los datos de entrada carecen de contexto o la línea de base mezcla condiciones distintas, un modelo sofisticado puede solo producir una clasificación difícil de explicar.
Para muchas operaciones, comenzar con reglas transparentes aporta valor más rápido. Las técnicas avanzadas pueden añadirse cuando existan datos históricos, criterios de evaluación y una necesidad que justifique la complejidad.
El objetivo es preservar la confianza sin ocultar eventos reales
La calidad de los datos IoT debe monitorearse de forma continua. Un dispositivo conectado puede producir información congelada, retrasada, inconsistente o interpretada con unidad incorrecta.
Una estrategia coherente comienza con un contrato de datos y combina validación estructural, actualidad, límites físicos, tasa de variación, detección de congelamiento y contexto operacional.
Esta profundización complementa el artículo sobre monitoreo de dispositivos IoT. El artículo anterior de esta serie trata del silencio de los dispositivos. Este texto se centra en situaciones donde el dato existe, pero su confiabilidad debe investigarse.
Para gestores de TI, telecomunicaciones, infraestructura y operaciones, el punto central es mantener visible la incertidumbre. La plataforma debe indicar por qué una lectura es sospechosa y ofrecer evidencias para que el equipo diferencie una falla del sensor de un cambio real del entorno.
Los datos IoT confiables dependen tanto de la continuidad de la comunicación como de la capacidad de evaluar el significado de cada medición.
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] SHARMA, Sheetal; GUPTA, Kamali; GUPTA, Deepali; RANI, Shalli; DHIMAN, Gaurav. An Insight Survey on Sensor Errors and Fault Detection Techniques in Smart Spaces. Computer Modeling in Engineering & Sciences, v. 138, n. 3, p. 2029-2059, 2024.
[2] W3C. Semantic Sensor Network Ontology. W3C Recommendation, 19 oct. 2017.
[3] OASIS. MQTT Version 5.0. OASIS Standard, 7 mar. 2019.
[4] GUPTA, Tanmaey; HANDA, Shubhankar; NAMBI, Akshay. Verified Telemetry: A General, Easy to Use, Scalable and Robust Fault Detection SDK for IoT Sensors. Proceedings of the 8th ACM/IEEE Conference on Internet of Things Design and Implementation, 2023.