Una HMI obsoleta rara vez falla en un momento conveniente. Puede ser una pantalla con retroiluminación degradada, un panel sin refacciones, un proyecto cuya fuente ya no está disponible o una estación que limita la ampliación de una línea. En un caso de migración HMI, el objetivo no es solamente reemplazar el hardware: es conservar el conocimiento operativo de la planta, reducir el riesgo de paro y entregar una interfaz mantenible, trazable y compatible con la arquitectura de control existente.
La migración exige revisar tanto la interacción del operador como la lógica, las comunicaciones y los dispositivos de campo que intervienen en cada maniobra. Una pantalla aparentemente simple puede concentrar arranques y paros, permisos, alarmas, recetas, tendencias, ajustes PID, secuencias de limpieza y diagnósticos esenciales para mantenimiento. Migrarla sin ingeniería previa puede trasladar defectos de la aplicación anterior o introducir nuevas condiciones de operación inseguras.
El punto de partida: obsolescencia con impacto operativo
Un caso típico ocurre en una línea de proceso o manufactura que utiliza una HMI instalada hace varios años, conectada a un PLC mediante PROFIBUS, Ethernet industrial u otra red existente. La aplicación continúa funcionando, pero la planta enfrenta uno o varios factores de riesgo: no hay disponibilidad confiable de refacciones, el equipo no es compatible con las versiones actuales de software, existen fallas intermitentes de comunicación o la interfaz ya no permite integrar nuevos equipos y señales.
El problema se vuelve más crítico cuando la HMI es el único medio práctico para operar una etapa del proceso. Si la pantalla falla, el PLC puede permanecer energizado y en condición correcta, pero el operador pierde visibilidad y capacidad de mando. En procesos con transportadores, dosificación, bombeo, control térmico, mezclado o sistemas CIP, esta condición puede detener producción, complicar la recuperación del proceso o aumentar el tiempo de diagnóstico.
Por ello, la decisión de migrar debe basarse en riesgo técnico y operativo, no únicamente en la antigüedad del panel. También debe considerar el ciclo de vida de la plataforma, la disponibilidad de respaldo, la criticidad de la estación, las ventanas de paro y los requerimientos futuros de producción.
Caso de migración HMI: alcance técnico correcto
En una migración bien definida, el alcance empieza por identificar qué hace realmente la HMI actual. Esto incluye inventariar pantallas, objetos gráficos, tags, alarmas, tendencias, recetas, usuarios, mensajes de diagnóstico, idiomas, reportes y conexiones con PLC, variadores, instrumentación o sistemas SCADA.
La revisión no debe limitarse a contar pantallas. Es necesario determinar qué funciones dependen de permisos de usuario, cuáles requieren confirmación del operador y cuáles cambian parámetros críticos. También se debe revisar cómo se presentan los estados de campo. Un motor puede mostrar “disponible”, “en marcha”, “falla” o “mantenimiento”, pero cada estado debe corresponder a señales, enclavamientos y filosofía de operación claramente definidos.
En plataformas Siemens, por ejemplo, la migración puede involucrar la transición hacia paneles SIMATIC HMI y proyectos desarrollados en TIA Portal con WinCC. La selección depende de la resolución requerida, condiciones ambientales, tipo de operación, conectividad, disponibilidad de puertos, necesidades de registro histórico y compatibilidad con el PLC. No siempre conviene replicar exactamente el equipo anterior: una pantalla mayor o una arquitectura basada en PC industrial puede ser justificable si la operación requiere tendencias, diagnóstico ampliado o integración con un nivel SCADA.
Sin embargo, aumentar capacidades también añade decisiones de ciberseguridad, mantenimiento y administración de respaldos. La solución adecuada depende de la criticidad del proceso y de la arquitectura completa, no de una preferencia de marca o del tamaño de la pantalla.
Levantamiento de información y respaldo
El primer entregable operativo debe ser un respaldo verificable de la aplicación disponible. Si se cuenta con archivos fuente, se revisan versiones de software, librerías, comunicación, licenciamiento y posibilidad de conversión. Si solo existe un archivo de ejecución o la documentación está incompleta, el proyecto requiere ingeniería inversa controlada mediante revisión en campo, capturas de pantalla, entrevistas con operadores y validación contra diagramas eléctricos, listas de I/O y programa de PLC.
Durante esta etapa se documentan las discrepancias entre planos y condición real. Es común encontrar cambios realizados durante mantenimientos o ampliaciones que nunca quedaron reflejados en los documentos As-Built. Identificarlos antes de programar evita que la nueva HMI reproduzca nombres de señales incorrectos, estados ambiguos o mandos que ya no corresponden al proceso.
Diseño de la nueva interfaz
La nueva aplicación debe conservar las funciones necesarias, pero no tiene que copiar los defectos de la interfaz anterior. Una migración es una oportunidad para estandarizar nomenclatura, jerarquía de alarmas, colores de estado, navegación y representación de equipos.
El diseño debe favorecer la lectura rápida en condiciones normales y anormales. Los colores no deben ser el único medio para distinguir un estado; los textos y símbolos deben ser consistentes. Las alarmas requieren prioridad, descripción clara, reconocimiento cuando aplique y una filosofía alineada con la operación. Una alarma sin contexto no ayuda a recuperar un proceso: “Falla bomba” debe permitir identificar el equipo, condición asociada y, cuando corresponda, la causa o permiso faltante.
En sistemas regulados, la revisión puede incluir perfiles de usuario, contraseñas, registro de eventos y trazabilidad de cambios conforme a los requerimientos aplicables, como GAMP 5 o 21 CFR Part 11. Estos controles deben definirse desde la especificación funcional, no añadirse al final de la programación.
Pruebas antes de intervenir la planta
La principal medida para proteger la continuidad operativa es probar fuera de línea todo lo que sea posible. La simulación de señales, la comunicación con un PLC de pruebas o el uso de una copia controlada del programa permiten verificar navegación, tags, alarmas, permisos y secuencias sin depender de la ventana de paro.
Una FAT debe ejecutarse contra una matriz de pruebas acordada. No basta con comprobar que cada pantalla abre correctamente. Deben probarse mandos, indicaciones, escalamiento de variables analógicas, límites, reconocimiento de alarmas, tendencias, recetas, cambios de usuario, recuperación tras reinicio y pérdida temporal de comunicación.
Antes de la puesta en marcha, conviene cerrar cuatro controles documentales:
- respaldo final de PLC, HMI y configuración de comunicaciones;
- lista de señales y equipos incluidos en el alcance;
- matriz FAT con resultados, observaciones y correcciones;
- procedimiento de reversión para reinstalar la condición anterior si aparece una desviación crítica.
El procedimiento de reversión no representa falta de confianza en el proyecto. Es una práctica de gestión de riesgo. Si la ventana de paro es limitada, la planta debe saber qué condición activa la reversión, quién toma la decisión y cuánto tiempo requiere recuperar operación.
Instalación, SAT y puesta en marcha
Durante la intervención se verifica primero la instalación física: alimentación, protecciones, tierra, montaje, identificación, cableado y condiciones del gabinete. Después se valida la red industrial, las direcciones de los equipos, la calidad de comunicación y el intercambio de datos con el PLC.
La SAT confirma que lo probado en entorno controlado corresponde a la condición real de planta. Aquí se ejecutan pruebas funcionales con operaciones y mantenimiento: arranques, paros, modos manual y automático, permisos, alarmas, variadores, válvulas, instrumentos y recuperación de condiciones de falla. Si la HMI participa en una modificación de proceso, la validación debe involucrar a los responsables del área y respetar los procedimientos internos de cambio.
La puesta en marcha no termina cuando la pantalla enciende. Debe concluir con respaldos finales, documentación As-Built, lista de pendientes cerrados o controlados, capacitación orientada al rol del usuario y entrega de los archivos necesarios para mantenimiento futuro. ProAIC Automatización puede integrar estas actividades desde la ingeniería y programación hasta FAT, SAT, comisionamiento y documentación del sistema.
Qué resultados debe dejar una migración bien ejecutada
El resultado esperado no es únicamente una HMI nueva. La planta debe recibir una plataforma con refacciones y soporte tecnológico disponibles, una aplicación ordenada, alarmas comprensibles, respaldos recuperables y documentación que permita intervenirla sin depender de conocimiento informal.
También debe mejorar la mantenibilidad. Cuando un técnico puede identificar un equipo, revisar su estado, confirmar la comunicación y rastrear una señal hasta el PLC con nombres consistentes, el diagnóstico se vuelve más rápido y menos dependiente de una sola persona. Esto es especialmente relevante en plantas con turnos continuos o con varios integradores históricos.
Una migración HMI bien planteada convierte una condición de obsolescencia en una oportunidad para recuperar control documental y disciplina operativa. La decisión más útil no es esperar a que el panel falle, sino definir el alcance, las pruebas y la ventana de intervención cuando la planta todavía tiene margen para elegir cómo modernizarse.
