Bailey INFI 90 Symphony HMI-k modernizálása OpenVMS Alpha rendszeren

A HMI modernizálása a teljes INFI 90 rendszer cseréje nélkül

Számos Bailey INFI 90 rendszer az eredeti telepítés után évtizedekkel is megbízhatóan működik. Vezérlőik, kommunikációs moduljaik, lezáróegységeik és terepi I/O-egységeik továbbra is elláthatják a szükséges vezérlési funkciókat.

A legközvetlenebb életciklus-probléma gyakran a vezérlőréteg felett található.

A kezelői állomások függhetnek elöregedő AlphaStation-hardvertől, nem támogatott grafikus adapterektől, elavult tárolóeszközöktől és régi OpenVMS Alpha-szoftverkörnyezetektől. A cserealkatrészek beszerzése egyre nehezebb, miközben egyre kevesebb tapasztalt OpenVMS- és Bailey Symphony-mérnök érhető el.

Az itt vizsgált példa négy AlphaStation 255 munkaállomást tartalmaz. Mindegyik állomáson OpenVMS Alpha fut, és a Bailey INFI 90 elosztott vezérlőrendszer Bailey Symphony kezelői felületi funkcióit biztosítja.

A cél nem feltétlenül a teljes DCS cseréje. Gyakorlatiasabb cél lehet az elöregedő AlphaStation-hardvertől való függés megszüntetése, miközben megőrizzük a stabil vezérlőket, a terepi kábelezést, az I/O-modulokat, a vezérlési logikát és a folyamatüzemeltetést.

Ez a különbségtétel megváltoztatja a modernizációs stratégiát.

A projekt elsősorban a kezelői felület és a számítási platform migrációja. Csak akkor válik teljes DCS-migrációvá, ha a vezérlők életciklusa, a kiberbiztonsági követelmények, a termelési célok vagy a támogatási feltételek indokolják az alsóbb vezérlési rétegek cseréjét.

Több lehetséges modernizációs út létezik. Ezek azonban a meglévő rendszer különböző részeit őrzik meg.

Egy Alpha-emulátor szinte a teljes szoftverkörnyezetet megőrizheti. Az OpenVMS x86-ra történő migráció megőrzi az operációs rendszer családját, de alkalmazásmigrációt igényel. Az OPC-alapú HMI-csere megőrzi a vezérlőréteget, miközben újjáépíti a kezelői felületet. Az ABB továbbfejlesztési stratégiája szakaszosan korszerűsítheti a Symphony teljesebb architektúráját.

Egyik út sem írható le egyszerű PC-cseréként.

1. ábra. Három fő modernizációs út a telepített Bailey INFI 90- és Symphony-beruházás különböző részeit őrizheti meg.

Miért nem elegendő az AlphaStation lemezének klónozása?

A lemezklónozás hasznos a telepített OpenVMS Alpha-környezet megőrzéséhez. Rögzítheti az operációs rendszert, az alkalmazásfájlokat, az eszközkonfigurációt, a felhasználói fiókokat, a Bailey-szoftvereket, az adatbázisokat, a grafikákat és a helyspecifikus beállításokat.

A lemez klónozása azonban nem alakítja át az Alpha-szoftvereket x86-os szoftverekké.

A klónozott operációs rendszer továbbra is Alpha processzorutasításokat tartalmaz. A kernelét, rendszerbetöltőjét, rendszertárait, alkalmazásait és hardver-illesztőprogramjait az Alpha architektúrához készítették.

Egy szabványos modern PC x86-64 processzort használ. Emellett eltérő tárolóvezérlőket, hálózati eszközöket, megszakítási struktúrákat, grafikus hardvert, firmware-interfészeket és perifériabuszokat biztosít.

A VMware, a VirtualBox, a Hyper-V és a hagyományos x86-os hipervizorok x86-kompatibilis hardvert virtualizálnak. Általában nem fordítják le az Alpha-processzor utasításait x86-os utasításokra.

Ezért egy OpenVMS Alpha-lemezkép egyszerű x86-os virtuális gépbe helyezése nem teszi a lemezképet indíthatóvá.

A virtuális gép biztosíthat virtuális lemezt, virtuális hálózati adaptert és virtuális grafikus eszközt. Az OpenVMS Alpha továbbra is Alpha-processzort és támogatott, Alpha-korszakbeli eszközöket vár.

Ezért kell a két fogalmat különválasztani:

A virtualizáció általában a gazdagéppel azonos processzorarchitektúrát használó virtuális hardvert biztosít.

A platformok közötti emuláció egy másik processzort és hardverkörnyezetet reprodukál szoftverben.

Az OpenVMS Alpha a második megközelítést igényli, amikor az eredeti Alpha-binárisoknak és az operációs rendszernek változatlanul kell maradniuk.

Ezért a lemezklónozás három korlátozott esetben életképes.

Az első lehetőség ugyanarra az AlphaStation-modellre történő helyreállítás kompatibilis tárolóeszközökkel és perifériákkal.

A második lehetőség egy másik támogatott Alpha-rendszerre történő helyreállítás, a szükséges eszköz- és konfigurációmódosítások elvégzése után.

A harmadik lehetőség egy olyan Alpha-emulátorba történő helyreállítás, amely kompatibilis AlphaServer- vagy AlphaStation-környezetet reprodukál.

A klónozás önmagában nem oldja meg az architektúra problémáját. A célkörnyezetnek továbbra is értenie és végre kell hajtania az Alpha-gépi utasításokat.

Az Alpha-emuláció őrzi meg a meglévő beruházás legnagyobb részét

Az Alpha-emuláció általában a legkevésbé zavaró út, ha a meglévő Symphony-szoftvernek forráskódmódosítások nélkül kell működőképesnek maradnia.

Az Alpha-emulátor modern x86-os hardveren fut, de virtuális Alpha-rendszert mutat az OpenVMS számára. Az eredeti operációs rendszer és az alkalmazások továbbra is Alpha-kompatibilis hardverkörnyezetet érzékelnek.

Az olyan termékeket, mint a CHARON-AXP, erre a célra tervezték. Az emulátor a fizikai Alpha-processzort, a memóriarchitektúrát, a tárolóvezérlőket, az Ethernet-adaptereket és az egyéb támogatott eszközöket szoftveresen definiált megfelelőikkel helyettesíti.

Az x86-os szerveren a Windows vagy a Linux fut gazdakörnyezetként. Az Alpha-emulátor ezen a gazdarendszeren fut. Az OpenVMS Alpha ezután az emulált Alpha-rendszeren belül fut.

Ez a megközelítés eltér az OpenVMS x86-ra történő portolásától.

Az eredeti OpenVMS Alpha-telepítés továbbra is Alpha-telepítés marad. A Bailey Symphony bináris fájljai továbbra is Alpha-binárisok maradnak. Az emulátor lefordítja vagy reprodukálja a szükséges Alpha-hardver működését.

Ez megőrizheti:

• A telepített OpenVMS Alpha operációs rendszer.

• Meglévő Bailey Symphony-alkalmazások.

• Operátori grafikák és kijelzőadatbázisok.

• Riasztási konfigurációk és előzményfájlok.

• A felhasználói fiókok és parancsfájlok.

• A meglévő, helyspecifikus segédprogramok.

• Az Alpha-környezettől függő alkalmazásinterfészek.

• Azok a kezelői munkafolyamatok, amelyek egyébként átképzést igényelnének.

A gyakorlati migráció általában az eredeti Alpha-lemezek ellenőrzött lemezképének vagy biztonsági mentésének elkészítésével kezdődik. Ezeket az adatokat az emulátor által használt virtuális lemeztárolókba állítják vissza.

Az emulátor konfigurációjának megfelelő CPU-, memória-, lemez-, hálózati és perifériatulajdonságokat kell reprodukálnia. Előfordulhat, hogy a csapatnak a fizikai soros portokat vagy hálózati interfészeket is le kell képeznie a gazdarendszeren keresztül.

Az Alpha-emuláció jelentősen csökkentheti az elavult fizikai hardvertől való függőséget. A biztonsági mentést is egyszerűsítheti, mivel a virtuális lemezképfájlok modern tárolási infrastruktúrával másolhatók.

A „zéró módosítás” kifejezést azonban óvatosan kell használni.

Az alkalmazáskód változatlan maradhat, de a környezet továbbra is mérnöki tervezést igényel. Ellenőrizni kell az eszközleképezéseket. Be kell állítani a hálózati interfészeket. Felül kell vizsgálni az OpenVMS- és alkalmazáslicenceket.

Az emulátort a helyszínen használt Bailey kommunikációs interfésszel is tesztelni kell.

Egy általános OpenVMS-alkalmazás megfelelően működhet, miközben egy speciális DCS-interfész meghibásodik, mert egy adott hálózati adaptertől, buszinterfésztől, soros eszköztől vagy időzítési viselkedéstől függ.

Ezért a pontos AlphaStation 255-konfigurációt fel kell mérni, mielőtt emulátorprofilt választanak.

A Bailey kommunikációs interfész a kritikus emulációs teszt

A legfontosabb emulációs kérdés nem az, hogy az OpenVMS eljut-e a bejelentkezési promptig.

A legfontosabb kérdés az, hogy az emulált állomás teljes üzemi körülmények között megfelelően kommunikál-e a Bailey INFI 90 rendszerrel.

Az interfész Ethernettől, soros kommunikációtól, Bailey hálózati interfésztől vagy speciális kommunikációs hardvertől függhet. A helyszíni konfigurációk jelentősen eltérhetnek.

Az Alpha-emuláció alkalmazása előtt a mérnököknek dokumentálniuk kell:

• Az egyes AlphaStationökbe telepített fizikai hálózati interfész.

• A Symphony és az INFI 90 között használt kommunikációs protokoll.

• Az OpenVMS-en belül hozzárendelt eszköznevek.

• A hálózati címek és csomópont-definíciók.

• A szükséges DECnet-, TCP/IP-, LAT- vagy szabadalmaztatott szolgáltatások.

• Az alkalmazandó sorosport-beállítások.

• Bármilyen külső licenckulcs vagy hardverkulcs.

• A kezelői állomások közötti redundancia és feladatátvétel működése.

• Az időszinkronizálási követelmények.

• A kezelők által használt grafikai és billentyűzetfunkciók.

Egy emulátorszállító támogathat általános Alpha Ethernet- és tárolóeszközöket. Ez azonban nem erősíti meg automatikusan minden szabadalmaztatott Bailey-interfész támogatását.

Ha a meglévő HMI olyan speciális fizikai adaptertől függ, amely nem virtualizálható, az emulátoros megoldáshoz alternatív kommunikációs átjáróra lehet szükség.

Ezért a projektnek tartalmaznia kell egy próbapadi tesztet klónozott állomással és egy reprezentatív Bailey-hálózathoz való hozzáféréssel.

A tesztnek a statikus tagolvasásnál többet kell magában foglalnia. A kezelőknek ellenőrizniük kell a valós idejű értékeket, a parancsokat, a riasztásokat, a nyugtázást, a trendeket, a kijelzők közötti navigációt, a nyomtatást, az eseménykezelést és az állomás helyreállását.

A teljesítményt riasztási hullámok és nagy gyakoriságú tagfrissítések során is tesztelni kell.

Az OpenVMS x86-64 eltérő migrációs útvonal

A modern OpenVMS elérhető az x86-64 architektúrához. Támogatott virtualizált környezetekben, modern szervereken is üzemeltethető.

Ez további migrációs lehetőséget teremt, amely számos korábbi INFI 90-modernizációs megbeszélés idején még nem állt rendelkezésre.

Az OpenVMS x86-64 azonban nem futtatja közvetlenül az OpenVMS Alpha-binárisokat úgy, mintha natív x86-alkalmazások lennének.

Az alkalmazási környezetet át kell migrálni.

Előfordulhat, hogy a forráskódot át kell vinni, át kell vizsgálni, újra kell fordítani, linkelni és tesztelni kell x86-64-en. A külső fejlesztésű könyvtáraknak és rétegtermékeknek szintén elérhetőnek kell lenniük a célverzióhoz.

A központi kérdés az, hogy a telepített Bailey Symphony szoftvernek létezik-e x86-kompatibilis OpenVMS-verziója.

Ha a szoftvergyártó soha nem adta ki az alkalmazást OpenVMS x86-64 rendszerre, akkor önmagában az operációs rendszer áthelyezése nem őrzi meg a HMI-t.

A helyszínen fejlesztett programok hordozhatók lehetnek, ha a forráskód és a buildkörnyezet továbbra is elérhető. Zárt kereskedelmi alkalmazások általában nem építhetők újra gyártói támogatás nélkül.

Ez az út továbbra is praktikus lehet a Symphony HMI mellett futó egyedi adatforgalmi szerverek, historizálók, segédprogramok, jelentések és integrációs alkalmazások esetében.

Kevésbé valószínű, hogy támogatott alkalmazáskiadás nélkül megőrzi a régi, saját fejlesztésű Symphony-kezelői környezetet.

Az OpenVMS x86-migrációs felmérésnek azonosítania kell:

• Minden telepített futtatható fájl és rétegtermék.

• Elérhető forráskód és buildeljárások.

• Fordító- és futtatókörnyezet-függőségek.

• Adatbázistermékek és fájlformátumok.

• Saját fejlesztésű kommunikációs könyvtárak.

• Grafikai vagy ablakkezelő-rendszer-függőségek.

• Az x86-64 licencelérhetősége.

• Az architektúrák közötti különbségek miatt szükséges módosítások.

• Teljesítményre és időzítésre vonatkozó feltételezések.

Ennek az útnak nagyobb a hosszú távú potenciálja, mint az Alpháról egy másik megszüntetett hardverarchitektúrára való átállásnak. Lehetővé teheti a kompatibilis OpenVMS-munkaterhelések támogatott x86-virtualizációs infrastruktúrára helyezését.

Mindazonáltal ezt alkalmazásmigrációs projektként, nem pedig lemezklónozási projektként kell leírni.

Miért átmeneti lehetőség általában az Itanium-migráció?

Az OpenVMS az Itanium architektúrát használó HPE Integrity szerverekre is megjelent.

Léteznek migrációs eszközök és mérnöki módszerek egyes Alpha-alkalmazások OpenVMS Integrity rendszerbe való áthelyezéséhez. Ez korábban támogatott átállási lehetőséget biztosított az elöregedő Alpha hardverről.

Ma azonban maga az Itanium hardver is örökölt platformnak számít.

Az Alpha rendszerről Integrity rendszerre való áttérés megszüntethet egy elavult hardverfüggőséget, miközben létrehoz egy másikat. A megfelelő szerverek, alkatrészek, tárolóinterfészek és speciális szakértelem továbbra is egyre nehezebben lesznek elérhetők.

Az Itanium továbbra is releváns lehet, ha a helyszín már rendelkezik támogatott Integrity-infrastruktúrával. Akkor is releváns lehet, ha egy szükséges rétegtermék elérhető Integrity rendszerhez, de x86-64-hez nem.

Egy új korszerűsítési projekt esetén ezt általában köztes kompatibilitási megoldásként kell értékelni.

Az üzleti indoklásnak meg kell magyaráznia, miért előnyösebb az Integrity rendszerre való áttérés az Alpha-emulációnál, az OpenVMS x86-ra való migrációnál vagy a HMI újraplatformozásánál.

Az OPC-alapú újraplatformozás megőrzi a vezérlési réteget

Az OPC-alapú újraplatformozás lecseréli a kezelői felületi réteget, miközben megtartja a meglévő INFI 90-vezérlőket és a terepi I/O-t.

Egy kommunikációs szerver kapcsolódik a Bailey-rendszerhez, és folyamatcímkéket tesz elérhetővé egy modern HMI- vagy SCADA-platform számára.

Az új HMI kezeli a kijelzőket, riasztásokat, trendeket, biztonságot, kezelői parancsokat, jelentéseket és a munkaállomás-szolgáltatásokat.

Ez a megoldás megszünteti az eredeti Symphony kezelői alkalmazástól való függőséget. Emellett elkerülhetővé teszi az OpenVMS Alpha futtatása az új kezelői állomásokon.

Az architektúra általában a következőket tartalmazza:

• Meglévő Bailey INFI 90-vezérlők és I/O.

• Kompatibilis Bailey-kommunikációs interfész.

• OPC DA-, OPC UA- vagy gyártóspecifikus adatszerver.

• Modern HMI- vagy SCADA-platform.

• Kezelői és mérnöki munkaállomások.

• Opcionális historizáló, jelentéskészítő és riasztáselemző szolgáltatások.

A forrásanyagban hivatkozott terepi példában RoviSys OPC-szervert használtak GE CIMPLICITY rendszerrel. A beszámoló szerint a rendszer sikeresen működött, de a projekt során újra kellett építeni a kezelői kijelzőket és az animációs logikát.

Ezt a példát nem szabad úgy értelmezni, mint minden INFI 90-telepítésre vonatkozó automatikus termékajánlást.

A kiválasztott szervernek támogatnia kell a helyszínen használt konkrét Bailey-hálózatot, kommunikációs modulokat, vezérlőgenerációt, címkeszámot, frissítési gyakoriságot, redundanciakövetelményeket és parancsfunkciókat.

Ugyanez vonatkozik a HMI-platformra is.

A GE CIMPLICITY az egyik lehetséges vállalati HMI/SCADA-platform. Más rendszerek is megfelelőek lehetnek, ha biztosítják a szükséges OPC-kapcsolatot, grafikákat, riasztásokat, szkriptelést, redundanciát, biztonságot és életciklus-támogatást.

2. ábra. Az OPC-alapú migráció megőrzi az INFI 90 vezérlési rétegét, miközben lecseréli a régi Symphony kezelői környezetet.

Az OPC-kapcsolat nem alakítja át a meglévő képernyőket

Az OPC-szerver adatkapcsolatot biztosít. Általában nem alakítja át a régi HMI-képernyőket új HMI-formátumra.

Az eredeti Symphony képernyők statikus grafikákat, dinamikus szimbólumokat, színváltozásokat, numerikus értékeket, oszlopdiagramokat, riasztásjelzőket, navigációs gombokat, parancsvezérlőket, trendeket és egyéni funkciósablonokat tartalmazhatnak.

Ezeket az elemeket újra létre kell hozni a cél-HMI-ben.

Az egyszerű kijelzők közvetlenül újrarajzolhatók. Az összetett kijelzők rejtett szkripteket vagy kifejezéseket tartalmazhatnak, amelyek nem láthatók azonnal.

A mérnököknek meg kell érteniük, hogy az egyes animált objektumok hogyan szerzik be és dolgozzák fel az adataikat.

Egy szelepszimbólum nem feltétlenül egyetlen kimeneti címkét követ. Színe és pozíciója függhet a nyitási visszajelzéstől, a zárási visszajelzéstől, a parancsállapottól, a reteszelési állapottól, a kommunikáció minőségétől és a berendezés üzemmódjától.

Egy motor szimbóluma külön címkéket használhat az indítási parancshoz, a működés visszajelzéséhez, a leállított állapothoz, a kioldáshoz, a helyi vezérléshez, a karbantartási állapothoz, az engedélyezési feltételekhez és a riasztásblokkoláshoz.

Ezért kizárólag a látható grafikák áthelyezése olyan HMI-t eredményezhet, amely helyesnek tűnik, de helytelenül működik.

A migrációs csapatnak dokumentálnia kell az egyes kijelzőelemek mögött rejlő funkcionális jelentést.

Ez a munka a következőket foglalja magában:

• Minden dinamikus objektum adatforrásához való hozzárendelése.

• Az animációs kifejezések újraalkotása.

• A parancsok megerősítésének és a biztonságnak az ellenőrzése.

• A navigáció és a kijelzőhierarchiák újjáépítése.

• A riasztási osztályok és prioritások újraalkotása.

• A mértékegységek és a tizedesjegyek pontosságának ellenőrzése.

• Az előzmény- és valós idejű trendek újjáépítése.

• Az érvénytelen, bizonytalan és kommunikációs hibás állapotok tesztelése.

• A kezelői üzenetek és útmutatások reprodukálása.

• A nem támogatott betűtípusok és szimbólumok cseréje.

A ráfordítást ezért a kijelzők összetettsége, nem csupán a kijelzők száma határozza meg.

Egy modern HMI-nek nem szabad vakon lemásolnia minden régi kijelzőt

A kézi újraalkotás lehetőséget teremt a kezelői felület javítására.

A régi HMI-grafikák gyakran élénk színeket használnak a normál állapotú berendezésekhez, sűrű folyamatábrákat, dekoratív csővezetékeket és következetlen riasztásjelzéseket tartalmaznak.

Ezek a konvenciók észszerűek lehettek az eredeti rendszer fejlesztésekor. A jelenlegi irányítótermi gyakorlatokhoz azonban nem mindig ideálisak.

Egy korszerűsítési projektnek át kell tekintenie:

• A kijelzők hierarchiája.

• A riasztások láthatósága.

• A navigáció következetessége.

• A berendezés állapotának megjelenítése.

• A színek használata.

• A trendek elérhetősége.

• A kezelői beavatkozással kapcsolatos követelmények.

• Képernyőfelbontás és munkaállomás-elrendezés.

• Akadálymentesség és olvashatóság.

A normál üzemállapotoknak vizuálisan visszafogottnak kell maradniuk. Az élénk színeknek a figyelmet igénylő rendellenes állapotokat kell jelezniük.

A kezelőknek túlzott navigáció nélkül el kell tudniuk jutni az üzem áttekintő képétől az érintett egységhez, a berendezés előlapjához, a trendhez, a riasztási előzményekhez és a diagnosztikai kijelzőhöz.

A túlzott újratervezés azonban újabb kockázatot teremthet.

A kezelők sok éven át használhatták az eredeti képernyőket. Ha ugyanazon projekt során minden szimbólumot, színt és navigációs útvonalat megváltoztatunk, az növelheti a képzési igényt és az átállás kockázatát.

A kiegyensúlyozott megközelítés megőrzi a megszokott folyamatkapcsolatokat, miközben javítja a riasztások megjelenítését és a navigációt.

A címkék kinyerését mérnöki munkacsomagként kell kezelni

A forrásanyag felveti a Bailey-tagadatok CSV-be történő exportálásának lehetőségét. Nem tartalmaz azonban megerősített, univerzális eljárást.

Ezért nem szabad abból kiindulni, hogy egyetlen exportparancs teljes és rendezett HMI-adatbázist hoz létre.

A taginformációk lehetséges forrásai:

• Symphony-konfigurációs adatbázisok.

• Meglévő képernyődefiníciók.

• Vezérlőkonfigurációs és mérnöki nyilvántartások.

• Bailey-kommunikációs szerverek adatbázisai.

• Az OPC-szerver böngészési funkciói.

• Riasztáskonfigurációs fájlok.

• Historikus adatbázisok.

• Nyomtatott vagy archivált taglisták.

• Telephelyi mérnöki táblázatok.

Az OPC-böngészés praktikus kiindulópontot jelenthet, miután a szerver kommunikációt létesít a Bailey-rendszerrel.

Tartalmazhatja a tagek neveit, az elemazonosítókat, a leírásokat, a minőséget és az aktuális értékeket. Egyes szerverek a böngészett névtér exportálását is támogatják.

Az OPC-névtér azonban nem feltétlenül tartalmaz minden, az új HMI-hez szükséges mezőt.

A riasztási prioritások, a mérnöki határértékek, a képernyőcsoportosítások, az operátori megjegyzések, a parancsbiztonság és a berendezések közötti kapcsolatok máshol lehetnek tárolva.

Egyes OPC-szerverek olyan generált nevekkel teszik közzé a tageket, amelyek eltérnek az eredeti Symphony-nevektől.

A projektnek legalább a következőket tartalmazó, ellenőrzött tagtörzset kell létrehoznia:

• Eredeti tag neve.

• Új HMI-tag neve.

• OPC-elemazonosító.

• Leírás.

• Adattípus.

• Olvasási vagy írási jogosultság.

• Mértékegységek.

• Skálázási információk.

• Riasztási határértékek és prioritás.

• Frissítési gyakoriság.

• Kapcsolódó képernyő.

• Érvényesítési állapot.

• Teszteredmény.

Ez a törzs lesz a régi és az új rendszer közötti egyeztetési nyilvántartás.

A tagek száma nem az egyetlen kommunikációs követelmény

A sikeres böngészési teszt nem bizonyítja, hogy az OPC-architektúra képes támogatni a teljes HMI-t.

A mérnököknek értékelniük kell az aktív tagek számát, a kért frissítési gyakoriságot, a változások gyakoriságát, a riasztási aktivitást, a parancsforgalmat és a szerverredundanciát.

Egy rendszer több tízezer konfigurált taget is tartalmazhat. Ezeknek egyszerre csak egy része lehet aktív az operátori képernyőkön.

A szervert és a HMI-t valósághű körülmények között kell tesztelni.

A fontos teljesítmény-ellenőrzések közé tartoznak:

• Az összetett képernyő megnyitásához szükséges idő.

• A mezőbeli változás és a HMI-animáció közötti késleltetés.

• Riasztások kézbesítése eseménytorlódások idején.

• A trendek gyűjtése a szükséges mintavételi gyakorisággal.

• A parancsvégrehajtás és a visszajelzés ideje.

• Helyreállás hálózati megszakítás után.

• Átváltás redundáns szerverek között.

• A vezérlő újraindítását követő viselkedés.

• A minőségi állapot kommunikációs hiba esetén.

• CPU-, memória- és hálózati terhelés.

A parancsok különös figyelmet igényelnek.

Az értékek OPC-n keresztüli olvasása viszonylag egyszerű lehet. Az értékek biztonságos írásához hozzáférés-vezérlésre, parancsérvényesítésre, visszajelzés-megerősítésre és a kommunikációs hibák megfelelő kezelésére van szükség.

A csapatnak minden operátori parancstípust tesztelnie kell, nem csak egy reprezentatív taget.

Az ABB Symphony Plus szélesebb körű továbbfejlesztési útvonalat kínál

Egy OPC-csere nem az egyetlen lehetőség egy telepített Bailey-rendszer esetében.

Az ABB továbbra is a Symphony Plust a régebbi Bailey, INFI 90, Harmony Rack és Symphony telepítések továbbfejlesztési platformjaként pozicionálja.

A fokozatos ABB-modernizáció megőrizheti a telepített vezérlési és I/O-architektúra egyes részeit, miközben újabb operátori, mérnöki, hálózati, vezérlő- vagy I/O-komponenseket vezet be.

Ez a megközelítés vonzó lehet, ha a szervezet független HMI-csere helyett szállító által támogatott életciklus-stratégiát szeretne.

A projekt először az operátori környezetet modernizálhatja. A vezérlők és az I/O-rendszer üzemben maradhatnak, amíg az életciklusuk vagy az üzemeltetési értékük indokolttá nem teszi a cseréjüket.

A későbbi szakaszok a kommunikációval, a vezérlőkkel, a mérnöki eszközökkel és a terepi interfészekkel foglalkozhatnak.

A pontos migrációs architektúra a telepített rendszer generációjától függ.

A Bailey INFI 90, az INFI 90 OPEN, a Network 90, a Harmony, a Symphony és a Symphony Plus telepítései nem mind ugyanazokat az interfészeket használják.

A modulneveket és a hálózati terminológiát a helyszíni rajzok és a hardverleltárak alapján ellenőrizni kell.

A meglévő vezérlési réteget karbantartó szervezetek a tartalékellátás, az életciklus-támogatás és a szakaszos modernizáció tervezésekor áttekinthetik az elérhető ABB Bailey INFI 90 és Network 90 komponenseket is.

Ez a belső hivatkozás azért releváns, mert a modernizációs projektekben gyakran szükséges, hogy a régi rendszer a mérnöki munkák, a tesztelés és a szakaszos átállás során is üzemképes maradjon.

A megfelelő tartalékvezérlők, kommunikációs modulok, tápegységek és I/O-modulok készenlétben tartása csökkentheti az átmenet során jelentkező kockázatot.

Egyedi vagy nyílt forráskódú HMI lehetséges, de tulajdonosi felelősséget igényel

Az egyedi HMI nyílt forráskódú vagy kereskedelmi szoftveres keretrendszerek használatával is fejleszthető.

A forrásanyag egy VMS-en futó, Qt-alapú modern klienssel rendelkező szervert említ. Az ilyen típusú architektúrák elválaszthatják a szerveroldali adatkapcsolatot az operátori klienstől.

Ez a megközelítés rugalmasságot biztosíthat, és elkerülhetővé teheti az egyetlen HMI-szállítótól való függést.

Ez hosszú távú szoftverfejlesztési kötelezettséggé is válhat.

A szervezetnek kell birtokolnia vagy karbantartania:

• Kommunikációs szerver.

• Tagadatbázis.

• Kliensalkalmazás.

• Grafikai keretrendszer.

• Riasztásfeldolgozás.

• Historian-integráció.

• Felhasználói hitelesítés.

• Kiberbiztonsági frissítések.

• Telepítés és verziókezelés.

• Dokumentáció és képzés.

A Qt, a Python, a C++, a webtechnológiák és más keretrendszerek is alkalmas ipari interfészek létrehozására. A nehézség nem egy technológiai grafika megrajzolása.

A nehézséget egy megbízható operátori rendszer létrehozása jelenti, amely megfelelően működik kommunikációs hibák, szerver-újraindítások, riasztásáradatok, felhasználói változtatások és az üzem rendellenes állapotai esetén.

Egyedi platformot csak akkor érdemes választani, ha a szervezet rendelkezik fenntartható mérnöki csapattal vagy megbízható, hosszú távú integrátorral.

A licencelés meghatározhatja, hogy egy műszaki útvonal gyakorlatban megvalósítható-e

A régi ipari szoftverek gyakran hardverazonosítókhoz, Ethernet-címekhez, licencadatbázisokhoz, hardverkulcsokhoz vagy a gyártó által kiadott engedélyezési kulcsokhoz kötött licencelési mechanizmusokat használnak.

Egy klónozott rendszer megfelelően elindulhat, de megtagadhatja a Symphony alkalmazás indítását, mert megváltozott a virtuális hardverazonosító.

A migrációs leltárnak a következőket kell tartalmaznia:

• OpenVMS operációsrendszer-licencek.

• Bailey Symphony alkalmazáslicencek.

• Adatbázis-licencek.

• Hálózati és kommunikációs licencek.

• Emulátorlicencek.

• HMI- és OPC-pontszámlicencek.

• Historian-licencek.

• Redundanciaopciók.

• Mérnöki klienslicencek.

• Futtatási klienslicencek.

A végleges platform kiválasztása előtt írásos megerősítést kell beszerezni.

A műszaki kompatibilitás jogszerű licencelérhetőség nélkül nem eredményez telepíthető megoldást.

A kiberbiztonságot már a csere tervezésébe be kell építeni

A régi AlphaStation-rendszereket gyakran még azelőtt telepítették, hogy a modern ipari kiberbiztonsági gyakorlatok szabványossá váltak volna.

Izolált hálózatokon, korlátozott távoli hozzáféréssel működhetnek. A Windows-szerverekkel, modern SCADA-kliensekkel, OPC-szerverekkel és Ethernet-infrastruktúrával való lecserélésük megváltoztatja a támadási felületet.

Az új architektúrának külön vezérlési, szerver-, mérnöki és vállalati hálózati zónákat kell meghatároznia.

A tűzfalak csak a szükséges kommunikációs útvonalakat engedélyezhetik. A távoli hozzáféréshez felügyelt hitelesítést és rögzítést kell használni.

A kezelői fiókoknak szerepköralapú jogosultságokat kell követniük. A mérnöki funkciók nem lehetnek elérhetők minden HMI-kliensről.

Az OPC írási hozzáférést azokra a tagekre és állomásokra kell korlátozni, amelyeknek erre szükségük van.

A kialakításnak a következőkkel is foglalkoznia kell:

• Operációs rendszer javítása.

• Vírusvédelem vagy alkalmazásvezérlés.

• Biztonsági mentés és helyreállítás.

• Időszinkronizálás.

• Biztonsági naplózás.

• Cserélhető adathordozók kezelése.

• Gyártói távoli támogatás.

• Tanúsítványkezelés az OPC UA-hoz.

• Fiókok életciklus-kezelése.

A kiberbiztonsági kontrollok nem akadályozhatják meg a kezelőket abban, hogy üzemzavarok esetén reagáljanak. A kialakításnak egyensúlyt kell teremtenie a védelem, a rendelkezésre állás és a determinisztikus működés között.

A migrációt bizonyítékokon alapuló leltárral kell kezdeni

Az útvonal kiválasztása előtt a mérnököknek részletesen dokumentálniuk kell a meglévő rendszert.

A leltárnak mind a négy AlphaStationt tartalmaznia kell, és meg kell határoznia, hogy a konfigurációik valóban azonosak-e.

Rögzítse:

• AlphaStation-modell és processzorkonfiguráció.

• Memóriakapacitás.

• Lemeztípus és logikai kötetek.

• OpenVMS-verzió és javítási szint.

• Telepített Bailey-szoftververziók.

• Rétegzett termékek és adatbázisok.

• Grafikus hardver és megjelenítési felbontás.

• Hálózati adapterek.

• Soros interfészek.

• Bailey kommunikációs hardver.

• Csomópontnevek és -címek.

• Indítási parancsok eljárásai.

• Licencfájlok.

• Tartalék eljárások.

• Kezelői állomás redundanciája.

• Csatlakoztatott nyomtatók és külső eszközök.

• Előzmény- és riasztási adatok megőrzése.

A csapatnak minden kijelzőről képernyőképeket is kell gyűjtenie. A dinamikus állapotokat lehetőség szerint rögzíteni kell.

Rögzíteni kell a normál, leállított, üzemelő, riasztási, tiltott, helyi, kézi, automatikus és kommunikációs hibás állapotokat.

Ez a bizonyíték elengedhetetlen az új képernyők tesztelésekor.

A próbapadi rendszer kötelező

Egyetlen modernizálási útvonalat sem szabad először az éles termelési rendszeren tesztelni.

A próbapadi környezetnek a telepített architektúra elegendő részét kell reprodukálnia a kommunikáció és a kezelői funkciók ellenőrzéséhez.

Egy emulációs projektnél a próbapadnak tartalmaznia kell egy klónozott OpenVMS Alpha-környezetet és a javasolt emulátorkonfigurációt.

Egy OPC-projektnél ennek tartalmaznia kell a kiválasztott kommunikációs szervert, a HMI-szoftvert, reprezentatív grafikákat, valamint hozzáférést egy biztonságos Bailey-tesztcsomóponthoz vagy szimulált adatforráshoz.

A próbapadi tesztnek ellenőriznie kell:

• Rendszerindítás és alkalmazásindítás.

• Kommunikáció a Bailey rendszerrel.

• A hozzáférhető címkék teljes száma.

• Olvasási és írási műveletek.

• Címkék skálázása és mérnöki mértékegységek.

• Riasztások létrehozása és nyugtázása.

• Trendgyűjtés.

• Kijelzőanimáció.

• Parancsbiztonság.

• Nyomtatási és jelentéskészítési funkciók.

• A szerver újraindítási viselkedése.

• Hálózati hiba esetén tanúsított viselkedés.

• Redundancia és tartalék rendszerre történő átállás.

• Biztonsági mentés visszaállítása.

• Kezelői válaszidő.

A teszteredményeket az üzemeltetés, a vezérléstechnika, a karbantartás és a kiberbiztonság képviselőinek jelenlétében kell ellenőrizni.

A párhuzamos üzemeltetés csökkenti az átállás kockázatát

Az eredeti AlphaStation állomásokat az új rendszer kezdeti üzembe helyezése alatt továbbra is elérhetővé kell tenni.

Az új HMI párhuzamosan működhet, miközben a mérnökök összehasonlítják az értékeket, a riasztásokat, a trendeket és a parancsokat.

A párhuzamos üzemeltetés lehetővé teszi az eltérések azonosítását, mielőtt a régi állomást eltávolítják.

A csapatnak egyeztetnie kell:

• Megjelenített folyamatértékek.

• Állapotjelzések.

• Riasztási prioritások.

• Riasztások időbélyegei.

• Parancsok eredményei.

• Trendértékek.

• Berendezés üzemmódja.

• Kommunikációs minőség.

• Biztonsági jogosultságok.

Nem minden eltérés jelent hibát. Az új rendszer továbbfejlesztett skálázást vagy riasztásmegjelenítést használhat.

Minden eltérést továbbra is meg kell magyarázni és jóvá kell hagyni.

A régi állomásoknak helyreállíthatónak kell maradniuk addig, amíg az új HMI át nem megy egy tanúsított helyszíni átvételi teszten, és le nem telik az egyeztetett üzemeltetési időszak.

A megfelelő migrációs útvonal kiválasztása

Válassza az Alpha-emulációt, ha:

A meglévő Symphony alkalmazásnak változatlanul kell maradnia. A forráskód nem érhető el. A kezelői grafikák összetettek. Az átképzést minimálisra kell csökkenteni. A Bailey kommunikációs interfész támogatását az emulátor architektúrája lehetővé teszi.

Válassza az OpenVMS x86-os migrációját, ha:

A szükséges alkalmazások x86-64-en elérhetők, vagy újraépíthetők. A forráskód és a mérnöki szaktudás továbbra is rendelkezésre áll. A szervezet meg kívánja tartani az OpenVMS-t, miközben támogatott x86-os környezetre tér át.

OPC-újraplatformozást válasszon, ha:

Az INFI 90 vezérlője és a be-/kimeneti rétegek továbbra is megbízhatóak. A szervezet modern HMI-platformot szeretne. Rendelkezésre állnak a mérnöki erőforrások a kijelzők, riasztások, címkék és parancslogika újjáépítéséhez és ellenőrzéséhez.

ABB evolúciós útvonalat válasszon, ha:

A szervezet szélesebb körű, gyártó által támogatott modernizációs programot szeretne. A későbbi fázisok magukban foglalhatják a kezelői rendszereket, a mérnöki eszközöket, a hálózati interfészeket, a vezérlőket és a be-/kimeneteket.

Egyedi HMI-t válasszon, ha:

A szervezetnek speciális követelményei vannak, és képes hosszú távon támogatni a szoftverfejlesztést, a tesztelést, a kiberbiztonságot és az életciklus-karbantartást.

Ideiglenesen tartsa meg a meglévő rendszert, ha:

A migrációs interfészek továbbra sem egyértelműek. A biztonsági mentések hiányosak. A licencelés megoldatlan. A címkeadatbázisok nem érhetők el. A próbapadi tesztelés egyelőre nem képes reprodukálni a Bailey kommunikációs útvonalát.

Gyakorlati, szakaszos modernizációs terv

1. fázis: Őrizze meg a meglévő környezetet.

Készítsen ellenőrzött lemezkép-mentést minden AlphaStationről. Rögzítse a hardver-, szoftver-, hálózati-, licencelési- és indítási adatokat. Ahol lehetséges, tesztelje a visszaállítást.

2. fázis: Azonosítsa a kommunikációs architektúrát.

Dokumentálja pontosan, hogyan kommunikál az egyes Symphony-állomás az INFI 90-nel. Erősítse meg, hogy az interfész emulálható-e vagy lecserélhető-e egy támogatott szerverre.

3. fázis: Készítsen működési koncepciót.

Teszteljen egy klónozott állomást Alpha-emulátoron, vagy csatlakoztasson egy OPC-szervert egy reprezentatív Bailey-csomóponthoz.

4. fázis: Hozza létre a címkék törzsadatbázisát.

Egyeztesse a vezérlőcímkéket, az OPC-elemazonosítókat, a mértékegységeket, a parancsokat, a riasztásokat és a kijelzők használatát.

5. fázis: Építse újra a reprezentatív kijelzőket.

Válasszon ki több olyan képernyőt, amelyek eltérő animációs, riasztási, parancs- és trendkövetelményeket tartalmaznak.

6. fázis: Fejezze be a próbapadi átvételt.

Tesztelje a teljes címkebetöltést, a kommunikációs hibát, a szerver újraindítását, a riasztási hullámokat, a parancsok működését és a biztonsági mentés visszaállítását.

7. fázis: Telepítse párhuzamosan.

Működtesse együtt az új és a régi HMI-ket. Hasonlítsa össze az értékeket és a kezelői válaszokat.

8. fázis: Hajtsa végre a felügyelt átállást.

Használjon jóváhagyott teszteljárást. Tartsa elérhetően az AlphaStationöket tartalékként.

9. fázis: Fokozatosan vonja ki a régi hardvert.

A hosszú távú elfogadás befejezéséig ne semmisítse meg az eredeti lemezképeket, konfigurációs nyilvántartásokat, licenceket vagy hardvereket.

Gyakran ismételt kérdések

Közvetlenül klónozható egy OpenVMS AlphaStation lemeze egy modern PC-re?

Nem. A lemezkép Alpha-gépi kódot tartalmaz, és Alpha-kompatibilis hardvert vár. Egy modern x86-os PC nem tudja közvetlenül elindítani. A lemezképet kompatibilis Alpha-hardverre vagy Alpha-emulátorra kell visszaállítani.

Futtatható az OpenVMS VMware-en vagy VirtualBoxon?

Futtathatók rajtuk a támogatott OpenVMS x86-64 kiadások. Egy régi OpenVMS Alpha-telepítést azonban nem alakítanak át x86-os alkalmazássá. Az OpenVMS Alphához Alpha-emuláció szükséges.

Megőrizhetők az eredeti Symphony kijelzők?

Általában megőrizhetők, ha a teljes Alpha-környezet kompatibilis emulátor alatt fut. Más HMI-platformra áttéréskor rendszerint kézzel kell újra létrehozni őket.

Az OPC-szerver automatikusan exportál minden Bailey taget?

Nem feltétlenül. Az OPC-böngészés hasznos névteret biztosíthat, de a riasztáskonfiguráció, a képernyőkapcsolatok, a parancsok, a leírások és a mérnöki metaadatok további kinyerést és egyeztetést igényelhetnek.

A GE CIMPLICITY az egyetlen lehetséges HMI-csere?

Nem. Ez egy lehetséges platform, és szerepel a forrásban bemutatott terepi példában. A végső választásnak a kommunikációs támogatástól, a redundanciától, a licenceléstől, a kiberbiztonságtól, a mérnöki erőforrásoktól és a kezelői követelményektől kell függenie.

Érdemes még Alpháról Itaniumra migrálni?

Ez indokolt lehet, ha a szükséges szoftver csak Integrity rendszerekhez érhető el, vagy ha a meglévő Integrity-infrastruktúra már támogatott. Általában átmeneti megoldás, nem pedig a legerősebb hosszú távú korszerűsítési stratégia.

A meglévő INFI 90 vezérlők és bemenetek/kimenetek a helyükön maradhatnak?

Igen, ha továbbra is megbízhatóak, és a kiválasztott kommunikációs architektúra támogatja őket. A HMI korszerűsítése a vezérlők és a bemeneti/kimeneti rendszer cseréjétől függetlenül is elvégezhető.

El kell távolítani a régi AlphaStationöket közvetlenül az átállás után?

Nem. Tesztelt tartalékként elérhetőnek kell maradniuk mindaddig, amíg az új kezelői környezet át nem megy a funkcionális, teljesítmény- és üzemi átvételen.

A helyes megoldás attól függ, mit kell megőrizni

Sok régi HMI-terv fő műszaki hibája, hogy a kezelőállomást közönséges PC-ként kezeli.

Az OpenVMS Alphát és a Bailey Symphonyt futtató AlphaStation teljes hardver- és szoftverkörnyezet. Processzorarchitektúrája, operációs rendszere, kommunikációs interfészei, alkalmazásbinárisai, licencei, grafikája és a vezérlőrendszer-kapcsolatai kölcsönösen függenek egymástól.

A lemezklón megőrzi az adatokat. Nem fordítja le azonban a környezetet egy másik architektúrára.

Az Alpha-emuláció a legközvetlenebb út, ha a teljes Symphony-telepítésnek változatlanul működőképesnek kell maradnia.

Az OpenVMS x86-64 korszerű operációsrendszer-alternatívát kínál, ha az alkalmazások migrálhatók vagy újraépíthetők.

Az OPC újraplatformozása gyakorlati megoldást kínál, ha az INFI 90 vezérlési réteg továbbra is értékes, de a kezelői réteget le kell cserélni.

Az ABB Symphony Plus továbbfejlesztése szélesebb körű, fokozatos stratégiát kínálhat, ha a szervezet a HMI-n túl is korszerűsíteni kíván.

A végső döntést ellenőrzött leltárnak, kommunikációs interfészvizsgálatnak, licencfelülvizsgálatnak, koncepcióigazolásnak, próbapadi tesztnek és tanúsított üzemi átvételnek kell megalapoznia.

Nincs teljesen erőfeszítésmentes csere. Létezik azonban több szabályozott migrációs útvonal, amely megóvhatja a meglévő folyamatirányítási beruházást, miközben megszünteti az elöregedő AlphaStation hardvertől való függőséget.