Toto je prvý blog zo série úvah o viacerých aspektoch SCADA systémov. Všetky vychádzajú zo skúseností –mojich alebo kolegov. Verím, že získané poučenia môžu byť užitočné aj pre iných – implementátorov ale aj užívateľov SCADA systémov.

Tento blog sa bude zaoberať nákladmi na komunikáciu, ktoré vyplývajú z použitia treťostranných OPC alebo OPC UA serverov.

Príbeh

Dovoľte mi začať príbehom z praxe: v roku 2005 sme u zákazníka nasadzovali MES systém, ktorý potreboval komunikovať s inými SCADA systémami pomocou protokolu IEC 60870-6, tiež známym ako ICCP/TASE-2. Tento protokol sme nemali implementovaný, takže sme použili OPC server od renomovaného výrobcu. Keďže sme systém budovali ako vysokodostupný, s 2 redundantnými aplikačnými servermi, potrebovali sme zalicencovať 2 tieto OPC servery. Boli pomerne drahé (v prepočte desiatky tisíc Eur).

Nasledovalo niekoľko rokov postupného rozvoja MES systému, zvyšovania počtu užívateľov, nárastu funkcionality .. skrátka, po čase sme potrebovali nahradiť aplikačné servery novšími a výkonnejšími. Tu sme narazili – licencia OPC serverov bola viazaná na hardvér a nedala sa premigrovať. Výrobca chcel, aby náš zákazník zaplatil novú licenciu, pričom jej cena bola vyššia ako cena nového hardvéru! Nakoniec sme tento problém vyriešili “inžiniersky“. Staré aplikačné servery sa používali ďalej ako dedikované komunikačné servery. Zákazník bol na jednej strane spokojný, že nemusel kupovať drahé licencie, na druhej strane musel ešte niekoľko rokov prevádzkovať staré servery. Vznikali náklady na prevádzku (napájanie, chladenie) a údržbu (čistenie, profylaktika, patchovanie).

Do ďalšej generačnej obmeny sme protokol ICCP/TASE-2 podporili v D2000.

OPC (UA) vládne všetkým

Integrátorom, nasadzujúcim SCADA systémy, sa bežne stáva, že sa stretnú s protokolom, ktorý nimi používaná SCADA nepodporuje. Čo je najjednoduchším a najrýchlejším riešením? Zakúpenie konvertora protokolov – vo forme OPC alebo OPC UA servera. Stačí nakonfigurovať a problém je vyriešený. Alebo nie?

Dovoľte mi ponúknuť niekoľko argumentov, ktoré demonštrujú nevýhody použitia treťostranných OPC (UA) serverov.

Nákupná cena OPC servera. Ak potrebujem iba jednu inštanciu OPC servera, cena môže byť nízka. Čo ak potrebujem komunikovať s viacerými zariadeniami, prípadne inštalovať OPC servery na viacerých komunikačných počítačoch? S týmto súvisí aj ďalší bod.
Licencovanie a obmedzenia. Aké množstvo zariadení alebo meraných bodov zvláda OPC server? Ak má nejaké limity (napr. 5000 meraných bodov), nehrozí ich dosiahnutie a potreba zakúpenia a inštalácie ďalšieho servera? Ako je to so záťažou CPU? Dokáže využiť viacero jadier, alebo má niekde úzke hrdlo, ktoré spôsobí, že jedno procesorové jadro je využité naplno a ostatné nemajú čo robiť?
Na ilustráciu - keď použijem protokol dostupný v Ipesoft D2000, tak licencia protokolu sa platí iba raz, bez ohľadu na počet komunikačných liniek. Každá komunikačná linka (obsluhujúca napr. jednu sériovú alebo TCP či UDP linku s viacerými stanicami) má vlastný obslužný task (v prípade niektorých protokolov dokonca 2 tasky (prijímací/posielací), či viacero (napr. pre IEC-104 server alebo pre IEC-101 na redundantných linkách), takže rozsiahla konfigurácia dokáže využiť veľa CPU.
Pokiaľ rozdelím komunikáciu na viacero D2000 KOM procesov (či už v rámci jedného aplikačného servera, alebo na vzdialených komunikačných serveroch napr. kvôli funkcionalite KOM Archív), je nutné kúpiť licenciu na každý D2000 KOM proces.
Migrácia licencií a virtualizácia. Je licencia migrovateľná (na nový hardvér a podobne)? Je možné použiť ju vo virtualizovaných prostrediach? Navýšiť výkon pridaním jadier, prípadne migráciou virtuálneho stroja na iného hostiteľa?
Konfigurácia. Nie každý si uvedomuje, že aj OPC server je potrebné nakonfigurovať. V niektorých prípadoch je konfigurácia jednoduchá. Napríklad v prípade protokolov podporujúcich autodetekciu meraných bodov a „browsovanie“ (BACnet), prípadne zisťovanie konfigurácie z externého súboru (napr. Siemens OPC UA server pracujúci s konfiguráciou projektu vytvoreného nástrojom TIA Portal). Ale aj v prípade spomenutého OPC UA servera to zabralo kolegom niekoľko dní, kým ho nakonfigurovali podľa svojich predstáv (jednalo sa o fungovanie v redundantnom nasadení).
Rozširovateľnosť a riešenia s vysokou dostupnosťou. Má licencia obmedzenia na počty meraných bodov? Ako rastie cena pri potrebe rozširovania? Ak budujem systém s vysokou dostupnosťou, cena bude vyššia. Dvakrát? Viac? Záleží na konkrétnom produkte.
Navyše každú konfiguračnú zmenu bude nutné vykonať dvakrát. Prípadne exportovať konfiguráciu „primárneho“ OPC servera a importovať ju na „sekundárny“.
Zálohovanie a obnova. Určite zálohujete konfiguráciu SCADA systému. Pokiaľ používate externé OPC servery, netreba zabudnúť aj na ne. Záloha je vhodná po každej rekonfigurácii - ci už formou exportu do súboru, odzálohovaním vetvy Windows registry alebo zálohou celého (virtuálneho alebo fyzického) stroja, na ktorom OPC server pracuje.
Údržba a patchovanie. Ako distribuuje výrobca OPC servera záplaty na zistené funkčné alebo bezpečnostné problémy? Je to platená služba? Závisí cena od počtu (a rozsahu) licencií? Ako dlho je garantované poskytovanie záplat?
Kompatibilita a väzba na platformu. Keď (Nie ak, ale keď!) si zákazník vyžiada prechod na novú verziu operačného systému (štandardne pri výmene hardvéru, ale môže k tomu dôjsť aj skôr napr. z dôvodov ukončenia podpory OS), bude k dispozícii OPC server podporujúci túto verziu? Ako je to s migráciou licencií? S migráciou konfigurácie na novšiu verziu OPC servera?
V prípade OPC UA serverov, ktoré na rozdiel od OPC serverov nie sú viazané na platformu Windows: je k dispozícii verzia pre inú platformu? Napríklad Linux, prípadne platforma ARM? Pokiaľ bude chcieť zákazník v budúcnosti migrovať SCADA systém na Linux, nebude obmedzený nedostupnosťou OPC UA servera a nutnosťou prevádzkovať kvôli nemu dedikovaný Windows server?
Prispôsobovanie a úpravy. OPC server býva uzatvorený balík. Ponúka ten, ktorý ste si vybrali, možnosť implementovať nové vlastnosti alebo prispôsobiť chovanie komunikačného protokolu prípadnému neštandardnému chovaniu zariadenia? Čo ak natrafíte na nejaké problémy - napr. presakovanie pamäte alebo nestabilitu pri dlhodobom používaní (týždne a mesiace bez reštartu)? Ako sa k tomu postaví jeho výrobca? Bude chcieť, aby ste mu dokázali navodiť reklamované chovanie v nejakom „laboratórnom“ prostredí? To býva v prípade komunikácií ťažké.
Na porovnanie – pre konkrétne projekty (naše alebo OEM partnerov) upravujeme chovanie komunikačných protokolov, pričom táto zmena sa aktivuje prostredníctvom tzv. parametrov protokolu.

Všetky uvedené body sú nezávislé od použitého SCADA produktu (ale, samozrejme, ich relevantnosť závisí od vlastností konkrétneho OPC servera). Ak potrebujeme nakomunikovať napr. 1000 tagov cez OPC server, tak potrebujeme 1000-tagovú licenciu OPC servera (pokiaľ je jeho licencovanie založené na počte tagov), ale zároveň na týchto 1000 tagov potrebujeme licenciu v SCADA systéme (opäť, pokiaľ je licencovanie založené na počte tagov, prípadne pokiaľ nemáme „unlimited“ licenciu).

Alternatívy

Aké iné možnosti má integrátor?

Prvou z nich je vývoj komunikačného protokolu. Ideálne je, aby výrobca SCADA produktu vyvinul ovládač pre požadovaný komunikačný protokol a pridal ho k zoznamu podporených. Záleží na flexibilite výrobcu (dostupnosti vývojárských kapacít a komplikovateľnosti protokolu). A samozrejme – na cene

Za náš aplikačný server D2000 – toto sa deje pomerne často, tento rok boli napríklad pre nové projekty podporené protokoly General Electric SRTP a Omron FINS.
Výhodou je, že protokol je automatický dostupný v ďalších verziách, včítane rôznych vylepšení a rozšírení (pre používateľov dostupný v rámci maintenance).

Druhou možnosťou je vlastný vývoj komunikačného protokolu. Toto je cesta, pokiaľ SCADA podporuje rozhranie na programovanie vlastných „plug-in“ komunikačných protokolov. V prípade Ipesoft D2000 sa jedná o rozhranie D2000 KomAPI, ktoré umožňuje implementáciu protokolov vo forme DLL knižníc na platforme Windows, resp. SO knižníc na platforme Linux. Túto možnosť využívajú naši OEM partneri, najmä pokiaľ sa opakovane stretávajú s nejakým špecializovaným protokolom a je pre nich flexibilnejše jednorazovo vyvinúť vo vlastnej réžii ovládač protokolu, ako nechať ho implementovať nám.

Záver

OPC a OPC UA servery ako protokolové konvertory sú určite užitočné. Pred ich výberom je nutné dôkladne zvážiť všetky pre a proti – aj z dlhodobého hľadiska a z pohľadu ďalšieho rozvoja SCADA aplikácie, včítanie výmen hardvéru, operačných systémov a prípadného rozširovania . Aby sa nestalo, že celkové náklady budú oveľa vyššie ako sa pôvodne počítalo, prípadne bude kvôli rôznym obmedzeniam nutná migrácia na iný produkt. V prípade technicky zdatného zákazníka môže byť prínosom zapojiť do rozhodovania aj jeho. Môže pridať do zoznamov pre a proti vlastné špecifické dôvody, ktoré nenapadli mne ani Vám.

22.9.2020, Ing. Peter Humaj, www.ipesoft.com

SCADA úvahy - (skrytá) cena komunikácie

Peter Humaj

Tento blog sa bude zaoberať nákladmi na komunikáciu, ktoré vyplývajú z použitia treťostranných OPC alebo OPC UA serverov.

Príbeh

OPC (UA) vládne všetkým

Alternatívy

Záver

Iné blogy

XML Tool

Archív a PostgreSql trezory - kompresia

Gateway v historickom režime