Modernisierung der auf OpenVMS Alpha laufenden Bailey INFI 90 Symphony-HMIs

Modernisierung einer HMI ohne Ersatz des gesamten INFI-90-Systems

Viele Bailey-INFI-90-Systeme arbeiten noch Jahrzehnte nach ihrer ursprünglichen Installation zuverlässig. Ihre Steuerungen, Kommunikationsmodule, Abschlussgeräte und Feld-E/A können die erforderlichen Steuerungsfunktionen weiterhin erfüllen.

Das dringendste Lebenszyklusproblem liegt häufig oberhalb der Steuerungsebene.

Bedienerstationen können von veralteter AlphaStation-Hardware, nicht mehr unterstützten Grafikadaptern, überholten Speichergeräten und alten OpenVMS-Alpha-Softwareumgebungen abhängen. Ersatzteile sind immer schwieriger zu beschaffen, während erfahrene OpenVMS- und Bailey-Symphony-Ingenieure immer seltener verfügbar sind.

Das hier betrachtete Beispiel umfasst vier AlphaStation-255-Arbeitsstationen. Jede Station führt OpenVMS Alpha aus und stellt Bedienfunktionen für Bailey Symphony eines dezentralen Bailey-INFI-90-Leitsystems bereit.

Das Ziel besteht nicht unbedingt darin, das gesamte DCS zu ersetzen. Ein praktischeres Ziel ist es, die Abhängigkeit von veralteter AlphaStation-Hardware zu beseitigen und zugleich stabile Steuerungen, Feldverdrahtung, E/A-Module, Steuerungslogik und Prozessabläufe zu bewahren.

Diese Unterscheidung verändert die Modernisierungsstrategie.

Das Projekt ist in erster Linie eine Migration der Bedienoberfläche und der Computing-Plattform. Es wird erst dann zu einer vollständigen DCS-Migration, wenn der Lebenszyklus der Steuerungen, Cybersicherheitsanforderungen, Produktionsziele oder Supportbedingungen den Ersatz der unteren Steuerungsebenen rechtfertigen.

Es gibt mehrere mögliche Modernisierungswege. Sie bewahren jedoch unterschiedliche Teile des bestehenden Systems.

Ein Alpha-Emulator kann nahezu die vollständige Softwareumgebung bewahren. Eine OpenVMS-x86-Migration bewahrt die Betriebssystemfamilie, erfordert jedoch eine Migration der Anwendungen. Ein OPC-basierter HMI-Ersatz bewahrt die Steuerungsebene und erstellt die Bedienoberfläche neu. Eine ABB-Weiterentwicklungsstrategie kann die umfassendere Symphony-Architektur schrittweise modernisieren.

Keiner dieser Wege sollte als einfacher PC-Ersatz beschrieben werden.

Abbildung 1. Drei wesentliche Modernisierungswege können unterschiedliche Teile der installierten Investition in Bailey INFI 90 und Symphony bewahren.

Warum das Klonen des AlphaStation-Datenträgers nicht ausreicht

Das Klonen von Datenträgern ist nützlich, um eine installierte OpenVMS-Alpha-Umgebung zu bewahren. Dabei können das Betriebssystem, Anwendungsdateien, Gerätekonfigurationen, Benutzerkonten, Bailey-Software, Datenbanken, Grafiken und standortspezifische Einstellungen erfasst werden.

Das Klonen eines Datenträgers wandelt Alpha-Software jedoch nicht in x86-Software um.

Das geklonte Betriebssystem enthält weiterhin Prozessorbefehle für Alpha. Sein Kernel, Bootloader, seine Systembibliotheken, Anwendungen und Hardwaretreiber wurden für die Alpha-Architektur entwickelt.

Ein moderner Standard-PC verwendet einen x86-64-Prozessor. Außerdem verfügt er über andere Speichercontroller, Netzwerkgeräte, Interruptstrukturen, Grafikhardware, Firmware-Schnittstellen und Peripheriebusse.

VMware, VirtualBox, Hyper-V und herkömmliche x86-Hypervisoren virtualisieren x86-kompatible Hardware. Sie übersetzen Alpha-Prozessorbefehle normalerweise nicht in x86-Befehle.

Daher wird ein OpenVMS-Alpha-Datenträgerabbild nicht dadurch bootfähig, dass es in eine gewöhnliche x86-VM eingebunden wird.

Die virtuelle Maschine kann eine virtuelle Festplatte, einen virtuellen Netzwerkadapter und ein virtuelles Grafikgerät bereitstellen. OpenVMS Alpha erwartet weiterhin einen Alpha-Prozessor und unterstützte Geräte aus der Alpha-Ära.

Deshalb müssen zwei Konzepte getrennt betrachtet werden:

Virtualisierung stellt normalerweise virtuelle Hardware unter Verwendung derselben Prozessorarchitektur wie der Host bereit.

Architekturübergreifende Emulation bildet einen anderen Prozessor und eine andere Hardwareumgebung softwareseitig nach.

OpenVMS Alpha erfordert den zweiten Ansatz, wenn die ursprünglichen Alpha-Binärdateien und das Betriebssystem unverändert bleiben müssen.

Das Klonen von Datenträgern ist daher in drei eingeschränkten Situationen praktikabel.

Die erste Möglichkeit ist die Wiederherstellung auf demselben AlphaStation-Modell mit kompatiblem Speicher und kompatiblen Peripheriegeräten.

Die zweite Möglichkeit ist die Wiederherstellung auf einem anderen unterstützten Alpha-System nach Durchführung der erforderlichen Änderungen an Geräten und Konfiguration.

Die dritte Möglichkeit ist die Wiederherstellung in einem Alpha-Emulator, der eine kompatible AlphaServer- oder AlphaStation-Umgebung nachbildet.

Das alleinige Klonen löst das Architekturproblem nicht. Die Zielumgebung muss Alpha-Maschinenbefehle weiterhin verstehen und ausführen können.

Alpha-Emulation bewahrt den größten Teil der bestehenden Investition

Die Alpha-Emulation ist normalerweise der am wenigsten störende Weg, wenn die vorhandene Symphony-Software ohne Änderungen am Quellcode weiter betrieben werden muss.

Ein Alpha-Emulator läuft auf moderner x86-Hardware, stellt OpenVMS jedoch ein virtuelles Alpha-System bereit. Das ursprüngliche Betriebssystem und die Anwendungen sehen weiterhin eine Alpha-kompatible Hardwareumgebung.

Produkte wie CHARON-AXP wurden für diesen Zweck entwickelt. Der Emulator ersetzt den physischen Alpha-Prozessor, die Speicherarchitektur, Speichercontroller, Ethernet-Adapter und andere unterstützte Geräte durch softwaredefinierte Entsprechungen.

Der x86-Server führt Windows oder Linux als Hostumgebung aus. Der Alpha-Emulator läuft auf diesem Host. OpenVMS Alpha läuft anschließend innerhalb des emulierten Alpha-Systems.

Dieser Ansatz unterscheidet sich von der Portierung von OpenVMS auf x86.

Die ursprüngliche OpenVMS-Alpha-Installation bleibt eine Alpha-Installation. Die Bailey-Symphony-Binärdateien bleiben Alpha-Binärdateien. Der Emulator übersetzt das erforderliche Verhalten der Alpha-Hardware oder bildet es nach.

Dies kann Folgendes bewahren:

• Das installierte OpenVMS-Alpha-Betriebssystem.

• Vorhandene Bailey-Symphony-Anwendungen.

• Bedienergrafiken und Anzeigedatenbanken.

• Alarmkonfigurationen und historische Dateien.

• Benutzerkonten und Befehlsprozeduren.

• Vorhandene standortspezifische Dienstprogramme.

• Anwendungsschnittstellen, die von der Alpha-Umgebung abhängen.

• Bedienerabläufe, die andernfalls eine Umschulung erfordern würden.

Die praktische Migration umfasst in der Regel die Erstellung eines verifizierten Abbilds oder Backups der ursprünglichen Alpha-Festplatten. Diese Daten werden in virtuelle Festplattencontainer wiederhergestellt, die vom Emulator verwendet werden.

Die Emulatorkonfiguration muss geeignete Merkmale für CPU, Arbeitsspeicher, Festplatten, Netzwerk und Peripheriegeräte reproduzieren. Möglicherweise muss das Team außerdem physische serielle Schnittstellen oder Netzwerkschnittstellen über das Hostsystem zuordnen.

Die Alpha-Emulation kann die Abhängigkeit von veralteter physischer Hardware erheblich verringern. Sie kann außerdem die Sicherung vereinfachen, da virtuelle Festplattendateien mithilfe moderner Speicherinfrastrukturen kopiert werden können.

Der Begriff „keine Änderungen“ sollte jedoch mit Vorsicht verwendet werden.

Der Anwendungscode kann unverändert bleiben, doch die Umgebung erfordert weiterhin Engineering-Aufwand. Gerätez Zuordnungen müssen überprüft werden. Netzwerkschnittstellen müssen konfiguriert werden. OpenVMS- und Anwendungslizenzen müssen überprüft werden.

Der Emulator muss außerdem mit der am Standort verwendeten Bailey-Kommunikationsschnittstelle getestet werden.

Eine generische OpenVMS-Anwendung kann korrekt funktionieren, während eine spezialisierte DCS-Schnittstelle ausfällt, weil sie von einem bestimmten Netzwerkadapter, einer Bus-Schnittstelle, einem seriellen Gerät oder einem bestimmten Zeitverhalten abhängt.

Die genaue Konfiguration der AlphaStation 255 muss daher vor der Auswahl eines Emulatorprofils inventarisiert werden.

Die Bailey-Kommunikationsschnittstelle ist der entscheidende Emulationstest

Die wichtigste Frage bei der Emulation ist nicht, ob OpenVMS die Anmeldeaufforderung erreicht.

Die entscheidende Frage ist, ob die emulierte Station unter vollständigen Betriebsbedingungen korrekt mit dem Bailey-INFI-90-System kommuniziert.

Die Schnittstelle kann von Ethernet, serieller Kommunikation, einer Bailey-Netzwerkschnittstelle oder spezieller Kommunikationshardware abhängen. Standortkonfigurationen können erheblich variieren.

Vor der Entscheidung für die Alpha-Emulation sollten Ingenieure Folgendes dokumentieren:

• Die in jeder AlphaStation installierte physische Netzwerkschnittstelle.

• Das zwischen Symphony und INFI 90 verwendete Kommunikationsprotokoll.

• In OpenVMS zugewiesene Gerätenamen.

• Netzwerkadressen und Knotendefinitionen.

• Erforderliche DECnet-, TCP/IP-, LAT- oder proprietäre Dienste.

• Einstellungen der seriellen Schnittstellen, sofern zutreffend.

• Externe Lizenzschlüssel oder Hardware-Dongles.

• Redundanz- und Failover-Verhalten zwischen Bedienerstationen.

• Anforderungen an die Zeitsynchronisierung.

• Von Bedienern verwendete Grafik- und Tastaturfunktionen.

Ein Emulatoranbieter unterstützt möglicherweise gängige Alpha-Ethernet- und Speichergeräte. Das bestätigt nicht automatisch die Unterstützung jeder proprietären Bailey-Schnittstelle.

Wenn die bestehende HMI von einem spezialisierten physischen Adapter abhängt, der nicht virtualisiert werden kann, kann für den Emulatorweg ein alternatives Kommunikations-Gateway erforderlich sein.

Das Projekt sollte daher einen Prüfstandstest mit einer geklonten Station und Zugriff auf ein repräsentatives Bailey-Netzwerk umfassen.

Der Test muss mehr als das statische Lesen von Tags umfassen. Bediener sollten Echtzeitwerte, Befehle, Alarme, Quittierungen, Trends, die Navigation in Anzeigen, das Drucken, die Ereignisverarbeitung und die Wiederherstellung der Station überprüfen.

Die Leistung sollte auch während Alarmspitzen und bei hoher Tag-Aktualisierungsrate getestet werden.

OpenVMS x86-64 ist eine andere Migrationsroute

Modernes OpenVMS ist für die x86-64-Architektur verfügbar. Es kann in unterstützten virtualisierten Umgebungen auf modernen Servern betrieben werden.

Dadurch entsteht eine zusätzliche Migrationsoption, die während vieler früherer Diskussionen zur Modernisierung von INFI 90 nicht verfügbar war.

OpenVMS x86-64 führt OpenVMS-Alpha-Binärdateien jedoch nicht direkt aus, als wären sie native x86-Anwendungen.

Die Anwendungsumgebung muss migriert werden.

Der Quellcode muss möglicherweise übertragen, geprüft, neu kompiliert, gelinkt und für x86-64 getestet werden. Auch Drittanbieterbibliotheken und Layered Products müssen für die Zielversion verfügbar sein.

Die zentrale Frage ist, ob für die installierte Bailey-Symphony-Software eine x86-kompatible OpenVMS-Version existiert.

Wenn der Softwareanbieter diese Anwendung nie für OpenVMS x86-64 veröffentlicht hat, bleibt die HMI durch die alleinige Migration des Betriebssystems nicht erhalten.

Standortentwickelte Programme können portierbar sein, wenn ihr Quellcode und ihre Build-Umgebung weiterhin verfügbar sind. Geschlossene kommerzielle Anwendungen können ohne Unterstützung des Herstellers normalerweise nicht neu erstellt werden.

Diese Route kann für kundenspezifische Datenserver, Historian-Systeme, Dienstprogramme, Berichte und Integrationsanwendungen, die neben der Symphony-HMI ausgeführt werden, dennoch praktikabel sein.

Es ist weniger wahrscheinlich, dass eine alte proprietäre Symphony-Bedienerumgebung ohne eine unterstützte Anwendungsversion erhalten werden kann.

Eine Bewertung der OpenVMS-x86-Migration sollte Folgendes ermitteln:

• Jede installierte ausführbare Datei und jedes Layered Product.

• Verfügbarer Quellcode und Build-Verfahren.

• Abhängigkeiten von Compilern und Laufzeitumgebungen.

• Datenbankprodukte und Dateiformate.

• Proprietäre Kommunikationsbibliotheken.

• Abhängigkeiten von Grafik- oder Fenstersystemen.

• Verfügbarkeit von Lizenzen für x86-64.

• Erforderliche Änderungen aufgrund von Architekturunterschieden.

• Annahmen zu Leistung und Timing.

Diese Route bietet langfristig größeres Potenzial als der Wechsel von Alpha auf eine andere eingestellte Hardwarearchitektur. Sie kann kompatible OpenVMS-Workloads auf unterstützte x86-Virtualisierungsinfrastrukturen bringen.

Sie sollte dennoch als Anwendungsmigrationsprojekt und nicht als Projekt zum Klonen von Datenträgern beschrieben werden.

Warum eine Itanium-Migration normalerweise eine Übergangslösung ist

OpenVMS wurde auch für HPE-Integrity-Server mit Itanium-Architektur veröffentlicht.

Migrationswerkzeuge und Engineering-Methoden für die Übertragung einiger Alpha-Anwendungen auf OpenVMS Integrity sind vorhanden. Damit gab es einst einen unterstützten Weg weg von veralteter Alpha-Hardware.

Heute ist die Itanium-Hardware jedoch selbst eine Legacy-Plattform.

Ein Wechsel von Alpha zu Integrity kann zwar eine veraltete Hardwareabhängigkeit beseitigen, zugleich aber eine andere schaffen. Geeignete Server, Ersatzteile, Speicherschnittstellen und spezialisiertes Fachwissen werden weiterhin immer schwerer verfügbar sein.

Itanium kann weiterhin relevant sein, wenn ein Standort bereits über unterstützte Integrity-Infrastruktur verfügt. Es kann auch relevant sein, wenn ein erforderliches Layered Product für Integrity, nicht aber für x86-64 verfügbar ist.

Bei einem neuen Modernisierungsprojekt sollte diese Option im Allgemeinen als Zwischenlösung zur Sicherstellung der Kompatibilität bewertet werden.

Die geschäftliche Begründung muss erläutern, warum der Wechsel zu Integrity gegenüber einer Alpha-Emulation, einer OpenVMS-x86-Migration oder einer Neuplattformierung der HMI vorzuziehen ist.

Die OPC-Neuplattformierung erhält die Steuerungsebene

Die OPC-Neuplattformierung ersetzt die Bedienoberfläche und behält dabei die vorhandenen INFI-90-Controller und die Feld-I/O bei.

Ein Kommunikationsserver verbindet sich mit dem Bailey-System und stellt Prozess-Tags für eine moderne HMI- oder SCADA-Plattform bereit.

Das neue HMI übernimmt Anzeigen, Alarme, Trends, Sicherheit, Bedienerbefehle, Berichte und Arbeitsplatzdienste.

Dieser Weg beseitigt die Abhängigkeit von der ursprünglichen Symphony-Bedienanwendung. Außerdem entfällt die Notwendigkeit, OpenVMS Alpha auf den neuen Bedienerstationen auszuführen.

Die Architektur umfasst üblicherweise:

• Vorhandene Bailey-INFI-90-Controller und I/O.

• Eine kompatible Bailey-Kommunikationsschnittstelle.

• Ein OPC-DA-, OPC-UA- oder herstellerspezifischer Datenserver.

• Eine moderne HMI- oder SCADA-Plattform.

• Bediener- und Engineering-Arbeitsplätze.

• Optionale Historian-, Reporting- und Alarmanalysedienste.

In einem in den Ausgangsmaterialien genannten Praxisbeispiel wurde ein RoviSys-OPC-Server mit GE CIMPLICITY eingesetzt. Das berichtete System lief erfolgreich, allerdings mussten die Bedieneranzeigen und die Animationslogik neu erstellt werden.

Dieses Beispiel sollte nicht als automatische Produktempfehlung für jede INFI-90-Installation verstanden werden.

Der ausgewählte Server muss das spezifische Bailey-Netzwerk, die Kommunikationsmodule, die Controllergeneration, die Anzahl der Tags, die Aktualisierungsrate, die Redundanzanforderungen und die Befehlsfunktionen am jeweiligen Standort unterstützen.

Dasselbe gilt für die HMI-Plattform.

GE CIMPLICITY ist eine mögliche unternehmensweite HMI-/SCADA-Plattform. Auch andere Systeme können geeignet sein, sofern sie die erforderliche OPC-Anbindung, Grafiken, Alarme, Skripterstellung, Redundanz, Sicherheit und Unterstützung über den gesamten Lebenszyklus bieten.

Abbildung 2. Eine OPC-basierte Migration erhält die INFI-90-Steuerungsebene und ersetzt gleichzeitig die veraltete Symphony-Bedienumgebung.

Die OPC-Anbindung konvertiert vorhandene Bildschirme nicht

Ein OPC-Server stellt die Datenanbindung bereit. In der Regel konvertiert er alte HMI-Anzeigen nicht in ein neues HMI-Format.

Die ursprünglichen Symphony-Bildschirme können statische Grafiken, dynamische Symbole, Farbänderungen, numerische Werte, Balkendiagramme, Alarmanzeigen, Navigationsschaltflächen, Befehlssteuerungen, Trends und benutzerdefinierte Funktionsvorlagen enthalten.

Diese Elemente müssen im Ziel-HMI neu erstellt werden.

Einfache Anzeigen können direkt neu gezeichnet werden. Komplexe Anzeigen können verborgene Skripte oder Ausdrücke enthalten, die nicht sofort sichtbar sind.

Ingenieure müssen verstehen, wie jedes animierte Objekt seine Daten bezieht und verarbeitet.

Ein Ventilsymbol folgt möglicherweise nicht einfach einem einzigen Ausgangs-Tag. Seine Farbe und Position können von der Rückmeldung „offen“, der Rückmeldung „geschlossen“, dem Befehlszustand, dem Verriegelungsstatus, der Kommunikationsqualität und dem Gerätemodus abhängen.

Ein Motorsymbol kann separate Tags für den Startbefehl, die Laufmeldung, den Stillstand, die Auslösung, die lokale Steuerung, den Wartungszustand, Freigabebedingungen und die Alarmsperre verwenden.

Die alleinige Übertragung der sichtbaren Grafiken kann daher zu einem HMI führen, das korrekt aussieht, aber fehlerhaft funktioniert.

Das Migrationsteam muss die funktionale Bedeutung hinter jedem Anzeigeelement dokumentieren.

Diese Arbeiten umfassen:

• Zuordnen jedes dynamischen Objekts zu seiner Datenquelle.

• Neuerstellen von Animationsausdrücken.

• Überprüfen der Befehlsbestätigung und Sicherheit.

• Neuerstellen der Navigation und Anzeigehierarchien.

• Neuerstellen von Alarmklassen und Prioritäten.

• Bestätigen von technischen Einheiten und Dezimalgenauigkeit.

• Neuerstellen historischer und echtzeitbasierter Trends.

• Testen ungültiger, unsicherer und unterbrochener Kommunikationszustände.

• Nachbilden von Bedienermeldungen und Anleitungen.

• Ersetzen nicht unterstützter Schriftarten und Symbole.

Der Aufwand wird daher durch die Komplexität der Anzeigen bestimmt, nicht nur durch deren Anzahl.

Ein modernes HMI sollte nicht blind jede alte Anzeige kopieren

Die manuelle Neuerstellung bietet die Möglichkeit, die Bedienerschnittstelle zu verbessern.

Ältere HMI-Grafiken verwenden häufig leuchtende Farben für den Normalzustand von Geräten, dichte Prozessdiagramme, dekorative Rohrleitungen und uneinheitliche Alarmanzeigen.

Diese Konventionen mögen bei der Entwicklung des ursprünglichen Systems sinnvoll gewesen sein. Für heutige Leitwartenpraktiken sind sie jedoch nicht immer ideal.

Ein Modernisierungsprojekt sollte Folgendes überprüfen:

• Anzeigehierarchie.

• Sichtbarkeit von Alarmen.

• Einheitlichkeit der Navigation.

• Darstellung des Gerätezustands.

• Verwendung von Farben.

• Zugänglichkeit von Trends.

• Anforderungen an die Bedienerreaktion.

• Bildschirmauflösung und Arbeitsplatzanordnung.

• Barrierefreiheit und Lesbarkeit.

Normale Betriebsbedingungen sollten visuell unaufdringlich bleiben. Kräftige Farben sollten abnormale Zustände kennzeichnen, die Aufmerksamkeit erfordern.

Bediener sollten von einer Anlagenübersicht zu einer betroffenen Einheit, einer Geräteansicht, einem Trend, einer Alarmliste und einer Diagnoseanzeige wechseln können, ohne übermäßig navigieren zu müssen.

Eine übermäßige Neugestaltung kann jedoch ein weiteres Risiko schaffen.

Bediener haben möglicherweise viele Jahre lang die ursprünglichen Bildschirme verwendet. Wenn in demselben Projekt jedes Symbol, jede Farbe und jeder Navigationspfad geändert wird, kann dies den Schulungsaufwand und das Risiko bei der Umstellung erhöhen.

Ein ausgewogener Ansatz bewahrt vertraute Prozessbeziehungen und verbessert zugleich die Alarmdarstellung und Navigation.

Die Extraktion von Tags muss als technisches Arbeitspaket behandelt werden

Das Ausgangsmaterial weist auf die Möglichkeit hin, Bailey-Tag-Daten nach CSV zu exportieren. Es enthält jedoch kein bestätigtes, universell gültiges Verfahren.

Daher sollte nicht davon ausgegangen werden, dass ein einziger Exportbefehl eine vollständige, bereinigte HMI-Datenbank erzeugt.

Mögliche Quellen für Tag-Informationen sind:

• Symphony-Konfigurationsdatenbanken.

• Vorhandene Anzeigedefinitionen.

• Controllerkonfiguration und technische Unterlagen.

• Datenbanken der Bailey-Kommunikationsserver.

• OPC-Server-Browsing-Funktionen.

• Alarmkonfigurationsdateien.

• Historische Datenbanken.

• Gedruckte oder archivierte Tag-Listen.

• Technische Standorttabellen.

Das OPC-Browsing kann einen praktikablen Ausgangspunkt bieten, sobald der Server die Kommunikation mit dem Bailey-System hergestellt hat.

Er kann Tagnamen, Elementkennungen, Beschreibungen, Qualität und aktuelle Werte bereitstellen. Einige Server unterstützen außerdem den Export des durchsuchten Namespace.

Ein OPC-Namespace enthält jedoch möglicherweise nicht jedes Feld, das die neue HMI benötigt.

Alarmprioritäten, technische Grenzwerte, Anzeigegruppierungen, Bedienerhinweise, Befehlssicherheit und Anlagenbeziehungen können an anderer Stelle gespeichert sein.

Einige OPC-Server stellen Tags unter generierten Namen bereit, die von den ursprünglichen Symphony-Namen abweichen.

Das Projekt sollte ein kontrolliertes Tag-Master mit mindestens folgenden Angaben erstellen:

• Ursprünglicher Tagname.

• Neuer HMI-Tagname.

• OPC-Elementkennung.

• Beschreibung.

• Datentyp.

• Lese- oder Schreibberechtigung.

• Technische Einheiten.

• Skalierungsinformationen.

• Alarmgrenzen und Priorität.

• Aktualisierungsrate.

• Zugehörige Anzeige.

• Validierungsstatus.

• Testergebnis.

Dieses Master wird zum Abgleichsdatensatz zwischen dem alten und dem neuen System.

Die Tag-Anzahl ist nicht die einzige Kommunikationsanforderung

Ein erfolgreicher Browsing-Test beweist nicht, dass die OPC-Architektur die vollständige HMI unterstützen kann.

Ingenieure müssen die Anzahl aktiver Tags, die angeforderte Aktualisierungsrate, die Änderungshäufigkeit, die Alarmaktivität, den Befehlsverkehr und die Serverredundanz bewerten.

Ein System kann Zehntausende konfigurierte Tags enthalten. Zu einem bestimmten Zeitpunkt ist möglicherweise nur ein Teil davon auf den Bedieneranzeigen aktiv.

Der Server und die HMI sollten unter realistischen Bedingungen getestet werden.

Wichtige Leistungsprüfungen umfassen:

• Zeit zum Öffnen einer komplexen Anzeige.

• Verzögerung zwischen einer Feldänderung und der HMI-Animation.

• Alarmübermittlung während Ereignisspitzen.

• Trendaufzeichnung mit der erforderlichen Abtastrate.

• Zeit für die Befehlsausführung und Rückmeldung.

• Wiederherstellung nach einer Netzwerkunterbrechung.

• Umschaltung zwischen redundanten Servern.

• Verhalten nach einem Neustart des Controllers.

• Qualitätsstatus während eines Kommunikationsfehlers.

• CPU-, Speicher- und Netzwerkauslastung.

Befehle erfordern besondere Aufmerksamkeit.

Das Lesen von Werten über OPC kann relativ unkompliziert sein. Das sichere Schreiben von Werten erfordert Zugriffskontrolle, Befehlsvalidierung, Bestätigung der Rückmeldung und den korrekten Umgang mit Kommunikationsfehlern.

Das Team sollte jeden Typ von Bedienerbefehl testen, nicht nur ein repräsentatives Tag.

ABB Symphony Plus bietet einen umfassenderen Entwicklungspfad.

Ein OPC-Ersatz ist nicht der einzige Weg für ein installiertes Bailey-System.

ABB positioniert Symphony Plus weiterhin als Weiterentwicklungsplattform für ältere Bailey-, INFI-90-, Harmony-Rack- und Symphony-Installationen.

Eine schrittweise ABB-Modernisierung kann Teile der installierten Steuerungs- und E/A-Architektur erhalten und gleichzeitig modernere Bedien-, Engineering-, Netzwerk-, Steuerungs- oder E/A-Komponenten einführen.

Dieser Weg kann attraktiv sein, wenn die Organisation eine vom Anbieter unterstützte Lebenszyklusstrategie statt eines unabhängigen HMI-Austauschs anstrebt.

Das Projekt kann zunächst die Bedienumgebung modernisieren. Steuerungen und E/A können weiter betrieben werden, bis ihr Lebenszyklus oder ihr betrieblicher Nutzen einen Austausch rechtfertigt.

Spätere Phasen können Kommunikation, Steuerungen, Engineering-Tools und Feldschnittstellen umfassen.

Die genaue Migrationsarchitektur hängt von der installierten Systemgeneration ab.

Bei Installationen von Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony und Symphony Plus kommen nicht überall dieselben Schnittstellen zum Einsatz.

Modulnamen und Netzwerkterminologie müssen anhand von Anlagenzeichnungen und Hardwareinventaren überprüft werden.

Organisationen, die die bestehende Steuerungsebene betreiben, können bei der Planung der Ersatzteilabdeckung, der Unterstützung über den Lebenszyklus und einer schrittweisen Modernisierung auch die verfügbaren ABB Bailey INFI 90- und Network-90-Komponenten prüfen.

Dieser interne Link ist relevant, da Modernisierungsprojekte häufig erfordern, dass das alte System während Engineering, Tests und einer schrittweisen Umschaltung weiter betrieben wird.

Die Vorhaltung geeigneter Ersatzsteuerungen, Kommunikationsmodule, Netzteile und E/A-Module kann das Risiko während dieses Übergangs verringern.

Eine maßgeschneiderte oder Open-Source-HMI ist möglich, erfordert jedoch Eigenverantwortung

Eine maßgeschneiderte HMI kann mithilfe von Open-Source- oder kommerziellen Software-Frameworks entwickelt werden.

Das Ausgangsmaterial erwähnt einen VMS-residenten Server mit einem modernen Qt-basierten Client. Architekturen dieser Art können die serverseitige Datenverbindung vom Bediener-Client trennen.

Dieser Weg kann Flexibilität bieten und die Abhängigkeit von einem einzelnen HMI-Anbieter vermeiden.

Dies kann auch zu einer langfristigen Verpflichtung zur Softwareentwicklung werden.

Die Organisation muss Folgendes besitzen oder betreiben:

• Der Kommunikationsserver.

• Tag-Datenbank.

• Client-Anwendung.

• Grafik-Framework.

• Alarmverarbeitung.

• Historian-Integration.

• Benutzerauthentifizierung.

• Cybersicherheits-Updates.

• Bereitstellung und Versionsverwaltung.

• Dokumentation und Schulung.

Mit Qt, Python, C++, Webtechnologien oder anderen Frameworks lassen sich leistungsfähige industrielle Bedienoberflächen erstellen. Die Schwierigkeit besteht nicht darin, eine Prozessgrafik zu zeichnen.

Die Schwierigkeit besteht darin, ein zuverlässiges Bedienersystem zu entwickeln, das sich bei Kommunikationsausfällen, Serverneustarts, Alarmfluten, Benutzeränderungen und anomalen Anlagenzuständen korrekt verhält.

Eine maßgeschneiderte Plattform sollte nur ausgewählt werden, wenn die Organisation über ein nachhaltiges Engineering-Team oder einen zuverlässigen Integrator für die langfristige Betreuung verfügt.

Die Lizenzierung kann entscheidend dafür sein, ob ein technischer Migrationspfad praktikabel ist.

Ältere Industriesoftware verwendet häufig Lizenzierungsmechanismen, die an Hardwarekennungen, Ethernet-Adressen, Lizenzdatenbanken, Dongles oder vom Anbieter ausgestellte Autorisierungsschlüssel gebunden sind.

Ein geklontes System kann zwar korrekt starten, aber den Start der Symphony-Anwendung verweigern, weil sich die Identität der virtuellen Hardware geändert hat.

Das Migrationsinventar sollte Folgendes umfassen:

• Lizenzen für das OpenVMS-Betriebssystem.

• Lizenzen für Bailey-Symphony-Anwendungen.

• Datenbanklizenzen.

• Netzwerk- und Kommunikationslizenzen.

• Emulatorlizenzen.

• HMI- und OPC-Punktzähllizenzen.

• Historian-Lizenzen.

• Redundanzoptionen.

• Lizenzen für Engineering-Clients.

• Lizenzen für Laufzeit-Clients.

Vor der Auswahl der endgültigen Plattform sollte eine schriftliche Bestätigung eingeholt werden.

Technische Kompatibilität ohne rechtlich verfügbare Lizenzen ergibt keine einsetzbare Lösung.

Cybersicherheit muss in den Ersatz integriert werden

Alte AlphaStation-Systeme wurden häufig installiert, bevor moderne Praktiken für industrielle Cybersicherheit zum Standard wurden.

Sie können in isolierten Netzwerken mit eingeschränktem Fernzugriff betrieben werden. Ihr Ersatz durch Windows-Server, moderne SCADA-Clients, OPC-Server und Ethernet-Infrastruktur verändert die Angriffsfläche.

Die neue Architektur sollte separate Netzwerkzonen für Steuerung, Server, Engineering und Unternehmensnetzwerk definieren.

Firewalls sollten nur erforderliche Kommunikationspfade zulassen. Der Fernzugriff sollte eine verwaltete Authentifizierung und Aufzeichnung verwenden.

Für Bedienerkonten sollten rollenbasierte Berechtigungen gelten. Engineering-Funktionen sollten nicht von jedem HMI-Client aus verfügbar sein.

Der OPC-Schreibzugriff sollte auf die Tags und Stationen beschränkt werden, die ihn benötigen.

Das Design sollte außerdem Folgendes berücksichtigen:

• Patches für das Betriebssystem.

• Virenschutz oder Anwendungskontrolle.

• Sicherung und Wiederherstellung.

• Zeitsynchronisierung.

• Sicherheitsprotokollierung.

• Kontrollen für Wechselmedien.

• Fernsupport durch den Anbieter.

• Zertifikatsverwaltung für OPC UA.

• Verwaltung des Kontenlebenszyklus.

Cybersicherheitskontrollen dürfen Bediener nicht daran hindern, während Anlagenereignissen zu reagieren. Das Design sollte Schutz, Verfügbarkeit und deterministisches Verhalten ausgewogen berücksichtigen.

Die Migration sollte mit einem evidenzbasierten Inventar beginnen

Vor der Auswahl eines Migrationspfads sollten die Ingenieure das bestehende System detailliert dokumentieren.

Das Inventar sollte alle vier AlphaStations umfassen und feststellen, ob ihre Konfigurationen tatsächlich identisch sind.

Dokumentation:

• AlphaStation-Modell und Prozessorkonfiguration.

• Speicherkapazität.

• Festplattentyp und logische Volumes.

• OpenVMS-Version und Patchstand.

• Installierte Bailey-Softwareversionen.

• Geschichtete Produkte und Datenbanken.

• Grafikhardware und Bildschirmauflösung.

• Netzwerkadapter.

• Serielle Schnittstellen.

• Bailey-Kommunikationshardware.

• Knotennamen und Adressen.

• Verfahren für Startbefehle.

• Lizenzdateien.

• Sicherungsverfahren.

• Redundanz der Bedienerstationen.

• Angeschlossene Drucker und externe Geräte.

• Aufbewahrung historischer Daten und Alarmdaten.

Das Team sollte außerdem Screenshots jeder Anzeige erfassen. Dynamische Zustände sollten nach Möglichkeit aufgenommen werden.

Erfassen Sie die Zustände „normal“, „gestoppt“, „in Betrieb“, „Alarm“, „gesperrt“, „lokal“, „manuell“, „automatisch“ und „Kommunikationsfehler“.

Diese Nachweise sind unerlässlich, wenn die neuen Bildschirme getestet werden.

Ein Prüfstandsystem ist obligatorisch

Kein Modernisierungspfad sollte erstmals auf dem Live-Produktionssystem getestet werden.

Eine Prüfstandumgebung sollte genügend Elemente der installierten Architektur nachbilden, um Kommunikation und Bedienerfunktionen zu validieren.

Bei einem Emulatorprojekt sollte der Prüfstand eine geklonte OpenVMS-Alpha-Umgebung und die vorgeschlagene Emulatorkonfiguration enthalten.

Bei einem OPC-Projekt sollte er den ausgewählten Kommunikationsserver, die HMI-Software, repräsentative Grafiken und Zugriff auf einen sicheren Bailey-Testknoten oder eine simulierte Datenquelle umfassen.

Der Prüfstand sollte Folgendes verifizieren:

• Systemstart und Start der Anwendung.

• Kommunikation mit dem Bailey-System.

• Gesamtzahl der zugänglichen Tags.

• Lese- und Schreibvorgänge.

• Skalierung der Tags und technischen Einheiten.

• Alarmerzeugung und -quittierung.

• Trendaufzeichnung.

• Anzeigeanimation.

• Befehlssicherheit.

• Drucker- und Berichtsfunktionen.

• Verhalten beim Neustart des Servers.

• Verhalten bei Netzwerkausfall.

• Redundanz und Failover.

• Wiederherstellung aus der Sicherung.

• Reaktionszeit des Bedieners.

Die Testergebnisse sollten von Vertretern des Betriebs, der Regelungstechnik, der Instandhaltung und der Cybersicherheit beobachtet werden.

Parallelbetrieb reduziert das Umstellungsrisiko

Die ursprünglichen AlphaStations sollten während der ersten Einführung des Ersatzsystems verfügbar bleiben.

Die neue HMI kann parallel betrieben werden, während Ingenieure Werte, Alarme, Trends und Befehle vergleichen.

Der Parallelbetrieb ermöglicht es, Abweichungen zu erkennen, bevor die Legacy-Station entfernt wird.

Das Team sollte abgleichen:

• Angezeigte Prozesswerte.

• Statusanzeigen.

• Alarmprioritäten.

• Alarmzeitstempel.

• Befehlsergebnisse.

• Trendwerte.

• Anlagenmodus.

• Kommunikationsqualität.

• Sicherheitsberechtigungen.

Nicht jede Abweichung stellt einen Fehler dar. Das neue System kann eine verbesserte Skalierung oder Alarmdarstellung verwenden.

Jede Abweichung sollte dennoch erklärt und genehmigt werden.

Die Legacy-Stationen sollten wiederherstellbar bleiben, bis die neue HMI einen vor Ort beobachteten Abnahmetest und einen vereinbarten Betriebszeitraum bestanden hat.

Den richtigen Migrationspfad auswählen

Wählen Sie die Alpha-Emulation, wenn:

Die bestehende Symphony-Anwendung muss unverändert bleiben. Der Quellcode ist nicht verfügbar. Die Bediengrafiken sind komplex. Der Umschulungsaufwand muss minimiert werden. Die Bailey-Kommunikationsschnittstelle kann von der Emulatorarchitektur unterstützt werden.

Wählen Sie die OpenVMS-x86-Migration, wenn:

Die erforderlichen Anwendungen sind für x86-64 verfügbar oder können neu erstellt werden. Quellcode und technisches Fachwissen sind weiterhin verfügbar. Die Organisation möchte OpenVMS beibehalten und gleichzeitig auf eine unterstützte x86-Umgebung umsteigen.

Wählen Sie eine OPC-Neuplattformierung, wenn:

Der INFI-90-Controller und die I/O-Ebenen weiterhin zuverlässig sind. Die Organisation eine moderne HMI-Plattform wünscht. Engineering-Ressourcen für die Neuerstellung und Validierung von Anzeigen, Alarmen, Tags und Befehlslogik verfügbar sind.

Wählen Sie einen ABB-Evolutionspfad, wenn:

Die Organisation ein umfassenderes, herstellerunterstütztes Modernisierungsprogramm anstrebt. Künftige Phasen können Bedienersysteme, Engineering-Tools, Netzwerkschnittstellen, Controller und I/O umfassen.

Wählen Sie eine kundenspezifische HMI, wenn:

Die Organisation spezielle Anforderungen hat und eine langfristige Entwicklung, Erprobung, Cybersicherheit und Lebenszykluswartung der Software unterstützen kann.

Behalten Sie das bestehende System vorübergehend bei, wenn:

Die Migrationsschnittstellen sind weiterhin unklar. Die Sicherungen sind unvollständig. Die Lizenzierung ist ungeklärt. Tag-Datenbanken sind nicht verfügbar. Mit Tests am Prüfstand lässt sich der Bailey-Kommunikationspfad derzeit nicht nachbilden.

Ein praxisorientierter, phasenweiser Modernisierungsplan

Phase 1: Die bestehende Umgebung bewahren.

Erstellen Sie verifizierte Image-Sicherungen jeder AlphaStation. Erfassen Sie Hardware-, Software-, Netzwerk-, Lizenzierungs- und Startdetails. Testen Sie die Wiederherstellung, wo immer möglich.

Phase 2: Die Kommunikationsarchitektur ermitteln.

Dokumentieren Sie genau, wie jede Symphony-Station mit INFI 90 kommuniziert. Bestätigen Sie, ob die Schnittstelle emuliert oder durch einen unterstützten Server ersetzt werden kann.

Phase 3: Einen Machbarkeitsnachweis erstellen.

Testen Sie eine geklonte Station in einem Alpha-Emulator oder verbinden Sie einen OPC-Server mit einem repräsentativen Bailey-Knoten.

Phase 4: Den Tag-Stammdatensatz erstellen.

Gleichen Sie Controller-Tags, OPC-Elementkennungen, technischen Einheiten, Befehle, Alarme und die Anzeigenverwendung ab.

Phase 5: Repräsentative Anzeigen neu erstellen.

Wählen Sie mehrere Bildschirme mit unterschiedlichen Anforderungen an Animationen, Alarme, Befehle und Trends aus.

Phase 6: Die Abnahme am Prüfstand abschließen.

Testen Sie das vollständige Laden der Tags, Kommunikationsausfälle, den Neustart des Servers, Alarmspitzen, das Befehlsverhalten und die Wiederherstellung aus Sicherungen.

Phase 7: Parallel bereitstellen.

Betreiben Sie die neue und die alte HMI gemeinsam. Vergleichen Sie Werte und Bedienerreaktionen.

Phase 8: Die Umschaltung unter Beobachtung durchführen.

Verwenden Sie ein genehmigtes Testverfahren. Halten Sie die AlphaStations als Ausweichlösung verfügbar.

Phase 9: Veraltete Hardware schrittweise außer Betrieb nehmen.

Zerstören Sie die ursprünglichen Abbilder, Konfigurationsunterlagen, Lizenzen oder die Hardware nicht, bevor die langfristige Abnahme abgeschlossen ist.

Häufig gestellte Fragen

Kann der Datenträger einer OpenVMS AlphaStation direkt auf einen modernen PC geklont werden?

Nein. Das Abbild enthält Alpha-Maschinencode und setzt Alpha-kompatible Hardware voraus. Ein moderner x86-PC kann es nicht direkt booten. Das Abbild muss auf kompatibler Alpha-Hardware oder in einem Alpha-Emulator wiederhergestellt werden.

Können VMware oder VirtualBox OpenVMS ausführen?

Sie können unterstützte OpenVMS-x86-64-Versionen ausführen. Sie wandeln keine alte OpenVMS-Alpha-Installation in eine x86-Anwendung um. OpenVMS Alpha erfordert eine Alpha-Emulation.

Können die ursprünglichen Symphony-Anzeigen erhalten bleiben?

Sie können in der Regel erhalten bleiben, wenn die vollständige Alpha-Umgebung unter einem kompatiblen Emulator ausgeführt wird. Bei einem Wechsel auf eine andere HMI-Plattform müssen sie normalerweise manuell neu erstellt werden.

Exportiert ein OPC-Server automatisch jedes Bailey-Tag?

Nicht unbedingt. Das OPC-Browsing kann einen nützlichen Namensraum bereitstellen, doch Alarmkonfiguration, Anzeigebeziehungen, Befehle, Beschreibungen und technische Metadaten können eine zusätzliche Extraktion und Abstimmung erfordern.

Ist GE CIMPLICITY die einzige Ersatz-HMI?

Nein. Es ist eine mögliche Plattform und wird im mit der Quelle bereitgestellten Praxisbeispiel erwähnt. Die endgültige Auswahl sollte von Kommunikationsunterstützung, Redundanz, Lizenzierung, Cybersicherheit, technischen Ressourcen und den Anforderungen der Bediener abhängen.

Lohnt sich die Migration von Alpha zu Itanium noch?

Das kann gerechtfertigt sein, wenn die benötigte Software nur für Integrity-Systeme verfügbar ist oder die vorhandene Integrity-Infrastruktur bereits unterstützt wird. Im Allgemeinen handelt es sich eher um einen Übergangspfad als um die überzeugendste langfristige Modernisierungsstrategie.

Können die INFI-90-Steuerungen und die E/A installiert bleiben?

Ja, sofern sie weiterhin zuverlässig sind und die ausgewählte Kommunikationsarchitektur sie unterstützt. Die HMI-Modernisierung kann getrennt vom Austausch der Steuerungen und E/A abgeschlossen werden.

Sollten die alten AlphaStations unmittelbar nach der Umschaltung entfernt werden?

Nein. Sie sollten als getestete Rückfallebene verfügbar bleiben, bis die neue Bedienerumgebung die funktionale, leistungsbezogene und betriebliche Abnahme bestanden hat.

Die richtige Lösung hängt davon ab, was erhalten bleiben muss

Der wichtigste technische Fehler bei vielen Legacy-HMI-Plänen besteht darin, die Bedienerstation wie einen gewöhnlichen PC zu behandeln.

Eine AlphaStation mit OpenVMS Alpha und Bailey Symphony ist eine vollständige Hard- und Softwareumgebung. Prozessorarchitektur, Betriebssystem, Kommunikationsschnittstellen, Anwendungsbinärdateien, Lizenzen, Grafiken und Verbindungen zum Steuerungssystem sind voneinander abhängig.

Ein Festplattenklon bewahrt die Daten. Er übersetzt diese Umgebung jedoch nicht auf eine andere Architektur.

Die Alpha-Emulation bietet den direktesten Weg, wenn die vollständige Symphony-Installation unverändert erhalten bleiben muss.

OpenVMS x86-64 bietet einen modernen Betriebssystempfad, wenn Anwendungen migriert oder neu erstellt werden können.

Eine OPC-Neuimplementierung bietet einen praktikablen Weg, wenn die INFI-90-Steuerungsebene weiterhin wertvoll ist, die Bedienerebene jedoch ersetzt werden soll.

Die Weiterentwicklung von ABB Symphony Plus kann eine umfassendere schrittweise Strategie bieten, wenn das Unternehmen über die Modernisierung der HMI hinausgehen möchte.

Die endgültige Entscheidung sollte auf einem verifizierten Inventar, einer Untersuchung der Kommunikationsschnittstellen, einer Lizenzprüfung, einem Proof of Concept, einem Test am Prüfstand und einer unter Zeugen durchgeführten betrieblichen Abnahme beruhen.

Es gibt keinen Austausch ohne Aufwand. Es gibt jedoch mehrere kontrollierte Migrationspfade, die die bestehende Investition in die Prozesssteuerung schützen und gleichzeitig die Abhängigkeit von veralteter AlphaStation-Hardware beseitigen können.