Modernizzare un’HMI senza sostituire l’intero sistema INFI 90

Molti sistemi Bailey INFI 90 continuano a funzionare in modo affidabile per decenni dopo l’installazione originale. I relativi controllori, moduli di comunicazione, unità di terminazione e I/O di campo possono ancora svolgere le funzioni di controllo richieste.

Il problema più immediato del ciclo di vita si trova spesso al di sopra del livello dei controllori.

Le stazioni operatore possono dipendere da hardware AlphaStation obsoleto, schede grafiche non più supportate, dispositivi di archiviazione obsoleti e vecchi ambienti software OpenVMS Alpha. I ricambi diventano difficili da reperire, mentre gli ingegneri esperti di OpenVMS e Bailey Symphony sono sempre meno disponibili.

L’esempio considerato qui comprende quattro workstation AlphaStation 255. Ogni stazione esegue OpenVMS Alpha e ospita le funzioni dell’interfaccia operatore Bailey Symphony per un sistema di controllo distribuito Bailey INFI 90.

L’obiettivo non è necessariamente sostituire l’intero DCS. Un obiettivo più pratico è eliminare la dipendenza dall’hardware AlphaStation obsoleto, preservando al contempo i controllori stabili, il cablaggio di campo, i moduli I/O, la logica di controllo e le operazioni di processo.

Questa distinzione modifica la strategia di modernizzazione.

Il progetto consiste principalmente nella migrazione dell’interfaccia operatore e della piattaforma informatica. Diventa una migrazione completa del DCS solo quando il ciclo di vita dei controllori, i requisiti di cybersecurity, gli obiettivi di produzione o le condizioni di assistenza rendono giustificata la sostituzione dei livelli di controllo inferiori.

Esistono diversi possibili percorsi di modernizzazione. Tuttavia, ciascuno preserva parti diverse del sistema esistente.

Un emulatore Alpha può preservare quasi l’intero ambiente software. Una migrazione a OpenVMS x86 preserva la famiglia del sistema operativo, ma richiede la migrazione delle applicazioni. Una sostituzione dell’HMI basata su OPC preserva il livello dei controllori e ricostruisce l’interfaccia operatore. Una strategia di evoluzione ABB può modernizzare per fasi l’architettura Symphony nel suo complesso.

Nessun percorso dovrebbe essere descritto come una semplice sostituzione del PC.

Figura 1. Tre principali percorsi di modernizzazione possono preservare parti diverse dell’investimento installato in Bailey INFI 90 e Symphony.

Perché clonare il disco dell’AlphaStation non è sufficiente

La clonazione del disco è utile per preservare un ambiente OpenVMS Alpha installato. Può acquisire il sistema operativo, i file delle applicazioni, la configurazione dei dispositivi, gli account utente, il software Bailey, i database, gli elementi grafici e le impostazioni specifiche del sito.

Tuttavia, la clonazione di un disco non converte il software Alpha in software x86.

Il sistema operativo clonato contiene ancora istruzioni per processori Alpha. Il kernel, il boot loader, le librerie di sistema, le applicazioni e i driver hardware sono stati realizzati per l’architettura Alpha.

Un PC moderno standard utilizza un processore x86-64. Presenta inoltre controller di archiviazione, dispositivi di rete, strutture degli interrupt, hardware grafico, interfacce firmware e bus periferici differenti.

VMware, VirtualBox, Hyper-V e gli hypervisor x86 convenzionali virtualizzano hardware compatibile con x86. Normalmente non traducono le istruzioni del processore Alpha in istruzioni x86.

Pertanto, inserire un’immagine disco di OpenVMS Alpha in una normale macchina virtuale x86 non rende avviabile tale immagine.

La macchina virtuale può fornire un disco virtuale, un adattatore di rete virtuale e un dispositivo grafico virtuale. OpenVMS Alpha si aspetta comunque un processore Alpha e dispositivi dell’era Alpha supportati.

Per questo motivo, i due concetti devono rimanere distinti:

La virtualizzazione presenta normalmente hardware virtuale che utilizza la stessa architettura del processore dell’host.

L’emulazione cross-architecture riproduce tramite software un altro processore e un altro ambiente hardware.

OpenVMS Alpha richiede il secondo approccio quando i binari Alpha originali e il sistema operativo devono rimanere invariati.

La clonazione dei dischi è quindi praticabile in tre situazioni limitate.

La prima consiste nel ripristino sullo stesso modello di AlphaStation, con dispositivi di archiviazione e periferiche compatibili.

La seconda consiste nel ripristino su un altro sistema Alpha supportato, dopo aver completato le modifiche necessarie ai dispositivi e alla configurazione.

La terza consiste nel ripristino all’interno di un emulatore Alpha che riproduca un ambiente AlphaServer o AlphaStation compatibile.

La sola clonazione non risolve il problema dell’architettura. L’ambiente di destinazione deve comunque comprendere ed eseguire le istruzioni macchina Alpha.

L’emulazione Alpha preserva la maggior parte dell’investimento esistente

L’emulazione Alpha è normalmente il percorso meno invasivo quando il software Symphony esistente deve rimanere operativo senza modifiche al codice sorgente.

Un emulatore Alpha viene eseguito su hardware x86 moderno, ma presenta a OpenVMS un sistema Alpha virtuale. Il sistema operativo e le applicazioni originali continuano a rilevare un ambiente hardware compatibile con Alpha.

Prodotti come CHARON-AXP sono progettati a questo scopo. L’emulatore sostituisce il processore Alpha fisico, l’architettura della memoria, i controller di archiviazione, gli adattatori Ethernet e gli altri dispositivi supportati con equivalenti definiti tramite software.

Il server x86 esegue Windows o Linux come ambiente host. L’emulatore Alpha viene eseguito sopra tale host. OpenVMS Alpha viene quindi eseguito all’interno del sistema Alpha emulato.

Questo approccio è diverso dal porting di OpenVMS su x86.

L’installazione originale di OpenVMS Alpha rimane un’installazione Alpha. I binari di Bailey Symphony rimangono binari Alpha. L’emulatore traduce o riproduce il comportamento hardware Alpha richiesto.

Questo può preservare:

• Il sistema operativo OpenVMS Alpha installato.

• Applicazioni Bailey Symphony esistenti.

• Grafiche dell’operatore e database delle schermate.

• Configurazioni degli allarmi e file storici.

• Account utente e procedure operative.

• Utility specifiche del sito esistenti.

• Interfacce dell’applicazione che dipendono dall’ambiente Alpha.

• Flussi di lavoro degli operatori che altrimenti richiederebbero una nuova formazione.

La migrazione pratica consiste generalmente nella creazione di un’immagine verificata o di un backup dei dischi Alpha originali. Tali dati vengono ripristinati in contenitori di dischi virtuali utilizzati dall’emulatore.

La configurazione dell’emulatore deve riprodurre caratteristiche adeguate di CPU, memoria, dischi, rete e periferiche. Il team potrebbe inoltre dover mappare le porte seriali fisiche o le interfacce di rete attraverso il sistema host.

L’emulazione Alpha può ridurre significativamente la dipendenza dall’hardware fisico obsoleto. Può anche semplificare i backup, perché i file dei dischi virtuali possono essere copiati utilizzando moderne infrastrutture di archiviazione.

Tuttavia, il termine “nessuna modifica” dovrebbe essere usato con cautela.

Il codice dell’applicazione può rimanere invariato, ma l’ambiente richiede comunque attività di progettazione. È necessario verificare le mappature dei dispositivi. Le interfacce di rete devono essere configurate. Occorre riesaminare le licenze OpenVMS e quelle dell’applicazione.

L’emulatore deve inoltre essere testato con l’interfaccia di comunicazione Bailey utilizzata nel sito.

Un’applicazione OpenVMS generica può funzionare correttamente mentre un’interfaccia DCS specializzata non funziona perché dipende da uno specifico adattatore di rete, da un’interfaccia bus, da un dispositivo seriale o da determinati comportamenti temporali.

È quindi necessario inventariare l’esatta configurazione dell’AlphaStation 255 prima di selezionare un profilo dell’emulatore.

L’interfaccia di comunicazione Bailey è il test di emulazione fondamentale

La questione più importante sull’emulazione non è se OpenVMS raggiunga la schermata di accesso.

La domanda importante è se la stazione emulata comunica correttamente con il sistema Bailey INFI 90 in condizioni operative complete.

L’interfaccia può dipendere da Ethernet, dalla comunicazione seriale, da un’interfaccia di rete Bailey o da hardware di comunicazione specializzato. Le configurazioni dei siti possono variare significativamente.

Prima di procedere con l’emulazione Alpha, gli ingegneri dovrebbero documentare:

• L’interfaccia di rete fisica installata in ciascuna AlphaStation.

• Il protocollo di comunicazione utilizzato tra Symphony e INFI 90.

• Nomi dei dispositivi assegnati in OpenVMS.

• Indirizzi di rete e definizioni dei nodi.

• Servizi DECnet, TCP/IP, LAT o proprietari richiesti.

• Impostazioni delle porte seriali, ove applicabili.

• Eventuali chiavi di licenza esterne o dongle hardware.

• Comportamento di ridondanza e failover tra le stazioni operatore.

• Requisiti di sincronizzazione dell’ora.

• Funzioni grafiche e della tastiera utilizzate dagli operatori.

Un fornitore di emulatori può supportare comuni dispositivi Ethernet e di archiviazione Alpha. Ciò non conferma automaticamente il supporto per ogni interfaccia Bailey proprietaria.

Se l’HMI esistente dipende da un adattatore fisico specializzato che non può essere virtualizzato, la soluzione con emulatore potrebbe richiedere un gateway di comunicazione alternativo.

Il progetto dovrebbe quindi includere un test al banco utilizzando una stazione clonata e l’accesso a una rete Bailey rappresentativa.

Il test deve includere più della semplice lettura statica dei tag. Gli operatori dovrebbero verificare i valori in tempo reale, i comandi, gli allarmi, il riconoscimento, i trend, la navigazione tra le schermate, la stampa, la gestione degli eventi e il ripristino delle stazioni.

Le prestazioni dovrebbero essere testate anche durante i picchi di allarmi e un’elevata attività di aggiornamento dei tag.

OpenVMS x86-64 è un percorso di migrazione diverso

OpenVMS moderno è disponibile per l’architettura x86-64. Può funzionare in ambienti virtualizzati supportati su server moderni.

Ciò introduce un’ulteriore opzione di migrazione che non era disponibile durante molte precedenti discussioni sulla modernizzazione di INFI 90.

Tuttavia, OpenVMS x86-64 non esegue direttamente i binari OpenVMS Alpha come se fossero applicazioni x86 native.

È necessario migrare l’ambiente applicativo.

Potrebbe essere necessario trasferire, esaminare, ricompilare, collegare e testare il codice sorgente per x86-64. Anche le librerie di terze parti e i prodotti stratificati devono essere disponibili per la versione di destinazione.

La domanda centrale è se il software Bailey Symphony installato disponga di una versione di OpenVMS compatibile con x86.

Se il fornitore del software non ha mai rilasciato quell’applicazione per OpenVMS x86-64, il solo spostamento del sistema operativo non preserva l’HMI.

I programmi sviluppati internamente possono essere portabili quando il codice sorgente e l’ambiente di compilazione rimangono disponibili. Normalmente, le applicazioni commerciali chiuse non possono essere ricompilate senza il supporto del fornitore.

Questo percorso può essere ancora praticabile per server dati personalizzati, storici, utilità, report e applicazioni di integrazione che operano insieme all’HMI Symphony.

È meno probabile che preservi un vecchio ambiente operatore proprietario Symphony senza una versione supportata dell’applicazione.

Una valutazione della migrazione a OpenVMS x86 dovrebbe identificare:

• Ogni eseguibile installato e ogni prodotto stratificato.

• Codice sorgente disponibile e procedure di compilazione.

• Dipendenze da compilatori e ambienti di runtime.

• Prodotti di database e formati di file.

• Librerie di comunicazione proprietarie.

• Dipendenze da sistemi grafici o a finestre.

• Disponibilità delle licenze per x86-64.

• Modifiche necessarie dovute alle differenze architetturali.

• Presupposti relativi a prestazioni e temporizzazione.

Questo percorso ha un potenziale a lungo termine maggiore rispetto al passaggio da Alpha a un’altra architettura hardware dismessa. Può consentire di eseguire carichi di lavoro OpenVMS compatibili su un’infrastruttura di virtualizzazione x86 supportata.

Tuttavia, dovrebbe essere descritta come un progetto di migrazione delle applicazioni, non come un progetto di clonazione dei dischi.

Perché una migrazione a Itanium è solitamente un’opzione transitoria

OpenVMS è stato inoltre rilasciato per i server HPE Integrity basati sull’architettura Itanium.

Esistono strumenti di migrazione e metodi ingegneristici per trasferire alcune applicazioni Alpha a OpenVMS Integrity. In passato, ciò offriva un percorso supportato per abbandonare l’hardware Alpha obsoleto.

Oggi, tuttavia, anche l’hardware Itanium è una piattaforma legacy.

Il passaggio da Alpha a Integrity può eliminare una dipendenza hardware obsoleta, creandone al contempo un’altra. La disponibilità di server, componenti, interfacce di storage e competenze specialistiche continuerà a diminuire.

Itanium può essere ancora rilevante quando un sito dispone già di un’infrastruttura Integrity supportata. Può inoltre essere rilevante quando esiste un prodotto integrato richiesto per Integrity ma non per x86-64.

Per un nuovo progetto di modernizzazione, dovrebbe generalmente essere valutato come un percorso intermedio di compatibilità.

Il business case deve spiegare perché il passaggio a Integrity sia preferibile all’emulazione Alpha, alla migrazione di OpenVMS x86 o alla ripiattaformazione HMI.

La ripiattaformazione OPC preserva il livello di controllo

La ripiattaformazione OPC sostituisce il livello di interfaccia operatore mantenendo i controller INFI 90 esistenti e l’I/O di campo.

Un server di comunicazione si connette al sistema Bailey ed espone i tag di processo a una moderna piattaforma HMI o SCADA.

La nuova HMI gestisce display, allarmi, trend, sicurezza, comandi operatore, report e servizi delle workstation.

Questo approccio elimina la dipendenza dall’applicazione operatore Symphony originale. Evita inoltre la necessità di eseguire OpenVMS Alpha sulle nuove stazioni operatore.

L’architettura include normalmente:

• Controller e I/O Bailey INFI 90 esistenti.

• Un’interfaccia di comunicazione Bailey compatibile.

• Un server dati OPC DA, OPC UA o specifico del fornitore.

• Una moderna piattaforma HMI o SCADA.

• Workstation operatore e di engineering.

• Servizi opzionali di storicizzazione, reporting e analisi degli allarmi.

Un esempio sul campo citato nel materiale di origine utilizzava un server OPC RoviSys con GE CIMPLICITY. Il sistema segnalato funzionava correttamente, ma il progetto richiedeva la ricostruzione dei display operatore e della logica di animazione.

Questo esempio non deve essere interpretato come una raccomandazione automatica di prodotto per ogni installazione INFI 90.

Il server selezionato deve supportare la rete Bailey specifica, i moduli di comunicazione, la generazione dei controller, il numero di tag, la frequenza di aggiornamento, i requisiti di ridondanza e le funzioni di comando presenti nel sito.

Lo stesso vale per la piattaforma HMI.

GE CIMPLICITY è una possibile piattaforma HMI/SCADA aziendale. Anche altri sistemi possono essere idonei se forniscono la connettività OPC, la gestione di grafiche, allarmi, scripting, ridondanza e sicurezza richieste, oltre al supporto per l’intero ciclo di vita.

Figura 2. Una migrazione basata su OPC preserva il livello di controllo INFI 90 sostituendo al contempo l’ambiente operatore Symphony legacy.

La connettività OPC non converte le schermate esistenti

Un server OPC fornisce la connettività dei dati. Normalmente non converte i display HMI obsoleti in un nuovo formato HMI.

Le schermate Symphony originali possono contenere grafiche statiche, simboli dinamici, variazioni di colore, valori numerici, grafici a barre, indicatori di allarme, pulsanti di navigazione, controlli dei comandi, trend e modelli di funzioni personalizzati.

Questi elementi devono essere ricreati nell’HMI di destinazione.

I display semplici possono essere ridisegnati direttamente. I display complessi possono contenere script o espressioni nascoste che non sono immediatamente visibili.

Gli ingegneri devono comprendere come ogni oggetto animato ottiene ed elabora i propri dati.

Un simbolo di valvola potrebbe non seguire semplicemente un singolo tag di uscita. Il suo colore e la sua posizione possono dipendere dal feedback di apertura, dal feedback di chiusura, dallo stato del comando, dallo stato dell'interblocco, dalla qualità della comunicazione e dalla modalità dell'apparecchiatura.

Un simbolo di motore può utilizzare tag separati per il comando di avvio, il feedback di funzionamento, lo stato di arresto, lo scatto, il controllo locale, lo stato di manutenzione, i permissivi e l'inibizione degli allarmi.

Spostare solo gli elementi grafici visibili può quindi creare un'HMI che appare corretta ma si comporta in modo errato.

Il team di migrazione deve documentare il significato funzionale alla base di ogni elemento della schermata.

Questo lavoro comprende:

• Mappatura di ogni oggetto dinamico alla relativa origine dati.

• Ricreazione delle espressioni di animazione.

• Verifica della conferma dei comandi e della sicurezza.

• Ricostruzione della navigazione e delle gerarchie delle schermate.

• Ricreazione delle classi e delle priorità degli allarmi.

• Conferma delle unità ingegneristiche e della precisione decimale.

• Ricostruzione dei trend storici e in tempo reale.

• Test degli stati di comunicazione non validi, incerti e interrotti.

• Riproduzione dei messaggi e delle indicazioni per gli operatori.

• Sostituzione di font e simboli non supportati.

Lo sforzo è quindi determinato dalla complessità delle schermate, non solo dal loro numero.

Un'HMI moderna non dovrebbe copiare ciecamente ogni schermata legacy

La ricreazione manuale offre l'opportunità di migliorare l'interfaccia operatore.

Le grafiche HMI legacy spesso usano colori vivaci per le apparecchiature in condizioni normali, diagrammi di processo densi, tubazioni decorative e indicazioni degli allarmi incoerenti.

Queste convenzioni potrebbero essere state ragionevoli quando è stato sviluppato il sistema originale. Non sono sempre ideali per le attuali pratiche delle sale di controllo.

Un progetto di ammodernamento dovrebbe esaminare:

• Gerarchia delle schermate.

• Visibilità degli allarmi.

• Coerenza della navigazione.

• Presentazione dello stato delle apparecchiature.

• Uso del colore.

• Accessibilità dei trend.

• Requisiti di risposta degli operatori.

• Risoluzione dello schermo e disposizione delle postazioni di lavoro.

• Accessibilità e leggibilità.

Le condizioni operative normali dovrebbero rimanere visivamente discrete. I colori forti dovrebbero identificare gli stati anomali che richiedono attenzione.

Gli operatori dovrebbero poter passare dalla panoramica dell'impianto all'unità interessata, alla faceplate dell'apparecchiatura, al trend, alla cronologia degli allarmi e alla schermata diagnostica senza una navigazione eccessiva.

Tuttavia, una riprogettazione eccessiva può creare un altro rischio.

Gli operatori potrebbero aver utilizzato le schermate originali per molti anni. Cambiare ogni simbolo, colore e percorso di navigazione durante lo stesso progetto può aumentare i requisiti di formazione e il rischio di messa in servizio.

Un approccio equilibrato mantiene le relazioni di processo familiari, migliorando al contempo la presentazione degli allarmi e la navigazione.

L'estrazione dei tag deve essere trattata come un pacchetto di lavoro di ingegneria

Il materiale di origine prospetta la possibilità di esportare i dati dei tag Bailey in formato CSV. Non fornisce una procedura universale confermata.

Pertanto, non si dovrebbe presumere che un singolo comando di esportazione produca un database HMI completo e pulito.

Le possibili fonti di informazioni sui tag includono:

• Database di configurazione Symphony.

• Definizioni delle schermate esistenti.

• Configurazione dei controller e documentazione tecnica.

• Database dei server di comunicazione Bailey.

• Funzioni di esplorazione del server OPC.

• File di configurazione degli allarmi.

• Database storici.

• Elenchi di tag stampati o archiviati.

• Fogli di calcolo tecnici del sito.

L'esplorazione OPC può fornire un punto di partenza pratico dopo che il server ha stabilito la comunicazione con il sistema Bailey.

Può esporre i nomi dei tag, gli identificatori degli elementi, le descrizioni, la qualità e i valori correnti. Alcuni server supportano anche l'esportazione dello spazio dei nomi esplorato.

Tuttavia, uno spazio dei nomi OPC potrebbe non includere tutti i campi necessari alla nuova HMI.

Le priorità degli allarmi, i limiti ingegneristici, i raggruppamenti delle schermate, le note dell'operatore, la sicurezza dei comandi e le relazioni tra apparecchiature possono essere memorizzati altrove.

Alcuni server OPC espongono i tag utilizzando nomi generati diversi dai nomi Symphony originali.

Il progetto dovrebbe creare un master dei tag controllato contenente almeno:

• Nome del tag originale.

• Nome del tag della nuova HMI.

• Identificatore dell'elemento OPC.

• Descrizione.

• Tipo di dati.

• Permesso di lettura o scrittura.

• Unità ingegneristiche.

• Informazioni sullo scaling.

• Limiti e priorità degli allarmi.

• Frequenza di aggiornamento.

• Schermata associata.

• Stato della convalida.

• Risultato del test.

Questo master diventa il registro di riconciliazione tra i sistemi legacy e quelli nuovi.

Il numero di tag non è l'unico requisito di comunicazione

Un test di esplorazione riuscito non dimostra che l'architettura OPC sia in grado di supportare l'intera HMI.

Gli ingegneri devono valutare il numero di tag attivi, la frequenza di aggiornamento richiesta, la frequenza delle variazioni, l'attività degli allarmi, il traffico dei comandi e la ridondanza del server.

Un sistema può contenere decine di migliaia di tag configurati. Solo una parte può essere attiva contemporaneamente nelle schermate dell'operatore.

Il server e l'HMI devono essere testati in condizioni realistiche.

I controlli prestazionali importanti includono:

• Tempo necessario per aprire una schermata complessa.

• Ritardo tra una variazione sul campo e l'animazione nell'HMI.

• Recapito degli allarmi durante picchi di eventi.

• Raccolta dei trend alla frequenza di campionamento richiesta.

• Tempo di esecuzione del comando e di ricezione del feedback.

• Ripristino dopo un'interruzione di rete.

• Commutazione tra server ridondanti.

• Comportamento dopo il riavvio del controller.

• Stato della qualità durante un guasto di comunicazione.

• Carico di CPU, memoria e rete.

I comandi richiedono particolare attenzione.

La lettura dei valori tramite OPC può essere relativamente semplice. La scrittura sicura dei valori richiede controllo degli accessi, convalida dei comandi, conferma del feedback e gestione corretta dei guasti di comunicazione.

Il team dovrebbe testare ogni tipo di comando dell'operatore, non soltanto un tag rappresentativo.

ABB Symphony Plus offre un percorso evolutivo più ampio

La sostituzione di OPC non è l'unica strada per un sistema Bailey installato.

ABB continua a posizionare Symphony Plus come piattaforma evolutiva per le installazioni Bailey, INFI 90, Harmony Rack e Symphony meno recenti.

Una modernizzazione ABB per fasi può preservare sezioni dell'architettura di controllo e I/O installata, introducendo al contempo componenti più recenti per operatori, ingegneria, rete, controller o I/O.

Questo percorso può essere interessante quando l'organizzazione desidera una strategia di gestione del ciclo di vita supportata dal fornitore anziché una sostituzione indipendente dell'HMI.

Il progetto può modernizzare innanzitutto l'ambiente degli operatori. I controller e gli I/O possono rimanere in servizio finché il loro ciclo di vita o il loro valore operativo non ne giustifichino la sostituzione.

Le fasi successive possono riguardare comunicazioni, controller, strumenti di ingegneria e interfacce di campo.

L'architettura esatta della migrazione dipende dalla generazione del sistema installato.

Le installazioni Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony e Symphony Plus non utilizzano tutte le stesse interfacce.

I nomi dei moduli e la terminologia di rete devono essere verificati sui disegni dell'impianto e negli inventari hardware.

Le organizzazioni che mantengono il livello di controllo esistente possono inoltre esaminare i componenti ABB Bailey INFI 90 e Network 90 disponibili per pianificare la copertura dei ricambi, il supporto durante il ciclo di vita e una modernizzazione per fasi.

Questo collegamento interno è pertinente perché i progetti di modernizzazione spesso richiedono che il vecchio sistema rimanga operativo durante l'ingegneria, i test e il passaggio graduale.

Mantenere controller, moduli di comunicazione, alimentatori e moduli I/O di ricambio adeguati può ridurre i rischi durante questa transizione.

Un'HMI personalizzata o open source è possibile, ma richiede responsabilità diretta

Un'HMI personalizzata può essere sviluppata utilizzando framework software open source o commerciali.

Il materiale di origine menziona un server residente su VMS con un client moderno basato su Qt. Architetture di questo tipo possono separare la connessione ai dati lato server dal client dell'operatore.

Questo percorso può offrire flessibilità ed evitare la dipendenza da un unico fornitore di HMI.

Può anche trasformarsi in un impegno di sviluppo software a lungo termine.

L'organizzazione deve possedere o gestire:

• Server di comunicazione.

• Database dei tag.

• Applicazione client.

• Framework grafico.

• Elaborazione degli allarmi.

• Integrazione con lo storico.

• Autenticazione degli utenti.

• Aggiornamenti di sicurezza informatica.

• Distribuzione e controllo delle versioni.

• Documentazione e formazione.

Qt, Python, C++, tecnologie web o altri framework possono produrre interfacce industriali efficienti. La difficoltà non consiste nel disegnare una grafica di processo.

La difficoltà consiste nel creare un sistema per operatori affidabile, che funzioni correttamente in caso di guasti di comunicazione, riavvii del server, raffiche di allarmi, cambiamenti degli utenti e condizioni anomale dell'impianto.

Una piattaforma personalizzata dovrebbe essere scelta solo quando l'organizzazione dispone di un team di ingegneria sostenibile o di un integratore affidabile a lungo termine.

La licenza può determinare se un percorso tecnico è praticabile

I software industriali legacy utilizzano spesso meccanismi di licenza legati a identificativi hardware, indirizzi Ethernet, database delle licenze, dongle o chiavi di autorizzazione rilasciate dal fornitore.

Un sistema clonato può avviarsi correttamente, ma rifiutarsi di avviare l'applicazione Symphony perché l'identità dell'hardware virtuale è cambiata.

L'inventario della migrazione dovrebbe includere:

• Licenze del sistema operativo OpenVMS.

• Licenze applicative Bailey Symphony.

• Licenze dei database.

• Licenze di rete e comunicazione.

• Licenze dell'emulatore.

• Licenze HMI e per il numero di punti OPC.

• Licenze dello storico.

• Opzioni di ridondanza.

• Licenze dei client di ingegneria.

• Licenze dei client runtime.

Prima di scegliere la piattaforma finale, si dovrebbe ottenere una conferma scritta.

La compatibilità tecnica, senza la disponibilità legale delle licenze, non crea una soluzione distribuibile.

La cibersicurezza deve essere progettata nella sostituzione

I vecchi sistemi AlphaStation sono stati spesso installati prima che le moderne pratiche di cibersicurezza industriale diventassero uno standard.

Possono operare su reti isolate con accesso remoto limitato. Sostituirli con server Windows, client SCADA moderni, server OPC e infrastruttura Ethernet modifica la superficie di attacco.

La nuova architettura dovrebbe definire zone di rete separate per controllo, server, ingegneria e azienda.

I firewall dovrebbero consentire solo i percorsi di comunicazione necessari. L'accesso remoto dovrebbe utilizzare autenticazione gestita e registrazione.

Gli account operatore dovrebbero seguire autorizzazioni basate sui ruoli. Le funzioni di ingegneria non dovrebbero essere disponibili da ogni client HMI.

L'accesso in scrittura OPC dovrebbe essere limitato ai tag e alle stazioni che ne hanno bisogno.

La progettazione dovrebbe inoltre affrontare:

• Applicazione delle patch del sistema operativo.

• Antivirus o controllo delle applicazioni.

• Backup e ripristino.

• Sincronizzazione dell'ora.

• Registrazione degli eventi di sicurezza.

• Controlli sui supporti rimovibili.

• Supporto remoto del fornitore.

• Gestione dei certificati per OPC UA.

• Gestione del ciclo di vita degli account.

I controlli di cibersicurezza non devono impedire agli operatori di intervenire durante gli eventi di impianto. La progettazione dovrebbe bilanciare protezione, disponibilità e funzionamento deterministico.

La migrazione dovrebbe iniziare con un inventario basato su evidenze

Prima di selezionare un percorso, gli ingegneri dovrebbero documentare dettagliatamente il sistema esistente.

L'inventario dovrebbe includere tutte e quattro le AlphaStation e indicare se le loro configurazioni sono realmente identiche.

Registrare:

• Modello AlphaStation e configurazione del processore.

• Capacità di memoria.

• Tipo di disco e volumi logici.

• Versione di OpenVMS e livello delle patch.

• Versioni del software Bailey installate.

• Prodotti a livelli e database.

• Hardware grafico e risoluzione del display.

• Adattatori di rete.

• Interfacce seriali.

• Hardware di comunicazione Bailey.

• Nomi e indirizzi dei nodi.

• Procedure dei comandi di avvio.

• File di licenza.

• Procedure di backup.

• Ridondanza delle stazioni operatore.

• Stampanti collegate e dispositivi esterni.

• Conservazione dei dati storici e degli allarmi.

Il team dovrebbe inoltre raccogliere schermate di ogni visualizzazione. Gli stati dinamici dovrebbero essere acquisiti quando possibile.

Registrare gli stati normale, arrestato, in esecuzione, in allarme, inibito, locale, manuale, automatico e di comunicazione non riuscita.

Questa evidenza è essenziale quando vengono testate le nuove schermate.

Un sistema di test al banco è obbligatorio

Nessun percorso di modernizzazione dovrebbe essere testato per la prima volta sul sistema di produzione in funzione.

Un ambiente di test al banco dovrebbe riprodurre una parte sufficiente dell'architettura installata per convalidare la comunicazione e le funzioni operatore.

Per un progetto di emulazione, il banco dovrebbe contenere un ambiente OpenVMS Alpha clonato e la configurazione proposta dell'emulatore.

Per un progetto OPC, dovrebbe includere il server di comunicazione selezionato, il software HMI, grafiche rappresentative e l'accesso a un nodo Bailey di test sicuro o a una sorgente dati simulata.

Il test al banco dovrebbe verificare:

• Avvio del sistema e dell'applicazione.

• Comunicazione con il sistema Bailey.

• Numero totale di tag accessibili.

• Operazioni di lettura e scrittura.

• Scalatura dei tag e unità ingegneristiche.

• Generazione e riconoscimento degli allarmi.

• Raccolta delle tendenze.

• Animazione delle schermate.

• Sicurezza dei comandi.

• Funzioni di stampa e report.

• Comportamento al riavvio del server.

• Comportamento in caso di guasto della rete.

• Ridondanza e failover.

• Ripristino dei backup.

• Tempo di risposta dell'operatore.

I risultati dei test dovrebbero essere verificati da rappresentanti delle operations, dell'ingegneria del controllo, della manutenzione e della cybersecurity.

Il funzionamento in parallelo riduce il rischio del passaggio

Le AlphaStation originali dovrebbero rimanere disponibili durante la distribuzione iniziale del sistema sostitutivo.

Il nuovo HMI può funzionare in parallelo mentre gli ingegneri confrontano valori, allarmi, tendenze e comandi.

Il funzionamento in parallelo consente di identificare le discrepanze prima di rimuovere la stazione legacy.

Il team dovrebbe riconciliare:

• Valori di processo visualizzati.

• Indicazioni di stato.

• Priorità degli allarmi.

• Timestamp degli allarmi.

• Risultati dei comandi.

• Valori delle tendenze.

• Modalità dell'apparecchiatura.

• Qualità della comunicazione.

• Autorizzazioni di sicurezza.

Non tutte le differenze rappresentano un errore. Il nuovo sistema potrebbe utilizzare una scalatura migliorata o una presentazione degli allarmi migliorata.

Ogni differenza dovrebbe comunque essere spiegata e approvata.

Le stazioni legacy dovrebbero rimanere ripristinabili finché il nuovo HMI non supera un test di accettazione in sito osservato e un periodo operativo concordato.

Scegliere il percorso di migrazione corretto

Scegliere l'emulazione Alpha quando:

L'applicazione Symphony esistente deve rimanere invariata. Il codice sorgente non è disponibile. Le grafiche operatore sono complesse. È necessario ridurre al minimo la riqualificazione. L'interfaccia di comunicazione Bailey può essere supportata dall'architettura dell'emulatore.

Scegliere la migrazione di OpenVMS a x86 quando:

Le applicazioni richieste sono disponibili per x86-64 o possono essere ricostruite. Il codice sorgente e le competenze di progettazione sono ancora disponibili. L'organizzazione desidera mantenere OpenVMS passando al contempo a un ambiente x86 supportato.

Scegliere la ripiattaformazione OPC quando:

Il controllore INFI 90 e i livelli I/O rimangono affidabili. L'organizzazione desidera una piattaforma HMI moderna. Sono disponibili risorse di progettazione per ricostruire e convalidare schermate, allarmi, tag e logica dei comandi.

Scegliere un percorso di evoluzione ABB quando:

L’organizzazione desidera un programma di modernizzazione più ampio e supportato dal fornitore. Le fasi future possono includere sistemi per operatori, strumenti di ingegneria, interfacce di rete, controller e I/O.

Scegliere un’HMI personalizzata quando:

L’organizzazione ha requisiti specializzati e può sostenere lo sviluppo software, i test, la cybersicurezza e la manutenzione durante l’intero ciclo di vita a lungo termine.

Mantenere temporaneamente il sistema esistente quando:

Le interfacce di migrazione non sono ancora chiare. I backup sono incompleti. La situazione delle licenze non è risolta. I database dei tag non sono disponibili. I test in laboratorio non sono ancora in grado di riprodurre il percorso di comunicazione Bailey.

Un piano pratico di modernizzazione per fasi

Fase 1: preservare l’ambiente esistente.

Creare backup verificati delle immagini di ogni AlphaStation. Registrare i dettagli relativi a hardware, software, rete, licenze e avvio. Testare il ripristino ove possibile.

Fase 2: identificare l’architettura di comunicazione.

Documentare esattamente come ogni stazione Symphony comunica con INFI 90. Verificare se l’interfaccia può essere emulata o sostituita da un server supportato.

Fase 3: realizzare una prova di concetto.

Testare una stazione clonata su un emulatore Alpha oppure collegare un server OPC a un nodo Bailey rappresentativo.

Fase 4: creare l’anagrafica principale dei tag.

Riconciliare i tag dei controller, gli identificativi degli elementi OPC, le unità ingegneristiche, i comandi, gli allarmi e l’utilizzo nelle schermate.

Fase 5: ricostruire schermate rappresentative.

Selezionare diverse schermate contenenti requisiti differenti di animazione, allarmi, comandi e trend.

Fase 6: completare l’accettazione in laboratorio.

Testare il caricamento completo dei tag, i guasti di comunicazione, il riavvio del server, i picchi di allarmi, il comportamento dei comandi e il ripristino dai backup.

Fase 7: distribuire in parallelo.

Utilizzare contemporaneamente le HMI nuova e vecchia. Confrontare i valori e le risposte degli operatori.

Fase 8: eseguire il passaggio controllato con osservatori.

Utilizzare una procedura di test approvata. Mantenere disponibili le AlphaStation come soluzione di riserva.

Fase 9: dismettere gradualmente l’hardware obsoleto.

Non distruggere le immagini originali, i registri di configurazione, le licenze o l’hardware finché l’accettazione a lungo termine non è completata.

Domande frequenti

È possibile clonare direttamente su un PC moderno il disco di una AlphaStation OpenVMS?

No. L’immagine contiene codice macchina Alpha e richiede hardware compatibile con Alpha. Un moderno PC x86 non può avviarla direttamente. L’immagine deve essere ripristinata su hardware Alpha compatibile o su un emulatore Alpha.

VMware o VirtualBox possono eseguire OpenVMS?

Possono eseguire versioni supportate di OpenVMS x86-64. Non convertono una vecchia installazione OpenVMS Alpha in un’applicazione x86. OpenVMS Alpha richiede l’emulazione Alpha.

È possibile conservare le schermate Symphony originali?

Di norma possono essere conservati quando l’intero ambiente Alpha viene eseguito su un emulatore compatibile. Solitamente richiedono una ricreazione manuale durante il passaggio a un’altra piattaforma HMI.

Un server OPC esporta automaticamente ogni tag Bailey?

Non necessariamente. La navigazione OPC può fornire uno spazio dei nomi utile, ma la configurazione degli allarmi, le relazioni tra le schermate, i comandi, le descrizioni e i metadati ingegneristici possono richiedere un’ulteriore estrazione e riconciliazione.

GE CIMPLICITY è l'unico HMI sostitutivo?

No. È una delle piattaforme possibili e compare nell'esempio sul campo fornito con la fonte. La selezione finale dovrebbe dipendere dal supporto alla comunicazione, dalla ridondanza, dalle licenze, dalla cybersicurezza, dalle risorse di ingegneria e dai requisiti degli operatori.

La migrazione da Alpha a Itanium è ancora conveniente?

Può essere giustificato quando il software necessario è disponibile solo per i sistemi Integrity o quando l'infrastruttura Integrity esistente è già supportata. In genere è un percorso transitorio, non la strategia di modernizzazione a lungo termine più solida.

I controller e l'I/O INFI 90 possono rimanere installati?

Sì, quando rimangono affidabili e l'architettura di comunicazione selezionata le supporta. La modernizzazione dell'HMI può essere completata separatamente dalla sostituzione dei controller e dell'I/O.

Le vecchie AlphaStation devono essere rimosse immediatamente dopo il passaggio al nuovo sistema?

No. Dovrebbero rimanere disponibili come fallback collaudato finché il nuovo ambiente operatore non avrà superato il collaudo funzionale, prestazionale e operativo.

La soluzione corretta dipende da ciò che deve essere preservato

Il principale errore tecnico in molti piani HMI legacy consiste nel trattare la stazione operatore come un normale PC.

Un'AlphaStation con OpenVMS Alpha e Bailey Symphony costituisce un ambiente hardware e software completo. L'architettura del processore, il sistema operativo, le interfacce di comunicazione, i binari delle applicazioni, le licenze, la grafica e le connessioni al sistema di controllo sono interdipendenti.

Una clonazione del disco preserva i dati. Non traduce quell'ambiente in un'altra architettura.

L'emulazione Alpha offre il percorso più diretto quando è necessario mantenere invariata l'intera installazione Symphony.

OpenVMS x86-64 offre un percorso verso un sistema operativo moderno quando le applicazioni possono essere migrate o ricostruite.

La ripiattaformazione OPC offre un percorso pratico quando il livello di controllo INFI 90 conserva il proprio valore, ma il livello operatore deve essere sostituito.

L'evoluzione di ABB Symphony Plus può offrire una strategia più ampia e graduale quando l'organizzazione desidera modernizzarsi oltre il solo HMI.

La decisione finale dovrebbe basarsi su un inventario verificato, uno studio delle interfacce di comunicazione, una revisione delle licenze, una prova di fattibilità, un test al banco e un collaudo operativo con verifica da parte del cliente.

Non esiste una sostituzione a costo e impegno zero. Esistono tuttavia diversi percorsi di migrazione controllati in grado di proteggere l'investimento esistente nel controllo di processo, eliminando al contempo la dipendenza da hardware AlphaStation obsoleto.