- React
- NestJS
- TypeScript
Plataforma de Análisis de Vibraciones
Una interfaz para transformar los datos de sensores industriales en información accionable
El Contexto
El sistema permitía visualizar recomendaciones asociadas a posibles fallas de equipos y consultar la información relacionada de los sensores.
Uno de los objetivos principales era que el analista de vibraciones pudiera acceder desde una sola vista a:
• La jerarquía de equipos y sensores
• Los datos de vibración
• Los gráficos de análisis
• Las alertas recientes
• El nivel de criticidad
• La información asociada a la alerta
• Las acciones de aceptar o rechazar una alerta
La necesidad de una vista unificada aparece explícitamente en el historial de desarrollo de la nueva vista de análisis de vibraciones.
El Problema
Analizar una alerta requiere conectar distintas piezas de información: el equipo afectado, el sensor correspondiente, los datos de vibración y el estado de la alerta.
El desafío era construir una experiencia donde estas piezas estuvieran conectadas y el usuario pudiera pasar de una a otra sin perder el contexto.
La nueva vista debía permitir seleccionar sensores desde una estructura jerárquica y actualizar los gráficos correspondientes, además de mostrar las alertas relacionadas y gestionar su estado.
Crear una vista centralizada para el análisis de vibraciones, conectando la jerarquía de sensores, la visualización de datos y la gestión de alertas.
Del Dashboard a la Plataforma de Análisis
El proyecto no comenzó directamente con la vista de análisis de vibraciones.
Una de las primeras funcionalidades fue un dashboard de recomendaciones que permitía visualizar posibles fallas, priorizar alertas y consultar su historial.
Las alertas podían tener distintos estados, como aceptado y rechazado, y el detalle podía incluir gráficos, comentarios y códigos SAP.
Diseñando la Nueva Experiencia
La nueva vista de análisis de vibraciones se estructuró en torno a tres elementos principales:
- Jerarquía de Sensores — Navegar desde el sistema y sus componentes hasta sensores específicos
- Visualización de Datos — Gráficos que muestran la información asociada al sensor seleccionado
- Alertas y Acciones — Alertas recientes que se pueden seleccionar para ver información y realizar acciones como aceptar o rechazar
Una Jerarquía de Sensores Conectada
Uno de los componentes principales de la interfaz era el árbol de sensores.
La información jerárquica debía obtenerse a través de metadatos y transformarse en una estructura navegable dentro de la aplicación.
Selección de Sensor → Actualización de Información
Seleccionar un sensor no era solo un cambio visual.
Al seleccionar un sensor, la aplicación debía lanzar las solicitudes necesarias para obtener la información correspondiente y actualizar los gráficos.
Para coordinar esta interacción entre los distintos componentes se utilizó Redux.
Seleccionar un elemento del árbol se convirtió en el punto de entrada para actualizar el resto de la interfaz.
- Seleccionar sensor → Actualizar estado global → Solicitar datos → Actualizar gráficos → Mostrar sensor seleccionado
Visualización de Datos
Los gráficos eran una parte fundamental de la experiencia.
La nueva vista debía incorporar distintas representaciones de los datos de vibración y actualizarlas según el sensor seleccionado.
La visualización debía permitir al analista interpretar rápidamente el comportamiento del sensor y detectar patrones asociados a posibles problemas.
Haciendo los Gráficos Interactivos
La interacción con los gráficos siguió evolucionando.
Se incorporó un control de Material UI para seleccionar el rango del eje X y hacer zoom sobre los datos. Cada gráfico necesitaba su propio control porque los ejes podían representar rangos distintos.
Iterando con el Feedback
La experiencia de visualización no terminó con la primera implementación.
El feedback recibido durante el proyecto llevó a distintos ajustes, como:
• Reducir el tamaño de los puntos de los gráficos
• Mantener visibles las fechas inicial y final
• Incorporar un filtro para elementos no vistos
• Ordenar las alertas por fecha
También se detectó que el zoom funcionaba correctamente en algunos gráficos, pero era menos intuitivo en otros tipos de visualización. Esto llevó a evaluar librerías de gráficos alternativas.
La interfaz evolucionó a partir del uso real y del feedback recibido durante el desarrollo.
La Criticidad como Lenguaje Visual
Las alertas debían comunicar rápidamente su nivel de criticidad.
Se definieron cuatro niveles:
| Nivel | Rango |
|---|---|
| Nivel 1 — Crítico | 80–100% |
| Nivel 2 — Alto | 50–80% |
| Nivel 3 — Medio | 20–50% |
| Nivel 4 — Monitoreo | 0–20% |
Gestión de Alertas
La información de la alerta podía visualizarse junto con acciones para modificar su estado.
El formulario incluía:
• Aceptar
• Rechazar
• Comentario
• Código SAP
El formulario fue diseñado para aparecer al seleccionar una alerta o un sensor con una alerta activa.
Diseño Responsive
La vista debía adaptarse a distintas resoluciones.
Esto implicó revisar los componentes y modificar el layout para hacerlo responsive.
Además, una de las iteraciones del sistema estuvo orientada específicamente a mejorar la visualización de gráficos en pantallas de menor resolución.
Arquitectura de Interacción
Una de las decisiones importantes del frontend fue utilizar Redux para manejar la información que debía compartirse entre distintos componentes.
Por ejemplo, seleccionar un sensor en el árbol actualizaba el estado de Redux, lo que a su vez disparaba la actualización de los gráficos y mostraba la información del sensor seleccionado.
Stack Tecnológico
- React — Desarrollo de interfaz y composición de componentes
- Redux — Manejo de estado para la selección de sensores y la comunicación entre componentes
- Material UI — Componentes de interfaz, incluidos los controles para la interacción con los gráficos
- Visualización de Datos — Visualización e interacción con datos de vibración
- Diseño Responsive — Adaptación de la interfaz a distintas resoluciones
- REST APIs — Obtención de metadatos y solicitudes para la actualización de gráficos
Resultados
El resultado fue una nueva vista de análisis de vibraciones que reunía en una sola experiencia:
- Navegación por la jerarquía de sensores
- Visualización de datos de vibración
- Gestión de alertas
- Evaluación de criticidad
- Acciones sobre alertas y seguimiento de estado
Lo que Aprendí
- Diseñar alrededor del flujo del usuario — La interfaz no se construyó como componentes independientes. Seleccionar un sensor debía disparar cambios en distintas áreas de la aplicación
- El estado global debe tener un propósito — Redux se usó principalmente para mantener sincronizada la selección de componentes, evitando estados locales desconectados
- La visualización también necesita iteración — Los gráficos no fueron una funcionalidad cerrada en la primera versión. El feedback llevó a modificar tamaños, filtros, interacción y a evaluar nuevas alternativas de visualización
- Lo responsive se piensa desde el layout — Una interfaz con múltiples gráficos, árbol de navegación y paneles laterales requiere pensar con cuidado cómo se reorganiza la información cuando el espacio disminuye
Resumen
Desde el dashboard inicial de alertas hasta la nueva vista de análisis de vibraciones, el proyecto involucró visualización de datos, interacción con gráficos, jerarquías de sensores, manejo de estado, reglas de criticidad, formularios y diseño responsive.
Mi contribución principal estuvo en el desarrollo frontend de estas experiencias usando React y Redux, conectando las interacciones de la interfaz con los datos necesarios para el análisis.
Un proyecto donde el desafío no era solo visualizar datos, sino conectar distintas fuentes de información dentro de una experiencia de análisis coherente.