Basta con pasar un tiempo en una sala de control para darse cuenta de que a los operadores de turno no les faltan conocimientos ni experiencia. Conocen sus procesos a la perfección, a menudo incluso mejor que los propios ingenieros de procesos que los diseñaron. Lo que sí suele faltarles es una interfaz realmente optimizada. Con demasiada frecuencia, la información en la IHM se presenta de forma poco intuitiva: está dispersa, sobrecargada y mal jerarquizada. Y es ahí donde empiezan los problemas.
Durante muchos años, la interfaz hombre-máquina fue la gran olvidada de los proyectos de automatización. Se invertía en autómatas, sensores y redes de campo. La IHM se dejaba para el final del proyecto, a menudo con presupuestos ajustados y, en ocasiones, en manos de personas sin una experiencia real en la operación de las instalaciones. El resultado eran pantallas sinópticas saturadas de información, colores utilizados sin ningún criterio coherente y alarmas que se sucedían sin una lógica clara para el operador.
Con el tiempo, al analizar incidentes y situaciones críticas, era frecuente descubrir que toda la información necesaria estaba disponible. El problema era que el operador no la había visto a tiempo o no había podido interpretarla correctamente porque la interfaz no estaba diseñada para facilitar la toma de decisiones.
Esa situación no ha desaparecido por completo. Sin embargo, el sector ha evolucionado y hoy aborda esta cuestión desde una perspectiva diferente.
La definición académica, que la describe como un sistema de hardware y software que permite a una persona interactuar con un proceso automatizado, apenas refleja la realidad de una planta industrial. En un entorno de supervisión industrial, una interfaz hombre-máquina es, ante todo, la pantalla desde la que el operador comprende lo que está ocurriendo y toma decisiones.
Se trata de los sinópticos que representan gráficamente el proceso, con sus tuberías, depósitos, válvulas, motores y todas las variables que evolucionan en tiempo real. Son también las gráficas de tendencias que permiten detectar de un vistazo si una temperatura lleva dos horas aumentando. Son las alarmas, mostradas con su nivel de prioridad y su registro temporal. Y son, por supuesto, los controles que permiten actuar sobre la instalación: abrir una válvula, arrancar una bomba o modificar una consigna de operación.
Todo ello se sustenta sobre distintas capas de software, cuya complejidad depende de la arquitectura implantada. En las infraestructuras distribuidas predominan los sistemas SCADA, mientras que en los procesos continuos suelen utilizarse plataformas DCS. En las instalaciones de gran tamaño, además, es habitual encontrar entornos híbridos que combinan ambas tecnologías.
Cada solución tiene sus propias fortalezas, sus limitaciones y sus retos de migración, además de un ecosistema específico de integradores y especialistas. En este contexto, Ignition ha ganado una gran popularidad en los últimos años gracias a su modelo de licencias por servidor y a una arquitectura concebida desde el principio para entornos web. Para muchas empresas, esto supone una ventaja considerable, ya que evita los costes y las complicaciones de instalar y mantener software cliente en cada puesto de operación.
Las primeras interfaces hombre-máquina industriales fueron paneles sinópticos cableados. Un piloto encendido equivalía a un estado físico concreto de la instalación. Era un sistema simple, directo y prácticamente imposible de interpretar de forma ambigua. Un operador habituado a este tipo de paneles lo leía casi como un lenguaje propio. Detectaba una anomalía antes incluso de ser plenamente consciente de ella, a partir de un cambio de color en su campo visual periférico.
La llegada de los terminales informáticos en los años ochenta y, más tarde, la expansión de las interfaces gráficas en los años noventa, cambiaron por completo el panorama. Las pantallas se volvieron configurables, la cantidad de información disponible se disparó y, de repente, un mismo puesto de operación podía supervisar cientos de veces más variables que antes.
Y ahí empezó el problema. Porque más información no significa necesariamente mejor comprensión. Los primeros sistemas SCADA con interfaz gráfica dieron lugar, en muchos casos, a entornos visuales poco estructurados, saturados y difíciles de interpretar. El uso del color carecía de criterios homogéneos: el rojo podía indicar un estado normal en una pantalla y una alarma crítica en otra, dependiendo simplemente de cómo se hubiera configurado el sistema.
Las normas y buenas prácticas que hoy orientan el diseño de las IHM surgieron en gran medida como respuesta a esta situación. Referencias como la norma ISA-101 para el diseño de interfaces en automatización de procesos o la guía EEMUA 191 para la gestión de alarmas reflejan una toma de conciencia colectiva en el sector. La industria entendió que no bastaba con mostrar información: había que estructurarla, jerarquizarla y aplicar criterios de diseño coherentes para facilitar la toma de decisiones en entornos cada vez más complejos.
Pasar una noche de turno en una gran sala de control resulta revelador en más de un sentido. Se entiende muy rápido que el entorno impone unas condiciones que pocos diseñadores de IHM tienen plenamente en cuenta durante el desarrollo. La iluminación tenue para no comprometer la legibilidad de las pantallas, la fatiga que se acumula hacia el final del turno y la rotación de equipos, que hace que un operador pueda enfrentarse a una situación poco familiar tras un tiempo alejado del proceso. A todo ello se suma la necesidad constante de mantener una representación mental coherente de un sistema que está en permanente cambio.
Los especialistas en factores humanos hablan de “conciencia situacional“, un concepto tomado de la aviación y aplicado de forma bastante natural a los entornos industriales críticos. Se trata de la capacidad de percibir lo que ocurre en el entorno, comprender su significado y anticipar lo que probablemente va a suceder a continuación. Una IHM bien diseñada refuerza esa conciencia situacional. Una IHM mal diseñada, por el contrario, la deteriora de forma activa.
Probablemente no haya un mejor indicador de la calidad de una interfaz hombre-máquina industrial que el estado de su sistema de gestión de alarmas. No porque las alarmas sean la parte más visible del sistema, sino porque concentran todos los fallos de diseño acumulados a lo largo de los años.
El fenómeno de las “tormentas de alarmas” está ampliamente documentado en la industria. Durante un incidente, decenas o incluso cientos de alarmas se activan en cascada, a menudo porque cada subsistema ha sido configurado con su propia lógica de alarmas, sin que nadie haya establecido una jerarquía global coherente. En algunas instalaciones se han llegado a registrar más de 300 alarmas en menos de diez minutos durante un evento relevante. A ese ritmo, el operador deja de ser capaz de actuar con criterio: o bien reconoce y confirma alarmas de forma automática y casi mecánica, o directamente deja de gestionarlas.
El estándar EEMUA 191 establece referencias claras basadas en la experiencia industrial. En condiciones normales de operación, un operador no debería tener que gestionar más de entre 6 y 12 alarmas por hora. En situaciones de perturbación, el umbral crítico se sitúa en una alarma cada diez segundos. A partir de ese punto, la capacidad de respuesta humana se satura. Diversos estudios realizados en plantas petroquímicas han mostrado que algunas instalaciones operaban de forma habitual por encima de estos valores, sin que la situación se hubiera identificado formalmente como un problema.
La racionalización de alarmas es un trabajo largo y, en muchos casos, poco visible, que implica revisar años de configuraciones acumuladas. Sin embargo, las IHM modernas ofrecen cada vez más herramientas para facilitar esta tarea: motores de análisis de historiales de alarmas, detección de alarmas recurrentes no resueltas y mecanismos de supresión contextual en función del estado del proceso.
La cuestión aparece con frecuencia en los pliegos de licitación y en los proyectos de modernización: ¿hay que pensar en términos de SCADA, de DCS o de IHM? La respuesta más honesta es que estas distinciones tienen cada vez menos sentido.
Históricamente, el SCADA supervisa equipos geográficamente distribuidos, como redes de distribución de agua, redes de gas o subestaciones eléctricas repartidas a lo largo de cientos de kilómetros. El DCS, en cambio, gestiona procesos continuos concentrados, como una columna de destilación o un horno en una cementera. La IHM era la capa de presentación de uno u otro sistema.
Hoy en día, plataformas como AVEVA System Platform o Ignition proponen arquitecturas unificadas capaces de asumir ambos roles, con una capa de interfaz común accesible directamente desde un navegador web.
Esta convergencia tiene consecuencias prácticas importantes. Simplifica las arquitecturas, reduce el número de sistemas que hay que mantener y facilita el acceso a los datos desde distintos tipos de dispositivos. Pero también introduce nuevas presiones sobre los equipos: un operador acostumbrado a experiencias digitales modernas en su vida cotidiana acepta cada vez menos una IHM con tiempos de refresco de varios segundos o con una ergonomía heredada de los años 2000.
La brecha entre la experiencia digital de consumo y la que ofrecen algunos sistemas de supervisión industrial se ha vuelto tan evidente que empieza a generar dificultades incluso en la formación y la adaptación de los operarios en determinados sectores.
La migración hacia interfaces hombre-máquina basadas en estándares web (HTML5, SVG, WebSocket) supone una auténtica ruptura tecnológica para el sector. En teoría, permite visualizar los sinópticos directamente desde un navegador, sin necesidad de cliente pesado, con actualizaciones centralizadas desde el servidor. Las mejoras en mantenimiento son reales.
Ahora bien, esta apertura arquitectónica tiene un reverso que los equipos de ciberseguridad industrial conocen bien. Una IHM accesible desde un navegador es, potencialmente, una IHM accesible desde la red IT de la empresa o incluso desde el exterior si la segmentación no está gestionada con rigor.
Las buenas prácticas en este ámbito exigen una disciplina estricta: separación entre las zonas OT e IT, ya sea física o lógica, despliegue de una DMZ industrial y autenticación multifactor para todos los accesos remotos. Son exigencias que el estándar IEC 62443 formaliza con precisión.
La ciberseguridad industrial ha sido durante mucho tiempo considerada por muchos actores del sector como una preocupación más bien teórica. El argumento habitual era que los sistemas OT estaban aislados, en redes air gap, y que nadie podía acceder a ellos desde el exterior. Sin embargo, este planteamiento ha ido perdiendo solidez a medida que se han documentado distintos incidentes en los últimos años.
El caso de Oldsmar, en Florida, en 2021, ilustra bien el problema. Un atacante logró tomar el control remoto de la IHM de una planta de tratamiento de agua potable y llegó a aumentar temporalmente la dosis de hidróxido de sodio hasta niveles peligrosos. El acceso fue posible debido a una IHM accesible de forma remota sin una autenticación robusta y a una segmentación de red insuficiente. Es un escenario que muchas instalaciones industriales tendrían dificultades para descartar por completo si analizaran con rigor su propia infraestructura.
Según el informe The Global State of Industrial Cybersecurity 2023 de Claroty, el 75 % de las organizaciones industriales encuestadas había sufrido al menos un ciberataque con impacto operativo directo durante los doce meses anteriores. Los vectores más frecuentes incluían el acceso remoto a IHM y sistemas SCADA, especialmente a través de herramientas de acceso remoto mal protegidas.
Hace falta cierta humildad para diseñar una buena interfaz hombre-máquina industrial. La humildad de reconocer que el operador que utiliza el sistema a diario suele conocer mejor sus necesidades reales que el ingeniero que lo diseña desde su despacho.
Bill Hollifield, autor de High Performance HMI Handbook, contribuyó a popularizar un enfoque de diseño centrado en el rendimiento operativo real, más que en la estética o en la riqueza funcional. Sus recomendaciones pueden parecer contraintuitivas a primera vista: sinópticos mayoritariamente en escala de grises, con pocos colores vivos y una reducción de valores numéricos en favor de indicadores de tendencia.
Detrás de esta aparente sobriedad hay una lógica sólida. Si todo está coloreado, nada es realmente prioritario. Si el rojo se utiliza para indicar un estado normal en ciertos equipos, pierde su función de alerta. La disciplina del color en una IHM industrial no es una cuestión de gusto, sino de seguridad.
La modernización de un parque de IHM en una instalación en producción es un ejercicio delicado. Con demasiada frecuencia, los proyectos empiezan con la ambición de una renovación completa y terminan en compromisos difíciles, con interfaces híbridas que acumulan los defectos de dos generaciones sin aprovechar las ventajas de ninguna.
El enfoque que mejor funciona, y en esto las experiencias del sector son bastante consistentes, es la migración por capas, por zonas o por niveles de criticidad decreciente. Primero se realiza una auditoría del sistema existente: cuántas alarmas por hora se generan en condiciones normales, qué sinópticos se utilizan con más frecuencia y en qué puntos los operadores pierden más tiempo navegando. Estos datos permiten establecer prioridades reales, no prioridades teóricas de ingeniería.
La fase de diseño posterior gana mucho cuando los operadores participan desde el inicio.
> Son preguntas a las que quienes trabajan a diario con el proceso suelen dar respuestas muy precisas.
La resistencia al cambio en estos proyectos suele malinterpretarse. No es irracional. Un operador que domina perfectamente su IHM anterior, aunque sea imperfecta, sabe que el periodo de transición es cuando estará más expuesto.
La IHM corresponde a la capa visible del sistema: los sinópticos, las pantallas y la consola con la que interactúa el operador. El SCADA, en cambio, designa el conjunto de la arquitectura: adquisición de datos de campo, transmisión, almacenamiento y visualización. En la práctica, ambos términos se utilizan a menudo de forma indistinta, y las plataformas modernas suelen integrar estas funciones en un único entorno de software.
La norma ISA-101 (ANSI/ISA-101.01-2015) es la referencia principal para el diseño de IHM en supervisión de procesos. La norma EEMUA 191 establece directrices para la gestión de alarmas con umbrales cuantificados. En materia de ciberseguridad de sistemas de control, la norma IEC 62443 es imprescindible, y sus requisitos tienen un impacto directo en la forma en que deben desplegarse y protegerse las IHM.
El análisis de los registros de alarmas es el primer indicador clave. Si la tasa de alarmas supera de forma habitual las 12 por hora en régimen normal, existe un problema estructural. Después, las entrevistas con los operadores de turno suelen revelar fricciones cotidianas que nunca se han formalizado: navegación excesivamente compleja, información mal jerarquizada, colores que no significan nada. Estas observaciones del terreno suelen ser más reveladoras que cualquier auditoría técnica.
Los accesos remotos no seguros ocupan el primer lugar: herramientas de acceso remoto dejadas activas, cuentas compartidas sin trazabilidad, sistemas operativos sin actualizar durante años. El phishing dirigido a operadores y técnicos de mantenimiento también representa un vector en crecimiento. La respuesta pasa por la segmentación de redes, la autenticación reforzada y, sobre todo, una cartografía actualizada de los accesos realmente expuestos.
La disponibilidad de la instalación es la prioridad absoluta. Sustituir una IHM en una planta en operación continua requiere una ventana de mantenimiento, formación del personal y un periodo de mayor riesgo. Por ello, muchas industrias prefieren prolongar su uso el mayor tiempo posible. Este enfoque es comprensible, pero genera problemas de soporte de software y, cada vez más, vulnerabilidades de ciberseguridad difíciles de corregir en sistemas cuyos fabricantes ya no publican actualizaciones. La tendencia actual se orienta hacia ciclos de renovación de 8 a 12 años como máximo.
Copyright © 2026. MOTILDE. All rights reserved.