Kiterjesztett valóság alkalmazása a folyamatiparban

Átírás

1 MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR Villamosmérnök mester szak Folyamatirányítás és ipari kommunikáció szakirány Automatizálási és Infokommunikációs Intézeti Tanszék Kiterjesztett valóság alkalmazása a folyamatiparban Diplomamunka 2014 Név: Bartók Roland Neptun: AQCCRH Cím: 4090 Polgár, Bajza u. 42.

2 Tartalomjegyzék 1 BEVEZETÉS MI A KITERJESZTETT VALÓSÁG? A MOBIL KITERJESZTETT VALÓSÁG RÖVID TÖRTÉNETE [1] INFORMÁCIÓSZERZÉS A KÖRNYEZETRŐL Jelzések használata A környezet sajátosságainak felhasználása A készülék érzékelőinek használata NÉHÁNY NÉPSZERŰ KITERJESZTETT VALÓSÁG KERETRENDSZER ARToolkit [5] [10] Vuforia [11] [12] Metaio [13] SIEMENS ÁLTAL TERVEZETT IPARI ALKALMAZÁS (2002) [14] A BECKHOFF TANULMÁNYA GOOGLE GLASS-AL GOOGLE GLASS HASZNÁLATA A TURBINA KARBANTARTÁSBAN SZEMÜVEG NÉLKÜL KITERJESZTETT VALÓSÁG RENDSZER IOS-RE FEJLESZTÉSI TERV, KÖVETELMÉNYEK A FEJLESZTÉS CÉLJA MEGOLDANDÓ FELADATOK A platform kiválasztása Helymeghatározás, helyzet-meghatározás, azonosítás A mérőpontok adatainak valós idejű lekérdezése Kommunikáció Egyéb felmerült feladatok A RENDSZER VÁZLATA A MOBIL KLIENS MŰKÖDÉSI VÁZLATA A KÖZPONTI KISZOLGÁLÓ MŰKÖDÉSI VÁZLATA, FUNKCIÓI A KLIENS PROGRAM I

3 5.1 OPERÁCIÓS RENDSZER ÉS HARDVER A KÖRNYEZET AZONOSÍTÁSA A QR-KÓD [25] A QR-kód rövid története A QR-kód felépítése A QR-kód fajtái A QR-kód felhasználása [26] QR-KÓD FELHASZNÁLÁSA A KITERJESZTETT VALÓSÁG RENDSZERHEZ A QR-KÓD AZONOSÍTÁSA, DEKÓDOLÁSA KOMMUNIKÁCIÓ A KISZOLGÁLÓVAL WebSocket Üzenetek a kiszolgáló és a kliens között FELHASZNÁLÓI FELÜLET ÉS MŰKÖDÉS Információ a jelzések fölött A bővebb információs buborék Beállítások panel Az alkalmazás leállítása AZ ALKALMAZÁS TULAJDONSÁGAI ÉS JOGOSULTSÁGAI AZ ALKALMAZÁS FONTOSABB OSZTÁLYAI ÉS KAPCSOLATAIK MEARActivity ShowCamera osztály ARView DetectedMarker ARWebSocketClient A KÖZPONTI KISZOLGÁLÓ KAPCSOLÓDÁS AZ IPARI RENDSZERHEZ Az OPC kapcsolat [33] OPC kapcsolat fajtái [33] UTGARD - OPC DA kliens [34] QR-KÓDOK GENERÁLÁSA ÉS ÖSSZERENDELÉSE AZ ÉRZÉKELŐKKEL KAPCSOLATTARTÁS A KLIENSEKKEL A KÖZPONTI KISZOLGÁLÓ ELŐNYE II

4 6.5 A PROGRAMOT ALKOTÓ OSZTÁLYOK ÉS KAPCSOLATAIK MEARX osztály SplashGUI MainGUI MEARProperties MWebServer ARClient ARMarker MarkerDataBaseManager ARQrCodeGenerator MearOpcConnection UtgardOpc DataCallbackDumper és VariantDumper ELVÁRÁSOK A KIHELYEZETT JELZÉSEKKEL SZEMBEN HOGYAN MŰKÖDIK A RENDSZER? A KÖZPONTI KISZOLGÁLÓ HASZNÁLATA A főablak alapállapotban A főablak élő kapcsolattal Új jelzés felvétele OPC tag-ek rendelése a jelzéshez, mértékegység megadása A KLIENSEK HASZNÁLATA MIÉRT LEHET HASZNOS EGY ILYEN RENDSZER? FEJLESZTÉSI TERVEK ÖSSZEGZÉS SUMMARY KÖSZÖNET FORRÁSOK MELLÉKLET III

5 1 Bevezetés Az embereknek általános igénye, hogy információt szerezzenek a környezetükről. A megszokott érzékelés azonban nem képes azonnal megmutatni mindent, amire kíváncsiak vagyunk. Például, ha csak ránézünk egy forgó motorra, nem tudjuk, hogy pontosan milyen fordulatszámmal forog, mekkora áramot vesz fel. A saját érzékelői mérik, de előfordulhat, hogy a kijelzés távolabb van, így nem láthatjuk. Az okostelefonok, táblaszámítógépek, viselhető eszközök segítségével azonban egyre inkább elérhetővé válik egy régóta ismert és igényelt, friss technológia, amellyel a szemlélt környezetről olyan információkat is szerezhetünk, amely eredetileg nem látható, esetleg nem hallható. A technológia neve kiterjesztett valóság (angolul augmented reality). Körülbelül az 1990-es évek közepétől kezd lassan terjedni, ahogy egyre nagyobb számítási teljesítmény áll rendelkezésre. Napjainkban az egyre növekvő számítási teljesítménnyel bíró hordozható eszközöknek köszönhetően egyre szélesebb körben tud elterjedni. Kezdetben a mérnökök játéka volt, később a tervezők munkáját segítette, majd lecsapott rá a reklámipar, használják navigációs rendszerekben, megjelentek a karbantartási, javítási munkálatokhoz segítséget nyújtó programok főleg bonyolult gépek esetén. Ipari alkalmazásában az utóbbi években tűnt fel, a technológia monitorozására használják. Ez a dolgozat is egy monitorozó, megfigyelő rendszert mutat be, amely egy táblaszámítógép képernyőjén keresztül a kamera által látott képre vetíti a megfigyelt technológia működési paramétereit akár a tényleges mérési ponttól távolabbi helyeken is, ahol az értékek még helyesek lehetnek (például a nyomás vagy áramlási sebesség egy csővezeték szakasz teljes hosszában). Az iparban is egyre elterjedtebbek az érintőképernyős eszközök, felépítésük robosztus az ipari körülményeknek megfelelően. Ezeken futtatható a bemutatásra kerülő alkalmazás, hogy a karbantartók egy egyszerű pásztázással információt szerezhessenek a megfigyelt technológia működéséről. A rendszer egy központi kiszolgálóból, kliens alkalmazásból és a technológián elhelyezett helyőrzőkből épül fel, amelyeket a kliens felismer

6 2 Mi a kiterjesztett valóság? A kiterjesztett valóság és a virtuális valóság sok tekintetben hasonlít egymásra mégsem szabad összekeverni a két technológiát, bár több közös vonásuk van, mégsem ugyan arról van szó. Míg a virtuális valóság egy elképzelt, virtuális világot vetít a szemlélő elé, teljesen elfedve a valóságos képet, addig a kiterjesztett valóság virtuális képpel, információkkal kiegészíti a valóságot. Nem cseréli fel teljesen, hanem kibővíti azt. 2.1 A mobil kiterjesztett valóság rövid története [1] Legelőször 1901-ben L. Frank Baum író a The Master Key című regényében ír egy olyan elektronikus kijelzőről, amelyen keresztül a megfigyelt személy homlokán megjelenik a fő tulajdonságának megfelelő betű (G good, E evil stb.). Az író szerint ez a technológia egy évszázaddal megelőzi a korát. [2] 1968-ban készítette el Ivan Sutherland az első fejre tehető kijelzőt ben Myron Krueger kivetítőkkel és kamerákkal kötötte össze a valóságot a virtuális világgal. Gyors algoritmusokkal ismerte fel a 1. ábra Ivan Sutherland fejre homogén vászon előtt mozgó kesztyűt és más helyezhető kijelzője [1] alakokat. [3] 1994-ben Paul Milgram és Fumio Kishino definiálta a Valóság-Virtualitás kontinuumot, amely magába foglalja a valós környezetet és a virtuális környezetet. A kiterjesztett valóság szerintük közelebb áll a valósághoz, mint a virtualitáshoz. 2. ábra Valóság-Virtualitás Kontinuum [1] 1995-ben Jun Rekimoto és Katashi Nagao elkészítette a NaviCam-ot, ami színes színkódolt jelzéseket azonosítva jelenítette meg a kapcsolódó információkat

7 Hordozható kijelzőt és kamerát alkalmazott. A kamera képét egy közeli erős asztali munkaállomás dolgozta fel ban Jun Rekimoto bemutatta a 2 dimenziós fekete-fehér mátrix kódokat, négyzet alakú vonalkódokat, amelyeket a kamera 6 szabadsági fokban tud követni. [4] 1999-ben Hirokazu Kato és Mark 3. ábra NaviCAM [1] Bilinghurst bemutatta az ARToolkit-et, amely mára nagyon népszerű nyílt forrással is elérhető kiterjesztett valóság könyvtár. [5] 2000-ben Bruce Thomas és csapata bemutatta az AR-Quake-et, amely a népszerű PC játék, a Quake kiterjesztett változata. A kültéren és beltérben is játszható első személy nézetes játékhoz felhasználtak GPS-t, digitális iránytűt és vizuális jelzéseket. A játékosok egy-egy 4. ábra ARToolkit [1] számítógépet cipeltek a hátukon, irányításhoz egyszerű kétgombos beviteli eszközt használtak. A kiterjesztett valóságot fejen hordott kijelzőn keresztül látták. A hagyományos billentyűzet és egér utasításokat a játékosok valóságos mozgása adta ben Michael Kalkusch és csapata bemutatott egy olyan rendszert, amely egy ismeretlen épületben segíti a tájékozódást ARToolkit alapon 2 dimenziós feketefehér jelzések segítségével ban Reitmayr és csapata egy modell alapú hibrid objektumkövető rendszert mutatott be kültéri kiterjesztett valóság alkalmazásokhoz. Már képes valós időben a virtuális képet a valós képre vetíteni egy kézi számítógépen. [6] 2007-ben Kelin és Murray bemutatott egy rendszert, amely képes valós időben objektumkövetésre és térképezésre egy egyszerű kamerával kis munkaterületen

8 2008-ban Wagner és csapata mutatta be az első valós idejű, mobil eszközön futó, 6 szabadsági fokú objektumkövető rendszert, amely természetes jellemzőket ismer fel a képen. A METAIO pedig az első kereskedelmi mobil kiterjesztett valóság alapú múzeumi útmutatót mutatott be. Szintén a környezet természetes jellemzőit használták fel a virtuális kép helyének meghatározásához től egyre több kiterjesztett valóság alapú alkalmazás jelent meg: Layar [7], amely a városban segíti a felhasználót például egy éttermet megtalálni. Google Sky Map [8], amely az égbolt csillagait rajzolja ki segítve az egyes csillagképek, bolygók azonosítását. A reklámipar a vizuális jelzés alapján működő kiterjesztett valóság alkalmazásokat használja. Ilyen az Ikea mobil alkalmazása [9], amely a katalógus megfelelő ábráját felismerve a szobába rajzolja a kiválasztott bútort a kívánt színben, valós méretben. 2.2 Információszerzés a környezetről Ahhoz, hogy a megfelelő objektum kerüljön a kamerakép megfelelő helyére, meg kell határozni, hogy mit lát éppen a felhasználó a kijelzőn keresztül (ebben az esetben a kijelzőn keresztül vagy egy kamera valós képén keresztül látja a világot vagy egy átlátszó kijelzőn keresztül, ekkor nincs látható élő kamerakép) Jelzések használata Az egyik legegyszerűbb mód, ha a fontos objektumokat, helyeket valamilyen kameraképen könnyen felismerhető és azonosítható címke jelöli. Ilyen címke lehet a már említett 2 dimenziós vonalkód vagy a napjainkban elterjedt változata, a QR-kód. A vonalkód kameraképen nehezen ismerhető fel, a sűrű függőleges vonalakat egy telefon kamerája általában összemosódva érzékeli, ezért előnyösebb a négyzet alapú jelzés. A négyzet torzulása segítséget nyújt ahhoz is, hogyan kell transzformálni a kirajzolt virtuális objektumot

9 2.2.2 A környezet sajátosságainak felhasználása Az eljárás angol neve: natural feature detection/tracking. A környezetről készít egy absztrakciót, amely pontokból, vonalakból, esetleg foltokból vagy ezek keverékéből áll. Attól függően választja ki, hogy a látott kép melyik absztrakciónak felel meg, hogy mennyire illeszkedik a tárolt absztrakt képre a látott absztrakt kép. Ezzel a módszerrel szinte bármi használható jelzésnek a kiterjesztett valóság alkalmazáshoz A készülék érzékelőinek használata Egy mai átlagos készüléket felszerelnek sok esetben GPS vevővel, elektronikus iránytűvel, gyorsulásmérővel, elfordulás mérővel. Ezek adataiból meghatározható, hogy a készülék éppen hol van, mit láthat a kamerája. Használják az egyes érzékelőket egyenként is, gyakori kombináció a GPS és az elektronikus iránytű párosa. A felsorolt módszerek külön-külön is használhatóak, de általában valamilyen kombinációban használják őket. Az általunk megcélzott környezet tartalmaz fedett helyszíneket és olyan fémekkel körülhatárolt teret, ahol a GPS használhatatlan, az iránytű megbízhatósága is kérdéses. Ezért inkább a vizuális jelzéseken alapuló megvalósítást választottam. A jelzés vagy helyőrző azonosítása, helyének meghatározása a kameraképen már megadja azt is, hová kell rajzolni az információt. Megfelelő 2 dimenziós kód akár plusz információt is tárolhat, így ha több helyen szükséges ugyan azt az információt megjeleníteni csak egy újabb jelzést kell elhelyezni a mobil alkalmazás számára. 2.3 Néhány népszerű kiterjesztett valóság keretrendszer ARToolkit [5] [10] 1999-ben Hirokazu Kato és Mark Bilinghurst által kifejlesztett mára az egyik legelterjedtebb kiterjesztett valóság könyvtár. Valós idejű kamerakép feldolgozást támogat, amelyre képes 3 dimenziós objektumokat rajzolni a felismert jelzésre és követi a nézőpont változását. Létezik jelzés alapú és a környezet sajátosságait felhasználó megvalósítása is. Jelzésnek fekete négyzet fehér belsejében elhelyezett - 5 -

10 képet, alakzatot használják. Elérhető Windows, ios, Android platformokra. Támogatja a Flash-t, Unitiy-t és a webes alkalmazásokat. A felhasznált gyors algoritmusoknak köszönhetően képes közel a kamera képfrissítési sebességével működni, viszonylag egyszerű egy új program implementációja a segítségével. Mobil platformokból az ios-t és az Android-ot támogatja. Létezik egy AndAR nevű Java alapú könyvtára, amely szintén használható Android platform is. Az Android rendszerekből a 2.2-től frissebbeken fut. A jelzések követésén túl lehetővé teszi a környezet jellemzőin alapuló nézőpontkövetést. Elérhető GPLv2 licenc alatt, így ingyenesen használható, de az elkészült programnak is nyílt forrásúnak kell lenni és 5. ábra ARToolkit működés közben [5] bárki számára ingyenesen elérhetőnek. Létezik kereskedelmi licenc, ezzel többletszolgáltatások is elérhetővé válnak pénzdíj ellenében. Az elkészült program zárt forrású, kereskedelmi forgalomba hozható lesz Vuforia [11] [12] A Vuforia a Qualcomm Connected Experiences által kiterjesztett valóság alkalmazások létrehozására fejlesztett platform. Elérhető Andriod és ios rendszerekre. Csak képfeldolgozáson alapul, hasonlóan az ARToolkit-hez. A fejlesztőkörnyezet által nyújtott lehetőségek: Szó felismerés körülbelül 100 ezer angol szót tartalmazó adatbázist használ vagy létrehozható egy saját szótár. Képek felismerése, követése a kameraképen. Saját kép használatára is lehetőséget nyújt. Forgástestek felismerése és követése, például üvegek, csészék, korsók. Egyszerű térbeli alakzatok, például dobozok felismerése. Keretes jelzések használata. A kereten belül bármilyen kép elhelyezhető, a keretek 512 variációt biztosítanak. A jelzéseken virtuális gombok kezelését támogatja, videó lejátszást

11 A felsoroltakon túl a fejlesztő vállalat felhő-szolgáltatást is nyújt a fejlesztett alkalmazások adatainak tárolására illetve készülék adatbázist. Használható ingyenes és kereskedelmi licenc alatt. 6. ábra Egy Vuforia SDK-val készült mintaprogram [12] Metaio [13] A Metaio GmbH. a világ legnagyobb kiterjesztett valóság szoftvertechnológiát fejlesztő vállalata ban alapították és 2006 óta tagja az insidear kiterjesztett valóság konferenciának. Támogatják a Windows, ios, Android operációs rendszereket, asztali és mobil hardverre, webes alkalmazásokat. A metaio nem csak képfeldolgozást használ, feldolgozza a futtató készülék érzékelőinek és GPS-ének az adatait is, ha elérhető. Támogatják a viselhető eszközöket is, mint például a Google Glass, Vuzix szemüvegek. Létezik iparban használható kiterjesztett valóság alkalmazásuk is. Ipari megoldásaik többek között CAD objektumokat jelenítenek meg, új külsőt varázsolnak egy autóra, képesek vezérelni a KUKA robotot, interaktív javítási segédletet biztosítanak egyes autófajtákhoz a 7. ábra Gépkocsi szerelési segédlet [13] - 7 -

12 szerelőknek és a közembereknek. Létezik olyan ipari alkalmazásuk is, amellyel a megfigyelt környezet monitorozható, a megfigyelt terület azonosítása a környezet jellemzői alapján történik. Termékek: metaio SDK: kiterjesztett valóság alkalmazások készítésére használható fejlesztői csomag. metaio Creator: kiterjesztett valóság alkalmazás, amellyel a felhasználó készíthet teljes jeleneteket a kiterjesztett valóság alkalmazáshoz programozói tudás nélkül. junaio: Kiterjesztett valóság alapú böngésző. metaio CVS (Continuous Visual Search): képfelismerés. metaio Cloud: a metaio felhasználói számára online tárhely a tartalmak számára. metaio Engineer: ipari használatra szánt alkalmazás, CAD állományok valós méretű megjelenítésére. A metaio SDK elérhető ingyenes és pénzdíjas változatban is. Az ingyenes változat megjelenít egy vízjelet az elkészített programban. 2.4 Siemens által tervezett ipari alkalmazás (2002) [14] Elsősorban meghibásodott eszközök felderítésére tervezte a Siemens a beszédet támogatott kiterjesztett valóság (Speech Enabled Augmented Reality SEAR) nevű elképzelését. A rendszer az üzemben elhelyezett infra-adók segítségével határozza meg a kezelő helyét és irányát, a pontosításhoz optikai jelzéseket is használnak. Segítségével a karbantartó mérnök hamarabb megtalálja a meghibásodott alkatrészt, mert a rendszer a pillanatnyi pozícióját felhasználva navigálja a megfelelő helyre. Szóbeli utasításokra az IP címmel rendelkező egységek 8. ábra Siemens - Beszélő csövek [14] válaszolnak a PDA-n keresztül. A es cikkben az kereskedelmi forgalomba helyezését 5-7 évre becsülték

13 2.5 A Beckhoff tanulmánya Google Glass-al A Beckhoff a novemberi nürnbergi SPS IPC Drives automatizálási szakvásáron mutatta be a gépek kezelésének új, Google Glass szemüvegre alapozott koncepciójának műszaki tanulmányát. [15] 9. ábra Képek a Beckhoff alkalmazásáról [16] A leírásuk szerint a szemüveg a kameráján keresztül felismeri a gépeken elhelyezett QR-kódokat, amely alapján azonosítja az adott gépet. Ezután megjelennek a szemüveg kijelzőjén a megfigyelt gép működési paraméterei, elérhetők az adatlapok. Kép készíthető az adott gépről, amelyet megoszthat más felhasználókkal. Ha szükséges kapcsolatba léphet más felhasználókkal vagy hanginformációkat érhet el. A szemüveg az adatokat a rendszerhez kapcsolódó szerverről kérdezi le a QR-kódban tárolt információ alapján. A szerver a TwinCAT-el vezérelt automatizálási szerverrel kommunikál. [16] [17] [18] 2.6 Google Glass használata a turbina karbantartásban A General Electric közzétett egy kisfilmet, amelyben egy turbina karbantartó csapat a karbantartási munkálatok során aknázza ki a viselhető számítógép és kiterjesztett valóság eszközben rejlő lehetőségeket. Az alkatrészek azonosításán, a részegységek javítási naplójának kezelésén túl külső hardver elemet is párosítanak a viselhető számítógéphez (endoszkóp) ezzel is egy kijelzőt és kezelőfelületet megspórolva. A munka közben a munkatársak hang alapú párbeszédet folytathatnak egymással és a szemüveggel, értesíthetik egymást például az új alkatrész érkezéséről. Segíti őket a rendszer, hogy a megfelelő helyre vigyék az alkatrészt. Az alkatrészek és azok helyének azonosítására QR-kódot használnak

14 A 10. ábra mutatja, hogy a karbantartó személy mit lát a szemüveg mögött. A hangutasítás után a készülék megmutatja, hogy éppen milyen állapotban van a munkálat. Másik információs ablakban az előrehaladás rögzíthető például megérkezett az alkatrész vagy elvégezték a turbina belső vizsgálatát. [19] 10. ábra General Electric, Google Glass felhasználása karbantartási munkálatok során (látvány a szemüveg mögül) [19] 2.7 Szemüveg nélkül Kiterjesztett valóság rendszer ios-re Az iqagent Inc. a Kepware-el közösen a dolgozatban leírthoz hasonló rendszert fejlesztett. Az iqagent kliens alkalmazás az Apple táblagépén fut, QR-kódokat olvas. Az adatokat az KEPServerEX biztosítja, amely OPC kapcsolatot tart többfajta ipari rendszerrel. A valósidejű adatátvitelen kívül az adott rendszer kezelési leírását is biztosítja az iquest Server PDF formátumban továbbá szöveges és videó 11. ábra iqagent kliens formátumban a kliensek számára. Tapasztalatuk szerint 5000 jelzés létrehozása kicsit több mint egy hetet vett igénybe. [20] [21] [22]

15 3 Fejlesztési terv, követelmények 3.1 A fejlesztés célja A cél egy olyan rendszer létrehozása, amely segítségével az iparban dolgozó felhasználó egyszerű módon juthat valós idejű információhoz a megfigyelt technológiával kapcsolatban. Mindezt úgy, hogy egy kamerával felszerelt készülék azonosítja a megfigyelt területet, kérdezi le a szükséges adatokat olyan helyen is, ahol már az adatokat mérő érzékelők kijelzője nem látható, hozzáférhető, de az értékek még jellemzik a rendszert. Ezen kívül fontos a mobilitás. Az alkalmazással szemben elvárás, hogy olyan hardveren is fusson, amely veszélyes ipari környezetben is használható. Illetve tudnia kell kommunikálni, adatkapcsolatot létesíteni az elterjedt számítógépes folyamatirányító rendszerekkel (OPC kapcsolat), hogy valós idejű adatokat kérdezzen le az azonosított technológiarészlettel kapcsolatban. 3.2 Megoldandó feladatok A platform kiválasztása Az alkalmazás számára a jelenleg legelterjedtebb mobil operációs rendszert, az Android-ot választom. Népszerűsége miatt nagyon sokfajta hardveren elérhető, használják az iparban is. Léteznek rá például Bluetooth alapú adatmegjelenítő, adatgyűjtő alkalmazások különféle mérőeszközökhöz. [23] Helymeghatározás, helyzet-meghatározás, azonosítás Fontos, hogy az alkalmazás tudja, mit lát éppen a kamera. Beltéri ipari környezetben és olyan külső téren, ahol a megfigyelőpont sok fémes építménnyel van körülvéve a GPS megbízhatatlan vagy akár használhatatlanná is válhat. Ezért a hely meghatározására nem alkalmazható. A pontos meghatározáshoz vizuális jelzések felismerése jelenthet megoldást. 2 dimenziós mátrix kódokkal a mérőpontok azonosítása is megoldható. Felismerésük viszonylag gyors, a kinyert információ alapján egyértelműen kiderül mely jelzés került a kamera látóterébe. A mérőpont által tárolt azonosító egyúttal a lekérdezendő adatok azonosítója is lehet. A vonalkódok kamerával nehezen azonosíthatóak, a vékony vonalak könnyen összemosódhatnak a kamera képén

16 3.2.3 A mérőpontok adatainak valós idejű lekérdezése Az azonosítást követően az ipari folyamatirányító szervertől kell az adatokat lekérdezni. Mivel várhatóan sok mérőpontot kell kezelni a rendszerben így szükséges lehet egy központi kiszolgáló felállítása. Így nem szükséges vastag kliensalkalmazást létrehozni a terepen használt mobil eszközre. A központi kiszolgáló kérdezi le a folyamatirányító rendszerről a kívánt információkat, bármilyen változás esetén elegendő a közös adatbázison változtatni nem kell a kliensalkalmazást minden mobil eszközön frissíteni. Ez főként akkor kényelmes megoldás, ha karbantartás vagy új mérőeszközök beépítése miatt akár időszakosan is gyakran kellene a műveletet elvégezni. Előnyös azért is egy központi kiszolgáló használata, mert nem biztos, hogy minden folyamatirányítási rendszernek létezik támogatása mobil operációs rendszerre Kommunikáció A mobil eszközök körében a legelterjedtebb kommunikációs lehetőség a WiFi és a Bluetooth kapcsolat. Utóbbi kisebb hatótávolsága és az egyidejűleg kezelhető kliensek alacsony száma miatt nem használható. A WiFi segítségével akár a meglévő hálózat is igénybe vehető, ha a többlet adatmennyiség nem zavarja a megszokott kommunikációt. Ellenkező esetben szükséges lehet egy újabb hozzáférési pont hálózat kiépítése figyelembe véve, hogy az újabb rádiós eszközök között ne lépjenek fel zavarások. A központi kiszolgálónak egyszerre több kliens számára is biztosítani kell az adatokat, ezért olyan kapcsolati megoldást kell alkalmazni, amely támogatja, hogy egyszerre sok klienst kiszolgál. Tehát az egyszerű TCP/UDP csomagok küldésénél és fogadásánál érdemes valami intelligensebb megoldást választani Egyéb felmerült feladatok A használhatóság javítása érdekében a központi kiszolgálót ki kell egészíteni egy olyan lehetőséggel, hogy a kihelyezendő mátrixkódokat is képes legyen előállítani és legalább nyomtatható formátumba exportálni. Az ilyen módon generált kódokat automatikusan felveszi az adatbázisba így már csak össze kell rendelni a megfelelő mérőeszközök adataival

17 4 A rendszer vázlata 12. ábra A teljes rendszer vázlata A 12. ábra a teljes rendszer vázlatát mutatja. Az üzemben a mobil kliensek mozognak és kérdezik le a szükséges információkat a központi kiszolgálótól. A központi kiszolgáló feladata a kapcsolat fenntartása az ipari rendszerrel, az adatok lekérdezése és a kért adatok kiküldése a kliensek számára

18 4.1 A mobil kliens működési vázlata A mobil kliens a kameraképen felismeri és azonosítja a telepített jelzéseket. Hálózati kapcsolaton keresztül lekérdezi a jelzéshez tartozó információkat és a 13. ábra A mobil kliens működési vázlata kameraképen a jelzésnek megfelelő helyre rajzolja. Az adatok nem a 2. fejezet képein látható 3 dimenziós megjelenítési módon tűnnek fel a képernyőn, hanem 2 dimenziós síkban kerülnek kirajzolásra. Mivel csak adatok megjelenítéséről van szó, nem feltétlenül szükséges a térbeli transzformációjuk

19 4.2 A központi kiszolgáló működési vázlata, funkciói 14. ábra A központi kiszolgáló vázlata A központi kiszolgáló egy adatbázisban tárolja mely jelzésekhez mely adatokat kell lekérdezni az ipari szervertől. Tartja a kapcsolatot az aktív kliensekkel és az ipari szerverrel. Fogadja a kéréseket a kliensektől és a megfelelő adatok lekérdezése után válaszként küldi a kívánt információt. Lehetőséget nyújt új jelzések generálására, hozzájuk adatok rendelésére és a meglévő jelzésekhez új érzékelők rendelésére

20 5 A kliens program A kliens program felhasználói főként az üzem területén, a technológia, gépek közelében karbantartási, felügyeleti munkát végző személyek. A kliens segítségével a kameraképen láthatják, hogy a megfigyelt mérőpontokon a technológia helyesen működik-e és a fontos paraméterek értékét valós időben követhetik. Az alkalmazás fantázia neve: MEAR-X, az egyetem nevének rövidítéséből (ME) és a kiterjesztett valóság angol elnevezésének rövidítéséből (AR) képzett betűszó az X pedig a ZXing (Zebra Crossing) csomagra utal. 5.1 Operációs rendszer és hardver A kliens alkalmazás számára a jelenleg legelterjedtebb és általam is legjobban ismert mobil operációs rendszert, az Android-ot választottam. Egyik követelmény, hogy a kifejlesztett rendszer veszélyes ipari környezetben is használható legyen. Ennek feltétele, hogy a kliensalkalmazást futtató hardver rendelkezzen a megfelelő ATEX minősítéssel. A tábla számítógépek széles választékában elérhető szinte minden zónához megfelelő készülék. Természetesen olyan területen, ahol nem fenyeget robbanás vagy egyéb veszély a megszokott, de tartós kivitelű készülékek is alkalmazhatóak. Célszerű az alkalmazást tesztelni a kiválasztott készülékkel, mert előfordulhat, hogy a kamera gyenge minőségű, ami miatt a jelzések felismerése 15. ábra Z720-EX [39] lehetetlenné válik vagy olyan módosított Android változatot telepített a gyártó a készülékére, ami miatt módosítani kell az alkalmazáson vagy más készüléket kell keresni. A jelzések megfelelő elhelyezésével lehetséges, hogy nem kell például a legszigorúbb elősírásoknak megfelelő készüléket használni, mert biztonságos távolságból is monitorozható a veszélyes üzemrész működése. Itt látható az egyik előnye a kiterjesztett valóság alapú monitorozó rendszernek, mert nem szükséges külön SCADA/HMI panelt a biztonságos területre telepíteni, hanem elegendő a jelzést felfesteni vagy kihelyezni. Másik fontos követelmény, hogy a készüléken legyen egy megfelelő minőségű hátoldali kamera. A használhatóság érdekében fontos, a kamera jó

21 felbontóképessége, tehát videó üzemmódban is részletes képet adjon, amelyen jól látszik a jelzés akár nagyobb távolságról is. Fontos, hogy gyenge fényviszonyok mellett se legyen a kép túl zajos, mert az lehetetlenné teheti a felismerést. Ennek a követelménynek a közép-, és felsőkategóriás illetve ipari kivitelű készülékek többsége eleget tesz. Szintén fontos a készülék kijelzője. Felhasználástól függően célszerű lehet olyan rezisztív érintőképernyővel szerelt készüléket választani, amely kesztyűben is kezelhető. A képernyő mérete lényeges, egy kisebb méretű képernyőn jóval kevesebb információ fér el és bizonyos esetekben a képernyő pixelekben számított mérete meghatározza a kamera élőképének is a legnagyobb méretét pixelekben. Tapasztalat szerint 800*480pixel méretű élőképpel és képernyővel már kényelmesen használható az alkalmazás. A táblagépek általában legalább 7-12 képátlóval készítik és egyre gyakoribb a HD-nek megfelelő felbontás (1920*1050). A napjainkban használt hardverek számítási teljesítménye elegendő az alkalmazás megfelelő használatához a közép-, és felsőkategóriában az ipari és ellenálló kivitelű készülékek teljesítménye szintén elegendő. 5.2 A környezet azonosítása A 2. fejezetben bemutatott módszerek alapján a mérőpontok azonosítása 2 dimenziós fekete-fehér mátrix kódokkal történik. Ezek közül is a közismert QRkóddal. Ennek előnye a vonalkóddal szemben, hogy kamerával is könnyen felismerhető és értelmezhető. Elterjedtebb, mint a többi hasonló megoldás, például az Aztec-kód [24]. Az egyszerű fekete keretes mátrixkódokkal szemben jóval több egyedi azonosítót lehet létrehozni. Jelen esetben nem elég azt felismerni, hogy hol van a jelzés a képen, hanem azonosítani is kell, hogy melyik jelzésről van szó. Előnye, hogy bármilyen szögben elforgatva dekódolható. 5.3 A QR-kód [25] A QR-kód rövid története Japánban az 1960-as években fejlesztették ki a vonalkódot termékazonosításra. Az ok, hogy a pénztárosok ínhüvelygyulladást kaptak a sok gépeléstől. A vonalkódnak köszönhetően, ami 20 karaktert, betűt és számokat tudott tárolni egy leolvasó segítségével a termék azonosítója a számítógépbe került, nem

22 kellett tehát a pénztárosnak begépelni az árat sem. A vonalkód olvasó készülékeket a DENSO WAVE INCORPORATED (az akkori DENSO CORPORAITON divíziója) fejlesztette. Felmerült az igény arra, hogy ne csak latin karaktereket tároljanak a kódokban, hanem Kanji és Kana karaktereket is. Ehhez nagyobb adatmennyiség tárolása vált szükségessé. A nagyobb adatmennyiség nem csak más karakterek kódolására, hanem jóval több egyszerű információk tárolására is lehetőséget nyújtott, ami nagyon jól jött a logisztikában. A vonalkódokat csak egy irányban lehet leolvasni, olyan kódra volt igény, amely több irányból is leolvasható, dekódolható. Erre a problémára jelentett megoldást a 2 dimenziós adatmátrix, de 16. ábra QR-kód olvasási irányok, még mindig nem lehetett bármilyen pozíciójelzések [25] irányból leolvasni ezért raktak rá pozíciójelzéseket, egy teljesen egyedi kódot létrehozva ben a DENSO WAVE bejelentette a QR-kódot. A QR-kód neve egy rövidítés, Quick Response Code, azaz gyors válasz, mivel tízszer gyorsabban lehet dekódolni, mint a hagyományos kódokat. Masahiro Hara ötlete (a QR-kód) nagyban hozzájárult a logisztikai folyamatok gyorsításához, pontosításához. A DENSO WAVE bárki számára szabadon hozzáférhetővé tette a QR-kód leírását, ezzel is nagyban hozzájárult a kód gyors elterjedéséhez óta nemzetközi szabvány (ISO/IEC18004). A legnagyobb lökést a 2002-től megjelenő telefonok jelentették, mert így ténylegesen bárki használhatta, leolvashatta a kódokat, amelyek segítségével weboldalakat érhetett el és érhet el napjainkban is A QR-kód felépítése A QR-kód egy 2 dimenziós pont mátrix, pozíciójelzésekkel. 21x21-től 177x177 darab modulból épülhet fel oldalanként 4-4 modullal növekedve. Egy-egy modul egyegy 8 bites mintának felel meg. A különböző QR-kód verziók eltérő adatmennyiséget

23 17. ábra A QR-kód felépítése [40] képesek tárolni. A tárolt adatmennyiség függ a QR-kód méretétől és a tárolandó karakterek fajtájától is. Számokból képes a legtöbbet tárolni. Európában a legelterjedtebb a 3-as verziójú QR-kód. A QR-kód kinyomtatva kisméretű, kosz és sérülésálló a hibajavításnak köszönhetően. Négy hibajavítási szintet tartalmaz a szabvány: L, M, Q, H szinteket, amelyek sorban a kódszavak 7%, 15%, 25% és 30%-át képesek visszaállítani. A hibajavításra a zenei CD-k nyomán ismert Reed-Solomon eljárást használják. A fekete négyzetek egy-egy 8bitet tároló mintát rejtenek, amely az információt tárolja. 18. ábra A QR-kód verziói [25]

24 A QR-kód felépítését a 17. ábra mutatja. A 2-es modell tartalmaz egy vonatkozási pontot is, amely segítségével nagyobb szögből és enyhén meggyűrődve is olvasható marad a kód. A QR-kód jó olvashatóságát segíti, ha a keret legalább a belső négyzeteket alapul véve 4-5 négyzet szélességű és lehetőleg fehér színű A QR-kód fajtái A QR-kód a megszokott feketefehér megjelenésén kívül az alábbi fajtái léteznek: Mikro QR-kód: Egyetlen eligazodási pontja van. Előnye, hogy sokkal kisebb, mint az általános változat. A legnagyobb verziója M4-es, amely 17x17 modulból áll 35 számot képes 19. ábra Átalános és tárolni. mikroméretű QR-kód [25] iqr-kód: olyan QR-kód, amely nem csak négyzet alakú lehet, hanem az adatmátrixhoz hasonlóan téglalap alakú is. Előnye, hogy kisebb méretben képes a QR-kód által tárolt információt tárolni, jobb a hibajavítási képessége is. 20. ábra iqr-kód [25] SQRC: Formáját tekintve nem különbözik a hagyományos QR-kódtól, hogy a tényleges információ csak a megfelelő készülékkel nyerhető ki belőle. Ebben a kódban tárolható személyes információ, vállalatok magán információi, tehát minden, ami nem tartozik mindenkire. Normál QR-kód olvasóval is le lehet olvasni, de értelmetlen számsort lehet csak kinyerni belőle. LogoQ: Olyan QR-kód, amely egy teljes színes képet ágyaz magába. 21. ábra LogoQ [25]

25 5.3.4 A QR-kód felhasználása [26] Gyártás területen gyártmánykövetésre, folyamatirányításra, rendeléskövetésre, gépek és berendezések kezelésére használják. Raktározás és logisztika területen csomagok, szállítmányok követésére, a kiskereskedelemben termékazonosításra és leltárkezelésre használják. Az egészségügyben a leletek kezelésére, betegazonosításra és követésre alkalmazzák. Ezen kívül QR-kód alapon vásárolhatunk például vonatjegyet is (MÁV-START) [27]. Ekkor elektronikus levél formájában küldik a QR-kódot is, amelyet a jegyellenőrzésnél a telefon kijelzőjéről olvasnak le. Népszerű a marketing és reklámiparban, ahol címeket, URL-eket rejtenek vagy hűségpont illetve kuponként is működhetnek a QR-kódok. 5.4 QR-kód felhasználása a kiterjesztett valóság rendszerhez A környezet azonosítására QR-kódok kerülnek felhasználásra, mégpedig a 2- es verzió 2-es modellje, amely tartalmaz a három pozicionálójelzésen kívül egy negyedik jelzést is, hogy nagyobb szögből, akár torzítva is nagy távolságról olvasható legyen. A teszteléshez használt telefon kamerájának gyújtótávolsága 35mm-es rendszerben 24mm-nek felel meg, ez 85 -os látószöget jelent. Az élőkép legnagyobb mérete 800x480pixel. Egy 50x50mm-es 2-es verziójú QR-kódot még 1 méterről felismer. 4 méterről már 150*150mm-es méret szükséges egy 2-es verziójú QRkódból. Előfordulhat, hogy vibráló fény vetül a QR-kódra vagy eleve sötét helyre kell valamiért elhelyezni. Ez gyakran olvashatatlanná teszi a kódot. A probléma orvosolható, ha saját LED-es fényforrás világítja meg a mérőpont jelzését

26 5.5 A QR-kód azonosítása, dekódolása A QR-kódok feldolgozása ZXing (Zebra Crossing) projekt csomagjával történik. Ez egy gyors és népszerű nyílt forráskódú csomag, elérhető az Android mellett más mobil és asztali operációs rendszerekre is különböző programozási nyelveken. Képes többfajta zebra-kódot értelmezni, lehetőség van egyszerre több QR-kód olvasására is. Minden felismert és dekódolt kódnak megadja a jellegzetes pontjait. Az alkalmazás ezt használja fel a kirajzolandó információk középpontjának meghatározásához. 22. ábra ZXing logo [29] A fekete-fehér kódokat az élő képfolyam világossági értékeinek binarizálása után a kép síkfrekvenciájának megnövekedése alapján találja meg, majd értelmezi, hogy azon a helyen valóban QR-kódot talált-e. Amennyiben sikeres az azonosítás elérhető a QR-kód sarkainak pozíciója és a benne található információ. A ZXing csomag nem csak a QR-kódok olvasásra, hanem azok generálására is használható. Erről bővebben a kiszolgáló működésénél lesz szó. [28] [29] 5.6 Kommunikáció a kiszolgálóval A mobil eszközön futó alkalmazás egy vékony kliens, amely csak a kihelyezett jelzések azonosításával és az azokhoz tartozó adatok megjelenítésével foglalkozik. A szükséges információkat egy központi kiszolgáló biztosítja, amely a klienseken kívül az ipari folyamatirányító rendszerrel is tartja a kapcsolatot. Mivel egy gyár területén nem csak egyetlen dolgozónak szándéka információt szerezni a technológiáról, amelynél munkát végez, ezért egyidejűleg több kliens is kapcsolódhat a kiszolgálóhoz. Ehhez érdemes olyan kommunikációs csatornát választani, amely kezeli a több kliens kapcsolódását és kiszolgálását duplex módon. A kliensnek és a kiszolgálónak is tudniuk kell egymásról, jelezni, ha megszakadt a kapcsolat. A kapcsolat megszakadása főleg a kliens szempontjából fontos. A kiszolgáló számára a kliensek számontartása fontosabb, hogy tudja kik csatlakoztak hozzá és kinek mely információkat kell lekérdeznie és továbbítania

27 Nem elhanyagolható az üzenetváltás sebessége sem. Lényeges, hogy ne kelljen sokat várni az adatok lekérdezésétől azok megérkezéséig. Néhány, például 2-5 másodperces késés már kevésbé használhatóvá teheti a monitorozó rendszert. A fenti elvárásoknak eleget tesz a WebSocket technológia, amely kétirányú kapcsolatot biztosít egyetlen TCP socket-en keresztül alacsony fejlécforgalommal, ezzel is segítve a gyors üzenetváltást WebSocket A WebSocket protokol a HTML5 részeként jött létre, kétirányú üzenetkapcsolatot biztosít egyetlen socket kapcsolaton keresztül a kliens és a szerver között. A WebSocket 2011 óta szabvány (RFC6455), ami leegyszerűsíti a kétirányú webes kommunikációt és kapcsolatkezelést. Segítségével sokkal gyorsabb üzenetváltás valósítható meg, mint az eddigi hasonló megoldásokkal http alapon, 2byte adat küldése 150ms-ről 50ms-ra csökken a WebSocket használatával. Lehetővé válik a valós idejű, eseményvezérelt webes alkalmazások készítése a fölösleges hálózati forgalom csökkenése mellett. A WebSocket használható tűzfalakon és proxy-kon keresztül is. Egyszerre több klienssel tartja a kapcsolatot a szerver. Lehetőséget biztosít, az egyénenkénti és a csoportos válaszadásra a kliensek felé. [30] 23. ábra WebSocket vázlat [30]

28 5.6.2 Üzenetek a kiszolgáló és a kliens között Az alkalmazás indulásakor automatikusan létrejön a kapcsolat a kiszolgálóval és fut a jelzések keresése. Egyszerű szöveges üzeneteket küldenek egymásnak. A kapcsolat felépülése után azonnal küld egy üzenetet a központi kiszolgálónak, amellyel bejegyzi magát a kliensek listájába: HELLO@@[személy_azonosító]##[személy_neve] Jelenleg ez csak a megjelenítést segíti, hogy a kiszolgálón olvasható legyen a mobil klienst használó személy neve. A későbbiek folyamán a személy neve helyett egy jelszót fog küldeni a kliens, amellyel megfelelő jogosultsággal jelentkezhet be a folyamatirányító rendszerbe a központi kiszolgálón keresztül. Amikor egy jelzés felismerése, értelmezése megtörtént létrejön egy objektum, amely az alkalmazás WebSocket kliensén keresztül kérést küld a kiszolgálónak a saját azonosítójával: REG@@[mérőhely_azonosító] Ennek hatására a központi kiszolgáló felveszi a jelzést a lekérdezendő jelzések listájára, hozzárendeli a nevét és adatokra vár. GET@@[mérőhely_azonosító] A WebSocket kliens gondoskodik arról, hogy ez az üzenet másodpercenként ismétlődjön, ameddig a jelzés objektuma él a rendszerben. A kiszolgáló ezen kérésekre küldi el a már lekérdezett adatokat. A kiszolgáló erre válaszként elküldi a megfelelő adatokat a kliensnek: DATA@@[mérőhely_azonosító]@@[mérőhely_neve]##[mérőhely_állapota]@@ [adat]##[mértékegység] Az adat-mértékegység páros többször ismétlődhet, az első három helyen a legfontosabb adatokat kell szerepeltetni, ezeket rajzolja az alkalmazás közvetlenül a felismert kódra. Hiányos adatok esetén csak a kitöltött részeket jeleníti meg az alkalmazás. Amikor egy jelzés 8 másodperc után sem kap új pozíció adatokat, vagyis a QR-kódja nem került felismerésre, törlődik a listából, amelyet a kliens a kiszolgáló felé az alábbi üzenettel jelez: UNREG@@[mérőhely_azonosító]

29 5.7 Felhasználói felület és működés Ahogy a 24. ábra mutatja, az alkalmazás a jelzések fölé egy-egy kört rajzol, amelyen megjelennek a technológiára jellemző folyamatosan frissített valós idejű információk. 24. ábra Illusztráció az felhasználói felületről Információ a jelzések fölött Egy-egy információs buborékon megjelenik a mérőpont neve, az állapota és legfeljebb 3 mért adat. Az adatokat a kliens kérdezi le másodpercenként, de ez az idő változtatható. A képernyőn bármilyen QR-kód helye megjelenik alapértelmezetten N/A felirattal. Ekkor bekerül a hozzátartozó információs buborék objektuma egy listába. Az objektum tartalmazza a QR-kódból kiolvasott információt, a képernyőn elfoglalt helyének középpontját és egy adatstruktúrát, amely feltöltésre vár. Az objektum létrejöttekor regisztrálja magát a WebSocket kliensnél, aki másodpercenként a listát bejárva elküldi a kéréseket a kiszolgálónak és folyamatosan várja a választ. A beékezett válaszokban található azonosító alapján interface-en keresztül beírja az adatokat az objektumba. Amíg az adatok nem íródnak be addig N/A jelzés látható az információs buborékban, beírás után a mérőpontra jellemző információk jelennek meg. Tehát a WebSocket kliens a listájában lévő információs buborékokat időközönként lekérdezi

30 Az információs buborékok életciklusa a felismeréssel kezdődik, amikor létrejön a hozzájuk tartozó objektum és bekerül az alkalmazás listájába. A listát folyamatosan kirajzolja az alkalmazás. Mivel nem minden előnézeti képen sikerül minden jelzést felismerni, ezért az információs buborék objektumoknak van egy minimális láthatósági ideje, ez 2 másodperc. Minden felismert objektum legalább 2 másodpercig megjelenik a képernyőn. Ez alatt a felismerés sikerességétől függően frissül a pozíciója. A lágyabb mozgás érdekében nem azonnal az új pozícióra ugrik át, hanem átlagolással átúszik az új helyére. A kirajzolt információs buborék 2 másodperc után nem törlődik azonnal, hanem csak a láthatósága szűnik meg. Ezt követően még 6 másodpercig kapja az információt. Egy információs buborék összesen legalább 8 másodpercig tartózkodik a listában a felismerést követően, ez az az eset, amikor csak egyetlen egyszer sikerül azt a QR-kódot felismerni. A további láthatatlan állapotra azért van 25. ábra Jelzés és rajta az információs buborék 26. ábra Az információs buborék életciklusa

31 szükség, hogy ha valaki pásztázik, akkor ne kelljen újra új objektumot létrehozni, hanem csak a láthatóságát megváltoztatni és azonnal a friss információkkal jelenik meg újra az információs buborék. A 2 és 6 másodperc tapasztalati úton került meghatározásra, a további tesztek és használat folyamán valószínűleg még változhat. Ha 8 másodpercig nem frissül egy információs buborék pozíciója, akkor az objektuma törlődik a listából, ezzel a WebSocket kliens listájából is törlődik, nem kerül lekérdezésre tovább a hozzátartozó információ. Az információs buborékok mérete igazodik hozzájuk tartozó QR-kódok méretéhez, de van egy minimális méretük, mert ha túl kicsi a képen a QR-kód, akkor olvashatatlanná válhat a megjelenített információ. Maximális mérete az előkép, vagyis a képernyő pixelben mért mérete A bővebb információs buborék Mivel az alap információs buborékokon csak minimális és fontos információk jelennek meg, ezért szükség van arra, hogy egy-egy mérőpontról további információ jelenjen meg. Ezt a mérőpont információs buborékának megérintésével lehet elérni. Az érintést követően a kiválasztott információs buborék egy teljes képernyős mezőt nyit magának, amelyen minden, a mérőponthoz tartozó információ megjelenik folyamatosan frissítve. Mi történik ilyenkor az információs buborékok életciklusában? A kiválasztott buborék ekkor kitüntetett szerepet kap, nem kerül ki a listából akkor sem, ha a QRkódja nem látható a kameraképen, a többiek pedig végigmennek a cikluson és törlődnek a listából. Ezzel az is lehetővé válik, hogy ha egy nehezebb gépet kell maga előtt tartania a dolgozónak, nyugodtan kényelmesebb pozícióba eresztheti az értékek elemzésének idejére. Fejlesztés alatt áll, hogy ne csak számok, hanem indokolt esetben grafikonok és egyéb grafikus elemek is megjelenjenek a teljes képernyős nézetben ezzel is segítve a gyors információszerzést a technológiáról

32 5.7.3 Beállítások panel A beállítások panelen adható meg a központi kiszolgáló címe, portja, amin figyel. Továbbá a felhasználó neve és azonosítója. A beállításokat az Android beépített Shared Preferences módszerével tárolja. Ezen a helyen az alkalmazás teljes leállítása után is megmaradnak a szükséges információk, onnan csak az alkalmazás törlésével tűnnek el. Más alkalmazások nem férnek hozzá a tárolt információkhoz csak a létrehozója, hogy ha privát módban jöttek létre a beállítások. Az alkalmazás induláskor lekérdezi a beállításokat és azoknak megfelelően indul. A telepítés utáni első indításkor ezek az információk üresek, ezért az alkalmazás kéri őket. A felhasználó nevére és azonosítójára a kiszolgálóban történő regisztrálás miatt van szükség, ez információt szolgáltat arról, hogy ki éppen melyik mérőpontnál tartózkodik, éppen használatban van-e a készülék és ki által. Később ez tényleges azonosítást fog szolgálni, a felhasználó neve helyett kódolva a jelszavát küldi el a kliens. Az azonosítás után külön jelentkezhet be az ipari rendszerbe, ezzel elérve a saját jogosultságait Az alkalmazás leállítása A Vissza gomb hatására az alkalmazás megkérdezi a felhasználót, hogy valóban ki szeretne lépni vagy sem. Ha igen, akkor elengedi a kamerát, mert ez egy osztott erőforrás az Android-ban és egyszerre csak egy program használhatja. Megszakad a kapcsolat a központi kiszolgálóval, leáll a WebSocket kliens és végül az alkalmazás is kilép. Külön kijelentkezési üzenetet nem szükséges küldeni a WebSocket kiszolgálónak, mert felügyeli a kapcsolatot és szétkapcsolás esetén a megfelelő kliensre jelzi, hogy bontotta a kapcsolatot. A kapcsolatfelvételkor az üzenet elküldése a klienst használó személy azonosítására szolgál

33 5.8 Az alkalmazás tulajdonságai és jogosultságai A alkalmazást az Eclipse Kepler fejlesztőkörnyezettel és Android SDK Tools rev. 22.3, Android SDK Platform-tools rev el fejlesztettem. Az alkalmazás minimális Android verziója: API 9, amely a Gingerbread kódnevet viseli, ezzel megegyezik a célverzió is. Az alkalmazás jogosultságai: Kamera elérés WiFi állapot lekérdezése WiFi állapot megváltoztatása Hálózat állapotának lekérdezése Hálózat állapotának megváltoztatása Internet elérés Jellemzők: kamera automata élességállítás használata. 5.9 Az alkalmazás fontosabb osztályai és kapcsolataik Az Android-ra készült vékonykliens alkalmazás 4 csomagban 9 osztályból és 3 elrendezés állományból épül fel. Csomagok: A me.akt.mear_x csomag tartalmazza az alkalmazást és az egyetlen, egyben fő Activity-t, amely a működési funkciók kezeléséért felelős: MEARActivity.java. Az me.akt.mear_x.connection csomag a központi kiszolgálóval való kapcsolattartással foglalkozik. Tartalmazza a WebSocket klienst és egy szervert [31], amely szimulált adatokat küld bemutató módban az alkalmazásnak. Ezeken kívül két interface-t tartalmaz, amellyel a kliens közli az állapotát és a kapott adatot. ARWebScoketClient.java a WebSocket kliens osztálya. ARWebScoketServer.java a szimulált adatokat küldő belső szerver. IMarkerData.java a jelzéshez tartozó fogadott adatokat közvetítő interface. ISocketClient.java a kliens állapotüzeneteit közvetítő interface. Az me.akt.mear_x.data csomagban egy osztály van, amely a jelzéshez tartozó adatokat fogadja, tárolja: DetectedMarker.java

34 Az me.akt.mear_x.views csomag a képernyőelemeket és az eseményeiket közvetítő interface-eket tárolja. ShowCamera.java a beépített kamera élőképét jeleníti meg. ARView.java a virtuális adatok megjelenítését végzi. IMarkerTouched.java az ARView-n érintéssel kiválasztott információs buborékhoz tartozó interface MEARActivity Az alkalmazást indító és egyetlen Activity-je. Implementálja az IMarkerTouched és az ISocketClient interface-eket. Az Activity kényszerítetten fekvő nézetben jelenik meg, címsor nélkül tehát teljes képernyőn és a készülék forgatására vagy billentyűzetről érkező kérésre nem változtat irányt és csak egy példányban futhat egyszerre, amíg az alkalmazás előtérben van a képernyő nem kapcsolhat ki automatikusan. Induláskor betölti az activity_mear.xml elrendezést, amely FrameLayout-on tartalmazza teljes méretben alul a ShowCamerat, fölötte pedig az ARView-t. Lefoglalja a kamerát, kiválasztja a hátlapi kamerát és átadja a ShowCamera-nak. Ellenőrzi az előzetesen tárolt beállításokat, ha azok léteznek, felhasználásukkal 27. ábra MEARActivity osztály

35 elindítja az ARWebSocketClient-et. Ha nem léteznek, kéri az adatokat. Miután kész, elindítja az ARView-n a QR-kódok keresését is. Az alkalmazás készen áll, ha sikeres a csatlakozás a kamerakép látszik ellenkezőleg Offline vagy Hibás csatlakozás felirat a kamerakép előtt az ARView-n. Felüldefiniálja az Activity állapotváltozására vonatkozó metódusokat: onpause(), onresume(). Ezek az alkalmazás indításakor, leállításakor vagy háttérbe küldésekor szükségesek, elengedni illetve újra lefoglalni a kamerát, leállítani vagy újra elindítani a WebSocketClient-et. A Kapcsolat menü eléréshez szükséges felüldefiniálni az oncreateoptionsmenu(menu m) metódust és a kiválasztott elem kezeléséhez az onoptionsitemselected(menuitem m) metódust. A Kapcsolat menü egy párbeszédablakot nyit meg, amelyben egysoros EditText képernyőelemekben lehet rögzíteni a felhasználó azonosítóját, nevét, a központi kiszolgáló címét (ez lehet IP vagy tartománynév, a WebSocket ellenőrzi a helyességét) és elérési portját a portot rögzítő mező csak számot fogad el. Az egyes mezők úgynevezett HintText-et tartalmaznak üres állapotukban, ezzel jelezve, hogy oda mit kell írni. A Csatlakozás gomb megnyomása után az aktív kapcsolatot bontja, majd újra építi a bevitt adatokkal majd újra elindítja a QR-kódok keresését. Az onbackpressed() felüldefiniált metódus a vissza gomb megnyomásakor aktiválódik, ha meg van nyitva egy párbeszédablak, akkor azt bezárja. Ha nincs, akkor a program leállítását végzi el: elengedi a kamerát, leállítja a klienst (ha fut, akkor a szervert is), kéri az Activity leállítását majd leállítja a programot. Így biztosan nem marad még egy ideig a háttérben, mire a rendszer automatikusan leállítja. A markertouched(detectedmarker dm) metódus az IMarkerTouched interface felüldefiniált metódusa. Az ARView-n a megérintett információs buborékhoz tartozó adatokat adja át (DetectedMarker típusú referencia a kiválasztott buborékhoz). Ekkor létrejön egy párbeszédablak, címsorban az információs buborék nevével, a tartalmi rész a detailedview.xml állomány alapján TextView képernyőelemek függőleges LinearLayout elrendezésben görgethető ScrollView-ba ágyazva. A szöveges elemek tartalmát egy felhasználói interface szálban futó háttérszál (SelectedMarkerRefresher belső privát osztály, a Thread leszármazottja) frissíti másodpercenként a DetectedMarker típusú objektum alapján

36 A connected(string msg), message(string msg), connectionerror(string msg), disconnect(string msg) metódusok az ISocketClient interface felüldefiniált metódusai, a kliens állapotüzeneteit közvetítik és az üzenet az ARView-n is megjelenik. A QR-kódok olvasása csak élő kapcsolat mellett aktív ShowCamera osztály Az osztály a ViewGroup leszármazottja. Csak az élő kamerakép megjelenítéséért felelős. Létrehoz egy SurfaceView képernyőelemet és hozzáadja a ViewGroup-hoz. A SurfaceView képernyőelem egy külön háttérszálról frissíthető gyors megjelenítést támogató elem. Általában ezt szokták Android rendszerben használni a számításigényes grafikák megjelenítésekor. Jellemzője, hogy nem szerencsés egynél többet elhelyezni a képernyőn és nem szabad ScrollView-ba helyezni. Ha a fenti két eset közül legalább egy bekövetkezik, akkor kirajzolási hibák jelennek meg a képernyőn. 28. ábra ShowCamera osztály Példányosításakor, ha kész az objektum, lekérdezi a méretét (onmeasure(int w, int h) metódus) és a getbestpreviewsize(int w, int h, Paramteters param) metódus segítségével meghatározza a képernyőre legjobban illeszkedő kamera előnézeti képméretet. Ha kisebb vagy nagyobb az előnézeti képméret, akkor elmosott lesz a látott kép, ha nem megfelelő az oldalarány, akkor fekete csík látszik a képernyő szélén vagy torzult kép látható a kijelzőn. A túl kicsi felbontás a QR-kód felismerő algoritmus dolgát is ellehetetleníti vagy túlzottan nagy felbontás esetén lelassítja a működését. Az alkalmazás működése alatt folyamatosan fut az élőkép

37 5.9.3 ARView Az ARView a View leszármazottja, implementálja az PreviewCallback (a kamerától) és az ontouchlistener (Android rendszerből az érintést figyelő) interfacet. Feladata összetett. Az információs buborékok és a rajta lévő adatok kirajzolását végzi, kapcsolatot tart a felhasználóval. A PreviewCallback metódus akkor hívódik meg, amikor új képkocka érkezik a kamerától. Ha engedélyezett a kódok keresése, akkor ezt megkapja a QR-kód értelmező és kódokat keres rajta, amelyeket egy tömbben ad vissza a helyükkel és a kiolvasott adattal. A hely a pixelben mért helyet jelenti, ebből számolja ki a program a QR-kód középpontját. Ez ellenőrzést és több számolást igényel, mert a kód elforgatott helyzetétől függően változik a három vagy négy sarkának a koordinátája. QR-kód 2-es verzió és 2-es modell esetén négy sarokról beszélhetünk. Mivel ez változó ezért az eljárás csak a három fő tájékozódási pont koordinátája alapján számol. A középpont meghatározása után szükség van a QR-kód képen elfoglalt szélességére is. Az olvashatóság megtartása érdekében ellenőrzi, hogy egy minimális szélességnél ne legyen kisebb a szélesség értéke. Ennek az információs buborék 29. ábra ARView osztály kirajzolásakor lesz jelentősége

38 Ez alapján (középpont koordinátája, szélesség, jelzés azonosítója) jön létre egy DetectedMarker típusú objektum, amely bekerül egy ArrayList-be. Illetve a kód regisztrálásra kerül a WebScoketClient-ben. Ellenőrzésre kerül az felismeréskor, hogy a jelzés benne van-e már a listában. Ha igen, akkor csak a pozíció és szélesség értékek kerülnek frissítésre. A kirajzolás a View-ból örökölt ondraw(canvas c) metódus felüldefiniált törzsében történik. Ha engedélyezett a kódok keresése és vannak a listában megtalált kódok, akkor sorra veszi őket a metódus, ami látható, abból kiolvassa az adatokat, amelyek az információs buborékba kerülnek: buborék által fedett terület neve, helye, mérete, ami meghatározza, mekkora kört kell a pontra rajzolni és az első két adat így egy buborékban három sor jelenik meg: a neve és két adat. Ellenőrizni kell, hogy az szövegek kiférnek-e a buborékra, ha túl hosszú, akkor jelenleg csonkolásnak esik áldozatul a kiírt szöveg. Megoldás előtt álló feladat, hogy fényreklámhoz hasonlóan görgesse a túl hosszú elnevezéseket a program. A szöveg a buborékkal együtt átméreteződik a kód méretének megfelelően. Az adatok kirajzolása után szükséges egy ellenőrzés, hogy mely jelzéseket kell láthatatlanná tenni vagy törölni a listából, mert túl régen nem került frissítésre a pozícióinformációja. Illetve azt is itt ellenőrzi, hogy mely jelzés került megérintésre. A megfelelő jelzést ekkor halhatatlanná kell tenni és átadni az IMarkerTouched interface-en keresztül az egyedi megjelenítésre. Ekkor a többi jelzés 2 másodperc múlva eltűnik, mert leáll a további keresés is. Ekkor a felhasználónak nem kell tovább maga előtt tartani a táblagépet, a kiválasztott jelzés értéke részletesen látszik teljes képernyőn egy görgethető listában. A MEARActivity-ben leírt párbeszédablak ekkor jelenik meg. Bezárható a képernyő bármely a párbeszédablakon kívüli megérintésével vagy a vissza gombbal. A bezáráskor újra elindul a kódok keresése és az információ buborékok kirajzolása. A setmessagedisconnected(string msg) és a setmessageconnected(string msg) metódusok a WebSocketClient állapotüzeneteit adják át az ARView-nak és kapcsolják a megfelelő állapotba

39 5.9.4 DetectedMarker A DetectedMarker osztály tárolja a jelzésekhez tartozó adatokat. Implementálja az IMarkerData interface-t. Példányosításakor szükséges információk: a QR-kódból kiolvasott jelzés azonosítója, helye és mérete a képernyőn és egy időbélyeg. Az osztályt az ARView példányosítja és elhelyezi egy ArrayList-ben. A listában tárolt példányokat egyszerre használja az ARView és a WebSocketClient. Előbbi a tárolt adatok megjelenítése miatt főként olvassa, felismert QR-kód esetén frissíti a pozíció információkat. Utóbbi az érzékelők adataival tölti fel az azokat tároló ArrayList-et. Az érzékelők adatait String tömbben adat-mértékegység párosban tárolja. A pozíció frissítése a setmarkerpos(float centrectx, float centrecty, float wrect, long timestamp) metódus segítségével lehetséges. A String tömböket tartalmazó Iterator-al visszatérő getmarkerdata()metódus a feltöltött adatok kinyerését valósítja meg az adatmértékegység párosokat tartalmazó ArrayList-ből. 30. ábra DetectedMarker osztály Az isdatafilled() boolean értékkel visszatérő metódus arról ad információt, hogy az objektum megkapta-e már a távoli szervertől az adatokat

40 Amennyiben nem, addig az N/A, mint nem érhető el rövidítés látható. Ha egy jelzést nem ismer a rendszer, akkor ez a felírat marad látható. Az isshown() boolean értékkel visszatérő metódus az információs buborék láthatóságát mondja meg, ha 2 másodpercig nem volt pozíciófrissítés, akkor nem látható a jelzés. Az isalive() boolean értékkel visszatérő metódus arról ad visszajelzést, hogy az adott DetectedMarker típusú objektumot életben kell-e még tartani. Amennyiben 8 másodpercig nem frissült a pozíció információ, tehát ennyi ideig nem került leolvasható állapotba a megfelelő QR-kód, akkor az objektum törlődik. Ekkor nem csak az ARView listájából, hanem az ARWebSocketClient frissítési listájából is. A setselected(boolean selected) metódus segítségével örökéletűvé lehet tenni az információs buborékot. Ez akkor áll igaz értékre, amikor a felhasználó kiválasztja a jelzést részletes nézetben való megjelenítésre. Utóbbi hat metódust az ARView hívja meg rendszeresen a kirajzolás folyamán. A datarecieved(string msg[]) metódus az IMarkerData implementált interface felüldefiniált metódusa. Az ARWebSocketClient-től érkezik rajta keresztül az adat-mértékegység páros, amelyet a DetectedMarker hozzáad a saját markerdata ArrayList-jéhez, illetve az információs buborék által jelölt mérőpont nevét. Ha a név nem létezik a Névtelen felirat jelenik meg a buborékon ARWebSocketClient Ez az osztály a központi kiszolgálóval WebSocket-en keresztül tartja a kapcsolatot. A WebSocketClient osztály leszármazottja [31], felüldefiniálja az ősosztály onopen(handshake sh), onmessage(string st), onclose(int i, String string, boolean bln), onerror(exception excptn)visszatérési érték nélküli metódusokat, amelyek a kapcsolattal kapcsolatos eseményeket közvetítik. Sorban a következőket: kapcsolat létrejött, üzenet érkezett a WebSocket szervertől, a kapcsolat lezárult, hiba lépett fel a kapcsoaltban. Az onopen(handshake sh), onclose(int i, String string, boolean bln), onerror(exception excptn) metódusok az ISocketClient interface-en keresztül továbbítják az állapotot az alkalmazás felé. Az onmessage(string st) által a String típusú objektumban átadott üzenetet azonosítás után, amely a DATA@@

41 kezdő karaktersor azonosítását és levágását követően karakter párok mentén String tömbbe darabolt üzenetet az IMarkerData interface-en továbbítja a DetectedMarker megfelelő objektumának. A megfelelő objektum kiválasztása úgy történik, hogy a DATA@@ rész levágása és darabolás után keletkezett tömb első eleme a jelzés azonosítója, amelyhez az adatok tartoznak. Az osztály tartalmaz egy HashMap-et, amelynek a kulcsai a jelzések azonosítói, értékei pedig az IMarkerData interface-ek. Tehát a kulcs keresése után már adott, hogy a név, adat-mértékegység párokat melyik jelzésnek kell átadni. 31. ábra ARWebSocket osztály A jelzéseket az addimarkerdatalistener(imarkerdata md, String markerid) lehet regisztrálni az ARWebSocketClient-ben. Az elévült jelzések a removeimarkerdatalistener(string markerid) metódussal lehet törölni a HashMap-ből. Ezeket a metódusokat az osztály statikus metódusain keresztül lehet

42 elérni: addimarkerdata(imarkerdata md, String markerid) és removeimarkerdata(string markerid). A jelzés felismerésekor a sendmarkerregmessage(string markerid) statikus metódussal lehet regisztrálni a központi kiszolgálónál, ekkor a WebSocket kliens send(string msg) metódusa hívódik meg és küldi el a REG@@[azonosító] üzenetet. A jelzés elévülésekor a sendmarkerunregmessage(string markerid)statikus metódussal lehet az előzővel megegyező módon az UNREG@@[azonosító] üzenettel törölni a jelzés regisztrációját. A kapcsolat felépülésekor a sendhello(string user, String id) statikus metódus az előző két statikus metódussal megegyező módon küldi el a HELLO@@user##id üzenetet a központi kiszolgálónak. Az osztályt a connect(string address, int port, String user, String id)string visszatérésű statikus metódussal lehet éleszteni. Ekkor létrejön az osztály saját WebSocketClient példánya csatlakozik a megadott paraméterekkel a WebSocketServer-hez, amely a központi kiszolgálóban fut, a kapcsolat felépülésekor elküldi a hello üzenetet. Ezt követően kell átadni a kapcsolat állapotát figyelő ISocketClient interface-t a setisocketclient(isocketclient is) statikus metódussal. A kliens elindít egy háttérszálat is, amely másodpercenként elküldi a GET@@[azonosító] üzenetet a központi kiszolgálónak a HashMap-ben lévő jelzések azonosítójával. A kapcsolatot a void disconnect() statikus visszatérési érték nélküli metódussal lehet bontani, amely szabályosan bontja a WebSocket kapcsolatot és leállítja a háttérszálat

43 6 A központi kiszolgáló A központi kiszolgáló lényegében átjáróként és adatbázisként működik a rendszerben. Kapcsolatot tart a kliensekkel és az ipari szerverrel, a kliensek által küldött azonosító alapján lekérdezi az érzékelők adatait és továbbítja a kérésnek megfelelő kliensnek. Számon tartja az aktív klienseket. Ezen kívül elvégezhető rajta a QR-kódok generálása és bennük kódolt azonosító összerendelése a technológia érzékelőivel. A központi kiszolgálót Java nyelven, NetBeans IDE 7.2 alatt fejlesztettem, Java SDK 1.7 fejlesztő környezettel. Futtatásához a Java futtató környezet (JRE) 1.7-es változata szükséges. 6.1 Kapcsolódás az ipari rendszerhez Az alkalmazás a tanszéki DeltaV DCS rendszeren kerül majd tesztelésre, amely OPC szerver OPC DA klienseket képes kiszolgálni. A kapcsolódáshoz Java alapú nyílt forrású OPC klienst kerestem, amely integrálható a központi kiszolgálóba. A fejlesztés alatt a Matrikon OPC Simulation Server-t [32] használtam Windows XP rendszeren futtatva. Ez a szimulált adatokon kívül tartalmaz egy univerzális klienst, amellyel akár más OPC szerverről is lekérdezhető az adat, összehasonlítható a saját programban megjelent értékekkel Az OPC kapcsolat [33] Az OPC nyitott szabvány (OLE for Process Control, OLE Object Linking and Embedding) 1996-ban jelent meg először. Célja, hogy a PLC protokollok egy egységes felületen keresztül folyamatosan és torzítatlanul legyenek elérhetőek. Az OPC-nek két fontos eleme van, az OPC szerver és az OPC kliens. Az OPC szerver kapcsolatban áll a terepi műszerekkel és egy jól definiált felületen keresztül biztosítja az összegyűjtött adatok elérését az OPC kliensek számára. Az OPC kliensek az OPC szerver által biztosított adatok felhasználói OPC kapcsolat fajtái [33] OPC DA: Data Access, amely adatelérést tesz lehetővé, értékek, idő és minőség információk lekérdezését

44 OPC AE: Alarm and Events, amely az alarm és esemény típusú üzenetek cseréjét írja le. OPC HDA: Historical Data Access, lekérdezési eljárásokat és elemzéseket határoz meg, amelyek időbélyegzett adatokhoz használhatóak. OPC UA: Unified Architecture, egy platform független szolgáltatásorientált architektúra, amely a fentebb felsorolt leírásokat egyesíti UTGARD - OPC DA kliens [34] Az openscada részeként készült nyílt forrású, ingyenes, tisztán Java nyelven írt OPC kliens, amely jelenleg csak OPC DA 2.x hozzáférést támogat. Használható az openscada-tól függetlenül is. A tisztán Java nyelv azt jelenti, hogy nem tartalmaz JNI (Java Native Interface) állományokat. Ennek köszönhetően bármilyen Java-t futtatni képes rendszeren használható a program külön fordítása nélkül. Tehát a központi kiszolgáló az UTGARD OPC DA kliens segítségével kapcsolódik a tanszéki OPC szerverhez. 6.2 QR-kódok generálása és összerendelése az érzékelőkkel A QR-kódokat a kiszolgáló a ZXing csomag segítségével generálja és menti el PNG (Portable Network Graphics) formátumba. A PNG egy veszteségmentes tömörített formátum, amely kezeli az átlátszóságot és gamma korrekciót. Ezek a nyomtatásnál játszhatnak fontos szerepet. Az azonosító nevek minimális hossza 12 karakter, mert a QR-kód generátor legalább ilyen hosszúságú szöveg esetén készít 2-es típusú kódokat. Az ilyen kódok 32. ábra Központi kiszolgáló, jelzések tartalmaznak egy negyedik a összerendelése dekódolást segítő vonatkozási pontot (az információ növekedésével további vonatkozási pontok jelennek meg)

45 A minimális 12 karakter, amely betűk és számok tetszőleges kombinációja lehet, már számos mérőpont egyedi azonosítására elegendő. Túl hosszú azonosítót sem szabad választani, mert tapasztalat szerint a több adat miatt nagyobb méretű és sűrűbb kódok olvasása problémás lehet nagyobb távolságból vagy fényszegény környezetben. A karakter hosszúságú kódok könnyen, gyorsan és elég éles szögből olvashatóak a kliens alkalmazás számára. Az elkészült QR-kód megjelenik a kijelzőn, ha megtörtént az összerendelés helyben ki is próbálható, hogy a kívánt adatok jelennek-e meg a mobil készülék kijelzőjén. A kész kódokat a program a saját könyvtárában tárolja, az Exportálás gombbal a kívánt helyre menthető. (32. ábra) A QR-kódban kódolt azonosítóhoz tartozó OPC címeket egy XML állományban tárolja, amely formátuma a következő: <?xml version="1.0" encoding="utf-8"?> <markers> <marker> <id>mérőpnt_azonosító</id> <name>mérpont_neve</name> <sensor> <sid>opc_cím</sid> <sunit>mértékegység<sunit> </sensor> </marker> </markers> A marker és a sensor tag-ek ismétlődnek a jelzések és a megjeleníteni kívánt érzékelők számának megfelelően

46 6.3 Kapcsolattartás a kliensekkel A kliensekkel a kapcsolatot a WebSocket szervere tartja. Amikor egy kliens elküldi a kérését, a kiszolgáló feljegyzi a mérőpont azonosítóját és az összerendelés alapján lekérdezi az ipari szerverről az értékeket. Az adatok megérkezésekor összeállítja a csomagot és továbbítja a kérést kezdeményező kliensnek. 33. ábra Központi kiszolgáló, kliensek listája Emellett egy listában megjeleníti, hogy mely kliensek elérhetőek a rendszerben, illetve éppen mely mérőpontokat kérdezik le. Ez információt ad arról, hogy a felhasználók merre mozognak a gyár területén. 6.4 A központi kiszolgáló előnye A központi kiszolgáló segítségével megoldható az is, hogy egy mérőponthoz más értékeket jelenítsen meg például érzékelő csere esetén vagy abban az esetben, ha mégsem az az érték szükséges, amelyet eredetileg az információs buborék megjelenít. A központi kiszolgáló váza (grafikus felület, WebSocket szerver, QR-kód generátor) állandó maradhat a különféle rendszerekhez könnyen alakítható, ha az ipari rendszerrel való kapcsolatért felelős csomagot kicseréljük így szinte bármilyen rendszerhez illeszthető a kiterjesztett valóság rendszer

47 6.5 A programot alkotó osztályok és kapcsolataik A program a me.vau.mear.* csomagban található. 9 csomagban 15 osztályból, 5 interface-ből és 3 kivételosztályból áll a program. Három nagy részre tagolható: grafikus felület kapcsolattartás a kliensekkel kapcsolattartás az OPC szerverrel Az ezeket a jelzéseket tartalmazó adatbázis kapcsolja össze, egy almodul a QR-kód generáló osztály. Csomagok és osztályok: A me.vau.mear csomag az egész programot magában foglaló csomag. Itt található az indító fő osztály: MEARX.java: Az alkalmazást indító főosztály. MEARProperties.java: Az alkalmazás beállításainak a kezelését végzi. Elmenti, illetve betölti azokat egy config.xml állományból. Ha még nem létezik, akkor létrehozza. IMainControls.java: A MEARX.java osztály interface-e, amellyel a közli a különböző állapotait. ISplashControl.java: A MEARX.java osztály interface-e, amellyel az indításkori állapotokat írja a betöltő (úgynevezett splash screen-re) képernyőre. A me.vau.mear.gui csomag osztályai a grafikus felületeket és a hozzájuk tartozó interface-eket tartalmazzák: SplashGUI.java: A betöltő képernyőt jeleníti meg. Kiírja az alkalmazás nevét, alatta állapotüzenet, alatta végtelenített folyamatjelző mutatja, hogy még az alkalmazás betöltése zajlik. MainGUI.java: A 32. ábra és a 33. ábra által mutatott grafikus felületet kezelő osztály. Létrehozza és frissíti, kezeli az állapotait. IGControls.java: A MainGUI.java eseményeit továbbító interface

48 A me.vau.mear.clients csomag a távoli kliens adatstruktúráját és az általa olvasott jelzés adatstruktúráját tartalmazza: ARClient.java: A távoli kliens bejelentkezésekor jön létre belőle egy példány, amely a kijelentkezésig marad a rendszerben. Számon tartja hány és melyik jelzéseket olvassa a távoli kliens. ARMarker.java: A távoli kliens által leolvasott jelzés regisztrálásakor jön létre belőle egy-egy példány jelzésenként. Tárolja a jelzés azonosítóját, a megjelenítendő adatokat. A me.vau.mear.marker csomag a helyi jelzések adatainak nyújt struktúrát és a hozzájuk tartozó adatbázist kezeli: Marker.java: A jelzés adatait tárolja helyben. Minden élő QR-kódhoz létrejön belőle egy példány. MarkerDataBaseManager.java: A helyi jelzések adatait olvassa fel illetve írja ki XML állományba. Az adatbázisban található QR-kódoknak megfelelő számú Marker objektumot tartalmaz egy HashMap-ben. ezek lekérdezhetőek, szerkeszthetőek, törölhetőek és új jelzés is hozzáadható a listához. A me.vau.mear.opc csomag osztályai az ipari rendszerrel való kapcsolatért felelősek. Jelenleg egy alcsomagja van, amely az Utgard OPC kliens csomagját tartalmazza: MearOpcConnection.java: Absztrakt osztály, amely a különböző kapcsolati osztályokhoz biztosít egységes felületet az alkalmazásnak. IOpcDataListener.java: Az ipari kiszolgálótól érkezett adatokat közvetítő interface. OpcConnectionErrorException.java: Az ipari kiszolgálóhoz történő kapcsolódás során felmerült hibákat jelzi

49 Alcsomagja a me.vau.mear.opc.utgard, OPC DA kliens az Utgard külső csomagból: UtgardOPC.java: Az OPC DA kliens, amely csatlakozik az ipari kiszolgálóhoz. DataCallBackDumper.java: Adat érkezésekor ez az osztály figyel és értelmezi a kapott adatot a következő osztály segítségével: VariantDumper.java: A beérkezett adatot értelmezi, kinyeri belőle, hogy mely tag adata, milyen típusú és ez alapján meghatározza az értékét. A me.vau.mear.qr.zxing csomag a QR-kódok generálásáért felelős. ARQrCodeGenerator.java: A kapott paraméterek alapján előállítja a kívánt QR-kódot és az előre megadott tároló mappába menti az azonosítónak megfelelő névvel. QrCodeIsExistException.java: Kivétel, amely akkor dobódik, ha a QR-kód már létezik a tároló mappában. QrCodeTextTooShortException.java: Kivétel, amely a 12 karakternél rövidebb azonosítóra figyelmeztet. A me.vau.mear.webconn csomag osztályai a kliensekkel biztosítják a kapcsolatot WebSocket-en keresztül: MWebSocketServer.java: Az osztály figyel a hálózaton, fogadja a kliensek csatlakozását és a rendelkezésre álló adatokat továbbítja feléjük. ISocketServer.java: A WebSocketServer.java osztály állapotait és üzeneteit továbbítja az alkalmazás felé

50 6.5.1 MEARX osztály Az alkalmazás a MEARX osztállyal indul, ez az indító fő osztály. Implementálja az ISocketServer és IGControls interface-eket. 34. ábra MEARX osztály Induláskor elkészíti a saját példányát, elindítja az üdvözlő ablakot, amely az adatok betöltésének idejére tájékoztatást ad az éppen zajló folyamatokról. Betölti, felépíti a jelzések adatbázisát. A jelzések helyét a MEARProperties osztály határozza meg, ha nem található a beállításokat tartalmazó állomány vagy a QR-kódokat és az adatbázist tartalmazó mappa, akkor létrehozza őket és üresen indul az alkalmazás. A betöltést követően a fő képernyőt, a MainGUI-t indítja el és használhatóvá válik az alkalmazás

51 Ez az osztály jelenti a kapcsolatot az egyes komponensek között. Számon tartja melyik jelzés van kiválasztva a grafikus felületen, jelzi és kezeli a WebSocketServer és az OPC kliens állapotát, ezt továbbítja a grafikus felület felé. Betöltés vagy módosítás után számon tartja a jelzések adatbázisának a helyét, ahonnan a kiválasztott kódhoz tartozó képet felolvassa és továbbítja a grafikus felületnek megjelenítésre. Elindítja a QR-kód generálását és kezeli az utána szükséges eseményeket. Saját metódusai, amelyek nem interface-ektől származó metódusok felüldefiniálása: void loaddatabase(): tájékoztatja az üdvözlő ablakot az adatbázis betöltéséről és elindítja a MarkerDataBaseManeger.loadMarkerDataFromXML() metódust. A feladat befejezésével tájékoztatja az üdvözlő képernyőt a feladat befejezéséről. void setimc(imaincontrols imc): Az IMainControls interface referenciáját állítja be a MEARX példányában. void setsplascontrol(splashgui splashgui): Az üdvözlő képernyő interface referenciáját állítja be. void startload(): A betöltés kezdetét jelzi az üdvözlő képernyőnek. void stopload(): A betöltés végét jelzi az üdvözlő képernyőnek. void fillmainguimarkerlist(): A fő grafikus ablaknak adja át a helyi jelzéseket tartalmazó adatbázist a megfelelő lista feltöltésére. Az IGControls interface felüldefiniált metódusai, a grafikus felület felől érkező parancsok: void addnewmarkertodatabase(string qr_id): Amikor egy új QRkód elkészült az azonosítója bekerül az alkalmazás adatbázisába. Ezután a grafikus felületen frissül az elérhető QR-kódok listája

52 editmarker(string id, String name, int x, int y): A szerkesztett QR-kódhoz tartozó nevet és pozíció értékeket írja felül. Utóbbiak a későbbi fejlesztéshez tartoznak, amikor az alkalmazás kijelzi azt is, hogy melyik dolgozó a gyár területén merre mozog. void deletemarker(string id): Törli a QR-kódot az adatbázisból a bejegyzéseivel együtt és a létrehozott képállományt is. void addsensorstomarker(string tag): Amikor egy jelzéshez új érzékelőt rendel a felhasználó, azt az OPC tag alapján rögzíti az adatbázisba és a QR-kódhoz tartozó érzékelők listát frissíti. void delsensorstomarker(string tag, String unit): Törli a QR-kódhoz rendelt tag-et majd frissíti a hozzárendelt érzékelők listáját. String connect(string ip, int port): A MWebServer-t indítja el az adott IP címmel és porttal. Ha az indítás sikeres null értékkel tér vissza egyébként hibaüzenettel. void disconnect(): Az előző ellenpárja, leállítja az MWebserver-t, ha fut. String generateqrcode(string qr_id): Új jelzést generál és visszatér az elkészült képállomány nevével. Marker getmarkerforedit(string id): Azonosító alapján visszaadja a kért jelzés objektumának referenciáját, amelyből kiolvashatók a szerkesztésre betöltött információk. String getqrstorepath(): Visszaadja a QR-kódokat tartalmazó mappa elérési útvonalát. void setqrstorepath(string path): Beállítja a kitallózott mappa útvonalát, ahol majd a QR-kódokat tárolja a program. String selectedmarker(string id): Beállítja a kiválasztott jelzést és visszatér az azonosítójával, ami alapján kijelölt állapotba kerül a jelzések listáján a megfelelő sor. void savemarkerdatabase(): Kiíródnak a jelzések adatbázisa egy állományba

53 String opcconnect(string ip, String host, String progid, String username, String userpassword): A szükséges adatokkal létrehozza az OPC kapcsolatot. void opcdisconnect(): Bontja az élő OPC kapcsolatot. Az ISocketServer interface felüldefiniált metódusai: void userloggedin(hashtable<websocket, ARClient> clients, WebSocket conn, String id, String username): A csatlakozott új klienst megjeleníti a bejelentkezett kliensek listájában és frissíti a csatlakozott kliensek számát. void clientloggedout(hashtable<websocket, ARClient> clients, WebSocket conn, ARClient ac): A lecsatlakozott új klienst törli a bejelentkezett kliensek listájából és frissíti a csatlakozott kliensek számát. void newmarkerrecieved(hashtable<websocket, ARClient> clients, WebSocket conn, ARMarker am): Az adott klienshez megjeleníti az éppen olvasott jelzés nevét. void markerdeleted(hashtable<websocket, ARClient> clients, WebSocket conn, ARMarker am): Az adott kliens mellől törli a már elévült jelzés nevét

54 6.5.2 SplashGUI A betöltő képernyő a JFrame osztály leszármazottja implementálja az ISplashControl interface-t. Feladata, hogy jelezze a betöltés folyamatát, a program indulásakor jelenik meg az adatbázis méretétől függően hosszabb vagy rövidebb ideig. Rajta megjelenik jelenleg az alkalmazás neve, alatta szöveges információ az éppen feldolgozás alatt álló adatokról és alatta egy végtelenített folyamatjelző. Később a sima szöveg helyett az alkalmazás logója jelenik meg ebben az ablakban. 35. ábra SplashGUI osztály Jelenlegi állapotai: elindult a betöltés (startload()), adatbázis betöltése folyamatban (startloaddatabase()), adatbázis betöltése kész (readyloaddatabase()), betöltés kész (stopload()). A végén az ablak bezárul

55 6.5.3 MainGUI Az alkalmazás főképernyője a JFrame leszármazottja. Implementálja az IMainControls interface-t, amelyen keresztül a MEARX osztály utasításait és adatait fogadja. Fő részei: Szerver állapot: WebSocket szerver csatlakozási adatai, a csatlakozott kliensek száma és a kapcsolat létrehozására, bontására használható gomb. Futó szerver esetén a gomb háttérszíne zöldre vált. OPC kapcsolat: OPC csatlakozási adatok és az előzővel megegyező gomb. Ezek alatt egy lapfüles felület, jelenleg két lapfüllel: Kliensek, ahol megjelenik a csatlakozott kliens neve, azonosítója, az éppen olvasott jelzések azonosítója egy táblázatban. Jelzések kezelése: Ezen a felületen balról jobbra haladva egy listában jelennek meg az OPC szerveren elérhető tag-ek egy fában. Mellette fentről lefelé a középső oszlopban a kiválasztott QR-kód képe (nem csak látványelem, tesztelésre is használható), a rendszerben elérhető QR-kódok listája a kiválasztott kóddal, a jelzések törlésére és a tároló mappa helyének megadására szolgáló gomb. Törléskor a kiválasztott jelzést teljesen törli a rendszerből. Mellette a harmadik oszlopban fentről lefelé a jelzés azonosítója olvasható (innen ki is másolható a jelzés neve). Alatta a jelzés szerkesztésére szolgáló gomb, ekkor egy párbeszédablak jelenik meg a szerkeszthető szövegmezőkkel, amelyek a már felvitt adatokkal feltöltve jelennek meg. Alatta az új jelzés létrehozására szolgáló gomb, amely egy párbeszédablakot dob fel ahová begépelhető vagy beilleszthető a jelzés neve. Itt zajlik a név hosszának ellenőrzése is. Alatta listában a társított OPC tag-ek a mértékegységükkel, ha kitöltött. Mentés gomb amivel az adatbázis xml állományba írható a QR-kódkat tartalmazó mappába. A Töröl gomb a kiválasztott társított OPC tag-et törli a társítás listából

56 Saját metódusai: void initcomponents(): A fejlesztőkörnyezet által generált metódus, a felület felépítésére szolgál. static MainGUI mainguistart(igcontrols gc): A felület elindítására szolgáló metódus, amely egyúttal átveszi az IGControls interface referenciát. Visszatér a statikus változóba példányosított saját referenciájával, hogy átadható legyen a hívó osztály interface-ének. Az IMainControls interface felüldefiniált metódusai: void userloggedin( String id, String username, int numofclients): A Kliensek lapfül táblázatába új sorként beszúrja rendre a felhasználó azonsosítóját (id), a felhasználó nevét (username) és létrehoz még egy oszlopot, ahová majd az éppen olvasok jelzések azonosítója kerül. A Szerver állapot rész Kliensek száma szövegmezőbe beírja a kliensek számát (numofclients). 36. ábra MainGUI osztály

57 void userloggedout(arclient ac, String clientid, int numofclients): Az előző ellentétes metódusa, törli a klienshez tartozó egész sort a táblázatból és beírja a kliensek új számát a szövegmezőbe. void newmarkerrecieved(string clientid, ARMarker am): Befűzi a táblázat utolsó oszlopába a kliens azonosítójának megfelelő sorba az újonnan olvasott jelzés azonosítóját. void markerdeleted(string clientid, ARMarker am): Az előző ellentétes metódusa, törli az utolsó oszlop megfelelő sorából a már nem olvasott jelzés azonosítóját. void fillmainguimarkerlist(string[] markeridarray): Feltölti a jelzéseket tartalmazó listát a középső oszlopban a Jelzések kezelése fülön. void setselectedmarkerqrcode(file file): A QR-kód képét tartalmazó File objektumot adja át a grafikus felületnek, amiből az felolvassa a képet és átméretezi a megjelenítési terület méretének megfelelően, majd kirajzolja. void filltagtomarkerlist(string[] pairedtagstomarker): A jelzésekhez rendelt OPC tag-ek listáját frissíti. void fillmainguitagtree(vector<string> arr): Az OPC kliens által visszaadott elérhető OPC tag-ek listáját írja az első oszlop fájába. A működés többi része a MEARX osztály leírásánál került részletezésre, az IGControls interface leírásánál. A IGContorls metódusai az alábbi események hatására hívódnak meg (az alkalmazás képét lásd: 50. ábra): void addnewmarkertodatabase(string qr_id): Kattintás az Új jelzés párbeszédablak OK gombján. Ha helytelen a név újra kéri a név beírását. editmarker(string id, String name, int x, int y): A Szerkeszt gomb hatására megnyíló párbeszédablak OK gombjára való kattintás után kerül hívásra ez a metódus. void deletemarker(string id): A Jelzés törlése gombra kattintás hatására hívódik meg

58 void addsensorstomarker(string tag): A Hozzáad >> gomb váltja ki ezt az eseményt. void delsensorstomarker(string tag, String unit): A Töröl X gombra kattintás által kiváltott esemény. String connect(string ip, int port): A fenti Szerver állapot területen található Indít gombra kattintva indul el a WebSocket kiszolgáló. void disconnect(): Az előző ellenpárja, ekkor a gomb zöld és Elindítva felirattal jelzi a kiszolgáló állapotát. A gombra kattintva indul a kiszolgáló leállítása. String generateqrcode(string qr_id): Kattintás az Új jelzés. párbeszédablak OK gombján. Ha helytelen a név újra kéri a név beírását. Marker getmarkerforedit(string id): A Szerkesztés gombra kattintva kéri a kiválasztott jelzés adatait. String getqrstorepath(): A Jelzések helye gomb megnyomását követően hívódik meg, hogy a böngészőablak megnyílásakor az éppen használt mappánál nyíljon meg. void setqrstorepath(string path): A Jelzések helye gomb megnyomását követően, ha van kiválasztott mappa a fájlböngészőben, akkor a megnyitás gombra kattintás után állítja be az útvonalat (amikor bezárul a fájlböngésző ablaka). String selectedmarker(string id): Egy jelzésre kattintáskor a Jelzések listában állítja be a MEARX osztályban a kiválasztott jelzést az aktuálisra. Ellenőrzésként visszatér a kiválasztott jelzés azonosítójával. void savemarkerdatabase(): A Mentés gombra kattintás váltja ki az eseményt. String opcconnect(string ip, String host, String progid, String username, String userpassword): Az OPC kapcsolat területen az Indít gombra kattintás váltja ki az eseményt. A megfelelő adatokat a területen található szöveg beviteli mezőkből olvassa ki a program. void opcdisconnect():az OPC kapcsolat területen az Elindítva gombra kattintás váltja ki az eseményt

59 6.5.4 MEARProperties A MEARProperties osztály statikus metódusokból áll, amelyek írják vagy olvassák a config.xml állományt. 37. ábra MEARProperties osztály A PR_QR_STORE_LOCATIOON változó a QR-kódok tároló mappa helyének a kulcsa. A CF_APP_CONFIG a config.xml állomány nevét tartalmazza. A config.xml állomány a program mappájának a gyökerében jön létre, ha még nincs ott. A writeproperty( ) metódusok vagy egyszerre több vagy egyszerre egy tulajdonságot írnak a config.xml-be. A String readproperty(string filename, String prop) metódus visszaolvas egy tulajdonságot. A getqrstorepath() visszatérési értékben String objektumban adja meg a QR-kódokat tároló mappa helyét. A setqrstorepath(string path) beállítja a QR-kódokat tároló mappa helyét. Utóbbi két metódus a writeproperty( ) és readproperty( ) metódusokat használja fel megfelelő paraméterekkel

60 6.5.5 MWebServer Az MWebServer a WebSocketServer [31] leszármazott osztálya. Az ISocketServer interface-en keresztül tartja a kapcsolatot a külvilággal, jelen esetben a MEARX osztállyal. A szerver indítása a void setserverparameters(string serverip, int serverport) és void sstart(final ISocketServer isocketserver) statikus metódusokkal lehetséges, előbbi átadja a szükséges paramétereket, mely IP-n és porton figyeljen, utóbbi pedig háttérszálban elindítja a figyelést. A kapcsolat megszakítása a void sstop() metódussal történik, amely leállítja a háttérszálat. Az ISocketServer-nek a referenciát a void setserverlistener(isocketserver is) metódussal kapja meg. Az osztály a kapcsolatokat egy HashMap-ben tárolja, ahol a kulcsérték egy WebSocket típusú objektum az érték pedig ARClient típusú objektum. Az ősosztályból felüldefiniálja a void onopen(websocket conn, ClientHandshake handshake), void onclose(websocket conn, int code, String reason, boolean remote), void onmessage(websocket conn, String message), void onerror(websocket conn, Exception ex) metódusokat. Az onmessage(websocket conn, String message) metódus akkor hívódik meg, ha egy kliens üzenetet küld. A conn paraméterben a kliens kapcsolati adatai, a message paraméterben az üzenet érkezik. Az üzenet fogadásához az osztály tartalmaz String konstansokat, amelyek a megfelelő üzenetfejet tartalmazzák. Az üzenet fogadásának lépései: Ellenőrzi, hogy az üzenet a GET_MESSAGE, HELLO_MESSAGE, REG_MESSAGE, UNREG_MESSAGE konstans által tartalmazott String-gel kezdődik-e. Ha bármelyik megfelel, levágja az üzenet fejét a konstans értéknek megfelelően és az üzenet tartalmához igazodva folytatja a feldolgozást:

61 o HELLO_MESSAGE: Szétosztja a maradék üzenetet a ## karakterpár mentén és új elemet helyez a HashMap-be, ahol a kulcs az aktuális WebSocket lesz az érték pedig egy újonnan példányosított ARClient objektum. Az ISocketServer interface void userloggedin(hashtable<websocket, ARClient> clients, WebSocket conn, String id, String username) metódusán keresztül a grafikus felületen is megjelenik a csatlakozott felhasználó. o REG_MESSAGE: A maradék üzenet a jelzés azonosítója, amelyet a kliens kiolvasott a QR-kódból. A megfelelő ARClient-hez hozzáadódik egy ARMarker, amelynek az azonosítója beérkezett. Tájékoztatni kell a grafikus felületet is, hogy új jelzés áll olvasás alatt a: void newmarkerrecieved(hashtable<websocket, ARClient> clients, WebSocket conn, ARMarker am)metódussal az interface-n keresztül. o UNREG_MESSAGE: A maradék üzenet a jelzés azonosítója, amely már elévült, régóta nem frissült a kliensben a pozíciója. A megfelelő ARClient-ből törlődik az ARMarker, ezzel az adatainak a lekérdezése is megszűnik. Az interface void markerdeleted(hashtable<websocket, ARClient> clients, WebSocket conn, ARMarker am) metódusán keresztül a grafikus felületről is eltűnik az elévült jelzés. o DATA_MESSAGE: A maradék üzenet a jelzés azonosítója, amely alapján a megfelelő ARClient kívánt ARMarker-ének String getdata() metódusát hívja. A visszatérési értékben összerakja a kliensnek küldendő üzenetet, amely az [érték]##[mértékegység] karaktersorral elválasztva tetszőleges számban ismétlődhet. Az üzenet elejét kiegészíti a DATA@@ karaktersorral és elküldi a kliensnek

62 Az void onclose(websocket conn, int code, String reason, boolean remote) metódus a kapcsolat megszakadása vagy lezárásakor hívódik meg. Ekkor a conn paraméter szerinti ARClient az ARMarker-ekkel együtt törlődik a rendszerből és az interface void clientloggedout(hashtable<websocket, ARClient> clients, WebSocket conn, ARClient ac) metódusával a grafikus felületről is törlődik a kliens. 38. ábra MWebServer osztály ARClient Az ARClient osztály a kliens adatait tartalmazza: a felhasználó azonosítóját, felhasználónevét és az éppen olvasott jelzéseket, amelyeket egy HashMap-be gyűjt. A kulcs jelzés azonosítója értéke pedig ARMarker. Példányosításkor szükség van a felhasználónévre és a felhasználó azonosítójára. A konstruktorban létrejön a HashMap is üresen a szöveges adattagok beállítása után. A void addmarker(string markerid, ARMarker ma) metódussal HashMap-hez adódik egy új ARMarker objektum és hozzáadódik az interface- e az OPC kapcsolathoz, hogy megkezdődhessen az adatainak a lekérdezése. Az ARMarker getmarker(string markerid) metódus visszatérési értékben adja a markerid-nek megfelelő ARMarker objektumot

63 A Enumeration getmarker(int markernum) visszatérési értékben adott Enumeration objektum segítségével bejárható az összes tárolt ARMarker. Az ARMarker removemarker(string id) eltávolítja a HashMap-ből az id-nek megfelelő ARMarker-t és visszatérési értékben visszaadja. Ezzel egy időben értesíti az OPC kapcsolatért felelős osztályt is, hogy ezt az ARMarker-t már nem kell lekérdezni. A String getclientid() és String getclientuser() metódusokkal lekérhetők az ARClient által reprezentált kliens neve és azonosítója. A void removeallmarkers() metódus egyenként eltávolítja a HashMapből az ARMarker-eket és értesíti az OPC kapcsolatért felelős osztályt, hogy melyeket ne kérdezze már le. 39. ábra ARClient osztály ARMarker Az ARMarker a kliens által lekérdezett jelzések szerver oldali megfelelő objektuma. Implementálja az IOpcDataListener interface-t, amelyen keresztül kapja a frissített adatokat. Az ARMarker objektumok csak az ARClient HashMap-jében léteznek a rendszerben. Az ARMarker létrejöttéhez csak a jelzés azonosítójára van szükség. A konstruktorban ekkor létrejön egy Vector<String[]>, amely az adat-mértékegység párosokat tartalmazza, a MarkerDataBaseManager megfelelő Marker objektumából itt kerül feltöltésre még adatok nélkül. Az ARMarker nevét szintén a MarkerDataBaseManager segítségével állítja be az adatbázisból. A void addmarkerdata(string tag, String data, String unit) metódussal az adott OPC tag adatát lehet beírni az ARMarker adatlistájába. Mivel a

64 Vector sorrendtartó ezért a grafikus felületen kialakított sorrendben fogja az adatokat továbbítani a kliensnek. Ennek köszönhetően megadható prioritási sorrend a jelzések adatsorára, vagyis az, hogy melyiket jelenítse meg előbb, a fontosabbakat előbbre lehet helyezni. Ez a metódus arra is képes, ha olvasás közben módosul az értéklista vagy a mértékegység, akkor az azonnal módosul a kliensnél is. 40. ábra ARMarker osztály A String[] getnextelement() metódus a kiolvasott elemet törli a listából. A String getmarkerid(),string getmarkername(),void setmarkername(string markername) metódusokkal az ARMarker azonosítóját lehet lekérdezni illetve a nevét lekérdezni vagy megváltozatni. A String getdata() metódus összeállítja a küldésre kész adatot és visszaadja egy String-ben. Az IOpcDataListener interface metódusai az adatok feltöltéséhez: A void setdata(string tag, String data, String unit) metódussal az OPC kliens tölti fel a megfelelő adattal az ARMarker-t. A void removealldata() metódussal el lehet távolítani az adatokat az ARMarker Vector-ából

65 6.5.8 MarkerDataBaseManager A MarkerDataBaseManager a QR-kódok és OPC tag-ek összerendelési listáját menti el és tölti vissza az adatbázisként használt XML állományt használva. Magában tart egy Hashtable-t, amelyben a Marker típusú adattároló objektumok kapnak helyet. A QR-kódok tároló mappájában helyet foglaló armarkers.xml nevű állomány felolvasásakor tölti fel a Hashtable-t, amelynek kulcsértéke a Marker azonosítója, értéke a Marker. 41. ábra MarkerDataBaseManager osztály Az osztály szolgáltatásai statikus metódusokon keresztül érhetők el. A void setmarkerdatafilepath(string path) metódussal beállítható a tárolómappa helye. A void addmarker(marker ma) metódus egy új Marker-t ad a Hastablehöz

66 Az int getmarkercount() metódussal lekérdezhető mennyi Marker-t tárol éppen az adatbázis. A void removeallmarkers() metódus eltávolítja az összes Marker-t az adatbázisból, de az XML-ből nem. Az Enumeration<Marker> getmarkeriterator() segítségével egyszerűen bejárhatóak az elérhető Marker-ek. A Marker getmarker(string id) metódus az id-nek megfelelő Marker-t adja vissza. A String[] getmarkeridarray() metódus egy String tömbben adja vissza az elérhető Marker-ek azonosítóinak a listáját. A String[] getpairedtagstomarker(string mid) metódus az midnek megfelelő Marker-hez tartozó OPC tag mértékegység párokat adja vissza String tömbben. A tömb egyes elemei a következő formátumúak: opctag/mértékegység. A Marker removemarker(string id) metódus törli az id-nek megfelelő Marker-t a Hashtable-ből. A void writemarkerdatatoxml() metódus kiírja a Hashtable tartalmát a 6.2. fejezetben bemutatott formátumban. A void loadmarkerdatafromxml() metódus felolvassa az armarkers.xml állományt SAX értelmező segítségével és feltölti a Hashtable-t Marker objektumokkal

67 6.5.9 ARQrCodeGenerator A QR-kódok generálását a ZXing csomag [29] segítésével az ARQrCodeGenerator osztály egyetlen statikus metódusa végzi. A String createqrimage(string qrfile, String 42. ábra ARQrCodeGenerator osztály és a kivételei qrcodetext)metódus paraméterben megkapja a kódok tároló mappájának helyét (qrfile) és a kódolandó azonosítót, amelynek legalább 12 karakter hosszúnak kell lenni, hogy a kívánt QR-kód verzió és modell generálásához. A kódok 2000*2000 pixel méretű png típusú képekként kerülnek mentésre. Már létező QR-kód esetén saját QrCodeIsExistException kivételt dob, ha nincs 12 karakter hosszú az azonosító, akkor QrCodeTextTooShortException saját kivételt dob a metódus. Visszatérési értéke az elkészült állomány teljes elérési útvonala

68 MearOpcConnection A MearOpcConnection egy absztrakt osztály, amely funkciói statikus metódusokon keresztül érhetők el. Egy MearOpcConnection típusú változót tartalmaz, amely egy leszármazott osztályt tartalmazhat, amely megvalósítja az OPC vagy egyéb kapcsolatot. A leszármazott felüldefiniálja az absztrakt metódusokat, amelyeket a szülő osztály statikus metódusain keresztül egységes felületen lehet használni a programban. Ez azért szükséges, hogy könnyen cserélhető legyen az ipari kiszolgálóhoz kapcsolódó osztály. Az osztály tartalmaz két Hashtable-t. Az egyik kulcsa String típusú az ARMarker azonosítója, értékei IOpcDataListener típusúak, változó neve: armarkerdatalistener. Ezeken keresztül lehet feltölteni az ARMarker-ek adat Vectorait. A másik kulcsa szintén String, a lekérdezendő OPC tag neve, az értékek pedig String[]-ök, amelyek azon ARMarker-ek azonosítóit tartalmazzák, amelyeknek szükségük van a lekérdezendő OPC tag értékére, változó neve: tagstopoll. Az osztály statikus metódusai: Az osztály inicializálása a void setcontext(mearopcconnection conn) metódussal valósul meg. Itt kell átadni a leszármazott osztály referenciáját. A String connect(string serverhost, String serverdomain, String serveruser, String serverpassword, String opcprogid) metódussal felépíthető a kapcsolat. A void disconnect() metódus lecsatlakozik az ipari szerverről. A Vector<String> tagnames() metódus lekérdezi az elérhető tag-ek neveit az ipari szerverről. A void addtagtopoll(string tag, ARMarker marker) metódus egy új elemet ad a lekérdezési listába. Ekkor az ARMarker azonosítója beíródik a tagstopoll változónevű Hastable-be. A void removepolltag(string tag) eltávolítja a leszármazott osztály lekérdezési listájából az adott OPC tag-et. A static void valuerecieved(string tag, String value) metódus a beérkezett adathoz keresi meg azokat az ARMarker-eket, amelyek feliratkoztak rá és feltölti őket az adattal

69 A void addiarmarker(armarker ma, String markerid) metódus új ARMarkert regisztrál a lekérdezési és figyelő listába. A static void removeiarmarker(string id) eltávolítja az id azonosítót birtokló ARMarker-t a listából. A void removealltagsfromconnect() metódus minden OPC tag-et eltávolít így megszűnik a szerver lekérdezése. Az alábbi absztrakt metódusokat kell a leszármazott osztálynak megvalósítani, hogy a fentebb felsorolt funkciók működőképessé váljanak: String connecttoopc(string serverhost, String serverdomain, String serveruser, String serverpassword, String opcprogid) void disconnectopcserver() Vector<String> gettagnames() void addtagtopoll(string tag) void removetagtopoll(string tag) void removealltags() 43. ábra MearOpcConnection osztály

70 UtgardOpc Az OPC kapcsolatot megvalósító osztály az UtgardOpc [34], a MearOpcConnection osztály leszármazottja. Megvalósítja az ősosztály abstract metódusait. Az OpcConnectionErrorException saját kivételosztály, amelyet hiba esetén dob. Az másodpercenként lekérdezett adatok feldolgozását a DataCallbackDumper és a VariantDumper osztályok végzik. 44. ábra UtgardOPC osztály DataCallbackDumper és VariantDumper A DataCallbackDumper osztály az UtgardOPC által folyamatosan lekérdezett tag-ek beérkező adatait értelmezi. A pontos adattípust és ebből az értéket a VariantDumper állítja elő. Jelen esetben formázott String-ként adja vissza, amellyel a DataCallbackDumper adattal tölti fel az ARMarker-eket a valuerecieved( ) metóduson keresztül. 45. ábra Az OPC kapcsolat kis osztályai

71 7 Elvárások a kihelyezett jelzésekkel szemben A kihelyezett QR-kódok esetében nagyon fontos a jó olvashatóság a kamera szempontjából. Az olvashatóságot meghatározza a kliens kamerájának minősége, az élőkép mérete, a kihelyezett jelzések környezetének fényviszonyai, a jelzést hordozó felület tulajdonságai és a jelzés mérete, mely befolyásolja a leolvasási távolságot. A jelzést hordozó felülettel szembeni elvárás, hogy matt legyen, ne csillogjon, ragyogjon rajta a környező fényforrások fénye, mert a kamera nem képes a túl nagy fényerőkülönbséget kezelni és meghiúsul a felismerés. A jelzés mérete azt határozza meg, hogy milyen távolságból lehet leolvasni a kódot. 150x150 mm-es jelzést jó látási viszonyok mellett 3-4 méter távolságból felismer az alkalmazás egy átlagos hátoldali kamerával. Ez az esetek többségében elegendőnek bizonyul. Továbbá a jelzést nem feltétlenül muszáj közvetlenül az érzékelő közvetlen közelébe helyezni, ha annak mért adatai kissé távolabb való megjelenítése sem ad okot a félreértelmezésre. Elhelyezhető egy közeli kényelmesen leolvasható pontra is. Tapasztalatunk szerint, ha a jelzés bár matt, jól látható felületen van, akkor is előfordulhat, hogy nem képes a készülék értelmezni. Ennek oka a vibráló fény. Bár ipari környezetben erre egyébként is külön figyelmet fordítanak, de előfordulhat, hogy olyan közel van egy fénycsöves világítótesthez, hogy vibráló fény éri a jelzést. Erre és a sötét helyen elhelyezett jelzésre is megoldás a saját LED-es fényforrás, amely szemből megvilágítja a jelzést. Fontos elvárás, hogy a jelzés síkfelületen legyen elhelyezve ezzel is növelve az olvashatóságát a kamera számára. Mivel a merőleges megfigyelés nem elvárható ezért az oldalról történő megfigyelés miatt a síkfelületre elhelyezett jelzés eleve torzítva fog megjelenni a kamera képén, de ha egy viszonylag egyenes jelzés megy át a torzuláson, azt még az algoritmus fel fogja ismerni. A QR-kód akkor ismerhető fel biztosan, ha a kód körül van egy homogén és lehetőleg világos keret, amelynek a szélessége legalább 4 négyzetnyi az adatterületen található négyzetekből. [25]

72 8 Hogyan működik a rendszer? 8.1 A központi kiszolgáló használata A központi kiszolgáló számára alapkövetelmény, hogy a számítógép, amelyen futtatják, hálózati kapcsolatban legyen az OPC szerverrel és telepítve legyen a Java futató környezet (JRE) legalább 7-es verziója. A központi kiszolgálót telepítést nem igényel, a program mappájában található MEAR-X_server.jar állománnyal indítható. 46. ábra A központi kiszolgáló indító képernyője Az induláskor elvégzett műveletek folyamatáról egy indító képernyő tájékoztat alul úszó hullámokkal és szöveggel (46. ábra)

73 8.1.1 A főablak alapállapotban 47. ábra A főablak alapállapotban indulás után Az indulás után a főablak üresen jelenik meg (47. ábra), a mezők kitöltése után az Indít gombra kattintva lehet elindítani a klienseket figyelő szervert és az OPC klienst. Ekkor a gomb színe zöldre vált. Újra rákattintva leállítható a szerver. A Szerver állapot Port mezője azt a portot adja meg, ahol a szerver figyeli a kliensek csatlakozását. Az itt megadott portot kell megadni a kliensek beállításainál is. A Kliensek száma nem módosítható, az éppen csatlakozott kliensek számát mutatja. Az IP mezőbe a központi kiszolgálót futtató számítógép IP címét kell írni, amelyet elérhetnek a kliensek. Az Indít gombra kattintva elindul a figyelés. Az OPC kapcsolatnál szintén meg kell adni az OPC szerver IP címét az OPC IP mezőben. A Host mező kitöltése nem kötelező, az OPC szerver host neve írható ide. A ProgID az OPC szerver azonosítója például Matrikon.OPC.Simulation.1. A Felhasználó és Jelszó mezőkbe az OPC szervert futtató számítógéphez szükséges bejelentkezési adatok írhatók. Az Indít gombra kattintva néhány másodperc után a

74 gomb színe zöldre vált jelezve a helyes kapcsolódást vagy hibaüzenet jelenik meg a képernyőn. A gomb újbóli megnyomására a program bontja a kapcsolatot. A 48. ábra a Jelzések kezelése panel indítás utáni állapotát jelzi, amikor még nem él semmilyen kapcsolat. 48. ábra A Jelzések kezelése panel indítás után

75 8.1.2 A főablak élő kapcsolattal A kapcsolati adatok feltöltése és a kapcsolatok indítása után a 49. ábra szerinti képet lát a felhasználó. Az ábrán már látszik, hogy egy csatlakozott felhasználó is megjelent, olvasható az azonosítója, neve és az éppen megfigyelt jelzések azonosítója. 49. ábra Élő kapcsolatok és egy csatlakozott felhasználó A 50. ábra a Jelzések kezelése panelt mutatja, amikor már van élő OPC kapcsolat. Jobb oldalt az OPC Szerver területen láthatók milyen tag-eket hirdet a szerver. Ezek közül lehet tetszőleges számút hozzárendelni egy-egy jelzéshez a Hozzáad>> gombbal. Középen a Jelzések listája fölött az éppen kiválasztott jelzés képe látható. A lista alatt jelzés törlésére szolgáló Jelzés törlése gomb. Megnyomására a kiválasztott jelzés teljesen törlődik a rendszerből. Alatta a Jelzések helye gomb látható, melynek hatására egy fájlböngésző ablakban adhatjuk meg, hol tárolja a program a generált QR-kódokat és az adatbázisát. A bal oldali oszlopban a jelzés azonosítója olvasható, ebből a mezőből az érték kijelölhető,

76 másolható. Alatta a Szerkeszt gomb látható, amellyel a jelzésnek nevet lehet adni. Ez alatt az Új jelzés gombbal egy új jelzés generálható a legalább 12 karakter hosszú azonosítójának megadásával. A Társítot OPC tag lista a jelzéshez társított OPC tag-et és a beírt mértékegységet mutatja az éppen kiválasztott jelzéshez. A legalsó Töröl X gombbal ezeket lehet törölni. Fölötte a Mentés gombbal minden, a jelzéseken elvégzett változás menthető a merevlemezre. 50. ábra Jelzések kezelése élő kapcsolat esetén

77 A jelzések és az adatbázisuk helyét a Jelzések helye gombra kattintva lehet megadni. Ha nincs külön megadva, akkor a program gyökérkönyvtárában egy QRStore nevű mappában tárolja a QR-kódokat. Ez azért fontos, mert az elkészült jelzéseket a kihelyezésük előtt ki kell nyomtatni. A jelzések fájlneve megegyezik az azonosítójukkal. (51. ábra) 51. ábra Jelzések tároló mappájának megadása A jelzések nyomtatásához használt hordozóra vonatkozóan, a QR-kódok méretének megválasztásában és olvashatóságuk biztosítására segítséget nyújt a 7. fejezet. használható. A rendszer csak a QR-kódok nyomtatását és kihelyezését követően

78 8.1.3 Új jelzés felvétele Az Új jelzés gombra kattintva a megnyíló párbeszédablakban felvehető az új jelzés azonosítója, amelynek legalább 12 karakter hosszúnak kell lennie, tetszőleges karaktereket tartalmazhat. (52. ábra) 52. ábra Új jelzés felvétele Az OK gombra kattintva az új jelzés megjelenik a Jelzések listában. Kiválasztva a listában és a Szerkeszt gombra kattintva nevet is lehet adni a jelzés által megjelenített mérőpontnak. Amíg a Jelzés neve mező nincs kitöltve, a 53. ábra Jelzés elnevezése kliensek az információs buborékban a Névtelen szöveget jelenítik meg. Az OK gombra kattintva a név hozzáadódik az adatbázishoz

79 8.1.4 OPC tag-ek rendelése a jelzéshez, mértékegység megadása Az elkészült jelzés még üres. A kliensek már felismerik, kiírják a megadott nevet, de egyéb értékeket még nem jelenít meg. Működő OPC kapcsolat esetén az OPC szerver listából a kiválasztott elemet a Hozzáad >> gombbal lehet a jelzéshez rendelni, amit az 54. ábra mutat. 54. ábra OPC tag hozzárendelése a jelzéshez Az információs buborékban az első két elem fog megjelenni. A Társított OPC tag listában a kiválasztott soron az egér jobb gombjával kattintva megadható a megjelenítendő mértékegység. (55. ábra) 55. ábra Mértékegység megadása

80 8.2 A kliensek használata Az alkalmazás nem igényel aktív WiFi kapcsolatot, mert 3G kapcsolaton keresztül is képes igény esetén egy Interneten keresztül elérhető központi kiszolgálóval kommunikálni. Ha belső WiFi hálózaton érhető el a központi kiszolgáló, akkor a mobil eszközön előbb a megfelelő WiFi hálózathoz kell kapcsolódni. Az alkalmazás futtatásához a mobil eszközön lennie kell legalább VGA felbontású hátoldali kamera. Ezzel közelről felismerhetőek a jelzések, ajánlott a legalább 800*480 pixel élőkép biztosítására képes kamera. Az alkalmazás indítása a MEAR-X nevű ikonra bökéssel történik. Ekkor, ha sikeres a csatlakozás, akkor a kamera élőképe látható, ha egy jelzés a kamera látóterébe kerül, akkor azon megjelenik az információs buborék. Sikertelen kapcsolódás esetén Offline vagy Hiba a kapcsolatban szöveg olvasható. Ekkor az Android menü gomb megnyomásakor a Csatlakozás menüpontot kiválasztva párbeszédablakban megadhatóak a kapcsolódási adatok. 56. ábra Kapcsoalti adatok kitöltés előtt és kitöltés után Az üres mezők kitöltését úgynevezett HintText segíti, amely az első betű beírásakor eltűnik. A Kapcsolódás gombra kattintva megszakad az addig élő kapcsolat és a beírt adatokkal új kapcsolat jön létre