Modernizace HMI systémů Bailey INFI 90 Symphony běžících na OpenVMS Alpha

Modernizace HMI bez nahrazení celého systému INFI 90

Mnoho systémů Bailey INFI 90 nadále spolehlivě funguje desítky let po původní instalaci. Jejich řídicí systémy, komunikační moduly, zakončovací jednotky a polní I/O mohou stále plnit požadované řídicí funkce.

Nejbezprostřednější problém životního cyklu se často nachází nad vrstvou řídicích systémů.

Stanice operátorů mohou záviset na stárnoucím hardwaru AlphaStation, nepodporovaných grafických adaptérech, zastaralých úložných zařízeních a starých softwarových prostředích OpenVMS Alpha. Náhradní díly se shánějí stále obtížněji a zkušených odborníků na OpenVMS a Bailey Symphony je stále méně.

Zde zvažovaný příklad zahrnuje čtyři pracovní stanice AlphaStation 255. Každá stanice používá OpenVMS Alpha a hostuje funkce rozhraní operátora Bailey Symphony pro distribuovaný řídicí systém Bailey INFI 90.

Cílem nemusí být nutně nahradit celý DCS. Praktičtějším cílem je odstranit závislost na stárnoucím hardwaru AlphaStation a současně zachovat stabilní řídicí systémy, polní kabeláž, moduly I/O, řídicí logiku a provoz technologického procesu.

Toto rozlišení mění strategii modernizace.

Projekt je primárně migrací rozhraní operátora a výpočetní platformy. Plnou migrací DCS se stává teprve tehdy, když životní cyklus řídicích systémů, požadavky na kybernetickou bezpečnost, výrobní cíle nebo podmínky podpory odůvodňují nahrazení nižších řídicích vrstev.

Existuje několik možných cest modernizace. Každá z nich však zachovává jiné části stávajícího systému.

Emulátor Alpha může zachovat téměř kompletní softwarové prostředí. Migrace na OpenVMS x86 zachovává rodinu operačních systémů, ale vyžaduje migraci aplikací. Náhrada HMI založená na OPC zachovává vrstvu řídicích systémů a současně znovu vytváří rozhraní operátora. Strategie vývoje ABB může postupně modernizovat širší architekturu Symphony.

Žádnou z těchto cest nelze popsat jako prostou náhradu počítačů PC.

Obrázek 1. Tři hlavní cesty modernizace mohou zachovat různé části investic do nainstalovaných systémů Bailey INFI 90 a Symphony.

Proč samotné klonování disku AlphaStation nestačí

Klonování disku je užitečné pro zachování nainstalovaného prostředí OpenVMS Alpha. Může zachytit operační systém, soubory aplikací, konfiguraci zařízení, uživatelské účty, software Bailey, databáze, grafiku a nastavení specifická pro daný provoz.

Klonování disku však nepřevádí software Alpha na software x86.

Klonovaný operační systém stále obsahuje instrukce procesoru Alpha. Jeho jádro, zaváděcí program, systémové knihovny, aplikace a hardwarové ovladače byly vytvořeny pro architekturu Alpha.

Běžný moderní počítač používá procesor x86-64. Nabízí také jiné řadiče úložišť, síťová zařízení, struktury přerušení, grafický hardware, rozhraní firmwaru a sběrnice periferií.

VMware, VirtualBox, Hyper-V a běžné hypervizory x86 virtualizují hardware kompatibilní s x86. Obvykle nepřekládají instrukce procesoru Alpha na instrukce x86.

Umístění obrazu disku OpenVMS Alpha do běžného virtuálního počítače x86 proto neznamená, že z něj lze zavést systém.

Virtuální počítač může poskytovat virtuální disk, virtuální síťový adaptér a virtuální grafické zařízení. OpenVMS Alpha však stále očekává procesor Alpha a podporovaná zařízení z éry Alpha.

Proto je nutné tyto dva pojmy rozlišovat:

Virtualizace obvykle poskytuje virtuální hardware využívající stejnou architekturu procesoru jako hostitel.

Emulace napříč architekturami reprodukuje jiný procesor a hardwarové prostředí v softwaru.

OpenVMS Alpha vyžaduje druhý přístup, když původní binární soubory pro Alpha a operační systém musí zůstat beze změn.

Klonování disků je proto proveditelné ve třech omezených situacích.

První možností je obnova do stejného modelu AlphaStation s kompatibilními úložišti a periferiemi.

Druhou možností je obnova do jiného podporovaného systému Alpha po provedení požadovaných změn zařízení a konfigurace.

Třetí možností je obnova do emulátoru Alpha, který reprodukuje kompatibilní prostředí AlphaServeru nebo AlphaStation.

Samotné klonování problém architektury neřeší. Cílové prostředí stále musí rozumět instrukcím stroje Alpha a umět je provádět.

Emulace Alpha zachovává největší část stávajících investic

Emulace Alpha je obvykle nejméně rušivou cestou, když stávající software Symphony musí zůstat provozuschopný bez změn zdrojového kódu.

Emulátor Alpha běží na moderním hardwaru x86, ale systému OpenVMS poskytuje virtuální systém Alpha. Původní operační systém a aplikace nadále pracují s hardwarovým prostředím kompatibilním s Alpha.

Produkty jako CHARON-AXP jsou k tomuto účelu určeny. Emulátor nahrazuje fyzický procesor Alpha, paměťovou architekturu, řadiče úložišť, ethernetové adaptéry a další podporovaná zařízení softwarově definovanými ekvivalenty.

Server x86 provozuje Windows nebo Linux jako hostitelské prostředí. Nad tímto hostitelským prostředím běží emulátor Alpha. OpenVMS Alpha pak běží uvnitř emulovaného systému Alpha.

Tento přístup se liší od portování OpenVMS na x86.

Původní instalace OpenVMS Alpha zůstává instalací pro Alpha. Binární soubory Bailey Symphony zůstávají binárními soubory pro Alpha. Emulátor překládá nebo reprodukuje požadované chování hardwaru Alpha.

To může zachovat:

• Nainstalovaný operační systém OpenVMS Alpha.

• Stávající aplikace Bailey Symphony.

• Grafika operátora a databáze obrazovek.

• Konfigurace alarmů a historické soubory.

• Uživatelské účty a příkazové procedury.

• Stávající nástroje specifické pro dané pracoviště.

• Rozhraní aplikace, která závisí na prostředí Alpha.

• Pracovní postupy operátorů, které by jinak vyžadovaly přeškolení.

Praktická migrace obvykle zahrnuje vytvoření ověřeného obrazu nebo zálohy původních disků Alpha. Tato data se obnoví do kontejnerů virtuálních disků používaných emulátorem.

Konfigurace emulátoru musí reprodukovat odpovídající vlastnosti procesoru, paměti, disků, sítě a periferií. Tým také možná bude muset prostřednictvím hostitelského systému namapovat fyzické sériové porty nebo síťová rozhraní.

Emulace Alpha může výrazně snížit závislost na zastaralém fyzickém hardwaru. Může také zjednodušit zálohování, protože soubory virtuálních disků lze kopírovat pomocí moderní infrastruktury úložiště.

Výraz „nulová změna“ je však třeba používat obezřetně.

Kód aplikace může zůstat beze změn, prostředí však stále vyžaduje technické řešení. Je nutné zkontrolovat mapování zařízení. Síťová rozhraní musí být nakonfigurována. Je třeba prověřit licence OpenVMS a licence aplikace.

Emulátor musí být také otestován s komunikačním rozhraním Bailey používaným na daném pracovišti.

Obecná aplikace OpenVMS může fungovat správně, zatímco specializované rozhraní DCS selže, protože závisí na konkrétním síťovém adaptéru, sběrnicovém rozhraní, sériovém zařízení nebo časování.

Přesnou konfiguraci stanice AlphaStation 255 je proto nutné inventarizovat před výběrem profilu emulátoru.

Rozhraní Bailey Communication Interface je kritickou zkouškou emulace

Nejdůležitější otázkou emulace není, zda OpenVMS dospěje k přihlašovací výzvě.

Důležitou otázkou je, zda emulovaná stanice správně komunikuje se systémem Bailey INFI 90 za plných provozních podmínek.

Rozhraní může záviset na Ethernetu, sériové komunikaci, síťovém rozhraní Bailey nebo specializovaném komunikačním hardwaru. Konfigurace jednotlivých pracovišť se mohou výrazně lišit.

Před rozhodnutím pro emulaci Alpha by měli technici zdokumentovat:

• Fyzické síťové rozhraní nainstalované v každé stanici AlphaStation.

• Komunikační protokol používaný mezi systémy Symphony a INFI 90.

• Názvy zařízení přiřazené v OpenVMS.

• Síťové adresy a definice uzlů.

• Požadované služby DECnet, TCP/IP, LAT nebo proprietární služby.

• Nastavení sériových portů, pokud je relevantní.

• Veškeré externí licenční klíče nebo hardwarové hardwarové klíče.

• Chování redundance a převzetí služeb mezi operátorskými stanicemi.

• Požadavky na synchronizaci času.

• Grafické a klávesnicové funkce používané operátory.

Dodavatel emulátoru může podporovat běžná zařízení Alpha Ethernet a úložiště. To však automaticky nepotvrzuje podporu každého proprietárního rozhraní Bailey.

Pokud stávající HMI závisí na specializovaném fyzickém adaptéru, který nelze virtualizovat, může emulace vyžadovat alternativní komunikační bránu.

Projekt by proto měl zahrnovat test na zkušebním pracovišti s klonovanou stanicí a přístupem k reprezentativní síti Bailey.

Test musí zahrnovat více než jen statické čtení tagů. Operátoři by měli ověřit hodnoty v reálném čase, příkazy, alarmy, potvrzování, trendy, navigaci v zobrazeních, tisk, zpracování událostí a obnovu stanice.

Výkon by měl být testován také během nárazového nárůstu alarmů a při vysoké aktivitě aktualizace tagů.

OpenVMS x86-64 představuje jinou migrační cestu

Moderní OpenVMS je dostupný pro architekturu x86-64. Může fungovat v podporovaných virtualizovaných prostředích na moderních serverech.

Tím vzniká další možnost migrace, která nebyla k dispozici při mnoha dřívějších diskusích o modernizaci INFI 90.

OpenVMS x86-64 však nespouští binární soubory OpenVMS Alpha přímo tak, jako by šlo o nativní aplikace pro x86.

Je nutné migrovat aplikační prostředí.

Zdrojový kód může být nutné přenést, zkontrolovat, znovu zkompilovat, slinkovat a otestovat pro x86-64. Pro cílovou verzi musí být dostupné také knihovny třetích stran a vrstvené produkty.

Zásadní otázkou je, zda má nainstalovaný software Bailey Symphony verzi OpenVMS kompatibilní s x86.

Pokud dodavatel softwaru danou aplikaci nikdy nevydal pro OpenVMS x86-64, samotný přesun operačního systému HMI nezachová.

Programy vyvinuté přímo na daném pracovišti mohou být přenositelné, pokud zůstane dostupný jejich zdrojový kód a prostředí pro sestavení. Uzavřené komerční aplikace obvykle nelze bez podpory dodavatele znovu sestavit.

Tato cesta může být stále praktická pro vlastní datové servery, historizační systémy, nástroje, sestavy a integrační aplikace, které běží vedle HMI Symphony.

Bez podporované verze aplikace je méně pravděpodobné, že se podaří zachovat staré proprietární operátorské prostředí Symphony.

Posouzení migrace OpenVMS na x86 by mělo identifikovat:

• Každý nainstalovaný spustitelný soubor a vrstvený produkt.

• Dostupný zdrojový kód a postupy sestavení.

• Závislosti na kompilátoru a běhovém prostředí.

• Databázové produkty a formáty souborů.

• Proprietární komunikační knihovny.

• Závislosti na grafice nebo okenním systému.

• Dostupnost licencí pro x86-64.

• Nezbytné změny způsobené rozdíly v architektuře.

• Předpoklady týkající se výkonu a časování.

Tato cesta má lepší dlouhodobý potenciál než přechod z platformy Alpha na jinou ukončenou hardwarovou architekturu. Umožňuje umístit kompatibilní úlohy OpenVMS na podporovanou virtualizační infrastrukturu x86.

Přesto by měla být popsána jako projekt migrace aplikace, nikoli jako projekt klonování disků.

Proč je migrace z Itanium obvykle přechodnou možností

OpenVMS byl vydán také pro servery HPE Integrity využívající architekturu Itanium.

Existují migrační nástroje a techniky pro přesun některých aplikací Alpha na OpenVMS Integrity. Tato možnost dříve představovala podporovanou cestu od stárnoucího hardwaru Alpha.

Dnes je však samotný hardware Itanium již zastaralou platformou.

Přechod z Alpha na Integrity může odstranit jednu závislost na zastaralém hardwaru a zároveň vytvořit jinou. Vhodné servery, náhradní díly, úložná rozhraní a specializované odborné znalosti budou nadále méně dostupné.

Itanium může být stále relevantní, pokud provoz již vlastní podporovanou infrastrukturu Integrity. Může být relevantní také tehdy, pokud pro Integrity existuje požadovaný vrstvený produkt, který není dostupný pro x86-64.

U nového modernizačního projektu by měl být tento přístup obecně posuzován jako mezilehlá kompatibilní cesta.

Obchodní zdůvodnění musí vysvětlit, proč je přechod na Integrity výhodnější než emulace Alpha, migrace OpenVMS na x86 nebo nové nasazení HMI.

Nové nasazení OPC zachovává řídicí vrstvu

Nové nasazení OPC nahrazuje vrstvu operátorského rozhraní a zachovává stávající řídicí jednotky INFI 90 a provozní I/O.

Komunikační server se připojuje k systému Bailey a zpřístupňuje procesní tagy moderní platformě HMI nebo SCADA.

Nové HMI zajišťuje obrazovky, alarmy, trendy, zabezpečení, příkazy operátora, reporty a služby pracovních stanic.

Tato cesta odstraňuje závislost na původní operátorské aplikaci Symphony. Zároveň odpadá nutnost provozovat OpenVMS Alpha na nových operátorských stanicích.

Architektura běžně zahrnuje:

• Stávající řídicí jednotky a I/O Bailey INFI 90.

• Kompatibilní komunikační rozhraní Bailey.

• Datový server OPC DA, OPC UA nebo server specifický pro daného dodavatele.

• Moderní platforma HMI nebo SCADA.

• Operátorské a inženýrské pracovní stanice.

• Volitelné služby historizace, reportingu a analýzy alarmů.

Příklad z provozu uvedený ve zdrojových materiálech využíval server OPC RoviSys s GE CIMPLICITY. Uváděný systém fungoval úspěšně, projekt však vyžadoval znovuvytvoření operátorských obrazovek a animační logiky.

Tento příklad nelze interpretovat jako automatické doporučení produktu pro každou instalaci INFI 90.

Vybraný server musí v daném provozu podporovat konkrétní síť Bailey, komunikační moduly, generaci řídicích jednotek, počet tagů, rychlost aktualizace, požadavky na redundanci a příkazové funkce.

Totéž platí pro platformu HMI.

GE CIMPLICITY je jednou z možných podnikových platforem HMI/SCADA. Vhodné mohou být i jiné systémy, pokud poskytují požadované připojení OPC, grafiku, alarmy, skriptování, redundanci, zabezpečení a podporu po dobu životního cyklu.

Obrázek 2. Migrace založená na OPC zachovává řídicí vrstvu INFI 90 a zároveň nahrazuje původní operátorské prostředí Symphony.

Připojení OPC nepřevádí stávající obrazovky

Server OPC zajišťuje datové připojení. Obvykle nepřevádí staré obrazovky HMI do nového formátu HMI.

Původní obrazovky Symphony mohou obsahovat statickou grafiku, dynamické symboly, změny barev, číselné hodnoty, sloupcové grafy, indikátory alarmů, navigační tlačítka, ovládací prvky příkazů, trendy a šablony vlastních funkcí.

Tyto prvky musí být znovu vytvořeny v cílovém HMI.

Jednoduchá zobrazení lze překreslit přímo. Složitá zobrazení mohou obsahovat skryté skripty nebo výrazy, které nejsou na první pohled viditelné.

Inženýři musí rozumět tomu, jak každý animovaný objekt získává a zpracovává svá data.

Symbol ventilu nemusí jednoduše sledovat jediný výstupní tag. Jeho barva a poloha mohou záviset na zpětné vazbě otevření, zpětné vazbě zavření, stavu příkazu, stavu blokování, kvalitě komunikace a režimu zařízení.

Symbol motoru může používat samostatné tagy pro příkaz ke spuštění, zpětnou vazbu chodu, stav zastavení, vypnutí z důvodu poruchy, místní ovládání, stav údržby, blokovací podmínky a potlačení alarmu.

Přenos pouze viditelné grafiky proto může vytvořit HMI, které vypadá správně, ale chová se nesprávně.

Migrační tým musí zdokumentovat funkční význam každého prvku zobrazení.

Tato práce zahrnuje:

• Namapování každého dynamického objektu na jeho zdroj dat.

• Obnovení animačních výrazů.

• Ověření potvrzování příkazů a zabezpečení.

• Obnovení navigace a hierarchií zobrazení.

• Obnovení tříd a priorit alarmů.

• Ověření technických jednotek a desetinné přesnosti.

• Obnovení historických a aktuálních trendů.

• Testování neplatných, nejistých stavů a stavů selhání komunikace.

• Reprodukce zpráv a pokynů pro operátory.

• Nahrazení nepodporovaných písem a symbolů.

Náročnost je proto určena složitostí zobrazení, nikoli pouze jejich počtem.

Moderní HMI by nemělo slepě kopírovat každé starší zobrazení

Ruční rekonstrukce vytváří příležitost ke zlepšení rozhraní pro operátory.

Starší grafika HMI často používá jasné barvy pro normální stav zařízení, hustá procesní schémata, dekorativní potrubí a nekonzistentní indikace alarmů.

Tyto konvence mohly být v době vývoje původního systému rozumné. Ne vždy jsou ideální pro současné postupy v řídicích místnostech.

Modernizační projekt by měl posoudit:

• Hierarchie zobrazení.

• Viditelnost alarmů.

• Konzistentní navigace.

• Zobrazení stavu zařízení.

• Použití barev.

• Přístupnost trendů.

• Požadavky na reakci operátora.

• Rozlišení obrazovky a uspořádání pracoviště.

• Přístupnost a čitelnost.

Normální provozní podmínky by měly zůstat vizuálně nenápadné. Výrazné barvy by měly označovat abnormální stavy vyžadující pozornost.

Operátoři by měli být schopni přejít z přehledu provozu na dotčenou jednotku, čelní panel zařízení, trend, historii alarmů a diagnostické zobrazení bez nadměrného navigování.

Nadměrný redesign však může vytvořit další riziko.

Operátoři mohli původní obrazovky používat mnoho let. Změna každého symbolu, barvy a navigační cesty během jediného projektu může zvýšit nároky na školení a riziko přechodu na nový systém.

Vyvážený přístup zachovává známé vazby mezi procesy a současně zlepšuje zobrazování alarmů a navigaci.

Extrakce tagů musí být považována za samostatný inženýrský pracovní balíček

Zdrojový materiál zmiňuje možnost exportu dat tagů Bailey do formátu CSV. Neposkytuje však potvrzený univerzální postup.

Proto nelze předpokládat, že jeden exportní příkaz vytvoří kompletní a čistou databázi HMI.

Mezi možné zdroje informací o tagech patří:

• Konfigurační databáze Symphony.

• Existující definice displejů.

• Konfigurace řídicích jednotek a technické záznamy.

• Databáze komunikačních serverů Bailey.

• Funkce procházení OPC serveru.

• Konfigurační soubory alarmů.

• Historické databáze.

• Vytištěné nebo archivované seznamy tagů.

• Tabulky technických údajů z lokality.

Procházení OPC může poskytnout praktický výchozí bod poté, co server naváže komunikaci se systémem Bailey.

Může zpřístupňovat názvy tagů, identifikátory položek, popisy, kvalitu a aktuální hodnoty. Některé servery také podporují export procházeného namespace.

Namespace OPC však nemusí obsahovat všechna pole potřebná pro nové HMI.

Priority alarmů, technické limity, seskupení displejů, poznámky operátorů, zabezpečení příkazů a vztahy mezi zařízeními mohou být uloženy jinde.

Některé OPC servery zpřístupňují tagy pomocí generovaných názvů, které se liší od původních názvů v Symphony.

Projekt by měl vytvořit řízený hlavní seznam tagů obsahující alespoň:

• Původní název tagu.

• Název tagu v novém HMI.

• Identifikátor položky OPC.

• Popis.

• Datový typ.

• Oprávnění ke čtení nebo zápisu.

• Technické jednotky.

• Informace o škálování.

• Alarmové limity a priorita.

• Rychlost aktualizace.

• Přidružený displej.

• Stav validace.

• Výsledek testu.

Tento hlavní seznam se stane záznamem pro porovnání starého a nového systému.

Počet tagů není jediným požadavkem na komunikaci

Úspěšný test procházení neprokazuje, že architektura OPC dokáže podporovat celé HMI.

Inženýři musí vyhodnotit počet aktivních tagů, požadovanou rychlost aktualizace, frekvenci změn, aktivitu alarmů, provoz příkazů a redundanci serveru.

Systém může obsahovat desítky tisíc nakonfigurovaných tagů. Na displejích operátorů může být současně aktivní pouze jejich část.

Server a HMI by měly být testovány v realistických podmínkách.

Mezi důležité kontroly výkonu patří:

• Doba potřebná k otevření komplexního displeje.

• Zpoždění mezi změnou v poli a animací v HMI.

• Doručování alarmů během nárazového výskytu událostí.

• Shromažďování trendů s požadovanou vzorkovací frekvencí.

• Doba provedení příkazu a odezvy.

• Obnovení po přerušení sítě.

• Přepnutí mezi redundantními servery.

• Chování po restartu řídicí jednotky.

• Stav kvality během výpadku komunikace.

• Vytížení CPU, paměti a sítě.

Příkazům je třeba věnovat zvláštní pozornost.

Čtení hodnot prostřednictvím OPC může být poměrně jednoduché. Bezpečný zápis hodnot vyžaduje řízení přístupu, validaci příkazů, potvrzení zpětné vazby a správné zpracování komunikačních chyb.

Tým by měl otestovat každý typ příkazu operátora, nikoli pouze jeden reprezentativní tag.

ABB Symphony Plus poskytuje širší cestu evoluce

Náhrada OPC není jedinou možností pro nainstalovaný systém Bailey.

ABB nadále prezentuje Symphony Plus jako evoluční platformu pro starší instalace Bailey, INFI 90, Harmony Rack a Symphony.

Postupná modernizace ABB může zachovat části nainstalované řídicí a I/O architektury a současně zavést novější operátorské, inženýrské, síťové, řídicí nebo I/O komponenty.

Tato cesta může být atraktivní, když organizace chce strategii životního cyklu podporovanou dodavatelem namísto nezávislé náhrady HMI.

Projekt může nejprve modernizovat operátorské prostředí. Řídicí jednotky a I/O mohou zůstat v provozu, dokud jejich životní cyklus nebo provozní přínos neodůvodní výměnu.

V pozdějších fázích lze řešit komunikaci, řídicí jednotky, nástroje pro projektování a rozhraní v provozu.

Přesná architektura migrace závisí na generaci nainstalovaného systému.

Instalace Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony a Symphony Plus nepoužívají všechny stejné rozhraní.

Názvy modulů a síťová terminologie musí být ověřeny podle výkresů instalace a inventur hardwaru.

Organizace, které udržují stávající řídicí vrstvu, mohou při plánování náhradních dílů, podpory po dobu životního cyklu a postupné modernizace také prověřit dostupné komponenty ABB Bailey INFI 90 a Network 90.

Tento interní odkaz je relevantní, protože modernizační projekty často vyžadují, aby starý systém zůstal v provozu během projektování, testování a postupného přechodu.

Udržování vhodných náhradních řídicích jednotek, komunikačních modulů, napájecích zdrojů a I/O modulů může během tohoto přechodu snížit riziko.

Vlastní nebo open-source HMI je možné, ale vyžaduje převzetí odpovědnosti

Vlastní HMI lze vyvíjet pomocí open-source nebo komerčních softwarových frameworků.

Zdrojový materiál zmiňuje server běžící ve VMS s moderním klientem založeným na Qt. Architektury tohoto typu mohou oddělit datové připojení na straně serveru od operátorského klienta.

Tato cesta může poskytnout flexibilitu a zabránit závislosti na jediném dodavateli HMI.

Může se z toho také stát dlouhodobý závazek k vývoji softwaru.

Organizace musí vlastnit nebo udržovat:

• Komunikační server.

• Databáze tagů.

• Klientská aplikace.

• Grafický framework.

• Zpracování alarmů.

• Integrace s historizační databází.

• Ověřování uživatelů.

• Aktualizace kybernetického zabezpečení.

• Nasazení a správa verzí.

• Dokumentace a školení.

Qt, Python, C++, webové technologie nebo jiné frameworky mohou vytvořit schopná průmyslová rozhraní. Obtíž nespočívá v nakreslení technologického schématu.

Obtíž spočívá ve vytvoření spolehlivého operátorského systému, který se chová správně při výpadcích komunikace, restartování serverů, záplavách alarmů, změnách uživatelů a nestandardních stavech provozu.

Vlastní platformu je vhodné zvolit pouze tehdy, když má organizace udržitelný vývojový tým nebo spolehlivého dlouhodobého integrátora.

Licence může rozhodnout, zda je technický postup praktický

Starší průmyslový software často používá licenční mechanismy navázané na identifikátory hardwaru, ethernetové adresy, licenční databáze, hardwarové klíče nebo autorizační klíče vydané dodavatelem.

Klonovaný systém se může správně spustit, ale odmítnout spustit aplikaci Symphony, protože se změnila identita virtuálního hardwaru.

Inventář migrace by měl zahrnovat:

• Licence operačního systému OpenVMS.

• Licence aplikací Bailey Symphony.

• Databázové licence.

• Síťové a komunikační licence.

• Licence emulátoru.

• Licence HMI a licence podle počtu bodů OPC.

• Licence historizačního systému.

• Možnosti redundance.

• Licence inženýrských klientů.

• Licence runtime klientů.

Před výběrem konečné platformy by mělo být získáno písemné potvrzení.

Technická kompatibilita bez dostupných právních licencí nevytváří nasaditelné řešení.

Kybernetická bezpečnost musí být součástí návrhu náhrady

Staré systémy AlphaStation byly často instalovány ještě předtím, než se moderní postupy průmyslové kybernetické bezpečnosti staly standardem.

Mohou fungovat v izolovaných sítích s omezeným vzdáleným přístupem. Jejich nahrazení servery Windows, moderními klienty SCADA, servery OPC a ethernetovou infrastrukturou mění plochu útoku.

Nová architektura by měla definovat oddělené zóny řídicí, serverové, inženýrské a podnikové sítě.

Firewally by měly povolovat pouze nezbytné komunikační cesty. Vzdálený přístup by měl používat řízené ověřování a nahrávání.

Účty operátorů by měly používat oprávnění založená na rolích. Inženýrské funkce by neměly být dostupné z každého klienta HMI.

Přístup k zápisu OPC by měl být omezen na tagy a stanice, které jej vyžadují.

Návrh by měl řešit také:

• Opravování operačního systému.

• Antivirová ochrana nebo řízení aplikací.

• Zálohování a obnova.

• Synchronizace času.

• Bezpečnostní protokolování.

• Řízení vyměnitelných médií.

• Vzdálená podpora dodavatele.

• Správa certifikátů pro OPC UA.

• Správa životního cyklu účtů.

Pravidla kybernetické bezpečnosti nesmějí operátorům bránit v reakci během událostí v závodě. Návrh by měl vyvažovat ochranu s dostupností a deterministickým provozem.

Migrace by měla začít inventářem založeným na důkazech

Před výběrem postupu by měli technici stávající systém podrobně zdokumentovat.

Inventář by měl zahrnovat všechny čtyři stanice AlphaStation a určit, zda jsou jejich konfigurace skutečně identické.

Záznam:

• Model AlphaStation a konfigurace procesoru.

• Kapacita paměti.

• Typ disků a logické svazky.

• Verze OpenVMS a úroveň opravných balíčků.

• Nainstalované verze softwaru Bailey.

• Vrstvené produkty a databáze.

• Grafický hardware a rozlišení displeje.

• Síťové adaptéry.

• Sériová rozhraní.

• Komunikační hardware Bailey.

• Názvy a adresy uzlů.

• Postupy spouštěcích příkazů.

• Licenční soubory.

• Zálohovací postupy.

• Redundance operátorských stanic.

• Připojené tiskárny a externí zařízení.

• Uchovávání historických dat a dat alarmů.

Tým by měl také pořídit snímky obrazovek každého displeje. Dynamické stavy by měly být zachyceny, kdykoli je to možné.

Zaznamenejte normální, zastavené, běžící, alarmové, blokované, lokální, ruční, automatické stavy a stavy při selhání komunikace.

Tento důkaz je při testování nových obrazovek nezbytný.

Testovací systém je povinný

Žádná modernizační cesta by neměla být poprvé testována na živém produkčním systému.

Testovací prostředí by mělo reprodukovat dostatečnou část instalované architektury, aby bylo možné ověřit komunikaci a funkce pro operátory.

U projektu s emulátorem by testovací pracoviště mělo obsahovat klonované prostředí OpenVMS Alpha a navrhovanou konfiguraci emulátoru.

U projektu OPC by měla zahrnovat vybraný komunikační server, software HMI, reprezentativní grafiku a přístup k bezpečnému testovacímu uzlu Bailey nebo simulovanému zdroji dat.

Zkouška na testovacím pracovišti by měla ověřit:

• Spuštění systému a start aplikace.

• Komunikace se systémem Bailey.

• Celkový počet dostupných tagů.

• Operace čtení a zápisu.

• Škálování tagů a technické jednotky.

• Generování a potvrzování alarmů.

• Shromažďování trendů.

• Animace obrazovek.

• Zabezpečení příkazů.

• Funkce tiskáren a sestav.

• Chování po restartu serveru.

• Chování při selhání sítě.

• Redundance a převzetí provozu.

• Obnova ze zálohy.

• Doba reakce operátora.

Výsledky zkoušek by měli potvrdit zástupci provozu, řídicí techniky, údržby a kybernetické bezpečnosti.

Paralelní provoz snižuje riziko přepnutí

Původní stanice AlphaStations by měly zůstat k dispozici během počátečního nasazení náhradního systému.

Nové HMI může pracovat paralelně, zatímco technici porovnávají hodnoty, alarmy, trendy a příkazy.

Paralelní provoz umožňuje identifikovat nesrovnalosti před vyřazením starší stanice.

Tým by měl porovnat:

• Zobrazené procesní hodnoty.

• Indikace stavu.

• Priority alarmů.

• Časová razítka alarmů.

• Výsledky příkazů.

• Hodnoty trendů.

• Režim zařízení.

• Kvalita komunikace.

• Oprávnění zabezpečení.

Ne každý rozdíl představuje chybu. Nový systém může používat vylepšené škálování nebo prezentaci alarmů.

Každý rozdíl by měl být přesto vysvětlen a schválen.

Starší stanice by měly zůstat obnovitelné, dokud nové HMI neprojde za přítomnosti svědků přejímací zkouškou na místě a dohodnutou provozní dobou.

Volba správné migrační cesty

Emulaci systému Alpha zvolte, když:

Stávající aplikace Symphony musí zůstat beze změny. Zdrojový kód není k dispozici. Grafika operátorských obrazovek je složitá. Je třeba minimalizovat přeškolení. Komunikační rozhraní Bailey lze podporovat architekturou emulátoru.

Migraci OpenVMS na x86 zvolte, když:

Požadované aplikace jsou dostupné pro x86-64 nebo je lze znovu sestavit. Zdrojový kód a technické znalosti jsou nadále k dispozici. Organizace chce zachovat OpenVMS a zároveň přejít na podporované prostředí x86.

Zvolte změnu platformy na OPC, pokud:

Řadič INFI 90 a vrstvy I/O zůstávají spolehlivé. Organizace chce moderní platformu HMI. Jsou k dispozici inženýrské zdroje pro opětovné vytvoření a ověření displejů, alarmů, tagů a logiky příkazů.

Zvolte evoluční cestu ABB, pokud:

Organizace chce širší program modernizace podporovaný dodavatelem. Budoucí fáze mohou zahrnovat operátorské systémy, inženýrské nástroje, síťová rozhraní, řadiče a I/O.

Zvolte vlastní HMI, pokud:

Organizace má specializované požadavky a dokáže dlouhodobě podporovat vývoj softwaru, testování, kybernetickou bezpečnost a údržbu po dobu životního cyklu.

Stávající systém dočasně ponechte, pokud:

Migrační rozhraní zůstávají nejasná. Zálohy jsou neúplné. Licencování není vyřešeno. Databáze tagů nejsou k dispozici. Testování na zkušebním pracovišti zatím nedokáže napodobit komunikační cestu Bailey.

Praktický plán modernizace po fázích

Fáze 1: Zachovejte stávající prostředí.

Vytvořte ověřené záložní obrazy každé stanice AlphaStation. Zaznamenejte podrobnosti o hardwaru, softwaru, síti, licencování a spuštění. Kdykoli to bude možné, otestujte obnovení.

Fáze 2: Identifikujte komunikační architekturu.

Přesně zdokumentujte, jak jednotlivé stanice Symphony komunikují se systémem INFI 90. Ověřte, zda lze rozhraní emulovat nebo nahradit podporovaným serverem.

Fáze 3: Vytvořte ověření koncepce.

Otestujte jednu naklonovanou stanici v emulátoru platformy Alpha nebo připojte jeden server OPC k reprezentativnímu uzlu Bailey.

Fáze 4: Vytvořte hlavní seznam tagů.

Porovnejte tagy řadiče, identifikátory položek OPC, technické jednotky, příkazy, alarmy a využití displejů.

Fáze 5: Znovu vytvořte reprezentativní displeje.

Vyberte několik obrazovek s různými požadavky na animace, alarmy, příkazy a trendy.

Fáze 6: Dokončete přejímku na zkušebním pracovišti.

Otestujte úplné načítání tagů, selhání komunikace, restart serveru, nárazové série alarmů, chování příkazů a obnovení ze zálohy.

Fáze 7: Nasaďte řešení souběžně.

Provozujte nové a staré HMI současně. Porovnávejte hodnoty a reakce obsluhy.

Fáze 8: Proveďte přechod za účasti svědků.

Použijte schválený testovací postup. Ponechte stanice AlphaStation k dispozici jako zálohu.

Fáze 9: Postupně vyřaďte zastaralý hardware.

Neničte původní obrazy, konfigurační záznamy, licence ani hardware, dokud nebude dokončeno dlouhodobé přejímací řízení.

Často kladené otázky

Lze disk z OpenVMS AlphaStation přímo naklonovat na moderní počítač?

Ne. Obraz obsahuje strojový kód pro platformu Alpha a očekává hardware kompatibilní s platformou Alpha. Moderní počítač x86 jej nemůže přímo spustit. Obraz je nutné obnovit na kompatibilním hardwaru Alpha nebo v emulátoru platformy Alpha.

Mohou OpenVMS provozovat VMware nebo VirtualBox?

Mohou provozovat podporované verze OpenVMS x86-64. Nepřevedou starou instalaci OpenVMS Alpha na aplikaci pro x86. OpenVMS Alpha vyžaduje emulaci platformy Alpha.

Lze zachovat původní displeje Symphony?

Obvykle je lze zachovat, pokud kompletní prostředí Alpha běží pod kompatibilním emulátorem. Při přechodu na jinou platformu HMI je obvykle nutné je znovu ručně vytvořit.

Exportuje server OPC automaticky všechny tagy Bailey?

Ne nutně. Procházení OPC může poskytnout užitečný jmenný prostor, ale konfigurace alarmů, vazby mezi obrazovkami, příkazy, popisy a technická metadata mohou vyžadovat dodatečnou extrakci a sladění.

Je GE CIMPLICITY jedinou náhradou za HMI?

Ne. Jde o jednu z možných platforem a objevuje se v terénním příkladu uvedeném ve zdrojovém textu. Konečný výběr by měl záviset na podpoře komunikace, redundanci, licencování, kybernetické bezpečnosti, dostupných technických kapacitách a požadavcích operátorů.

Má migrace z Alpha na Itanium stále smysl?

Může to být odůvodněné, pokud je požadovaný software dostupný pouze pro systémy Integrity nebo pokud je stávající infrastruktura Integrity již podporována. Obecně jde spíše o přechodovou cestu než o nejsilnější dlouhodobou modernizační strategii.

Mohou řídicí jednotky INFI 90 a I/O zůstat nainstalované?

Ano, pokud zůstanou spolehlivé a zvolená komunikační architektura je podporuje. Modernizaci HMI lze dokončit odděleně od výměny řídicích jednotek a I/O.

Měly by být staré AlphaStationy po přechodu okamžitě odstraněny?

Ne. Měly by zůstat k dispozici jako otestovaná záloha, dokud nové operátorské prostředí neprojde funkčním, výkonnostním a provozním převzetím.

Správné řešení závisí na tom, co je třeba zachovat

Hlavní technickou chybou mnoha plánů modernizace starších HMI je považovat operátorskou stanici za běžný počítač.

AlphaStation se systémem OpenVMS Alpha a Bailey Symphony představuje kompletní hardwarové a softwarové prostředí. Jeho procesorová architektura, operační systém, komunikační rozhraní, aplikační binární soubory, licence, grafika a připojení k řídicímu systému jsou vzájemně závislé.

Klon disku zachovává data. Nepřekládá však toto prostředí na jinou architekturu.

Emulace systému Alpha poskytuje nejpřímější cestu, pokud musí kompletní instalace Symphony zůstat nezměněná.

OpenVMS x86-64 poskytuje cestu k modernímu operačnímu systému, pokud lze aplikace migrovat nebo znovu sestavit.

Přechod na novou platformu OPC představuje praktickou cestu, pokud vrstva řízení INFI 90 zůstává hodnotná, ale vrstvu operátorského rozhraní je třeba nahradit.

Vývoj platformy ABB Symphony Plus může nabídnout širší postupnou strategii, pokud chce organizace modernizovat systém nad rámec HMI.

Konečné rozhodnutí by mělo vycházet z ověřené inventarizace, analýzy komunikačních rozhraní, kontroly licencí, ověření konceptu, zkoušky na zkušebním pracovišti a provozního převzetí za účasti svědků.

Neexistuje výměna bez námahy. Existuje však několik řízených migračních cest, které mohou ochránit stávající investice do řízení procesů a zároveň odstranit závislost na zastarávajícím hardwaru AlphaStation.