Cómo un integrador de sistemas creó una aplicación de sensores con IoT Query, no con APIs

Un supervisor de almacén busca en un panel de gestión de flotas lecturas de temperatura que están ocultas a tres clics de profundidad. Los datos están ahí, pero la interfaz está diseñada para despachadores, no para operaciones de almacenamiento en frío. Esta disparidad entre las capacidades de la plataforma y las necesidades del negocio es común. Crear aplicaciones personalizadas suele llevar meses, pero este estudio de caso describe un camino más rápido.

Puntos clave

• Cree aplicaciones de monitoreo personalizadas más rápido con acceso directo a la telemetría, eliminando la necesidad de middleware y tuberías de datos complejas.
• Simplifique el desarrollo de análisis usando SQL para consultar datos históricos de forma directa, evitando la sobrecarga y las limitaciones de las integraciones basadas en API.
• Cree paneles específicos para cada rol con consultas SQL flexibles que se alineen estrechamente con los flujos de trabajo operativos, mejorando la usabilidad y la toma de decisiones.
• Escale de manera fluida entre almacenes y usuarios, sin reconstruir la infraestructura ni tener que gestionar restricciones de API.
• Acelere el tiempo de generación de valor centrándose en la analítica y los conocimientos a través de SQL, en lugar de mantener servicios backend o integraciones de API.

Explorar IoT Query para desbloquear todo el potencial de sus datos telemáticos para aplicaciones de análisis personalizadas.

La realidad operativa del monitoreo especializado

Las plataformas telemáticas de uso general destacan en lo que fueron diseñadas: seguimiento de vehículos, optimización de rutas y análisis del comportamiento del conductor. Pero cuando una empresa de logística necesita monitoreo ambiental en múltiples salas de almacén, esa misma interfaz se convierte en un obstáculo.

Los supervisores en este caso necesitaban algo específico:

• Lecturas de temperatura y humedad en 12 zonas de almacenamiento.
• Tendencias históricas para la investigación de incidentes.
• Un indicador cuando las condiciones se desvíen de los rangos aceptables.

Tradicionalmente, resolver este problema requería uno de dos caminos: ampliar las API y las plataformas existentes más allá de su propósito original, o crear una pila de aplicaciones independiente con tuberías de datos personalizadas, infraestructura y gestión de roles. Ambos enfoques introducen complejidad innecesaria. El primero conduce a integraciones y flexibilidad limitada para análisis. El segundo retrasa la entrega, ya que los equipos pasan semanas y meses ensamblando tuberías de datos, manteniendo infraestructura y conciliando varias fuentes de datos en lugar de generar valor.

El desafío: equilibrar independencia con integración

El integrador de sistemas se enfrentó a una lista de requisitos que parecía sencilla, pero que conllevaba implicaciones arquitectónicas. Los sensores ya estaban desplegados en la red de almacenes, alimentando telemetría a Navixy. Temperatura, humedad, estados de puertas y datos de tiempo de funcionamiento de los equipos fluían de forma continua.

Pero los supervisores necesitaban una interfaz que mostrara solo lo que les importaba en su flujo de trabajo:

• Estado en tiempo real de un vistazo.
• Consultas históricas para investigar por qué el congelador de la Zona 3 mostró un pico de temperatura el martes pasado.
• Vistas específicas para clientes que deseaban visibilidad en sus áreas de almacenamiento designadas.

La aplicación también necesitaba mantenerse independiente, como una herramienta enfocada en las operaciones del almacén, a la vez que continuaba conectada a la plataforma telemática. Nuevos almacenes y sensores deberían integrarse sin tener que reconstruir la aplicación. Los permisos de usuario debían respetar la estructura organizativa existente.

La escalabilidad significaba tres cosas: más salas dentro de un almacén, más almacenes en toda la red y más usuarios con diferentes niveles de permiso. La arquitectura debía soportar los tres sin requerir desarrollo personalizado para cada expansión.

Decisión arquitectónica: por qué el acceso directo a los datos superó el enfoque basado en API

Se presentaban dos caminos arquitectónicos para implementar una aplicación funcional. El primero, usar la API de la plataforma, es la opción convencional. El segundo, el acceso directo a través de IoT Query, ofrecía un enfoque diferente.

El enfoque basado en API funciona bien para muchas integraciones. Para paneles de estado en tiempo real, este patrón ofrece resultados rápidamente. Pero el análisis histórico cambia la situación. Consultar seis meses de datos de temperatura en 12 zonas mediante una API implica paginación, limitaciones de tasa y lógica de agregación de datos que reside en un middleware personalizado. El integrador tendría que construir y mantener una base de datos local, rutinas de sincronización e infraestructura de almacenamiento, todo antes de escribir una sola línea de código para el panel.

IoT Query ofreció una arquitectura diferente. La aplicación consulta una capa de datos preparada directamente usando SQL estándar.

"IoT Query brinda acceso listo para usar a datos de telemetría en tiempo real e históricos sin la necesidad de crear capas de almacenamiento y agregación", explica Andrew Melnik, vicepresidente de Datos y Soluciones en Navixy. "Las consultas SQL son más rápidas de lo que permitirían varias llamadas a la API. Como resultado, podemos servir paneles en tiempo real y análisis históricos desde la misma fuente de datos, lo que mantiene la arquitectura simple. La aplicación permanece independiente pero se integra fácilmente con Navixy. Especialmente para este caso de uso, la carga de mantenimiento es mucho menor que la alternativa basada en API."

Implementación: del acceso a la base de datos a los paneles operativos

Con la decisión arquitectónica tomada, la implementación se centró en lo que mejor hacen los integradores de sistemas: crear aplicaciones que resuelven problemas específicos.

La capa de datos bruta de IoT Query proporcionó la base. Este conjunto de datos contiene lecturas de telemetría con la estructura e indexación necesarias para el análisis de series temporales. Lecturas de temperatura, mediciones de humedad, estados de puertas y estado de equipos, todo consultable con sintaxis SQL estándar compatible con las herramientas de PostgreSQL.

El patrón de desarrollo se parecía al de cualquier persona que haya creado aplicaciones de análisis:

1. Conectar a la fuente de datos.
2. Escribir consultas para las métricas específicas necesarias.
3. Construir visualizaciones que respondan a preguntas operativas.

Para el monitoreo en tiempo real, la aplicación consulta las lecturas recientes y actualiza los paneles en intervalos adecuados para las condiciones ambientales (los cambios a nivel de minuto importan menos que las tendencias a nivel de hora en el almacenamiento en frío). Para el análisis histórico, la misma fuente de datos admite consultas de semanas o meses sin la complejidad de paginación de la API.

La separación de clientes se logró a través de la estructura organizativa existente. Cada cliente de almacén ve únicamente sus zonas de almacenamiento designadas. La aplicación respeta estos límites sin requerir lógica personalizada de control de acceso.

La aplicación entregada brinda a los supervisores exactamente lo que necesitan:

• Estado ambiental en tiempo real en todas las zonas monitoreadas.
• Gráficos de tendencias históricas para investigar anomalías.
• Alertas basadas en umbrales cuando las condiciones superan los rangos aceptables.
• Vistas específicas para los clientes con el debido aislamiento de los datos.

La aplicación funciona como una herramienta independiente pero se abre desde la interfaz de Navixy, manteniendo una experiencia coherente para los usuarios que trabajan tanto en la gestión de flotas como en operaciones de almacén.

Esta integración está habilitada a través de App Connect, la herramienta de autenticación de Navixy. Transfiere la autenticación de usuario desde la plataforma a la aplicación externa, lo que permite a los usuarios acceder a la herramienta de monitoreo sin inicios de sesión separados. Para los integradores de sistemas, esto elimina la necesidad de crear o mantener infraestructura de autenticación.

¿Qué sigue?: del monitoreo a la predicción

A medida que la aplicación escala, se pueden agregar KPI adicionales para extender el panel más allá de la temperatura y la humedad. Métricas como tiempo de funcionamiento de equipos, consumo de energía e indicadores de mantenimiento pueden integrarse sin problemas utilizando la misma capa de datos.

El siguiente paso en la mejora operativa son los análisis predictivos. En lugar de alertar cuando las condiciones superen los umbrales, el sistema puede identificar patrones que preceden a las fallas. Un compresor que funciona con más frecuencia de lo normal. Un sensor de puerta que muestra duraciones de apertura inusuales. Estas señales están presentes en los datos históricos, esperando análisis.

Los mecanismos de alerta irán más allá de la propia aplicación. La integración con los flujos de trabajo operativos garantiza que las personas adecuadas reciban notificaciones a través de los canales que ya utilizan (correo electrónico, mensajería), y permite reducir o desactivar alertas cuando sea necesario.

Las interfaces móviles ampliarán el acceso a los supervisores durante recorridos por las instalaciones. Las mismas consultas que alimentan los paneles de escritorio pueden impulsar vistas móviles enfocadas, que muestran el estado de la zona y alertas recientes.

La base es importante porque estas expansiones requieren cambios mínimos en la arquitectura. La capa de datos ya contiene las señales necesarias para un análisis más sofisticado. Crear vistas y análisis adicionales se convierte en desarrollo de aplicaciones, no en trabajo de infraestructura.

El argumento a favor de un enfoque centrado en los datos

Este estudio de caso ilustra un principio que se aplica más allá del monitoreo de almacenes: cuando la infraestructura de datos está resuelta, los integradores de sistemas pueden centrarse en aplicaciones que resuelvan problemas reales. Una capa de datos preparada permite a los desarrolladores consultar telemetría estructurada a través de SQL estándar, sin tener que gestionar sistemas subyacentes.

Para los integradores de sistemas, esto representa una ventaja arquitectónica. Con soporte integrado para análisis de series temporales y entornos multi-inquilino, una capa de datos lista puede reducir la entrega de meses a semanas.

Contáctenos para habilitar IoT Query y desbloquear todo el potencial de sus datos telemáticos para aplicaciones de análisis personalizadas.

---

Preguntas frecuentes

P: ¿Qué componentes de middleware específicos requeriría un enfoque basado únicamente en API?

R: El enfoque basado en API requiere gestionar la paginación, los límites de tasa, el almacenamiento en bases de datos locales, rutinas de sincronización y la lógica de agregación antes de poder comenzar con el desarrollo del panel.

P: ¿Cómo afectan los límites de tasa y la paginación de la API al análisis de datos históricos a gran escala?

R: Las consultas históricas que abarcan meses de datos en múltiples zonas requerirían un amplio manejo de paginación y estarían sujetas a límites de tasa de la API, lo que hace que el análisis histórico en tiempo real sea poco práctico.

P: ¿Cómo maneja IoT Query los datos inconsistentes o ruidosos de sensores procedentes de diferentes dispositivos?

R: IoT Query actualmente brinda acceso a una capa de datos en bruto, que contiene datos telemáticos y empresariales con una transformación mínima. Según la Documentación de Navixy, la capa de Transformación para datos depurados y transformados, así como la capa de Insight para agregados listos para el negocio, están planeadas pero aún no están disponibles de manera general. Esto significa que los integradores trabajan principalmente con datos de origen en bruto y deben considerar la normalización y limpieza en su propia lógica de análisis cuando sea necesario.

P: ¿Qué sucede cuando los datos de telemetría se retrasan o faltan?

R: La disponibilidad de los datos depende de la conectividad y el comportamiento de reporte del dispositivo. IoT Query refleja los datos recibidos por la plataforma, por lo que los integradores deben diseñar paneles y lógica que manejen brechas, retrasos y conjuntos de datos incompletos.

P: ¿Cuáles son los límites prácticos o las consideraciones al usar IoT Query para implementaciones a gran escala?

R: El rendimiento depende del diseño de las consultas, el volumen de datos y los rangos de tiempo. Aunque IoT Query elimina la necesidad de infraestructura de almacenamiento personalizada, los integradores deben evaluar la eficiencia de las consultas, los tiempos de respuesta para grandes volúmenes de datos y la frecuencia de actualización de los paneles en condiciones de uso real.

P: ¿Cómo se integra IoT Query con sistemas externos o herramientas de BI?

R: IoT Query admite acceso basado en SQL compatible con PostgreSQL, lo que permite la integración con herramientas de análisis externas y aplicaciones personalizadas que puedan conectarse a bases de datos relacionales.

P: ¿Cómo se manejan el control de acceso y el aislamiento de datos multi-inquilino?

R: IoT Query sigue la estructura organizativa de la plataforma, garantizando que los usuarios solo puedan acceder y consultar los datos disponibles dentro de su cuenta y permisos asignados.