Az eddigi fejezetekben a „hogyan beszélnek egymással az eszközök” kérdést jártuk körül. Ez a fejezet egy szinttel feljebb visz: hogyan lát rá egy kezelő egy egész gyárra vagy akár egy egész országot behálózó csővezetékrendszerre, és honnan tudja a rendszer, mikor kell magától beavatkoznia, mikor kell csak jelentenie.
- 7.1 SCADA: struktúra, elemek, kommunikáció
- 7.2 DCS: struktúra, elemek, kommunikáció
- 7.3 Az elemek kommunikációja és a fejlesztő szoftverek
- 7.4 HMI, központi adatgyűjtés, folyamatvizualizáció
- 7.5 A két kategória hasonlósága és különbsége
- 7.6 Konfigurálás dokumentáció alapján
- Összefoglalás
- Ellenőrző kérdések
- Tudáspróba
7.1 SCADA: struktúra, elemek, kommunikáció
Olyan rendszerarchitektúra, amely FÖLDRAJZILAG ELOSZTOTT (nagy távolságban lévő) folyamatok vagy eszközök felügyeleti szintű megfigyelésére és irányítására szolgál.
A SCADA-rendszer fő elemei:
A központi szerver, amely parancsokat küld a távoli egységeknek, és összegyűjti tőlük az adatot.
Terepi (helyszíni, távoli) eszköz, amely az érzékelőket figyeli, és végrehajtja az MTU-tól kapott vezérlési parancsokat.
Grafikus kezelőfelület a folyamat megjelenítésére és a kezelői beavatkozásra.
Ezeket egy kommunikációs hálózat köti össze — nagy távolságú SCADA-rendszereknél ez gyakran nem is vezetékes hálózat, hanem mikrohullámú, cellás (mobilhálózatos) vagy akár műholdas kapcsolat.
Az adatáramlás iránya:
Érzékelők → RTU (digitalizálja) → MTU (feldolgozza, tárolja)
→ HMI (megjeleníti a kezelőnek)
Kezelői parancs → MTU → RTU → BeavatkozókGyakori tervezési hiba lenne a GYORS szabályozási feladatokat (pl. egy PID-szabályozási kört 50-250 milliszekundumos ciklusidővel) a SCADA-szerverbe helyezni. A SCADA a FELÜGYELETI hurkot zárja — alapérték-módosítás, üzemmódváltás, riasztás nyugtázása, trendmegjelenítés —, a gyors szabályozási hurkot a helyi PLC/RTU vagy DCS-vezérlő végzi. A SCADA-lekérdezés, a HMI-megjelenítés és az adattárolás (historian) ugyanis jellemzően 250 milliszekundumtól akár több másodpercig terjedő késleltetést (jittert) ad hozzá — ez egy gyors szabályozási körnél elfogadhatatlan lenne.
7.2 DCS: struktúra, elemek, kommunikáció
Olyan architektúra, amely EGYETLEN LÉTESÍTMÉNYEN (üzemen, gyáron) belüli, folyamatos technológiai folyamat vezérlésére szolgál — a vezérlők, a be-/kimenetek és a kezelői állomások nagy sebességű, redundáns hálózaton, a gyáron BELÜL kapcsolódnak össze.
A DCS neve onnan ered, hogy a vezérlési feladatokat NEM egyetlen központi számítógép végzi, hanem TÖBB, a technológiához közel elhelyezett (elosztott) vezérlő osztja meg egymás között — miközben egységes, integrált felügyelet és kezelőfelület alá tartoznak.
A DCS-t tipikusan olyan üzemekben alkalmazzák (pl. vegyipari, olajfinomítói, erőművi), ahol a teljes technológiai folyamat egyetlen telephelyen zajlik — a vezérlők, az I/O-modulok és a kezelői állomások fizikailag közel vannak egymáshoz, a kommunikáció nagy sebességű és determinisztikus lehet.
7.3 Az elemek kommunikációja és a fejlesztő szoftverek
Ez az alfejezet MINDKÉT rendszertípusra vonatkozik: a SCADA és a DCS ugyanazokból az építőkockákból dolgozik, csak más léptékben.
Az elemek kommunikációja
A SCADA és a DCS elemei nem saját, új protokollt használnak: az EDDIG megismert ipari buszrendszerek (1-6. fejezet) egyikén vagy másikán, illetve ipari Ethernet-alapú hálózaton keresztül kommunikálnak egymással. A kutatási forrásaink az átviteli lehetőségeket ezen a fogalmi szinten adják meg — Ethernet, soros átvitel, illetve vezeték nélküli kapcsolat (nagy távolságnál mikrohullámú, cellás vagy műholdas) —, a konkrét protokoll mindig rendszerterv- és gyártófüggő.
Ami ebből biztosan kijelenthető:
| Kapcsolat | Jellemző átviteli mód | Korábbi fejezet, ahol tanultuk |
|---|---|---|
| SCADA: MTU ↔ távoli RTU | soros vagy Ethernet-alapú, nagy távolságnál vezeték nélküli | 1. (RS-485), 4. (Modbus) |
| DCS: vezérlők ↔ kezelői állomások | üzemen belüli, nagy sebességű, redundáns hálózat | 6. (ProfiNet mint ipari Ethernet) |
| Terepi eszköz ↔ vezérlő/RTU | terepi buszrendszer vagy analóg hurok | 3. (Foundation Fieldbus), 5. (HART), 6. (Profibus-PA) |
Egy SCADA- vagy DCS-rendszer nem különálló, új kommunikációs technológia — hanem az 1-6. fejezetben tanult buszrendszerek (pl. Modbus, Profibus/ProfiNet) egyikét vagy többet is FELHASZNÁLÓ, azok fölé épülő felügyeleti/vezérlési réteg. A gépszintű, gépen belüli buszok (pl. a 2. fejezet CAN-busza) jellemzően nem a SCADA vagy a DCS gerinchálózataként jelennek meg, hanem egy-egy berendezésen belül.
Hogy egy adott rendszerben az MTU pontosan milyen protokollon éri el az RTU-kat, azt a rendszerterv és a gyártói dokumentáció mondja meg — nem a fejezet, és nem is a „szokás”. A jegyzet itt szándékosan csak a TÍPUSOKAT sorolja fel; a konkrét választ mindig a dokumentációból olvasd ki.
Lekérdezés és eseményvezérelt adatgyűjtés
Az adat kétféleképpen juthat el a terepről a központba. Az egyik a lekérdezés (polling): a központ (MTU) ciklikusan, sorban megkérdezi az állomásokat (RTU), és azok válaszul elküldik az aktuális értékeiket. Ez egyszerű és kiszámítható, de sok olyan adatot is átvisz, amely a legutóbbi kérdés óta nem változott.
A másik az eseményvezérelt adatgyűjtés, más néven változás alapú jelentés (report by exception): az állomás csak a változásokat, az eseményeket jelenti. Jó példa erre a SCADA-központ és a távoli állomások között használt DNP3 protokoll (szabványként: IEEE 1815). Ezt a protokollt a jegyzet nem tanítja, itt csak az eseményjelentés példájaként szerepel. Kétféle eseményjelentést ismer:
- a központ rákérdezhet csak a legutóbbi lekérdezés óta keletkezett eseményekre, így csak a megváltozott értékek utaznak;
- az állomás kérés nélkül is elküldheti az eseményt (kéretlen válasz, unsolicited response), a központ lekérdezési ciklusától függetlenül.
A gyakorlatban a két módszert együtt használják: a központ időnként a teljes állapotot is lekérdezi (ellenőrzésként), közben pedig főként az eseményeket gyűjti. Így kevesebb adat megy át a vonalon, és a központ hamarabb értesül a változásokról. A kéretlen válasz különösen akkor hasznos, ha sok állomás van, és a központnak egy változásról a lehető leghamarabb tudnia kell.
Fejlesztő (mérnöki/konfigurációs) szoftverek
Az a szoftvereszköz, amellyel a rendszertervező vagy a karbantartó mérnök felépíti és karbantartja a SCADA- vagy DCS-rendszert: beállítja a kommunikációs kapcsolatokat, megtervezi a HMI-képernyőket, beállítja az alarmküszöböket, és — DCS esetén — megírja a vezérlési logikát is.
Néhány, az iparban elterjedt SCADA/DCS fejlesztőszoftver-példa (fogalmi tájékozódásra, NEM memorizálandó lista): SCADA-oldalon pl. Wonderware/AVEVA System Platform, Siemens WinCC, Rockwell FactoryTalk View, Inductive Automation Ignition; DCS-oldalon pl. Yokogawa CENTUM, Emerson DeltaV, Siemens PCS7. Ezek a szoftverek platformonként eltérő felülettel, de HASONLÓ alapfunkciókkal (kommunikáció-konfiguráció, HMI-tervezés, alarmkezelés, historian-integráció) dolgoznak.
A KKK szintjén a FOGALOM (mire való egy fejlesztő/konfigurációs szoftver, milyen feladatokat lát el) a fontos, nem az, hogy melyik gyártó melyik terméke hogy hívják. A fenti nevek csak azt szemléltetik, hogy ilyen szoftverek léteznek és elterjedtek.
7.4 HMI, központi adatgyűjtés, folyamatvizualizáció
A kezelő szemszögéből az egész SCADA- vagy DCS-rendszer EGY képernyő. Ezen a képernyőn három dolog találkozik: a folyamat pillanatnyi állapota (folyamatvizualizáció), a múltbeli adat (központi adatgyűjtés, trend) és a beavatkozási lehetőség.
A technológiai folyamat pillanatnyi állapotának grafikus megjelenítése a kezelő számára. Ez a HMI elsődleges feladata: a mért értékek, a berendezések állapota és a riasztások egyetlen, áttekinthető képen jelennek meg.
A SCADA/DCS azon komponense, amely a mért értékeket az idő függvényében eltárolja. Ebből készül a trendmegjelenítés: a kezelő nemcsak azt látja, MENNYI az érték most, hanem azt is, HOGYAN változott.
A központi adatgyűjtés tehát nem öncél. Az MTU (illetve DCS-nél a rendszer központi része) azért gyűjti be és tárolja az adatot, hogy a kezelő és a mérnök vissza tudjon nézni: mikor indult el a szivattyú, meddig ment a hőmérséklet, előjelezte-e valami a tegnapi leállást.
7.4.1 Egy tipikus HMI-képernyő elemei
A konkrét képernyő mindig a rendszerterv szerint készül. Az elemek TÍPUSA viszont visszatérő. Az alábbi példa egy szivattyúállomást felügyelő képernyő elemeit mutatja:
| Képernyőelem | Mit mutat vagy mit tesz | Az adat iránya |
|---|---|---|
| Mért érték (analóg kijelzés) | az RTU-tól érkező, digitalizált mérési adat | RTU → HMI |
| Berendezés-állapot (kétállapotú) | pl. szivattyú jár / áll | RTU → HMI |
| Trendgörbe | a historianból visszaolvasott időbeli lefutás | historian → HMI |
| Riasztásjelző és nyugtázó gomb | a küszöböt átlépő érték kijelzése, majd nyugtázása | mindkét irány |
| Kezelői beavatkozó elem | be/ki kapcsoló, indítás vagy leállítás parancsgomb | HMI → RTU |
| Alapérték (setpoint) mező | a felügyeleti hurok alapértékének módosítása | HMI → RTU |
| Üzemmód-választó | kézi / automatikus üzemmód váltása | HMI → RTU |
A fejlesztő szoftverek a megjelenített vagy vezérelt adatpontokat jellemzően adatpont-azonosítóval (tag) kezelik: minden kijelzőmező, kapcsoló és trendgörbe egy ilyen névhez kötődik. A névadás rendjét — hogy mit hívnak a képernyőn és a dokumentációban ugyanúgy — a rendszerterv rögzíti, nem a képernyő tervezője találja ki menet közben. Ha a név a terven és a HMI-n eltér, a hibakeresés órákkal hosszabb.
A lekérdezés, a megjelenítés és a historianba írás jellemzően 250 milliszekundumtól akár több másodpercig terjedő késleltetést ad hozzá (7.1). A kezelő tehát mindig egy kicsit a múltat látja. Felügyeleti döntéshez ez elég; gyors szabályozási beavatkozáshoz nem — azt a helyi PLC/RTU vagy DCS-vezérlő végzi, nem a képernyő előtt ülő ember.
7.4.2 Az adatgyűjtési (historian) ciklus lépéssora
1. Az érzékelő fizikai jelet ad a terepen. 2. Az RTU (SCADA) vagy a helyi vezérlő (DCS) digitalizálja a jelet. 3. A központ (MTU, ill. DCS) lekérdezi vagy eseményként megkapja az adatot (7.3). 4. A központi egység feldolgozza és eltárolja — ez kerül a historianba. 5. A HMI megjeleníti az aktuális értéket és a tárolt előzményt trendként. 6. A kezelő a látottak alapján avatkozik be: parancs → MTU → RTU → beavatkozó.
Vedd észre, hogy a lépéssor a 7.1 adatáramlási irányát bontja ki. A 4. lépés az, ami a puszta megjelenítést ADATGYŰJTÉSSÉ teszi: enélkül a kezelő csak a mostot látná.
7.4.3 Riasztás (alarm) beállítása és kezelése
A riasztás az a mechanizmus, amitől a rendszer nem csak megjelenít, hanem SZÓL is. Két része van: a mérnöki beállítás (egyszer, a fejlesztő szoftverben) és az üzemi kezelés (nap mint nap, a HMI-n).
BEÁLLÍTÁS – fejlesztő szoftverben, a rendszerterv alapján 1. Kiválasztod az adatpontot, amelyet figyeltetni akarsz. 2. Megadod a riasztási küszöböt (alarmküszöb) a rendszerterv szerint. 3. Beállítod, hogyan jelenjen meg a riasztás a HMI-képernyőn. 4. Beállítod, hogy a kezelő nyugtázni tudja a riasztást. KEZELÉS – üzem közben, a HMI-n 5. Az érték átlépi a küszöböt, a HMI riasztást jelez. 6. A kezelő nyugtázza a riasztást (ezzel elismeri, hogy látta). 7. A kezelő beavatkozik: alapérték-módosítás, üzemmódváltás, parancs.
Alarmküszöböt soha nem „érzésre” állítasz be. A számot a rendszerterv, a technológiai előírás vagy a gyártói dokumentáció adja (7.6). Egy rosszul megválasztott küszöbnek két kimenetele van, és mindkettő rossz: vagy elhallgatja a valódi hibát, vagy annyi téves riasztást ad, hogy a kezelő megszokásból nyugtázza az igazit is.
Rajzold fel egy kétszivattyús átemelő HMI-képernyőjének vázlatát. Tegyél rá legalább: egy mért értéket (pl. szintjelzés), a két szivattyú állapotjelzőjét, egy kezelői be/ki kapcsolót, egy üzemmód-választót és egy riasztásjelzőt nyugtázó gombbal. Dokumentáld táblázatban minden elemre: (a) az adatpont neve (tag), (b) az adat iránya (RTU → HMI vagy HMI → RTU), (c) kap-e riasztási küszöböt, (d) bekerül-e a historianba. A konkrét küszöbértékeket NE találd ki — írd oda, hogy „rendszertervből”.
7.5 A két kategória hasonlósága és különbsége
A DCS egyetlen üzemre koncentrál — minden eleme „sétatávolságra” van a központi vezérlőteremtől. A SCADA ezzel szemben FÖLDRAJZILAG SZÉTSZÓRT eszközökre való, amelyeknél a kommunikáció bérelt vonalakon, mikrohullámú, cellás vagy műholdas hálózaton keresztül zajlik — például olaj- és gázvezetékeknél, villamosenergia- átviteli hálózatoknál, vagy egy egész várost kiszolgáló vízhálózatoknál.
| Szempont | SCADA | DCS |
|---|---|---|
| Földrajzi kiterjedés | nagy terület, szétszórt eszközök | egyetlen üzem/telephely |
| Jellemző kommunikáció | WAN (bérelt vonal, mikrohullám, cellás, műhold) | üzemen belüli, nagy sebességű, redundáns hálózat |
| Fő feladat | felügyelet, adatgyűjtés, magas szintű parancsok | folyamatos technológiai folyamat vezérlése |
| Tipikus alkalmazás | csővezetékek, energiaátviteli hálózat, vízhálózat | vegyipari/olajfinomítói/erőművi üzem |
Mindkét rendszer figyeli a folyamatot, adatot jelenít meg a kezelőnek, és vezérlési logikát hajt végre — csak MÁS LÉPTÉKBEN és MÁS KAPCSOLATI KÖRNYEZETBEN. A gyakorlatban sok modern rendszer HIBRID módon, a két architektúra elemeit ötvözve épül fel.
7.6 Konfigurálás dokumentáció alapján
A HMI-képernyők felépítése, az alarmküszöbök, a kommunikációs paraméterek beállítása mindig a konkrét rendszertervhez és a használt szoftver/hardver platform (pl. a kezelőfelület-szoftver vagy a vezérlő gyártójának) dokumentációjához igazodik — ezek platformonként jelentősen eltérhetnek, ezért a KONKRÉT lépéseket mindig a rendelkezésre álló dokumentációból kell megismerni.
Nézz meg egy ipari folyamatábrát vagy esettanulmányt (pl. egy vízmű vagy egy vegyi üzem leírását), és döntsd el, SCADA vagy DCS jellegű-e a leírt rendszer. Indokold meg a döntésed a földrajzi kiterjedés és a kommunikációs infrastruktúra alapján. Azonosítsd a leírásban az MTU/RTU/HMI (SCADA esetén) vagy az elosztott vezérlők (DCS esetén) szerepét.
Egy rendelkezésre álló SCADA- vagy DCS-szoftverkörnyezetben (vagy szimulátorban) hozz létre egy egyszerű HMI-képernyőt, amely megjelenít legalább egy mért értéket és egy kezelői beavatkozási lehetőséget (pl. egy be/ki kapcsolót). Dokumentáld legalább: a protokollt, a címzést (eszközcím, adatpont-cím), a lekérdezési ütemet és az adatpont nevét (tag) — mindegyiket abból a dokumentációból, amelyet használtál. Jegyezd fel azt is, melyik beállítást hol találtad meg: a gyakorlat célja a dokumentációolvasás gyakorlása, nem a képernyő szépsége.
Összefoglalás
- A SCADA (Supervisory Control and Data Acquisition) földrajzilag elosztott eszközök felügyeleti megfigyelésére és irányítására szolgál, MTU-RTU-HMI architektúrával.
- A SCADA nem végez gyors, valós idejű szabályozást — a felügyeleti hurkot zárja, a gyors szabályozás a helyi PLC/RTU/DCS-vezérlő feladata.
- A DCS (Distributed Control System) egyetlen üzemen belüli, folyamatos technológiai folyamat vezérlésére szolgál, elosztott vezérlőkkel, nagy sebességű, redundáns belső hálózaton.
- Egyik architektúra sem hoz saját protokollt: a korábbi fejezetek buszrendszereire, ipari Ethernetre, illetve SCADA-célú protokollokra (pl. DNP3) épülnek, a konkrét választást a rendszerterv dönti el.
- Az adatgyűjtés lehet lekérdezéses (a központ ciklikusan kérdez) vagy eseményvezérelt (az állomás csak a változást jelenti); a gyakorlatban a kettőt együtt használják, pl. a DNP3 protokoll mindkettőt támogatja.
- A fejlesztő (mérnöki/konfigurációs) szoftver az az eszköz, amellyel a kommunikációt, a HMI-képernyőket, az alarmküszöböket és — DCS-nél — a vezérlési logikát beállítjuk.
- A HMI három dolgot ad egyszerre: folyamatvizualizációt, a historianból visszanézhető trendet és a kezelői beavatkozás lehetőségét.
- A riasztásnak két fele van: a küszöb mérnöki beállítása a fejlesztő szoftverben, és a nyugtázás-beavatkozás az üzemeltetés során a HMI-n.
- A két architektúra legfontosabb megkülönböztető jegye a földrajzi kiterjedés: a DCS egy telephelyre, a SCADA nagy távolságra szétszórt eszközökre való — a konkrét konfigurálás mindkettőnél a rendszerterv és a gyártói dokumentáció alapján történik.
Ellenőrző kérdések
- Mit jelent a SCADA betűszó, és mi a fő feladata?
- Sorold fel a SCADA architektúra három fő eszközét, és mondd el, mi a szerepe az őket összekötő kommunikációs hálózatnak.
- Miért nem szabad gyors, valós idejű szabályozást a SCADA-szerverbe helyezni?
- Mit jelent a DCS betűszó, és mi a fő feladata?
- Mi a legfontosabb megkülönböztető jegy a SCADA és a DCS között?
- Sorolj fel legalább négy elemtípust, amely egy tipikus HMI-képernyőn megjelenik, és mondd meg mindegyikről, melyik irányba mozog rajta az adat.
- Mi a historian feladata, és mi lenne a következménye, ha nem lenne a rendszerben?
- Írd le a riasztás beállításának és kezelésének két szakaszát: mi történik a fejlesztő szoftverben, és mi történik üzem közben a HMI-n?
Tudáspróba
1. Egy vízellátó vállalat egy egész várost lefedő, sok kilométerre szétszórt szivattyúállomását felügyeli központilag. Melyik architektúra illik erre? a) SCADA b) DCS c) Mindkettő egyformán d) Egyik sem
2. Melyik SCADA-elem gyűjti össze a távoli egységek adatát, és küld nekik parancsokat? a) RTU b) MTU c) PLC d) HMI
3. Egy vegyi üzem teljes technológiai folyamatát egyetlen telephelyen, nagy sebességű belső hálózaton vezérlik, elosztott vezérlőkkel. Melyik architektúráról van szó, és miért?
4. Igaz vagy hamis: a SCADA-rendszer feladata a gyors, milliszekundumos ciklusidejű PID-szabályozás elvégzése.
5. Mi a fő oka annak, hogy a SCADA-rendszereknél jelentős (akár másodperces) késleltetéssel kell számolni?
6. Melyik elem digitalizálja a terepi érzékelők jelét egy SCADA-rendszerben? a) HMI b) historian c) RTU d) MTU
7. Nevezd meg, mi a szerepe a HMI-nek egy SCADA- vagy DCS-rendszerben.
8. Honnan veszed egy riasztási küszöb (alarmküszöb) konkrét értékét, és miért nem szabad becsülni?