Új megoldások az ipari folyamatok vezérlésében és vizualizálásában
Zidarics Zoltán PTE PMMIK Automatizálási Tanszék 2012.
[email protected] [email protected]
1
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 okos-telefonok és tablet-ek egy asztali PC számítási képességeivel rendelkeznek, a képernyő felbontásuk megközelíti, sőt némelyik meg is haladja azokat, viszont teljesen más operációs rendszereket használnak, és a 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özépbeosztású alkalmazottjai – igénylik a folyamatos és távoli monitorozás lehetőségét. A hagyományos vizualizáló szoftverek több okból sem alkalmasak ezeket az igényeket kiszolgálni: •
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óak. 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öbblet erőforrást igényel az ipari hálózat elemeitől. Ha csak egy szerver eszkö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.
2
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.
•
Kliens oldal vékony-réteg technológia.
•
Szerver oldal lehetőleg uC-ben legyen megvalósítható.
•
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.
•
Platform-fü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ággal bír.
•
Az egyes megvalósítások egyszerűen adaptálódjanak a technológiához.
•
A felhasznált szoftverek nyíltforrásúak legyenek.
3
Szerver
A fenti követelményeknek a Spring framework maradéktalanul megfelel, mivel nyíltforrású és Java alapú, ezért platform-független lehet. A többi J2EE megvalósításhoz képest kisebb erőforrásigényű, ezért egy beágyazott Linux-ot 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 kliens oldali szoftverrel képekkel, és egyéb alkotóelemekkel ~32Mb méretű war fájl-ban telepíthető. Ezzel a módszerrel akár egy PLC modulként is meg lehet valósítani a rendszert, nincs szükség drága hardverek beállítására. Szerver oldalon 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, így az esetleges hibák gyorsan napvilágra kerülnek, ill. javítják. 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 logolni az ipari folyamat fontos eseményeit, valamint riasztási szolgáltatást is végez, sms ill. email formában. Természetesen, ha beágyazott rendszeren szeretnénk használni, akkor az adatbázist 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. Ezen kívül csak a technológia rajzát kell elkészíteni, erről később még lesz szó. Ezzel a módszerrel rugalmasan lehet adaptálni a rendszert a technológiához, de megmarad az ellenőrizhetőség.
4
Kliens
A definiált követelményeknek kliens oldalon 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 –, ill. 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. A biztonsági megfontolások komoly mértékben befolyásolják a fejlesztést, tehát használatával a legmodernebb biztonsági hátteret tudjuk biztosítani. A kliens oldalon 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 kliens oldalon 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 a biztonságot nagymértékben növelhetjük. Fokozott biztonság esetén egyszerű szerver-oldali módszerekkel meg lehet akadályozni a felhasználói azonosítók mentését a kliens oldalon, így egy okos-telefon, 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 kliens oldalon jelentkezik. Ez azt jelenti, hogy a kliensek számának növekedése esetén nincs szükség szerver-oldali bővítésre, mivel a szerver és kliens között csak a nyers adatok cserélődnek, így egy új kliens nem terheli jelentősen a szervert.
5
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 az adott kliensen online méretezze magát a rendelkezésre álló képernyőhöz. Ez a bitmap-ek használatát kizárja. Szerencsére létezik az SVG (Scalable Vector Graphic), ami egy szabványos vektor-grafikus 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 először 2001-ben adta ki a W3C 1.0 verziószámmal, majd 2003-ban a 1.1 verziót, ami a mai napig érvényben van. A szabvány minőségét jelzi, hogy egészen kifinomult tranzakciókra képes, pl. az animációt is támogatja. Az eltelt idő alatt egy 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. Az automatikus képernyőhöz méretezés kis problémát okozott, de nem túl nagy munkával ezt is sikerült megvalósítani. Sajnálatos módon az egyes böngészők nem teljesen adaptálják az SVG szabványt. Az alábbi táblázatban foglaltam össze a képességeiket: Böngésző
SVG támogatás
Firefox > 11.0 Windows/Linux/Android
100%
Opera > 11 Windows/Linux/Opera
100%
Chrome > 21 Windows/Linux/Android
100%
Hiányosság -
Chrome IoS/OSX
90% Nincs animáció
Safari IoS/OSX
90% Nincs animáció
Internet Explorer > 8
Nincs animáció Nagyon lassú Misztikus hibák a nem szabványos megvalósítás 70% miatt
A fenti táblázatból látszik, hogy a piacon található kliens eszközök döntő többségét 100%-ban ki tudjuk szolgálni, sajnos Apple OSX és IOS az animációt nem támogatja. Windows-on az Internet Explorer mellett mindhárom „jelentős” böngésző rendelkezésre áll, így az IE gyenge minősége nem okoz gondot. A rajzokat a nyílt forrású multi-platform-os Inkscape segítségével készítettem, így nem kellett sok időt eltölteni a rajzolással. Minden modul egy SVG fájlban készül, így egy esetleges módosítás könnyedén elvégezhető. Az elkészült rajzokon le kell futtatni egy script-et, ami a kívánt formátumra hozza őket, ill. az alapvető ellenőrzéseket elvégzi. Ugyanez a script be is másolja a formázott SVG fájlokat a program hierarchia megfelelő könyvtárába, így ezek automatikusan bekerülnek a telepítő készletbe. Az SVG azt is megengedi, hogy egy tetszőleges képi elem eseményt generáljon, így a kliens szoftverben ezt kihasználva bonyolult mechanizmusokat is egyszerűen lehet megvalósítani.
6
Teszt
A koncepció tesztelésére egy minta alkalmazást készítettem, amelyet a lehetséges legmostohább körülmények között teszteltem. Az elvárások között szerepelt a beágyazott rendszeren működés lehetősége. Erre a célra egy BeagleBoard XM rev-C típusú beágyazott Linux-ot futtató hardvert
használtam. Ennek fő paraméterei: •
Texas Instruments Cortex A8 1Ghz processzor,
•
512Mb RAM,
•
4Gb class 4(!) SD card,
•
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ázis szerver 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 hibátlanul és elfogadható sebességgel működni tud a rendszer, 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
7
Árak és licenc díjak Komponens
Licenc
Ár
Google GWT
Apache v.2.0
$0
Gwt-svg lib
LGPL
$0
Spring framework
Apache v.2.0
$0
OpenJDK
GPL
$0
Linux
GPL
$0
Debian
GPL
$0
PostgreSQL
BSD
$0
BeagleBoard XM rev-C
$125.00
Amint a táblázatból látszik, csak hardver költséggel kell számolnunk, ami igen szerénynek mondható.
8
Milyen ipari szereplők érdeklődésére tarthat számot a rendszer? 8.1
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, ezzel magas minőségű, korszerű és olcsó vizualizációt biztosíthatnak a vevőiknek.
8.2
Vizualizációs szoftver gyártók
A szoftver a felhasznált moduloknak köszönhetően rugalmasan konfigurálható, a szoftvergyártás automatizálható, így az egyes megvalósítások költsége minimális. A szoftver komponensek licenc-díja költséghatékony, modern szoftvert eredményez.
8.3
Autóipar
A fedélzeti számítógéprendszerek már most megkövetelik, hogy okos-telefonnal, táblagéppel, ill. hagyományos személyi számítógéppel lehessen kezelni, ill. diagnosztizálni az autó egyes alrendszereit. Itt is ugyanaz a probléma merül fel, mint a PLC iparban; a kliensek számának növelésével nem lehet a fedélzeti számítógép erőforrásait növelni. Ha a megjelenítés erőforrás igényét a kliensekre hárítjuk, akkor egy szerényebb teljesítményű fedélzeti számítógép is elegendő lehet. A nagy példányszámból adódóan ez a gyártóknak életbevágóan fontos szempont lehet. EIB/KNX gyártók Az intelligens épületvezérlési rendszerek gyártói ugyanazokkal a kihívásokkal szembesülnek mint a fentiek, azzal a kiegészítéssel, hogy itt egy nagyobb irodaépület esetén sokkal több kliens várható.
9
Konklúzió
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ányosságaiból adódik. Bízhatunk benne, hogy az elkövetkezendő időkben vagy maradéktalanul adaptálják az SVG szabványt, vagy eltűnnek a piacról. A kísérlet bebizonyította, hogy lehetséges egy beágyazott rendszeren költséghatékonyan megvalósítani a feladatot.
