.png)
info@ipesoft.com
+421 907 703 854
Obchodná 9076/3D
010 08 Žilina
Slovensko
SK
27.5.2025
SCADA úvahy - (skrytá) cena štandardov
%20cena%20%20%C5%A1tandardov.png)
Scada úvahy - (skrytá) cena štandardov
Dnes by som sa chcel pozrieť bližšie na modularitu SCADA systémov, štandardizáciu rozhraní medzi modulmi a jej vzťah k funkčným vlastnostiam. Na začiatku krátky príbeh:
Bývalý spolužiak prišiel ku nám pracovne do firmy. Následne sme sa rozprávali o problémoch, ktoré momentálne rieši (používal jeden nemenovaný americký SCADA systém). Potreboval, aby po ručnej úprave archivovaných hodnôt užívateľom vykonal archívny subsystém (historian) prepočet štatistík nad týmito hodnotami.
Chvíľu mi trvalo, kým sme si ujasnili, že dotyčný archívny subsystém počíta štatistiky na hrane časového intervalu (napr. minúty alebo hodiny). Následná korekcia hodnôt užívateľom (prípadne príchod oneskorených hodnôt z komunikácie) automaticky nevyvolá žiadnu akciu archívneho subsystému. Prepočty musia byť „vynucované“ ručne – treba teda vedieť, hodnoty akých objektov užívateľ menil, zistiť, ktoré objekty na zmenených objektoch závisia, a nakoniec vynútiť prepočet.
V aplikačnom serveri reálneho času D2000 je správanie odlišné – pokiaľ majú štatistické a vypočítané archívne objekty nakonfigurované priebežné výpočty (parameter Výpočet na hodnote Priebežný), tak D2000 Archív dohliada na udržovanie konzistencie hodnôt týchto archívnych objektov s hodnotami ich zdrojových archívov. Pri korekcii hodnoty (užívateľom alebo zo skriptu) primárneho archívu sa automaticky prepočítajú všetky archívne objekty, ktoré sú na ňom závislé.
Ďalším scenárom, ktorý spôsobí prepočet archívnych objektov v D2000, môže byť napríklad dočítanie hodnôt z komunikácie pomocou príkazu GETOLDVAL. Pod týmto si môžete predstaviť vyčítanie hodnôt z dataloggera (napr. komunikačný protokol ESC8816) alebo z elektromera (protokol IEC 62056-21:2002 Serial).
Inou možnosťou je dočítanie starých hodnôt z iného SCADA systému postaveného na D2000 technológii a prepojeného pomocou procesu D2000 Gateway. Takéto dočítanie je užitočné napríklad po výpadku komunikácie medzi dvoma SCADA systémami.
Prečo tento príklad spomínam? Je to ukážka toho, ako môže homogenita (v zmysle, že všetky časti SCADA systému – komunikačný aj archívny subsystém – pochádzajú od rovnakého výrobcu) pomôcť pri implementovaní nadštandardnej funkcionality.
Ak máme subsystémy od rôznych výrobcov, pracujúce na základe štandardného rozhrania, a vznikne požiadavka na takúto rozšírenú funkcionalitu (ktorá nie je podporená rozhraním), môže byť problém ju implementovať.
Nechápte ma zle – štandardizované rozhrania sú skvelá vec. Ale myslím si, že SCADA systém by ich mal používať smerom von. Nie smerom dovnútra – medzi svojimi komponentami či modulmi. Vidím tu paralelu k otázke, prečo Linux nemá stabilné kernel rozhranie pre ovládače. Ako sa píše v dokumentácii, vývoj Linuxového kernela (opravy chýb, optimalizácie, pridávanie nových vlastností) prirodzene vedie k úpravám rozhrania ovládačov, ktorým sa ovládače musia prispôsobiť.
Podobne, vylepšenia, opravy a implementácia nových vlastností v SCADA systéme by nemali byť blokované stabilizovanými („zamrznutými“) rozhraniami.
Pokiaľ súhlasíte s touto argumentáciou, ponúka sa logický dôsledok. Čím väčšiu časť požiadaviek zákazníka dokáže SCADA systém splniť „vlastnými silami“, a teda bez pomoci produktov tretích strán (a obmedzení rozhraní), tým lepšie a efektívnejšie môže implementovať novú funkcionalitu a nové optimalizácie.
Uvediem príklady, ktoré sa tiež budú týkať archivácie.
D2000 Archív je jediný proces, ktorý má prístup k archívnej databáze (výnimka je utilita arcsynchro, ktorá slúži na plátanie dier v redundantných archívov a v aktuálnom kontexte nie je dôležitá). Všetky ostatné rozhrania na prístup k archívnym hodnotám (D2000 JAVA API, D2000 OBJApi, D2000 ODBC Driver, D2000 OPC Server, D2000 OPC UA Server, D2000 VBApi, D2000 WorkBook) využívajú služby D2000 Archívu – podobne ako ich využívajú aj iné procesy pre čítanie alebo zápis historických hodnôt. Táto vlastnosť umožnila okrem iného:
- Zmenovú archiváciu periodických hodnôt – jedná sa o optimalizáciu ukladania periodických hodnôt. Ak sa hodnoty v čase nemenia, uloží sa iba prvá hodnota s časovou značkou, čo šetrí miesto v archívnej databáze, ako aj výkon archívneho servera. Pri čítaní musí prebehnúť „dekompresia“ – vygenerovanie opakovaných hodnôt.
- Implementáciu izochrónnej cache v archíve – ak je k dispozícii dostatok RAM, časť je možné dedikovať D2000 Archívu. Ten ju použije na zapamätanie si najnovších hodnôt objektov za posledných N hodín alebo dní – v závislosti na veľkosti pamäte a na dátovom toku. Toto môže výrazne zrýchliť prístup klientov k dátam, keďže typicky sú najviac čítané najnovšie dáta - za poslednú pracovnú zmenu, prípadne za posledný deň.
- Podporu komprimovaných trezorov na platforme PostgreSQL v D2000 verzii 22. Trezorová databáza je vlastnosť D2000 Archívu, ktorá umožňuje časovo neobmedzenú archiváciu hodnôt. Podľa konfigurácie sa napr. každých 30 dní vytvorí nová trezorová databáza, napĺňa sa a po naplnení sa buď odpojí, alebo ostane prístupná na čítanie. Komprimácia trezorov spočíva v optimalizovaní ich dátovej štruktúry po naplnení, pričom dôjde k výraznej úspore miesta (vlastnosť využíva okrem iného aj TOAST technológiu implementovanú v PostgreSQL na ukladanie veľkých polí). Komprimované trezory sú bežne 10-krát menšie ako pôvodné trezory – čo je podstatná úspora miesta (a spojených nákladov), keď uvážime, že sa jedná dáta, ktorých veľkosť stále iba narastá a niektorí naši zákazníci majú už viac ako 10 TB trezorov.
Pekným príkladom z inej oblasti je aj firma Oracle. Pôvodne výrobca zrejme najpokročilejšej SQL databázy vykonal sériu akvizícií (včítane firmy SUN) a získal tak celý technologický „stack“, ktorý môže optimalizovať a ponúkať zákazníkom – od hardvéru, cez operačný systém, jazyk Java, databázovú technológiu, až po nástroje typu ERP, CRM a SCM. Mimochodom, keď spomíname SQL, čo je tiež štandard – asi každá SQL databáza má vlastné rozšírenia SQL jazyka, implementujúce vylepšenia a nové vlastnosti, ktoré štandard neobsahuje...
Záver
V závere iba zopakujem, čo som už napísal vyššie. Čím väčší záber má SCADA systém a čím viac funkcionality dokáže pokryť „vlastnými silami“, tým širší priestor má na optimalizácie a implementovanie vlastností, ktoré vyžadujú koordinovanú spoluprácu jednotlivých modulov SCADA systému. Vývojári sa môžu sústrediť na dodávanie prínosnej funkcionality zákazníkovi a nie na premýšľanie, ako presvedčiť treťostranné komponenty, aby nové vlastnosti podporili, a ako obísť obmedzenia existujúcich štandardných rozhraní.
10.5.2021, Ing. Peter Humaj, www.ipesoft.com
Iné blogy