MOSES - SCADA

Antecedentes

El sistema recopila y procesa variables físicas complejas provenientes de sensores instalados en cimentaciones, viaductos, vías, puentes y componentes estructurales de la línea férrea.

El sistema MOSES - SCADA original funcionaba correctamente a nivel lógico y técnico. La plataforma se ejecutaba sobre SIMATIC WinCC 7.4 y se migró a SIMATIC WinCC 8.1, en un entorno robusto para control y supervisión (SCADA), pero con capacidades gráficas nativas rígidas y limitadas para una buena experiencia de usuario.

El problema técnico y de negocio

El software ya se encontraba operativo, pero sin capa de presentación mostraba graves deficiencias de usabilidad, heredadas de patrones de diseño tipo Windows XP. Esto generaba tres problemas críticos:

1. Alta carga cognitiva y omisión de alarmas: Los operadores e ingenieros deben interpretar volúmenes masivos de variables físicas bajo condiciones de estrés. La información competía visualmente por atención y no había un punto focal claro, lo que provocaba una fatiga por alarmas y saturación cognitiva e impedía distinguir alertas mayores y menores con facilidad.
2. Desorientación en la navegación: Las pantallas y funcionalidad se desarrollaron de forma aislada a lo largo del tiempo, lo que provocaba que el usuario operara sin un flujo centralizado, se desorientara y se perdiera entre módulos secundarios sin saber cuál era su pantalla principal y cómo regresar a ella.
3. Gobernanza del proyecto: Inicialmente se aprobó una propuesta que no contemplaba un cuadro de mando centralizado. En una actualización posterior de requerimientos, los stakeholders identificaron la necesidad imperativa de un Dashboard Centralizado y solicitaron su diseño e integración ágil, sin alterar la lógica interna ya programada.

El reto de diseño

¿Cómo estructurar una interfaz modular y un dashboard de control que redujera drásticamente la fatiga cognitiva y agilizara la toma de decisiones, operando estrictamente dentro de los límites rígidos de visualización y navegación de un sistema SIMATIC WinCC 8.1, que los operadores ya conocían y que pudieran adoptar de manera natural?

A diferencia del desarrollo clásico, el entorno cerrado de SIMATIC WinCC 8.1 impuso limitantes que redefinieron mi estrategia de diseño. Cada decisión requirió un balance entre costo/beneficio:

• Lo técnicamente inviable: Se descartó la implementación de un buscador predictivo global. También se descartó que la barra de menú lateral fuera colapsable, debido al costo prohibitivo en tiempos de desarrollo y recursos.
• Mantener la lógica intacta: El rediseño debía ser estrictamente visual y funcional con iteraciones apegadas a las reglas de negocio, fórmulas de ingeniería y la arquitectura del hardware de sensores.

Debido a cláusulas contractuales con el cliente final y estrictos protocolos de seguridad industrial, no se otorgó acceso directo al personal del área de monitoreo. Para subsanar esto, la fase de descubrimiento se basó en:

1. Mapeo con expertos (SMEs): Entrevistas técnicas en profundidad con ingenieros SCADA, ingenieros estructurales e ingenieros de sitio para entender cómo decodificaban las variables físicas en condiciones reales y cómo deberían mostrarse en pantalla para que operadores con perfiles junior o especializados pudieran interpretar de manera fácil.
2. Auditoría de cumplimiento normativo: Reemplacé el user research tradicional por la alineación estricta a tres estándares internacionales de ingeniería industrial:
   • ISA 101: Diseño de interfaces humano-máquina (HMI) eficientes.
   • ISA-18.2: Gestión y priorización de alarmas operativas.
   • ISO 9241-210: Ergonomía e interacción humano-sistema.

Comparativa visual: interfaz heredada vs. rediseño UX alineado a ISA-101.

Para mitigar la desorientación del usuario y resolver el cambio de alcance de los stakeholders, reestructuré el ecosistema dividiendo la estrategia de información en dos grandes pilares funcionales.

1. Arquitectura de información y navegación global de la aplicación

   Este bloque resolvió la inconsistencia modular de todo el software y la transición entre pantallas, atacando la experiencia desde la puerta de entrada:

   • Estandarización de módulos existentes: Definí layouts consistentes e iconografía unificada para que la navegación dentro del sistema se rigiera por las mismas reglas espaciales y jerárquicas.
   • Menú lateral: Diseñé un menú de navegación estructurado por sección operativa, con listas desplegables y sección administrativa. Aunque WINCC dificulta estas interacciones, el equipo de desarrollo SCADA logró un acto heroico de programación mediante scripts personalizados para emular el efecto dinámico de contracción y expansión de las maquetas creadas con Figma.
   • Modernización del acceso (login): De forma nativa, el sistema abre una ventana flotante sin estilos. Negocié y coordiné con el equipo de desarrollo la creación de una base de datos externa a WinCC para administrar usuarios, lo que me permitió diseñar una interfaz de acceso limpia, corporativa y alineada con el lenguaje visual actual.
2. Arquitectura de información y diseño del Dashboard central

   El nuevo dashboard centralizó el estado operativo de los 250+ sensores en tres zonas estratégicas:

   • Mapa espacial.

     Contenido técnico: Mejora del mapa del trazo ferroviario con iconos de infraestructura (estaciones, viaductos, túneles, puentes) y que ahora incluyen estados de alarmas visuales.

     Estrategia de diseño/negociación: Originalmente se pretendía saturar esta vista con planos plagados de semáforos y etiquetas. Diseñé esa propuesta para evidenciar la alta carga cognitiva. Al verla, los stakeholders entendieron el punto y aceptaron el diseño limpio propuesto.

   • Estado general del sistema.

     Contenido técnico: 5 tarjetas consensuadas (Alarmas de comunicación, Alarmas críticas de instrumentos, Dataloggers activos, Trenes en circulación, Switches activos).

     Estrategia de diseño: Rompe la dispersión de datos. Permite saber de un vistazo si el sistema operativo está sano o requiere atención inmediata. Refuerza los estados de alarma con el número de alarmas o instrumentos.

   • Estadísticas y tendencias.

     Contenido técnico: 3 gráficos distintos que muestran el comportamiento histórico de la severidad del sistema.

     Estrategia de diseño: Facilita a los operadores identificar patrones anómalos en el tiempo para activar mantenimientos preventivos.

Debido a que el enfoque central es identificar estados de alarmas, opté por un diseño minimalista funcional de manera que las alarmas tuvieran el enfoque principal. Para ello utilicé los principios de Material Design y la norma ISA-101.

• Estilo oscuro (Dark mode): Con base en los principios de Material Design y considerando que la operación del sistema se realiza sobre Windows 10+, utilicé los estándares de Microsoft UI y Fluent 2. La adopción de un esquema oscuro mejoró el contraste tipográfico y redujo drásticamente la fatiga ocular durante las jornadas de monitoreo continuo en el Centro de Control.
• Separación de colores: Siguiendo la norma ISA-101, los colores vivos se reservaron estrictamente para alertamiento funcional (Rojo: crítico, Anaranjado: atención, Amarillo: falla de comunicación, Verde: normal). Para las gráficas de métricas y barras de datos cotidianos, utilicé una paleta neutra en colores azul y morado, evitando que las variaciones normales de datos se confundan con alertas del sistema.

Actualmente, el sistema MOSES-SCADA se encuentra desplegado y operando entiempo real en el Centro de Control del Tren Interurbano México-Toluca. Aunque los protocolos de seguridad impidieron el uso de analíticas cuantitativas directas, las pruebas de entrega y la capacitación técnica arrojaron resultados cualitativosde alto valor:

• Velocidad de reacción síncrona: Durante las capacitaciones, los operadores demostraron una identificación significativamente más rápida de las zonas geográficas con alertas críticas.
• Reducción de la curva de aprendizaje: Los comentarios de los operadores validaron directamente la reestructura de la navegación global: “Ahora ya sé exactamente cómo llegar a “una pantalla específica”; moverme entre las opciones del menú y las pantallas es mucho más sencillo.”
• Precisión en diagnósticos: El detalle visual unificado de las estructuras y sus instrumentos mitigó posibles errores de interpretación que provocaba la interfaz anterior.

Mi aportación final en el proyecto no se limitó a resolver el aspecto visual del Tren Interurbano; busqué dejar una base de gobernanza de diseño duradero para la organización y futuros proyectos de monitoreo estructural.