Upgrade dispečerského riadiaceho systému - SCADA

Pred pár týždňami sme sa s kolegami vrátili z niekoľkodňovej akcie. U zákazníka sme upgradovali SCADA systém na dispečingu. Jednalo sa o riadiaci SCADA systém, ktorý bol pôvodne postavený na redundantných Alpha serveroch DS25 s operačným systémom OpenVMS (verzie 7.3.1) a na technológii IPESOFT D2000 OpenVMS verzie 7.1. Konfiguračné, monitorovacie a archívne dáta boli uložené v databáze Oracle verzie 9.2. Dispečing bol budovaný ako redundantný 24 x 7 s vlastnosťami High Availability / Disaster Recovery: 2 aplikačné a 2 archívne servery na hlavnej lokalite, 1 aplikačný a 1 archívny server na niekoľko kilometrov vzdialenej záložnej lokalite. Aj sieťové segmenty boli zdvojené. Komunikácia s technológiou prebiehala jednak po sériových linkách a jednak po WAN sieti. Niektoré nakomunikované technologické zariadenia a lokálne riadiace systémy boli aj 200 km vzdialené.

Obrázok 1 - riadiaci systém má takmer 17 tisíc meraných bodov

V minulosti bol v rámci SCADA systému, asi po desiatich rokoch prevádzky, vymenený morálne zastaraný hardvér a nahradený HP servermi postavenými na procesoroch Itanium. Operačný systém vtedy zostal OpenVMS, akurát novšia verzia 8.4. Archívne, logovacie a aj konfiguračné databázy boli migrované na Oracle 10.2.0.4, neskôr aktualizované na Oracle 10.2.0.5.

Obrázok 2 - archiváciu zabezpečuje vyše 26 tisíc archívnych objektov, vrátane štruktúrovaných

Tento rok (z dôvodu zastarania infraštruktúry na báze Intel Itanium + Operačný systém OpenVMS) bola naplánovaná výmena hardvéru spojená so sťahovaním serverov do nových priestorov. Tentokrát sa jednalo o kompletnú výmenu technologickej platformy a okrem D2000-ky nezostal kameň na kameni. Zákazník si presadil prechod na servery značky DELL, dohodol sa prechod na operačný systém Linux – konkrétne RedHat - a ako databázovú platformu sme zvolili PostgreSQL verzie 11 (aj pre archívnu, logovaciu a aj konfiguračnú databázu). A na vrchu SCADA migrovaná na samozrejme najnovšiu IPESOFT D2000 Linux v 12.1. Takže – ako to prebiehalo?

Príprava

Dôkladná a dôsledná príprava na migráciu je základom úspechu. Najmä keď meníte celý technologický stack. V rámci prípravy boli nainštalované nové servery a pripojené do technologickej siete – na dočasných adresách, z ktorých nebolo možné komunikovať s technológiou. Bola vykonaná prvotná migrácia konfiguračnej databázy z verzie IPESOFT D2000 v9.2 na verziu 12.1 a import do PostgreSQL databázy. Podobne bola vykonaná migrácia archívov a trezorov z Oracle do PostgreSQL – toto trvalo vyše mesiaca, keďže sa jednalo o cca 1.56 TB dát od augusta 2005. Zároveň sme zmenili časové parametre trezorov – pôvodné 10-dňové trezory sme premigrovali do mesačných.

Obrázok 3 - výpis zoznamu importovaných trezorov za 170 mesiacov

Kvôli inému spôsobu štartovania procesov na platforme OpenVMS (pomocou štartovacích DCL skriptov) bolo nutné ručne upraviť konfiguráciu automaticky štartovaných procesov a nastaviť im príslušné parametre. Podobne bolo nutné upraviť profylaktický systém IPESOFT SysProf a pridať doň moduly na monitorovanie operačného systému RedHat a serverov firmy DELL.

Testovanie

Prípravu na migráciu sme vykonali už v prvej polovici augusta. Následne boli nové servery pripojené pomocou transparentného D2000 Gatewaya k produkčnému systému. D2000 Gateway bol nakonfigurovaný, aby prenášal hodnoty všetkých objektov z komunikácie, hodnoty štruktúrovaných premenných, užívateľských premenných a vypínačov. Prepojenie zároveň zabezpečilo, že D2000 Archívy nového systému priebežne ukladali hodnoty objektov.

Dispečeri a ostatní užívatelia riadiaceho systému mohli následne otvárať schémy so živými hodnotami a testovať funkčnosť nového systému (s výnimkou ovládania). Reálne dáta z komunikácie pomohli otestovať aj výkon nových serverov.

Počas testovania neboli spustené D2000 KOM procesy (hodnoty meraných bodov sa prenášali cez D2000 Gateway) a EVH procesy (aby neovplyvňovali produkčný systém napr. zápisom do externej databázy).

Administrátori nakonfigurovali a spustili aj separátny KOM proces a na ňom niekoľko vzorových komunikácií rôznych typov (napr. IEC-104). Takto overili funkčnosť komunikačných protokolov v novej verzii. Čo sme overiť nedokázali, bol protokol ICCP/TASE-2. Táto komunikácia v produkčnom systéme prebiehala iba s jediným partnerom, aj to zahraničným, ktorý nám nedokázal zabezpečiť zariadenie, voči ktorému by bolo možné testovacie spojenie vytvoriť.

Výmena

Deň pred samotnou výmenou sa vykonal reimport konfiguračnej databázy – keďže počas augusta a septembra prebiehali na produkčnom prostredí konfiguračné zmeny. Následne boli pomocou XML importu modifikované všetky potrebné objekty (komunikačné procesy a pod).

V deň výmeny bol produkčný systém uvedený do stavu, keď aplikácia bola spustená iba na jednom node (server ScadaB). Novému serveru ScadaA boli nastavené produkčné IP adresy a bola spustená aplikácia – zatiaľ bez D2000 KOM a D2000 EVH procesov. Cez transparentný D2000 Gateway bola nová aplikácia pripojená k produkčnej, takže až do prepnutia mali všetky objekty aktuálne hodnoty.

Dispečeri si spustili aj nové HI (Human Interface) a pripojili sa cezeň k novému systému.

Samotné prepínanie bolo v zásade jednoduché a trvalo asi minútu. Kolega povypínal D2000 KOM a D2000 EVH procesy na pôvodnom systéme (a zakázal ich automatické štartovanie). Ja som pozapínal tieto procesy na novom systéme a nastavil automatické štartovanie.

Starý server ScadaB sme aj s aplikáciou nechali spustený – ako zálohu, keby bolo nutné sa rýchlo vrátiť naspäť. Navyše bol určený ako záloha pri ďalšej diagnostike prípadných „neplánovaných” problémov, ktoré by sme museli riešiť okamžite po prepnutí. O čo sa jednalo?

Niektoré archívne objekty nemali dáta. Zistili sme, že to boli archívy plnené zo skriptu. A keďže EVH procesy neboli na novom prostredí spustené, nemal ich kto plniť. Riešenie? Dosynchronizovanie príslušných objektov. Vďaka dobre navrhnutej mennej konvencii boli tieto objekty identifikované pomocou niekoľkých menných masiek. Utilita D2000 arcsynchro, ktorá slúži na plátanie dier v archíve, bola následne spustená so zadaním týchto menných masiek – trikrát, keďže sme potrebovali dosynchronizovať skriptom plnené objekty do troch redundantných archívov.

Jedna či dve komunikácie mali niekoľkominútové výpadky. Analýzou logov komunikácie sme zistili, že došlo k rozpadu sieťového spojenia. D2000 KOM proces sa ho niekoľko minút snažil neúspešne vytvoriť a až následne sa mu to podarilo. Chyba teda nebola na našej strane, ale niekde vo WAN sieti.

Obrázok 4 - OpenVMS pomaly odchádza na smetisko dejín ...

Hodnoty niektorých objektov na schémach sa zobrazovali trochu iným spôsobom ako v starom systéme (napr. namiesto hodnoty 1.00 sa zobrazila iba hodnota 1). Analýza ukázala, že pri preklápaní konfiguračného súboru aplikácie (obdoba registry nastavení vo Windows) nebola nastavená hodnota aplikačného parametra OldMasks na True. Následná detailná kontrola ukázala ešte niekoľko marginálnych rozdielov v konfigurácii, ktoré boli napravené. Napr. parameter dynamGraphDescTable, ktorý riadi zobrazenie popisnej tabuľky pri ad-hoc otvorenom dynamickom grafe, bol vypnutý.

Keď už bolo overené, že po migrácii funguje riadiaci systém dobre a spoľahlivo, zmenili sme IP adresy na produkčné aj na druhom novom serveri ScadaB, takže nový systém mal už aj aplikačnú redundanciu. Na porovnávanie dát starej a novej aplikácie sme spustili aplikáciu na starom serveri ScadaC na záložnom dispečingu. Nový server ScadaC zatiaľ bežal na neprodukčných IP adresách s tým, že v rámci redundancie mal nastavenú prioritu 0, aby sa automaticky nestal aktívnym on (kvôli IP adresám by bola komunikácia nefunkčná), ale iba ScadaA a ScadaB s produkčnými adresami. Mali sme ešte v pláne prideliť starému serveru ScadaC neprodukčné IP adresy, aby mohol byť pre istotu ešte stále spustený – pokiaľ by sa vyskytol nejaký problém, bude ľahšie preveriť, či existoval už pred migráciou, alebo je dôsledkom upgradu.

Ďalšie dni sme otestovali funkčnosť prepnutia redundancie zo ScadaA na ScadaB, vykonali sme preškolenia administrátorov na D2000 Linux V12.1 – operácie ako spustenie a vypnutie aplikácie alebo archívu, zistenie stavu aplikácie a spustených procesov, vykonanie zálohy a obnovy databáz, atď.

Záver

Vzhľadom na to, že upgrade zahŕňal generačnú výmenu riadiaceho systému po mnohých rokoch, výmenu hardvérovej platformy, operačného systému a databázovej platformy ako aj upgrade IPESOFT D2000 z verzie 9.2 na verziu 12.1, hodnotím priebeh výmeny ako veľmi hladký. K tomuto výsledku určite vo vysokej miere prispela kvalitná projektová príprava, dobrá kooperácia nášho tímu so samotným zákazníkom a dôkladné viacnásobné testovanie jednotlivých krokov migrácie ako aj simulácia celého priebehu migrácie „nanečisto“ s dôrazom na minimalizáciu rizík, náhod a prekvapení, keďže sa jednalo o kritický SCADA systém. Čo je ešte dôležitejšie – podobne to videli aj aplikační správcovia zákazníka, ktorí majú s platformou IPESOFT D2000 skoro 20 ročné skúsenosti.

Zákazníkovi výmena priniesla všetky výhody najnovšej verzie D2000. Zároveň už nemusí servisovať dosluhujúce Itaniové servery a ušetrí aj na spotrebe energie.

‍

Migračná cesta z IPESOFT D2000 OpenVMS a IPESOFT D2000 HP-UX na IPESOFT D2000 Linux verziu 12.1 je k dispozícii aj našim ďalším zákazníkom, ktorí prevádzkujú riadiace dispečingy kritického významu na technológii IPESOFT D2000.