Cómo construir un sistema de monitoreo de sensores en tiempo real para almacenes y más allá

Si usted construye flujos de trabajo para almacenes, sitios de cadena de frío o instalaciones técnicas, este caso muestra cómo convertir datos telemáticos existentes en un sistema de monitoreo de sensores a la medida, sin añadir un pipeline de datos aparte. También desglosa la arquitectura de la aplicación: acceso PostgreSQL, configuración de sensores, lógica de umbrales en vivo, historial, reportes y mapa.

Imagine un almacén donde ya se recogen lecturas de temperatura y humedad a través de dispositivos conectados. El equipo de operaciones puede no necesitar otra pantalla organizada por rastreadores e IDs de sensores. Puede necesitar una respuesta más simple: ¿qué cámaras frías o zonas de almacenamiento están ahora dentro del rango configurado?

IoT Query, la plataforma de analítica de flotillas de Navixy, ofrece acceso estructurado a datos de flota y sensores a través de PostgreSQL, mientras el integrador define la interfaz alrededor del flujo del cliente. Sensoriqua, una aplicación construida por un partner de Navixy, demuestra este enfoque. Agrupa canales de sensores individuales por zona física, aplica límites configurados y muestra el estado operativo antes de los valores crudos.

El código de color en la interfaz facilita interpretar el estado sin revisar cada lectura. Verde significa que todas las lecturas configuradas de una zona están dentro del rango definido. Rojo destaca una zona en la que al menos un sensor está fuera de su umbral. Un estado neutro significa que no se ha configurado umbral para ese sensor.

Dónde aplica el monitoreo de sensores por zona

El mismo patrón de aplicación puede cubrir varios escenarios en los que los usuarios trabajan con ubicaciones físicas y no con IDs de dispositivo:

• Los clientes de farmacéutica y almacenes de alimentos pueden necesitar registros de temperatura y humedad organizados por zona de almacenamiento y documentados según GxP o estándares de cumplimiento de cadena de frío. Para una pista de auditoría, la pregunta relevante es qué zona se mantuvo dentro del rango especificado, no qué ID de dispositivo produjo una lectura individual.
• Los clientes de centros de datos y salas de servidores pueden necesitar estado por fila de racks o por sala, para que operaciones revise un área concreta sin cruzar una hoja de cálculo.
• Los clientes de cuartos limpios y laboratorios monitorean condiciones ambientales que pueden variar entre áreas de un espacio controlado.
• Los clientes de invernaderos y agricultura pueden monitorear microclimas por sector de cultivo, donde las condiciones difieren entre secciones de la misma instalación.
• Operadores de museos y archivos pueden organizar el monitoreo de temperatura y humedad por sala, alineando las lecturas con los espacios donde se guardan las colecciones.
• Los clientes industriales pueden agrupar datos de condición de equipo por línea de producción, taller o ala del edificio.

En cada caso, IoT Query suministra los datos telemáticos y de sensores. El integrador decide cómo la aplicación mapea esas lecturas a las ubicaciones y conceptos operativos del cliente.

Qué compone un sistema de monitoreo de sensores a la medida

Sensoriqua es una implementación de referencia construida por un partner de Navixy para un tipo concreto de flujo. La aplicación corre sobre Navixy IoT Query, con acceso SQL directo a los datos de sensores.

Su arquitectura combina tres capas centrales, apoyadas por historial, reportes y vista de mapa:

1. Acceso a datos: una conexión PostgreSQL directa a una base dentro de IoT Query.
2. Configuración de sensores: un mapeo persistente entre objetos fuente, canales de sensor, zonas definidas por el cliente, umbrales, factores de escala y etiquetas de visualización. Los datos de sensores pueden organizarse con independencia de los rastreadores que los entregaron.
3. Tablero en vivo: un dashboard que consulta valores recientes a un intervalo configurable, evalúa umbrales en el navegador y presenta el estado agregado por zona.
4. Historial y reportes: una vista de consulta para comparar lecturas en el tiempo, revisar mínimo, máximo y promedio diarios, e identificar anomalías o patrones recurrentes.
5. Mapa: una vista de ubicación que coloca los objetos monitoreados en un mapa y permite filtrarlos por condición de umbral. Es útil cuando los almacenes u otros sitios están distribuidos en varias ubicaciones.

El backend recupera datos y guarda la configuración de la aplicación. El frontend calcula el estado visual actual a partir de la última respuesta, de modo que el estado de zona no necesita mantenerse como un registro aparte en el servidor.

Capa 1: Acceder a los datos de sensores directamente a través de IoT Query

Durante el inicio de sesión, el backend de Sensoriqua envía las credenciales del usuario a Navixy App Connect. Esta herramienta actúa como puerta de integración: mantiene la autenticación de plataforma y el acceso a bases de datos dentro del contexto de aplicación de Navixy, mientras Sensoriqua maneja el flujo específico del cliente.

Las lecturas están disponibles a través de raw_telematics_data y raw_business_data, con valores de sensores expuestos como columnas y no como filas. Para poblar la lista de sensores disponibles de cada objeto, Sensoriqua consulta de forma dinámica los conjuntos de columnas en inputs, states y tracking_data_core.

Explore el detalle de la capa Raw data de IoT Query en la documentación de Navixy para analistas.

Como resultado, un operador que configura el sistema de monitoreo de sensores ve los nombres de dispositivos que realmente existen en los datos del cliente, en lugar de elegir de una lista estática predefinida.

El acceso SQL directo también da al integrador control sobre cómo se consultan esos datos. La aplicación puede, por ejemplo, calcular promedios de 1 minuto, cambiar ventanas de sparkline o pedir un periodo histórico concreto sin un endpoint adicional en un contrato REST fijo.

La consulta y la interfaz pueden adaptarse al flujo de monitoreo del cliente mientras IoT Query permanece como capa de datos subyacente.

Capa 2: Configurar sensores con independencia de los rastreadores

La segunda capa es un mapa persistente de sensores que define cuáles pertenecen a cada zona y cómo deben interpretarse sus lecturas.

Cada sensor configurado guarda:

• el objeto y la columna de la tabla fuente de la que lee
• una etiqueta legible
• un multiplicador, usado como factor de escala antes de mostrar, para conversión de unidades o calibración
• umbrales MIN y MAX, que definen el rango operativo usado para el estado visual
• una profundidad de sparkline, que define cuántas horas de promedios de 1 minuto muestra el widget: 1, 2, 4 u 8 horas

Los sensores se organizan en planos de dashboard con nombre, o paneles que corresponden a zonas físicas como una cámara fría, una fila de racks o un sector de invernadero.

Un mismo dashboard puede contener varios planos, y cada plano contiene los sensores asignados a esa ubicación. Así se separa la forma en que los usuarios trabajan con la interfaz de monitoreo de la estructura de rastreadores que transportó las lecturas originales.

El mapa de sensores se almacena en la base de estado de la aplicación.

Capa 3: Calcular el estado en vivo de la zona a partir de lecturas recientes

El tablero en vivo usa sondeo (polling) en lugar de actualizaciones push. Recupera datos frescos a un intervalo configurable de 30 segundos, 1 minuto o 5 minutos.

Los endpoints de datos en vivo consultan PostgreSQL de IoT Query de forma directa y devuelven los valores. La evaluación de umbrales corre entonces en el navegador.

Después de aplicar el multiplicador configurado, el frontend compara cada lectura con sus límites MIN y MAX. Un valor fuera de cualquiera de los dos cambia el estado de ese sensor a rojo. Si cualquier sensor de una zona está en rojo, el panel de la zona también se muestra en rojo. Si todos los sensores configurados permanecen dentro de sus umbrales, el panel es verde. Un sensor neutro no tiene umbral configurado.

Esta arquitectura mantiene el backend sin estado respecto a la salud de la zona. Guarda configuración y recupera lecturas, mientras el estado actual de zona se recalcula a partir del último sondeo exitoso.

En la implementación actual, la aplicación no mantiene un registro en el servidor del momento en que se cruzó un umbral. Tampoco envía notificaciones push ni encola alertas. Si el sondeo falla, los valores mostrados permanecen sin cambio hasta la siguiente solicitud exitosa.

Revisar lecturas históricas y reportes diarios

El tablero en vivo responde si una zona monitoreada está ahora dentro de rango. Las vistas de historial y reportes de Sensoriqua aportan las lecturas de fondo para una revisión de más largo plazo.

El endpoint de historial acepta un ID de objeto, un nombre de sensor y un rango de tiempo, y luego recupera lecturas crudas de IoT Query por un periodo de hasta 90 días. La aplicación las renderiza como un gráfico interactivo con bandas de umbral superpuestas.

La vista de reporte agrega la serie temporal en estadísticas diarias para cada sensor:

• mínimo
• máximo
• promedio

Los reportes pueden exportarse en varios formatos:

• JSON: agregados diarios crudos
• HTML y PDF: tablas formateadas con gráficos embebidos
• XLSX: salida de hoja de cálculo

La agregación y el render ocurren en el navegador. El backend sigue siendo la capa de recuperación de datos, mientras la aplicación cliente genera y descarga el reporte sin un paso extra de render en el servidor.

Añadir contexto geográfico a las excepciones de sensores

IoT Query también da a Sensoriqua acceso a los datos de ubicación asociados a los objetos monitoreados. La vista de mapa de Sensoriqua traza la última posición GPS de cada objeto junto con sus lecturas recientes. Los operadores pueden filtrar el mapa por entidad de negocio y condición de umbral.

Para un cliente que opera varios almacenes o sitios técnicos, el operador puede filtrar objetos con lecturas fuera de rango, localizar el sitio relevante y abrir su vista detallada de sensores.

El objeto no necesita moverse para que la ubicación sea útil. Un gateway estacionario puede identificar un almacén fijo o un sitio técnico en el mapa.

Construir la aplicación de monitoreo sobre la capa de datos de IoT Query

La capa de datos crudos de IoT Query permite a Sensoriqua acceder al flujo de sensores a través de PostgreSQL sin introducir una API de middleware aparte ni un pipeline ETL a la medida.

Las lecturas se exponen en una estructura de columnas consistente. Los desarrolladores de Sensoriqua añadieron configuración de zonas y evaluación de umbrales sin cambiar los datos fuente.

Desde la perspectiva de Sensoriqua, las tablas de IoT Query permanecen de solo lectura. El sistema de monitoreo de sensores actúa como capa de aplicación y visualización, en lugar de crear otra copia de los datos telemáticos.

Navixy IoT Logic, una herramienta de automatización de procesos de datos, puede ejecutar reglas contra el mismo flujo de forma independiente. Así se mantiene la presentación de datos en la aplicación a la medida separada de la automatización de flujos.

Usar Sensoriqua como implementación de referencia

Para proveedores de servicios telemáticos e integradores de sistemas, el caso destaca cómo se puede construir una aplicación a la medida con capacidades existentes de Navixy:

• autenticación App Connect
• consultas PostgreSQL directas a IoT Query
• un esquema persistente de zona y configuración de sensores
• evaluación de umbrales del lado del cliente
• consultas de datos históricos
• exportaciones de resumen diario
• filtrado geográfico de objetos monitoreados

Sensoriqua usa estos bloques para crear un sistema de monitoreo de sensores por zona. Un integrador puede usar el mismo modelo de acceso a datos para otras aplicaciones, incluidas vistas de salud de equipo, dashboards operativos específicos del cliente, reportes a la medida, pantallas de monitoreo ambiental o herramientas de monitoreo basadas en mapa.

Si el flujo de monitoreo de su cliente no se representa de forma efectiva en un dashboard estándar, contacte al equipo de Navixy para hablar opciones de construir una aplicación IoT Query a la medida.