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
Név:
Bartók Roland
Neptun: AQCCRH Cím:
4090 Polgár, Bajza u. 42.
2014
Tartalomjegyzék
1
BEVEZETÉS ........................................................................................ - 1 -
2
MI A KITERJESZTETT VALÓSÁG? .................................................... - 2 2.1
A MOBIL KITERJESZTETT VALÓSÁG RÖVID TÖRTÉNETE [1] .......................- 2 -
2.2
INFORMÁCIÓSZERZÉS A KÖRNYEZETRŐL ...............................................- 4 -
2.2.1 Jelzések használata.................................................................... - 4 2.2.2 A környezet sajátosságainak felhasználása ............................... - 5 2.2.3 A készülék érzékelőinek használata ........................................... - 5 2.3
NÉHÁNY NÉPSZERŰ KITERJESZTETT VALÓSÁG KERETRENDSZER .............- 5 -
2.3.1 ARToolkit [5] [10] ........................................................................ - 5 2.3.2 Vuforia [11] [12] .......................................................................... - 6 2.3.3 Metaio [13] .................................................................................. - 7 -
3
2.4
SIEMENS ÁLTAL TERVEZETT IPARI ALKALMAZÁS (2002) [14] ...................- 8 -
2.5
A BECKHOFF TANULMÁNYA GOOGLE GLASS-AL ....................................- 9 -
2.6
GOOGLE GLASS HASZNÁLATA A TURBINA KARBANTARTÁSBAN ................- 9 -
2.7
SZEMÜVEG NÉLKÜL – KITERJESZTETT VALÓSÁG RENDSZER IOS-RE......- 10 -
FEJLESZTÉSI TERV, KÖVETELMÉNYEK ....................................... - 11 3.1
A FEJLESZTÉS CÉLJA ........................................................................- 11 -
3.2
MEGOLDANDÓ FELADATOK ................................................................- 11 -
3.2.1 A platform kiválasztása ............................................................. - 11 3.2.2 Helymeghatározás, helyzet-meghatározás, azonosítás............ - 11 3.2.3 A mérőpontok adatainak valós idejű lekérdezése ..................... - 12 3.2.4 Kommunikáció .......................................................................... - 12 3.2.5 Egyéb felmerült feladatok ......................................................... - 12 4
5
A RENDSZER VÁZLATA ................................................................... - 13 4.1
A MOBIL KLIENS MŰKÖDÉSI VÁZLATA...................................................- 14 -
4.2
A KÖZPONTI KISZOLGÁLÓ MŰKÖDÉSI VÁZLATA, FUNKCIÓI ......................- 15 -
A KLIENS PROGRAM ....................................................................... - 16 -
I
5.1
OPERÁCIÓS RENDSZER ÉS HARDVER ..................................................- 16 -
5.2
A KÖRNYEZET AZONOSÍTÁSA .............................................................- 17 -
5.3
A QR-KÓD [25] ................................................................................- 17 -
5.3.1 A QR-kód rövid története .......................................................... - 17 5.3.2 A QR-kód felépítése.................................................................. - 18 5.3.3 A QR-kód fajtái ......................................................................... - 20 5.3.4 A QR-kód felhasználása [26] .................................................... - 21 5.4
QR-KÓD FELHASZNÁLÁSA A KITERJESZTETT VALÓSÁG RENDSZERHEZ ...- 21 -
5.5
A QR-KÓD AZONOSÍTÁSA, DEKÓDOLÁSA.............................................- 22 -
5.6
KOMMUNIKÁCIÓ A KISZOLGÁLÓVAL .....................................................- 22 -
5.6.1 WebSocket ............................................................................... - 23 5.6.2 Üzenetek a kiszolgáló és a kliens között ................................... - 24 5.7
FELHASZNÁLÓI FELÜLET ÉS MŰKÖDÉS ................................................- 25 -
5.7.1 Információ a jelzések fölött ....................................................... - 25 5.7.2 A bővebb információs buborék ................................................. - 27 5.7.3 Beállítások panel ...................................................................... - 28 5.7.4 Az alkalmazás leállítása............................................................ - 28 5.8
AZ ALKALMAZÁS TULAJDONSÁGAI ÉS JOGOSULTSÁGAI..........................- 29 -
5.9
AZ ALKALMAZÁS FONTOSABB OSZTÁLYAI ÉS KAPCSOLATAIK ..................- 29 -
5.9.1 MEARActivity ............................................................................ - 30 5.9.2 ShowCamera osztály ................................................................ - 32 5.9.3 ARView ..................................................................................... - 33 5.9.4 DetectedMarker ........................................................................ - 35 5.9.5 ARWebSocketClient ................................................................. - 36 6
A KÖZPONTI KISZOLGÁLÓ ............................................................. - 39 6.1
KAPCSOLÓDÁS AZ IPARI RENDSZERHEZ ..............................................- 39 -
6.1.1 Az OPC kapcsolat [33] .............................................................. - 39 6.1.2 OPC kapcsolat fajtái [33] .......................................................... - 39 6.1.3 UTGARD - OPC DA kliens [34] ................................................. - 40 6.2
QR-KÓDOK GENERÁLÁSA ÉS ÖSSZERENDELÉSE AZ ÉRZÉKELŐKKEL ......- 40 -
6.3
KAPCSOLATTARTÁS A KLIENSEKKEL ...................................................- 42 -
6.4
A KÖZPONTI KISZOLGÁLÓ ELŐNYE ......................................................- 42 -
II
6.5
A PROGRAMOT ALKOTÓ OSZTÁLYOK ÉS KAPCSOLATAIK ........................- 43 -
6.5.1 MEARX osztály ......................................................................... - 46 6.5.2 SplashGUI ................................................................................ - 50 6.5.3 MainGUI.................................................................................... - 51 6.5.4 MEARProperties ....................................................................... - 55 6.5.5 MWebServer ............................................................................. - 56 6.5.6 ARClient.................................................................................... - 58 6.5.7 ARMarker .................................................................................. - 59 6.5.8 MarkerDataBaseManager ......................................................... - 61 6.5.9 ARQrCodeGenerator ................................................................ - 63 6.5.10 MearOpcConnection ............................................................... - 64 6.5.11 UtgardOpc .............................................................................. - 66 6.5.12 DataCallbackDumper és VariantDumper ................................ - 66 7
ELVÁRÁSOK A KIHELYEZETT JELZÉSEKKEL SZEMBEN ........... - 67 -
8
HOGYAN MŰKÖDIK A RENDSZER? ............................................... - 68 8.1
A KÖZPONTI KISZOLGÁLÓ HASZNÁLATA ...............................................- 68 -
8.1.1 A főablak alapállapotban........................................................... - 69 8.1.2 A főablak élő kapcsolattal ......................................................... - 71 8.1.3 Új jelzés felvétele ...................................................................... - 74 8.1.4 OPC tag-ek rendelése a jelzéshez, mértékegység megadása . - 75 8.2 9
A KLIENSEK HASZNÁLATA ..................................................................- 76 -
MIÉRT LEHET HASZNOS EGY ILYEN RENDSZER? ...................... - 78 -
10 FEJLESZTÉSI TERVEK .................................................................... - 79 11 ÖSSZEGZÉS ...................................................................................... - 80 12 SUMMARY ......................................................................................... - 81 KÖSZÖNET ............................................................................................... - 82 FORRÁSOK .............................................................................................. - 83 MELLÉKLET ............................................................................................. - 86 -
III
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.
-1-
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.
A mobil kiterjesztett valóság rövid története [1]
2.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. 1974-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
homogén vászon előtt mozgó kesztyűt és más
1. ábra Ivan Sutherland fejre 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.
-2-
kijelzőt
Hordozható
és
kamerát
alkalmazott. A kamera képét egy közeli erős asztali munkaállomás dolgozta fel. 1996-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 Bilinghurst amely
bemutatta
mára
nagyon
az
3. ábra NaviCAM [1]
ARToolkit-et,
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 4. ábra ARToolkit [1]
vizuális jelzéseket. A játékosok egy-egy
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. 2002-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. 2006-ban objektumkövető
Reitmayr rendszert
és
csapata
mutatott
be
egy kültéri
modell
alapú
kiterjesztett
hibrid 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.
-3-
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. 2009-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).
2.2.1 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.
-4-
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.
2.2.3 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
2.3.1 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-
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
Android
platform
rendszerekből
a
is.
Az
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.
2.3.2 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.
-6-
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]
2.3.3 Metaio [13] A Metaio GmbH. a világ legnagyobb kiterjesztett valóság szoftvertechnológiát fejlesztő vállalata. 2003-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 külsőt
jelenítenek
varázsolnak
meg,
egy
új
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-
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.
Siemens által tervezett ipari alkalmazás (2002) [14]
2.4
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
Segítségével
a
is
használnak.
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
válaszolnak a PDA-n keresztül. A 2002-
8. ábra Siemens - Beszélő csövek [14]
es cikkben az kereskedelmi forgalomba helyezését 5-7 évre becsülték.
-8-
2.5
A Beckhoff tanulmánya Google Glass-al
A Beckhoff a 2013. 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.
-9-
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ó
formátumban a kliensek számára. Tapasztalatuk
11. ábra iQagent kliens
szerint 5000 jelzés létrehozása kicsit több mint egy hetet vett igénybe. [20] [21] [22]
- 10 -
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
3.2.1 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]
3.2.2 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.
- 11 -
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.
3.2.4 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.
3.2.5 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.
- 12 -
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.
- 13 -
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.
- 14 -
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.
- 15 -
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 15. ábra Z720-EX [39]
kamera gyenge minőségű, ami miatt a jelzések felismerése 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ó
- 16 -
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]
5.3.1 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
- 17 -
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 nyújtott,
tárolására
ami
nagyon
is
lehetőséget 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 még
mindig
nem
lehetett
16. ábra QR-kód olvasási irányok,
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. 1994-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. 2000 ó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.
5.3.2 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
- 18 -
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]
- 19 -
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ű.
5.3.3 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. iQR-kód: olyan QR-kód, amely
mikroméretű QR-kód [25]
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]
- 20 -
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 2es 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.
- 21 -
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.
- 22 -
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 25 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.
5.6.1 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]
- 23 -
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ó]
- 24 -
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
5.7.1 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.
- 25 -
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
25. ábra Jelzés és
másodpercig tartózkodik a listában a felismerést követően,
rajta az információs
ez az az eset, amikor csak egyetlen egyszer sikerül azt a
buborék
QR-kódot felismerni. A további láthatatlan állapotra azért van
26. ábra Az információs buborék életciklusa
- 26 -
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.
5.7.2 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.
- 27 -
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.
5.7.4 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.
- 28 -
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. 19.0.1-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.
- 29 -
me.akt.mear_x.views
Az
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.
5.9.1 MEARActivity Az
alkalmazást
indító
és
egyetlen Activity-je. Implementálja és
IMarkerTouched
az
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
betölti
az
automatikusan. Induláskor
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
ShowCamera-nak.
és
átadja
Ellenőrzi
a az
előzetesen tárolt beállításokat, ha azok
léteznek,
felhasználásukkal 27. ábra MEARActivity osztály
- 30 -
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.
- 31 -
connected(String
A
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.
5.9.2 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. Példányosításakor,
28. ábra ShowCamera osztály
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.
- 32 -
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, egy
amelyeket
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
olvashatóság
is.
Az
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.
- 33 -
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
setMessageConnected(String
msg)
metódusok
msg) a
és
a
WebSocketClient
állapotüzeneteit adják át az ARView-nak és kapcsolják a megfelelő állapotba.
- 34 -
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 centRectY,
float
setMarkerPos(float
wRect,
long
timestamp)
centRectX, metódus
float
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.
- 35 -
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.
5.9.5 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@@
- 36 -
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
- 37 -
elérni:
addIMarkerData(IMarkerData
md,
String
és
markerID)
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 send(String
kliens
msg)
metódusa
hívódik
meg
és
küldi
el
a
REG@@[azonosító] üzenetet. A
jelzés
markerID)statikus
elévülésekor metódussal
a lehet
sendMarkerUnRegMessage(String 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.
- 38 -
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.
6.1.1 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.
6.1.2 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.
- 39 -
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.
6.1.3 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.
QR-kódok generálása és összerendelése az érzékelőkkel
6.2
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
gamma
az
átlátszóságot
korrekciót.
nyomtatásnál Az
szerepet.
Ezek
és a
játszhatnak
fontos
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.
tartalmaznak
Az
egy
ilyen
kódok
negyedik
a
32. ábra Központi kiszolgáló, jelzések összerendelése
dekódolást segítő vonatkozási pontot (az információ növekedésével további vonatkozási pontok jelennek meg).
- 40 -
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 12-18 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ő: <markers> <marker>
mérőpnt_azonosító mérpont_neve <sensor> <sid>opc_cím <sunit>mértékegység<sunit>
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.
- 41 -
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.
- 42 -
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.
- 43 -
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.
- 44 -
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é.
- 45 -
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.
- 46 -
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
Az
üdvözlő
referenciáját állítja be a MEARX példányában.
void
setSplasControl(SplashGUI
splashGUI):
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.
- 47 -
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.
- 48 -
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,
clients,
WebSocket
conn,
ARMarker
ARClient>
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.
- 49 -
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.
- 50 -
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.
- 51 -
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
Visszatér
a
referenciát.
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 beszúrja
táblázatába rendre
új a
sorként
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
- 52 -
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.
- 53 -
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.
- 54 -
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.
- 55 -
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
a
referenciát
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
ClientHandshake
felüldefiniálja
a
handshake), void
void
onOpen(WebSocket
onClose(WebSocket
conn,
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:
- 56 -
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, username) metódusán
String
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]
páros
@@
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.
- 57 -
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
6.5.6 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.
- 58 -
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
6.5.7 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
- 59 -
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.
- 60 -
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.
- 61 -
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.
- 62 -
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.
- 63 -
6.5.10
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.
- 64 -
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
- 65 -
6.5.11
UtgardOpc
Az
kapcsolatot
OPC
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
6.5.12
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
- 66 -
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]
- 67 -
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).
- 68 -
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
- 69 -
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
- 70 -
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ő,
- 71 -
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
- 72 -
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. A rendszer csak a QR-kódok nyomtatását és kihelyezését követően használható.
- 73 -
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.
- 74 -
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
- 75 -
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.
- 76 -
Élő kapcsolat esetén, amikor egy QR-kód jelzés a kamera látóterébe kerül megfelelő méretben, megjelenik rajta a zöld információs buborék (Hiba! A hivatkozási forrás nem található.). A buborékra bökve a két legfontosabb értéken kívül a többi jelzéshez rendelt érték is olvashatóvá válik (58. ábra). A bővebb információs buborék az Android Vissza gombbal vagy a képernyő üres területére bökéssel eltüntethető.
57. ábra Információs buborék működés közben (teszt, véletlen értékekkel)
58. ábra A bővebb információs buborék (teszt, véletlen értékekkel)
- 77 -
9
Miért lehet hasznos egy ilyen rendszer? Ez a kiterjesztett valóság rendszer jól elhelyezett QR-kódok és megfelelően
hozzárendelt adatokkal az üzemrész azon a pontján képes megmutatni a rendszer állapotát jellemző információkat, ahol azok érvényesek. Ellentétben egy helyhez kötött HMI eszközzel, amely egy grafikán keresztül próbálja a valós eszközök működését megmutatni. Mivel helyhez kötött nem képes arra, hogy pontosan egy kívánt helyen adjon információt a rendszer működéséről. Azonban ha azon a helyen van egy QR-kód, amelyet a MEAR-X kliens felismer, akkor máris megtudhatja a karbantartó, hogy az rész jól működik-e. Az ilyen helyeket tapasztalat alapján lehet feltérképezni, hogy a személyzetet mely részek mely adatai érdeklik. Ezeket tetszőlegesen lehet hozzárendelni a QR-kódokhoz. A kódok megfelelő helyezésével pedig azok leolvasása is kényelmessé tehető. A kijelzőn már feldolgozott adatok jelennek meg úgy, ahogy az a legjobban jellemzi a rendszert, ahogy az HMI eszközön is megjelenne. Egy alkatrész működése valóságosan követhető közben azonnal leolvasható a kijelzőről a hozzá kapcsolódó valós idejű adat. Bár így minden karbantartónak, dolgozónak saját táblagépre van szüksége, az alkalmazás későbbi verzióiban elérhető olyan funkció is, amely segítséget nyújt a rendszer használatához, elérhetővé teszi a használati útmutatókat és adatlapokat a klienst használó számára. A vezetéknélküli kapcsolatnak köszönhetően nem szükséges minden klienst külön telepíteni csak az őket kiszolgáló WiFi hozzáférési pontokat, amelyek akár már telepítve is lehetnek egy modern üzem területén. Bár nem váltja ki a vezetékes telepített vezérlő állomásokat, mégis nagy segítséget nyújthat a személyzetnek akár egy probléma gyors felfedezésében. A megfelelően telepített kiterjesztett valóság rendszer képes könnyebbé tenni a rendszer monitorozását, karbantartását, ahogy ezt a közelmúltban nyilvánosságra hozott külföldi rendszerekről szóló írásokban is részletezték.
- 78 -
10 Fejlesztési tervek A legközelebbi fejlesztési terv, hogy a kliensek egymás között képesek legyenek kommunikálni. Lehetőséget biztosítva arra, hogy az éppen megjelenített adatokat a felhasználó egy másik felhasználó képernyőjére továbbítsa, és szöveges úton megbeszélhessék a problémát, gyors megoldási javaslatot kaphat az, aki a segítséget kérte. Jelenleg a kiterjesztett valóság rendszer csak passzív megfigyelést tesz lehetővé, azonban sokszor szükség lehet beavatkozásra is, egy szelep kinyitására vagy más műveletre. Ehhez meg kell oldani a felhasználó azonosítását, az esetleges jogosultsági szintek kezelését (ki avatkozhat be és melyik rendszerbe?), ha a felhasználó valahol leteszi a táblagépét, más ne vezérelhesse a rendszert. Kérdéses, hogy ekkor az alkalmazás a felhasználóra bízza a képernyő lezárását vagy valamilyen módszerrel, például a készülék mozgása, közelségérzékelő használata alapján érzékelje a tétlenséget és automatikusan lezárja a képernyőt. Egy ilyen alkalmazás nem csak megfigyelésre vagy vezérlésre használható. Nagy segítséget nyújthat a betanulás ideje alatt. Ez alatt nem csak az új munkaerőnek jelenthet segítséget, hanem a tapasztalt kollégáknak abban az esetben, ha egy új üzemrészt kell kezelniük. Az állapotinformációk mellett megjelenhet például az, hogy milyen határértékeken belül működik optimálisan a rendszer. Természetesen közben is működik a szöveges üzenetváltás a többi felhasználóval akár egy operátorral is. Karbantartási munkálatoknál külön segítséget nyújthat a rendszer, ha elnavigálja a karbantartót a hiba helyéhez. Ez több módszerrel is megoldható. Egyik, hogy a felismert jelzések alapján határozza meg a pillanatnyi helyét és ez alapján jelzi, merre van a hiba. Vagy folyamatosan a kamerakép alapján az elmozdulásból és a jelzésekből pontosan számítható merre jár a felhasználó, a térkép alapján pedig az, hogy merre kell mennie. Mivel egy 500-1000g-os készüléket is nehéz sokáig tartani ezért az alkalmazást érdemes kompatibilissé tenni olyan viselhető eszközökkel, mint a Google Glass [35] vagy az Epson Moverio [36] esetleg a Vuzix [37] kijelzővel és kamerával ellátott szemüvege. Ezáltal a felhasználó kezei szabadon maradnak, miközben ugyan úgy megjelennek előtte a kívánt információk.
- 79 -
11 Összegzés Az intelligens mobil eszközök fejlődésével egyre szélesebb körben elérhetővé válik a régóta ismert, de mégis újszerű technológia, a kiterjesztett valóság a mindennapi életben. Már jelenleg is számos kiterjesztett valóság alkalmazást lehet találni a polgári, orvosi, mérnöki, oktatási alkalmazásban. A technológia lényege, hogy egy kamera által a képernyőn vagy kijelzővel ellátott szemüvegen keresztül látott valóság kibővül virtuális objektumokkal, információkkal. Ipari alkalmazására is lehet példákat találni, főleg a modellek, CAD rendszerek térbeli objektumainak megjelenítésével. Néhány tanulmány és alaprendszer is megjelent az elmúlt hónapokban, amely egy folyamatirányító rendszer monitorozását segíti egy táblaszámítógép vagy intelligens szemüveg segítségével. A dolgozatban is egy folyamatirányításban is használható monitorozó rendszer került bemutatásra. Alapja, hogy a rendszerben bizonyos kitüntetett pontokat
QR-kódok
jelölnek,
amikor
ezek
valamelyike
a
táblaszámítógép
kamerájának látóterébe kerül, a képernyőn a QR-kód képernyőn elfoglalt helyének megfelelő helyen megjelennek olyan valós idejű információk, amelyek a technológia adott pontján érvényesek, jellemzőek. Az információkat a táblaszámítógép alkalmazása egy központi kiszolgálón keresztül kérdezi le a folyamatirányító rendszerről például OPC kapcsolaton keresztül. Az így megjelenített információk egyfajta előnézeti adatok. Az információs buborékokra bökve további adatok olvashatók ki a rendszerből, amelyek az adott mérőponthoz kapcsolódnak. Az eddig elkészült programpáros - az Android operációs rendszert futtató mobil eszközön futó kliens program és a folyamatirányító rendszerhez kapcsolódó központi kiszolgáló – egy minta arra, hogyan használható a kiterjesztett valóság a folyamatirányításban, egy ipari rendszer monitorozására. "A kutató munka a Miskolci Egyetem stratégiai kutatási területén működő Mechatronikai és Logisztikai Kiválósági Központ keretében valósult meg."
- 80 -
12 Summary Due to the development of intelligent mobile devices, augmented reality, a long-known, yet novel technology, is becoming wide-spread in everyday life. There are already several augmented reality applications to be found in the fields of pedagogy, medicine, engineering and civilian work. The point of this technology is the extension of reality with virtual objects and information via camera through a monitor or glasses fitted with a display. There are examples of them used by the industry, especially the three dimensional display of models, more specifically CAD systems. A few studies and base-systems were published in the past few months, which support the monitoring of a process control system’s with the help of a pair of intelligent glasses or a tablet. The subject of the dissertation is also a monitoring system, which can be used for process control. The basis of this is the fact that within the system certain points are indicated by QR-codes. When one of them is within the visual field of the tablet’s camera the monitor displays real-time information relevant and typical to the position of the QR-code on the monitor. The information is relayed from the process control system through a central server (e.g. through an OPC connection) by the application of the tablet. Information displayed like this is a preview data of a sort. By tapping on the information bubble, further information can be obtained from the system, which is related to the given measuring points. The client program running on mobile devices using Android and the central server connected to the process control system, the pair of programs that have been completed to date is an example of how augmented reality can be used in process control to model an industrial system.
- 81 -
Köszönet Köszönet illeti Trohák Attilát, aki felhívta a figyelmemet erre a rendkívül érdekes és újszerű témára és vállalta a tervezésvezetői feladatokat. A szakmai tanácsokon kívül segített a téma nyilvános konferencián történő megjelentetésében. Köszönet illeti azokat a tanárokat, barátokat, akik tanácsot adtak az egyes részfeladatok megoldásában vagy éppen engedték a telefonjukra telepíteni a kliens alkalmazást hibakeresés céljából.
- 82 -
Források [1]
„A mobil kiterjesztett valóság története,” [Online]. Elérhető: https://www.icg.tugraz.at/~daniel/HistoryOfMobileAR/.
[2]
„For real! The incredible story of augmented reality,” Nokia, 13. 01. 2013. [Online]. Elérhető: http://conversations.nokia.com/2013/01/13/for-real-theamazing-story-of-augmented-reality/.
[3]
„Myron Krueger - Videoplace,” 1974. [Online]. Elérhető: http://www.youtube.com/watch?v=dmmxVA5xhuo.
[4]
J. Rekimoto, „Matrix: a realtime object identification and registration method for augmented reality,” 1996. [Online]. Elérhető: http://www.sonycsl.co.jp/person/rekimoto/papers/apchi98.pdf.
[5]
[Online]. Elérhető: http://www.hitl.washington.edu/artoolkit/. [Hozzáférés dátuma: 2014].
[6]
T. W. D. Gerhard Reitmayr, „Going out: robust model-based tracking for outdoor augmented reality,” Mixed and Augmented Reality, 2006. ISMAR 2006. IEEE/ACM International Symposium on, %1. szám10.1109/ISMAR.2006.297801 , pp. 109-118, 2006.
[7]
[Online]. Elérhető: https://www.layar.com/.
[8]
[Online]. Elérhető: http://www.google.com/mobile/skymap/. [Hozzáférés dátuma: 2014].
[9]
2013. [Online]. Elérhető: http://www.gizmag.com/ikea-augmented-realitycatalog-app/28703/. [Hozzáférés dátuma: 2014].
[10] [Online]. Elérhető: http://www.artoolworks.com/products/desktop/artoolkit-fordesktop/. [Hozzáférés dátuma: 2014]. [11] Qualcomm, [Online]. Elérhető: http://www.qualcomm.com/solutions/augmentedreality. [Hozzáférés dátuma: 2014]. [12] [Online]. Elérhető: https://www.vuforia.com/. [Hozzáférés dátuma: 2014]. [13] [Online]. Elérhető: http://www.metaio.com/. [Hozzáférés dátuma: 2014]. [14] Siemens, „Industry – Augmented Reality,” 2002. [Online]. Elérhető: http://www.siemens.com/innovation/pool/en/publikationen/publications_pof/pof_ fall_2002/industry_articles/augmented_reality/PoF104art15_1202602.pdf. [15] „Google Glass az ipari automatizálásban,” 2014. [Online]. Elérhető: http://www.gyartastrend.hu/gyartastechnologia/cikk/google_glass_az_ipari_auto matizalasban.
- 83 -
[16] Beckhoff, [Online]. Elérhető: https://www.beckhoff.com/english.asp?press/news1613.htm. [Hozzáférés dátuma: 2014]. [17] [Online]. Elérhető: http://www.youtube.com/watch?v=8o2TkYGCgUQ. [Hozzáférés dátuma: 2014]. [18] [Online]. Elérhető: http://trends.directindustry.com/news-trends/industrialautomation-soon-to-be-seen-through-google-glass/. [Hozzáférés dátuma: 2014]. [19] G. Electric, „Youtube - General Electric csatorna,” 03 11 2013. [Online]. Elérhető: http://youtu.be/ndKqo0pzmqM. [Hozzáférés dátuma: 2014]. [20] „AutomationWorld,” iQagent Inc., 15 10 2013. [Online]. Elérhető: http://www.automationworld.com/augmented-reality-industry-without-glasses. [Hozzáférés dátuma: 2013]. [21] „Kepware,” Kepware, 26 09 2013. [Online]. Elérhető: http://www.kepware.com/News/iquest-integrates-kepwares-kepserverex-todeliver.asp. [Hozzáférés dátuma: 2013]. [22] „iQagent,” iQagent, [Online]. Elérhető: http://iqagent.com/features. [Hozzáférés dátuma: 2014]. [23] „Agilent Mobile Logger,” Agilent Technologies, 2012. [Online]. Elérhető: https://play.google.com/store/apps/details?id=com.agilent.mobilemeterlogger&f eature=also_installed. [24] [Online]. Elérhető: http://en.wikipedia.org/wiki/Aztec_Code. [Hozzáférés dátuma: 2014]. [25] Denso Wave, [Online]. Elérhető: www.qrcode.com. [26] [Online]. Elérhető: http://www.nacs.org/LinkClick.aspx?fileticket=D1FpVAvvJuo%3D&tabid=1426& mid=4802. [27] [Online]. Elérhető: http://www.mav-start.hu/hirek/hir.php?mid=150c5b800cd127. [28] [Online]. Elérhető: http://zxingnet.codeplex.com/. [Hozzáférés dátuma: 2014]. [29] [Online]. Elérhető: https://github.com/zxing/zxing. [Hozzáférés dátuma: 2014]. [30] [Online]. Elérhető: www.websocket.org. [Hozzáférés dátuma: 2014]. [31] TooTallNate, „TooTallNate Java-Websocket,” [Online]. Elérhető: http://javawebsocket.org/. [32] „MatrikonOPC Simulation Server,” Matrikon, [Online]. Elérhető: http://www.matrikonopc.com/products/opc-drivers/opc-simulation-server.aspx. [Hozzáférés dátuma: 2014].
- 84 -
[33] OPC Foundation, [Online]. Elérhető: https://opcfoundation.org/. [Hozzáférés dátuma: 2014]. [34] OpenSCADA, [Online]. Elérhető: http://openscada.org/projects/utgard/. [35] Google, [Online]. Elérhető: http://www.google.com/glass/start/. [36] Epson, [Online]. Elérhető: https://www.epson.com/cgibin/Store/jsp/Moverio/Home.do. [37] Vuzix, [Online]. Elérhető: http://www.vuzix.com/. [38] „Augmented reality: The past, present and future,” 03. 07. 2011. [Online]. Elérhető: http://thenextweb.com/insider/2011/07/03/augmented-reality-the-pastpresent-and-future/. [39] „Mobile Computing in Zone2,” [Online]. Elérhető: http://www.mobile-computinghazardous-area.com/en/learn-about/z710-ex/. [Hozzáférés dátuma: 2014]. [40] [Online]. Elérhető: http://www.qr-kod.hu/. Linkek ellenőrizve: 2014-05-12
- 85 -
Melléklet 1 db DVD melléklet, tartalma:
Dolgozat mappa: o A dolgozat elektronikus formája
Program mappa o Kliens alkalmazás o Központi kiszolgáló
- 86 -
