FOLYAMATVIZUALIZÁLÓ ÉS SCADA PROGRAM-RENDSZEREK

FOLYAMATVIZUALIZÁLÓ ÉS SCADA PROGRAM-RENDSZEREK

A technológiai folyamat felügyeletét ellátó személyzet számára az információk még a közel-

múltban is technológiai sématáblákon, kijelzőműszereken, regisztrálókon jelentek meg. Ha a

folyamat működésében valamilyen vészállapot fellépésére lehetett következtetni, akkor hang-

jelzéssel és a sématáblán a hiba okának kijelzésével figyelmeztették a kezelőt a fokozott fi-

gyelemre, esetleg a beavatkozás szükségességére.

Egy kiterjedt technológiai folyamat esetén a sématábla mérete, a kijelző- és a regiszt-

rálóműszerek száma igen tekintélyes. Ebből az is következik, hogy létrehozásuk költséges.

Problémás a technológia átalakítása, bővítése, az eszközbázison nehézkes és költséges a vál-

toztatások naprakész követése. A gyakorlat szerint a sématáblák nem a tényleges technológiai

állapotot tükrözik, kisebb-nagyobb eltérések nem tekinthetők kirívó kivételnek.

Kézenfekvőnek tűnik, hogy a funkciók számítógépes bázison integrálódjanak. A szá-

mítógépes hardverbázist napjainkban PC kategóriájú (esetleg ipari kivitelű) számítógépek,

míg a szoftverrendszer alapját a folyamatvizualizáló programrendszer jelenti. A megjelenítő

munkahelyek intelligenciája a kezelői funkciók új, korábban elképzelhetetlen minőségi javu-

lását eredményezte.

Szakmai viták tárgya, hogy egy vagy több számítógép képernyőjén lehetséges-e a ke-

zelő számára megjeleníteni a technológiai folyamat átfogó értékelésére alkalmas sémát, vagy

ez csak egy több négyzetméteres felületű sématáblán lehetséges. Mindkét fél képviselői na-

gyon hihető és megfontolandó érveket sorakoztatnak fel álláspontjuk igazolására. A vita ösz-

tönzi a számítógépes megoldás híveit, hogy a vizualizálási feladatok megoldására tervezett

rendszer a lehetőségek által megszabott határokon belül kielégítse a másik tábor alapvető igé-

nyeit. Napjainkban a gazdasági és a többletfunkciókból származó előnyök alapján a számító-

gépes folyamatvizualizálás térnyerése figyelhető meg.

A folyamatvizualizáló szoftverek nem egyedi fejlesztés eredményei. A szoftvergyár-

tók sokasága forgalmaz olyan keretrendszereket, amelyek alkalmasak a folyamatvizualizálás

alapvető feladatainak megvalósítására. A keretrendszerek azt biztosítják, hogy az alkalmazók

számára az applikáció során ne a programozástechnika alapkérdései (pl. egy grafikus ábra

kirajzolása) legyen a fő probléma, hanem a technológiai állapot megjelenítésének optimális

módja kerüljön a megoldandó feladatok első helyére. Ha egy rendszer tervezői sok egyedi, a

keretszoftvert gyártó által nem preferált funkciót kívánnak beépíteni, akkor az alkalmazás

sikeressége nagymértékben a keretrendszer rugalmasságán múlik.

10.1. A technológiai folyamat állapotát jellemző változók és feldolgozásuk

Egy technológia folyamat állapotát általában kétállapotú jelzések és mérési adatok jellemzik.

A folyamatvizualizáló rendszerek a technológia állapotára jellemző jelzések és mérések érté-

két   soros kommunikáció útján kapják a folyamattal közvetlen kapcsolatban álló PLC-

berendezésektől. A megjelenítő-rendszerek tervezésekor, kialakításakor törekedni kell arra,

hogy a felhasznált és megjelenített adatok hitelesek, hihetők legyenek. Amennyiben ezt a kö-

vetelményt figyelmen kívül hagyjuk, a felhasználók bizalma jogosan csökken a rendszer iránt.

10.1.1. A jelzések és hihetőségük

A technológiai folyamat nagyon sok eseményéről a kétállapotú jelzések megváltozásából sze-

rezhetünk tudomást. A jelzések két, egymást kizáró állapothoz rendelődnek. A jelzés egyik

értéke (legyen ez a logikai 1) pl. egy gázfáklya lángjának meglétét, a jelzés másik (logikai 0)

értéke a láng hiányát jelzi. A jelzés aktuális értékét a technológián elhelyezett lángérzékelő

szolgáltatja. A jelzések szerepére számos más példa is van. Elemezhetjük, pl. egy kemenceaj-

tó zárt, ill. nyitott állapotát mutató jelzés kiépítésének technikai részleteit, vagy egy reaktor-

tartály nyomás-, ill. szintkapcsolójának kialakítását, amelyek a nyomás, ill. a szint egy adott

nagyságot meghaladó értékénél szolgáltatnak logikai 1 jelet. A jelzések értelmezésének lehe-

tőségeit egyedi jelzések, jelzéspárok és jelzéscsoportok szerint csoportosíthatjuk.

Egyedi jelzések

Ebbe a csoportba azokat a jelzéseket soroljuk, amelyek értelmezéséhez nem szükséges

más jelzés értékét figyelembe venni. Az a jelzés, ami a láng jelenlétét vagy hiányát mutatja,

csak önmagában értelmezhető. A jelzések hihetőségét a vizualizáló rendszer nem tudja ellen-

őrizni, hiszen nincs semmi alap a technológia felől érkező adat felülbírálatára. Amennyiben

egy technológiai folyamat nagyon fontos egyedi jelzéseinek hihetőségéről is szeretnénk in-

formációt kapni, akkor ezen egyedi jelzések megkettőzését alkalmazzák. A megkettőzés során

nem az a célszerű eljárás, hogy mindkét jelzés ugyanazt az információt hordozza, azaz mind-

két jelzés azonosan 1, vagy azonosan 0 értékű legyen. Előnyösebb, ha a megkettőzött jelzések

egymás komplemensei, azaz pl. az egyik jelzés 1 értéke a láng meglétét, míg a másik jelzés 1

értéke a láng hiányát mutatja. A hihetőség a két jelzés eltérő értéke (1, 0 vagy 0,1) esetén áll

fenn.

Jelzéspárok

Néhány esetben a technológia állapotára két jelzés (jelzéspár) értéke nyújt informáci-

ót. Erre példaként egy folyadéktartály minimum- és maximumjelzéseinek lehetséges értékvál-

tozatait mutatjuk be. A példából kiderül, hogy a jelzéspárok esetén már megkettőzés nélkül is

bizonyos hibaellenőrzésre nyílik lehetőség, bár ez korántsem jelenti, hogy minden érzékelő-

meghibásodás kijelezhető a rendszerben.

Szint a minimum alatt          Szint a maximum felett

A folyadékszint

1

minimum és maximum között

maximum fölött

minimum alatt

hihetetlen

Másik példaként egy igen gyakori technológiai berendezést, a tolózár állapotait említ-

jük. A tolózár nyitott, valamint a tolózár zárt állapotát egy-egy jelzés mutatja. A különbség a

két példa állapotjelzései között az, hogy a jelzéspár 00 értékpárja csak a tolózár nyitási, ill.

zárási időtartamára állhat fenn. Ha az időtartamnál hosszabb ideig érzékeljük az értékpárt,

akkor a tolózár elakadását prognosztizálhatjuk. Azaz a jelzéspár hihetőség-ellenőrzésén túl

időzítésfigyelés is szükséges.

Tolózár nyitott

Jelzéscsoportok

Tolózár zárt

Áz állapot

tolózár éppen zár vagy nyit

zárt

nyitott

hihetetlen

Nem túl gyakran fordul elő, hogy több jelzés együtt mutatja egy technológiai berende-

zés állapotát. Ha pl. egy szállítószalag kilépőpontján három különböző irányba terelhetjük a

szalagon haladó anyagot, és a lehetséges útvonalak közül csak egy lehet beállítva (mert me-

chanikusan csak ez lehetséges), akkor a három lehetséges haladási irány beállítását jelző há-

rom érzékelő közül csak egyetlen jelezhet logikai 1 értéket. A jelzések minden olyan érték-

kombinációja, ahol bármelyik kettő, vagy mindhárom jelzés 1, csak az érzékelők meghibáso-

dását (a jelzéscsoport hihetetlenségét) tükrözi.

10.1.2. A mérési adatok, hihetőségük és határérték-vizsgálatuk

A technológiai berendezés pillanatnyi állapotáról a mérési adatok (nyomások, hőmérsékletek,

közegáramok stb.) szolgáltatnak a jelzéseken túl információkat. A mérési adatokat általában

hagyományos, vagy intelligens távadók, esetleg impulzussorozatot szolgáltató eszközök ad-

ják.

A hagyományos távadók a mért mennyiséggel arányos áramjelet adnak tipikusan a

4...20 mA tartományban. Az áramjelet precíziós ellenállással feszültségjellé alakítják, ami az

analóg multiplexeren keresztül már az A/D konverter bemenetére csatlakoztatható. Például

100 Ohm lezáró ellenállás alkalmazásával maximum 2 V feszültségjel kapcsolódik (20 mA

esetén) az A/D konverter bemenetére. Az A/D konverter a felbontásától függően 12...16 bites

bináris számot szolgáltat, amely a bemenetére kapcsolt feszültséggel arányos. A folyamatvi-

zualizáló rendszerekben nyilván nem ezt a számértéket, hanem a mérnöki egységre átszámí-

tott megfelelőjét kell megjeleníteni. Az átszámítást skálázásnak nevezik.

A mérések többsége a mért mennyiséggel arányos áramjelet szolgáltat, azaz lineáris

skálázás szükséges. Ha közegáramot kívánunk mérőperemmel mérni, úgy a mérőperemen

fellépő nyomáskülönbség nagyságából következtethetünk a térfogatáram nagyságára. A tér-

fogatáram a mért nyomáskülönbség (az A/D által adott számérték) négyzetgyökével arányos.

Ebben az esetben gyökös skálázás szükséges.

Ha a számérték a 4 mA-nél kisebb, vagy a 20 mA-nél nagyobb áramértékre enged kö-

vetkeztetni, akkor ez az adat hihetetlenségét jelenti. A folyamatvizualizálás során a hihetőségi

tartományt a méréshatárnál szűkebbre választják technológiai megfontolások alapján.

Az  intelligens (smart) távadók soros kommunikációval a terepi buszon keresztül a

mért adatot digitálisan szolgáltatják. Ez az adat már mérnöki egységre számítva (pl. egy nyo-

más esetén bar-ban) jelenik meg a rendszerben. A hihetetlenséget a távadó alsó méréshatárá-

nál kisebb, vagy a felső méréshatáránál nagyobb adatok jelentik (bár ez elvileg nem fordulhat

elő). A hihetőségi tartomány beállított értéke itt is lehet kisebb, mint a távadó méréshatára.

Közegáram mérésekor gyakori, hogy a mérőeszköz nem áram-, hanem impulzuskime-

netet szolgáltat. Egy víz- vagy gázóra térfogategységenként szolgáltat egy-egy impulzust. En-

nél sokkal nagyobb számban fordul elő, hogy           mérőturbinákkal mérik a folyadékok, gázok

mennyiségét, egy-egy térfogategységhez egy-egy impulzus tartozik. Az alapvető különbség

az impulzusok frekvenciájában mutatkozik a különböző mérőeszközök között. Vannak mérő-

eszközök (pl. vízóra, gázóra), ahol csak maximum néhány Hz frekvenciájú impulzus szoká-

sos, míg vannak olyan eszközök (turbinák, örvényszórásos mérők), ahol kHz-es frekvenciák a

tipikusak. Az impulzusokat számlálókkal számláltatják. Nyilvánvaló különbséget jelent egy

PLC számára a maximum néhány Hz és a kHz frekvenciájú impulzusok számlálása. Az egyik

esetben egy, a PLC-ben szoftveresen leképezett számláló is megfelelő, míg a másik esetben

hardveres számlálóegység szükséges. Az adat megjelenítésének követelményei kettősek: egy

gőztermelő kazán legfontosabb adatai közé tartozik, hogy egy műszak, vagy egy nap alatt

mennyi vizet, ill. mennyi gázt használtunk fel. Ezen adatokat a víz- és a gázórának az adott

időszak végéhez, ill. kezdetéhez tartozó számlálóállásaiból számítják. Követelmény a pilla-

natnyi víz- és gázfogyasztás megjelenítése is. Ehhez meg kell határoznunk, hogy két mintavé-

telezés között mennyit változott a számláló (mennyi a növekmény), ill. az ehhez tartozó térfo-

gatot, majd ezt el kell osztani a mintavételezések között eltelt idővel. Így megkapjuk a pilla-

natnyi fogyasztást (az intenzitást) m /s vagy m /h mértékegységben. A módszer csak akkor

alkalmazható, ha a mérőeszköz a két mintavételezés között nagyszámú (több száz) impulzust

szolgáltat. Amennyiben pl. 1 s mintavételi idővel 1 Hz környékén kismértékben ingadozó

frekvenciájú impulzusokat kívánunk megjeleníteni (egy-egy impulzus feleljen meg 1 m tér-

fogatnak), úgy a vizualizáló rendszerben 0, 1, 2 m /s fogyasztásadatokat fogunk látni, holott a

valóságban a fogyasztás 1 m /s környékén egy szűk tartományban ingadozik. Ez használhatat-

lan adat, ezért ilyen esetekben változtatni kell az algoritmuson. A jelenséget a tört impulzusok

számlálási problémájának nevezik, és kiküszöbölésének több módja ismert. Szoftveresen egy

hosszabb időszak számlálóállásaiból képezzük az adott időszak átlagfogyasztását (intenzitá-

sát). Korrektebb megoldás, ha az impulzus frekvenciájára nem a számlálóállásokból, hanem

két impulzus felfutó (vagy lefutó) éle között eltelt időből következtetünk.

Általában a technológiai jellemzők, pl. egy kemence munkaterének hőmérséklete, nem

változhatnak ugrásszerűen. Ha két egymást követő mintavétel adataiból kiszámított változási

sebesség meghalad egy hihetőségi határt, akkor az adatot hihetetlennek kell minősíteni.

Az adat hihetetlensége a mérőeszköz, ill. a kommunikációs csatorna pillanatnyi hibá-

jára utal, és ekkor az adat pótlásáról kell gondoskodni. Többféle adatpótlási technika szoká-

sos. A leggyakoribb módszer az, hogy hihetetlenség esetén az adatot az utolsó érvényes érté-

kével helyettesítjük (pótoljuk). Az adatpótlás időtartamát nem lehet önkényesen választani.

Amennyiben pl. egy gyorsan változni képes nyomás nagyságát több perc időtartamban pótol-

juk, úgy ennek az adatnak már semmi köze nincs a valósághoz, csak a kezelőt vezeti félre.

Nem célszerű olyan rendszereket tervezni, amelyek a technológia nélkül is képesek adatokat

megjeleníteni, azokból következtetéseket levonni. Helytelen tervezési gyakorlat, hogy a leg-

apróbb hiányosság esetén is riasszuk a kezelőt, mert így eltereljük a figyelmét a technológia

érdemi felügyeletétől. Valamilyen ésszerű kompromisszumot kell találni a technológia isme-

retében az adatpótlás módjáról és időtartamáról.

A technológiai mért jellemzői (pl. nyomás, hőmérséklet, szint) normális üzemelés ese-

tén egy-egy előre meghatározható, a hihetőségi tartománytól lényegesen szűkebb, tartomá-

nyon belül változnak. A tartomány határain való átlépéskor fel kell hívni a kezelő figyelmét a

rendellenességre. Ezt a funkciót alarmvizsgálatnak nevezik. A gyakorlatban az alarmmini-

mum és az alarmmaximum figyelésén túl esetleg a változás sebességének (trend)

alarmvizsgálata szokásos. Ha a mért technológiai jellemző az alarmhatár szűk környezetében

ingadozik, akkor a kezelő folyamatosan figyelmeztetést kap arról, hogy az alarm fellépett, ill.

megszűnt. Ez rendkívül zavaró, ezért gyakran az alarm fellépésekor az alarm határát

automatikusan egy adott értékkel eltolják (maximum esetén csökkentik, míg minimum esetén

növelik), majd a normál értékre való visszatérést követően visszaállítják az eredeti értékre,

megszüntetve a jelenséget.

10.1.3. A feldolgozási feladatok

A technológiából származó jelzésekhez és mérési adatokhoz számos feldolgozási feladat kap-

csolódhat, amely feladatok megoldását a vizualizáló programrendszernek kell biztosítania.

a) Eseményüzenetek

A jelzések változásához gyakran       szöveges eseményüzenetet rendelnek. Az esemény-

üzenet a jelzésváltozáshoz kapcsolódó történést fogalmazza szövegesen. Egy eseményüzenet

például a következő:

2000 jan. 26. 12:15:23 A T1001 tartály szintje a maximum felett.

Ezeket a szöveges üzeneteket azonnal a kezelő tudomására kell hozni (pl. a képernyő

egy elhatárolt ablakában), mert előfordulhat, hogy valamilyen kezelői intézkedés válik szük-

ségessé. Az ilyen üzeneteket vészesemény-üzeneteknek nevezik. Vannak rendszerek, ahol kö-

vetelmény, hogy a technológia normál történéseiről is ún. közönséges eseményüzenetek gene-

rálódjanak. Vész- vagy közönséges eseményüzeneteket nemcsak a jelzések változása generál-

hat, hanem a mérőcsatornákhoz is kapcsolódhatnak akár vész-, akár közönséges eseményüze-

netek. Például, ha egy nyomás túllépi a felső vészhatárt (alarm), akkor egy vészüzenetet kell

generálni. Az eseményüzeneteket az esemény fellépésekor és a megszűnésekor hozzák létre.

A rendszerek tervezésekor gondosan elemezni kell, mely állapotok fellépése tekinthe-

tő vészállapotnak, azaz mely eseményekhez kapcsoljunk vészüzeneteket. Ha egy rendszerben

indokolatlanul gyakran jelennek meg vészüzenetek, akkor a kezelő képtelen lesz felismerni

egy tényleges vészállapotot. Hasonló dilemma a rendszerek tervezésekor, hogy megkövetel-

jük-e a vész-eseményüzenetek nyugtázását (pl. egy billentyű megnyomásával) a kezelőtől,

vagy jelenítsük meg számára automatikusan a következő frissebb vészüzenetet anélkül, hogy

a korábbi üzenetsort nem olvasta el. Mindkét változatra vannak példák, általános szabályokat

nem lehet felállítani.

A vészüzeneteket a rendszerben archiválni kell, hogy a legfontosabb rendellenességek

fellépése és megszűnése nyomon követhető legyen. Az archiválás napjainkban egyre inkább

egy  adatbázisban történő tárolást jelenti. A megőrzés időtartama a néhány naptól a néhány

hónapig igen változatos lehet, a technológia jellegétől függően. A vizualizáló rendszernek az

archiválás mellett lehetőséget kell teremtenie, hogy az adatarchívumból kikeressük a szá-

munkra érdekes eseményüzeneteket. A keresés tipikusan egy adott időtartamra, esetleg adott

objektumra (pl. T1001 tartály) vonatkozik. Néhány esetben a korábbi számítógépes hagyomá-

nyok alapján követelményként fogalmazzák meg az azonnali eseménykinyomtatást egy külön

ún. eseménynyomtatón.

b) Származtatott adatok előállítása

Gyakran a mérési csatornák adataiból valamilyen algoritmus alapján kell előállítani a

kezelő számára szükséges adatokat. Ha az áramló gáz mennyiségét mérőperemmel mérjük,

úgy a gáz mennyisége (normál állapotra számított értéke):

dpp

q = c

T

(10-1)

ahol q a gáz mennyisége, c a mérőperem konstansa, dp a mérőperemen létrejövő nyomásesés,

p a gáz abszolút nyomása és T a gáz hőmérséklete.

A kifejezés alapján látható, hogy három mérőcsatorna adatából határozhatjuk meg a

számunkra szükséges gázmennyiséget.

Egy másik példa a származtatott adat előállítására egy gömbtartály olajkészletének a

figyelése. Ha mérjük a gömbtartályban lévő olaj szintjét, már az is igen fontos információ, de

ebből célszerű meghatározni, hogy mennyi a tartályban lévő olaj térfogata. Ehhez a szintér-

tékhez egy tartálykalibrációs táblázat alapján, ahol adott lépésközzel az összetartozó szint- és

térfogatadatok találhatók, hozzárendeljük a térfogati adatot, mint származtatott mennyiséget.

A tartálykalibrációs táblázat a vizualizáló rendszer adatbázisának a része, és az összerendelés

algoritmussal történik.

A példák nagy számban sorolhatók, a különböző technológiáknál igen változatos szár-

maztatott mennyiségek előállítására van szükség a technológia követése érdekében.

c) Adatarchiválás

A vizualizáló rendszerek alapvető követelménye, hogy legyen lehetőség az adatok ar-

chiválására. Az adatarchívumokba tipikusan a mérési csatornák adatait (nyomások, hőmérsék-

letek, közegáramok stb.) tárolják, de a jelzéseket is archiválni kell. Az archiválásnak az a cél-

ja, hogy a kezelő bármikor megjeleníthesse egy vagy több mennyiség időbeli alakulását

(trendjét). Technológiafüggő az, hogy egy archívumba mennyi ideig kell egy adatot megőriz-

ni. Például nagy tömegű sósav regenerálási ciklusa több (három-négy) hét időtartam is lehet,

ezért nem túlzott igény, ha az egyhónapos adatmegőrzést követeljük.

A legegyszerűbb adatarchiválási technika, hogy          minden egyes mintavételkor minden

egyes mérési csatorna adatát azonosítóval, dátummal, ill. időponttal kiegészítve az adatbá-

zisba helyezzük. Nézzük meg, hogy ez a módszer milyen tárolási helyigényt jelent. 2 s minta-

vételi idővel számolva mérőcsatornánként 1339200 rekordot kell bejeg ezni az adatbázisba

egy hónap (31 nap) alatt. A rekord mérete még a legtakarékosabb számábrázolási esetben is

minimum 10 bájt (azonosító 2 bájt, adat 4 bájt, dátum és idő 4 bájt), azaz a helyigény mintegy

13 Mbájt mérőcsatornánként. Sok mérőcsatorna hosszú idejű archiválására a fenti módszer

még nagy háttérkapacitás esetén sem alkalmazható.

A gyakorlatban a mért mennyiségek normál üzemelésnél nem változnak gyorsan. A

nyomás vagy a hőmérséklet az esetek jelentős részében hosszú ideig nem, vagy alig változik.

Ilyen esetekben jelentősen csökkenthetjük a helyigényt, ha egy mérőcsatorna adatát (azonosí-

tóval és dátummal, ill. időponttal kiegészítve) csak akkor írjuk be az archívumba, ha a mért

adat a korábban letárolt értékhez képest egy általunk előírt szignifikáns változási küszöbnél

nagyobb mértékben megváltozott. Tehát pl. egy hőmérséklet csak akkor kerül az archívumba,

ha az aktuális értéke pl. 0,5 C nagysággal eltér az utoljára tárolt értéktől. Az egész archiválá-

si módszer értelmét veszti akkor, ha az archívum pontossága érdekében túl kicsire választjuk

a szignifikáns változási küszöböt, vagy a mért mennyiségek két mintavétel között jelentősen

megváltoznak.

Egyes vizualizáló rendszerek az adattömörítés érdekében azt a technikát alkalmazzák,

hogy a mért adatok (időben lineáris) változási trendjét tárolják az archívumba. Csak akkor

kerül új bejegyzés, ha az adat a trend alapján meghatározott értéktől szignifikánsan eltér. Az-

az minden rekord az adaton (azonosítón és dátumidőponton) túl tartalmazza az adat változási

meredekségét is a korábbi adatok alapján. A gyakorlat szerint ez a tárolási technika nagyon

hatékony adattömörítést biztosít, viszonylag kis háttérkapacitáson igen hosszú idejű visszate-

kintést lehet biztosítani.

d) Post-mortem adatarchívumok

A post-mortem archívumoknak az a szerepe, hogy egy üzemzavar után meg lehessen

határozni a zavar okát. Az archívum gyakorlatilag minden mérőcsatorna és jelzés értékét tar-

talmazza minden egyes mintavételi időpontban. Az elévült adatok felülíródnak, azaz ha az

archívumot egy táblázatnak képzeljük el, akkor az utolsó sor (rekord) beírását követően ismét

a táblázat első sorától kezdve írjuk be az adatrekordokat.

A post-mortem archívum írása feltételekhez kötött. Ha a normál üzemelésre vonatkozó

feltételek teljesülnek, akkor az archívum az említett módon íródik. Ha egy, az üzemzavart

tükröző feltétel (pl. tartálynyomás a maximum fölött jelzés logikai 1 értékű) az archívumba

írás megszűnik, és az archívum tartalma az üzemzavart megelőző időszakot tükrözi. Ennek

kiértékelése alapján meg lehet határozni, hogy milyen okok vezettek az üzemzavarhoz. Az

archívum írásának ismételt bekapcsolását az ok megszűnését követően a kezelő kezdeménye-

zi.

A post-mortem archívumok általában azért különülnek el a korábbi archívumoktól,

mert a normál archiválás helytelen paraméterezés esetén pontatlan, és egyáltalán nem biztos,

hogy a hibaok kiderítéséhez szükséges valamennyi adat normál archiválása előírt. A post-

mortem archívumok alapján kellő intelligenciájú rendszerben az üzemzavar előtti időszak

lépésről lépésre tetszőleges lassítással lejátszható. Egy ilyen rendszer jelentőségét pl. a vasúti

forgalmat felügyelő rendszer esetén nem lehet túlbecsülni.

e) Órás, műszakos, napi adatok előállítása

A gyakorlatban az adatok áttekinthető terjedelemre tömörítésének egyik legáltaláno-

sabb elve, hogy egy adott időszakra (órára, műszakra, napra) vonatkozó értékét állítjuk elő, és

jelenítjük meg a termelési naplókban.

A kötött (1, 8, 24 óra) időtartamú adatok előállításának elvei

Az intenzitást tükröző adatokra (nyomás, hőmérséklet stb.) az adott időtartamra vo-

natkozó átlagértéket állítják elő. Általában az átlagérték önmagában nem tükrözi megfelelően

az adott időszak történéseit, ezért előállítják az adat átlag körüli ingadozására jellemző mérő-

számot is. Ez kézenfekvően a szórás lehet, de az adott időszakon belüli legkisebb (minimum),

ill. az adott időszakon belüli legnagyobb (maximum) adat értékének tárolása is elfogadott.

Szabályozott jellemzők esetén a kívánt értéktől vett eltérés átlagát, ill. ennek ingadozását is

előállíthatjuk.

A fogyasztással kapcsolatos adatokra (gáz, víz, elektromos energia) általában az idő-

szakra vonatkozó felhasználás (fogyasztás) meghatározása a cél. Amennyiben a mérőeszköz a

fogyasztás pillanatnyi nagyságával (pl. m /h) arányos jelet szolgáltat, a számítógépes rend-

szernek az idő szerinti integrált értéket kell előállítania. Ez tipikusan a téglányszabály szerinti

közelítéssel történik. Ha a mérőeszköz a fogyasztással (pl. m ) arányos számú impulzust szol-

gáltat (pl. áramlásmérők), akkor a fogyasztást az impulzusok egyszerű összegzésével határoz-

zák meg.

A készletekre jellemző (pl. tartály folyadékszintje, vagy folyadék térfogata esetén),

hogy az adott időszak utolsó érvényes adatát használják fel. Ez az adott időszak (óra, műszak,

nap) végén érvényes készlet képzését jelenti.

A 8, 24 órás adatok akkor korrektek, ha az adott óra valamennyi mintavétele során a

mérőcsatorna hihető adatot szolgáltat. Egy folyamatosan üzemelő berendezésnél óhatatlanul

előfordul, hogy a mérőeszköz vagy a kommunikáció meghibásodik, vagy a vizualizáló szoft-

vert tartalmazó számítógépet rövidebb-hosszabb időszakra kikapcsolják vagy meghibásodik.

Ekkor felvetődhet az igény, hogy a hihetetlen adatokat manuálisan pótolni lehessen. Az al-

kalmazók igénylik, hogy a manuális adatpótlás korlátozás nélkül − a termelési naplóban meg-

jelenő adatcsoportokra − alkalmazható legyen. E törekvés magyarázataként számos műszaki

okot szoktak felsorolni, de a tényleges ok az adatok utólagos módosításának a lehetősége. Ezt

a törekvést mindenképpen meg kell akadályozni, mert ellenkező esetben a számítógépes rend-

szer objektivitásába vetett bizalmat néhány hetes üzem után elveszíti. A manuális adatpótlást

csak a célszerűen órás adatokra szabad a rendszernek engedélyezni, ahol jelentős időre hiá-

nyoznak az objektív adatok. Azt a tényt, hogy az adat manuálisan pótolt az adatot kísérő stá-

tusváltozóban, ill. a naplóban is jelezni kell.

Az adatokat termelési (órás, műszakos, napi) naplókban szokás megjeleníteni. A nap-

lók a mérési adatokkal kapcsolatos információk mellett az adott időszak egyéb történéseit is

tartalmazzák. Meg kell jeleníteni az adott időszakra vonatkozó vész-eseményüzeneteket, ame-

lyek alapvetően a jelzésváltozáshoz köthetők.

Gyakori követelmény, hogy a műszakváltáskor (amikor a kezelők is kicserélődnek)

készített naplóknak tartalmaznia kell a műszakváltás pillanatában fennálló vészjelzéseket, ill.

ezek jelentését. A szolgálatot átvevő kezelőnek ismernie kell az üzemelés rendellenességeit.

A naplók tervezésénél abból az alapelvből kell kiindulni, hogy ezek a termelési folya-

mat elsődleges dokumentumai, és a termelés menetét alapvetően befolyásoló minden tényező-

re következtetni lehessen.

f) Kötetlen időtartam adatainak előállítása

Az olajkutak hozamának megváltozását úgy követik nyomon, hogy havonta egyszer

egyedi mérőszeparátorra kapcsolják, mivel nincs annyi mérésre alkalmas mérőszeparátor,

ahány olajkút van egy termelőtérségben. A technológiai előírás szerint minimálisan 24 óra

időtartamban mérni kell a főtermék (olaj), a segédtermék (kísérő gáz), a melléktermék (víz)

hozamát (térfogatáramát), valamint mérni kell a kútfej nyomását (átlagértékét), a hőmérsékle-

tet (átlagértékét) és néhány más paramétert.

Egy tartály készletváltozásának (betárolás, kitárolás, áttöltés) figyelése a tartályműve-

let kezdetéhez, ill. befejezéséhez köthető, aminek sem a kezdete, sem az időtartama előre nem

rögzíthető.

Ezekben az esetekben is az órás, műszakos, napi adatok átlag-, fogyasztás-, készlet-

adat-fogalmaival találkozunk, de nem meghatározott időtartamra képezve. Az adatok képzé-

sének kezdetét és végét általában a jelzések megváltozása jelöli ki. Mind az olajkút, mind a

tartály esetén a tolózárak jelzéseiből következtethetünk a műveletek kezdetére és a befejezé-

sére.

g) Üzemelési idő előállítása

Gyakori feladat, hogy egy technológiai berendezés különböző üzemmódjainak üzem-

idejét kell előállítani. Meg kell határozni, hogy egy adott időszakban egy kompresszor meny-

nyi ideig működött. Elő kell állítani, hogy egy olaj vagy gázkút mennyi ideig volt mérőszepa-

rátoron, mennyi ideig működött közös szeparátoron, és mennyi ideig állt.

Az üzemidő-előállítás jelzések vagy jelzéscsoportok változásához kapcsolható. Egy-

szerű esetben (pl. a kompresszor) egyetlen jelzés logikai 1 vagy 0 értéke jelenti az üzemidő

képzésének alapját. A gáz- vagy olajkút esetén már csak több jelzést tartalmazó jelzéscsoport

kiértékelése alapján következtethetünk az üzemidőre.

10.1.4. Kezelői jogosultságok

Egy nagy rendszer felügyeletét nem egyetlen kezelő látja el, mert erre még számítógépes tá-

mogatással is képtelen. Több kezelő esetén felmerül a jogosultságok kérdése, a kezelőket nem

feltétlenül azonos jogosítványokkal kívánják ellátni.

Nem törvényszerű, hogy a technológiai folyamat valamennyi adatába valamennyi ke-

zelő betekinthessen. Lehetséges, hogy pl. mérőcsatornánként kell előírni, hogy egy-egy csa-

torna adatát mely kezelők ismerhetik. Ez nem azt jelenti, hogy egy csatorna adatát csak egyet-

len kezelő látja, de nem mindenki számára biztosított a betekintési jog az adott mérőcsatorna

adataira. A   betekintési jog meghatározása az adatbázis valamennyi adatcsoportjára követel-

mény.

A kezelők tevékenysége nem pusztán az adatok megtekintésére korlátozódik. Ha pl.

egy mérőperemet üzemszerűen (1-2 nap gyakorisággal) váltogatnak, akkor az adatbázisban a

mérőcsatornához tartozó peremkonstansot módosítani kell. Az adat módosítási joga nem fel-

tétlenül biztosítandó minden kezelő számára. A kezelők adatmódosításait rögzíteni kell, pl.

eseményüzenet formájában. Az üzenetek tartalmazzák, hogy melyik adatot, mikor, ki és mire

módosította.

A munkamegosztásból adódóan nem célszerű minden eseményüzenetet minden kezelő

képernyőjére kiküldeni. Objektumonként (pl. jelzésenként, mérőcsatornánként) előírják az

eseményüzenet illetékességet. Ez azt jelenti, hogy egy esemény csak azon kezelők képernyő-

jén jelenik meg, akik az illetékességi körbe esnek.

10.2. A folyamatvizualizáló rendszerek szolgáltatásai

Ha egy adott technológia esetén a kívánságok és a vizualizáló rendszer szolgáltatási köre fedi

egymást, akkor viszonylag kevés munkával (paraméterezéssel) megoldhatjuk a feladatokat.

Ez egy idealizált állapot, a kívánságok köre általában meghaladja a lehetőségeket. Ilyen eset-

ben a vizualizáló szoftver keretrendszerén belül egyedi komponensek megírása szükséges a

nem preferált funkciók leképezéséhez. A komponenseket vagy egy magas szintű program-

nyelven (pl.Visual BASIC), vagy egy interpreter nyelv felhasználásával írhatjuk meg a vizua-

lizáló rendszertől függően.

A vizualizáló rendszer használata időben elválasztható részekre bontható:

− az alkalmazás kifejlesztésének fázisa;

− a kész rendszer futtatása.

A fejlesztéshez a vizualizáló rendszerek ún. fejlesztő változatát kell használni, ami

biztosítja a grafikus szerkesztést, a kép dinamizálását (animálását), az azonosítók és a techno-

lógiai objektumok összerendelését stb. A kifejlesztett rendszer olyan PC-n is futtatható, amely

csak a vizualizáló rendszer egy futtatható verziójával rendelkezik. A kétféle verzió árban igen

jelentős mértékben eltér, ezért nem lényegtelen, hogy több PC esetén milyen módon rendeljük

meg a vizualizáló szoftvereket.

10.2.1. A vizualizáló rendszer és a technológia közötti kommunikáció

Egy folyamatvizualizáló rendszer legalapvetőbb feladatai közé tartozik, hogy a technológiá-

hoz igazodó gyakorisággal lekérdezze az aktuális jelzésállapotokat és egyéb mérési csatornák

adatait. Ezek a technológiai adatok tipikusan PLC-berendezésekben képződnek, és a vizuali-

záló rendszer a PLC-egységeket kérdezi. Napjainkra sem sikerült különböző okok miatt egy-

ségesen használható kommunikációs felületet kialakítani a PLC-technikában. Így a vizualizá-

ló rendszerek opcionálisan nagyszámú, különböző gyártmányú PLC-protokollját ismerik (ti-

pikusan 40...100), és közülük választhatjuk ki a számunkra szükséges protokoll típusát. A

vizualizáló rendszer kiválasztásának legalapvetőbb szempontja, hogy vajon az adott rendszer

képes-e kommunikálni az alkalmazott PLC-berendezésekkel. A PLC-kommunikáció kiválasz-

tásának menülapjait a 10.1. és a 10.2. ábrák mutatják [1].

10.1. ábra. Az alkalmazott PLC és kommunikációs mód kiválasztása

Gyakorlatilag értelmét veszti egy vizualizáló rendszer, ha az alkalmazott PLC kom-

munikációs programja nem létezik, mert ennek egyedi fejlesztése számos akadályba ütközik,

és kicsi az esélye, hogy határidőre, ill. megfelelő minőségben előállítsuk.

A PLC-k gyártóspecifikus kommunikációs protokollja nem túl nyilvános, és az is kér-

déses, hogy az esetleges protokoll-leírás vajon az adott verziójú PLC-vel ténylegesen kompa-

tibilis-e. A vizualizáló szoftverek napjainkban általában PC-s környezeten Windows operáci-

ós rendszer alatt működnek. A vizualizáló szoftverek és a kommunikációs program közötti

adatcsere általában a DDE (Dynamic Data Exchange, dinamikus adatcsere) szolgáltatással

valósul meg. A kommunikációs szoftverek önálló kereskedelmi termékként is megjelenhet-

nek, azaz egyedi fejlesztésű programok használhatják a szolgáltatásokat.

Megfigyelhetők olyan törekvések is, hogy különösebb indok nélkül a lehető leggyor-

sabb, egyben a legdrágább megoldást preferálják. Egy nem gyorsan változó, néhány 10 mérő-

csatornát és jelzést tartalmazó rendszernél nem biztos, hogy a lehető legnagyobb adatátviteli

sebességet kell elérni. A folyamatvizualizáló rendszereket nem szokás közvetlen vezérlési és

szabályozási algoritmusok realizálására felhasználni, alapvetően üzembiztonsági okok miatt.

A megjelenítendő adatok frissítési idejét nem célszerű (indokolt) 1-2 s alá csökkenteni, így az

átviendő információmennyiségből és a kívánatos frissítési időből meghatározhatjuk, hogy

számunkra hozzávetőlegesen milyen sebességű átviteli vonalra van szükség.

10.2. ábra. A kommunikáció választását segítő súgó lapok

A PLC-berendezések normál (hagyományos) kommunikációs vonalai 19200 Baud át-

viteli sebességre képesek RS 232C vagy RS 485 vonalon. A vonalak protokolljai egy master

kiszolgálását tételezik fel. Ezért csak olyan rendszertechnikai kialakításoknál jöhetnek szóba,

amikor a vizualizáló rendszert tartalmazó PC lehet az egyetlen master, míg a PLC-k slave-

ként viselkednek. Ha ez rendszertechnikailag nem tartható, vagy az átviendő információ túl

sok, akkor mindenképpen a nagy sebességű, több master kiszolgálására alkalmas megoldáso-

kat kell választani, ami a PLC-ben is többletberuházást, esetleg nagyobb teljesítményű PLC-

változatot igényel.

10.2.2. A szerver- és klienskapcsolatok

Egy technológia felügyeletét az esetek többségében több kezelő látja el. Ennek megfelelően a

vizualizáló rendszernek több munkahelyen (PC-n) kell egyidejűleg működnie ún. szerver-

kliens kapcsolatú rendszerrel (10.3. ábra) [1].

10.3. ábra. Vizualizáló rendszer kialakítása szerver- és kliensgépekkel

A szervergép áll kommunikációs kapcsolatban a PLC-berendezésekkel, ill. tartalmaz-

za az adatbázist és végzi a feldolgozásokat, míg a kliensek nagy sebességű kommunikációs

vonalon a szervergéptől kérik a megjelenítéshez szükséges adatokat. A szervergép megjelení-

tő munkahelyként is használható. A szervergép munkahelye és a kliensgépek munkahelyei

felhasználói szempontból vagy azonosak, vagy más vizualizáló rendszerek esetén eltérők.

Vannak rendszerek, ahol a kliensmunkahelyek csak megjelenítésre használhatók, kezelői pa-

rancsok nem adhatók ki, adatmódosítás nem végezhető.

A vizualizáló rendszer egy szervere által kezelt objektumok (TAG) maximális száma

kötött. A rendszerek árát nagymértékben a kezelni kívánt objektumok és a kliensek száma

határozza meg. A TAG számra vonatkozó korlátozást az indokolja, hogy még egy gyors gép

esetén sem lehetne biztosítani a kívánt mintavételezési időt az adatbázis méretének korlátozá-

sa nélkül. Amennyiben a technológia terjedelme lehetetlenné teszi, hogy egy szerver alkalma-

zásával oldjuk meg a feladatot, akkor feladatmegosztás szükséges a 10.4. ábra szerinti módon

A 10.4. ábrán látható, hogy a felügyeleti rendszer üzembiztonságának növelését a re-

dundancia beépítésével (jelen esetben az azonos funkciójú szerverek és az adatátviteli utak

megkettőzésével) érhetjük el.

Napjaink törekvése, hogy a vizualizáló rendszerek kliensgépeire ne kelljen telepíteni

speciális programrendszert (a vizualizáló rendszer kliensszoftverét), hanem bármely hálózati

gépről interneten (intraneten) keresztül elérhető legyen a szolgáltatás. Ez azt jelenti, hogy a

hálózati gépek böngészőprogramjával lehet a vizualizáló rendszer szerverének szolgáltatásait

igénybe venni.

10.4. ábra. Több szervert tartalmazó redundáns rendszerkialakítás

10.2.3. A vizualizáló rendszer adatbázisának elérése

A vizualizáló rendszerek adatbázisa tartalmazza a technológia működésével kapcsolatos ada-

tokat. Az adatok egy részére a vállalatirányítási rendszer magasabb hierarchiaszintjének is

szüksége lehet. Ezért a vizualizáló rendszerek lehetőséget biztosítanak, hogy                hálózaton ke-

resztül az adatbázis adatait más számítógépek is elérjék az ODBC (Open DataBase

Connectivity) felületen keresztül, szabványos SQL hívásokkal.

Az SQL hívásokon keresztül az adatelérési idő nagyságrendekkel megnövekszik a vi-

zualizáló szoftverek belső adatbázis-kezelési idejéhez képest. Ezért nem célszerű olyan rend-

szereket tervezni, ahol ezen felületen akarunk nagy gyakorisággal adatokat cserélni (pl. a pil-

lanatértékeket kiemelni egy külső rendszer számára). A kísérletek szerint ugyanaz a

hardvereszköz (két PC közvetlenül hálózatba kapcsolva), ugyanaz a szoftverkörnyezet

(Windows NT 4.0) adatelérési ideje különbözik SQL hívásos adatcsere, ill. egyedi, direkt

címkiszámításon alapuló adatbázis-kezelési technika alkalmazásakor. Az ORACLE

adatbázis-kezelő rendszernek 10000 rekord felvitelére 210 s, míg az egyedi kezelés esetén

mindössze 0,2 s időre volt szükség. Ezt a több mint ezerszeres sebességkülönbséget a

rendszerek tervezésekor nem hagyhatjuk figyelmen kívül.

10.2.4. Technológiai sémaképek létrehozása

Egy képernyőn a legtöbb információt áttekinthető formában grafikus képpel közölhetjük.

Ezen ok és a hagyományok miatt is a technológiai folyamatok pillanatnyi állapotát a sématáb-

lákhoz hasonló formában jelenítik meg.

Egy technológia jellemzői egyetlen képernyőlapon a legritkább esetben jeleníthetők

meg. Általában a technológiai sémát áttekintő és részletező képekre bontják. Az áttekintő ké-

pek csak a legfontosabb technológiai jellemzőket mutatják. Amennyiben valamelyik techno-

lógiai részletre vagyunk kíváncsiak, akkor az adott részletnek megfelelő képet hívjuk be. Egy

nagy technológia esetén a képek több szintjét szokás kialakítani (egyre kisebb részlet egyre

teljesebb információit jelenítjük meg).

A grafikus képek elkészítése a kép fix (időben állandó) részének kidolgozásával kez-

dődik. A sémát általában a vizualizáló részét képező grafikus editorprogrammal rajzoljuk. A

rajzolásnál jelentős segítséget nyújthat, hogy egy                   grafikuskönyvtárból a leggyakoribb

sématáblaelemek (tartály, tolózár, villamos motor stb.) kiemelhetők, és többnyire minőség-

romlás nélkül nagyíthatók, ill. kicsinyíthetők. A 10.5. ábra egy vizualizáló rendszer könyvtá-

rának néhány objektumra vonatkozó képét mutatja [1].

10.5. ábra. Technológiai berendezések szimbólumai

A technológiai kép megszerkesztése a segédeszközökkel is meglehetősen időigényes

tevékenység. Talán ez az egyik indoka, hogy egyre gyakrabban a technológia digitális fény-

képezőgéppel készített felvételét építik be a vizualizáló rendszerbe fix képként.

A fix kép önmagában nem sok információt hordoz. Ezt a képet dinamizálni, más szó-

val  animálni kell, hogy a futás során a technológia aktuális állapotára jellemző információk

frissülve megjelenjenek. A képek fejlesztésénél az alábbi animációs formákat alkalmazzák.

Színanimáció

Ez az animációs forma azt jelenti, hogy a grafikus kép egy kijelölt objektumának színe

a grafikus objektumhoz rendelt változó(k) értékétől függően más és más lesz. Tipikus példa,

hogy egy villamos motort ábrázoló képrészlet attól függően jelenik meg zöld, ill. piros szín-

nel, hogy a motor működését mutató kétállapotú jelzés logikai 1 (működik), vagy logikai 0

(nem működik). A motor vagy azért nem működik, mert normál módon leállítottuk, vagy

azért mert pl. a motor túlterhelése miatt a hőkioldó működött. A hőkioldó működött, ill. nem

működött állapotát is kétállapotú jelzés mutatja. Ha azt is meg akarjuk jeleníteni, hogy milyen

ok miatt állt le a motor, akkor egy újabb képterület színét (ami a hőkioldó állapotát mutatja) a

hőkioldó állapotjelzésétől függő színben jelenítjük meg vagy a motort ábrázoló képrészlet

színét nem kettő, hanem a motor működésére jellemző jelzéspártól függően három különböző

színben jelenítjük meg. Egy képen, ha pl. üzemzavarra kívánjuk felhívni a figyelmet, akkor

ennek leghatékonyabb eszköze a képterület villogtatása.

10.6. ábra. Szabályozóberendezés adatainak megjelenítése

Szöveganimáció

Ha egy szövegablakban a működés során változó tartalmú szöveget kívánunk megje-

leníteni (pl. egy nyomás aktuális nagyságát), akkor ez a szöveganimáció. A szövegablakban

megjelenő információ egy adott objektumhoz (pl. mérőcsatornához, ill. pontosabban TAG-

hez) rendelhető. Előnyös, ha a szöveg megjelenítésénél a szöveg színe, esetleg a háttér színe

dinamikusan (feltételtől függően) változtatható.

Virtuális műszerek, oszlopkijelzők

Egy megadott változó értéke kijelezhető egy virtuális mutatós műszeren, vagy ami

gyakoribb, oszlopkijelzőn. Speciális kialakítás esetén a grafikai objektum (pl. tartály) belsejé-

ben a kiszínezett terület nagysága egy TAG értékével arányos (pl. tartályon belüli folyadék-

szint).

Kezelőszervek (nyomógombok, csúszkák, kapcsolók

A 10.6. ábrán látható kezelőszerveket helyezhetünk el a képernyőn. Ezek működteté-

sével akár a PLC kétállapotú vagy regiszterváltozóját állíthatjuk.

Mozgás, elfordulás

Egy grafikus objektum kirajzolási pozíciója egy változó (TAG) értékétől függ. Ezzel,

pl. a haladó mozgást végző munkadarab kirajzolási pozíciója a tényleges helyzetnek

megfelelően változik. A 10.7. ábra        egyszerű technológiai vázlat animálás közbeni állapotát

mutatja [1].

10.7. ábra. Technológiai vázlat fejlesztés közbeni állapotban

10.2.5. Eseménygenerálás

Egy logikai jelet azonosító TAG-hez eseményüzenet generálását rendelhetjük. Az esemény a

jelzés megváltozásakor generálódik, és archiválódik egy általunk megadott terjedelmű ese-

ménytáblában. Általában az események azonnal is megjeleníthetők a képernyő egy előre defi-

niált eseményablakában, de összesítőtáblák is képezhetők a 10.8. ábra szerinti módon [1].

10.8. ábra. Archivált események megjelenítése

10.2.6. Trend megjelenítése

A vizualizáló rendszerek biztosítják, hogy kijelölt csatornák (TAG-ek) adatai tárolódjanak az

adatarchiválási, ill. -tömörítési elvek valamelyike szerint. Ezen adatok bármikor trend formá-

jában grafikusan megjeleníthetők (nyomtathatók). A trendet megjelenítő képernyő a 10.9.

ábrán látható [1].

10.9. ábra. Trend megjelenítése a képernyőn

10.2.7. Egyedi szoftvermodulok fejlesztése

Gyakorlatilag minden feladat megoldásakor felmerül olyan feldolgozási, megjelenítési igény,

amely a vizualizáló rendszer szolgáltatásaival közvetlenül nem elégíthető ki. Ekkor szüksé-

gessé válik, hogy a funkciót egyedi szoftverkomponenssel valósítsuk meg.

Az egyedi komponens írása tipikusan a rendszertől nem teljesen független szoftverrel

történik (pl. egy általános célú C, C++), mert túl sok ponton kell kapcsolódni a vizualizáló

rendszer adatbázis-kezelő, ill. grafikus szolgáltatásaihoz. Ezért a vizualizáló rendszer része

egy olyan magas szintű leírónyelv, amellyel a feladat megfogalmazható, és a rendszer szerves

részének tekinthető. A leírónyelvek általában hasonlítanak a magas szintű programnyelvekhez

(C, Pascal).

10.3. SCADA rendszerek

Az ipari irányítástechnikai rendszerek terén a könyv írásának idején két kategória igen erős

versenye tapasztalható a piacon: a PLC-SCADA rendszerek és a DCS rendszerek (Distributed

Control System, osztott intelligenciájú folyamatirányító rendszer).

A PLC-SCADA kategória esetén a folyamatjeleket PLC-k vagy intelligens szabályo-

zók kezelik, azaz a vezérlést, a szabályozást ezen eszközök végzik, de az ember-gép kapcsolat

(MMI vagy HMI) a PC-n vagy munkaállomáson keresztül valósul meg, és az eszközöket va-

lamilyen ipari lokális hálózat (terepi busz) köti össze. Az ember-gép kapcsolatot kibővítve

értelmezzük a központi adatgyűjtéssel és a folyamatvizualizálással bemutatott valamennyi

funkcióval. A SCADA rövidítés a Supervisory Control and Data Acquisition angol névből

származik és felügyeleti irányítást és adatgyűjtést jelent.

A SCADA egy központi számítógépen futó szoftver, amelynek révén a rendszert alko-

tó PLC-k, szabályozók, CNC-k stb, valamilyen lokális hálózaton keresztül a DCS-hez hason-

ló funkciókkal rendelkező folyamatirányító rendszer létrehozására alkalmasak. Mivel a

SCADA-szoftver csak e rendszerben használható, ezért PLC-SCADA rendszerről beszélnek.

A PLC-SCADA rendszerek funkcionálisan igen nagy hasonlóságot mutatnak az 1. fe-

jezetben bevezetett és 11. fejezetben tárgyalt DCS rendszerekkel. Érdemes tehát a legfonto-

sabb hasonlóságokat és különbségeket összefoglalni.

Hasonlóságok

A modern PLC-SCADA és DCS kategóriájú rendszerek az utóbbi időben nagymérték-

ben közeledtek egymáshoz. Egyrészt a DCS-szállítók ember-gép kapcsolati eszköznek egyre

inkább munkaállomás alapú eszközt használnak, melynek konkrét feladatra konfigurálása

megegyezik a SCADA rendszerekével, másrészt a PLC-gyártók elsősorban a nagykategóriájú

PLC-családjaikban egyre több olyan megoldást alkalmaznak, amelyek korábban csak a DCS-

ekre voltak jellemzők.

A két rendszer struktúrája szinte azonos. Van egy vagy több megjelenítő számítógép

és egy folyamatillesztő rendszer, amelyeket valamilyen nagy sebességű adatátviteli hálózat

köt össze. A PLC és a DCS folyamatillesztő hardvere szinte semmiben sem tér el, mindkettő

moduláris, mindkettő rendelkezhet távolba kihelyezett modulokkal, ún. remote I/O rendszer-

rel és mindkét rendszerben nagy teljesítményű processzormodulok vannak.

Különbségek

Mindezek ellenére napjainkban még megkülönböztetik e két kategóriát.

A DCS típusú rendszereket eredetileg         bonyolult és általában veszélyes technológiák

felügyeletére fejlesztették ki és ezeket az ismertetőjegyeket ma is magukon viselik. Bár a

PLC-gyártók is igen nagy gondot fordítanak a megbízhatóságra, a DCS rendszerek esetében

ez különösen hangsúlyos szempont. A DCS rendszerek sokkal nagyobb mértékben tartalmaz-

nak redundanciákat, mint a PLC-k. Tipikus megoldás a PLC-knél a processzormodul opcioná-

lis megduplázása, az ún. hotstandby megoldás, tipikus a különféle adatátviteli hálózatok opci-

onális duplikálása, de nem tipikus a technológiai jeleket illesztő modulok megduplázása. Re-

dundáns analóg kimenet pl. csak külső szavazó áramkörrel valósítható meg. Ezzel szemben a

DCS rendszerek hardvere és alapszoftvere minden szinten támogatja a redundanciát, továbbá

a PLC-hez képest teljesebb az öndiagnosztika is. A DCS rendszerekben pl. előfordul, hogy

nincs külön analóg vagy digitális bemenet és kimenet, hanem analóg vagy digitális csatorna

van, amely konfigurálható akár bemenetnek, akár kimenetnek, hiszen pl. egy kimenetet úgyis

kapocslécszintről vissza kell mérni.

A DCS rendszerekben a folyamatközeli hardverek és az ember-gép kapcsolati eszkö-

zök sokkal inkább összedolgozott, egységes rendszert alkotnak. A PLC-SCADA rendszerek-

ben a PLC és a SCADA között ténylegesen csak az összekötő lokális hálózat tart kapcsolatot.

Külön fejlesztési környezete van a PLC-nek és a SCADA-nak. Sok esetben a PLC fejlesztő-

szoftver a SCADA hardveren is futtatható, de a SCADA szoftvertől teljesen független. Több-

nyire a  SCADA szoftver fejlesztője a PLC fejlesztőjétől teljesen független cég. Ez a külön

PLC- és SCADA-fejlesztési technológia számos esetben többletmunkát okoz a rendszerinteg-

rátor számára, pl. külön fel kell építeni a PLC adatbázisát és azt valamilyen gépi úton áttölteni

a SCADA oldalra. Több odafigyelést igényel a kommunikáció felépítése és sokszor nehézsé-

get okoz az, hogy bizonyos funkciók félig a PLC oldalon, félig a SCADA oldalon futnak, pl.

ha a PLC-n futó algoritmusokat a SCADA matematikai modulja támogatja, vagy recept vég-

rehajtása esetén annak lépéseit a SCADA futási időben adagolja a PLC-nek stb.

A PLC-SCADA rendszerek javára írható különbség, hogy sokkal szélesebb kapacitás-

tartományban nyújtanak piacképes megoldást, sokkal jobban támogatják a több lépéses rend-

szermegvalósítást és sokkal gazdagabb eszközválaszték áll a rendszerintegrátorok és végfel-

használók rendelkezésére.

A PLC-SCADA rendszerek szolgáltatásait a Citect          [1] főbb jellemzőivel szemléltet-

jük.

A rendszer felépítése

elosztott kliens-szerver-kialakítás;

központosított vészjelzés, trend- és naplófeldolgozás;

új hálózati PC-k hozzáadása programozás nélkül;

egyetlen adatbázis, mérethatár nincs.

Teljesítmény

a rendszerméret növekedésével nem csökken a teljesítmény;

100 000 egész változó/s adatgyűjtési sebesség;

alacsony hálózati terhelés méretektől függetlenül;

dinamikus optimalizálás minden I/O driver esetében;

kis CPU-teljesítményigény;

adatelérés csak igény esetén.

Hálózatkezelés

beépített hálózati redundancia lehetősége, 4-szeres biztonságig;

WAN, PSTN kapcsolt, RAS támogatás;

az internetes eléréshez nem kell a bejelentkező PC-n HW kulcs.

I/O kommunikáció

új I/O eszköz beállítása 60 másodpercen belül;

256 soros port szerverenként;

4095 I/O eszköz szerverenként;

definiálható kommunikációs hibajelzés;

minden soros meghajtó működtethető RS 232, TCP/IP, RS 422, RS 485, Arcnet in-

terfészek bármelyikén.

Hibatűrés

beépített elsődleges és tartalék funkciókészlet;

LAN-redundancia;

vészjelzésszerver-redundancia;

trendszerver-redundancia;

jelentésszerver-redundancia;

I/O-szerverredundancia;

automatikus tartalék át- és visszakapcsolás;

automatikus trendarchívum-szinkronizálás;

automatikus vészjelzésadatbázis-szinkronizálás;

időnyilvántartás-funkció redundanciája.

Változóazonosítás

max. 80 karakteres változóazonosítók (standard 32);

korlátlan számú változó lehetséges.

Képek

4096x4096 képfelbontás;

fokozatos képméret-változtatás futás alatt;

kétmonitoros alkalmazások támogatása;

objektumorientált RAD grafika;

szinkronizált villogó színek;

10 ms-tól állítható képfrissítési idő;

16,8 millió színből definiálható felhasználói színkészlet;

3D-s csövek, 3D-s hatások,

minden objektumra többszörös animáció;

szimbólumsor-animáció (mozgás);

korlátlan számú grafikus kép;

32000 animáció képenként;

közvetlen grafikus bevitel;

Windows Bitmap (BMP, RLE, DIB);

AutoCad (DXF);

Encapsulated Postscript (EPS);

Fax Image (FAX);

Ventura (IMG);

JPEG (JPG, JIF, JFF, JGE);

Photo CD (PCD);

Paintbrush (PCX);

Portable Network Graphic (PNG);

Targa (TGA);

Tagged Image Format (TIF);

Windows Meta File (WMF);

Wordperfect (WPG).

Szimbólumkönyvtárak

előre elkészített és szerkeszthető objektumkönyvtárak, képsémák és stílusok;

alkalmazások között átvihető szimbólumok;

kép frissítése automatikusan szimbólum változásakor;

animációs tulajdonságú könyvtárak;

több mint 500 előre gyártott szimbólum;

független fejlesztők szimbólumkönyvtárai.

Általános

minden PC-n automatikus időszinkronizálás;

95/NT4 látvány és érzet;

nemzetközi dátumformátumok;

12 és 24 órás időkijelzés;

megadható decimális jel.

Sémaképkönyvtárak

előre elkészített és szerkeszthető képsémák és stílusok;

alkalmazások között átvihető sémák;

kép frissítése automatikusan az alapséma változásakor;

animációs tulajdonságú sémák;

több mint 70 előre gyártott sémakép.

Adatátvitel

Támogatott

SQL kliens

ODBC kliens

OPC kliens

DDE

Email

DLL

Windows API

ASCII files

Serial.

Integrálva

Sixtrak

Steeplechase

Gello

VMIC

PID

SQL szerver

ODBC szerver

OPC szerver

MAPI

HTML

Citect API

Native dBASE

TCP/IP

Beckhoff

Paradym

OpenControl

AdvaBatch

FuzzyTech.

Alkalmazói programnyelv

(Cicode)

multitaszkos nyelvi környezet;

maximum 512 konkurensthread;

600-nál több beépített SCADA funkció;

funkciókönyvtárak felhasználói függvények készítéséhez;

több mint 2700 felhasználói funkció használható;

lokális, modulszintű és globális változók;

saját funkciók írása minden más segédeszköz nélkül;

közvetlen hozzáférés a trend-, vészjelzés- és jelentésadatokhoz.

Beépített szerkesztő:

töréspontos futtatás;

változó értékek ablaka;

programszálak követése;

színkódok;

töréspontok ablaka;

lépésenkénti futtatás;

aktuális programsor kijelzése;

remote debug (csak NT);

automatikus debug hiba esetén.

Többnyelvűség

többletkonfigurálás nélkül több nyelven futtatható;

nyelvváltás futás közben;

jelentések bármilyen nyelven;

vészjelzéslista bármilyen nyelven.

Vészjelzések

korlátlan számú vészjelzés;

központi vészjelzéskezelés.

Vészjelzéstípusok:

kétállapotú (1 vagy 2 trigger);

analóg határérték-túllépés;

kifejezés-kiértékelés eredménye;

kategória, területi beosztás és prioritás kezelése;

l ms felbontású időbélyegzett vészjelzés;

futás közbeni vészjelzéstiltás és küszöbérték-módosítás;

változó adatok behelyettesítése a vészjelzésüzenetbe;

csoportos vagy egyedi nyugtázás;

nyugtázás prioritás vagy kategória alapján;

vészjelzésre nyugta grafikus képről, listából vagy Cicode programból.

Trendek

korlátlan számú csatorna;

bármely csatorna megjelenítése l mp-en belül;

trend adatfájlméret választható;

archivált és valós idejű adatok együttes, folyamatos megjelenítése;

az időtengely felbontása folytonosan választható, akár l ms;

trendek összehasonlítása.

Jelentések

beépített jelentésszerkesztő WYSIWYN, Rich Text jelentés.

Indítási feltétel:

időpont;

külső esemény;

kifejezéskiértékelés;

kezelői beavatkozás.

Kimenet:

nyomtató;

e-mail;

HTML;

fájl;

képernyő.

Hozzáférési jogok

egyedi vagy csoportos hozzáférés;

250 egyidejűleg bejelentkezett kezelő;

korlátlan számú felhasználó definiálható;

jogosultsági szintek és területek kezelőnként megadhatók.

A hozzáférési szint befolyásolhatja

a grafikus elemek láthatóságát;

a képek hozzáférhetőségét;

a vészjelzések nyugtázhatóságát;

a jelentés indíthatóságát;

a rendszersegédprogramok, műveletek használatát.

Konfigurálás

csoportos fejlesztés egyidejűleg;

beépített, tömörített mentés, visszaállítás;

I/O eszközök szimulációja egyszerű átkapcsolással a valódi és a virtuális eszköz

között;

ipari, nem standard billentyűzetek támogatása;

korlátlan UNDD (grafikus szerkesztő);

konfiguráció automatikus dokumentálása.

Licencek

kulcs nélküli fejlesztés;

kulcs nélküli futtatás tesztje;

ugyanaz az installáció minden PC-n;

csak a külső folyamatváltozók számítanak;

korlátlan számú, ingyenes belső változók;

hw vagy sw licenckulcs.

Támogatás

beépített, on line protokoll analizátor;

beépített, on line parancs végrehajtás;

beépített, on line NETBIOS analizátor;

kernel ablak több mint 300 oldal rendszerinformációval;

tudásbázis;

internet-weboldalak.

Gépipari alkalmazásokhoz leginkább a FANUC cég           CIMPLICITY SCADA terméke

használatos, amelynek HMI for CNC funkciója révén a CNC-gépek kommunikációját a PLC-

khez hasonló módon oldja meg. Ehhez a CNC és a PC között nagy sebességű, optikai össze-

köttetés szükséges. Ezáltal a kezelő a CNC-re használhatja a CIMPLICITY valamennyi

szoftverfunkciót. A CIMPLICITY másik jellegzetessége a Webgate-way funkció, melynek

rendszervázlata a 10.10. ábrán látható. E funkció állandó betekintést biztosít az interneten

keresztül az üzem életébe a világ minden tájáról az internethez csatlakozó eszköz (LAP-

TOP), vagy telekommunikációs eszköz (mobil-WAP) révén.

10.10. ábra. Webgate-funkció

Felhívjuk a figyelmet a WONDERWARE cég által forgalmazott FACTORY SUITE

2000 elnevezésű programcsomagra, amely hét szoftverből áll (In-Touch, In-Control, In-Batch

stb.).

Napjainkban egyre inkább terjednek az olyan PC-bázisú rendszerek, amelyek a

SCADA-hoz hasonló funkciókat látnak el (Soft Logic), de a vezérlési és szabályozási funkci-

ókat is maguk a PC-k látják el szintén hálózati struktúrában, PLC-k nélkül.

10.4. Visual Logic Controller

A PLC-k másik versenytársa a piacon a PC bázisú irányítórendszer. A mikroprocessszor ala-

pú PLC-k és PC-k felépítése között nagyfokú a hasonlóság. A fő eltérés a hardver megbízha-

tóságában, ill. a szoftver kialakításában van, mivel a PLC-k valós idejű operációs rendszerrel

működnek. Utóbbi különbségre ajánl megoldást a Visual Logic Controller (VLC), ami egy

teljesen új megoldás a PLC-technikában, oly módon, hogy a PENTIUM processzorok telje-

sítményét, valamint a Windows NT előnyeit igyekszik kihasználni, ugyanakkor képes a Win-

dows-tól függetlenül, biztonságosan működni.

A VLC fejlesztésekor kiemelt figyelmet szentelnek arra, hogy a vezérlőprogram futta-

tása közben egy esetleges merevlemez-meghibásodás ne okozzon rendszerleállást. A VLC

ezért a futtatáshoz szükséges adatokat a memóriában tárolja, így a vezérlőprogram futtatása

idején nem kell a merevlemezről adatokat beolvasnia, arra csak a rendszerindításkor van

szükség. A futás közben fontosnak ítélt adatok a PC kikapcsolása után külön memóriakártyá-

ban megőrizhetők.

A VLC számára nem probléma a megfelelő I/O eszköz és PC kapcsolat. A VLC egyet-

len platformon több különböző gyártmányú, típusú, ill. buszcsatlakozású I/O egység vezérlé-

sére képes az eszközmeghajtók (driver-ek) széles választékának köszönhetően.

A fizikai I/O csatolást végző modulokat driver-ek illesztik a VLC-hez. A csatolást a

10.11. ábra szemlélteti [3].

10.11. ábra. Fizikai I/O-k szoftvercsatlakoztatása VLC-hez

A fizikai eszközök csatolásához tehát hardveres (interfészkártya) és szoftveres (driver)

megoldás szükséges a 10.12. ábra szerint [3].

10.12. ábra. Fizikai I/O-k hardverillesztése a VLC-hez terepi buszon keresztül

A gyártó cég napjainkban 21 cég eszközeihez kínál hardver I/O modult és VLC

drivert. Mind a PLC, mind a PC esetén a szoftverkörnyezet két részből áll: real-time operáci-

ós rendszerből (RTOS) és grafikus kezelői felületből (GUI, Grafical User Interfece). Míg az

előbbi a biztonságos és determinisztikus működésért felelős, az utóbbi feladata az ember-gép

kapcsolat megteremtése.

A VLC egy gépben a grafikus felhasználói környezetet real-time operációs rendszer-

ben egyesíti. A hagyományos PLC-s megoldásokkal szemben a VLC kihasználja a Windows

NT által nyújtott környezeti előnyöket, például a hálózaton keresztül végrehajtott gyors kom-

munikációt vagy a grafikus programozói-kezelői interfészt. A VLC legfőbb jellemzője, hogy

a real-time operációs rendszer prioritással rendelkezik a Windows NT-vel szemben, a

vezérlőrendszer a Windows-tól függetlenül fut, biztosítva ezáltal a vezérlőprogramoktól el-

várható teljesítményt és megbízhatóságot (10.13. ábra) [3].

A VLC túléli az ún. Windows "kék halált", így a folyamatirányítást nem befolyásolja

hátrányosan a Windows rendszerhibákból eredő instabilitás.

10.13. ábra. A Windows NT és a valós idejű operációs rendszer kapcsolata

A VLC működése lényegesen eltér az ún. szoft-PLC programoktól. A szoft-PLC és a

hard real-time vezérlés közti különbséget szemléltetik a 10.14. és 10.15 ábrák.

Szoft-PLC esetén a Windows alapvető funkciói élvezik a legmagasabb prioritást, pl. a

lemezműveletek, egérkezelés, billentyűzetkezelés stb., a vezérlési műveletek bármikor, akár a

vezérlési folyamat közepén is megszakítódnak. A ciklusidő így nem meghatározható, és a

valós idejű működés nem garantálható [3].

10.14. ábra. Szoft PLC PLC műveletvégzésének szemléltetése

Hard real-time vezérlés esetén a helyzet fordított: a folyamat szempontjából fontos

taszkok kapják a legmagasabb prioritást, míg az összes Windows folyamat a két ciklus között

kerül végrehajtásra (10.15. ábra), nem szakítja meg a vezérlést és ezáltal akár 1 ms-on belüli

ciklusidőt is lehetővé tesz [3].

10.15. ábra. Hard real-time PLC műveletvégzésének szemléltetése

A klasszikus PLC-vel megvalósított rendszerek külön hardver- és szoftverelemeket

használnak, ezért a rendszer konfigurálásához ugyanazt az adatot több helyen is el kell he-

lyezni. Így a rendszer legkisebb változtatásakor is valamennyi adatbázist egyenként módosí-

tani és tesztelni kell.

A VLC lehetővé teszi, hogy az összes szükséges adat egyetlen adatbázis szintjén le-

gyen egyesítve, ezáltal a szoftver valamennyi eleme (fejlesztő, MMI, DDE/OLE szerver stb.)

ugyanazokat a változókat használja. A VLC közös adatbázisának felépítését szemlélteti a

10.16. ábra [3].

10.16. ábra. Közös adatbázis-kezelés VLC-ben

A VLC támogatja a létradiagramos programozást is, de a folyamatábrával történő

programozás ajánlatos és elterjedt. Támogatja az on-line programozási lehetőséget, miáltal a

program futása közben is végrehajthatók módosítások, amelyek a program leállítása és újra-

indítása nélkül is azonnal érvényesíthetők. Kiemelkedő szolgáltatása a Diagnostic Manager,

amellyel lehetséges a hozzáférés egy sor felhasználó által kialakított HTML laphoz vagy egy

digitális kamera és MS PowerPoint segítségével elkészített segédanyaghoz, mellyel akár a

kezelő képes a meghibásodott gép javítására vagy újraindítására. Ezzel a web-technológián

alapuló eszközzel azok számára válik elérhetővé valamennyi információ a PC-n, az üzemi

LAN hálózaton és interneten, akikre ez leginkább tartozik.

A VLC támogatja a hálózaton keresztüli programfejlesztést és távprogramozást.

Irodalomjegyzék

Citect 5 folyamatmegjelenítő, felügyeleti programcsomag.

Termékismertető, 1999.

WONDERWARE: Factory Suite 2000.

USERS MANUAL, 2000.

Keresztesi K.: VLC, a megbízható PC alapú vezérlő.

Magyar Elektronika, 1999/10.

OMRON: SYSWIN leírás. 1999.

R. Carrow: Soft Logic. A Guide to Using a PC as a Programmable Logic Controller.

ABB: Industrial Manual, 1998.

SIEMENS: SIMATIC HMI.

Catalog ST 80.1, 1997.