Skip to main content

Új megoldások az ipari folyamatok vezérlésében és vizualizálásában

Megjelent: 2013. január 17.

Zidarics Zoltán – PTE PMMIK Automatizálási Tanszék

Az „okos” személyi informatikai eszközök (laptopok, tabletek, okostelefonok) egyre nagyobb szerepet követelnek magukban a mobil távfelügyelet megvalósításában. Az eszközök sokfélesége különösen a vizuálizáció egységes megjelenését akadályozza. A szerző olyan módszert javasol, amely meglevő, nyílt forráskódú szoftvereszközökkel akár beágyazott hardveren is képes egységes megjelenést generálni.

A feladat

Az újabb és egyre olcsóbb hordozható számítógépek megjelenése kikényszeríti az ipari folyamatirányító rendszerek újragondolását is. Ezek az okostelefonok és tabletek egy asztali PC számítási képességeivel
rendelkeznek, képernyőjük felbontása megközelíti, sőt némelyiké meg is haladja az előbbiekét. Általában azonban teljesen más operációs rendszereket használnak, amelyek sajátosságaikból következően más szemléletűek (nincsenek hagyományos ablakok stb.). A felhasználók – főként egy cég magas, ill. közepes beosztású alkalmazottjai – igénylik a folyamatos és távoli monitorozás lehetőségét. Ezeket az igényeket a  hagyományos vizualizáló szoftverekkel több okból sem lehetséges kiszolgálni. Ezek közül a legfontosabbak:

  • Egy meghatározott operációs rendszer alá készültek. Az összes többi kliensen is ez szükséges a futtatáshoz.

  • Egy meghatározott képernyőméretre fejlesztették őket. A megjelenített grafikai elemek bitképek, amelyek nem alkalmasak az online méretezésre.

  • Nehezen skálázhatók. Ha több helyről szükséges használni, akkor az újonnan beállított munkaállomások is adatot gyűjtenek az ipari hálózatból, növelve annak forgalmát. Ez pl. egy RS485-alapú hálózaton adattorlódáshoz vezet, de TCP/IP-alapú hálózaton is többleterőforrást igényel az ipari hálózat elemeitől. Ha csak egy szervereszközt állítanak be az adatgyűjtésre, és a kliensek csak ettől kérik le az adatokat, akkor a kliensek számának növelése a szerveren drasztikus erőforrás-növekedési igénnyel lép fel, mivel a megjelenített képtartalmat a szervernek kell előállítani.

  • Biztonsági kockázatot jelentenek a céges intraneten kívülről érkező kliensek.

A fentiek alapján szükségesnek látszik egy teljesen új rendszer megtervezése.

zidarics_2013_1-2_1

1. ábra Néhány képernyőkép a mintaalkalmazásból

 

Egy lehetséges megoldás ismertetése

Az új rendszerrel szemben támasztott követelmények
Érdemes alaposan megtervezni a rendszert, nehogy idő előtt elavulttá váljon. A legfontosabb követelmények az alábbiak:

  • Kliens-szerver architektúra.

  • Kliensoldali „vékonyréteg” technológia.

  • A szerveroldal lehetőleg mikrokontroller alapú legyen.

  • Több kliens tudja egyszerre használni. A gyakorlatban egy cég életében a tízes nagyságrend már elfogadható, de lehetőség szerint ne legyen explicit korlátozás.

  • Platformfüggetlen legyen. A leggyakrabban használt operációs rendszereken újrafordítás nélkül lehessen futtatni.

  • Ne legyen megkötés a képernyő méretére vonatkozóan.

  • Biztonság. A Stuxnet/Duqu vírus óta az ipari hálózatok védelme kiemelt fontosságú.

  • Az egyes megvalósítások egyszerűen adaptálódjanak a technológiához.

  • A felhasznált szoftverek nyíltforrásúak legyenek.

Szerver
A fenti követelményeknek a Spring framework maradéktalanul megfelel, mivel nyílt forráskódú és Java alapú, ezért platformfüggetlen lehet. A többi J2EE-megvalósításhoz képest kisebb erőforrás igényű, ezért egy beágyazott Linuxot használó mikrokontrolleren is képes működni. Moduláris felépítése miatt elég csak a szükséges modulokat betölteni. A teljes alkalmazás – a kliensoldali szoftverrel, képekkel és egyéb alkotóelemekkel – nagyjából 32 MB méretű war fájlban telepíthető. Ezzel a módszerrel a rendszert akár egy PLCmodulként is meg lehet valósítani, nincs szükség drága hardverek beállítására.
Szerveroldalon az autentikáció és az autorizáció kiemelt fontosságú. Ebben a Spring nagyon rugalmas, szinte minden ipari szabványnak megfelelő forrásból tud autentikálni. A keretrendszert intenzíven fejlesztik, ezért az esetleges hibák gyorsan napvilágra kerülnek, és rövid idő alatt megjelennek a szükséges javítások.
A szerver adatgyűjtőként és vezérlőként kommunikál az ipari folyamat hálózatával. Képes egy tetszőleges SQL vagy NoSQl adatbázisba naplózni az ipari folyamat fontos eseményeit, ezenkívül riasztási szolgáltatást is végez sms, ill. email-formában. Ha beágyazott rendszeren szeretnénk használni, akkor az adatbázist természetesen célszerű egy másik, nagyobb teljesítményű hardverre telepíteni.
A technológia leírására egy XML-fájl szolgál, ebben definiáljuk az egyes eszközök típusát és elérhetőségét az ipari folyamat hálózatában. Ezenkívül csak a technológia rajzát kell elkészíteni. A feladatanak ezt a  szegmensét a továbbiakban részletesebben tárgyaljuk. Ezzel a módszerrel rugalmasan lehet a rendszert a technológiához adaptálni, de megmarad az ellenőrizhetőség.


Kliens
A definiált követelményeknek kliensoldalon a Google GWT (Google Widget Toolkit) maradéktalanul megfelel. A keretrendszert a Google fejleszti – ez önmagában garantálja a megfelelő karbantartást és támogatást –, míg a 2.5 verziótól kezdődően a fejlesztés irányát a felhasználói közösség véleménye és javaslatai alapján alakítják ki. Ismert, hogy a GWT fejlesztését komoly mértékben befolyásolják a biztonsági megfontolások, tehát használatával a legmodernebb biztonsági hátteret tudjuk megvalósítani.
A kliensoldalon történik a technológia, ill. a vezérlési funkciók felhasználói felületének megjelenítése. Miután a kliensoldalon heterogén operációs rendszerek lehetnek, ide érzékeny adatok nem kerülnek, és nincs adatrögzítés sem. Ezzel a módszerrel nagymértékben növelhetjük a biztonságot.
Fokozott biztonság esetén egyszerű szerveroldali módszerekkel meg lehet akadályozni a felhasználói azonosítók mentését a kliensoldalon, mely után egy okostelefon, táblagép vagy laptop elvesztése esetén sem kell félni az esetleges idegen behatolástól.
A GWT használatával még egy igen komoly előnyhöz jutunk: a megjelenítés erőforrásigénye a kliensoldalon jelentkezik. Ez azt jelenti, hogy a kliensek számának növekedése esetén nincs szükség szerveroldali bővítésre, mivel a szerver és kliens között csak a nyers adatok cserélődnek, tehát egy új kliens nem terheli jelentősen a szervert.


Vizualizáció
A megjelenített ábráknak elegendően informatívnak – és természetesen tetszetősnek is – kell lenniük. Az előfeltételek megkövetelik, hogy vizualizált kép az adott kliensen online méretezze magát a rendelkezésre álló képernyőhöz. Ez kizárja a bitmap-ek használatát. Szerencsére létezik az SVG (Scalable Vector Graphic), ami egy szabványos, vektorgrafikus formátum. Az SVG egy XML-formátumú fájl, amit a legtöbb böngésző natív módon támogat.
A szabványt a W3C[1]. először 2001-ben adta ki 1.0 verziószámmal, majd 2003-ban jelent meg a mai napig érvényes 1.1 verzió. A szabvány minőségét jelzi, hogy egészen kifinomult tranzakciókra is kiterjed, például az animációt is támogatja. A fejlesztésének kezdete óta eltelt idő alatt jól kiforrott formátummá vált, amihez mind a megjelenítő, mind a rajzoló oldalon is kiváló szoftverek találhatóak.
Kis munkával a GWT alatt lehetőség van SVG-formátumú képek használatára. A klienshardver fizikai képernyőméretéhez való automatikus átméretezés nem tökéletesen valósul meg, de a fejlesztés során ezt a problémát is – nem túl nagy munkával – sikerült megoldani.
Sajnálatos módon az egyes böngészők nem teljesen adaptálják az SVG-szabványt. Képességeiket az 1. táblázatban foglaltam össze.
A táblázatból látszik, hogy a piacon található klienseszközök döntő többségét 100%-ban ki tudjuk szolgálni. Sajnálatos viszont, hogy az Apple OSX és IOS az animációt nem támogatja. Ez a hátrány Windows-környezetben viszont kiküszöbölhető, mivel az Internet Explorer mellett mindhárom „jelentős” böngésző rendelkezésre áll, emiatt az IE gyenge minősége nem okoz gondot.
A rajzokat a nyílt forrású, multiplatformos Inkscape segítségével készítettem, amely kellő hatékonysággal támogatja a megjelenítendő képeken előforduló tipikus alakzatok rajzolását. Ezért ez a munka nem igényelt jelentős időt és erőfeszítést. Minden modul külön SVG-fájlban helyezkedik el, tehát egy esetleges módosítás könnyedén elvégezhető. Az elkészült rajzokon le kell futtatni egy scriptet, ami a kívánt formátumra hozza őket, és elvégzi az alapvető ellenőrzéseket. Ugyanez a script be is másolja a formázott SVG-fájlokat a programhierarchia megfelelő könyvtárába, ezáltal ezek automatikusan kerülnek be a telepítőkészletbe.
Az SVG azt is megengedi, hogy egy tetszőleges képi elem eseményt generáljon. A kliensszoftverben ezt kihasználva bonyolult mechanizmusokat (a passzív megjelenítésen kívül beavatkozásokat) is egyszerűen lehet megvalósítani.

zidarics_2013_1-2_2

1. táblázat Néhány ismert böngésző SVG-kompatibilitása

 

Teszt
A koncepció tesztelésére egy mintaalkalmazást készítettem (1. ábra), amelyet a lehetséges legmostohább körülmények között teszteltem. Az elvárások között az is szerepelt, hogy beágyazott rendszeren működőképes legyen. Erre a célra egy BeagleBoard XM rev-C típusú, beágyazott Linuxot futtató hardvert használtam.
Ennek fő paraméterei:

  • Texas Instruments Cortex-A8 1 GHz processzor,

  • 512 MB RAM,

  • 4 GB class 4(!) SD-kártya,

  • Linux 3.2.13-x7 kernel,

  • Debian Wheezy operációs rendszer,

  • Java OpenJDK 7 Java-futtató környezet,

  • Jetty 8 webserver,

  • PostgreSQL 9 adatbázisszerver egy másik gépen.

A fenti konfiguráció manapság igen szerény teljesítményűnek számít. Ha ezen hosszú távon a rendszer hibátlanul és elfogadható sebességgel működni tud, akkor életképesnek minősíthetjük. A teszteszköz már 2012. október 28.-a óta megszakítás nélkül működik, és legalább egy kliens állandóan használja. A szerver az alábbi címen érhető el:

http://zamek.pmmf.hu:8080/gwt/Argus.html

 

Árak és licencdíjak
Amint a 2. táblázatból látszik, csak hardverköltséggel kell számolnunk, ami igen szerénynek mondható.

zidarics_2013_1-2_3

2. táblázat A rendszer megvalósításának költségbecslése

 


Milyen ipari szereplők érdeklődésére tarthat számot a rendszer?

PLC-gyártók
A szerény és igénytelen hardver miatt lehetővé válik, hogy PLC modulként gyártsák a rendszert, amely révén magas minőségű, korszerű és olcsó vizualizációt tudnak vevőik rendelkezésére bocsátani..

Vizualizációsszoft ver-gyártók
A szoftver a felhasznált moduloknak köszönhetően rugalmasan konfigurálható, a szoftvergyártás automatizálható, ezért az egyes megvalósítások költsége minimális. A szoftverkomponensek licencdíja költséghatékony, modern szoftvert eredményez.

Autóipar
A fedélzeti számítógéprendszerek már most megkövetelik, hogy okostelefonnal, táblagéppel vagy hagyományos személyi számítógéppel lehessen kezelni, és/vagy diagnosztizálni az autó egyes alrendszereit.  Figyelemreméltó, hogy ennél az alkalmazásnál is ugyanaz a probléma merül fel, mint a PLC-iparban: a kliensek számának növelésével nem célszerű a fedélzeti számítógép erőforrásait növelni. Ha a megjelenítés  erőforrásigényét a kliensekre hárítjuk, akkor egy szerényebb teljesítményű fedélzeti számítógép is elegendő lehet kiszolgálásukra. Ez a nagy szériaszámból adódóan a járműgyártóknak életbevágóan fontos szempont lehet.

Épületautomatizálási rendszergyártók
Az intelligens épületvezérlési rendszerek (EIB/KNX[2]. ) gyártói ugyanazokkal a kihívásokkal szembesülnek, mint a fentiek, azzal a kiegészítéssel, hogy egy nagyobb irodaépület esetén akár nagyságrenddel is több kliens telepítésére is szükség lehet.

Következtetés

A fentiek alapján megállapíthatjuk, hogy a kitűzött célokat majdnem 100%-ban sikerült teljesíteni. A fennmaradó kis eltérés az egyes operációs rendszerek, ill. böngészők hiányos SVG-kompatibilitásából adódik. Feltételezhető, hogy – az SVG-alkalmazásoknak a jelen alkalmazástól függetlenül is növekvő jelentősége miatt – a böngészők fejlesztői számára lényeges szempont lesz az SVG-megfelelőség maradéktalan biztosítása.
A kísérlet bebizonyította, hogy egy beágyazott rendszeren is lehetséges költséghatékonyan a kitűzött feladatot megvalósítani.

 



[1]

1 W3C: World Wide Web Consortium, a webszabványok fejlesztéséért felelős nemzetközi közösség a tagszervezetek, egy főállású munkacsoport és önkéntes együttműködők részvételével. – A szerk. megj.

[2]

2 Az épületautomatizálási és -felügyeleti rendszerek rendszerszerű megközelítéséhez szükséges, és arra optimalizált, egységes hálózati kommunikációs protokoll. EIB: European Installation Bus, Instabus. KNX: az EIB platformfüggetlen, nyílt forráskódú kiterjesztése. A szabvány bevezetését és karbantartását a KNX Association végzi, amelynek 2012 elején 33 országban kb. 300 tagvállalata volt. – A szerk. megj.

 


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