Koncepčné úvahy o dispečerskom systéme pre

slovenské uhoľné bane.

 

            Na základe viac ako 10 ročných skúseností z vývoja a prevádzky dispečerských systémov na sledovanie banskej výroby vzniká toto krátke zhrnutie ako podklad pre novú koncepciu dispečerského systému.

                                                                                  Zoznam príkladov SCADA

            Východiská – súčasný stav:

Dispečerský systém KRES-REAL bol vyvinutý už pred viac ako 14 rokmi a na svoje časy bol koncepčne aj realizačne riešený veľmi univerzálne a so širokým záberom. Použitý je na všetkých slovenských uhoľných baniach t.j. Baňa Nováky (BN), Baňa Handlová (BH), Baňa Cígeľ (BC), Baňa Dolina (BD), Baňa Záhorie (BZ), na každej v rozsahu a s prenosovými prostriedkami, aké baňa požadovala.

Výraznými charakteristikami systému KRESREAL boli a sú:

-         schopnosť implementovať širokú škálu technologických prenosových prostriedkov

-         intuitívne konfiguračné prostredie bez potreby znalosti programovania

-         viacúrovňové členenie prístupu k prezentácii informácií

            Druhy informácií a prenosových prostriedkov, monitorovaných a ovládaných dispečerským systémom KRES-REAL počas jeho prevádzkovania:

-         DAP prenosový systém

-         MTA prenosový systém (BN,BC,BH)

-         Sledovanie a regulácia centrálneho odberu elektrickej energie a kompenzácia

-         Sledovanie prevádzkových elektromerov

-         Sledovanie meračov tepla a pary (BH)

-         Systém sledovania koľajovej dopravy (BD)

-         Zabezpečovací systém – sledovanie narušenia objektov (BD)

 

V priebehu času sa samozrejme na baniach nasadzovali autonómne systémy, ktoré aj keď by logicky zapadali do integrovaného dispečerského systému, neboli doň z rôznych dôvodov (technických, či organizačných) integrované. Pri premýšľaniach o novej  koncepcii však treba uvažovať aj s nimi, a preto nasleduje aspoň ich krátke vymenovanie:

-         sledovanie váh – pásových, vagónových aj cestných

-         sledovanie popolomerov, prípadne detektorov kovov

-         sledovanie ťažných strojov

-         riadenie lokálnych automatov ventilátorov a čerpadiel

-         riadenie degazačných staníc

-         riadenie rekuperačných jednotiek

-         kompletné sledovanie hlavných a prevádzkových meračov tepla a elektriny

-         kompletné monitorovanie zabezpečovacích a kamerových systémov

-         monitorovanie systémov pre ohrev vetrov

Koncepcia by mala obsahovať aj pripravované, resp. perspektívne možné monitorovacie systémy ako:

-         integrované monitorovanie pohybu pracovníkov na povrchu a na banských pracoviskách

-         monitorovanie pohybu materiálu a strojno-technického zariadenia

-         sledovanie tlakových pomerov stien na hydraulických výstužiach

-         sledovanie inteligentných raziacich a rúbacích súprav

-         monitorovanie klimatizácie

-         riadenie výmenníkových staníc, resp. odovzdávacích staníc tepla

 

Základnou charakteristikou každého reálneho SCADA systému je prenos údajov z a do externého zdroja dát, t.j. nejakého zariadenia existujúceho mimo samotného počítača.

V druhov a formách zariadení je  obrovská variabilita, z hľadiska SCADA systému je dôležitým prvkom úroveň komunikačnej inteligencie externého zariadenia a rozhranie, cez ktoré sa údaje prenášajú.

            Úroveň komunikačnej inteligencie nemá priamu súvislosť s inteligenciou externého zariadenia samotného. Aj veľmi zložité zariadenie s veľkou vlastnou riadiacou inteligenciou môže byť vybavené žiadnou, alebo len minimálnou komunikačnou inteligenciou (napr. vo forme prostého relé kontaktu, signalizujúceho stav OK-KO.) Naopak aj v princípe jednoduché zariadenie, snímajúce povedzme prostý kontakt môže byť vybavené zložitým komunikačným protokolom (obvykle z dôvodov zaradenia do zložitejšieho komunikačného systému napr. BACnet). Z pohľadu SCADA systému sa komunikačná inteligencia prejavuje vo forme komunikačného protokolu, a TSM (transaction state machine) časovania komunikácie. Zároveň komunikačná inteligencia determinuje, či je možné komunikáciu so zariadením prerušiť bez straty informácie (buffer na strane zariadenia), resp. ako dlho je možné so zariadením nekomunikovať bez straty informácií. Vyplývajú z toho nároky na obslužné programy (driver-y) v počítači (či počítačoch) zabezpečujúce preberanie informácií.

Zhruba možno podľa komunikačnej inteligencie externé zariadenia rozdeliť na:

-         zariadenia s okamžitým stavom bez pamäte

-         zberacie zariadenia s uchovávaním informácií v komunikačnom buffri

-         zariadenia s autonómnym spracovaním údajov a vlastnou archiváciou činnosti.

 

            Prenosové rozhranie určuje akým spôsobom, cez aký port sa informácie zo zariadenia dostanú do počítača, zároveň určuje možný počet zariadení, ktoré komunikujú cez daný port.

Netradičné využívanie v PC zabudovaných portov ako joystick, či paralelné rozhranie na priame meranie a monitorovanie externých zariadení je skôr výnimkou, aj keď pre paralelné rozhranie existuje norma zbernice meracích zariadení IMS2. Stále ešte najčastejšou formou komunikácie zariadení s PC je komunikácia pomocou sériového rozhrania RS232 a s využívaním rôznych prevodníkov najčastejšie na RS485 pre zabezpečenie jednak ďalekého dosahu, jednak možnosti zbernicového usporiadania. Samozrejme existuje celá rada rôznych fyzických sériových rozhraní, či už štandartizovaných všeobecne, alebo firemne, alebo vyvinutých jednoúčelovo pre konkrétne aplikácie. (Na uhoľných baniach sa výrazne presadili 3 „ďalekonosné“ prenosové systémy: DFP, DAP, MTA s prakticky univerzálnym použitím pre priestorovo rozsiahle prenosy stavových (zapnuté/vypnuté) aj analógových informácií.)

Pokiaľ je z akéhokoľvek dôvodu vhodné na snímanie a riadenie určitej technológie použiť vyhradený autonómny počítač, ponúka sa a aj využíva možnosť použiť na komunikáciu so SCADA systémom „native“ počítačovú sieť formou prenosu súborov.

V súčasnosti trend smeruje veľmi silne k využívaniu počítačových sietí aj na priamy prenos informácií z a do zariadení na zber dát s tým, že výpočtová kapacita sama osebe potrebná na zabezpečenie sieťovej komunikácie sa využíva aj na autonómne spracovanie údajov, ich buffrovanie a archiváciu.

            Schématicky a zhruba možno znázorniť rôzne druhy prenosov:

-         priamy zber stavov a signálov počítačom - patria sem jednak „udělátka“ využívajúce priamo zabudované porty v počítači, ale aj rôzne meracie a monitorovacie zásuvné karty priamo do počítača

 

-         zber údajov zo zariadenia zabezpečujúceho vlastnú komunikáciu s fyzickými linkami prenosového systému, v prevažnej väčšine pomocou sériového portu RS232 priamo do počítača

 

-         zber údajov zo siete zariadení, pričom s každým zariadením komunikuje počítač samostatne prostredníctvom prostého prevodníka fyzických úrovní .... najčastejšie prevodník RS232/RS485 , resp. MBUS, Profibus ....

 

-         zber údajov z počítačovej siete autonómnych inteligentných zariadení , resp. PC

 

Druhy prenosov určujú

            V existujúcom systéme KRES-REAL sú spracovávané informácie z rôzne komunikačne inteligentných  zariadení cez prakticky všetky komunikačné porty v PC sa vyskytujúce.  

            Paralelný port:

-         snímanie kWh a 1/4hod. pulzov z fakturačného elektromera (BZ)

Joystick port:

-         snímanie kWh a 1/4hod. pulzov z fakturačných elektromerov (BC, BN)

karty v PC slote:

-         monitorovanie koľajovej dopravy (BD)

sériový COM port:

-         komunikácia so zberným systémom DAP, PRES (všetky bane)

-         podrobné snímanie fakturačných elektromerov cez RS485 (BH, BD)

-         komunikácia s fakturačným meračom tepla (BH)

-         koľajové váhy (BD funkčné, nakoniec nenasadené)

súborový prenos cez LAN:

-         komunikácia s MTA zberným systémom

 

Časovanie snímania a spracovanie informácií portov v systéme KRES-REAL je v prevažnej väčšine priamo software-ovo ošetrované v počítači MASTER – každý prenos (port) má svoj vlastný obslužný program – driver, zabezpečujúci presné časovanie procesov čítania, zapisovania z a do príslušných ­portov a tiež následné spracovanie prijatých informácií do zrozumiteľnej formy – dekódovanie surových údajov z portov prijatých podľa pravidiel výrobcom zariadenia definovaných. Drivery systému KRES-REAL, pracujú pod operačným systémom DOS, pričom využívajú priamy IO prístup na radiče portov a systémovej zbernice a zároveň využívajú plný prístup k hardware počítača vo forme IRQ (interrupt  request) a DMA (direct memory access) prístupov. Časovanie systému je riešené driverom času, prepínajúcim systémový timer do 16 násobne rýchlejšieho časovania, než je v DOS-e štandartom, čím sa zabezpečuje presné časovanie časovo kritických operácií driverov.

 

 

Porovnanie počítačového prostredia pre SCADA systém v čase vývoja KRES-REAL a dnes:

HW

x386

x486, Pentium

RAM

640 kB

512 MB

Hard disk

40 MB

40 GB

OS

DOS

W95,W98,Windows 32bit

LAN

Arcnet,peer-to-peer,Novell

1Mbit/s – 10 Mbit/s

Windows LAN TCP/IP internet

10 Mbit/s – 100 Mbit/s

HW IO

Priamy prístup

PP, COM, JOY

Len cez DDK, plug&play

EPP, USB, infra, BlueTooth

Display

640x480 direct

1024x768 coprocesor

 

 

Problémy plynúce zo smerovania HW,SW vývoja:

            Hlavný rozdiel medzi počítačom pred 10 rokmi a dnes (pod Windows) je ten, že kým nedávno bol počítač univerzálnym a dostatočne otvoreným nástrojom schopným rôznym spôsobom prijímať informácie z okolitého prostredia a následne ich plne pod kontrolou programátora spracovávať, dnes je z titulu „bezpečnosti“ pred prostredím obmedzený iba na ručné užívateľské vstupy, pričom akékoľvek periférne zariadenia musia byť výrobcom vopred pripravené  na komunikáciu s ním relatívne dosť zložitým a aj finančne náročným spôsobom.

Inak povedané, od periférnych zariadení sa dnes vyžaduje dosť vysoká úroveň komunikačnej inteligencie, zabezpečovaná do zariadení integrovanými mikroprocesormi.

            Zároveň razantným presadzovaním Windows sa do „už nepodporovaných systémov“ odsúvajú SW a HW, na ktorých bol súčasný dispečerský systém baní postavený, t.j. DOS, NOVELL, sériový COM port.

            Dôsledok: Neudržateľnosť systému KRESREAL z dôvodov:

-         začína byť nedostupný potrebný PC hardware

-         nie je dostupný podporovaný DOS

-         nie je dostupné podporované NOVELL sieťové prostredie

 

Keďže za nosný OS v súčasnosti na baniach používaný musíme považovať Windows (POZOR, nielen 32-bit ale aj W95 a W98), neostáva iné než prejsť na túto platformu aj so SCADA systémom.

Za tohto predpokladu však okamžite narážame na problém komunikácie s málo komunikačne inteligentnými technologickými prenosovými systémami, ktoré sú dnes stále (a nezdá sa, že by bolo priamo použiteľné niečo iné) jadrom monitorovania technológie na slovenských uhoľných baniach. Jednoznačne je potrebné nájsť riešenie, ktoré by umožnilo pripojenie existujúcich prenosových systémov do náročného prostredia Windows SCADA systému.

            Pre hľadanie riešenia treba najprv preskúmať možnosti s spôsoby práce dostupných SCADA systémov.

            Jednou z hlavných požiadaviek na SCADA systém pre slovenské uhoľné bane je otvorenosť a voľnosť v oblasti komunikácie, pripojovania nových druhov prenosov, nakoľko bude nutné pripojiť existujúce prenosy. Preto možno už dopredu vylúčiť SCADA systémy, viazané na konkrétne firemné protokoly a teda konkrétnou firmou dodávané periférne zariadenia.       

 

Ako zoznam SCADA systémov najlepšie poslúži zoznam niektorého výrobcu priemyslových riadiacich systémov (ktorý nevyrába vlastný SCADA systém), pekne zoradené to má firma AMIT :            http://www.amit.cz/cz/products/visual_sw.htm

                       

Nie je potrebné detailne preberať každý jednotlivý SCADA systém, dnes si „každá líška svoj chvost chváli“ a z kopy propagačných materiálov písaných každý svojím štýlom a bez možnosti priameho porovnania človeku sa iba zamotá hlava. Dôležitým výsledkom „browsovania“ by však mal byť prehľad o tom , aké technológie sa používajú a kam vlastne tieto veci smerujú.

 

Na vysvetlenie toho, čo je to SCADA systém môže veľmi dobre poslúžiť podrobná česká dokumentácia systému ControlWEB5, nachádzajúca sa vo voľne stiahnuteľnej aplikácii CW5 zo stránok firmy Moravské přístroje www.mii.cz .

            O technológiách hovorí kopa starých i nových skratiek, s modernými SCADA súvisiacich, so vzájomnou súvislosťou i bez nej, a hlavne bez zjavného systému členenia.

Ich mierne „ľudovo“ interpretovaný význam:

SCADA                      system for computer aided data acquistition,

systém zberu údajov s pomocou počítača

            HMI                            human machine interface, ľudské rozhranie k stroju

 

DLL                            dynamic linking library, za behu programu vkladaná knižnica

DDE,NetDDE             dynamic data exchange, dynamická výmena údajov

COM                          component object model, objektová technológia firmy Microsoft

DCOM                       distibuted component object model, sieťová varianta COM

OLE                            object linking and embedding, vkladanie a zaraďovanie objektov

OPC                           OLE for process control

ActiveX prvok COM rozšírenie Windows

 

Packet                         rámec pre prenos (časti) správy na určitom fyzickom komunikačnom médiu

IP/UDP/TCP               internet protocol, user datagram protocol, transfer control protocol, definícia paketov a ich výmeny v LAN a WAN

HTTP                          hypertext transfer protocol                              

 

HTML                         hypertext markup language

XML                           extensible markup language

SVG                            rozšírenie XML pre 2D grafiku                       

            Nádherný odkaz: http://www.wpsenergy.com/JayNick/default.asp

SMTP                         simple message transfer protokol

e-mail                          electronic mail

 

DBF                            database file format

ODBC                        open database connectivity

SQL                            structured query language

 

Internet/intranet            dnešné hlavné prostredie pre komunikáciu progr.systémov

Tenký (tiny) klient        v podstate iba prezentačná vrstva vzdialeného progr.systému

Hrubý (fat) klient          prezentačná aj aplikačná vrstva vzdialeného progr.systému

 

Prečo práve tento výber skratiek a pojmov a ako vlastne všetky súvisia s dispečerským systémom slovenských uhoľných baní ?

Odpoveďou môže byť, že pri snahe navrhnúť novú koncepciu dispečerského systému

je treba uvažovať s aktuálnymi technológiami, ktoré sú široko rozšíreným štandartom, a u ktorých je čo najväčšia istota, že sa nestratia v zabudnutí v najbližších rokoch (čo pri dnešnom extrémne rýchlom vývoji štandartov nie je vôbec ľahké).

 

Nasledujúce požiadavky na pripravovaný dispečerský systém nie sú presne definované v intenciách nejakej kategorizácie SCADA systémov, sú skôr intuitívne vychádzajúce z dlhodobých skúseností a dosť dôkladného štúdia možností. Požiadavky nie sú ani striktné, ani konečné, ale mali by byť východiskovým bodom na diskusiu o konečnej podobe koncepcie a formách realizácie.

             

S maximálnou snahou o štandartizáciu sa v súčasnom počítačovom svete stále viac prepojenom internetom sa možno stretnúť práve u technológií prenosov údajov cez počítačové siete, pričom prenos údajov po lokálnych sieťach (intranet) sa stále viac prispôsobuje prenosom po internete, pričom používajú rovnaké software technológie. Využitie štandartných technológií, zaručujúce budúcu kompatibilitu a stálu možnosť rozvoja by malo byť hlavnou požiadavkou na novú koncepciu dispečingu.

Zároveň počítačové siete sú už natoľko rozšírené a „všadeprítomné“, že sa objavuje stále viac zariadení na zber technologických informácií, ktoré sa pripojujú priamo na počítačovú sieť. Samozrejme existuje zároveň aj viacero možností, ako na počítačovú sieť napojiť stávajúce zariadenia, pôvodne komunikujúce pripojením priamo k počítaču. Vhodné je aj využiť počítač, ku ktorému sú priamo pripojené konkrétne technologické  zariadenia ako kompatibilný zdroj informácií pre integrovaný dispečerský systém

Úprava hardware-u a software-u používaných prenosových systémov je nevyhnutnou podmienkou pre plnú kompatibilitu so súčasnými trendami a zároveň pre integráciu všetkých monitorovacích systémov do jednotného celku.

 

Dispečerský systém ako celok rozdelíme pre naše potreby do dvoch základných komunikačných vrstiev:

1.      vrstva komunikácií s technológiou

2.      vrstva komunikácií medzi spracovávacím centrom (centrami) a klientami

 

V rámci komunikácie počítača s technologickými zbernými zariadeniami možno v prostredí operačného systému Windows použiť buď:

-         priame naprogramovanie potrebnej komunikácie vo forme DLL, ktorá sa prilinkuje k serveru SCADA – táto verzia nie je všeobecná, pevne sa viaže na konkrétny SCADA systém, žiadne oficiálne štandarty  na úrovni údajov neexistujú, využiteľné sú sériové porty (COM,USB,TCP/IP)

-         priame naprogramovanie komunikačného drivera  založené na COM objektovom modeli Windows s využitím štandartov ActiveX, DDE, resp. najlepšie OPC, v tomto prípade už väzba na konkrétny SCADA nie je, využiteľné porty sú rovnaké ako v predchádzajúcej verzii

-         pre počítač samotný nenaprogramovanie ničoho !!! ALE riešenie a naprog-ramovanie (aj pre predchádzajúce 2 varianty nutného) inteligentného interface zariadenia tak, aby mohlo existovať autonómne priamo na LAN sieti.

Dispečerský systém by mal podporovať získavanie údajov z autonómnych, inteligentných, na samotnom počítači nezávislých zariadení, komunikujúcich prostredníctvom internet technológie.      Táto požiadavka smeruje k použitiu embedded WEB serverov pre nosné prenosové systémy baní. Výhody takéhoto riešenia:

-         prenosový systém (či už PRES, DAP, iButton sieť, RS485 zbernica, MBus ...) sa stane úplne nezávislý od konkrétneho počítača ... vlastne vôbec nemusí existovať počítač pre konkrétny prenosový systém

-         pripojiť sa možno kdekoľvek, kde je v blízkosti HUB, či switch, alebo len prosto vedenie počítačovej siete (pri dnešných cenách switch-ov okolo 500 Sk nie je problém kdekoľvek aj UTP kábel rozstrihnúť a vložiť switch, koniec koncov je možné funkcionalitu switch-a zabudovať priamo do zariadenia)

-         napájanie pre menšie zariadenia možno riešiť akumulátorom alebo zálohovacím zdrojom, takže nedôjde k prerušeniu činnosti ani v prípade dlhšieho výpadku napájania, ako keby musel byť napájaný aj počítač

-         aj tie technológie, ktoré sú v súčasnosti napojený na vlastný riadiaci počítač, hoci aj na vzdialených miestach  sa môžu integrovať do centrálneho dispečerského systému buď aktivovaním ich WEB vlastností (Promotic pre riadenia ohrevu vetrov na jame AB v Novákoch, Control WEB na riadenie ťažného stroja v Handlovej), alebo pokiaľ postačuje aj zariadením s prostou funkciou monitora technologickej komunikácie. (Tým sa dá odstrániť duplicita v súčasnom sledovaní technológie jej „native“ dispečingom a snímaním vybraných stavov niektorým z prenosových systémov pre centrálny dispečing)

 

V každom SCADA systéme existuje jeden alebo viac serverov technologických informácií, ktoré slúžia ako spracovávateľské centrá, kde sa surové, resp. čiastočne spracované informácie z prenosových systémov ďalej spracúvajú, priraďujú, kombinujú, vyhodnocujú sa ich stavy, archivujú, prepočítavajú do podoby vhodnej na prenos do prezentačnej vrstvy v HMI, t.j. jasne zrozumiteľnej človekom.

 

 

 

 

 

 

 

 

 

Obrázok z dokumentácie

TirsWEB

www.coral.cz

 

 

 

 

 

 

 

Nakoľko na prístup k prezentačnej  vrstve dispečerského systému sa predpokladá nielen celá vnútropodniková počítačová sieť, ale treba koncepčne počítať aj s prístupom k prezentácii zvonku, z na internet pripojeného počítača, resp. z mobilu, či z PDA, najideálnejším riešením je urobiť komunikáciu medzi serverom(mi) a klientmi čistými štandartizovanými internet technológiami. Master server technologickej siete by mal byť zároveň plnohodnotným WEB serverom, poskytujúcim v rámci vlastnej funkcionality všetky potrebné informácie pre prezentáciu u klientov.

Viaceré SCADA systémy takúto formu prenosu údajov poskytujú ako voliteľnú možnosť – dynamicky generované HTML stránky, TirsWEB je dokonca priamo na tejto forme postavený a inú, vlastnú „native“ prezentáciu prostredníctvom „tučného klienta“ ani nemá, všetka prezentácia sa odohráva priamo v štandartnom WWW prehliadači, ktorý je dnes súčasťou OS prakticky každého PC.

Dispečerský systém by mal mať možnosť plnohodnotnej prezentácie a komunikácie s klientom prostredníctvom štandartného WWW prehliadača, ideálne by to mala byť jeho prirodzená prezentačná vrstva.

 

 

 

           

 

 

 

 

 

 

TIRS.NET, TIRS.WEB  www.coral.cz  ako klient postačuje čistý Internet Explorer

 

 

 

 

 

 

 

 

 

 

Zatiaľ uvedeným požiadavkám vyhovujú vo väčšej či menšej miere prakticky všetky moderné SCADA systémy, pre podrobnejšie preskúmanie ako to skutočne chodí sme podrobnejšie skúšali a skúmali (z hľadiska prezentácie „tenkým klientom“) názornými ukážkami vyzbrojený TirsWEB, a baniam už dobre známy Promotic6 a ControlWEB5.

Pri skúmaní bolo dôležité posúdiť, ako rýchlo dokážu prezentovať a aké nároky kladú na prenosové kapacity siete, nakoľko:

Prezentačná vrstva dispečerského systému by mala byť adekvátne rýchla (vo vzťahu k rýchlosti technologického prenosového systému identifikovať potenciálne nebezpečné stavy, o ktorých má byť ten-ktorý klient informovaný ), pričom by mala mať čo najmenšie nároky na prenosové kapacity.

Výsledok skúmania nás však príliš nenadchol,  podrobnejším skúmaním sme

identifikovali aj potenciálne problémy vo vzťahu k súčasným obrázkom dispečerského systému. Ide o princípy tvorby dynamických HTML stránok a stojí za to chvíľku sa nad tým zamyslieť. Na rozdiel od statických HTML stránok, ktoré sa raz „natiahnu“, vykreslia a užívateľ sa nimi môže kochať dokedy sa mu zažiada, HTML stránky dispečerského systému musia prezentovať zmeny stavov a hodnôt a teda byť dynamické. Dá sa to urobiť cez „refresh“ obrazovky s tým, že sa „natiahne“ znova komplet celá stránka (resp. jej zmenená časť) v preddefinovaných časových intervaloch, resp. sa vyžije mechanizmus v HTML zabudovaných scriptov a meniacich sa XML údajov (kratších súborov) s tým, že zmena vykreslenia sa udeje priamo v prehliadači. Použité mechanizmy v skúmaných systémoch boli funkčné, ale mali svoje obmedzenia hlavne v grafických častiach obrázkov – samotná definícia HTML má podporu pre „ťahanie“ rastrových obrázkov, ale nie pre 2D grafiku. Prekreslenie zmenenej čiary krížom cez celú obrazovku tak prakticky znamená komplet prenos rastrového obrazu vo veľkosti obrazovky – príliš rozšafné pre prenos!   

            Napriek tomu:

Prezentačná vrstva dispečerského systému by pokiaľ možno nemala mať žiadne obmedzenia ohľadne vypracovania a vzhľadu obrázku, mala by aj podporovať  animačné a multimediálne schopnosti dnešných PC.

            Na prvý pohľad nezlučiteľnosť WWW prehliadača s 2D (nieto ešte 3D) interaktívnou grafikou má však riešenie .... SVG rozšírenie XML štandartu práve pre 2D grafiku !!!

 

Scalable Vector Graphics  poskytuje presne to, čo prezentácia dispečerského systému potrebuje.

V okamihu „objavenia“ SVG prestali existovať akékoľvek pochybnosti o schopnosti WWW prehliadača (podporujúceho existujúce štandarty spravované organizáciou w3.org)

byť  plnohodnotným, rýchlym a interaktívnym prezentátorom dispečerského systému.

Zavolanie na technickú podporu ControlWEB a Promotic dalo odpoveď na váhanie, ktorý zo spomínaných, cenovo prijateľných systémov pripadá do úvahy:

            ControlWEB5:

smeruje k 3D prezentácii, pre ňu však zatiaľ neexituje všeobecne prijímaný štandart v rámci www technológií, toto smerovanie však implikuje ich „nezáujem“ o SVG. Majú veľmi kvalitne spracované editácie 2D aj 3D obrázkov a  prezentačné schopnosti ich „hrubých klientov“ sú výborné.

            Promotic:

V momentálnej verzii 6 sú dosť biedne možnosti editácie obrázkov a zdá sa, že ich obrázky sú silne horizontálno-vertikálne zamerané (axonometrický pohľad by robil dosť veľké problémy) ale: verzia Promotic7 pripravovaná k polovičke septembra tohto roku by mala pracovať pod SVG  špecifikáciou !  Nedostali sme sa však k podrobnejším informáciám, iba k tomu, že obrázky sa budú vyrábať v externom SVG editore. Promotic pravdepodobne dobuduje nejaké priraďovacie rozhranie medzi svg súbormi (a naviazanými script-ami ) k xml datovým súborom, definujúcim vlastnú interaktivitu obrázka.

           

Až do vyššie uvedených skúmaní to vypadalo, že SCADA systém Promotic bude veľmi dôstojným update-om dispečerského systému na slovenských uhoľných baniach. V rámci telefonických rozhovorov však malá zmienka zo strany kontaktovanej osoby upriamila pozornosť na uvedomenie si jedného fundamentálneho problému:

            Promotic, rovnako ako ControlWEB sú skriptovacie systémy, ktoré na svoj rozbeh potrebujú preloženie – kompiláciu aplikácie. Dôsledok : ANI JEDEN SYSTÉM SÁM OSEBE NIE JE SCHOPNÝ REAL-TIME ZMENY KONFIGURÁCIE !!!  a podľa vyjadrenia sa ani jeden z nich o to nebude snažiť. Navrhovali riešenie formou dvoch aplikácií, z ktorých jedna by prevzala „master-ovanie“ počas úprav konfigurácie, pričom aplikačný inžinier by už pri návrhu musel myslieť na možnú zmenu a pripraviť zoznam premenných, ktoré treba preniesť na zálohovú aplikáciu počas zmeny konfigurácie, aby sa nestratili údaje ako nápočty impulzov, nápočty pre časové archívy a ďalšie veličiny charakteru v pamäti ukladaných medzi-veličín.  

 

            Os.Pozn.: Nie je mi úplne jasné, ako to, že požiadavka on-line rekonfigurácie nie je obsiahnutá v SCADA systémoch ControlWEB a Promotic, oficiálne sa prehlasujúcich ako systémy vhodné pre správu aj veľmi rozsiahlych aplikácií v rádoch desaťtisícov monitorovaných a riadených veličín, stoviek pripojených IO zariadení, automatov a riadiacich jednotiek, s možnosťami spolupráce viacerých serverov a s veľkým množstvom klientov. V takých veľkých systémoch vždy dochádza k nejakým úpravám, doplneniam, zmene grafickej prezentácie ... Prostriedky, ktoré uvedené systémy majú hoci len na členenie a správu zoznamov premenných sú dosť malé a neprehľadné. Jediné vysvetlenie, ktoré na to mám, je to, že sa vlastne tieto SCADA vo veľkom rozsahu ani nepoužívajú, väčšinou sa jedná (podľa referencií) o jedno počítačové aplikácie – proste miestne riadenie nejakej konkrétnej technológie. Pokiaľ sa skutočne jedná o väčšie celky, ide pravdepodobne o pevne osadenú technológiu s presne určenými riadiacimi a monitorovacími jednotkami na jej sledovanie, s presnou a nijak nemenenou funkcionalitou, maximálne tak s nastavovaním presne už v projekte definovaných parametrov.

            V prostredí baní existujú samozrejme relatívne uzavreté technologické celky s vlastným prenosom a riadením (viď horeuvedené príklady), ale zároveň tu existuje technologické prenosové prostredie s dopredu presne neurčeným významom – pri povedzme 2-3 km dlhej linke DAP nie je dopredu presne známe, čo sa kde osadí, či na konkrétnej pozícii bude osadený prijímač, či vysielač, alebo analógovo digitálny prevodník, a či kanál vysielača č.3 bude motor pásového, hrabľového dopravníka, alebo drviča, alebo to bude signál otvorenia dverí, či signál stavu vn linky.

            Rovnako systém MTA si predsa nemôže dovoliť vypnúť sa a prestať sledovať merače plynov, či izolačné stavy rozvodní len preto, že treba odskúšať a nastaviť parametre nejakého konkrétneho merača.

            Zároveň je však dosť ťažko predstaviteľné, aby odvodené, viazané, či veličiny vypočítavané kombinovane zo stavov z viacerých prenosových IO zariadení (ktoré musí vykonávať „master“ systému) boli len tak „odstavené“ len kvôli nejakej nepatrnej zmene na usporiadaní systému snímania. Vyplýva z toho striktná požiadavka:    

Dispečerský systém musí byť rekonfigurovateľný počas prevádzky.

Požiadavka rekonfigurácia sa týka jednak všetkých činností vykonávaných serverom údajov, jednak grafickej prezentácie na všetkých pripojených klientoch. V dnešnej dobe je dostupných viacero možností, ako integrovať do programového systému on-line príkazový interpreter, ostatne žiadny Apache WEB server netreba reštartovať len preto, že sa pridá nový súbor s ASP script-om, rovnako ako žiadny WWW prehliadač sa nereštartuje a nerekompiluje keď má interpretovať v stránke zabudovaný Java, VisualBasic skript.

 

Posledne uvedená požiadavka prakticky vylučuje použiteľnosť ControlWEB a Promotic SCADA systémov ?

Ako vhodný by potom pripadal skutočne len IPESoft D2000, kde sa jasne píše:

 

D2000 Actis umožňuje vytvárať komplexné riešenia v oblasti informačných a riadiacich systémov reálneho času. Na vytváranie aplikácie systému D2000 Actis slúžia výkonné on-line konfiguračné nástroje s integrovanými ladiacimi funkciami. Aplikácia sa vytvára definíciou objektov systému a väzieb medzi nimi bez potreby znalosti programovania. Rozširovať a dopĺňať nové funkcie do aplikácie na báze D2000 Actis je možné bez prerušenia chodu systému.

 

Problémom však je, že v D2000 sa nijak zvlášť neprejavuje smerovanie k internetovým štandartom.

 

Objednať demoCD a pozrieť sa podrobnejšie na Actis !

 

 

 

 

Vzhľadom k nestavanie dispečerského systému „na zelenej lúke“, mala by existovať ešte jedna požiadavka:

Nový dispečerský systém by mal mať mechanizmus, umožňujúci „preklopiť“ existujúci dispečerský systém bez neprimeraného prerušenia chodu dispečingov.

Samozrejme sa nedá predpokladať, že akýkoľvek SCADA systém bude poznať „firemné“ štruktúry systému KRESREAL. Pokiaľ však SCADA systém obsahuje mechanizmy, umožňujúce uložiť svoju konfiguráciu a prezentačný systém do textového, či databankového  súboru (pre archívne, zálohovacie, editačné, vyhľadávacie, analytické, štrukturálne ... a pod. dôvody), je tu možnosť konverzie súborov. (V systéme KRESREAL existuje utilita Ocutil.exe, umožňujúca obojsmernú konverziu konfigurácie aj obrázkov do textového tvaru a späť).

Je samozrejme možné namaľovať a nakonfigurovať všetko odznova, mohlo by to však negatívne ovplyvniť dobu nasadenia nového systému a potenciálne ohroziť plynulý chod dispečingov. (Zároveň uvádzané dôvody pre existenciu odkladacieho mechanizmu sami osebe sú dosť presvedčujúce a zo skúsenosti pre rozľahlé systémy je to skoro nevyhnutné.)

 

Sumarizácia požiadaviek:

-         Využitie štandartných technológií, zaručujúce budúcu kompatibilitu a stálu možnosť rozvoja by malo byť hlavnou požiadavkou na novú koncepciu dispečingu.

-         Úprava hardware-u a software-u používaných prenosových systémov je nevyhnutnou podmienkou pre plnú kompatibilitu so súčasnými trendami a zároveň pre integráciu všetkých monitorovacích systémov do jednotného celku.

-         Dispečerský systém by mal podporovať získavanie údajov z autonómnych, inteligentných, na samotnom počítači nezávislých zariadení, komunikujúcich prostredníctvom internet technológie.

-         Dispečerský systém by mal mať možnosť plnohodnotnej prezentácie a komunikácie s klientom prostredníctvom štandartného WWW prehliadača, ideálne by to mala byť jeho prirodzená prezentačná vrstva.

-         Prezentačná vrstva dispečerského systému by mala byť adekvátne rýchla (vo vzťahu k rýchlosti technologického prenosového systému identifikovať potenciálne nebezpečné stavy, o ktorých má byť ten-ktorý klient informovaný ), pričom by mala mať čo najmenšie nároky na prenosové kapacity.

-         Prezentačná vrstva dispečerského systému by pokiaľ možno nemala mať žiadne obmedzenia ohľadne vypracovania a vzhľadu obrázku, mala by aj podporovať  animačné a multimediálne schopnosti dnešných PC.

-         Dispečerský systém musí byť rekonfigurovateľný počas prevádzky.

-         Nový dispečerský systém by mal mať mechanizmus, umožňujúci „preklopiť“ existujúci dispečerský systém bez neprimeraného prerušenia chodu dispečingov.

 

Podľa doterajšieho rozboru, návrhov požiadaviek a náznakov riešení novej koncepcie dispečerského systému ... zistíme, že najľahšie by bolo vybudovať vlastný systém na najmodernejších mechanizmoch prenosov.

 

Os.Pozn.: Záver, ku ktorému som dospel je pre mňa samého dosť prekvapujúci, ale štúdiom internet technológií a smerovaní SCADA systémov skutočne dospievam k záveru, že prostredie je pripravené pre udržanie sa určitých štandartov relatívne dlho nezmenených, skôr rozvíjaných. Najviac ma o tom presvedčuje fakt, že veľká väčšina prenosov na internete sa odohráva na úrovni textových súborov s relatívne jasne členenou štruktúrou, čo na rozdiel od firemných binárnych protokolov a štruktúr dáva záruky čitateľnosti prakticky navždy.

 

Na záver uvádzam (bez komentára) prehľad komerčných SCADA systémov, ktoré považujem za reprezentatívnu vzorku toho, čo sa v tejto oblasti vyskutuje, resp. ktoré majú niečo, čo sa dá považovať za inovatívne, resp. ktoré majú proste pekné obrázky:

 

scada-technology-profile.pdf    Schneider Electric

Reliance4_Leaflet_CZ.pdf                   Geovap

QLine_retos.pdf

GENESIS64_Flyer.pdf                       Iconics (64-bit)

cw5cz.pdf                                           Moravské přístroje

PROMOTIC.htm                                Microsys

CS Works - web-based HMI-SCADA-EMI control system framework.htm

CORAL s_r_o_ ===.htm

 

A špecialitka na úplný záver ... (mierne „zhadzujúca“ komerčné SCADA) ... SCADA sa dá robiť aj obyčajným MS Office (dnes v súvislosti s Office 2007 a jeho formátom DocX, XlsX dokonca aj bez potreby akéhokoľvek (v dokumente spomínaného) konverzného programu !

            SVG_MSOffice_paper.doc