Komplex, nagyméretű projektek I&C-tervezési szempontjai – 8.

Egy folyamatállomás felhasználói programstruktúrájának kialakítása

Ebben a részben foglalkozunk az irányítástechnikai rendszer struktúrakialakításának szempontjaival, a felhasználói szoftverrendszer kialakításának kérdéseivel és ezeket egy erőművi vízlágyítórendszer konkrét részfolyamatán a megvalósítási szintig szemléltetjük. 

Bevezetés

A folyamatállomások és a technológiai részrendszerek összerendelése az áttekintő konfiguráció kialakításakor történik meg. Itt az a legfontosabb, hogy a folyamatállomások elosztása feleljen meg a technológia funkcionális struktúrájának, azaz a folyamatállomások a technológia funkcionális részfolyamataihoz legyenek rendelve. A technológiai részfolyamatokhoz igazodó folyamatállomás-struktúra egyúttal lehetővé teszi a hatékony információfeldolgozást is, mert minimalizálja az oldalirányú (más részfolyamatok felé menő) kommunikációt. Itt a folyamatállomáson belüli programstruktúra kialakítását tárgyaljuk. Ehhez a funkciók párhuzamos, illetve soros futásának vizsgálata szükséges.

A párhuzamos és soros futás problémaköre

Egy technológia irányítástechnikájában az irányítási funkciók időben párhuzamos futása a természetes. A régi, műveleti-erősítős, analógkártyás rendszerekben – a több ezer műveleti-erősítő mai szemmel nézve primitív processzálásával – ez teljesült.

A szigorúan vett vezérléstechnikai, szabályozástechnikai processzálást a mai folyamatállomásokban a CPU-k végzik. Itt ma óhatatlanul előjön, hogy az adott folyamatállomás adott CPU-jára jutó feladatokat futás szempontjából sorba kell rakni. (Volt már egy igen erősen decentralizált – csak dedikált processzoros I/O-kártyákat (FUM) használó – rendszer is, amelyben a feladatok párhuzamos futása lényegében megvalósult, de árproblémák miatt ez egyelőre háttérbe szorult. Ez volt a Siemens TELEPERM MEA-rendszere).

A mai folyamatirányító rendszerekben – annak ellenére, hogy egy folyamatállomásban több processzor is dolgozik rendszerszintű feladatok ellátásán – a felhasználó által írt felhasználói programokat általában egy CPU dolgozza fel. Emiatt jelenleg lényegében

• a folyamatállomások egymással párhuzamosan működnek, azaz programjaik egyidejűleg futnak,

• de egy folyamatállomáson belül az egyes felhasználói taszkok

– azonos prioritás esetén egymás után,

– eltérő prioritások esetén egymást megszakítva (a magasabb prioritású taszk futása megszakítja az alacsonyabb prioritású taszk futását),

– a taszkokban levő funkciók pedig egymás után, a leírás sorrendjében futnak.

Folyamatállomáson belül taszkok definiálása

Itt kell megtörténnie a taszk–részrendszer-funkciók (logikai tervek) összerendelésének. Ezután az adott technológiai részrendszer funkcióinak megfelelően létre kell hozni az adott folyamatállomás taszkjait, és hozzájuk kell rendelni a funkciókat. A funkciók (logikai tervek) szétosztása a folyamatállomás taszkjai között alapvetően az alábbiak szerint célszerű: 

• Az egyes taszkokhoz komplex technológiai funkciókat realizáló logikai tervcsomagokat kell rendelni úgy, hogy a taszk–taszk-kommunikációk jól meghatározottak és minimalizáltak legyenek.

• Az idő szerint ciklikus indítású taszkok közül

–     a laza ciklusú taszk(ok) általános méréseket, fölérendelt vezérléseket, részvezérléseket, egyedi vezérléseket,

–     a merev ciklusú taszk(ok) fölérendelt szabályozásokat, egyedi szabályozásokat (méréseikkel és vezérléscsatlakozásaikkal együtt), valamint kiegészítésképpen üzemóra-számlálást, napi összegzést, integrálást stb. végeznek.

• Az eseményindítású taszkok feladatai közé a különleges eseményekkel kapcsolatos feldolgozás – pl. éjféli napló napi összegekkel, összegzők nullázásával –, az indulás és a leállás tartozik.

A definiált taszkok futásával kapcsolatban az alábbi megfontolásokat célszerű megtenni. Ha elérhető az, hogy több – közel azonos méretű (futási időigényű) – taszkból álljon a felhasználói programrendszer; és az összes taszk futási idejének összege kisebb, mint a gyors taszk ciklusideje – azaz, a gyors ciklusú taszk után jövő taszkok is le tudjanak futni a gyors ciklusok között elosztva –, akkor megvalósítható a teljes kisorosítás (1. ábra), és a taszkok azonos prioritásúnak definiálhatók. Nem lesz felhasználói taszkmegszakítás. Minden taszk lefutása után taszk futáskiértékelés (diszpécserezés) történik, és a következő várakozó taszk fut.

1. ábra. Teljes kisorosítású futás gyors, közepes és lassú ciklussal

Vannak tervezőrendszerek (pl. Teleperm XP, PCS7), amelyekben lehetőség van a processzorterhelés egyenletessé tételére. Egy ilyen módszer a taszkon belüli futási egységek (runtime group, paket) cikluson belüli eltolása.

A taszk fut egy alapciklusban, pl. 0,1 s ciklusidőben. Ha ebbe a taszkba beteszünk 4 db futási egységet, amelyeknek 0,4 s-enként kell futni, akkor rendre megadhatjuk a 4 db futási egységhez a 0, 1, 2, 3 eltolásértéket. Ez azt jelenti, hogy pl. a 10. másodpercben csak az 1. paket fut a taszkon belül, a 2. paket 10,1 másodperckor, a 3. paket 10,2 másodperckor, a 4. paket pedig 10,3 másodperckor kerül sorra. A 10,4 s-ben kezdődik újra a futás az 1. csomaggal (pakettal). Ezzel a megoldással mindegyik csomag 0,4 másodpercenként kerül sorra. A CPU-terhelés helyesen megválasztott eltolásokkal kiegyenlíthető.

Ha néhány taszk hosszú futási ideje nem kerülhető el, akkor azokat alacsony prioritásúra kell definiálni, és ezeket megszakítják a magas prioritású taszkok. Ebben az esetben viszont különösen fontos, hogy az alacsony és magas prioritású taszknak nem szabad azonos változókat írni (a feladatoknak a technológiában szigorúan szétválasztottnak kell lenniük). A taszkok közötti kommunikáció megvalósítása függ attól, hogy IL-utasításlistás vagy blokkos nyelvet használunk. Az IL- (illetve ST) -nyelvekben a program elágazási lehetőségei miatt jobban lehet kezelni a taszk–taszk-kommunikációt. Itt a blokkos megvalósítást tételezzük fel.

Taszkon belüli kisorosítás

Egy taszkon belül a blokkhívások, programutasítások végrehajtási sorrendje a leírási sorrenddel (IL) vagy a futási sorrend megadásával egyértelműen rögzítve van. Ily módon a funkcióhoz tartozó blokkhívások sorozata mutatja az illető funkció időbeli működését, és ez a működés megértéséhez alapvető fontosságú.

Még egy esetleges, magasabb prioritású taszk által történt megszakítás esetén is ott folytatódik a megszakított taszk futása – amikor újra szóhoz jut –, ahol futása megszakadt, tehát a blokkok futási sorrendje nem változik. A globális változók több taszk által történő írását a funkciókiosztással lehetőleg kerülni kell. (Ha erre mégis szükség van, akkor gondosan ellenőrizni kell az ebből adódó problémákat!)

A kisorosítás esetében a problémák a futási sorrend helytelen megadásából adódhatnak. Ez a hardvertervezésnél megismert hazárdhoz hasonló jelenségeket okozhat. A taszkon belüli funkciók helyes kisorosítása érdekében az alábbi elveket célszerű betartani:

• A legfontosabb alapelv a futási sorrend tervezésekor, hogy bármelyik blokk hívásakor az adott blokk minden bemenete az adott futási ciklus frissített értékével álljon rendelkezésre. Ha ez egy blokkhívásra nem teljesül, akkor meg kell vizsgálni, hogy az illető jel egy ciklussal való késése okoz-e az illető blokknál problémát. Mint említettük, a taszk olyan futási egység, amelynek moduljai garantáltan a dokumentált sorrendben futnak le (a környezettől függően esetleg eltérő ágak futnak). A futási sorrend egyes rendszereknél megegyezik a beírási sorrenddel (S7 300), másoknál be kell írni a blokkhoz a futási sorszámot (Freelance, Teleperm MEA, DELTA V), de van automatikus futási sorrendező is (Teleperm XP).

• Egy mérés–vezérlés-taszk funkcióterveinek leírási sorrendjében (futási sorrend) gondoskodni kell arról, hogy a fölülről kiadott parancsokat (a feldolgozás után) a középső vezérlési szint adja tovább az egyedi vezérlési szintnek. A folyamatot az alábbi lépések szerint lehet elképzelni:

– Mérések (nem szabályozott jellemzők), kiértékelések

– Fölérendelt vezérlés (parancsot ad ki a lefutóvezérlés 1, 2, 3-nak)

– Lefutóvezérlés 1

– Lefutóvezérlés 2

– Lefutóvezérlés 3 (parancsot ad ki a részvezérlés 1, 2, 3-nak)

– Részvezérlés 1

– Részvezérlés 2

– Részvezérlés 3 (parancsot ad ki a hajtás 1, 2, 3, 4-nek)

– Hajtás 1

– Hajtás 2

˜– Hajtás 3

– Hajtás 4 ...

Ez a sorrend általában megfelelő ahhoz, hogy a fölérendelt vezérlőjelek az adott ciklusban az alsóbbak bemenetén rendelkezésre álljanak.

• A szabályozáshoz, integráláshoz, összegzéshez merev ciklusú taszk szükséges. A szabályozótaszkoknál egy célszerű sorrend választandó:

– Szabályozott jellemzők beolvasása a folyamatképből,

– Fölérendelt szabályzólogika (itt állítandók elő a statikus jelekből az impulzus vezérlőjelek),

– Fölérendelt szabályzók hívása, csatlakozások előállítása,

– Alárendelt szabályzólogikák (itt állítandók elő a statikus jelekből az impulzus vezérlőjelek),

– Alárendelt szabályzók hívása,

– Szelepvezérlő jelek, végrehajtó jelek konvertálása, kiadása,

• A run time-rendszer koherens adatbázis szolgáltatását – ha van ilyen – használni kell. A Freelance-ben a taszkokhoz pl. ún. folyamatkép- (Processimage, PI) -változókat kell definiálni. Ebben az esetben a taszk a futása előtt – a taszk által használt folyamatképként kijelölt – változókat a globális adatbázisból (koherens szegmensként) kimenti egy mentési területre (PI) és ebből dolgozik. Ezekbe ír, majd lefutása után a kimeneteket innen írja vissza a globális adatbázisba. Fontos kérdés, hogy taszkmegszakítás esetén hol tud megszakadni egy taszk futása:

– bármelyik PLC-utasítás végén (ez kockázatos, mert befejezetlen a funkció),

– csak a blokk végén (ez sokkal biztosabb, a funkció végrehajtása befejeződött).

A 2. ábra a Freelance-rendszer esetében a folyamatállomások párhuzamos és taszkjaik kisorosított működését szemlélteti (füstgáz–levegő-rendszer mérése, vezérléstaszk, szabályozási taszk, gőz–vízrendszer mérés–vezérlés-taszkja, szabályozási taszk a kazán folyamatállomáson; a turbina folyamatállomáson hasonló felosztás van).

2. ábra Folyamatállomások párhuzamos és azokon belüli taszkok soros működése

• A kommunikáció a terepi készülékekkel és operátorállomásokkal, folyamatállomásokkal (terepibusz-driverek, I/O-rack és intelligens perifériakezelés, Ethernet-busz kommunikáció) rendszerszinten történik. Ez a rész frissíti a terepi készülékek jeleivel, illetve az operátorállomások parancsaival, paramétereivel a globális adatbázishardver bemeneteit és a szoftverváltozókat. Rendszerprogramok viszik ki a terepi készülékekre a vezérlőjeleket, illetve a képernyőkre a technológia állapotjeleit.

• A felhasználói taszkok (mérés–vezérlés-taszkok, szabályozástaszkok stb.) érvényre jutási sorrendben (időzítés, prioritás, leírási sorrend) futnak. Először beolvassák a globális adatbázis (szoftverváltozók és hardver bemenőjelek) jeleit a PI-mentési területre. Ebből dolgozva lefutnak a taszkon belüli egységek a funkcióblokk hívásokkal, az eredményeket a PI-területre írják, ahonnan a taszk befejezése után a kimenetek átmásolódnak a globális adatbázisba. Ily módon az adatbázisban egyidejű adatokkal áll rendelkezésre a teljes technológiai folyamatkép.

A taszkok közötti kommunikáció elvei

Az alábbi elveket célszerű alkalmazni:

• A taszkokhoz való feladat-hozzárendelésnél ügyelni kell arra, hogy a taszkok közötti kommunikáció minimális legyen,

• A taszkok közötti kommunikáció lehetőleg statikus jeleket használjon,

• Minden 1-0, illetve 0-1 vezérlőjel-változást (impulzust) az őt használó taszkon belül kell előállítani. Az impulzushossz paraméterezésénél lehetőleg ne használjunk egy ciklusidejű impulzust, hanem több ciklus hosszúságút, mert az egy ciklusidejű impulzus könnyebben elveszhet. Taszkok között lehetőleg ne legyen impulzus formájú információátadás.

• Az analóg jel differenciálhányadosát az őt használó taszkon belül célszerű előállítani. Taszkok között lehetőleg ne legyen differenciálhányados átadás.

• Ha mégis impulzuskommunikációt kell használni az operátor- és a folyamatállomás közötti vagy több folyamatállomás közötti kommunikációban – ahol a parancsok véletlenszerűen mennek a folyamatállomásokhoz és nem szabad elveszniük –, akkor az igazán korrekt (jelvesztés mentes) megoldás a szoftver handshake (a task1 a parancsot, a task2 a visszaigazolást írja az 1. táblázat szerint).

1. táblázat Szoftver handshake illusztrálása

A folyamatállomások közötti vezérlőjelek átadásánál is ezt célszerű használni, mert a folyamatállomások exportált változóit sokszor csak a forrásállomás tudja írni, a célállomások pedig csak olvasni tudják.

• Ha lerögzíthető, hogy az 1. taszk mindig csak „1”-be írja, a 2. taszk pedig mindig csak „0”-ba írja (törli) az 1.taszkban definiált bitet, akkor a helyzet gyakorlatilag kezelhető. Ez az eset áll elő, amikor egy megjelenítőkezelő írja a parancsokat, a folyamatállomási szoftver pedig olvassa őket (ha parancs jött, végrehajtja a megfelelő feladatot, majd törli a parancsot).

• A task1 pl. 2 s hosszúságú impulzusok formájában adja a parancsokat, a task2 remélhetőleg elkapja ezeket. Ha nem, az operátor újra megnyomja a „be” gombot. A Simens WinCC-nél szokásos megoldás, hogy a képernyőről kiadott parancsbitet csak a WinCC írja (1-be vagy 0-ba), a PLC vagy szerver csak olvassa.

Blokk-készlet ellenőrzése

A felhasználói program tervezéséhez alapvető a blokk-készlet ellenőrzése, amelyből az irányítástechnika felépíthető. Az adott rendszer funkcióinak vizsgálatából kiadódnak a felhasználandó gyári blokkok, és kiadódik az esetleges alkalmazásspecifikus felhasználói blokkok listája. Ezeket specifikálni kell, el kell készíteni, majd le kell tesztelni. A logikai terveket adaptálni kell az adott folyamatirányító rendszerblokk készletéhez.

A felhasználói szoftver készítésekor fellépő hibalehetőségek, hazárdvizsgálat

Ha egy irányítástechnikai feladatot programozható folyamatirányító rendszer alkalmazásával oldunk meg, az alkalmazói szoftver lehetséges hibaforrásainak jelentős része jól ismert a korábbi megoldási formákból (relés, félvezetős kombinációs, szekvenciális vezérlések szokásos tervezési hibái, hazárdveszélyt magukban rejtő megoldások). Megjelennek viszont újszerű, a folyamatirányító rendszerek multitaszkos kisorosítás specialitásából, inkoherens adatokat eredményező kommunikációjából adódó hibalehetőségek. Fontos megjegyezni, hogy a „hagyományos” vezérléstechnikai problémák megoldáshoz a DCS-folyamatirányító rendszerek sokkal jobb, egyszerűbb és rugalmasabb megoldásokat kínálnak, mivel itt pótlólag beépítendő, huzalozandó kártyák helyett standard szoftvermodulokat kell betenni a programba. 

Folytatjuk!

Szerző: Dr. Nagy Dezső

Ez az e-mail-cím a szpemrobotok elleni védelem alatt áll. Megtekintéséhez engedélyeznie kell a JavaScript használatát.