%20cena%20%20%C5%A1tandardov.png)
info@ipesoft.com
+421 907 703 854
Obchodná 9076/3D
010 08 Žilina
Slovensko
SK
29.9.2025
SCADA verzus relačné databázy
SCADA verzus relačné databázy
Dnes nechcem písať o tom, aké rôznorodé využitie majú relačné (SQL) databázy v SCADA a MES systémoch, o tom bol iný blog. Dnes sa chcem zamyslieť nad jednou absolútne základnou vlastnosťou, bez ktorej si dnes asi ťažko niekto dokáže predstaviť databázovú aplikáciu. Jedná sa o referenčnú integritu.
Čo tento pojem znamená? Jednoducho povedané, pokiaľ záznam v tabuľke A obsahuje index do tabuľky B, tak tento index musí byť buď prázdny (null), alebo ukazovať na konkrétny (existujúci riadok) v tabuľke B.
SQL databázy na definíciu referenčnej integrity používajú cudzie kľúče (foreign keys), pomocou ktorých sa vytvára väzba medzi tabuľkami.
Obrázok z Wikipédie ukazuje, čo by sa stalo, keby databázový systém nevynucoval referenčnú integritu. V zozname albumov by mohol existovať riadok ktorého pole artist_id by ukazovalo na neexistujúci záznam v tabuľke autorov. Dáta by tak boli „rozbité“ a chybné.
Pokiaľ sú zadefinované cudzie kľúče, relačná databáza zabezpečuje, že nikdy nemôže dôjsť k vyššie uvedenému stavu. Referencovanému záznamu nie je možné zmeniť jeho kľúčový identifikátor, prípadne ho celý vymazať – s výnimkou zadefinovaného kaskádneho mazania, pri ktorom sa mažú aj príslušné záznamy z tabuliek, ktoré tento záznam referencujú (klauzula ON DELETE CASCADE v SQL syntaxi).
Integritu teda nie je potrebné komplikovane strážiť na úrovni aplikácie, ale zabezpečuje ju priamo SQL databáza.
A teraz poďme k SCADA (či MES) systémom. Obsahujú rôzne typy objektov, niekedy sa používa aj terminológia tagy (napr. merané body, počítané body, schémy, grafy, komunikačné stanice, bitmapy, skripty ...), medzi ktorými sú tiež rôzne vzťahy (relácie). Napríklad schéma používa meraný bod, bitmapu a graf. Výstupný meraný bod môže používať počítaný bod a zverejňovať jeho hodnotu (zapisovať ju do komunikácie). Počítaný bod môže používať iné merané body, pamäťové premenné (užívateľské premenné, štruktúrované premenné) a ďalšie objekty na výpočet hodnoty.
A teraz zásadná otázka: Dokáže SCADA systém strážiť referenčnú integritu podobne ako to robí SQL databáza? Dokáže zabrániť vymazaniu objektu, ktorý je používaný iným objektom? Dokáže zabrániť premenovaniu objektu (z rovnakého dôvodu)?
Pre väčšinu systémov platí odpoveď: Ich autori si uvedomujú zásadnosť problému a snažia sa ho riešiť ... a pre konkrétne situácie sa im to aj darí :-).
Dokážu napríklad zabrániť vymazaniu objektu (tagu), ktorý je zobrazený v schéme či alarme, alebo aspoň pomôcť užívateľovi nájsť referencie, pokiaľ chce zistiť, či je objekt používaný.
Napríklad WinCC má kontrolu konzistencie (consistency check), ktorá identifikuje, či a kde je objekt použitý. Užívateľ tak môže explicitne pred mazaním skontrolovať, či je mazanie ok. Podobne po premenovaní tagu je nutné vykonať kompiláciu projektu a následne vykonať kontrolu konzistencie.
Podobne to robí aj GE iFIX. Nezablokuje vždy mazanie, ale dokáže vygenerovať report so závislosťami (dependency report) pred mazaním tagu.
Ignition má napríklad pri zobrazovaní hodnôt možnosť zadefinovať väzbu medzi tagom a zobrazovacím elementom ako Direct Tag Binding (priamo zadaním mena tagu, napr. Valves/Valve4/FlowRate), v tomto prípade dokáže aj vizuálne pri editácii indikovať, že tag už neexistuje. Alebo sa použije Indirect Tag Binding (napr. Valves/Valve{intParameter}/FlowRate), ktoré môže obsahovať jeden alebo viac parametrov (v príklade {intParameter}), ktoré sa zviažu z nejakým dynamickým parametrom. Rozšírením vzniklo Expression Tag Binding, pri ktorom sa názov tagu vyskladá pomocou výrazu. Samozrejme, pre Indirect Tag Binding ani Expression Tag Binding nie je kontrola konzistencie možná.
Väčšna SCADA systémov ale zlyháva v skriptovaní. Principiálny problém je ten, že ak má identifikátor objektu v skripte textovú povahu (a teda sa môže aj vyskladať z viacerých textových reťazcov), je technicky obťažné až nemožné pri ukladaní skriptu analyzovať skript a vytvoriť zoznam všetkých použitých tagov. Je to nutné ošetriť za behu skriptu.
Napríklad WinCC, ktorý používa v jazyku VBScript funkciu SmartTags, môže pristupovať k druhému elementu poľa DB10_HMI_Data takto:
SmartTags("DB10_HMI_Data")(2)
Samozrejme je možné hľadať reťazec "DB10_HMI_Data" v skriptoch a ak je nájdený, tak sa daný objekt asi používa (ak nie je názov v zakomentovanej časti skriptu, prípadne v nejakých nepoužívaných častiach kódu). Ak nájdený nie je, stále sa môže používať, ak sa jeho názov vyskladáva z viacerých reťazcov.
Ignition je na tom podobne. Podľa dokumentácie sa číta v skripte z objektu (tagu) takto:
system.tag.readBlocking(["My/Tag/Path"]) # bez špecifikovania providera
system.tag.readBlocking(["[default]My/Tag/Path"]) # so špecifikovaním providera
Priamo v školiacom videu o tagoch sa hovorí, že presun tagov medzi providermi (ktorý mení aj identifikáciu tagu) môže narušiť väzby (bindings), skripty a iné objekty v projekte.
GE iFIX, ktorý používa VBA, je zaujímavejší prípad. Podľa dokumentácie podporuje priamy zápis (napr. do databázového tagu) so syntaxou
FIX32.NODE.AI1.F_CV = 50#
ale toto (kvôli menným konvenciám VBA a možnej kolízii s názvami objektov v iFIX-e) nie je odporúčané – preferované je použitie funkcií WriteValue a ReadValue, ktoré majú textové parametre, napr.
WriteValue "50", "AI-1"
Takže sme znovu pri textových identifikátoroch a problémoch s referenčnou integritou.
Systém AVEVA Plant SCADA (predtým Citect SCADA) umožňuje v proprietárnom skriptovacom jazyku Cicode referencovanie názvom tagu (direct references) aj cez reťazcové identifikátory (indirect references). Kontroly konzistencie (pre direct references) sa vykonávajú až pri kompilácii projektu. Pri reťazcových identifikátorov dôjde k chybe až počas behu skriptu.
Tu je výstup z ChatGPT, ktorý pre viacero SCADA systémov pripravil porovnanie.
Jediný systém, ktorý zabezpečuje kontrolu konzistencie aj v skriptoch, je ABB 800xA, čo ale nie je SCADA ale DCS (Distributed Control System) ... ktorý je navyše na úplne inej cenovej hladine.
Môžeme si tiež všimnúť, ako výber skriptovacieho jazyka a zvolený prístup k objektom ovplyvňuje aj kontrolu konzistencie.
Vychádza mi to teda tak, že väčšina SCADA systémov má implementuje referenčnú integritu iba čiastočne, prípadne ponúkajú nástroje na zistenie, či je objekt používaný – ale problém sú skripty. (Ak sa mýlim, dajte mi prosím vedieť).
Ďalším (súvisiacim) problémom je premenovanie objektov. Pri životnosti SCADA systémov, ktorá sa počíta v desaťročiach (najmä v prípade veľkých a investične náročných SCADA systémov) je logické, že dochádza k zmenám v technológii, k pridávaniu nových zariadení, k vyraďovaniu starých, k reorganizáciám v rámci podniku ... skrátka mení sa okolité prostredie a SCADA by mala tiež reagovať - rozširovaním konfigurácie, mazaním zastaralých častí systému a prípadne aj premenovaním existujúcich, pokiaľ je to užitočné. A tu narážame na ten istý problém s referenčnou integritou. Ak sa používajú textové identifikátory, ako ich premenujeme bez dosahu na aplikáciu, pokiaľ nevieme, kde všade sú použité?
V aplikačnom serveri reálneho času Ipesoft D2000, ktorý je možné použiť na tvorbu SCADA/MES/EMS a iných systémov, je referenčná integrita základom dizajnu. Jadro systému (proces D2000 Server) sústavne mapuje a udržiava referenčnú integritu celej konfigurácie, včítane skriptov – tie môžu byť v jazyku ESL (súčasť návrhu D2000) alebo v jazyku Java. Pri ukladaní objektov a skriptov sa analyzujú a mapujú všetky referencie. V skriptoch sa používajú priamo identifikátory objektov (napr. schéma S.MyScheme v ESL je referencovaná priamo ako S.MyScheme, v jazyku Java sú bodky nahradené znakom dolár, a mená sú prevedené na malé písmená, takže schéma je s$myscheme).
Vnútorne sú ale referencie ukladané ako numerické identifikátory (ktoré užívateľ nevie zmeniť). Preto premenovanie objektu nespôsobí zmenu v konfigurácii iných objektov, ktoré ho používajú, pretože v ich konfigurácii je numerický identifikátor objektu a prevod na textové meno sa vykoná iba pri otvorení objektov na editáciu.
Ak teda pri editácii dôjde k tomu, že skript (alebo iný D2000 objekt) obsahuje referenciu na neexistujúci objekt, uloženie sa nepodarí, ale systém generuje chybovú hlášku. To je ekvivalent zlyhania vloženia dát do SQL tabuľky pri porušení referenčnej integrity definovanej pomocou foreign key. Podobne pri XML importe objektov (meraných bodov, schém, grafov, skriptov, atď.) je overované, či po importe bude dodržaná referenčná integrita. Ak nie, import sa neuskutoční. Pokiaľ sa importuje viacero objektov, buď sa realizuje import všetkých alebo nie je importovaný žiaden objekt (ekvivalent transakčného vkladania dát do SQL databázy). Navyše editácia objektu aj XML import prebieha online, na živom systéme. V prípade redundantného systému sa zmeny šíria od aktívneho D2000 Servera na všetky pasívne D2000 Servery v reálnom čase, takže užívateľ si väčšinu času ani neuvedomuje, že pracuje na redundantnom systéme.
Zároveň je informácia o referenčnej integrite dostupná aj užívateľovi. Ten si môže v prostredí grafického nástrojov (D2000 GrEditor a D2000 CNF) zobraziť pre každý objekt zoznam objektov, ktoré používa a zoznam objektov, ktoré ho používajú (referencujú). Jedná sa o pomôcku aj na sledovanie toku dát, užitočnú najmä vo väčších aplikáciách.
Nasledujúci obrázok ukazuje objekty, ktoré používajú meraný bod M.StA.Temp1. Sú to:
• Graf D.StA.Temps,ktorý zas používa schéma S.StA.Temperatures.
• Archivovaná hodnota H.StA.Temp1 (ktorá je použitá v grafe a zároveň vchádza do výpočtu 5-minútovej štatistiky H.StA.Temp1_5minAvg)
• Počítaný bod P.StA.TempMax, zobrazovaný schémou.
• Samotná schéma, na ktorej je meraný bod zobrazovaný.
Pomocou referenčnej integrity je teda možné sledovať tok dát (hodnoty meraných bodov vstupujúce do výpočtov, prípadne do výstupných meraných bodov), čo môže výrazne pomôcť pri ladení a riešení problémov.
Záver
Referenčná integrita v SCADA systémoch je podľa môjho názoru podobne dôležitá ako v SQL databázach. Umožňuje vybudovať, udržovať a rozvíjať funkčný SCADA systém, v ktorom nedochádza v dôsledku vymazania alebo premenovania objektov k chybám a nekonzistentnosti. Zároveň je nutnou podmienkou, ak chceme vykonávať modifikácie živého, produkčného systému, bez ohrozenia jeho funkčnosti. Je užitočnou pomôckou aj pri mapovaní dátového toku vo veľkých aplikáciách.
Aplikačný server reálneho času Ipesoft D2000 ponúka svojím užívateľom ako jeden z mála referenčnú integritu. Je to vďaka svojim tvorcom, ktorí túto užitočná vlastnosť veľmi predvídavo zahrnuli už do pôvodného návrhu systému.
24.9.2025, Ing. Peter Humaj, www.ipesoft.com
Iné blogy