info@ipesoft.com
+421 907 703 854
Obchodná 9076/3D
010 08 Žilina
Slovensko
SK
26.3.2024
SCADA architektúra-DODM
SCADA architektúra - DODM
Toto je druhý zo série blogov ohľadne architektúry SCADA systémov. Chcel by som sa v nich venovať dôležitým vlastnostiam SCADA technológií, ktorých prítomnosť (alebo absencia) ovplyvňuje funkčnosť, užívateľskú prívetivosť, použiteľnosť a škálovateľnosť týchto technológií. Tento blog bude o dynamickom objektovom dátovom modele (DODM).
Čo je to DODM?
Keď v roku 1993 začala malá skupina ľudí z praxe (so skúsenosťami s vývojom a nasadzovaním riadiacich systémov, práce s operačným systémom RMX, znalosťami minipočítačov SMEP) vyvíjať technológiu D2000, prvého pol roka robili iba na dôkladnom dizajne – až potom začali programovať. Ich návrh čerpal z ich predchádzajúcich skúseností – najmä sa snažili vyvarovať sa chýb, ktorými trpeli riadiace systémy a softvérové projekty, na ktorých robili v minulosti.
Technológiu, ktorú navrhli, nazvali DODM. Čo jednotlivé slová znamenajú?
Dynamický – konfigurácia Ipesoft D2000 aplikácií prebieha na živom systéme. Nie je nutné ho kvôli aplikácii zmien reštartovať. Aby som bol úplne presný, v niektorých situáciách môže byť nutné reštartovať komunikačný proces (napr. zmena typu komunikačnej linky zo sériovej na UDP), ale aj tomuto sa dá vyhnúť zmenou konfiguračného postupu.
Objektový – konfigurácia aplikácie sa skladá z objektov. Objekty sú rôznych typov (meraný bod, stanica, linka, počítaný bod, archivovaná hodnota, proces ...). Okrem statických objektov (existujúcich v konfigurácii) existujú aj dynamické – napr. zoznam objektov otvorený z konfiguračného nástroja, ovládací dialóg pre nastavovanie hodnoty objektu alebo zoznam alarmov.
Dátový Model – konfigurácia aplikácie je v pamäti D2000 Servera. Skladá sa z objektov a zo vzťahov medzi nimi. Medzi objektami existujú dva základné typy vzťahov:
• Rodič – potomok
• Objekt X používa objekt Y
Keďže konfigurácia objektov prebieha na živom systéme, je dôležité, aby nedošlo k pokazeniu konfigurácie – napríklad tým, že uživateľ zmaže objekt, ktorý má potomkov (a stanú sa z nich siroty) alebo zmaže objekt, ktorý je používaný iným objektom (a tento objekt prestane korektne fungovať). Preto dôležitá vlastnosť, ktorú Ipesoft D2000 implementuje ako nutnú podmienku konzistencie DODM, je takzvaná referenčná integrita, ktorej sa venoval predchádzajúci blog: objekt sa nedá zmazať, ak je rodičom iných objektov, prípadne ak ho iné objekty používajú.
Vzťah rodič – potomok
Každý objekt v D2000 má svojho rodiča. Na najvrchnejšej konfigurovateľnej úrovni sú procesy (ich rodič je objekt SYSTEM). Procesy sa starajú o svojich potomkov, napríklad:
• Komunikačné procesy (D2000 KOM) majú potomkov komunikačné linky, tie majú komunikačné stanice a tie merané body. Komunikačné procesy sú zodpovedné za komunikáciu s okolím (PLC, RTU, iné SCADA/MES systémy).
• Výpočtové procesy (D2000 CALC) majú potomkov počítané body a sú zodpovedné za realizáciu výpočtov (periodických, zmenových).
• Archívne procesy (D2000 ARCHIV) majú potomkov archivované hodnoty a sú zodpovedné za archivovanie hodnôt (primárnych, štatistických, vypočítaných, skriptom plnených) a čítanie hodnôt z archívnej SQL databázy.
• Databázové procesy (D2000 DbManager) majú potomkov databázy, tie majú tabuľky. Sú zodpovedné za prácu s SQL databázami (čítanie/zápis/práca s BLOBmi/spúšťanie SQL príkazov a volanie SQL procedúr).
• Interpretery skriptov (D2000 Event Handler) majú potomkov skripty – eventy (napísané v D2000 ESL alebo v jazyku Java) a ich úlohou je ich vykonávať (na trigger, prípadne ako permanentne bežiaci serverovský skript).
• Klientske procesy, tj. konfiguračný nástroj (D2000 CNF), grafický editor (D2000 GrEditor) a proces užívateľského rozhrania (D2000 HI) nemajú potomkov, ale môžu otvárať objekty. Napríklad HI otvára schémy, grafy, zostavy, ale aj merané body – buď priamo v browseri alebo ako dôsledok otvorenia schémy, ktorá meraný bod používa.
Procesy
V predchádzajúcom zozname som zámerne procesy uvádzal v množnom čísle. V novej aplikácii je predkonfigurovaný napr. iba jeden komunikačný proces (SELF.KOM), ale je možné vytvoriť ďalšie (napr. OTHER.KOM, REMOTE.KOM a podobne), pričom tieto procesy môžu byť spustené lokálne alebo na vzdialenom počítači. Po štarte a pripojení sa k D2000 Serveru od neho získajú zoznam potomkov a môžu začať pracovať. To isté platí aj pre ostatné typy procesov. Vzťah rodič-potomok tak umožňuje rozdeliť objekty do skupín obsluhovaných samostatnými procesmi, ktoré môžu byť presunuté na samostatné servery - napr. kvôli distribúcii výkonu alebo v prípade komunikačného procesu kvôli fyzickej topológii – KOM proces môže byť umiestnený na vzdialenej lokalite, zbierať autonómne dáta aj v prípade výpadku sieťového pripojenia a po obnovení spojenia ich odoslať na D2000 Server (tento režim sa nazýva KOM Archív).
Jadro systému – proces D2000 Server – je zodpovedné za posielanie nových hodnôt objektov procesom, ktoré ich potrebujú. „Potreba“ mohla vzniknúť staticky (je súčasťou konfigurácie – napríklad meranú hodnotu potrebuje archivovaná hodnota a počítaný bod) alebo dynamicky (vznikla v dôsledku otvorenia objektu – napríklad meranú hodnotu potrebuje schéma otvorená v proces Human Interface alebo dynamický zoznam objektov otvorený v konfiguračnom nástroji D2000 CNF).
Identifikácia objektov
Objekty v Ipesoft D2000 majú tri rôzne typy identifikátorov:
• Textové meno
• Numerický identifikátor (HOBJ – Handle of Object)
• Unikátny identifikátor (UID)
Vnútorne Ipesoft D2000 používa numerické identifikátory (HOBJ), ktoré prideľuje D2000 Server pri vytvorení objektu a následne sa nikdy nemení. Preto je možné objekt premenovať bez rozbitia referenčnej integrity (a bez potreby aktualizovať meno objektu vo všetkých objektoch, ktoré ho používajú). Zaujímavosťou je, že aj v skriptoch (ESL skripty a Java) sa vnútorne nahrádza meno objektu (zadané užívateľom) príslušným HOBJ.
Pozor – ak je meno objektu „vynesené“ von z D2000 (napr. cez OPC Server či OPC UA Server, prípadne do treťostranných softvérov pomocou OBJApi alebo do Excelu pomocou VBApi), tak premenovanie objektu spôsobí jeho nedostupnosť z externého prostredia!
Meno objektu sa skladá z predpony, tela a prípony. Predpona a prípona sú voliteľné a konfigurovateľné pre jednotlivé typy objektov:
Výnimkou potvrdzujúcou pravidlo sú objekty typu proces. Ich prípona je určená typom procesu, napr. KOM (D2000 KOM), CLC (D2000 CALC), EVH (D2000 Event Handler), DBM (D2000 DbManager), HIP (D2000 HI). Následne systém umožňuje vytvoriť potomka procesu podľa prípony (napr. linku pre KOM proces, počítaný bod pre CLC alebo databázu pre DBM).
Menná konvencia je dôležitá – už pri pohľade na názov objektu je možné odlíšiť napr. vypočítaný bod (M.nieco) od počítaného bodu (P.nieco), štruktúrovanej premennej (SV.nieco) alebo užívateľskej premennej (U.nieco).
Unikátny identifikátor (UID) vznikol pri podporení XML Exportu a XML Importu objektov. Umožňujú rozlíšiť, či objekty v dvoch rôznych systémoch majú identický pôvod (jeden vznikol importom druhého, prípadne oba importom toho istého objektu) alebo je zhoda mien iba náhodná. Okrem toho pri prepojení dvoch D2000 systémov pomocou transparentného gatewaya je možné identifikovať objekty na základe UID (štandardná identifikácia je podľa mena), takže je možné objekty premenovať bez straty funkčnosti D2000 Gatewaya. Viac informácií – viď blogy o prepojení viacerých SCADA systémov a o aplikačnom module SysMirror. Systémové objekty majú „pekné“ UID, ostatné majú štandardné 16-bajtové čísla, vyjadrené ako 32-znakové reťazce (UUID).
Objekty sa dajú v D2000 filtrovať na základe vzťahu k rodičovi (zobrazenie potomkov konkrétneho objektu), masky pre meno objektu a na základe typu objektu. Navyše sa dajú objekty zaraďovať do hierarchie logických skupín a filtrovať podľa príslušnosti k logickým skupinám.
Komunikácia medzi procesmi
Všetky D2000 procesy sú pripojené k procesu D2000 Server a cezeň aj komunikujú. Nasledujúci obrázok ukazuje pripojenie niekoľkých serverovských procesov (modré) a procesov užívateľského rozhrania (oranžové) a komunikáciu D2000 Servera s konfiguračnou databázou (pri štarte z nej načíta konfiguráciu aplikácie a následne ukladá všetky konfiguračné zmeny).
Redundancia
D2000 podporuje viacero typov redundancie. V tomto blogu uvediem tri, ktoré sa týkajú DODM, viac informácií je v blogu o redundancii.
Redundancia sietí – vzdialené procesy (napr. D2000 HI) môžu byť k D2000 Serveru pripojené cez dve nezávislé siete, t.j. dvoma TCP spojeniami. Aj aktívne spojenie zlyhá, nepotvrdené dáta sa prepošlú záložným spojením, takže dôjde iba k niekoľkosekundovému „zamrznutiu“ dát.
Redundancia aplikačného servera –prevádzkovanie dvoch a viac aplikačných serverov spojených do tzv redundantnej skupiny. Každý aplikačný server je spustený na inom fyzickom počítači. Jeden z nich je aktívny - “HOT”, všetky ostatné sú pasívne – “SBS” (standby servery). Tieto prijímajú od HOT servera zmeny v konfigurácii a hodnotách objektov tak, aby v každom okamihu obsahovali aktuálne dáta a boli pripravené prevziať rolu HOT servera.
K aktivácii SBS servera dochádza automaticky v dôsledku nedostupnosti HOT servera alebo riadenie prepnutím redundancie administrátorom (prípadne príkazom zo skripu). Klienti môžu byť konfigurovaní na automatické pripojenie k novému HOT serveru. Spravidla sú takto konfigurované vzdialené procesy (D2000 HI) a inštančné procesy (D2000 KOM, D2000 Archiv).
Redundancia procesov – serverové procesy môžu byť spustené ako tzv. inštancie. Namiesto SELF.KOM sa spustia napr. inštancie 1 a 2 (t.j. [1]SELF.KOM a [2]SELF.KOM). Inštancií procesu môže byť až 15. Jedna inštancia je vždy aktívna a ostatné pasívne. Výber aktívnej inštancie riadi D2000 Server a dá sa nastavovať aj zo skriptu. Funkčnosť aktívnej inštancie je normálna, funkčnosť pasívnej záleží od typu procesu:
• D2000 DbManager, D2000 Event Handler – pasívna inštancia nič nerobí
• D2000 KOM – väčšina komunikačných protokolov je pasívna, v prípade niektorých (napr. IEC 870-5-104) je chovanie parametrizovateľné.
• D2000 Calc – pasívna inštancia počíta hodnoty počítaných bodov kvôli nastavenia vnútorných stavov (napr. funkcia %PrevV alebo implementácia časového filtra), ale neposiela hodnoty procesu D2000 Server.
• D2000 Archiv – pasívna inštancia archivuje hodnoty, požiadavky na čítanie hodnôt vykonáva iba aktívna inštancia.
Inštancie toho istého procesu sú spravidla spustené na rôznych fyzických počítačoch.
Redundancia sietí umožňuje aj údržbu sieťových komponentov počas prevádzky (výmena, aktualizácia firmware a pod). Redundancia procesov a aplikačného servera umožňuje počas prevádzky vykonávať údržbu počítačov, aktualizácie firmware, aktualizácie operačných systémov (včítane reštartov), aktualizácie databáz a samotneho systému Ipesoft D2000. Štandardne sa používa redundancia s dvoma D2000 Servermi a dvomi inštančnými procesmi D2000 Archiv (ktoré sa pripájajú k HOT serveru), v niektorých prípadoch aj trojitá redundancia (dva servery a dva inštančné procesy na hlavnej lokalite, jeden na záložnej).
Záver
Dobrý a kvalitný návrh architektúry SCADA systému je kriticky dôležitý nielen pre jeho správne a optimálne fungovanie, ale aj pre jeho dlhodobý rozvoj a rozširovanie jednak samotného SCADA systému a jednak aplikácií, ktoré sú ňom postavené. V prípade aplikačného servera reálneho času Ipesoft D2000 od návrhu uplynulo už 30 rokov, počas ktorých sa rozvíjal a rástol v súlade s požiadavkami čoraz väčších a dôležitejších aplikácií, do ktorých bol nasadzovaný. Aj samotné aplikácie časom rastú a sú rozvíjané – viaceré z tých veľkých už vyše 20 rokov. Technológia DODM s vlastnosťami ako referenčná integrita, redundancia, XML export a import umožňujú stabilné prevádzkovanie veľkých priemyselných riadiacich systémov a riadenie kritickej infraštruktúry (výroba a distribúcia elektrickej energie, plynárenské dispečingy, vodárenské dispečingy, tepelné hospodárstvo a iné). Ipesoft D2000 si dokázal získať a udržať dôveru našich zákazníkov a partnerov – a verím, že cenné služby im bude preukazovať aj v ďalších rokoch a desaťročiach.
19.10.2023, Ing. Peter Humaj, www.ipesoft.com
Iné blogy