Modernização das HMIs Bailey INFI 90 Symphony em execução no OpenVMS Alpha

Modernizando uma IHM sem substituir todo o sistema INFI 90

Muitos sistemas Bailey INFI 90 continuam operando de forma confiável décadas após sua instalação original. Seus controladores, módulos de comunicação, unidades de terminação e E/S de campo ainda podem executar as funções de controle necessárias.

O problema mais imediato do ciclo de vida geralmente está localizado acima da camada dos controladores.

As estações do operador podem depender de hardware AlphaStation antigo, adaptadores gráficos sem suporte, dispositivos de armazenamento obsoletos e ambientes de software OpenVMS Alpha antigos. As peças de reposição tornam-se difíceis de obter, enquanto engenheiros experientes em OpenVMS e Bailey Symphony ficam cada vez menos disponíveis.

O exemplo considerado aqui inclui quatro estações de trabalho AlphaStation 255. Cada estação executa o OpenVMS Alpha e hospeda funções de interface do operador do Bailey Symphony para um sistema de controle distribuído Bailey INFI 90.

O objetivo não é necessariamente substituir todo o DCS. Um objetivo mais prático é eliminar a dependência do hardware AlphaStation antigo, preservando controladores estáveis, cabeamento de campo, módulos de E/S, lógica de controle e operações do processo.

Essa distinção muda a estratégia de modernização.

O projeto é principalmente uma migração da interface do operador e da plataforma computacional. Ele só se torna uma migração completa do DCS quando o ciclo de vida dos controladores, os requisitos de cibersegurança, os objetivos de produção ou as condições de suporte justificarem a substituição das camadas inferiores de controle.

Há vários caminhos possíveis de modernização. No entanto, eles preservam partes diferentes do sistema existente.

Um emulador Alpha pode preservar quase todo o ambiente de software. Uma migração do OpenVMS para x86 preserva a família do sistema operacional, mas exige a migração dos aplicativos. Uma substituição da IHM baseada em OPC preserva a camada de controladores enquanto reconstrói a interface do operador. Uma estratégia de evolução da ABB pode modernizar a arquitetura mais ampla do Symphony em etapas.

Nenhum caminho deve ser descrito como uma simples substituição por PCs.

Figura 1. Três principais caminhos de modernização podem preservar diferentes partes do investimento instalado em Bailey INFI 90 e Symphony.

Por que clonar o disco da AlphaStation não é suficiente

A clonagem de disco é útil para preservar um ambiente OpenVMS Alpha instalado. Ela pode capturar o sistema operacional, os arquivos de aplicativos, a configuração de dispositivos, as contas de usuário, o software Bailey, os bancos de dados, os gráficos e as configurações específicas do local.

No entanto, a clonagem de um disco não converte software Alpha em software x86.

O sistema operacional clonado ainda contém instruções para processadores Alpha. Seu kernel, carregador de inicialização, bibliotecas do sistema, aplicativos e drivers de hardware foram desenvolvidos para a arquitetura Alpha.

Um PC moderno padrão usa um processador x86-64. Ele também apresenta controladores de armazenamento, dispositivos de rede, estruturas de interrupção, hardware gráfico, interfaces de firmware e barramentos periféricos diferentes.

VMware, VirtualBox, Hyper-V e os hipervisores x86 convencionais virtualizam hardware compatível com x86. Normalmente, eles não traduzem instruções do processador Alpha em instruções x86.

Portanto, colocar uma imagem de disco do OpenVMS Alpha dentro de uma máquina virtual x86 comum não torna essa imagem inicializável.

A máquina virtual pode fornecer um disco virtual, um adaptador de rede virtual e um dispositivo gráfico virtual. O OpenVMS Alpha ainda espera um processador Alpha e dispositivos compatíveis da era Alpha.

Por isso, dois conceitos precisam permanecer separados:

A virtualização normalmente apresenta hardware virtual usando a mesma arquitetura de processador do hospedeiro.

A emulação entre arquiteturas reproduz outro processador e ambiente de hardware por meio de software.

O OpenVMS Alpha exige a segunda abordagem quando os binários Alpha originais e o sistema operacional precisam permanecer inalterados.

Portanto, a clonagem de disco é viável em três situações limitadas.

A primeira é a recuperação no mesmo modelo de AlphaStation, com armazenamento e periféricos compatíveis.

A segunda é a recuperação em outro sistema Alpha compatível após a conclusão das alterações necessárias nos dispositivos e na configuração.

A terceira é a restauração em um emulador Alpha que reproduza um ambiente AlphaServer ou AlphaStation compatível.

A clonagem, por si só, não resolve o problema de arquitetura. O ambiente de destino ainda precisa entender e executar instruções de máquina Alpha.

A emulação Alpha preserva a maior parte do investimento existente

A emulação Alpha normalmente é o caminho menos disruptivo quando o software Symphony existente precisa continuar operacional sem alterações no código-fonte.

Um emulador Alpha é executado em hardware x86 moderno, mas apresenta um sistema Alpha virtual ao OpenVMS. O sistema operacional e as aplicações originais continuam vendo um ambiente de hardware compatível com Alpha.

Produtos como o CHARON-AXP são projetados para essa finalidade. O emulador substitui o processador Alpha físico, a arquitetura de memória, os controladores de armazenamento, os adaptadores Ethernet e outros dispositivos compatíveis por equivalentes definidos por software.

O servidor x86 executa Windows ou Linux como ambiente hospedeiro. O emulador Alpha é executado sobre esse ambiente. O OpenVMS Alpha então é executado dentro do sistema Alpha emulado.

Essa abordagem é diferente de portar o OpenVMS para x86.

A instalação original do OpenVMS Alpha continua sendo uma instalação Alpha. Os binários do Bailey Symphony continuam sendo binários Alpha. O emulador traduz ou reproduz o comportamento necessário do hardware Alpha.

Isso pode preservar:

• O sistema operacional OpenVMS Alpha instalado.

• Aplicações Bailey Symphony existentes.

• Gráficos do operador e bancos de dados de exibição.

• Configurações de alarmes e arquivos históricos.

• Contas de usuário e procedimentos de comando.

• Utilitários existentes específicos do local.

• Interfaces de aplicativos que dependem do ambiente Alpha.

• Fluxos de trabalho dos operadores que, de outra forma, exigiriam treinamento novamente.

A migração prática geralmente envolve criar uma imagem ou backup verificado dos discos Alpha originais. Esses dados são restaurados em contêineres de disco virtual usados pelo emulador.

A configuração do emulador deve reproduzir características adequadas de CPU, memória, disco, rede e periféricos. A equipe também poderá precisar mapear portas seriais físicas ou interfaces de rede por meio do sistema host.

A emulação de Alpha pode reduzir substancialmente a dependência de hardware físico obsoleto. Ela também pode simplificar o backup, pois os arquivos de disco virtual podem ser copiados usando uma infraestrutura de armazenamento moderna.

No entanto, o termo “zero mudança” deve ser usado com cautela.

O código do aplicativo pode permanecer inalterado, mas o ambiente ainda exige engenharia. Os mapeamentos de dispositivos devem ser verificados. As interfaces de rede devem ser configuradas. As licenças do OpenVMS e do aplicativo devem ser revisadas.

O emulador também deve ser testado com a interface de comunicação Bailey usada no local.

Um aplicativo genérico do OpenVMS pode operar corretamente, enquanto uma interface DCS especializada falha por depender de um adaptador de rede, uma interface de barramento, um dispositivo serial ou um comportamento de temporização específico.

Portanto, a configuração exata da AlphaStation 255 deve ser inventariada antes da seleção de um perfil de emulador.

A interface de comunicação Bailey é o teste crítico da emulação

A questão mais importante sobre a emulação não é saber se o OpenVMS chega ao prompt de login.

A questão importante é saber se a estação emulada se comunica corretamente com o sistema Bailey INFI 90 em condições operacionais completas.

A interface pode depender de Ethernet, comunicação serial, uma interface de rede Bailey ou hardware de comunicação especializado. As configurações do local podem variar significativamente.

Antes de optar pela emulação de Alpha, os engenheiros devem documentar:

• A interface de rede física instalada em cada AlphaStation.

• O protocolo de comunicação usado entre o Symphony e o INFI 90.

• Nomes de dispositivos atribuídos no OpenVMS.

• Endereços de rede e definições de nós.

• Serviços DECnet, TCP/IP, LAT ou proprietários necessários.

• Configurações de portas seriais, quando aplicável.

• Quaisquer chaves de licença externas ou dongles de hardware.

• Comportamento de redundância e failover entre estações de operação.

• Requisitos de sincronização de horário.

• Funções gráficas e de teclado usadas pelos operadores.

Um fornecedor de emuladores pode oferecer suporte a dispositivos Ethernet e de armazenamento Alpha comuns. Isso não confirma automaticamente o suporte a todas as interfaces proprietárias Bailey.

Se a HMI existente depender de um adaptador físico especializado que não possa ser virtualizado, a abordagem de emulação poderá exigir um gateway de comunicação alternativo.

Portanto, o projeto deve incluir um teste de bancada usando uma estação clonada e acesso a uma rede Bailey representativa.

O teste deve incluir mais do que a leitura estática de tags. Os operadores devem verificar valores em tempo real, comandos, alarmes, reconhecimento, tendências, navegação pelas telas, impressão, tratamento de eventos e recuperação das estações.

O desempenho também deve ser testado durante rajadas de alarmes e atividades intensas de atualização de tags.

O OpenVMS x86-64 é uma rota de migração diferente

O OpenVMS moderno está disponível para a arquitetura x86-64. Ele pode operar em ambientes virtualizados compatíveis em servidores modernos.

Isso cria uma opção de migração adicional que não estava disponível durante muitas discussões anteriores sobre a modernização do INFI 90.

No entanto, o OpenVMS x86-64 não executa diretamente binários do OpenVMS Alpha como se fossem aplicações x86 nativas.

O ambiente da aplicação precisa ser migrado.

Pode ser necessário transferir, revisar, recompilar, vincular e testar o código-fonte para x86-64. Bibliotecas de terceiros e produtos em camadas também precisam estar disponíveis para a versão de destino.

A questão central é saber se o software Bailey Symphony instalado possui uma versão do OpenVMS compatível com x86.

Se o fornecedor do software nunca lançou essa aplicação para OpenVMS x86-64, mover apenas o sistema operacional não preserva a IHM.

Programas desenvolvidos no local podem ser portáveis quando o código-fonte e o ambiente de compilação continuam disponíveis. Aplicações comerciais fechadas normalmente não podem ser recompiladas sem o suporte do fornecedor.

Essa rota ainda pode ser prática para servidores de dados personalizados, historiadores, utilitários, relatórios e aplicações de integração que funcionem junto à IHM do Symphony.

É menos provável que preserve um ambiente de operação proprietário antigo do Symphony sem uma versão da aplicação com suporte.

Uma avaliação de migração para OpenVMS x86 deve identificar:

• Cada executável instalado e produto em camadas.

• Código-fonte disponível e procedimentos de compilação.

• Dependências de compiladores e runtimes.

• Produtos de banco de dados e formatos de arquivo.

• Bibliotecas de comunicação proprietárias.

• Dependências de gráficos ou de sistemas de janelas.

• Disponibilidade de licenças para x86-64.

• Alterações necessárias causadas pelas diferenças de arquitetura.

• Suposições de desempenho e temporização.

Essa rota tem um potencial de longo prazo maior do que migrar do Alpha para outra arquitetura de hardware descontinuada. Ela pode colocar cargas de trabalho OpenVMS compatíveis em uma infraestrutura de virtualização x86 com suporte.

Ainda assim, isso deve ser descrito como um projeto de migração de aplicações, não como um projeto de clonagem de discos.

Por que uma migração de Itanium geralmente é uma opção de transição

O OpenVMS também foi lançado para servidores HPE Integrity que utilizavam a arquitetura Itanium.

Existem ferramentas de migração e métodos de engenharia para transferir algumas aplicações Alpha para o OpenVMS Integrity. Isso já ofereceu um caminho com suporte para abandonar o hardware Alpha antigo.

Hoje, no entanto, o hardware Itanium em si é uma plataforma legada.

Uma migração de Alpha para Integrity pode eliminar uma dependência de hardware obsoleta e criar outra. Servidores, peças, interfaces de armazenamento e conhecimentos especializados adequados continuarão a se tornar menos disponíveis.

O Itanium ainda pode ser relevante quando uma instalação já possui infraestrutura Integrity compatível. Ele também pode ser relevante quando existe um produto em camadas necessário para Integrity, mas não para x86-64.

Para um novo projeto de modernização, ela geralmente deve ser avaliada como uma alternativa intermediária de compatibilidade.

O caso de negócio deve explicar por que a migração para Integrity é preferível à emulação de Alpha, à migração do OpenVMS para x86 ou à reestruturação da plataforma HMI.

A reestruturação da plataforma para OPC preserva a camada de controle

A reestruturação da plataforma para OPC substitui a camada de interface do operador, mantendo os controladores INFI 90 e a E/S de campo existentes.

Um servidor de comunicação se conecta ao sistema Bailey e disponibiliza as tags de processo para uma plataforma moderna de HMI ou SCADA.

A nova HMI gerencia telas, alarmes, tendências, segurança, comandos do operador, relatórios e serviços das estações de trabalho.

Essa abordagem elimina a dependência do aplicativo de operação Symphony original. Ela também evita a necessidade de executar o OpenVMS Alpha nas novas estações de operação.

A arquitetura normalmente inclui:

• Controladores e E/S Bailey INFI 90 existentes.

• Uma interface de comunicação Bailey compatível.

• Um servidor de dados OPC DA, OPC UA ou específico do fornecedor.

• Uma plataforma moderna de HMI ou SCADA.

• Estações de trabalho de operação e engenharia.

• Serviços opcionais de historiador, geração de relatórios e análise de alarmes.

Um exemplo de campo mencionado no material de origem utilizou um servidor OPC RoviSys com o GE CIMPLICITY. O sistema relatado operou com sucesso, mas o projeto exigiu a reconstrução das telas de operação e da lógica de animação.

Este exemplo não deve ser interpretado como uma recomendação automática de produto para toda instalação INFI 90.

O servidor selecionado deve ser compatível com a rede Bailey específica, os módulos de comunicação, a geração dos controladores, a quantidade de tags, a taxa de atualização, os requisitos de redundância e as funções de comando da instalação.

O mesmo se aplica à plataforma HMI.

O GE CIMPLICITY é uma possível plataforma corporativa de HMI/SCADA. Outros sistemas também podem ser viáveis quando fornecem a conectividade OPC, os gráficos, os alarmes, os scripts, a redundância, a segurança e o suporte ao ciclo de vida necessários.

Figura 2. Uma migração baseada em OPC preserva a camada de controle INFI 90 e substitui o ambiente de operação Symphony legado.

A conectividade OPC não converte telas existentes

Um servidor OPC fornece conectividade de dados. Normalmente, ele não converte telas HMI antigas para um novo formato de HMI.

As telas originais do Symphony podem conter gráficos estáticos, símbolos dinâmicos, alterações de cor, valores numéricos, gráficos de barras, indicadores de alarme, botões de navegação, controles de comando, tendências e modelos de funções personalizadas.

Esses elementos devem ser recriados na IHM de destino.

Telas simples podem ser redesenhadas diretamente. Telas complexas podem conter scripts ou expressões ocultos que não são imediatamente visíveis.

Os engenheiros devem entender como cada objeto animado obtém e processa seus dados.

Um símbolo de válvula pode não seguir simplesmente uma única tag de saída. Sua cor e posição podem depender do retorno de abertura, do retorno de fechamento, do estado do comando, do status do intertravamento, da qualidade da comunicação e do modo do equipamento.

Um símbolo de motor pode usar tags separadas para o comando de partida, o retorno de funcionamento, o status de parado, o desarme, o controle local, o estado de manutenção, as permissivas e a inibição de alarmes.

Assim, mover apenas os gráficos visíveis pode criar uma IHM que parece correta, mas se comporta de forma incorreta.

A equipe de migração deve documentar o significado funcional por trás de cada elemento da tela.

Este trabalho inclui:

• Mapear cada objeto dinâmico à sua fonte de dados.

• Recriar expressões de animação.

• Verificar a confirmação de comandos e a segurança.

• Recriar a navegação e as hierarquias de telas.

• Recriar classes e prioridades de alarmes.

• Confirmar unidades de engenharia e precisão decimal.

• Recriar tendências históricas e em tempo real.

• Testar estados de comunicação inválidos, incertos e com falha.

• Reproduzir mensagens e orientações ao operador.

• Substituir fontes e símbolos sem suporte.

Portanto, o esforço é determinado pela complexidade das telas, não apenas pela quantidade de telas.

Uma IHM moderna não deve copiar cegamente todas as telas legadas

A recriação manual oferece uma oportunidade de aprimorar a interface do operador.

Os gráficos de IHM legados frequentemente usam cores brilhantes para equipamentos em condições normais, diagramas de processo densos, tubulações decorativas e indicações de alarme inconsistentes.

Essas convenções podem ter sido razoáveis quando o sistema original foi desenvolvido. Elas nem sempre são ideais para as práticas atuais de salas de controle.

Um projeto de modernização deve analisar:

• Hierarquia das telas.

• Visibilidade dos alarmes.

• Consistência da navegação.

• Apresentação do estado dos equipamentos.

• Uso de cores.

• Acessibilidade das tendências.

• Requisitos de resposta do operador.

• Resolução da tela e layout da estação de trabalho.

• Acessibilidade e legibilidade.

As condições normais de operação devem permanecer visualmente discretas. Cores fortes devem identificar estados anormais que exigem atenção.

Os operadores devem conseguir passar da visão geral da planta para a unidade afetada, o faceplate do equipamento, a tendência, o histórico de alarmes e a tela de diagnóstico sem navegação excessiva.

No entanto, um redesenho excessivo pode criar outro risco.

Os operadores podem ter usado as telas originais por muitos anos. Alterar todos os símbolos, cores e caminhos de navegação durante o mesmo projeto pode aumentar as necessidades de treinamento e o risco da transição.

Uma abordagem equilibrada mantém as relações de processo conhecidas, ao mesmo tempo que aprimora a apresentação e a navegação dos alarmes.

A extração de tags deve ser tratada como um pacote de trabalho de engenharia

O material de origem levanta a possibilidade de exportar os dados de tags do Bailey para CSV. Ele não fornece um procedimento universal confirmado.

Portanto, não se deve presumir que um único comando de exportação produzirá um banco de dados completo e limpo para a IHM.

As possíveis fontes de informações de tags incluem:

• Bancos de dados de configuração do Symphony.

• Definições de telas existentes.

• Configurações do controlador e registros de engenharia.

• Bancos de dados do servidor de comunicação Bailey.

• Funções de navegação do servidor OPC.

• Arquivos de configuração de alarmes.

• Bancos de dados históricos.

• Listas de tags impressas ou arquivadas.

• Planilhas de engenharia da unidade.

A navegação OPC pode fornecer um ponto de partida prático depois que o servidor estabelecer a comunicação com o sistema Bailey.

Ele pode expor nomes de tags, identificadores de itens, descrições, qualidade e valores atuais. Alguns servidores também permitem exportar o namespace navegado.

No entanto, um namespace OPC pode não incluir todos os campos necessários para a nova IHM.

As prioridades dos alarmes, os limites de engenharia, os agrupamentos de telas, as observações do operador, a segurança dos comandos e as relações entre equipamentos podem estar armazenados em outro local.

Alguns servidores OPC expõem tags usando nomes gerados que diferem dos nomes originais do Symphony.

O projeto deve criar um cadastro mestre controlado de tags contendo, no mínimo:

• Nome original da tag.

• Nome da tag da nova IHM.

• Identificador do item OPC.

• Descrição.

• Tipo de dados.

• Permissão de leitura ou gravação.

• Unidades de engenharia.

• Informações de escalonamento.

• Limites e prioridade dos alarmes.

• Taxa de atualização.

• Tela associada.

• Status da validação.

• Resultado do teste.

Este cadastro mestre se torna o registro de reconciliação entre os sistemas legado e novo.

A quantidade de tags não é o único requisito de comunicação

Um teste de navegação bem-sucedido não comprova que a arquitetura OPC pode comportar a IHM completa.

Os engenheiros devem avaliar a quantidade de tags ativas, a taxa de atualização solicitada, a frequência de alterações, a atividade de alarmes, o tráfego de comandos e a redundância do servidor.

Um sistema pode conter dezenas de milhares de tags configuradas. Apenas uma parte delas pode estar ativa nas telas do operador em determinado momento.

O servidor e a IHM devem ser testados em condições realistas.

As verificações de desempenho importantes incluem:

• Tempo necessário para abrir uma tela complexa.

• Atraso entre uma alteração em campo e a animação na IHM.

• Entrega de alarmes durante picos de eventos.

• Coleta de tendências na taxa de amostragem necessária.

• Tempo de execução do comando e de recebimento do retorno.

• Recuperação após uma interrupção de rede.

• Failover entre servidores redundantes.

• Comportamento após a reinicialização do controlador.

• Status de qualidade durante uma falha de comunicação.

• Carga de CPU, memória e rede.

Os comandos exigem atenção especial.

Ler valores por OPC pode ser relativamente simples. Gravar valores com segurança exige controle de acesso, validação de comandos, confirmação do retorno e tratamento correto de falhas de comunicação.

A equipe deve testar todos os tipos de comando do operador, não apenas uma tag representativa.

O ABB Symphony Plus oferece um caminho de evolução mais amplo

A substituição do OPC não é a única opção para um sistema Bailey instalado.

A ABB continua posicionando o Symphony Plus como uma plataforma de evolução para instalações Bailey, INFI 90, Harmony Rack e Symphony mais antigas.

Uma modernização da ABB em fases pode preservar partes da arquitetura instalada de controle e E/S enquanto introduz componentes mais novos de operação, engenharia, rede, controle ou E/S.

Essa opção pode ser atraente quando a organização deseja uma estratégia de ciclo de vida com suporte do fornecedor, em vez de uma substituição independente da HMI.

O projeto pode modernizar primeiro o ambiente do operador. Os controladores e a E/S podem permanecer em serviço até que seu ciclo de vida ou valor operacional justifique a substituição.

As fases posteriores podem abordar comunicações, controladores, ferramentas de engenharia e interfaces de campo.

A arquitetura exata da migração depende da geração do sistema instalado.

As instalações Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony e Symphony Plus não utilizam todas as mesmas interfaces.

Os nomes dos módulos e a terminologia de rede devem ser verificados nos desenhos da instalação e nos inventários de hardware.

As organizações que mantêm a camada de controle existente também podem consultar os componentes ABB Bailey INFI 90 e Network 90 disponíveis ao planejar a cobertura de sobressalentes, o suporte ao ciclo de vida e a modernização em fases.

Este link interno é relevante porque projetos de modernização frequentemente exigem que o sistema antigo permaneça operacional durante a engenharia, os testes e a migração gradual.

Manter controladores sobressalentes adequados, módulos de comunicação, fontes de alimentação e módulos de E/S pode reduzir os riscos durante essa transição.

Uma HMI personalizada ou de código aberto é possível, mas exige responsabilidade de manutenção

Uma HMI personalizada pode ser desenvolvida usando frameworks de software de código aberto ou comerciais.

O material de origem menciona um servidor residente em VMS com um cliente moderno baseado em Qt. Arquiteturas desse tipo podem separar a conexão de dados no servidor do cliente do operador.

Essa opção pode oferecer flexibilidade e evitar a dependência de um único fornecedor de HMI.

Isso também pode se tornar um compromisso de desenvolvimento de software de longo prazo.

A organização deve possuir ou manter:

• O servidor de comunicação.

• Banco de dados de tags.

• Aplicativo cliente.

• Framework gráfico.

• Processamento de alarmes.

• Integração com historiador.

• Autenticação de usuários.

• Atualizações de cibersegurança.

• Implantação e controle de versões.

• Documentação e treinamento.

Qt, Python, C++, tecnologias web ou outros frameworks podem produzir interfaces industriais capazes. A dificuldade não está em desenhar um gráfico de processo.

A dificuldade está em criar um sistema de operação confiável que funcione corretamente durante falhas de comunicação, reinicializações de servidores, avalanches de alarmes, alterações de usuários e condições anormais da planta.

Uma plataforma personalizada só deve ser selecionada quando a organização tiver uma equipe de engenharia sustentável ou um integrador confiável de longo prazo.

O licenciamento pode determinar se uma rota técnica é viável

Os softwares industriais legados frequentemente usam mecanismos de licenciamento vinculados a identificadores de hardware, endereços Ethernet, bancos de dados de licenças, dongles ou chaves de autorização emitidas pelo fornecedor.

Um sistema clonado pode inicializar corretamente, mas se recusar a iniciar o aplicativo Symphony porque a identidade do hardware virtual foi alterada.

O inventário da migração deve incluir:

• Licenças do sistema operacional OpenVMS.

• Licenças de aplicativos Bailey Symphony.

• Licenças de banco de dados.

• Licenças de rede e comunicação.

• Licenças de emulador.

• Licenças de contagem de pontos HMI e OPC.

• Licenças de historiador.

• Opções de redundância.

• Licenças de cliente de engenharia.

• Licenças de cliente de runtime.

Deve-se obter uma confirmação por escrito antes de escolher a plataforma final.

A compatibilidade técnica sem disponibilidade legal das licenças não cria uma solução implantável.

A cibersegurança deve ser incorporada ao projeto da substituição

Os sistemas AlphaStation antigos eram frequentemente instalados antes que as práticas modernas de cibersegurança industrial se tornassem padrão.

Eles podem operar em redes isoladas com acesso remoto limitado. Substituí-los por servidores Windows, clientes SCADA modernos, servidores OPC e infraestrutura Ethernet altera a superfície de ataque.

A nova arquitetura deve definir zonas de rede separadas para controle, servidores, engenharia e empresa.

Os firewalls devem permitir somente os caminhos de comunicação necessários. O acesso remoto deve usar autenticação gerenciada e registro.

As contas dos operadores devem seguir permissões baseadas em funções. As funções de engenharia não devem estar disponíveis em todos os clientes HMI.

O acesso de escrita do OPC deve ser restrito às tags e estações que necessitam dele.

O projeto também deve abordar:

• Aplicação de patches do sistema operacional.

• Antivírus ou controle de aplicativos.

• Backup e recuperação.

• Sincronização de horário.

• Registro de eventos de segurança.

• Controles de mídias removíveis.

• Suporte remoto do fornecedor.

• Gerenciamento de certificados para OPC UA.

• Gerenciamento do ciclo de vida das contas.

Os controles de cibersegurança não devem impedir que os operadores respondam durante eventos na planta. O projeto deve equilibrar proteção, disponibilidade e operação determinística.

A migração deve começar com um inventário baseado em evidências

Antes de selecionar uma rota, os engenheiros devem documentar detalhadamente o sistema existente.

O inventário deve incluir as quatro AlphaStations e identificar se suas configurações são realmente idênticas.

Registro:

• Modelo da AlphaStation e configuração do processador.

• Capacidade de memória.

• Tipo de disco e volumes lógicos.

• Versão e nível de patch do OpenVMS.

• Versões do software Bailey instalado.

• Produtos em camadas e bancos de dados.

• Hardware gráfico e resolução da tela.

• Adaptadores de rede.

• Interfaces seriais.

• Hardware de comunicação Bailey.

• Nomes e endereços dos nós.

• Procedimentos de comandos de inicialização.

• Arquivos de licença.

• Procedimentos de backup.

• Redundância da estação do operador.

• Impressoras conectadas e dispositivos externos.

• Retenção de dados históricos e de alarmes.

A equipe também deve coletar capturas de tela de todas as telas. Estados dinâmicos devem ser capturados quando possível.

Registre os estados normal, parado, em operação, em alarme, inibido, local, manual, automático e com falha de comunicação.

Essa evidência é essencial quando as novas telas são testadas.

Um sistema de bancada é obrigatório

Nenhuma rota de modernização deve ser testada pela primeira vez no sistema de produção em operação.

Um ambiente de bancada deve reproduzir uma parte suficiente da arquitetura instalada para validar a comunicação e as funções do operador.

Para um projeto de emulador, a bancada deve conter um ambiente OpenVMS Alpha clonado e a configuração de emulador proposta.

Para um projeto OPC, ele deve incluir o servidor de comunicação selecionado, o software de IHM, gráficos representativos e acesso a um nó de teste Bailey seguro ou a uma fonte de dados simulada.

O teste de bancada deve verificar:

• Inicialização do sistema e do aplicativo.

• Comunicação com o sistema Bailey.

• Contagem total de tags acessíveis.

• Operações de leitura e gravação.

• Escalonamento das tags e unidades de engenharia.

• Geração e reconhecimento de alarmes.

• Coleta de tendências.

• Animação das telas.

• Segurança dos comandos.

• Funções de impressão e relatórios.

• Comportamento após a reinicialização do servidor.

• Comportamento em caso de falha de rede.

• Redundância e failover.

• Restauração de backups.

• Tempo de resposta do operador.

Os resultados dos testes devem ser acompanhados pelas equipes de operação, engenharia de controle, manutenção e representantes de cibersegurança.

A operação em paralelo reduz o risco da mudança

As AlphaStations originais devem permanecer disponíveis durante a implantação inicial do sistema substituto.

A nova IHM pode operar em paralelo enquanto os engenheiros comparam valores, alarmes, tendências e comandos.

A operação em paralelo permite identificar incompatibilidades antes que a estação legada seja removida.

A equipe deve reconciliar:

• Valores de processo exibidos.

• Indicações de status.

• Prioridades dos alarmes.

• Marcas de tempo dos alarmes.

• Resultados dos comandos.

• Valores das tendências.

• Modo do equipamento.

• Qualidade da comunicação.

• Permissões de segurança.

Nem toda diferença representa um erro. O novo sistema pode usar uma escala ou uma apresentação de alarmes aprimorada.

Toda diferença ainda deve ser explicada e aprovada.

As estações legadas devem permanecer recuperáveis até que a nova IHM seja aprovada em um teste de aceitação no local, acompanhado pelas partes envolvidas, e durante um período operacional acordado.

Escolhendo o caminho de migração correto

Escolha a emulação de Alpha quando:

O aplicativo Symphony existente deve permanecer inalterado. O código-fonte não está disponível. Os gráficos do operador são complexos. O retreinamento deve ser minimizado. A interface de comunicação Bailey pode ser compatível com a arquitetura do emulador.

Escolha a migração do OpenVMS para x86 quando:

Os aplicativos necessários estão disponíveis para x86-64 ou podem ser recompilados. O código-fonte e o conhecimento de engenharia continuam disponíveis. A organização deseja manter o OpenVMS enquanto migra para um ambiente x86 compatível.

Escolha a reimplementação em uma nova plataforma via OPC quando:

O controlador INFI 90 e as camadas de E/S continuarem confiáveis. A organização quiser uma plataforma de HMI moderna. Houver recursos de engenharia disponíveis para reconstruir e validar telas, alarmes, tags e lógica de comandos.

Escolha uma rota de evolução da ABB quando:

A organização quiser um programa de modernização mais amplo, com suporte do fornecedor. As fases futuras podem incluir sistemas de operação, ferramentas de engenharia, interfaces de rede, controladores e E/S.

Escolha uma HMI personalizada quando:

A organização tiver requisitos especializados e puder dar suporte ao desenvolvimento de software, aos testes, à cibersegurança e à manutenção do ciclo de vida no longo prazo.

Mantenha o sistema existente temporariamente quando:

As interfaces de migração continuam indefinidas. Os backups estão incompletos. O licenciamento não foi resolvido. Os bancos de dados de tags não estão disponíveis. Os testes de bancada ainda não conseguem reproduzir o caminho de comunicação da Bailey.

Um plano prático de modernização em fases

Fase 1: Preserve o ambiente existente.

Crie backups de imagem verificados de cada AlphaStation. Registre os detalhes de hardware, software, rede, licenciamento e inicialização. Teste a restauração sempre que possível.

Fase 2: Identifique a arquitetura de comunicação.

Documente exatamente como cada estação Symphony se comunica com o INFI 90. Confirme se a interface pode ser emulada ou substituída por um servidor compatível.

Fase 3: Desenvolva uma prova de conceito.

Teste uma estação clonada em um emulador de Alpha ou conecte um servidor OPC a um nó Bailey representativo.

Fase 4: Crie o cadastro mestre de tags.

Concilie as tags dos controladores, os identificadores de itens OPC, as unidades de engenharia, os comandos, os alarmes e o uso das telas.

Fase 5: Reconstrua telas representativas.

Selecione várias telas que contenham diferentes requisitos de animação, alarmes, comandos e tendências.

Fase 6: Conclua a aceitação em bancada.

Teste o carregamento completo das tags, falhas de comunicação, reinicialização do servidor, picos de alarmes, comportamento dos comandos e restauração de backups.

Fase 7: Implante em paralelo.

Opere as HMIs nova e antiga simultaneamente. Compare os valores e as respostas dos operadores.

Fase 8: Realize a transição acompanhada.

Use um procedimento de teste aprovado. Mantenha as AlphaStations disponíveis como alternativa.

Fase 9: Retire o hardware legado gradualmente.

Não destrua as imagens originais, os registros de configuração, as licenças ou o hardware até que a aceitação de longo prazo seja concluída.

Perguntas frequentes

Um disco de uma AlphaStation com OpenVMS pode ser clonado diretamente para um PC moderno?

Não. A imagem contém código de máquina Alpha e espera um hardware compatível com Alpha. Um PC x86 moderno não pode inicializá-la diretamente. A imagem deve ser restaurada em hardware Alpha compatível ou em um emulador de Alpha.

O VMware ou o VirtualBox podem executar o OpenVMS?

Elas podem executar versões compatíveis do OpenVMS x86-64. Elas não convertem uma instalação antiga do OpenVMS Alpha em um aplicativo x86. O OpenVMS Alpha requer emulação de Alpha.

As telas originais do Symphony podem ser preservadas?

Elas geralmente podem ser preservadas quando o ambiente Alpha completo é executado em um emulador compatível. Normalmente, exigem recriação manual ao migrar para outra plataforma de IHM.

Um servidor OPC exporta automaticamente todas as tags Bailey?

Não necessariamente. A navegação OPC pode fornecer um namespace útil, mas a configuração de alarmes, as relações entre telas, os comandos, as descrições e os metadados de engenharia podem exigir extração e reconciliação adicionais.

O GE CIMPLICITY é a única IHM substituta?

Não. Essa é uma plataforma possível e aparece no exemplo de campo fornecido com a fonte. A seleção final deve depender do suporte à comunicação, da redundância, do licenciamento, da cibersegurança, dos recursos de engenharia e dos requisitos dos operadores.

Ainda vale a pena migrar de Alpha para Itanium?

Isso pode ser justificável quando o software necessário está disponível apenas para sistemas Integrity ou quando a infraestrutura Integrity existente já tem suporte. Em geral, é um caminho de transição, e não a estratégia de modernização de longo prazo mais sólida.

Os controladores e a E/S INFI 90 podem permanecer instalados?

Sim, quando continuam confiáveis e a arquitetura de comunicação selecionada é compatível com elas. A modernização da IHM pode ser concluída separadamente da substituição dos controladores e da E/S.

As AlphaStations antigas devem ser removidas imediatamente após a mudança?

Não. Elas devem continuar disponíveis como uma alternativa de contingência testada até que o novo ambiente do operador seja aprovado nos testes funcionais, de desempenho e de aceitação operacional.

A solução correta depende do que precisa ser preservado

O principal erro técnico em muitos planos de modernização de IHM legados é tratar a estação do operador como um PC comum.

Uma AlphaStation executando OpenVMS Alpha e Bailey Symphony é um ambiente completo de hardware e software. Sua arquitetura de processador, sistema operacional, interfaces de comunicação, binários de aplicativos, licenças, gráficos e conexões com o sistema de controle são interdependentes.

Um clone do disco preserva os dados. Ele não traduz esse ambiente para outra arquitetura.

A emulação de Alpha oferece o caminho mais direto quando toda a instalação Symphony precisa continuar funcionando sem alterações.

O OpenVMS x86-64 oferece um caminho de sistema operacional moderno quando os aplicativos podem ser migrados ou recompilados.

A reformulação da plataforma OPC oferece um caminho prático quando a camada de controle INFI 90 continua valiosa, mas a camada do operador deve ser substituída.

A evolução do ABB Symphony Plus pode oferecer uma estratégia escalonada mais ampla quando a organização deseja modernizar além da IHM.

A decisão final deve seguir um inventário verificado, um estudo das interfaces de comunicação, uma análise de licenças, uma prova de conceito, um teste de bancada e uma aceitação operacional acompanhada.

Não existe uma migração sem esforço. No entanto, há vários caminhos de migração controlados que podem proteger o investimento existente em controle de processos e, ao mesmo tempo, eliminar a dependência de hardware AlphaStation obsoleto.