Modernización de las HMI Bailey INFI 90 Symphony que se ejecutan en OpenVMS Alpha

Modernizar una HMI sin reemplazar todo el sistema INFI 90

Muchos sistemas Bailey INFI 90 siguen funcionando de forma fiable décadas después de su instalación original. Es posible que sus controladores, módulos de comunicación, unidades de terminación y E/S de campo aún realicen las funciones de control requeridas.

El problema más inmediato del ciclo de vida suele encontrarse por encima de la capa de controladores.

Las estaciones del operador pueden depender de hardware AlphaStation obsoleto, adaptadores gráficos sin soporte, dispositivos de almacenamiento antiguos y entornos de software OpenVMS Alpha desactualizados. Las piezas de repuesto son cada vez más difíciles de obtener, mientras que hay menos ingenieros con experiencia en OpenVMS y Bailey Symphony.

El ejemplo considerado aquí incluye cuatro estaciones de trabajo AlphaStation 255. Cada estación ejecuta OpenVMS Alpha y aloja funciones de interfaz del operador de Bailey Symphony para un sistema de control distribuido Bailey INFI 90.

El objetivo no es necesariamente reemplazar todo el DCS. Un objetivo más práctico es eliminar la dependencia del hardware AlphaStation obsoleto, preservando al mismo tiempo los controladores estables, el cableado de campo, los módulos de E/S, la lógica de control y las operaciones del proceso.

Esa distinción cambia la estrategia de modernización.

El proyecto es principalmente una migración de la interfaz del operador y de la plataforma informática. Solo se convierte en una migración completa del DCS cuando el ciclo de vida del controlador, los requisitos de ciberseguridad, los objetivos de producción o las condiciones de soporte justifican reemplazar las capas de control inferiores.

Existen varias rutas de modernización posibles. Sin embargo, preservan distintas partes del sistema existente.

Un emulador Alpha puede conservar casi todo el entorno de software. Una migración de OpenVMS x86 conserva la familia de sistemas operativos, pero requiere migrar las aplicaciones. Un reemplazo de la HMI basado en OPC conserva la capa de control mientras reconstruye la interfaz del operador. Una estrategia de evolución de ABB puede modernizar gradualmente la arquitectura Symphony más amplia.

Ninguna ruta debe describirse como un simple reemplazo por un PC.

Figura 1. Tres rutas principales de modernización pueden preservar distintas partes de la inversión instalada en Bailey INFI 90 y Symphony.

Por qué no basta con clonar el disco de la AlphaStation

La clonación de discos es útil para preservar un entorno OpenVMS Alpha instalado. Puede capturar el sistema operativo, los archivos de aplicaciones, la configuración de dispositivos, las cuentas de usuario, el software Bailey, las bases de datos, los gráficos y las configuraciones específicas del sitio.

Sin embargo, la clonación de discos no convierte el software Alpha en software x86.

El sistema operativo clonado aún contiene instrucciones para procesadores Alpha. Su núcleo, cargador de arranque, bibliotecas del sistema, aplicaciones y controladores de hardware fueron desarrollados para la arquitectura Alpha.

Un PC moderno estándar utiliza un procesador x86-64. También presenta controladores de almacenamiento, dispositivos de red, estructuras de interrupciones, hardware gráfico, interfaces de firmware y buses periféricos diferentes.

VMware, VirtualBox, Hyper-V y los hipervisores x86 convencionales virtualizan hardware compatible con x86. Normalmente no traducen las instrucciones del procesador Alpha a instrucciones x86.

Por lo tanto, colocar una imagen de disco de OpenVMS Alpha dentro de una máquina virtual x86 ordinaria no hace que esa imagen sea arrancable.

La máquina virtual puede proporcionar un disco virtual, un adaptador de red virtual y un dispositivo gráfico virtual. OpenVMS Alpha sigue esperando un procesador Alpha y dispositivos compatibles de la era Alpha.

Por eso deben mantenerse separados dos conceptos:

La virtualización normalmente presenta hardware virtual utilizando la misma arquitectura de procesador que el anfitrión.

La emulación entre arquitecturas reproduce por software otro procesador y entorno de hardware.

OpenVMS Alpha requiere el segundo enfoque cuando los binarios Alpha originales y el sistema operativo deben permanecer sin cambios.

Por lo tanto, la clonación de discos es viable en tres situaciones limitadas.

La primera es recuperarlo en el mismo modelo de AlphaStation con almacenamiento y periféricos compatibles.

La segunda es recuperarlo en otro sistema Alpha compatible después de completar los cambios necesarios en los dispositivos y la configuración.

La tercera es restaurarlo en un emulador Alpha que reproduzca un entorno compatible con AlphaServer o AlphaStation.

La clonación por sí sola no resuelve el problema de arquitectura. El entorno de destino aún debe comprender y ejecutar las instrucciones de máquina Alpha.

La emulación Alpha conserva la mayor parte de la inversión existente

La emulación Alpha suele ser la opción menos disruptiva cuando el software Symphony existente debe seguir operativo sin cambios en el código fuente.

Un emulador Alpha se ejecuta en hardware x86 moderno, pero presenta un sistema Alpha virtual a OpenVMS. El sistema operativo y las aplicaciones originales siguen viendo un entorno de hardware compatible con Alpha.

Productos como CHARON-AXP están diseñados para este propósito. El emulador sustituye el procesador Alpha físico, la arquitectura de memoria, los controladores de almacenamiento, los adaptadores Ethernet y otros dispositivos compatibles por equivalentes definidos por software.

El servidor x86 ejecuta Windows o Linux como entorno anfitrión. El emulador Alpha se ejecuta sobre ese anfitrión. OpenVMS Alpha se ejecuta dentro del sistema Alpha emulado.

Este enfoque es diferente de portar OpenVMS a x86.

La instalación original de OpenVMS Alpha sigue siendo una instalación Alpha. Los binarios de Bailey Symphony siguen siendo binarios Alpha. El emulador traduce o reproduce el comportamiento requerido del hardware Alpha.

Esto puede conservar:

• El sistema operativo OpenVMS Alpha instalado.

• Aplicaciones existentes de Bailey Symphony.

• Gráficos del operador y bases de datos de pantallas.

• Configuraciones de alarmas y archivos históricos.

• Cuentas de usuario y procedimientos de comandos.

• Utilidades existentes específicas del sitio.

• Interfaces de aplicaciones que dependen del entorno Alpha.

• Flujos de trabajo de los operadores que, de otro modo, requerirían capacitación adicional.

La migración práctica suele implicar la creación de una imagen verificada o una copia de seguridad de los discos Alpha originales. Esos datos se restauran en contenedores de discos virtuales utilizados por el emulador.

La configuración del emulador debe reproducir características adecuadas de CPU, memoria, disco, red y periféricos. Es posible que el equipo también deba asignar puertos serie físicos o interfaces de red a través del sistema anfitrión.

La emulación de Alpha puede reducir considerablemente la dependencia del hardware físico obsoleto. También puede simplificar las copias de seguridad, ya que los archivos de disco virtual pueden copiarse mediante una infraestructura de almacenamiento moderna.

Sin embargo, el término «cero cambios» debe utilizarse con cautela.

El código de la aplicación puede permanecer sin cambios, pero el entorno aún requiere ingeniería. Deben comprobarse las asignaciones de dispositivos. Deben configurarse las interfaces de red. Deben revisarse las licencias de OpenVMS y de la aplicación.

El emulador también debe probarse con la interfaz de comunicación Bailey utilizada en el sitio.

Una aplicación genérica de OpenVMS puede funcionar correctamente mientras una interfaz DCS especializada falla porque depende de un adaptador de red, una interfaz de bus, un dispositivo serie o un comportamiento temporal específicos.

Por lo tanto, la configuración exacta de la AlphaStation 255 debe inventariarse antes de seleccionar un perfil de emulador.

La interfaz de comunicación Bailey es la prueba crítica de la emulación

La pregunta más importante sobre la emulación no es si OpenVMS llega al indicador de inicio de sesión.

La pregunta importante es si la estación emulada se comunica correctamente con el sistema Bailey INFI 90 en condiciones operativas completas.

La interfaz puede depender de Ethernet, comunicación serie, una interfaz de red Bailey o hardware de comunicación especializado. Las configuraciones del sitio pueden variar considerablemente.

Antes de comprometerse con la emulación de Alpha, los ingenieros deberían documentar:

• La interfaz de red física instalada en cada AlphaStation.

• El protocolo de comunicación utilizado entre Symphony e INFI 90.

• Nombres de dispositivos asignados dentro de OpenVMS.

• Direcciones de red y definiciones de nodos.

• Servicios DECnet, TCP/IP, LAT o propietarios necesarios.

• Configuración de los puertos serie, cuando corresponda.

• Cualquier clave de licencia externa o dongle de hardware.

• Comportamiento de redundancia y conmutación por error entre estaciones de operador.

• Requisitos de sincronización horaria.

• Funciones gráficas y de teclado utilizadas por los operadores.

Un proveedor de emuladores puede admitir dispositivos Ethernet y de almacenamiento Alpha comunes. Eso no confirma automáticamente la compatibilidad con todas las interfaces Bailey propietarias.

Si la HMI existente depende de un adaptador físico especializado que no puede virtualizarse, la opción del emulador puede requerir una pasarela de comunicación alternativa.

Por lo tanto, el proyecto debe incluir una prueba en banco con una estación clonada y acceso a una red Bailey representativa.

La prueba debe incluir más que la lectura estática de etiquetas. Los operadores deben verificar los valores en tiempo real, los comandos, las alarmas, el reconocimiento, las tendencias, la navegación por las pantallas, la impresión, la gestión de eventos y la recuperación de las estaciones.

El rendimiento también debe probarse durante ráfagas de alarmas y una alta actividad de actualización de etiquetas.

OpenVMS x86-64 es una vía de migración diferente

El OpenVMS moderno está disponible para la arquitectura x86-64. Puede operar en entornos virtualizados compatibles sobre servidores modernos.

Esto crea una opción de migración adicional que no estaba disponible durante muchos debates anteriores sobre la modernización de INFI 90.

Sin embargo, OpenVMS x86-64 no ejecuta directamente binarios de OpenVMS Alpha como si fueran aplicaciones x86 nativas.

Debe migrarse el entorno de la aplicación.

Es posible que haya que transferir, revisar, recompilar, enlazar y probar el código fuente para x86-64. Las bibliotecas de terceros y los productos en capas también deben estar disponibles para la versión de destino.

La pregunta central es si el software Bailey Symphony instalado tiene una versión de OpenVMS compatible con x86.

Si el proveedor del software nunca lanzó esa aplicación para OpenVMS x86-64, trasladar únicamente el sistema operativo no conserva la HMI.

Los programas desarrollados en el sitio pueden ser portables cuando su código fuente y entorno de compilación sigan disponibles. Normalmente, las aplicaciones comerciales cerradas no pueden recompilarse sin el soporte del proveedor.

Esta vía aún puede ser práctica para servidores de datos personalizados, historiadores, utilidades, informes y aplicaciones de integración que se ejecutan junto con la HMI Symphony.

Es menos probable que conserve un antiguo entorno de operador propietario Symphony sin una versión compatible de la aplicación.

Una evaluación de migración de OpenVMS x86 debe identificar:

• Cada ejecutable instalado y producto en capas.

• Código fuente disponible y procedimientos de compilación.

• Dependencias del compilador y del entorno de ejecución.

• Productos de bases de datos y formatos de archivo.

• Bibliotecas de comunicación propietarias.

• Dependencias de gráficos o del sistema de ventanas.

• Disponibilidad de licencias para x86-64.

• Cambios necesarios causados por las diferencias de arquitectura.

• Supuestos de rendimiento y temporización.

Esta vía tiene un mayor potencial a largo plazo que pasar de Alpha a otra arquitectura de hardware discontinuada. Puede trasladar cargas de trabajo OpenVMS compatibles a una infraestructura de virtualización x86 compatible.

No obstante, debe describirse como un proyecto de migración de aplicaciones, no como un proyecto de clonación de discos.

Por qué una migración desde Itanium suele ser una opción de transición

OpenVMS también se lanzó para servidores HPE Integrity que utilizaban la arquitectura Itanium.

Existen herramientas de migración y métodos de ingeniería para trasladar algunas aplicaciones Alpha a OpenVMS Integrity. Esto ofrecía una vía compatible para abandonar el hardware Alpha obsoleto.

Sin embargo, hoy el hardware Itanium es en sí mismo una plataforma heredada.

Un traslado de Alpha a Integrity puede eliminar una dependencia de hardware obsoleta y crear otra. Los servidores, repuestos, interfaces de almacenamiento y conocimientos especializados adecuados seguirán estando cada vez menos disponibles.

Itanium aún puede ser pertinente cuando el sitio ya cuenta con infraestructura Integrity compatible. También puede ser pertinente cuando existe un producto estratificado necesario para Integrity, pero no para x86-64.

Para un nuevo proyecto de modernización, generalmente debe evaluarse como una opción de compatibilidad intermedia.

La justificación empresarial debe explicar por qué trasladarse a Integrity es preferible a la emulación de Alpha, la migración de OpenVMS x86 o la reestructuración de la HMI.

La reestructuración mediante OPC conserva la capa de control

La reestructuración mediante OPC sustituye la capa de interfaz del operador, manteniendo los controladores INFI 90 existentes y la E/S de campo.

Un servidor de comunicación se conecta al sistema Bailey y expone las etiquetas de proceso a una plataforma HMI o SCADA moderna.

La nueva HMI gestiona pantallas, alarmas, tendencias, seguridad, comandos del operador, informes y servicios de las estaciones de trabajo.

Esta opción elimina la dependencia de la aplicación de operación Symphony original. También evita la necesidad de ejecutar OpenVMS Alpha en las nuevas estaciones del operador.

La arquitectura suele incluir:

• Controladores y E/S Bailey INFI 90 existentes.

• Una interfaz de comunicación Bailey compatible.

• Un servidor de datos OPC DA, OPC UA o específico del proveedor.

• Una plataforma HMI o SCADA moderna.

• Estaciones de trabajo de operación e ingeniería.

• Servicios opcionales de historiador, generación de informes y análisis de alarmas.

Un ejemplo de campo mencionado en el material de origen utilizó un servidor OPC de RoviSys con GE CIMPLICITY. El sistema informado funcionó correctamente, pero el proyecto requirió reconstruir las pantallas del operador y la lógica de animación.

Este ejemplo no debe interpretarse como una recomendación automática de producto para todas las instalaciones INFI 90.

El servidor seleccionado debe admitir la red Bailey específica, los módulos de comunicación, la generación de controladores, el número de etiquetas, la frecuencia de actualización, los requisitos de redundancia y las funciones de comando del sitio.

Lo mismo se aplica a la plataforma HMI.

GE CIMPLICITY es una posible plataforma HMI/SCADA empresarial. Otros sistemas también pueden ser viables si proporcionan la conectividad OPC, los gráficos, las alarmas, los scripts, la redundancia, la seguridad y el soporte durante todo el ciclo de vida necesarios.

Figura 2. Una migración basada en OPC conserva la capa de control INFI 90 y sustituye el entorno de operación Symphony heredado.

La conectividad OPC no convierte las pantallas existentes

Un servidor OPC proporciona conectividad de datos. Normalmente no convierte las pantallas HMI antiguas a un formato HMI nuevo.

Las pantallas originales de Symphony pueden contener gráficos estáticos, símbolos dinámicos, cambios de color, valores numéricos, gráficos de barras, indicadores de alarma, botones de navegación, controles de comandos, tendencias y plantillas de funciones personalizadas.

Estos elementos deben recrearse en la HMI de destino.

Las pantallas simples pueden redibujarse directamente. Las pantallas complejas pueden contener scripts o expresiones ocultos que no son inmediatamente visibles.

Los ingenieros deben comprender cómo cada objeto animado obtiene y procesa sus datos.

Un símbolo de válvula puede no seguir simplemente una etiqueta de salida. Su color y posición pueden depender de la realimentación de apertura, la realimentación de cierre, el estado del comando, el estado del enclavamiento, la calidad de la comunicación y el modo del equipo.

Un símbolo de motor puede utilizar etiquetas independientes para el comando de arranque, la realimentación de marcha, el estado detenido, el disparo, el control local, el estado de mantenimiento, los permisos y la inhibición de alarmas.

Por lo tanto, trasladar únicamente los gráficos visibles puede crear una HMI que parezca correcta, pero funcione de manera incorrecta.

El equipo de migración debe documentar el significado funcional de cada elemento de la pantalla.

Este trabajo incluye:

• Asignar cada objeto dinámico a su fuente de datos.

• Recrear las expresiones de animación.

• Verificar la confirmación de comandos y la seguridad.

• Reconstruir la navegación y las jerarquías de las pantallas.

• Recrear las clases y prioridades de las alarmas.

• Confirmar las unidades de ingeniería y la precisión decimal.

• Reconstruir las tendencias históricas y en tiempo real.

• Probar los estados de comunicación no válidos, inciertos y fallidos.

• Reproducir los mensajes y las instrucciones para el operador.

• Sustituir fuentes y símbolos no compatibles.

Por lo tanto, el esfuerzo está determinado por la complejidad de las pantallas, no solo por su cantidad.

Una HMI moderna no debe copiar ciegamente todas las pantallas heredadas

La recreación manual brinda la oportunidad de mejorar la interfaz del operador.

Los gráficos HMI heredados suelen utilizar colores brillantes para los equipos en condiciones normales, diagramas de proceso densos, tuberías decorativas e indicaciones de alarma incoherentes.

Estas convenciones pueden haber sido razonables cuando se desarrolló el sistema original. No siempre son ideales para las prácticas actuales de las salas de control.

Un proyecto de modernización debería revisar:

• Jerarquía de las pantallas.

• Visibilidad de las alarmas.

• Coherencia de la navegación.

• Presentación del estado del equipo.

• Uso del color.

• Accesibilidad de las tendencias.

• Requisitos de respuesta del operador.

• Resolución de pantalla y distribución de las estaciones de trabajo.

• Accesibilidad y legibilidad.

Las condiciones normales de operación deben permanecer visualmente despejadas. Los colores intensos deben identificar los estados anormales que requieren atención.

Los operadores deben poder pasar de una vista general de la planta a la unidad afectada, la carátula del equipo, la tendencia, el historial de alarmas y la pantalla de diagnóstico sin una navegación excesiva.

Sin embargo, un rediseño excesivo puede crear otro riesgo.

Es posible que los operadores hayan utilizado las pantallas originales durante muchos años. Cambiar todos los símbolos, colores y rutas de navegación en el mismo proyecto puede aumentar las necesidades de capacitación y el riesgo durante la puesta en servicio.

Un enfoque equilibrado conserva las relaciones de proceso conocidas y, al mismo tiempo, mejora la presentación de alarmas y la navegación.

La extracción de etiquetas debe tratarse como un paquete de trabajo de ingeniería

El material de origen plantea la posibilidad de exportar los datos de etiquetas de Bailey a CSV. No proporciona un procedimiento universal confirmado.

Por lo tanto, no debe suponerse que un único comando de exportación producirá una base de datos HMI completa y limpia.

Entre las posibles fuentes de información de etiquetas se incluyen:

• Bases de datos de configuración de Symphony.

• Definiciones de pantallas existentes.

• Registros de configuración e ingeniería de los controladores.

• Bases de datos del servidor de comunicaciones Bailey.

• Funciones de exploración del servidor OPC.

• Archivos de configuración de alarmas.

• Bases de datos históricas.

• Listas de etiquetas impresas o archivadas.

• Hojas de cálculo de ingeniería del sitio.

La exploración de OPC puede proporcionar un punto de partida práctico después de que el servidor establezca la comunicación con el sistema Bailey.

Puede exponer nombres de etiquetas, identificadores de elementos, descripciones, calidad y valores actuales. Algunos servidores también permiten exportar el espacio de nombres explorado.

Sin embargo, un espacio de nombres OPC puede no incluir todos los campos necesarios para la nueva HMI.

Las prioridades de las alarmas, los límites de ingeniería, las agrupaciones de pantallas, las notas del operador, la seguridad de los comandos y las relaciones entre equipos pueden almacenarse en otros lugares.

Algunos servidores OPC exponen etiquetas mediante nombres generados que difieren de los nombres originales de Symphony.

El proyecto debe crear un registro maestro controlado de etiquetas que contenga como mínimo:

• Nombre original de la etiqueta.

• Nombre de la etiqueta de la nueva HMI.

• Identificador del elemento OPC.

• Descripción.

• Tipo de datos.

• Permiso de lectura o escritura.

• Unidades de ingeniería.

• Información de escalado.

• Límites y prioridad de las alarmas.

• Frecuencia de actualización.

• Pantalla asociada.

• Estado de validación.

• Resultado de la prueba.

Este registro maestro se convierte en el registro de conciliación entre los sistemas heredado y nuevo.

El número de etiquetas no es el único requisito de comunicación

Una prueba de exploración exitosa no demuestra que la arquitectura OPC pueda admitir la HMI completa.

Los ingenieros deben evaluar el número de etiquetas activas, la frecuencia de actualización solicitada, la frecuencia de cambios, la actividad de alarmas, el tráfico de comandos y la redundancia del servidor.

Un sistema puede contener decenas de miles de etiquetas configuradas. Solo una parte puede estar activa simultáneamente en las pantallas del operador.

El servidor y la HMI deben probarse en condiciones realistas.

Las comprobaciones de rendimiento importantes incluyen:

• Tiempo necesario para abrir una pantalla compleja.

• Retraso entre un cambio en campo y la animación en la HMI.

• Entrega de alarmas durante ráfagas de eventos.

• Recopilación de tendencias a la frecuencia de muestreo requerida.

• Tiempo de ejecución del comando y de respuesta.

• Recuperación después de una interrupción de red.

• Conmutación por error entre servidores redundantes.

• Comportamiento después de reiniciar el controlador.

• Estado de calidad durante un fallo de comunicación.

• Carga de CPU, memoria y red.

Los comandos requieren especial atención.

Leer valores mediante OPC puede ser relativamente sencillo. Escribir valores de forma segura requiere control de acceso, validación de comandos, confirmación de la respuesta y gestión correcta de los fallos de comunicación.

El equipo debe probar todos los tipos de comandos del operador, no solo una etiqueta representativa.

ABB Symphony Plus ofrece una ruta de evolución más amplia

Una sustitución de OPC no es la única opción para un sistema Bailey instalado.

ABB sigue posicionando Symphony Plus como una plataforma de evolución para instalaciones Bailey, INFI 90, Harmony Rack y Symphony antiguas.

Una modernización de ABB por fases puede conservar partes de la arquitectura instalada de control y E/S, al tiempo que introduce componentes más recientes para operadores, ingeniería, redes, controladores o E/S.

Esta opción puede resultar atractiva cuando la organización desea una estrategia de ciclo de vida respaldada por el proveedor en lugar de una sustitución independiente de la HMI.

El proyecto puede modernizar primero el entorno del operador. Los controladores y la E/S pueden permanecer en servicio hasta que su ciclo de vida o valor operativo justifique su sustitución.

Las fases posteriores pueden abordar las comunicaciones, los controladores, las herramientas de ingeniería y las interfaces de campo.

La arquitectura exacta de la migración depende de la generación del sistema instalado.

Las instalaciones Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony y Symphony Plus no utilizan todas las mismas interfaces.

Los nombres de los módulos y la terminología de red deben verificarse en los planos de la planta y los inventarios de hardware.

Las organizaciones que mantienen la capa de control existente también pueden revisar los componentes ABB Bailey INFI 90 y Network 90 disponibles al planificar la cobertura de repuestos, el soporte durante el ciclo de vida y la modernización por fases.

Este enlace interno es relevante porque los proyectos de modernización a menudo requieren que el sistema antiguo permanezca operativo durante la ingeniería, las pruebas y la transición gradual.

Mantener controladores, módulos de comunicación, fuentes de alimentación y módulos de E/S de repuesto adecuados puede reducir el riesgo durante esa transición.

Una HMI personalizada o de código abierto es posible, pero requiere asumir la responsabilidad

Una HMI personalizada puede desarrollarse utilizando frameworks de software de código abierto o comerciales.

El material fuente menciona un servidor residente en VMS con un cliente moderno basado en Qt. Las arquitecturas de este tipo pueden separar la conexión de datos del lado del servidor del cliente del operador.

Esta opción puede ofrecer flexibilidad y evitar la dependencia de un único proveedor de HMI.

También puede convertirse en un compromiso de desarrollo de software a largo plazo.

La organización debe ser propietaria de lo siguiente o encargarse de su mantenimiento:

• Servidor de comunicaciones.

• Base de datos de tags.

• Aplicación cliente.

• Framework gráfico.

• Procesamiento de alarmas.

• Integración con el historiador.

• Autenticación de usuarios.

• Actualizaciones de ciberseguridad.

• Implementación y control de versiones.

• Documentación y capacitación.

Qt, Python, C++, las tecnologías web u otros frameworks pueden producir interfaces industriales capaces. La dificultad no está en dibujar un gráfico de proceso.

La dificultad consiste en crear un sistema de operación fiable que funcione correctamente durante fallos de comunicación, reinicios del servidor, avalanchas de alarmas, cambios de usuario y condiciones anómalas de la planta.

Solo se debe seleccionar una plataforma personalizada cuando la organización cuente con un equipo de ingeniería sostenible o un integrador fiable a largo plazo.

Las licencias pueden determinar si una ruta técnica es viable

El software industrial heredado suele utilizar mecanismos de licencia vinculados a identificadores de hardware, direcciones Ethernet, bases de datos de licencias, dongles o claves de autorización emitidas por el proveedor.

Un sistema clonado puede arrancar correctamente, pero negarse a iniciar la aplicación Symphony porque cambió la identidad del hardware virtual.

El inventario de migración debe incluir:

• Licencias del sistema operativo OpenVMS.

• Licencias de aplicaciones Bailey Symphony.

• Licencias de bases de datos.

• Licencias de red y comunicaciones.

• Licencias de emulador.

• Licencias de cantidad de puntos HMI y OPC.

• Licencias de historiador.

• Opciones de redundancia.

• Licencias de clientes de ingeniería.

• Licencias de clientes de tiempo de ejecución.

Debe obtenerse una confirmación por escrito antes de elegir la plataforma definitiva.

La compatibilidad técnica sin disponibilidad de licencias legales no crea una solución implementable.

La ciberseguridad debe integrarse en el diseño del reemplazo

Los sistemas AlphaStation antiguos se instalaban con frecuencia antes de que las prácticas modernas de ciberseguridad industrial se convirtieran en un estándar.

Pueden operar en redes aisladas con acceso remoto limitado. Reemplazarlos por servidores Windows, clientes SCADA modernos, servidores OPC e infraestructura Ethernet cambia la superficie de ataque.

La nueva arquitectura debe definir zonas de red independientes para control, servidores, ingeniería y empresa.

Los firewalls deben permitir únicamente las rutas de comunicación necesarias. El acceso remoto debe utilizar autenticación administrada y registrarse.

Las cuentas de operador deben seguir permisos basados en roles. Las funciones de ingeniería no deben estar disponibles desde todos los clientes HMI.

El acceso de escritura de OPC debe restringirse a las etiquetas y estaciones que lo requieran.

El diseño también debe abordar:

• Aplicación de parches del sistema operativo.

• Antivirus o control de aplicaciones.

• Respaldo y recuperación.

• Sincronización horaria.

• Registro de seguridad.

• Controles de medios extraíbles.

• Soporte remoto del proveedor.

• Gestión de certificados para OPC UA.

• Gestión del ciclo de vida de las cuentas.

Los controles de ciberseguridad no deben impedir que los operadores respondan durante eventos en la planta. El diseño debe equilibrar la protección con la disponibilidad y la operación determinista.

La migración debe comenzar con un inventario basado en evidencias

Antes de seleccionar una ruta, los ingenieros deben documentar detalladamente el sistema existente.

El inventario debe incluir las cuatro AlphaStation e identificar si sus configuraciones son realmente idénticas.

Registro:

• Modelo de AlphaStation y configuración del procesador.

• Capacidad de memoria.

• Tipo de disco y volúmenes lógicos.

• Versión y nivel de parches de OpenVMS.

• Versiones del software Bailey instalado.

• Productos en capas y bases de datos.

• Hardware gráfico y resolución de pantalla.

• Adaptadores de red.

• Interfaces seriales.

• Hardware de comunicación Bailey.

• Nombres y direcciones de los nodos.

• Procedimientos de comandos de inicio.

• Archivos de licencia.

• Procedimientos de respaldo.

• Redundancia de estaciones de operador.

• Impresoras conectadas y dispositivos externos.

• Retención de datos históricos y de alarmas.

El equipo también debe recopilar capturas de pantalla de cada pantalla. Los estados dinámicos deben capturarse cuando sea posible.

Registre los estados normal, detenido, en funcionamiento, con alarma, inhibido, local, manual, automático y con fallo de comunicación.

Esta evidencia es esencial cuando se prueban las nuevas pantallas.

Un sistema de banco es obligatorio

Ninguna ruta de modernización debe probarse por primera vez en el sistema de producción activo.

Un entorno de banco debe reproducir una parte suficiente de la arquitectura instalada para validar la comunicación y las funciones del operador.

Para un proyecto de emulación, el banco debe contener un entorno OpenVMS Alpha clonado y la configuración propuesta del emulador.

Para un proyecto OPC, debe incluir el servidor de comunicación seleccionado, el software HMI, gráficas representativas y acceso a un nodo de prueba Bailey seguro o a una fuente de datos simulada.

La prueba en banco debe verificar:

• Arranque del sistema e inicio de la aplicación.

• Comunicación con el sistema Bailey.

• Cantidad total de etiquetas accesibles.

• Operaciones de lectura y escritura.

• Escalado de etiquetas y unidades de ingeniería.

• Generación y reconocimiento de alarmas.

• Recopilación de tendencias.

• Animación de las pantallas.

• Seguridad de los comandos.

• Funciones de impresión e informes.

• Comportamiento tras reiniciar el servidor.

• Comportamiento ante fallos de red.

• Redundancia y conmutación por error.

• Restauración de copias de seguridad.

• Tiempo de respuesta del operador.

Los resultados de las pruebas deben ser presenciados por representantes de operaciones, ingeniería de control, mantenimiento y ciberseguridad.

La operación en paralelo reduce el riesgo de la conmutación

Las AlphaStation originales deben seguir disponibles durante el despliegue inicial del sistema de reemplazo.

La nueva HMI puede funcionar en paralelo mientras los ingenieros comparan valores, alarmas, tendencias y comandos.

La operación en paralelo permite identificar discrepancias antes de retirar la estación antigua.

El equipo debe conciliar:

• Valores de proceso mostrados.

• Indicaciones de estado.

• Prioridades de las alarmas.

• Marcas de tiempo de las alarmas.

• Resultados de los comandos.

• Valores de tendencias.

• Modo del equipo.

• Calidad de la comunicación.

• Permisos de seguridad.

No toda diferencia representa un error. El nuevo sistema puede utilizar una escala mejorada o una presentación de alarmas mejorada.

Aun así, toda diferencia debe explicarse y aprobarse.

Las estaciones antiguas deben seguir siendo recuperables hasta que la nueva HMI supere una prueba de aceptación en sitio presenciada y un período operativo acordado.

Elegir la ruta de migración correcta

Elija la emulación de Alpha cuando:

La aplicación Symphony existente debe permanecer sin cambios. No hay código fuente disponible. Las gráficas del operador son complejas. Se debe minimizar el reciclaje del personal. La interfaz de comunicación Bailey puede ser compatible con la arquitectura del emulador.

Elija la migración de OpenVMS a x86 cuando:

Las aplicaciones requeridas están disponibles para x86-64 o pueden recompilarse. El código fuente y los conocimientos de ingeniería siguen disponibles. La organización desea conservar OpenVMS mientras migra a un entorno x86 compatible.

Elija una reestructuración sobre OPC cuando:

El controlador y las capas de E/S de INFI 90 sigan siendo fiables. La organización quiera una plataforma HMI moderna. Haya recursos de ingeniería disponibles para reconstruir y validar las pantallas, las alarmas, las etiquetas y la lógica de comandos.

Elija una ruta de evolución de ABB cuando:

La organización quiera un programa de modernización más amplio con soporte del proveedor. Las fases futuras pueden incluir sistemas de operador, herramientas de ingeniería, interfaces de red, controladores y E/S.

Elija una HMI personalizada cuando:

La organización tenga requisitos especializados y pueda mantener a largo plazo el desarrollo de software, las pruebas, la ciberseguridad y el mantenimiento durante todo el ciclo de vida.

Conserve temporalmente el sistema existente cuando:

Las interfaces de migración siguen sin estar claras. Las copias de seguridad están incompletas. La concesión de licencias no está resuelta. Las bases de datos de etiquetas no están disponibles. Las pruebas en banco aún no pueden reproducir la ruta de comunicación de Bailey.

Un plan práctico de modernización por fases

Fase 1: Preserve el entorno existente.

Cree copias de seguridad de imagen verificadas de cada AlphaStation. Registre los detalles del hardware, el software, la red, las licencias y el arranque. Pruebe la restauración siempre que sea posible.

Fase 2: Identifique la arquitectura de comunicaciones.

Documente exactamente cómo se comunica cada estación Symphony con INFI 90. Confirme si la interfaz puede emularse o sustituirse por un servidor compatible.

Fase 3: Cree una prueba de concepto.

Pruebe una estación clonada en un emulador de Alpha o conecte un servidor OPC a un nodo Bailey representativo.

Fase 4: Cree el registro maestro de etiquetas.

Concilie las etiquetas de los controladores, los identificadores de elementos OPC, las unidades de ingeniería, los comandos, las alarmas y el uso de las pantallas.

Fase 5: Reconstruya pantallas representativas.

Seleccione varias pantallas que contengan distintos requisitos de animación, alarmas, comandos y tendencias.

Fase 6: Complete la aceptación en banco.

Pruebe la carga completa de etiquetas, los fallos de comunicación, el reinicio del servidor, las ráfagas de alarmas, el comportamiento de los comandos y la restauración de copias de seguridad.

Fase 7: Implemente en paralelo.

Opere las HMI nuevas y antiguas en conjunto. Compare los valores y las respuestas de los operadores.

Fase 8: Realice el cambio supervisado.

Utilice un procedimiento de prueba aprobado. Mantenga las AlphaStation disponibles como respaldo.

Fase 9: Retire gradualmente el hardware antiguo.

No destruya las imágenes originales, los registros de configuración, las licencias ni el hardware hasta completar la aceptación a largo plazo.

Preguntas frecuentes

¿Se puede clonar directamente el disco de una AlphaStation con OpenVMS en un PC moderno?

No. La imagen contiene código de máquina Alpha y requiere hardware compatible con Alpha. Un PC x86 moderno no puede arrancarla directamente. La imagen debe restaurarse en hardware Alpha compatible o en un emulador de Alpha.

¿Pueden VMware o VirtualBox ejecutar OpenVMS?

Pueden ejecutar versiones compatibles de OpenVMS x86-64. No convierten una instalación antigua de OpenVMS Alpha en una aplicación x86. OpenVMS Alpha requiere emulación de Alpha.

¿Se pueden conservar las pantallas Symphony originales?

Por lo general, pueden conservarse cuando todo el entorno Alpha se ejecuta en un emulador compatible. Normalmente requieren una recreación manual al migrar a otra plataforma HMI.

¿Un servidor OPC exporta automáticamente todas las etiquetas Bailey?

No necesariamente. La exploración mediante OPC puede proporcionar un espacio de nombres útil, pero la configuración de alarmas, las relaciones entre pantallas, los comandos, las descripciones y los metadatos de ingeniería pueden requerir extracción y conciliación adicionales.

¿Es GE CIMPLICITY la única HMI de reemplazo?

No. Es una plataforma posible y aparece en el ejemplo de campo proporcionado con la fuente. La selección final debería depender de la compatibilidad de las comunicaciones, la redundancia, las licencias, la ciberseguridad, los recursos de ingeniería y los requisitos de los operadores.

¿Sigue siendo conveniente migrar de Alpha a Itanium?

Puede estar justificado cuando el software necesario solo está disponible para sistemas Integrity o cuando ya se cuenta con una infraestructura Integrity compatible. Por lo general, es una ruta transitoria y no la estrategia de modernización a largo plazo más sólida.

¿Pueden mantenerse instalados los controladores y las E/S INFI 90?

Sí, cuando sigan siendo fiables y la arquitectura de comunicación seleccionada las admita. La modernización de la HMI puede completarse por separado de la sustitución de los controladores y las E/S.

¿Deben retirarse inmediatamente las AlphaStation antiguas después de la puesta en servicio?

No. Deben seguir disponibles como recurso alternativo probado hasta que el nuevo entorno del operador supere la aceptación funcional, de rendimiento y operativa.

La solución correcta depende de lo que deba conservarse

El principal error técnico en muchos planes de HMI heredadas es tratar la estación del operador como un PC común.

Una AlphaStation que ejecuta OpenVMS Alpha y Bailey Symphony es un entorno completo de hardware y software. Su arquitectura de procesador, sistema operativo, interfaces de comunicación, binarios de aplicaciones, licencias, gráficos y conexiones al sistema de control son interdependientes.

Un clon del disco conserva los datos. No traduce ese entorno a otra arquitectura.

La emulación de Alpha ofrece la ruta más directa cuando toda la instalación Symphony debe mantenerse sin cambios.

OpenVMS x86-64 proporciona una ruta hacia un sistema operativo moderno cuando las aplicaciones pueden migrarse o reconstruirse.

La migración de plataforma OPC ofrece una ruta práctica cuando la capa de control INFI 90 sigue siendo valiosa, pero se debe reemplazar la capa del operador.

La evolución de ABB Symphony Plus puede proporcionar una estrategia escalonada más amplia cuando la organización desea modernizarse más allá de la HMI.

La decisión final debería basarse en un inventario verificado, un estudio de las interfaces de comunicación, una revisión de las licencias, una prueba de concepto, una prueba en banco y una aceptación operativa presenciada.

No existe un cambio sin esfuerzo. Sin embargo, hay varias rutas de migración controladas que pueden proteger la inversión existente en control de procesos y, al mismo tiempo, eliminar la dependencia del hardware AlphaStation obsoleto.