Modernizzazione delle interfacce HMI Bailey INFI 90 Symphony in esecuzione su OpenVMS Alpha
Una guida pratica alla sostituzione delle stazioni operatore Bailey Symphony obsolete basate su OpenVMS Alpha. Confronta l’emulazione Alpha, la migrazione a OpenVMS x86, la ripiattaforma OPC e la m...
Modernizzare un HMI senza sostituire l’intero sistema INFI 90
Molti sistemi Bailey INFI 90 continuano a funzionare in modo affidabile per decenni dopo la loro installazione originale. I loro 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, adattatori grafici non più supportati, dispositivi di archiviazione datati 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 funzioni di 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 obsoleto delle AlphaStation, 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 è principalmente una 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 cybersicurezza, gli obiettivi di produzione o le condizioni di supporto giustificano la sostituzione dei livelli di controllo inferiori.
Esistono diversi possibili percorsi di modernizzazione. Tuttavia, preservano parti diverse del sistema esistente.
Un emulatore Alpha può preservare quasi l’intero ambiente software. Una migrazione di 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, ricostruendo al contempo 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 con PC.
Figura 1. Tre principali percorsi di modernizzazione possono preservare porzioni diverse dell’investimento installato in Bailey INFI 90 e Symphony.
Perché clonare il disco della 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, la grafica 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 sviluppati per l’architettura Alpha.
Un PC moderno standard utilizza un processore x86-64. Presenta inoltre controller di archiviazione, dispositivi di rete, strutture di interrupt, hardware grafico, interfacce firmware e bus per periferiche diversi.
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 all’interno di una normale macchina virtuale x86 non rende avviabile quell’immagine.
La macchina virtuale può fornire un disco virtuale, un adattatore di rete virtuale e un dispositivo grafico virtuale. OpenVMS Alpha richiede comunque un processore Alpha e dispositivi compatibili dell’epoca Alpha.
Per questo i due concetti devono rimanere distinti:
La virtualizzazione presenta normalmente hardware virtuale che utilizza la stessa architettura del processore dell’host.
L’emulazione cross-architettura riproduce via software un altro processore e un altro ambiente hardware.
OpenVMS Alpha richiede il secondo approccio quando i file binari Alpha originali e il sistema operativo devono rimanere invariati.
La clonazione del disco è 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 parte più consistente 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 vedere 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 altri dispositivi supportati con equivalenti definiti via 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 file 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.
• Grafica degli operatori e database delle schermate.
• Configurazioni degli allarmi e file storici.
• Account utente e procedure di comando.
• Utility esistenti specifiche del sito.
• Interfacce applicative che dipendono dall’ambiente Alpha.
• Flussi di lavoro degli operatori che altrimenti richiederebbero una nuova formazione.
La migrazione pratica consiste solitamente nella creazione di un’immagine verificata o di un backup dei dischi Alpha originali. Questi dati vengono ripristinati in contenitori di dischi virtuali utilizzati dall’emulatore.
La configurazione dell’emulatore deve riprodurre caratteristiche adeguate di CPU, memoria, disco, 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à ingegneristiche. È necessario verificare le mappature dei dispositivi. Le interfacce di rete devono essere configurate. È necessario esaminare 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 può non funzionare perché dipende da uno specifico adattatore di rete, un’interfaccia bus, un dispositivo seriale o un determinato comportamento temporale.
È 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 domanda più importante sull’emulazione non è se OpenVMS raggiunge la richiesta 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 del sito possono variare significativamente.
Prima di adottare l’emulazione Alpha, gli ingegneri dovrebbero documentare:
• L’interfaccia di rete fisica installata in ciascun 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 della ridondanza e del failover tra le stazioni operatore.
• Requisiti di sincronizzazione temporale.
• Funzioni grafiche e della tastiera utilizzate dagli operatori.
Un fornitore di emulatori può supportare dispositivi Ethernet e di archiviazione Alpha comuni. 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, il ricorso a un 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 lettura statica dei tag. Gli operatori dovrebbero verificare i valori in tempo reale, i comandi, gli allarmi, il riconoscimento, i trend, la navigazione nelle schermate, la stampa, la gestione degli eventi e il ripristino della stazione.
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ò operare in ambienti virtualizzati supportati su server moderni.
Ciò crea un’ulteriore opzione di migrazione che non era disponibile durante molte delle precedenti discussioni sulla modernizzazione di INFI 90.
Tuttavia, OpenVMS x86-64 non esegue direttamente i binari OpenVMS Alpha come se fossero applicazioni x86 native.
L’ambiente applicativo deve essere migrato.
Potrebbe essere necessario trasferire, esaminare, ricompilare, collegare e testare il codice sorgente per x86-64. Anche le librerie di terze parti e i prodotti a più livelli 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. Le applicazioni commerciali chiuse normalmente non possono essere ricompilate senza il supporto del fornitore.
Questo percorso può essere ancora pratico per server dati personalizzati, sistemi storici, utilità, report e applicazioni di integrazione che vengono eseguiti insieme all’HMI Symphony.
È meno probabile che preservi un vecchio ambiente operativo proprietario Symphony senza una versione supportata dell’applicazione.
Una valutazione della migrazione di OpenVMS x86 dovrebbe identificare:
• Ogni eseguibile installato e ogni prodotto a più livelli.
• Codice sorgente disponibile e procedure di compilazione.
• Dipendenze da compilatori e runtime.
• Prodotti database e formati di file.
• Librerie di comunicazione proprietarie.
• Dipendenze da sistemi grafici o a finestre.
• Disponibilità delle licenze per x86-64.
• Modifiche necessarie causate dalle differenze architetturali.
• Presupposti relativi a prestazioni e temporizzazione.
Questo percorso offre 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 Itanium è solitamente un’opzione transitoria
OpenVMS è stato inoltre rilasciato per i server HPE Integrity basati sull’architettura Itanium.
Esistono strumenti di migrazione e metodi di progettazione per trasferire alcune applicazioni Alpha a OpenVMS Integrity. In passato, questo offriva un percorso supportato per abbandonare l’hardware Alpha obsoleto.
Oggi, tuttavia, l’hardware Itanium è di per sé una piattaforma legacy.
Un passaggio da Alpha a Integrity può eliminare una dipendenza da hardware obsoleto creandone al contempo un'altra. Server, parti di ricambio, interfacce di archiviazione e competenze specialistiche adeguati continueranno a diventare meno disponibili.
Itanium può essere ancora rilevante quando un sito dispone già di un'infrastruttura Integrity supportata. Può inoltre essere rilevante quando esiste un prodotto stratificato richiesto per Integrity ma non per x86-64.
Per un nuovo progetto di modernizzazione, dovrebbe generalmente essere valutato come percorso intermedio di compatibilità.
Il piano aziendale deve spiegare perché il passaggio a Integrity sia preferibile all'emulazione di Alpha, alla migrazione di OpenVMS su x86 o alla riconfigurazione della piattaforma HMI.
La riconfigurazione su piattaforma OPC preserva il livello di controllo
La riconfigurazione su piattaforma OPC sostituisce il livello di interfaccia operatore mantenendo i controller INFI 90 e l'I/O di campo esistenti.
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 schermate, allarmi, trend, sicurezza, comandi operatore, report e servizi delle stazioni di lavoro.
Questo percorso elimina la dipendenza dall'applicazione operatore Symphony originale. Evita inoltre la necessità di eseguire OpenVMS Alpha sulle nuove stazioni operatore.
L'architettura include comunemente:
• 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.
• Stazioni di lavoro per operatori e tecnici.
• Servizi opzionali di storicizzazione, reportistica e analisi degli allarmi.
Un esempio sul campo citato nel materiale di origine utilizzava un server OPC RoviSys con GE CIMPLICITY. Il sistema risultava operativo con successo, ma il progetto richiedeva la ricostruzione delle schermate 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 adatti 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 conserva il livello di controllo INFI 90 sostituendo al contempo l'ambiente operativo Symphony legacy.
La connettività OPC non converte le schermate esistenti
Un server OPC fornisce la connettività dei dati. Normalmente non converte le vecchie schermate HMI in un nuovo formato HMI.
Le schermate Symphony originali possono contenere elementi grafici statici, simboli dinamici, variazioni di colore, valori numerici, grafici a barre, indicatori di allarme, pulsanti di navigazione, controlli di comando, trend e modelli di funzioni personalizzati.
Questi elementi devono essere ricreati nell'HMI di destinazione.
Le schermate semplici possono essere ridisegnate direttamente. Le schermate complesse 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.
Il simbolo di una 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.
Il simbolo di un motore può utilizzare tag separati per il comando di avviamento, il feedback di marcia, lo stato di arresto, lo scatto, il controllo locale, lo stato di manutenzione, i permessi e l'inibizione degli allarmi.
Il trasferimento delle sole grafiche visibili può quindi creare un HMI dall'aspetto corretto ma dal funzionamento errato.
Il team di migrazione deve documentare il significato funzionale alla base di ogni elemento della schermata.
Questo lavoro include:
• 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.
• Verifica delle unità di misura 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 moderno non dovrebbe copiare ciecamente ogni schermata legacy
La ricreazione manuale offre l'opportunità di migliorare l'interfaccia operatore.
Le grafiche HMI legacy utilizzano spesso colori vivaci per le apparecchiature in condizioni normali, diagrammi di processo densi, tubazioni decorative e indicazioni degli allarmi incoerenti.
Queste convenzioni potevano essere ragionevoli quando il sistema originale è stato sviluppato. Non sono sempre ideali per le attuali pratiche delle sale di controllo.
Un progetto di modernizzazione 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 intensi 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 della messa in servizio.
Un approccio equilibrato mantiene le relazioni familiari tra i processi, migliorando al contempo la presentazione e la navigazione degli allarmi.
L'estrazione dei tag deve essere trattata come un pacchetto di lavoro ingegneristico
Il materiale di origine solleva 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 unico comando di esportazione produca un database HMI completo e pulito.
Possibili fonti di informazioni sui tag includono:
• Database di configurazione Symphony.
• Definizioni delle schermate esistenti.
• Configurazione dei controller e documentazione ingegneristica.
• 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 dell’ingegneria di 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 originali di Symphony.
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 sulla scalatura.
• Limiti e priorità degli allarmi.
• Frequenza di aggiornamento.
• Schermata associata.
• Stato della convalida.
• Risultato del test.
Questo master diventa il registro di riconciliazione tra il sistema legacy e quello nuovo.
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 dei server.
Un sistema può contenere decine di migliaia di tag configurati. Solo una parte può essere attiva contemporaneamente sulle schermate dell’operatore.
Il server e l’HMI dovrebbero essere testati in condizioni realistiche.
I principali controlli delle prestazioni includono:
• Tempo necessario per aprire una schermata complessa.
• Ritardo tra una modifica sul campo e l’animazione sull’HMI.
• Distribuzione 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 solo un tag rappresentativo.
ABB Symphony Plus offre un percorso evolutivo più ampio
La sostituzione di OPC non è l'unica soluzione per un sistema Bailey installato.
ABB continua a presentare Symphony Plus come una piattaforma evolutiva per le installazioni Bailey, INFI 90, Harmony Rack e Symphony meno recenti.
Una modernizzazione ABB graduale può preservare parti dell'architettura di controllo e I/O installata, introducendo al contempo componenti più recenti per operatori, ingegneria, rete, controllo o I/O.
Questa soluzione può essere interessante quando l'organizzazione desidera una strategia di ciclo di vita supportata dal fornitore anziché una sostituzione indipendente dell'HMI.
Il progetto può modernizzare innanzitutto l'ambiente operatore. I controller e l'I/O possono rimanere in servizio finché il loro ciclo di vita o il loro valore operativo non ne giustifichi 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 sulla documentazione dell'impianto e negli inventari hardware.
Le organizzazioni che mantengono il livello di controllo esistente possono inoltre consultare i componenti ABB Bailey INFI 90 e Network 90 disponibili quando pianificano la disponibilità dei ricambi, il supporto durante il ciclo di vita e una modernizzazione graduale.
Questo collegamento interno è pertinente perché i progetti di modernizzazione spesso richiedono che il vecchio sistema rimanga operativo durante l'ingegneria, i test e la messa in servizio graduale.
Mantenere controller, moduli di comunicazione, alimentatori e moduli I/O di ricambio adeguati può ridurre i rischi durante questa transizione.
Un HMI personalizzato o open source è possibile, ma richiede responsabilità diretta
Un HMI personalizzato può essere sviluppato 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 dati lato server dal client operatore.
Questa soluzione può offrire flessibilità ed evitare la dipendenza da un unico fornitore di HMI.
Può inoltre diventare 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 capaci. La difficoltà non consiste nel disegnare una grafica di processo.
La difficoltà consiste nel creare un sistema operatore affidabile che funzioni correttamente in caso di guasti alle comunicazioni, riavvii dei server, raffiche di allarmi, modifiche degli utenti e condizioni anomale dell'impianto.
Una piattaforma personalizzata dovrebbe essere selezionata solo quando l'organizzazione dispone di un team di ingegneria sostenibile o di un integratore affidabile a lungo termine.
Le licenze possono determinare se una strategia tecnica è pratica
Il software industriale legacy utilizza spesso meccanismi di licenza associati a identificativi hardware, indirizzi Ethernet, database delle licenze, dongle o chiavi di autorizzazione rilasciate dal fornitore.
Un sistema clonato potrebbe 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 per il conteggio dei punti HMI e 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 implementabile.
La cybersicurezza deve essere progettata nella sostituzione
I vecchi sistemi AlphaStation venivano spesso installati prima che le moderne pratiche di cybersicurezza industriale diventassero standard.
Possono funzionare 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 degli operatori 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 cybersicurezza non devono impedire agli operatori di reagire durante gli eventi nell'impianto. La progettazione dovrebbe bilanciare protezione, disponibilità e funzionamento deterministico.
La migrazione dovrebbe iniziare da un inventario basato su evidenze
Prima di selezionare una strategia, gli ingegneri dovrebbero documentare in dettaglio 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 e database stratificati.
• Hardware grafico e risoluzione del display.
• Schede 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 funzione, in allarme, inibito, locale, manuale, automatico e con comunicazione non riuscita.
Questa documentazione è essenziale quando si testano 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 attivo.
Un ambiente di test al banco dovrebbe riprodurre una parte sufficiente dell'architettura installata per convalidare la comunicazione e le funzioni dell'operatore.
Per un progetto di emulazione, il banco dovrebbe contenere un ambiente OpenVMS Alpha clonato e la configurazione dell'emulatore proposta.
Per un progetto OPC, dovrebbe includere il server di comunicazione selezionato, il software HMI, schermate rappresentative e l'accesso a un nodo di test Bailey sicuro o a una fonte 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 funzioni operative, dell'ingegneria dei sistemi di controllo, della manutenzione e della sicurezza informatica.
Il funzionamento in parallelo riduce il rischio del passaggio
Le AlphaStation originali dovrebbero rimanere disponibili durante la distribuzione iniziale del sistema sostitutivo.
La nuova 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 deve comunque essere spiegata e approvata.
Le stazioni legacy dovrebbero rimanere ripristinabili finché la nuova HMI non avrà superato 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. La grafica dell'operatore è complessa. È necessario ridurre al minimo la riqualificazione. L'interfaccia di comunicazione Bailey può essere supportata dall'architettura dell'emulatore.
Scegliere la migrazione di OpenVMS x86 quando:
Le applicazioni richieste sono disponibili per x86-64 oppure possono essere ricompilate. Il codice sorgente e le competenze tecniche restano disponibili. L'organizzazione vuole mantenere OpenVMS passando al contempo a un ambiente x86 supportato.
Scegliere il re-platforming OPC quando:
Il controller INFI 90 e i livelli I/O rimangono affidabili. L'organizzazione desidera una piattaforma HMI moderna. Sono disponibili risorse di engineering per ricostruire e convalidare display, allarmi, tag e logica dei comandi.
Scegliere un percorso evolutivo ABB quando:
L'organizzazione desidera un programma di modernizzazione più ampio supportato dal fornitore. Le fasi future possono includere sistemi operatore, strumenti di engineering, interfacce di rete, controller e I/O.
Scegliere un HMI personalizzato quando:
L'organizzazione ha requisiti specializzati e può sostenere lo sviluppo software, i test, la cybersicurezza e la manutenzione del ciclo di vita a lungo termine.
Mantenere temporaneamente il sistema esistente quando:
Le interfacce di migrazione non sono ancora chiare. I backup sono incompleti. Le licenze non sono state risolte. I database dei tag non sono disponibili. I test al banco non possono ancora 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 hardware, software, di rete, delle licenze e dell'avvio. Testare il ripristino ove possibile.
Fase 2: identificare l'architettura di comunicazione.
Documentare esattamente il modo in cui 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 fattibilità.
Testare una stazione clonata su un emulatore Alpha oppure collegare un server OPC a un nodo Bailey rappresentativo.
Fase 4: creare il master dei tag.
Riconciliare i tag dei controller, gli identificativi degli item OPC, le unità ingegneristiche, i comandi, gli allarmi e l'utilizzo dei display.
Fase 5: ricostruire i display rappresentativi.
Selezionare diverse schermate contenenti requisiti differenti di animazione, allarmi, comandi e trend.
Fase 6: completare l'accettazione al banco.
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 dei backup.
Fase 7: implementare in parallelo.
Utilizzare contemporaneamente i nuovi e i vecchi HMI. Confrontare i valori e le risposte degli operatori.
Fase 8: eseguire il passaggio sotto supervisione.
Utilizzare una procedura di test approvata. Mantenere le AlphaStation disponibili come sistema di riserva.
Fase 9: dismettere gradualmente l'hardware legacy.
Non distruggere le immagini originali, i record 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 OpenVMS AlphaStation?
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 preservare i display Symphony originali?
Di norma possono essere preservati quando l'intero ambiente Alpha viene eseguito sotto un emulatore compatibile. In genere richiedono una ricreazione manuale quando si passa 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 visualizzazioni, i comandi, le descrizioni e i metadati ingegneristici possono richiedere un'ulteriore estrazione e riconciliazione.
GE CIMPLICITY è l'unico HMI sostitutivo?
No. È una possibile piattaforma 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 ingegneristiche e dai requisiti degli operatori.
Vale ancora la pena migrare da Alpha a Itanium?
Può essere giustificato quando il software richiesto è 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 gli 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 degli 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 l'accettazione funzionale, prestazionale e operativa.
La soluzione corretta dipende da ciò che deve essere preservato
Il principale errore tecnico in molti piani HMI per sistemi legacy consiste nel trattare la stazione operatore come un normale PC.
Un AlphaStation che esegue OpenVMS Alpha e Bailey Symphony è un ambiente hardware e software completo. L'architettura del processore, il sistema operativo, le interfacce di comunicazione, i binari applicativi, le licenze, la grafica e le connessioni al sistema di controllo sono interdipendenti.
Un clone del disco preserva i dati. Non traduce quell'ambiente per adattarlo a 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 riprogettazione della piattaforma OPC offre un percorso pratico quando il livello di controllo INFI 90 rimane valido, ma si desidera sostituire il livello operatore.
L'evoluzione di ABB Symphony Plus può offrire una strategia più ampia e graduale quando l'organizzazione desidera modernizzarsi oltre l'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'accettazione operativa alla presenza delle parti interessate.
Non esiste una sostituzione a sforzo zero. Esistono tuttavia diversi percorsi di migrazione controllata che possono proteggere l'investimento esistente nel controllo di processo, eliminando al contempo la dipendenza dall'hardware AlphaStation obsoleto.