MOSES - SCADA
Rediseño visual y funcional del sistema de monitoreo estructural del Tren Interurbano México - Toluca
El producto
MOSES-SCADA es la plataforma de Grupo Sener México encargada de supervisar en tiempo real el comportamiento estructural de la infraestructura ferroviaria del Tren Interurbano México – Toluca. El sistema monitorea síncronamente más de 250 sensores estructurales distribuidos en cimentaciones, viaductos, vías, puentes y componentes de la línea férrea.
El proyecto consistió en rediseñar de forma integral su capa visual e interactiva, eliminando la saturación cognitiva heredada del sistema original y construyendo un ecosistema de navegación modular que opera hoy activamente en el Centro de Control.
Usuarios objetivo: Operadores de turno e ingenieros de supervisión estructural en entornos de monitoreo continuo de misión crítica.
- Figma
- Notion
- Adobe Ilustrador
- SIMATIC WinCC 8.1
- Investigación con SMEs y auditoría normativa
- Arquitectura de información y navegación global
- Diseño del Dashboard centralizado
- Prototipado alta fidelidad y coordinación técnica
- Construcción del Design System corporativo
El problema técnico y de negocio
En sistemas industriales de misión crítica, la saturación visual no es un problema estético: es un riesgo de seguridad operativa. El software ya se encontraba operativo, pero su capa de presentación mostraba graves deficiencias de usabilidad, heredadas de patrones de diseño tipo Windows XP. Esto generaba tres problemas críticos:
Alta carga cognitiva y omisión de alarmas
La información competía visualmente por atención sin un punto focal claro. Los operadores desarrollaban fatiga por alarmas e impedía distinguir alertas mayores de menores.
Desorientación en la navegación
Las pantallas crecieron de forma aislada a lo largo del tiempo. Sin un Home centralizado, los usuarios se perdían entre módulos secundarios sin saber cómo regresar.
Ausencia de cuadro de mando centralizado
La propuesta original no contemplaba un Dashboard. Los stakeholders identificaron la necesidad a mitad del proyecto y solicitaron integración ágil sin alterar la lógica ya programada.
¿Cómo reducir la fatiga cognitiva y agilizar la toma de decisiones dentro de los límites rígidos de SIMATIC WinCC 8.1, sin alterar la lógica funcional preexistente?
A diferencia del desarrollo clásico, el entorno cerrado de WinCC 8.1 impuso limitantes que redefinieron mi estrategia de diseño. Cada decisión requirió un balance costo/beneficio:
Lo técnicamente inviable: Se descartó la implementación de un buscador predictivo global y una barra de menú lateral colapsable, debido al costo prohibitivo en tiempos de desarrollo y recursos de scripting.
Mantener la lógica intacta: El rediseño debía ser estrictamente visual y funcional, con iteración apegada a las reglas de negocio, fórmulas de ingeniería y la arquitectura del hardware de sensores.
Metodología de investigación alternativa
Debido a cláusulas contractuales y estrictos protocolos de seguridad industrial, no fue posible obtener acceso directo a los operadores del sistema. Esta restricción redefinió la fase de descubrimiento: en lugar de entrevistas con usuarios finales, la investigación se construyó sobre dos pilares complementarios.
Mapeo con expertos (SMEs): Sesiones técnicas en profundidad con ingenieros SCADA, ingenieros estructurales e ingenieros de sitio, quienes describieron cómo decodificaban variables físicas en condiciones reales de operación y qué nivel de abstracción visual necesitan para interpretar alarmas sin error bajo estrés.
Auditoría de cumplimiento normativo: Reemplazó el user research tradicional con alineación estricta a tres estándares internacionales de ingeniería. Estas normas funcionaron como sustitutos empíricos de los hallazgos de usabilidad que habrían emergido de pruebas directas con usuarios.
Arquetipos de usuario
Carlos es un técnico de monitoreo que necesita identificar y escalar alarmas críticas en segundos porque cualquier demora puede comprometer la seguridad estructural de la infraestructura ferroviaria activa. Opera en turnos de 8 hrs monitoreando múltiples pantallas simultáneamente.
Detectar y escalar cualquier anomalía estructural antes de que se convierta en un incidente.
El exceso de información hace que el ojo no sepa dónde ir primero; las alarmas menores se confunden visualmente con las críticas.
“Cuando todo está encendido en rojo y naranja al mismo tiempo, ya no sé qué es urgente de verdad.”
Brenda es una especialista en análisis de instrumentación que necesita acceder rápidamente a datos históricos y tendencias de sensores específicos para identificar patrones anómalos antes de que escalen a fallos estructurales. Accede por zona geográfica: viaductos, puentes, túneles.
Identificar patrones de deterioro para activar mantenimiento preventivo antes de llegar a umbrales críticos.
La navegación es errática; no hay un flujo que lleve eficientemente de la vista global al detalle de un sensor específico.
“Para llegar al detalle del sensor que necesito, debo recordar exactamente los pasos a seguir. No es fácil de usar.”
Flujo de navegación jerárquica
Flujo de Carlos — Detección y escalación de alarma
Inicio de sesión
Pantalla de login rediseñada. Interfaz corporativa sobre base de datos externa a WinCC, sin ventana flotante nativa.
Dashboard central
Vista de estado global del sistema: mapa ferroviario + 5 KPIs de estado + 3 gráficos de tendencias históricas.
Identificación de alerta
Tarjeta de alarmas muestra contador elevado. El ícono en el mapa señala visualmente la zona geográfica afectada.
Navegación al módulo
Desde el mapa global se identifica y navega directamente a la zona con alarma activa.
Pantalla de detalle de estructura
Representación visual de la estructura con sensores georreferenciados, datos de la estructura y tabla de alertas activas con codificación semántica de severidad.
Detalle del sensor
Pop up modal del transductor específico con datos del sensor, nivel de alarma, gráfica de comportamiento histórico, registro de eventos y tabla de alarmas propias del sensor.
Flujo de Brenda — Análisis predictivo
Inicio de sesión
Pantalla de login rediseñada. Interfaz corporativa sobre base de datos externa a WinCC, sin ventana flotante nativa.
Dashboard central
Vista de estado global del sistema: mapa ferroviario + 5 KPIs de estado + 3 gráficos de tendencias históricas.
Identificación de alerta
Tarjeta de alarmas muestra contador elevado. El ícono en el mapa señala visualmente la zona geográfica afectada.
Navegación al módulo
Desde el menú lateral navega directamente a la zona que debe analizar.
Pantalla de detalle de estructura
Representación visual de la estructura con sensores georreferenciados, datos de la estructura y tabla de alertas activas con codificación semántica de severidad.
Detalle del sensor o reporte de sensores
Pop up modal del transductor específico con datos del sensor, nivel de alarma, gráfica de comportamiento histórico, registro de eventos y tabla de alarmas propias del sensor. Generar reporte histórico con intervalo de fechas del sensor seleccionado.
Bocetado e iteración de baja fidelidad
La fase de bocetado generó cuatro propuestas de layout para la pantalla principal. La dirección y el especialista senior descartaron el Dashboard centralizado en esta etapa, optando por otra de las propuestas. Los bocetos finales documentan ambas: la propuesta seleccionada y el Dashboard centralizado, que quedó en reserva.
Esta decisión se revirtió en una fase posterior: al avanzar el desarrollo, los stakeholders identificaron la necesidad de un punto de control unificado y solicitaron integrarlo sin alterar la lógica ya programada. El boceto descartado se convirtió en la base de ese módulo.
Los dos pilares funcionales
Arquitectura de información y navegación global
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. Diseñé un menú lateral estructurado por sección operativa con listas desplegables. Aunque WinCC dificultaba estas interacciones, el equipo SCADA logró emularlas mediante scripts personalizados. El resultado: menú funcional que respetó el comportamiento de la maqueta al 80%.
Dashboard centralizado: tres zonas de lectura progresiva
El módulo más estratégicamente relevante del proyecto: un nuevo componente que no existía en el sistema original, integrado sin alterar la lógica funcional preexistente. Zona 1 — Mapa espacial: trazo ferroviario con íconos georreferenciados y estado de alarma; solo el color del ícono comunica el estado. Zona 2 — Estado general del sistema: 5 tarjetas KPI consensuadas (alarmas de comunicación, alarmas críticas de instrumentos, dataloggers activos, trenes en circulación, switches activos). Zona 3 — Estadísticas de tendencia: 3 gráficos de comportamiento histórico de severidad para activar mantenimiento preventivo.
Perfeccionar el diseño
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.
Estandaricé la paleta de colores de alarmas de acuerdo con la norma ISA-101, reservando los colores vivos exclusivamente para alertamiento funcional.
Dark mode como estándar de ergonomía visual
La adopción del esquema oscuro no fue una decisión estética sino ergonómica: el monitoreo continuo en el Centro de Control implica jornadas prolongadas frente a múltiples pantallas. Siguiendo los principios de Material Design y los estándares de Microsoft UI / Fluent 2, el dark mode mejoró el contraste tipográfico y redujo drásticamente la fatiga ocular. El fondo oscuro también hace que los colores de alerta resalten con mayor nitidez, reduciendo el tiempo de detección.
Separación semántica de colores ISA 101
En entornos de alta densidad de información, la ambigüedad cromática es un riesgo cognitivo. Los colores vivos quedaron reservados exclusivamente para alertamiento funcional. Las métricas de datos cotidianos usan paleta neutrales, evitando que variaciones normales de datos sean interpretadas como alertas del sistema. Los tokens de colores quedaron documentados en el Design System para garantizar consistencia futura.
Tipografía y componentes para lectura técnica prolongada
Las tipografías se seleccionaron por su legibilidad en pantallas técnicas de alta densidad de información. Los tamaños mínimos de texto en tablas de alarmas y etiquetas de sensores se definieron considerando la distancia de lectura en entornos de Centro de Control con múltiples monitores. Los tokens tipográficos quedaron documentados en el Design System para garantizar consistencia futura, alineados con ISO 9241-210.
Transformación del sistema
Prototipar el problema antes de resolverlo
Antes de proponer el diseño limpio, elaboré deliberadamente la versión saturada que los stakeholders pedían para evidenciar la carga cognitiva en contexto. Ver el diseño sobrecargado fue el argumento más efectivo para aceptar el rediseño minimalista.
- Interfaz sin punto focal central
- Fondo claro con alta densidad de elementos
- Ausencia de jerarquía visual entre niveles de alarma
- Sin menú estructurado
- Sin Dashboard de estado global
- Paleta cromática inconsistente con los colores de alerta
- Dark mode estructurado
- Dashboard centralizado como punto de entrada
- Mapa ferroviario limpio con estados visuales por color
- 5 tarjetas KPI para diagnóstico inmediato
- Paleta semántica ISA-101 estricta
- Menú lateral estructurado · Login corporativo
- Pantallas desarrolladas de forma aislada
- Alta densidad, fondos fotográficos complejos
- Base azul claro que inactiva visualmente las alertas
- Estructura fragmentada sin centralización de datos
- Alertas microscópicas debilitadas por iconos de sensores
- Miniatura fotográfica contextual de la estructura
- Ilustraciones lineales limpias en escala de grises
- Botones de filtros rápidos e interactivos
- Toggle switch para mostrar/ocultar alarmas de comunicación
- Barra de navegación superior en formato carrusel
- Interfaz corporativa construida sobre base de datos externa a WinCC
- Fondo oscuro, logo institucional, formulario limpio sin ventana flotante nativa
- Marca la identidad visual desde el primer punto de contacto
- Mapa ferroviario con estados de alarma por color
- 5 tarjetas KPI de estado global
- 3 gráficos de tendencia histórica de severidad
- Representación visual de la estructura con sensores georreferenciados
- Datos técnicos de la estructura
- Tabla de alertas activas con codificación semántica de severidad
- Datos del sensor y nivel de alarma
- Gráfica de comportamiento histórico
- Registro de eventos y tabla de alarmas propias del sensor
El prototipo de alta fidelidad es, en este caso, el sistema mismo: MOSES-SCADA opera hoy en tiempo real en el Centro de Control del Tren Interurbano México – Toluca. El ciclo en Figma culminó con la entrega técnica al equipo de desarrollo SCADA, que implementó cada pantalla dentro de los márgenes técnicos del entorno WinCC 8.1.
Vista restringida — se requieren permisos de administrador para acceder a este prototipo.
Resultados del rediseño
Actualmente, el sistema MOSES-SCADA se encuentra desplegado y operando en tiempo real en el Centro de Control del Tren Interurbano México-Toluca. Los protocolos de seguridad industrial y cláusulas contractuales impidieron el uso de analíticas cuantitativas directas. Las pruebas de entrega y la capacitación técnica a operadores arrojaron resultados cualitativos de alto valor:
Velocidad de reacción síncrona
Durante las capacitaciones, los operadores identificaron las zonas geográficas con alertas críticas con mayor rapidez que con el sistema anterior. El Dashboard centralizado y el mapa con estados visuales resultaron ser los elementos con mayor impacto en el tiempo de respuesta.
Reducción de la curva de aprendizaje
La reestructura del menú lateral y la navegación global fue validada directamente por los operadores durante las sesiones de capacitación técnica.
Precisión en diagnósticos
El detalle visual unificado de las estructuras y sus instrumentos mitigó las confusiones de interpretación que generaba la interfaz anterior. Los operadores distinguieron con claridad los niveles de alarma desde el primer turno de operación.
Un solo proyecto bien ejecutado transformó la forma en que la empresa diseña y entrega software industrial
“Ahora ya sé exactamente cómo llegar a una pantalla; moverme entre las opciones del menú y las pantallas es mucho más sencillo.”
Más allá de las pantallas, el Design System construido durante el proyecto se convirtió en el sello visual de Grupo Sener México división Mobility, siendo adoptado de forma inmediata por tres aplicativos subsecuentes.
Qué aprendí
Fusión de estándares industriales al UX tradicional
En sistemas de misión crítica, los marcos clásicos de UX no se reemplazan; se fortalecen mediante estándares industriales. La combinación de normas como ISA-101 e ISO 9241-210 con la teoría tradicional de diseño genera una base indiscutible para la toma de decisiones al crear soluciones para productos digitales.
La negociación técnica también es diseño
La colaboración continua con desarrollo fue tan determinante como los prototipos. Sin esa alineación técnica, componentes clave como el menú lateral y el nuevo acceso no habrían sido viables.
Prototipar la idea del cliente como estrategia
Construir la versión saturada que pedían los stakeholders fue la forma más rápida de hacer que el proyecto avanzara. Verlo en pantalla les permitió entender, sin discusiones, por qué la propuesta que estaba justificada por una investigación era la opción recomendada.
El scope creep puede ser una señal de interés
Cuando surgieron nuevos requerimientos a partir del prototipo inicial, quedó claro que el producto ganaba relevancia para el negocio. La clave estuvo en negociar el cómo sin comprometer la visión del por qué.
Próximos pasos
Maduración del Design System
Formalizar la documentación con especificaciones para desarrolladores SCADA, incluyendo restricciones técnicas de WinCC y reglas de implementación vía scripting. Esto reduciría el tiempo de desarrollo de nuevas pantallas y garantizaría la consistencia en toda la organización.
Validación cuantitativa con métricas operativas
Establecer indicadores medibles en los próximos proyectos: tiempo de detección de alarma crítica, tasa de errores de interpretación por turno, tiempo de navegación a pantalla principal. Estos datos permitirán validar con cifras lo que la validación cualitativa ya confirmó.
Expansión del framework a nuevos proyectos
Dos aplicativos adicionales ya están mapeados para heredar este framework. El paso siguiente es acompañar activamente esas implementaciones para asegurar que la arquitectura de información y el sistema de alarmas se adapten correctamente a nuevos contextos industriales sin perder coherencia.