MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR
TUDOMÁNYOS DIÁKKÖRI DOLGOZAT
Android alkalmazás fejlesztése egészségügyi állapotfelmérő rendszerhez Bartók Roland Mérnök informatikus hallgató
Konzulens: Dr. Gáti Attila egyetemi docens Elektrotechnikai-Elektronikai Tanszék
Miskolc, 2011
Tartalomjegyzék GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR............................................................................................... 1 TUDOMÁNYOS DIÁKKÖRI DOLGOZAT ..................................................................................................... 1 1.
AZ ÁLLAPOTFELMÉRŐ RENDSZER .................................................................................................... 2 1.1. 1.2.
2.
NÉHÁNY SZÓ A NULLSZÉRIÁRÓL ....................................................................................................... 5 2.1. 2.2.
3.
A PROTOTÍPUS FELÉPÍTÉSE ....................................................................................................................... 5 A PROTOTÍPUS MŰKÖDÉSE ....................................................................................................................... 5
FEJLESZTÉSI TERVEK, FELADATOK ELOSZTÁSA ........................................................................ 7 3.1. 3.2.
4.
AZ ÁLLAPOTFELMÉRŐ RENDSZER LÉTREHOZÁSÁNAK CÉLJA .................................................................... 3 A RENDSZER ÁLTALÁNOS MŰKÖDÉSE ...................................................................................................... 3
A TELJES RENDSZER VÁZLATA ................................................................................................................. 8 A MOBIL ALKALMAZÁS VÁZLATA ............................................................................................................ 8
MOBIL KÖRNYEZET .............................................................................................................................. 10 4.1. MIÉRT JÖHET SZÓBA A MOBIL TECHNOLÓGIA?....................................................................................... 10 4.2. KÖRNYEZET KIVÁLASZTÁSA .................................................................................................................. 11 4.2.1. Az okos telefonokon használt rendszerek ...................................................................................... 12 4.2.2. A cél rendszer................................................................................................................................ 13
5.
ANDROID – A LÁTHATÓ ÉS TAPINTHATÓ OPERÁCIÓS RENDSZER ....................................... 14 5.1. AZ ANDROID FELÉPÍTÉSE ....................................................................................................................... 15 5.1.1. Könyvtárak .................................................................................................................................... 16 5.1.2. A Dalvik VM és a futtatható állományok....................................................................................... 16 5.2. AZ ALKALMAZÁSOK FELÉPÍTÉSE ............................................................................................................ 16 5.2.1. Az Activity ..................................................................................................................................... 17 5.2.2. Az Intent ........................................................................................................................................ 18 5.2.3. A Service - háttérszolgáltatás........................................................................................................ 18 5.2.4. Content Provider........................................................................................................................... 19 5.3. A FORRÁS FELÉPÍTÉSE ............................................................................................................................ 19 5.3.1. bin könyvtár................................................................................................................................... 19 5.3.2. gen könyvtár .................................................................................................................................. 19 5.3.3. res könyvtár................................................................................................................................... 19 5.3.4. AndroidManifest.xml ..................................................................................................................... 20 5.4. AZ ÖSSZECSOMAGOLT ALKALMAZÁS ..................................................................................................... 21 5.5. FEJLESZTÉS ............................................................................................................................................ 21 5.5.1. A fejlesztőkörnyezet ....................................................................................................................... 21 5.5.2. Az emulátor ................................................................................................................................... 22 5.5.3. Kiegészítő lehetőség – valós készülék használata ......................................................................... 22
6.
KOMMUNIKÁCIÓ A HARDWARE-EL................................................................................................. 23 6.1. BLUETOOTH – AZ INTELLIGENSEBB ESZKÖZÖKÉRT ................................................................................ 23 6.1.1. Bluetooth az egészségügyben ........................................................................................................ 24 6.1.2. Jellemzői........................................................................................................................................ 24 6.1.3. Az alkalmazott modul .................................................................................................................... 25 6.2. A SAJÁT KOMMUNIKÁCIÓS KERET .......................................................................................................... 25 6.3. AZ ADATOK FOGADÁSA ......................................................................................................................... 27 6.4. UTASÍTÁSOK KÜLDÉSE ........................................................................................................................... 27
7.
ADATTÁROLÁS ........................................................................................................................................ 28 7.1. LEHETŐSÉGEK AZ ANDROID RENDSZERBEN ........................................................................................... 28 7.1.1. Belső adatbázis – SQLite............................................................................................................... 28 7.1.2. A rendszer saját cache lehetősége................................................................................................. 28 7.1.3. Saját mappa létrehozása ............................................................................................................... 29 7.2. ÁTMENETI FILE-OK ................................................................................................................................ 29 7.2.1. Mérés közben................................................................................................................................. 30
7.2.2. Egy vizsgálat megnyitásakor......................................................................................................... 30 7.3. EGY VIZSGÁLAT MENTÉSE ..................................................................................................................... 30 7.3.1. Az adatállomány............................................................................................................................ 30 7.4. AZ ADATÁLLOMÁNY SZERKEZETE ......................................................................................................... 31 7.4.1. A vizsgált személy adatai............................................................................................................... 31 7.4.2. Az állományhoz fűzött megjegyzés ................................................................................................ 32 7.4.3. Reakcióidő..................................................................................................................................... 32 7.4.4. A bináris adatok helye................................................................................................................... 33 8.
FELHASZNÁLÓI FELÜLET ................................................................................................................... 34 8.1. AZ ANDROID KÉPERNYŐ ........................................................................................................................ 34 8.2. ANDROID GOMBOK – FIZIKAI VEZÉRLŐ ELEMEK .................................................................................... 35 8.3. A KÉSZÜLŐ ALKALMAZÁS KÉPERNYŐI ................................................................................................... 36 8.3.1. Vizsgálat........................................................................................................................................ 36 8.3.2. Adatfelvitel párbeszédnézet ........................................................................................................... 37 8.3.3. Megnyitás párbeszédnézet............................................................................................................. 38 8.3.4. Bluetooth párbeszédnézet.............................................................................................................. 38
9.
FEJLESZTÉSI TERVEK .......................................................................................................................... 39
10.
ÖSSZEFOGLALÁS................................................................................................................................ 40
11.
KÖSZÖNET ............................................................................................................................................ 41
FORRÁSOK ........................................................................................................................................................ 42
1
1. Az állapotfelmérő rendszer Egy pécsi biofizikus, feltaláló, villamosmérnök Dr. Kellényi Lóránd, MSc, Ph.D, a MTA Idegélettani Tanszéki Kutatócsoport nyugalmazott tudományos főmunkatársa felismerte, hogy az időskorban illetve nagyobb, altatásos műtétek után az ember szellemi teljesítőképessége csökken és e változások még idejében kimutathatóak és a folyamat lassítható vagy akár a szellemi frissesség szinten tartható. Az agy egészségi állapota szorosan összefügg a keringési rendszer állapotával is. A kutatásai közben az adatgyűjtéshez tervezett egy mérőműszert, amelyet az évek során folyamatosan fejlesztett, módosított. A kutatási időszak alatt nagyon jó eredményeket ért el, ezért szükségessé vált az addig egyetlen műszert néhány példányban sokszorosítani, ezzel lehetővé téve a vizsgálatok szélesebb körű folytatását. Tervével 2009-ben keresett saját találmányának nullszériás legyártására fiatal egyetemistákat. A Bay Zoltán Alkalmazott Kutatási Közalapítvány Nanotechnológiai Kutatóintézetének közreműködésével az Elektrotechnikai-Elektronikai Tanszéken került sor a készülékek tervezésére és legyártására. A feladat elvégzésére alkalmas villamosmérnök és informatikus hallgatókból alakult egy csapat, mely Dr. Pungor András, a kutatóintézet akkori igazgatója és Dr. Gáti Attila docens szakmai vezetésével folyt a munka. A feltaláló több kapcsolási rajzot, egy általa készített működő
prototípust
rendelkezésünkre.
A
és
egy
kezdetleges
prototípusok
kiértékelő
elkészültek
és
programot
használatuk
bocsájtott
során
elért
kimagaslóan jó eredmények azt indokolták, hogy egy, a kor technológiai lehetőségeit kihasználó, kisméretű, könnyen kezelhető eszközt tervezzünk a mérőrendszer új verziójához. Szükségesnek bizonyult a számítógépes alkalmazás újragondolása is, valamint a hardware eszköz megjelenítő részeit a napjainkban nagy népszerűségnek örvendő okos telefonokra bíztuk. A munka könnyen felosztható részfeladatokra úgy, mint a hardware eszköz és a hozzá tartozó vezérlő program, a számítógépes alkalmazás és a mobiltelefonokra készült megjelenítő és adatgyűjtő alkalmazás. A csapat tagjaként utóbbi alkalmazást vállaltam. A csapat tagjai még Ferenc István Csaba mérnök informatikus hallgató, aki a hardware vezérlőprogramját készíti, Fodor Gábor Dénes mérnök informatikus és villamosmérnök hallgató, aki magát a hardware-t készíti és Simon Csaba mérnök
2
informatikus hallgató, aki a PC-s kiértékelő programot írja Java nyelven. A résztvevők mind a Miskolci Egyetem informatikus hallgatói. Az 5 prototípus elkészítése és a most készülő modernizált rendszer tervezése, kivitelezése nagyon értékes tapasztalatot és a félévek alatt meg nem szerezhető kiegészítő tudást biztosít számunkra a mérnöki és a csapatmunka terén egyaránt. Nem csak azt sajátíthattuk el, hogyan lehet megbízható, használható és esztétikus terméket létrehozni, hanem azt is, hogy a feladatot megtervezzük, részekre osszuk, és egymáshoz hangolva megoldjuk őket egy közös cél érdekében.
1.1.
Az állapotfelmérő rendszer létrehozásának célja
A készülék azért jött létre, hogy idejében kimutatható legyen több olyan időskori betegség, mint például keringési problémák,
szívproblémák,
idegrendszeri
elváltozások, amelyek megelőzhetők vagy hatásuk csökkenthető, ha időben felismerik. A mérő berendezés alkalmas arra, hogy altatásos műtétek előtt és után alkalmazva megállapítható, hogy az altatott személy agyi működése milyen mértékben romlottak az altatás hatására.
1.2.
1. ábra Dr. Kellényi Lóránd teszt készüléke
A rendszer általános működése
Az állapotfelmérő rendszer a vizsgálat során az emberi szervezet négy tulajdonságát vizsgálja:
•
Bőrfelszíni keringés vizsgálata (pletizmográfia): a bőrfelszín 1-3mm-es mélységében
keringő
vér
nyomásváltozását
vizsgálja infra adó-vevő párral. Ez az érrendszer és a szív állapotáról ad információt. (2. ábra)
•
Tremor vizsgálat: A végtagok, esetünkben a kar 2. ábra Szívgörbe képe és kéz természetes rezgését méri gyorsulásmérő segítségével. Ez a rezgés abból származik, hogy a végtag adott helyzetben tartását az
3
izomzat folyamatos apró mozgásokkal biztosítja a végtagra ható erő ellenében. A vizsgálat e része a mozgásért felelős agyterület és az idegrendszer állapotát térképezi fel. •
sRT, cRT – reakcióidő mérés: A reakcióidő mérés egy, a műszer által fejhallgatón
keresztül
szolgáltatott
1000Hz-es
hang
és
erre
gombnyomással adott válasz között eltelt idő mérésén alapul. Utóbbi meg is felel az egyszerű (sRT – simple reaction time) reakcióidőnek. A feltételes (cRT - choice) reakcióidő-mérés esetén egy másik, mélyebb hangot is hall a vizsgált személy, amelyet figyelmen kívül kell hagynia. Ez a vizsgálat a szellemi frissességét méri. Az átlagos idő 200 és 300ms közé esik. Befolyásolhatják olyan tényezők, mint a fáradtság, a környezet zavaró hatásai, stressz. A vizsgálat során a vizsgált személy kaphat egyszerű számolási feladatot, amelyet a célingerre adott válasz közben kell végrehajtania. Ezzel is további információkra lehet szert tenni a vizsgált személy állapotát illetően. Az előbbi vizsgálatok eredményeit egy számítógépes program dolgozza fel. A bőrfelszíni keringésből kiszámítja a pulzusszámot, ennek változását, végül statisztikát is készít belőle. Tremor vizsgálat esetén a jel FFT vizsgálat eredményében
a
kiugró
frekvenciaértékek
utalnak
bizonyos
idegrendszeri
betegségekre, mint például a Parkinson-kór. A reakcióidő adataiból átlagot, mediánt és szórást számít.
4
2. Néhány szó a nullszériáról
2.1.
A prototípus felépítése
A prototípusok csak a kísérleti mérések lebonyolítását szolgálják, ezért robosztusak, szükség esetén módosíthatóak és szerelhetőek. Annyiban különböznek a mintapéldánytól, hogy az alkatrészeket az áramkör számára tervezett nyomtatott áramköri lapra szereltük így biztosítottuk a megbízható működést. Maga az áramkör furatszerelt alkatrészekből épül fel, melyek hely-, és energiaigénye is viszonylag nagy, így csak konnektor közelében használható. A méréshez szükség van egy személyi számítógépre és egy külső, általunk módosított hangkártyára, és egy fejhallgatóra is. A kísérleti mérések során ez megfelelő, azonban a széleskörű használat során leginkább bosszúságot okoz a nagy mennyiségű vezeték, sok kapcsoló és
3. ábra Az elkészült prototípus
2.2.
ezek meghibásodásának lehetősége.
A prototípus működése
A prototípus működésének egyik jellemzője, hogy az érzékelők jeleit maga az alapműszer méri, majd analóg feldolgozás után analóg jelként továbbítja a hangkártya felé. Ilyen feldolgozás például a szívgörbe jelén végzett csúcsérzékelés, amely segítségével egy LED felvillantásával tájékoztat az érzékelő helyes működéséről. Az alapműszer képes trend görbét készíteni (vagyis ennek megfelelő jelet) a szívfrekvencia változásáról. A
hangkártyát
át
kellett
alakítani
két
vonal
bemeneti
leválasztó
kondenzátorának rövidre zárásával, hogy DC jeleket is képesek legyen digitalizálni a PC számára. A PC-s kiértékelő program, amely Delphi nyelven íródott, a hangkártya vonalbemenetéről gyűjti az adatot és rajzolja ki folyamatosan két grafikonra, a stereo csatornáknak megfelelően. Az esetleges erősítést magán a műszeren kell elvégezni, az alkalmazás maga csak a jel kiértékelésére képes. A műszer semmilyen adatot
5
nem közöl arról, hogy éppen melyik mérés folyik. Ezt a mérést végző személynek kell tudnia később az elemzésnél, hogy a grafikonnak azt a szakaszát (a grafikonon végezhető kijelölés) milyen mérésnek megfelelő menüponttal kell elemezni. Egyes jelek (szívgörbe jele) elemzéséhez azonban szükség van az orvos tapasztalatára és tudására, hogy „szemmel” tudja elemezni a görbéket. Az elemzés rögzítését segíti egy egyszerű szövegszerkesztő a kiértékelő programban, amelybe beilleszthető a grafikon egy-egy kijelölt darabja. Az elkészült szöveges értékelés elmenthető, kinyomtatható. Az, hogy az elemzés melyik méréshez tartozik legfeljebb onnan tudható, ha az írója valahol lejegyzi.
4. ábra A prototípusok kiértékelő programja (a két grafikon a hangkártya jobb és bal csatorna jelét rajzolja ki)
6
3. Fejlesztési tervek, feladatok elosztása A rendszert, korszerű eszközök felhasználásával fejlesztjük egy hatékony és olcsó, ezáltal az orvosok számára könnyen hozzáférhető rendszerré. A mérő hardware lelke egy mikrovezérlő, amely fogadja a gyorsulásmérő és digitalizálja az infradióda felerősített jelét, elvégzi a reakcióidő mérést a hangok generálásával együtt. A mért értékeket ezután USB vagy Bluetooth kapcsolaton keresztül küldi a PC vagy a mobilkészülék felé. Az áramellátását korszerű lítium alapú akkumulátorral oldjuk meg. A mikrovezérlő köré csak minimális mennyiségű alkatrészt kell építeni. Saját állapotát LED-ekkel jelzi, illetve elküldi azt a feldolgozó alkalmazásnak. A vezetéknélküli Bluetooth kapcsolatnak köszönhetően a vizsgált személy számára is kényelmesebb lesz az állapotfelmérés, nem kell a vezetékekre figyelnie. A vizsgálatot végző orvos pedig egyszerűen PC esetén kattintásokkal, mobilkészülék esetén érintésekkel irányíthatja a mérést. Ezzel a résszel Ferenc István Csaba, mint a firmware készítője és Fodor Gábor Dénes, mint a hardware tervezője foglalkozik. A PC-s alkalmazás teszi lehetővé a teljes körű kiértékelését, megjelenítését és tárolását a jeleknek. Egyszerű adatbázis-kezelő feladatot is ellát az mérési eredmények rendszerezésére. A fejlesztési nyelv választása a Java nyelvre esett. A program elkészítését Simon Csaba végzi. A mobilkészülékekre, ezen belül is az Android rendszerre készülő alkalmazás teszi lehetővé, hogy PC nélkül is elvégezhető legyen a vizsgálat szinte bárhol. Feladatait tekintve Bluetooth kapcsolaton keresztül fogadja a mérő hardware adatait, melyeket megjeleníti és tárolja. Ez nagy segítség az orvosnak, mert nem kell magával cipelnie súlyos és nagy számítógépet ellenben egy okos telefonnal, amely akár a megszokott táskájában is elfér a mérő hardware-el együtt. Természetesen ez az alkalmazás nem a PC-s alkalmazás kiváltására, hanem a lehetőségek és kényelmi funkciók kiterjesztésére szolgál. Bár a nem túl távoli jövőben akár ki is válthatja a PC feladatát.
7
3.1.
A teljes rendszer vázlata
A rendszer fizikailag két fő egységből áll, a mérőegység és a feldolgozó egység. Előbbi a mikrovezérlővel ellátott kézi eszköz, amely a vizsgált személyre kerül utóbbi pedig a PC-t illetve a mobil eszközt jelöli. A rendszer vázlata az 5. ábrán látható. A mérőegység feladata az adatok digitalizálása, gyűjtése, majd keretbe foglalva vezetékes (USB) vagy vezeték nélküli (Bluetooth) kapcsolaton továbbítja a feldolgozó egység felé. A feldolgozó egység végzi az adatok tárolását, elemzését. A PC-re készülő program teljes körű azonnali és utólagos elemzési feladatokat lát el az adatgyűjtés mellett. A hordozhatóság kényelme érdekében készül a mobil alkalmazás, amely a PC-s program egy egyszerűsített változata, főleg az adatgyűjtésre kihegyezve néhány hasznos elemzési kiegészítéssel és természetesen rendelkezik a nyers illetve feldolgozott adatok megjelenítéséért felelős részekkel is.
5. ábra A teljes rendszer vázlata
3.2.
A mobil alkalmazás vázlata
A mobil alkalmazás egyszerű vázlata a 6. ábrán látható. A nyilak az adatáramlás irányait mutatják. A Keret modul felelős a bejövő keretek feldolgozásáért és a típusának megfelelően továbbítani az adatfeldolgozásért illetve állapot üzenetek esetén a felhasználói felület kezelésére készült modul felé. Az fogadáson kívül szükséges a mérőegység számára különféle utasításokat küldeni, mint például melyik mérésre van szükség, esetleg kikapcsolás. Ezeket az üzeneteket az Keret modul foglalja
8
keretbe és továbbítja a Bluetooth modul felé. A Bluetooth a telefon belső kapcsolatkezelő modulját ábrázolja. Az Adatfeldolgozás a bejövő adatok főleg a megjelenítés számára történő elemzését végzi, FFT analízis a tremor jelből, csúcsérzékelés és ebből pulzus számítás a pletizmográf jeléből. Ezeket vagy a megjelenítő modul felé vagy a file kezelő modul felé továbbítja, amely a tárolóba írja az adatokat. A nyers adatokat átmeneti file-okban tárolja az alkalmazás. A felhasználó szándékait a megjelenítő és vezérlő modultól fogadja. Innen kapja az utasítást, hogy feldolgozza, vagy elmentésre küldje az adatot. A File kezelés modul a kapott adatot az utasításnak megfelelően átmeneti állományba vagy a végleges állományba menti. Az alkalmazás képes az elmentett méréseket megnyitni és megjeleníteni illetve egy valamilyen hiba miatt megszakadt mérés már meglévő adatait végleges formában elmenteni. A Felhasználói felület/vezérlés egy különleges modul, a két feladat az érintőképernyő miatt került egy csoportba. Az adatok kirajzolását grafikonokra végzi tartalmaz adatfelviteli lehetőséget és állapotsávot is kezel. A vezérlés a különböző gombokhoz tartozó utasításokat továbbítja a megfelelő modul felé.
6. ábra A mobil alkalmazás vázlata
9
4. Mobil környezet
4.1.
Miért jöhet szóba a mobil technológia?
A kezdetben méretes, nehéz és csak beszédhívásra alkalmas rádiótelefonok (1973) az 1980-90-es években indultak rohamos fejlődésnek. Az egyszerű hanghívás mellett megjelent a rövid szöveges üzenet szolgáltatás (SMS) - mely eredetileg szerviz szolgáltatás volt, azonban brit fiatalok akkor még ingyenessége miatt elkezdték kommunikációs célokra használni - , képüzenet,
továbbítási
lehetőség (MMS). A kijelzők a kezdetben egyszínű számkijelzőkből a nagyobb felbontású egyszínű majd árnyalatos kijelzőkön keresztül mára nagy felbontású színes kijelzőkké fejlődtek. Közben megjelentek új szolgáltatások úgy, mint a mobiltelefonon is elérhető Internet. Megjelentek az okos telefonok, melyek most a műszer szempontjából a cél-hardware-t jelentik. A továbbiakban is inkább ezekről írok. A hardware is közben egyre nagyobb számítási teljesítményre lett képes. Olyan dolgokra használhatóak mára, mint a számítógépek: játékok futtatása viszonylag bonyolult akár 3D-s grafikával, fényképszerkesztés, zenelejátszás, GPS helymeghatározás, WEB böngészés… a sor szinte végtelen. Általánossá vált a nagyméretű kijelző, érintéses vezérléssel. Láttam példát futároknál, a telefon segítségével regisztrálták az áru átadását, aláírást
az
érintés
érzékeny
képernyőn
kellett
elvégezni.
Alkalmas kérdőív kitöltésére, adatfelvételre fénykép csatolással, akár a pincéreknek is segítséget nyújthat a rendelés felvételekor, az elküld gomb nyomására a szakács már tudja mit kell készítenie. Az USA-ban az orvosok a betegek adatait olvassák ki okos telefonból, amelyet egyelőre maguk visznek fel, de mégis gyorsabb, mint egy több oldalas kartont átböngészni. Másik érdekes fiatal készülékcsoport a tábla PC-k csoportja. Ezek már legalább 7” képátlójú kijelzővel rendelkeznek, nincs billentyűzetük, szinte minden vezérlést a képernyő érintésével lehet megoldani. A telefonokhoz hasonlóan akár kézírást is képesek felismerni, szöveggé alakítani. Hardware szempontjából inkább
10
laptopnak számítanak, méret szempontjából nagyobb okos telefon vagy kisebb laptop. Operációs rendszerüket tekintve is elég széles a paletta. Tehát érdemes figyelembe venni ezeket a zsebszámítógépeket a mi műszerünk esetén is, melynél fontos a hordozhatóság és egyszerű használat. Véleményem szerint számítási teljesítményük az állapotfelmérő rendszerhez több mint elegendő. Kommunikációs képességeik lehetővé teszik, hogy magával a műszerhez készített hardware eszközzel vezeték nélküli kommunikációt folytasson.
4.2.
Környezet kiválasztása
A Java környezetet a megalkotása idején kis elektronikai eszközök közös nyelvének tervezték (kezdetben Oak néven futott). Elterjedése mégis a weboldalakba ágyazható applet-ek hatására történt meg, ma használatos az asztali és szerver gépek között felhasználói és szerver alkalmazásként is. Azonban mindig újra felmerült az igény a kis elektronikai eszközök programozási nyelvére, egy egységes rendszer kialakítására. Mivel a Java Virtuálisgép (JVM – Java Virtual Machine ) erőforrás igénye folyamatosan nőtt, már nem volt alkalmas ezen eszközökön történő futtatására. A Java 2 bevezetésével létrejött a J2SE (Standard Edition) a felhasználói és a J2EE (Enterprise Edition) üzleti változat. Ezek mellé létrehozták a J2ME-t (Micro Edition) a telefonok, beltéri egységek, autók, tv-k és egyéb eszközök számára. Utóbbi a J2SE korlátozott változata, szabványokat, profilokat tartalmaz. A J2ME elterjedése a telefonok népszerűvé válásának és rohamos hardware-es fejlődésének hatására történhetett meg. A telefonok fejlődésük során már nem csak telefonálásra váltak alkalmassá,
hanem
kiegészítő
programok
futtatására
is.
A
felhasználók leginkább játékprogramokat futtattak a telefonjukon. Ezért a J2ME szinte összenőtt a játékprogramokkal. Természetesen a játékok mellett egyéb hasznos alkalmazást is készítenek a telefonokra (például Miskolc Városi Közlekedési Zrt. mobiltelefonos menetrendje). A Java ME bővebb kifejtésére nem kerül sor, ugyanis a cél készülékeket a gyártók más, olyan operációs rendszerrel látják el, amelyek általában nem támogatják a Java ME-et. Kivételt képez a BlackBerry által használt RIM (Research
11
In Motion) operációs rendszer, amelyet a Java ME-n alapuló programokkal lehet kiegészíteni. További probléma a Java ME-vel, hogy sok készülék saját csomagot igényel a megfelelő működéshez, főleg a hardware eszközök használatakor úgy, mint a Bluetooth kapcsolat, kamera használata esetén, ez igaz a RIM-re is. A Java ME megmaradt a „kevésbé okos” telefonok nyelvének.
4.2.1. Az okos telefonokon használt rendszerek Az okos telefonokat a gyártók alapjaiban más operációs rendszerrel látják el, mint a hagyományos telefonokat. Ennek oka az erősebb hardware jobb kihasználása, a felhasználói élmény fokozása. Továbbá az, hogy egy egész szolgáltatáscsomagot hoznak létre az adott rendszerhez, mint például az alkalmazások számára létrehozott piactér, irodai szolgáltatások, szervező és e-mail és tárhely szolgáltatások. A jelenlegi népszerű rendszerek eloszlását a 7. ábra mutatja. Növekvő sorrendben az első az egyéb kategória, ezek a kevésbé ismert gyártók saját rendszerei illetve direkt mobil telefonok számára átalakított Linux változatok. A Bada a Samsung által 2010-ben
bemutatott
operációs
rendszer főként a csúcskategóriás okos telefonok, tábla PC-k és TV készülékek koreai
számára.
nyelven
A
óceánt
Bada jelent.
Linux, freeBSD alapú. C és Java nyelvet támogat. A Microsoft 2000 óta jelen van
a
mobil
piacon,
jelenleg
Windows Phone-nak hívja a mobil operációs rendszerét. C++, C#
7. ábra A mobil operációs rendszerek aránya 2011. 2. negyedévében
nyelven programozható.
12
A RIM a BlackBerry-k operációs rendszere. Zárt forráskódú és Java segítségével programozható. Az Apple 2007. június 28-án adta ki az első iPhone-t. Ez a készülék alapjaiban változtatta meg, amit addig az okos telefonoktól vártak az emberek.
Eddig 5
változata jelent meg. Programozása Objective C nyelven lehetséges. A Symbian a Nokia által fejlesztett és használt rendszer a felsőkategóriás illetve okos telefonjain. Java és C nyelven programozható. Végül a legdinamikusabban fejlődő rendszer az Android következik. A Google fejlesztése egy régebbi azonos nevű terv folytatásaként. Jelenleg a legtöbb készüléken érhetőek el különböző verziói, melyből a 4. éppen a napokban került nyilvánosságra.
4.2.2. A cél rendszer Az egészségügyi állapotfelmérő rendszer számára az Android rendszert választottam. Jelenleg ez a legelterjedtebb rendszer, a belépőtől a csúcs kategóriáig széles a készülék-kínálat, mindenki megtalálhatja a számára megfelelőt. Többek között ez is segíti az Android-ot a gyors terjedésében. A dolgozat írása idején, a világon a legelterjedtebb a 2.3-as változat, azonban a hazai szolgáltatóknál szép számmal vásárolható olyan készülék, amely a 2.1-es változatot futtatja. Ez az oka, hogy a készülő alkalmazás megkívánja legalább az Android 2.1-et. Az ettől idősebb rendszerek gyors ütemben tűnnek el készülékváltás vagy rendszerfrissítés következtében, az újak közül a 2.1 a legkisebb elérhető változat.
13
5. Android – a látható és tapintható operációs rendszer Az Android platform abból a célból született, hogy egységes nyílt forráskódú rendszere legyen a mobil eszközöknek (okos telefonok, tábla gépek). Alapját egy Linux operációs rendszer alkotja, amelyet úgy alakítottak át, hogy képes legyen gond nélkül kezelni a mobil eszközök hardware egységeit (érintőképernyőt, WiFi, Bluetooth, GPS, HSDPA) és kicsi legyen az erőforrásigénye. 2005-ben a Google megvásárolta az eredeti fejlesztő céget, az Android Inc.-t. Ez új irányt adott a fejlesztésnek. A Linux kernel fölé egy virtuális gép került, amely felelős a programok futtatásáért és a felhasználói felület kezeléséért. Ekkor került bele a Java nyelv is, mint az Android alkalmazások programozási nyelve. 2007. november 5-én bejelentették az Android disztribúciót az Open Handset Alliance alapításával együtt, amely összesen 84, hardware gyártó, software fejlesztő és telekommunikációs cég szövetsége. Az Android Open Source Project célja az Android fejlesztése és karbantartása. 2008. szeptember 20-án került nyilvánosság elé az első kiadása az Androidnak. Napjainkra már nem csak az okos telefonok elterjedt rendszere, hanem megtalálható a tábla PC-ken, TV készülékeken is. Hasonlóan a Sun Java-hoz (amelyet később felvásárolt az Oracle), fokozott érdeklődés mutatkozik iránta, hogy gépjárművek fedélzeti és navigációs rendszereként, ipari automatizálási területen alkalmazzák, illetve minden olyan helyen, ahol korlátozott erőforrások állnak rendelkezésre, kisméretű képernyő és egy egér vagy billentyűzet használata nehézkes lenne, így előnyt jelent az érintő kijelző. Az általunk modernizált egészségügyi állapotfelmérő rendszernek is egy kényelmes és hasznos kiterjesztése lehet egy Android alapú kiértékelő program. Ezáltal nem csak könnyen hordozhatóvá válik, hanem az elkészítendő mérő hardware is egyszerűbb lehet, nem kell rá például külön kijelző, nagy belső memória, mert az már ott van a telefonban. A szinte általánossá vált érintőképernyők mára teljesen használhatóvá váltak, képesek helyettesíteni a mutató és beviteli eszközöket, ez tovább csökkenti a csatlakoztatott külső hardware egységek számát.
14
5.1.
Az Android felépítése
Az Android felépítését szemlélteti a 8. ábra. A piros színnel jelölt rész a rendszer alapja egy monolitikus Linux kernel. Ez tartalmazza a hardware-n kezelhető eszközök meghajtó programjait. Ezeket azok készítik el, akiknél senki sem tudhatja jobban, hogyan működik az adott eszköz, vagyis azok a gyártók, akik Android-ot szeretnének használni a saját eszközeiken. Ez a kis méretű kernel biztosítja a memória kezelését, a folyamatok kezelését. A kernel szolgáltatásait használják a rendszer különféle könyvtárai, az ábrán zöld színnel jelölt részek. Ezek közvetlenül a kernelen futnak, részben ezekre épül a Dalvik VM (Virtuális gép) is. C, C++ nyelven íródtak. A felső kék rész már az alkalmazások területe, Java nyelven programozható és a virtuális gép futtatja a megírt programokat. A rendszer magját szinte teljesen elrejti. Lehetőség van egy külön fejlesztői csomag segítségével C nyelvű programokat is készíteni az Anrdoid-ra.
8. ábra Az Android rendszer felépítése
15
5.1.1. Könyvtárak •
libc: BSD-ből származó szabványos C könyvtár megvalósítása, mobil Linux alapú készülékek számára optimalizálva.
•
Media Framework: Több népszerű hang, állókép és mozgókép formátum lejátszását és felvételét támogatja, a PacketVideo OpenCORE-ja alapján.
•
Surface Manager: A megjelenítő alrendszerhez való hozzáférést kezeli a zökkenőmentes 2D és 3D megjelenítés érdekében.
•
LibWebCore: Egy modern web-böngésző mag az Android böngésző és a beágyazható webes nézet számára.
•
SGL: 2D-s grafikus motor
•
OpenGL|ES: OpenGL ES 1.0 megvalósítása. A könyvtár a 3D-s megjelenítéshez, ha elérhető hardware-es gyorsítást használ, vagy az erősen optimalizált softwarees 3D raszterezőt.
•
FreeType: bittérképes és vektoros betűtípusok megjelenítése
•
SQLite: egy könnyűsúlyú relációs adatbázis megvalósítása minden alkalmazás számára.
5.1.2. A Dalvik VM és a futtatható állományok A Dalvik VM egyáltalán nem kompatibilis a Java VM-el. Más, tömörebb, mobil eszközökre optimalizált byte-kódot futtat. A *.java állományokat a fordító nem *.class, hanem *.dex file-okba fordítja ( Dalvik Executable ). Ennek kisebb a mérete is, mint a *.class file-oknak. Ez annak is köszönhető, hogy a konstansokat egyszer fordítja bele az állományba és egyéb optimálásokat is alkalmaznak.
5.2.
Az alkalmazások felépítése
Mobil környezetben, ahol viszonylag kicsi a megjelenítő felülete és kevés az erőforrás nem elterjedt az ablakos felhasználói felület. Az Android esetén is inkább képernyőkről kell beszélni a Java ME-hez hasonlóan. Ezek a képernyők általában az egész megjelenítő felületet elfoglalják kivéve az állapotsort, de grafikus alkalmazások esetén előfordul, hogy ténylegesen az egész képernyőt veszik birtokba.
16
5.2.1. Az Activity Az Android-ban ezek a képernyők két részből épülnek fel. Az egyik a megjelenésért felel, egy XML alapú leíró file, amely megadja, milyen elemek hogyan vannak elrendezve a képernyőn. A másik a hozzá tartozó Activity osztály leszármazottja, amely a hozzá tartozó képernyő eseményeit kezeli, válaszol rá. Egyszerűbb programok esetén nem feltétlenül fontos az XML file létrehozása, a Java forrásból is (ahogy az a Java esetén megszokott) létrehozható a grafikus felület. Egyszerre mindig egyetlen Activity látszik, és külön életciklussal rendelkezik. Az életciklus minden Activity saját jellemzője, a 9. ábrán látható milyen állapotai vannak.
9. ábra Az Activity életciklusa
17
Lényegében az Activity az onStart() és onStop() állapot között látható és használható a képernyőn. Az ábrán látható állapotok azonos nevű metódusát az Activity ősosztályból örökli a saját képernyőnk és a platform hívja meg a megfelelő időben. A fontosabbakról néhány szó röviden: Az onCreate() metódus az Activity létrehozásakor hívódik meg, ebben lehet elvégezni az objektumok létrehozását, beállítását, az előzőleg elmentett állapot ilyenkor már visszatölthető. Az onPause() metódus a tevékenység háttérbe kerülésekor hívódik meg, ekkor elvégezhető az állapot mentése, szálak leállítása, szüneteltetése. Az onDestroy() metódus akkor hívódik meg, amikor a tevékenység már nem látható és kevés a rendelkezésre álló memória. Ugyanis az Android rendszer nem állítja le a programokat, csak felfüggesztett állapotba helyezi. Ennek köszönhetően a gyakran használt programok gyorsan indulnak, akár az előzőleg használt állapottól is folytatható a használatuk. Ez azért fontos, mert a program használatakor történhet olyan esemény, ami a program azonnali felfüggesztését kéri (bejövő telefonhívás, üzenet).
5.2.2. Az Intent Az Intent - magyarul szándék, egy összetett objektum. Arra használható, hogy az egyes Activity-k adatot cserélhessenek egymással vagy használható egy új Activity indítására is. Ilyen Intent-et nem csak saját magunk hozhatunk létre és kaphatunk el. A rendszer is küldhet Intent-et, például telefonhíváskor, ébresztéskor. A különböző Intent-ekre a BoradcastReciever osztály leszármaztatása segítségével iratkozhatunk fel. Ezt meg lehet tenni a program futása közben is vagy úgy, hogy az AndroidManifest.xml file-ban megadjuk milyen Intent eseményekre figyeljen az adott Activity. Ha egy alkalmazás feliratkozott az esemény figyelésére és az esemény bekövetkezik, akkor a platform gondoskodik az alkalmazás elindításáról.
5.2.3. A Service - háttérszolgáltatás Ha egy alkalmazásnak szükséges, hogy akkor is fusson, amikor éppen az alkalmazás be van zárva – az egészségügyi állapotfelmérő rendszer esetében például akár egy telefonhívás közben sem szakadhat meg az adatgyűjtés – akkor
18
szükség van a Service-re. Minden ilyen szolgáltatást addig futtat a platform, ameddig azok
be
nem
fejeződnek.
Minden
alkalmazás
képes
kapcsolódni
a
szolgáltatásokhoz, hogy azokat vezérelni is lehessen.
5.2.4. Content Provider Mivel az alkalmazások nem minden esetben csak az éppen rendelkezésre álló adatokkal dolgoznak, szükség van a két futás közötti adatok tárolására. Ezt támogatja a Content Provider, amely vagy az SQLite adatbázist vagy átmeneti file-ok használatát támogatja az alkalmazás számára.
5.3.
A forrás felépítése
A forrás csomag több könyvtárból áll, melyeknek kitüntetett szerepe van.
5.3.1. bin könyvtár Ebben a könyvtárban tárolja a fejlesztő környezet a *.class file-okat, amelyekből majd a *.dex file-okat fogja elkészíteni. Ebben a mappában található az utóbb említett *.dex file is. Tehát itt tárolja a byte-kódot és a *.apk file-t, amelyről később lesz szó.
5.3.2. gen könyvtár A gen könyvtárban található az R.java osztály. Ez egy különleges osztály a fejlesztőkörnyezet generálja és kezeli, létrehozásával memóriát és erőforrást takarít meg a rendszer. Ez a statikus osztály több belső statikus osztályt és azok statikus konstansokat tartalmaznak. A konstansok memóriacímeket tárolnak a különböző erőforrásokra (például egy gomb a képernyőn vagy egy elrendezés).
5.3.3. res könyvtár Ez a könyvtár több alkönyvtárból áll. Az erőforrásokat tartalmazza: •
drawable könyvtár: Az alkalmazás által használt képeket tárolja. Előfordul, hogy több is létrejön belőle: drawable-ldpi – kis méretű képek az alacsony kijelzőkhöz,
19
drawable-mdpi – közepes méretű képek, drawable-hdpi – nagy méretű képek. Ez a tulajdonság jellemző a többi itt található könyvtárra is. •
layout könyvtár: Az alkalmazás egyes képernyőinek elrendezését, kinézetének leírását tartalmazza egy-egy XML file-ban. Ebből is létezhet több, a különböző képernyőfelbontásoknak megfelelően.
•
menu könyvtár: Az alkalmazás tartalmazhat a menü gomb megnyomásának hatására felugró menüt. Az ilyen menük kinézetét írják le az itt található XML fileok.
•
values könyvtár: itt találhatóak az egyéb erőforrások, mint a strings.xml az alkalmazásban található szövegek tárolására (akár string tömböt is!), HTML alapon a formázására használható, a style.xml az alkalmazásban található stílusok leírására, továbbá lehetséges egy külön XML file-ban primitíveket tárolni az alkalmazás környezetének beállításához. A fentebb felsorolt erőforrásokra az R osztályon keresztül lehet hivatkozni
(R.id.txtSzoveg például egy szövegmezőre hivatkozhat) vagy az XML file-okon belül például egy gomb feliratának a layout könyvtár main.xml által leírt képernyő egy gombjának
a
szövegét
a
következő
hivatkozással
lehet
beállítani:
@strings/visszaGomb. Hasonló módon hivatkozhatunk egy képre is. Közös jellemzője még ezeknek az erőforrásoknak, ha több képernyőfelbontást vagy több nyelvet kezel az alkalmazás, akkor sem kell a hivatkozásokat megváltoztatni. A rendszer gondoskodik a kiválasztásról. ( Például a felsorolt 3 drawable könyvtárban ugyanazzal a névvel, de különböző méretben elmentett ikonok közül mindig az éppen szükségeset választja ki ezzel a hivatkozással: @drawable/startIkon.)
5.3.4. AndroidManifest.xml A címben szereplő file az alkalmazás lelke, a fő leírása itt található. Egy rövid leírás róla a teljesség igénye nélkül, mivel nagyon sok dolgot lehet ebben a file-ban beállítani az alkalmazással kapcsolatban. Ebben az állományban kell leírni, milyen jogokat igényel a program (például írás jog az SD kártyára, érzékelők olvasása, Bluetooth használata). Azt, hogy milyen verzión fut az alkalmazás, mely a minimális esetleg cél verzió. Itt kell bejegyezni az alkalmazást alkotó Activity-ket, a hozzájuk
20
regisztrált Intent-eket. Ezzel azt is megadja, melyik Activity az alkalmazás első, indító képernyője. A szolgáltatásokat, figyelőket is itt lehet bejegyezni.
5.4.
Az összecsomagolt alkalmazás
Fordítás után a futtatható byte-kódok és az erőforrások egyetlen file-ban kerülnek elhelyezésre, mint a Java nyelv esetén a *.jar file, csak az Android ezt *.apk kiterjesztéssel látja el (Application Package). A *.apk file a *.jar file egy változata, ugyanúgy zip tömörítési eljárást használ a csomag létrehozásához. Ezt a file-t kell a telefon rendszerére telepíteni.
5.5.
Fejlesztés
5.5.1. A fejlesztőkörnyezet Az Android honlapjának ajánlását követve az Eclipse fejlesztőkörnyezetet használtam az alkalmazás elkészítéséhez. Az Eclipse Indigo változata volt elérhető a fejlesztés kezdetén. Az Eclipse egy ingyenes és sokoldalú fejlesztőkörnyezet, amely több programozási nyelvet is támogat. Telepíteni nem szükséges, különféle kiegészítőkkel nagyon sok feladatra alkalmas. Az Android támogatását is egy kiegészítő telepítésével lehet elérni, amelyet az Android honlapján találhat meg a fejlesztő az Android SDK-val együtt, amely szükséges az alkalmazások fejlesztéséhez. A kiegészítő teljes körű segítséget nyújt az Android alkalmazások elkészítéséhez, beleértve a grafikus felhasználói felület tervezését segítő grafikus szerkesztő modult. Utóbbi segítségével egyszerűen, fogd és vidd módszerrel alakítható ki az alkalmazás felülete, az esetleges hibákat azonnal láthatja a tervező. Persze elengedhetetlen kipróbálni az emulátoron vagy inkább egy valós készüléken is. A kiegészítő segítségével lehetővé válik az Android XML állományainak felhasználóbarát szerkesztése, ennek ellenére időnként érdemesebb magát az állományt „kézzel” szerkeszteni.
21
5.5.2. Az emulátor Az Android SDK tartalmaz a készülő alkalmazások futtatásához egy emulátort, amely nagy segítséget nyújt az fejlesztés idején. Virtuális gép, egy telefont széleskörűen képes helyettesíteni kivéve néhány apróságot. Bár az emulátorban akár szimulált telefonhívást lehet indítani és fogadni, hálózati kapcsolatot létesíteni akár másik emulátorral is, néhány hiányossága is akad.
Nem
támogatja
többek
között
az
érzékelők
használatát
(beépített
gyorsulásmérő, fényérzékelő, akkumulátor felügyelő), a Bluetooth kapcsolatot, több érintést és hosszú érintést. Ezek nem létszükségletek, de az alkalmazás tényleges kipróbálásához mégis szükséges egy valós készülék megléte, az emulátor leginkább ellenőrzési, gyors kipróbálási célokat szolgál. Az Eclipse DDMS (Dalvik Debug Monitor Server) nézetében az emulátorban zajló folyamatok követhetők figyelemmel. Ekkor jelenik meg a programozáskor nagyon hasznos konzol, amelyre a futó folyamatok írják az állapotüzeneteiket, elérhető
a
virtuális
SD
kártya
tartalma,
a
futó
folyamatok
és
utóbbiak
monitorozhatóak is. Ebben a nézetben lehet GPS koordinátákat megadni a rendszernek, telefonhívást szimulálni. A folyamatok monitorozása kiterjed a folyamat futási idejének, memóriahasználatának jelzésére is.
5.5.3. Kiegészítő lehetőség – valós készülék használata Mivel az emulátor korlátozott és igen lassú is, lehetőség van egy arra alkalmas valós Android készülék használatára is. Ehhez csak a készülékhez szükséges meghajtó programot kell telepíteni és csatlakoztatni a PC-hez és az SDK-nak kijelölni, hogy a valós készüléket használja. Ekkor az emulátornál már megszokott információk jelennek meg, gyorsabb működés mellett. Sajnos ezt a lehetőséget nem volt alkalmam kipróbálni, az általam használt készülékhez nem készítettek erre alkalmas meghajtó programot.
22
6. Kommunikáció a hardware-el Az okos telefonok legelterjedtebb kapcsolata a külvilággal USB porton illetve valamilyen
rádiós
kapcsolaton
keresztül
valósul
meg.
Az
egészségügyi
állapotfelmérő rendszer követelménye szerint utóbbit kell figyelembe venni. A GSM alapú rádiós kapcsolat mellett szinte alapvető a Bluetooth és a WiFi jelenléte ezen eszközökben, bár utóbbi nem feltétlenül van jelen minden készülékben. A mindkét rádiós technológia a 2,4GHz körüli frekvenciatartományt használja,
mégis
a
Bluetooth
mellett
döntöttünk
főként
az
alacsonyabb
energiafogyasztása miatt.
6.1.
Bluetooth – az intelligensebb eszközökért
AZ 1994-ben az Ericsson által megalkotott technológia a kis elektronikai eszközök egységes kommunikációs felületévé vált. Eredetileg az egyszerű RS-232 vagyis soros porton keresztüli kommunikáció vezeték nélküli változatának készült. Mára, annyira elterjedt kommunikációs szabvány lett, hogy szinte minden elektronikai eszköz, amelynek szükséges más eszközzel kapcsolatot létesítenie használja a Bluetooth kapcsolatot. Nevét angol fordításban Harold Bluetooth, X. században élt dán királyról kapta, aki az akkori Dánia és Norvégia egy részét egyesítette
egyetlen
áfonyafogyasztásának
birodalommá, köszönhette.
a A
kékfogát
Bluetooth
pedig
logója
a
a király
folyamatos nevének
kezdőbetűiből áll skandináv rúna jelekkel (ᚼ-Hagall ᛒ-Bjarkan). A Bluetooth egyszerű, kis energiaigényű kapcsolatot biztosíthat egy viszonylag egyszerű és egy bonyolultabb eszköz között. Ezzel az egyszerűbb eszköz (és a bonyolultabb) lehetőségei is kibővülnek, összességében egy intelligens rendszert alkotnak. Az állapotfelmérő rendszer esetén is hasonló a helyzet, amikor az egyszerű mérő hardware a PC-re vagy telefonra küldi az adatot és fogadja az utasításokat. A beépített, az egész rendszert jelentősen drágító, nagy teljesítményű hardware-t igénylő megjelenítő és vezérlő modulok helyett egy már meglévő rendszer (PC, telefon) részeként működik, amelyhez akár több, más hasonló kis eszköz is kapcsolódhat.
23
6.1.1. Bluetooth az egészségügyben Az ipari, kutatási és szórakoztató elektronikai eszközök mellett a Bluetooth egyre inkább terjed az egészségügyi eszközök kommunikációs technológiájaként. Alkalmazzák lázmérők, vérnyomás és mellkasra csatolható pulzus és légzésmérők adatinak továbbításához. Ez kényelmet jelent a vizsgált személynek is, elég elképzelni egy sportolót a futópadon tele vezetékekkel vagy egyetlen Bluetooth modul segítségével csak az érzékelőkkel teleaggatva, amelyek bár saját áramforrást igényelnek mégsem annyira zavaróak, mintha egy oldalra futó vezetékre/vezetékekre kell figyelnie edzés, felmérés közben. A kis hatótáv és az interferencia elkerülésére alkalmazott megoldások lehetővé teszik, hogy egy viszonylag kis térben sok eszköz is használhassa különösebb zavarás nélkül a Bluetooth-t.
6.1.2. Jellemzői A Bluetooth, a kis hatótávú ipari, tudomány és gyógyászati sávba tartozó 2,4GHz-es tartományban működik. 2,4-2,485GHz-es tartományban üzemel, 72 frekvencián, amelyek 1MHz-re találhatóak egymástól. Az interferenciát elkerülendő ezeken a frekvenciák között másodpercenként 1600-szor vált adatátvitel során, ezt osztott spektrumú frekvencia-ugrásnak nevezik. Full-Duplex kapcsolatot valósít meg. Eredetileg GFSK (Gaussian Frequency Shift-Keying) modulációt használt, az újabb verziók π/4 DQPSK (Differential Quadrature Phase Shift Keying) és 8DPSK (Differential
Phase
Shift-Keying)
séma
szerint
működnek.
Az
eredetit
a
kapcsolatfelvételhez használja a rendszer az alap, 1Mbit/s-al valósul meg a kapcsolatfelvétel. Hatótávolsága és adóteljesítménye szerint 3 osztályba sorolják az egyes eszközöket: •
Class 1: főleg az iparban alkalmazott 100mW-os adóteljesítménnyel, melyhez 100 méteres hatótáv párosul.
•
Class 2: mobil eszközökben elterjedt 2,5mW teljesítmény és 10 méter hatótáv jellemzi.
•
Class
3:
a
legkisebb,
1
méteres
hatótávú
eszközök
osztálya
1mW
adóteljesítménnyel.
24
Az átviteli sebességet tekintve az első, 1.0 verzió 1Mbit/s névleges sebességre képes, 768kbit/s sebességet lehet valójában kihasználni. A 2.x verziók 3Mbit/s névleges és 2,1Mbit/s sebességre képesek. A következő 3.0 és 4.0 már 24Mbit/s névleges sebességen működik. Léteznek különféle Bluetooth profilok, amelyek különféle kommunikációs módokat írnak le az eszközök között. Egyik közülük az SPP vagyis Serial Port Profile, amelyet a készülő műszer is alkalmaz a kommunikációhoz. Az SPP az RS232 portot bővíti vezeték nélküli kapcsolattá. Mivel az alkalmazott mikrovezérlő, az Android rendszer és a Java is képes kezelni a soros portot kézenfekvőnek tűnt, hogy ezt alkalmazzuk. Talán a legegyszerűbb kommunikációs forma. Másik elnevezése az RFCOMM.
6.1.3. Az alkalmazott modul A rendszerhez jelenleg a BTM-112 jelű Class 2-es Bluetooth modult használjuk, több kapcsolódási felülettel rendelkezik, mint USB, SPI, UART. Ezek közül az UART-on kapcsolódik a mérőrendszerhez, mely lehetővé teszi a kétirányú adatáramlást is, ezáltal vezérelhető is a mérés. Bár létezik az egészségügyi eszközök számára külön profil a Bluetooth szabványban HDP (Health Device Profile), az új változat prototípusához szerelhető méretben az egyszerűbb SPP-t támogató modult sikerült beszerezni. Az SPP-t ezen felül biztosan támogatja a legtöbb mobil eszköz is.
6.2.
A saját kommunikációs keret
A műszer és a feldolgozó egység közötti párbeszédhez létrehoztunk egy keretet, amely az egyes utasításokat és a az adatokat továbbítja rendezett formában. A keret kitalálója Ferenc István Csaba aki a hardware vezérlő programját készíti, ebben a bekezdésben kerül ismertetésre maga a keret, amely a 10. ábrán látható.
10. ábra A kommunikációs keret
25
A keret két részből áll, egy fejrészből (Header) és egy adattérből (Payload). A fejrész tartalmazza a keret kezdetének jelzését 1 byte-ban, melyet a keret típusának kódja követ. A típusok listája a 11. ábrán látható. Az adattér adatküldés esetén értelmezendő, 4 byte hosszúságú, amely az egyes mintavételezések eredményét tartalmazza. Csoport
PC → µC utasítások
µC → PC nyugták
Jelentés
C/Java konstans neve
Érték
cRT induljon
START_CRT
231
sRT induljon Pletizm. ind. Tremor ind. cRT állj sRT állj Plet. állj Tremor állj PC oldali hiba
START_SRT START_PLET START_TREM STOP_CRT STOP_SRT STOP_PLET STOP_TREM PC_ERROR
232 241 251 211 212 214 215 1
cRT elindult
ACK_START_CRT
131
sRT elindult Plet. elindult Trem. elindult
ACK_START_SRT ACK_START_PLET ACK_START_TREM
132 141 151
Magas sípszó elh.
BEEP_H
31
Mély sípszó elh. BEEP_L Gombnyomás BTN Hibás gombnyomás BTN_ERR µC → PC Időtúllépés TIMEOUT adatok Pletizmográfia adat PLET X tremor adat TREM_X Y tremor adat TREM_Y Z tremor adat TREM_Z µC oldali hiba UC_ERROR 11. ábra A keret típusai (µC – mikrovezérlő)
32 33 34 35 41 51 52 53 2
Adat bájtok tartalma
üres
hibakód üres
üres reakcióidő [ms] üres érték [0,216] (fs=250Hz) érték [előjeles 16 bites] (fs=250Hz) érték [előjeles 16 bites] (fs=250Hz) érték [előjeles 16 bites] (fs=250Hz) hibakód
A táblázatból látható, hogy az a keret tekinthető érvényes keretnek, amely a szinkronjelzéssel kezdődik, majd valamely típussal folytatódik, a típus fogja eldönteni, hogy az adatmezőt csak megvárni kell vagy értelmezni is. Egy keret egyszerre két adatot továbbít egy típusból, amely lehet a valamely reakcióidő mérés (cRT, sRT), szívgörbe (Pletizmográfia) vagy a gyorsulásmérő adata (tremor). Szükséges, hogy a mérőegység is közölje az állapotát, ezzel ellenőrizhető, hogy rendben végbe ment-e a kívánt mérés elindítása, illetve, ha bármi hiba adódik, azt szövegesen a feldolgozó alkalmazás közli a felhasználóval. Ilyen például az akkumulátor töltöttsége, hibás érzékelő. A keret üresnek nevezett adatterét nem kell
26
a feldolgozó alkalmazásnak értelmezni, ott akármilyen adat is állhat, jelen esetben 1es értékekkel töltöttük fel.
6.3.
Az adatok fogadása
A fentebb ismertetett Bluetooth kapcsolatot használja a mobil alkalmazás az adatok
fogadására.
Az
Android
kényelmes
lehetőséget kínál
a
kapcsolat
létrehozására, beállítására és kezelésére. Egyszerűen megoldható, hogy az alkalmazás egy keresés után magától kapcsolódjon a mérőeszközhöz. Az adatok a felderítés és kapcsolódás után a Java-ban jól ismert InputStream osztály példányán keresztül egy byte-folyamként olvasható. Az alkalmazás gyűjti a beérkezett adatokat, az első keretszinkrontól átmeneti tárolóba helyezi a byte-okat majd keretként értelmezi. Az érvénytelen keretet eldobja, ha 5-nél több keret hibás, jelzi a felhasználónak.
6.4.
Utasítások küldése
Az Android az adatküldésre az InputStream párját, az OutputStream osztályt használja a Bluetooth kapcsolatnál. Egyszerűen byte-onként lehet az adatfolyamba írni a keretet. Az egyes utasítások elküldése után az alkalmazás vár a mérő hardware által küldött nyugtára, amennyiben 2 másodpercen belül nem érkezik nyugta az alkalmazás hibát jelez.
27
7. Adattárolás
7.1.
Lehetőségek az Android rendszerben
Az Android több különféle lehetőségeket kínál az adatok tárolására, két fő felhasználható tárolóval rendelkezik: az eszköz belső memóriája és az SD kártya, amely a bővíthető külső tároló. A belső memóriát a rendszer elrejti a felhasználó elől, a file rendszer tallózása a beépített böngészővel is az SD kártyára korlátozódik. (Léteznek az Android Market-en olyan alkalmazások, amelyek képesek a teljes file rendszer tallózására, de ezek jelenlétére a céleszközökön nem lehet építeni.) USB-re csatlakozáskor is az SD kártya tartalma kezelhető, olyan egyszerűen, mintha egy pendrive-ot csatlakoztattak volna a PC-hez.
7.1.1. Belső adatbázis – SQLite Az alkalmazásoknak lehetősége
nyílik
a
saját adataikat az SQLite
segítségével egy relációs adatbázisban tárolni. Használata megegyezik egy SQL adatbázis használatával. Maga az adatbázis a mobil készülék belső memóriáját használja. Az állapotfelmérő rendszernél az átmeneti adatok tárolásánál szóba került ez a lehetőség, azonban az adatállományok esetleges nagy mérete miatt (egy órás vizsgálat akár 5-10 MB adatot is jelenthet) elvetettem az ötletet. Ugyanis a belső memória főleg az alacsonyabb kategóriába tartozó készülékeknél néhány száz MBot tesz ki, amelyen helyet kapnak a telepített programok és azok által használt esetlegesen az adatbázisban lévő adatok is. Tehát előfordulhat, hogy olyan sok program kerül telepítésre, hogy már nincs hely egy vizsgálat adatai számára. Az itt tárolt adatok legkésőbb az alkalmazás törlésével automatikusan törlődnek.
7.1.2. A rendszer saját cache lehetősége Az alkalmazásoknak lehetősége van az SD kártyán is tárolni a saját adataikat egy adott helyen. A hely elérési útvonala az alkalmazás Java nyelven megadott
28
csomagnak felel meg az Android/data könyvtáron belül (például, alkalmazás
a
com.example.program
csomagban
található,
ha
az
akkor
az
Android/data/Com.example.program könyvtárat lehet használni). A könyvtárat beépített metódussal lehet létrehozni. Ez a metódus és használata az Android 2.2-től eltér az alacsonyabb verzióktól. Az ezen a helyen tárolt adatokat a rendszer számon tartja, az alkalmazás tulajdonságait lekérve jelzi, mennyi átmeneti tárolót használ, a program törlésével üríti a felhasznált területet is, mivel törli az alkalmazáshoz tartozó könyvtárat.
7.1.3. Saját mappa létrehozása Elterjedt módszer és talán a legegyszerűbb, (több, általam is kipróbált Android alkalmazás él ezzel a megoldással), hogy létrehoz az SD kártyán egy könyvtárat és abban helyezi el a működése közben szükséges átmeneti file-okat. Ennek jellemzője, hogy a program törlése után is megmarad, illetve a cache ürítésekor a rendszer nem törli. A file-okat olyan beállítással is létre lehet hozni, hogy az alkalmazáshoz tartozó virtuális gép bezárásakor (tehát a alkalmazás normális leállításakor) a file törlődjön, ellenkező esetben nem (vagyis, ha egy telefonhívás tette háttérbe az alkalmazást vagy valamiért nem rendesen állt le).
7.2.
Átmeneti file-ok
A mobil alkalmazáshoz a 7.1.3-as pontban leírt lehetőséget választottam. Az indításkor egy folyamat ellenőrzi az SD kártya meglétét, ha nincs csatolva, akkor a program leáll, mert anélkül nem érdemes működnie. Ha van SD kártya, akkor ellenőrzi a Tremometer könyvtár és alkönyvtárainak a meglétét, ha nincs, akkor létrehozza a Tremometer könyvtárat és azon belül egy temp könyvtárat. A Tremometer könyvtáron belül találhatóak a lezárt mérések és a temp könyvtárban a mérések átmeneti adatai vagy a megnyitott mérésekből készült átmeneti file-ok. Mivel az SD kártya használatával lehetőség van az alkalmazás memóriahasználatát csökkenteni. Ismert módszer Android rendszer esetén, hogy a készülék esetenként szűkös memóriakészletét úgy növelik, hogy az SD kártya egy részét is RAM-ként
29
használja a rendszer. Jelen esetben ez azt jelenti, hogy az átmeneti file-okból mindig csak a szükséges adatmennyiséget olvassa be a készülő alkalmazás. Az alkalmazás a szükséges adatállományokat egyedi névvel látja el, hogy a már meglévőt ne írja felül, egyszerű sorszámozással. Egy külön osztály tartja számon, hogy az adott állományok melyik személyhez tartoznak.
7.2.1. Mérés közben Mérés alatt az alkalmazás a pletizmográf és tremor mérések eredményeit 4 bináris átmeneti file-ba menti folyamatosan (a pletizmográfia egy adatállományt igényel a tremor vizsgálat a gyorsulásmérő 3 tengelyének adatait 3 állományba menti). A reakcióidő mérés nem jelent túl nagy adatmennyiséget, az adatvesztés elkerülése végett ezt is külön átmeneti file-ba menti az alkalmazás. Minden gombnyomáshoz tartozó értékeket külön-külön sorban helyezkednek el.
7.2.2. Egy vizsgálat megnyitásakor Egy mérés állományai kis átalakítást követően egyetlen zip file-ba kerülnek, ennek megnyitásakor szintén létrejönnek az átmeneti állományok, mint méréskor. Ezeken
végezhető
el
néhány
művelet,
így
az
eredeti
adatok
véletlen
megváltoztatását is el lehet kerülni.
7.3.
Egy vizsgálat mentése
Az Android alkalmazás és a PC-s programnak közös állományt kell használnia, hogy bármelyiken készített, szerkesztett mérést a másikon is meg lehessen jeleníteni. Ezért a feladat e része igényelte a legfőbb csapatmunkát a PC-s program készítőjével, Simon Csabával.
7.3.1. Az adatállomány Az adatállomány a *.jar vagy *.apk file-ok mintájára egy több file-t tartalmazó zip eljárással tömörített állomány. Tartalmaz egy XML file-t, amely a vizsgált alany személyes adatait tartalmazza RSA kódolással és egy másik XML állomány kódolás nélkül a reakcióidő mérés adatait. Továbbá több bináris állományt, amely az egyes
30
mérésekhez tartoznak, lényegében az átmeneti állományokat másolja ide az alkalmazás, így nem szükséges külön átalakítás és visszaalakítás, amely csak lassítaná a folyamatot. Az mérés eredményeit nem titkosítjuk, mert csak azokból nem lehet kitalálni, hogy kihez tartoznak.
7.4.
Az adatállomány szerkezete
Az alkalmazás által épített zip eljárással tömörített adatállomány több belső állományban tartalmazza a szükséges információkat, a következő szakaszokban ezek szerepe, felépítése kerül bemutatásra.
7.4.1. A vizsgált személy adatai A szemelyesAdatok nevű XML állomány tartalmazza a vizsgált személyhez tartozó legfontosabb információkat. Az állomány felépítését a 12. ábra szemlélteti. Ilyen a neve, címe (város, utca, házszám), születési dátuma és a TAJ száma. Ezek az adatok RSA titkosítással kerülnek elrejtésre az illetéktelenek szeme elől, csak az tudja, kiről készült a vizsgálat, aki rendelkezik a mobil vagy a PC-s kiértékelő alkalmazással.
<patient> Név 111111111 1900-01-01 Város <street>Utca 00 Megjegyzés 12. ábra szemelyesAdatok szerkezete
31
Ez az állomány tartalmazza a adatokhoz fűzött megjegyzéseket is szintén RSA kódolással. A megjegyzések tag-ek tulajdonságai tartalmazzák, hogy mely adatsorhoz és azon belül melyik szakaszhoz tartozik. Az egyes megjegyzések elláthatók fontossági jelzővel, mely egy egész szám és a 0 a kevésbé fontos a 2 pedig a nagyon fontos megjegyzéseket jelöli. A tag-en belül található a megjegyzés szövege, amely kódolt. A megjegyzések közül az első kitüntetett szereppel rendelkezik, ez a lelet vagy összegzés a vizsgált személy állapotáról. Ez a megjegyzés nem tartozik egyetlen adatsorhoz sem.
7.4.2. Az állományhoz fűzött megjegyzés Egy Comment nevű állomány tartalmazza a vizsgálat körülményeit, időpontját és bármilyen kiegészítést, amely megkönnyíti, hogy az adott személyhez tartozó méréseket el lehessen különíteni, azonosítani. Szintén kódolt szöveget tartalmaz az állomány.
7.4.3. Reakcióidő A reakcióidő mérés eredményeit egy külön RT nevű XML állomány tárolja. Az egyes tag-ek tulajdonságai rögzítik a reakcióidő mérés típusát (sRT, cRT), a beérkezett jeleket és az azokra érkezett reakciót. Tárolja azt is, ha a vizsgált személy nem a célingerre reagált vagy csak megnyomta a gombot cél vagy zavaró inger nélkül is. Ez az állomány nem kerül titkosításra, mivel nem azonosítható az adatok alapján, hogy kivel készült a vizsgálat.
13. ábra Az RT állomány szerkezete
32
7.4.4. A bináris adatok helye A pletizmográfia eredményeit a plet, és a tremor vizsgálat gyorsulásmérője által közvetített, három jelfolyam adatait az irányoknak megfelelően a trem_x, trem_y, trem_z nevű állományok tárolják binárisan. Egy-egy adat 4 byte hosszú bináris szám.
33
8. Felhasználói felület A felhasználói felület tervezése egy egészen fiatal és új irányát kell megismerni, mégpedig egy érintéssel vezérelt felület kialakítása a feladat. Némileg hasonlít az egér és billentyűzet által vezérelt rendszerekre, mégis sok új lehetőség rejtőzik benne. Azoknak a tervezőknek, akik a hosszú idő alatt bejáratott rendszerhez szoktak, sokszor furcsa és nehézkes ennek az új iránynak a használata, kihasználása. Saját tapasztalat, hogy a fejlesztésre szánt telefon használatát megtanulni néhány hétbe telt, utána értettem csak meg miben kell másként gondolkodni, a hagyományos alkalmazásokhoz képest. Annak ellenére, hogy nem tudhatok magam mögött több száz programfelületet, mint sok hivatásos és tapasztalt fejlesztő a kész programok használata nyomán megtanultam nagyjából milyen a kényelmes felhasználói felület és melyik az, amit borzalmas használni. Nem egyértelmű az sem, mi a kényelmes és mi nem, például egér használata esetén, egy PC monitorán szinte mindegy hol van a gördítő sáv, de ha a számítógépet balkezes embernek egy tollal kell vezérelni, a rendszeresen jobb oldalra helyezett gördítő sávok inkább bosszantóak, mint hasznosak…
8.1.
Az Android képernyő
Az Android más rendszerekhez hasonlóan, egy
keretrendszert
kialakításához. különféle
nyújt
A
a
grafikus
lehetőségeket
elrendezés
kezelőket,
felület tekintve
esemény
figyelőket és vezérlő elemek széles palettája áll rendelkezésre
a
felület
tervezéséhez,
ha
mégsem elég, akkor a tervező saját magának is létrehozhat új képernyőelemet valamely meglévő osztályának leszármaztatásával. Az 14. ábrán látható egy képernyőkép az Android rendszerről. Az emulátoron található változat
alapképernyője.
A
képen
legfelül 14. ábra Az alap képernyő az emulátoron
34
helyezkedik el az állapotsáv. Ez tartalmazza a szolgáltatások ikonjait, szöveges üzeneteit. Ilyen például az óra, akku töltöttség jelzés, hálózat jelszintje és típusa. Ezt az állapotsávot lehúzva részletezi a program milyen éppen futó szolgáltatások érhetőek el, különféle állapotüzenetek listája (USB tároló csatlakoztatva, új alkalmazás települt és innen azonnal el is indítható). A képernyő nagy részét az ikonok és úgynevezett widget-ek számára fenntartott hely foglalja el, amelyet egy felhasználó által választott háttérkép díszít. Az emulátoron a telepített alkalmazások listáját a legalsó szürke nyíl felfelé húzásával lehet elérni. A főképernyőre és az alkalmazások listájára is érvényes, hogy lapozható vagy gördíthető, bár a főképernyőből nagyrészt lapozható változat létezik. A haza gomb bárhonnan azonnal a főképernyőre viszi a felhasználót, ha az adott alkalmazás készítője másként nem rendelkezett.
8.2.
Android gombok – fizikai vezérlő elemek
Az Android rendszert futtató készülékeken általában 4 gombot lehet találni, esetleg kiegészítik hangerőszabályzó gombokkal és fényképező gombbal. A 4 gomb közül az egyik, a haza gomb, amely bárhonnan a főképernyőhöz lép, az éppen megnyitott alkalmazás háttérbe, leállított állapotba kerül, ha szolgáltatás, akkor csak a háttérbe. Hosszan lenyomva tartva a legutóbb használt hat alkalmazás közül lehet választani. A másik a vissza gomb. Ismerős lehet a böngésző programokból, szerepe is hasonló, mindig az előző képernyőre lép vissza. Következő a menü gomb, amely hatására bármely alkalmazás, amely reagál erre a gombra előhoz egy menüt. Általában ez a képernyő aljáról úszik fel, de akár egy párbeszédablak-szerű menü is lehet. Az alapértelmezett menü 6 menüpontot tartalmaz, ha azonban hatnál több menüpontot tartalmaz a menü, akkor a hatodik pont egy továbbiak menüpont lesz. A továbbiakra bökve egy lista jelenik meg a további menüpontokkal. Az egyes menüpontok ikonokkal díszíthetők. Végül a keresés gomb, amely sok készülékről lemarad, de mégis lehet hasznos is. Hatására vagy az alapértelmezett kereső vagy az alkalmazás saját
35
keresője jön elő (ha a programozó készített ilyet az alkalmazásba, ha nem akkor általában a Google keresője bukkan elő).
8.3.
A készülő alkalmazás képernyői
Az alkalmazás működését a főbb képernyők segítségével mutatom be.
8.3.1. Vizsgálat Az alkalmazás elindítását követően a 15. ábrán látható képernyő fogadja a felhasználót. A vezérlő
gombok
a
PC-s
alkalmazáshoz
igazítottan kaptak ikonokat. A gombok közül mindig
az
aktív,
felhasználó,
ezért
amelyet
használhat
kezdetben
csak
a az
adatrögzítés gomb elérhető. Az adatrögzítés gomb hatására elindul a kiválasztott vizsgálat, ha még nem csatlakozott a felhasználó a mérőegységhez, ezt megteheti a felugró párbeszédablakban (külön jelzi, ha nincs elérhető Bluetooth kapcsolat), majd az elvégezni kívánt vizsgálatokat kell kiválasztania. A vizsgálat szüneteltetését is kérheti a felhasználó, például akkor, ha meg kell igazítani a vizsgált személyen a készüléket. A stop gomb segítségével fejezi be a vizsgálatot és mentheti el az adatokat. A vizsgált személy adatait a vizsgálat ideje
15. ábra A vizsgálat képernyője éppen megállított szimulált mintavételezéssel, látható menüvel, kikapcsolt Plet vezérlővel és láthatóvá tett nagyító gombbal a tremor grafikonon. (Az emulátor megjelenítési hibája miatt nem látszik a grafikon teteje.)
alatt egy párbeszédablakban veheti fel a felhasználó. A gombok alatt a grafikonok láthatók. Az első a pletizmográf adatait jeleníti meg, a második a tremoron végzett FFT analízis eredményét az utolsó pedig a reakcióidő-mérés eredményeit. Utóbbinál lehetőség van választani sRT és cRT mód között (egyszerű vagy feltételes reakció idő).
36
A grafikonok érintésére eltűnnek a vezérlő elemek, hogy ne zavarják a jelek figyelemmel kísérését, újabb érintésre láthatóak lesznek. A grafikonok simításra gördülnek a simítás irányának megfelelően. A pozíciót gördítésnél a grafikon tetején megjelenő sáv jelzi. A nagyítás, kicsinyítés lehetőségét biztosító vezérlő is érintésre jelenik, meg majd tűnik el. A grafikonok kirajzolását egy háttérszál végzi. A mérés háttérszolgáltatásként fut, így egy telefonhívás sem szakíthatja meg az vizsgálatot. A vizsgálatot segíti egy külön bekapcsolható időzítő, amely rezgéssel és a képernyőre írt üzenettel tájékoztatja a vizsgáló és a vizsgált személyt a következő teendőkről. Vizsgálat közbeni súgóként üzemel. Az utasítások megjelenítésére a Toast nevű osztályt használtam. A menü elemei fentről kezdve és balról jobbra haladva: új személy felvétele, mentett mérés megnyitása, mérés mentése, kapcsolódás Bluetooth-on keresztül egy mérőegységhez, vizsgálatot segítő időzített súgó.
8.3.2. Adatfelvitel párbeszédnézet A vizsgált személy adatait akár a mérés közben is fel lehet vinni. Ezt szolgálja a 16. ábrán látható űrlap. A szöveget váró mezők érintése esetén
a
rendszer
szövegbevitelre
alkalmas
szolgáltatásaként billentyűzet
jelenik
meg, számmező esetén (TAJ) számbillentyűzet jelenik meg, a hónapokat pedig egy, a hónapok neveit tartalmazó billentyűzet áll a felhasználó segítségére. A mentés gombra bökve az adatok mentésre kerülnek, újbóli megnyitás esetén a már
kitöltött
mezők
kitöltve
jelennek
meg.
Felülírásuk az adott rész felülírását eredményezi (csak akkor, ha tényelegesen írnak is bele, véletlen érintéskor nem törlődik az adat). A
bevitelt
a
rendszer
által
nyújtott
úgynevezett HintText segíti, amely beírásig jelzi, 16. ábra Az adatfelvitel űrlap teteje. Az
emulátor angol beállításainak megfelelően rendezi a rendszer a dátum mezőit.
37
hogy mit kell az adott mezőbe írni az ábrán ilyen például a „Vezetéknév Keresztnév” szöveg. A teljes űrlap nem fér ki a képernyőre, a Lelet és a vezérlőgombokhoz ilyen kis képernyőn a felhasználónak egy egyszerű mozdulattal kell gördítenie a további elemek eléréséhez.
8.3.3. Megnyitás párbeszédnézet Az alkalmazás a saját könyvtárában található mentett méréseket egy párbeszédablakban
listázza.
A
kiválasztott
személy
adatai kirajzolódnak
a
grafikonokra, ekkor az adatgyűjtést vezérlő gombok eltűnnek.
8.3.4. Bluetooth párbeszédnézet A Bluetooth kapcsolat a mérés kezdetekor vagy bármikor a menüből választható. A megtalált mérőegységeket listába foglalja az alkalmazás, a kiválasztotthoz kapcsolódik. Jelvesztés esetén megpróbál önállóan újracsatlakozni a már kiválasztott mérőegységhez, ha az újra hatókörön belül van. A jelvesztést természetesen jelzi a felhasználónak, addig az adatgyűjtés is leáll.
38
9. Fejlesztési tervek Az alkalmazás ezen leírása csak egy pillanatkép a fejlesztés folyamatából. Ahogy a hardware-k is egyre fejlettebbek, egyre több hasznos szolgáltatást lehet elhelyezni a mobil alkalmazásban. A lehetőségek sora szinte végtelen, azonban meg kell találni azokat, amelyek ténylegesen segítik a mobilizált mérést. Bár a jelenlegi alkalmazás sem aknázza még ki a fejlesztésre használt készülék nyújtotta lehetőségeket. Bár jelenleg az országban nem üzemel egységes egészségügyi adatkezelő rendszer, a jövőben egy ilyen hálózathoz is csatlakozhat ez az állapotfelmérő rendszer. Esetleg ennek a rendszernek egy saját adatbázis létrehozható, ahová a lezárult vizsgálatok adatait az orvos feltöltheti, ahol szakemberek illetve egy automata rendszer elemezheti, összevetheti az adatokat a régebbi esetleg más vizsgálatokkal. Az eredményeket pedig kérésre visszaküldheti a vizsgálatot végző orvosnak. Egyfajta felhő szolgáltatásként működhet a rendszer. További haszna, hogy a mobilinternet segítségével bárhol elérhetővé válik az orvosok az éppen vizsgált beteg kórelőzménye. Egy ilyen rendszer nem csak az állapotfelmérő készülék számára lenne előnyös, hanem általában az egészségügyben is, ugyanis jelenleg szinte minden kórház és rendelőintézet saját, egymástól független, sokszor elavult, zárt rendszert használ, így ha valakit a szokott intézetétől távol szükséges gyógyítani, vagy önmaga mondja el a kórelőzményét vagy az ellátó orvos kénytelen nyomozni. További lehetőség az is, ha egy mobilszolgáltató támogatni kezdi ezt az egészségügyi állapotfelmérő rendszert. Elképzelhető egy célirányosan erre a rendszerre létrehozott díjcsomag, egy korszerű készülékkel, amelyen megtalálható az állapotfelmérő rendszer is előre telepítve, hogy a felhasználónak már ne kelljen bajlódni vele. Ehhez további szükséges fejlesztés az önmagát frissítő mobil alkalmazás. Az egészségügyi rendszereket támogatja például a Telenor, a Telenor Connexion elnevezésű program keretében.
39
10. Összefoglalás Egy egészségügyi állapotfelmérő rendszer tervének megvalósítására alakult a Miskolci Egyetem mérnök informatikus és villamosmérnök hallgatóiból egy néhány fős csapat, hogy a prototípusból sorozatgyártásra alkalmas, olcsó és az orvosok által széles körben hozzáférhető eszközt tervezzen. A rendszer egyszerű vizsgálatok segítségével (pletizmográfia, tremor analízis és egyszerű vagy feltételes reakcióidő-mérés) képes több idegrendszeri és keringési és időskori betegséget eredményesen előre jelezni. Ugyan nem helyettesíti a drága és precíz mérőberendezéseket, csupán egy gyors és eredményes előszűrésre alkalmazható, amely megadja, hogy szükséges-e a további vizsgálat vagy sem. A vizsgálat elvégzése után még időben elkezdhető a felismert probléma kezelése, így javítható az emberek jövőbeli életminősége. Mivel a rendszer tervezése egy embernek túl nagy feladatot jelentett volna, több részre osztottuk. A felosztás szerint külön feladattá vált a mérőegység és annak a firmware-ének elkészítése, másik feladat az asztali számítógépre egy adatgyűjtő, kiértékelő és egyszerű adatbázis-kezelést megvalósító program és az általam vállalt, mobil készülékek számára Android operációs rendszerre készített adatgyűjtő és megjelenítő alkalmazás készítése. A jelen kor rohamosan fejlődő készülékei, az okos telefonok lehetővé tették, hogy a mérőegység egyszerű kivitelű, könnyen hordozható és külön asztali számítógép vagy laptop jelenléte nélkül is szinte bárhol bevethető legyen. Magának a mérőegységnek nincs saját kezelőszerve, külön belső adattárolója. A vezérlést és az adattárolást, adatok grafikus megjelenítését az okos telefon végzi, az információcsere a kiselektronikai eszközök körében elterjedt Bluetooth kapcsolaton keresztül történik. A kisméretű mérőegység és az elterjedt, naponta használt telefonok segítségével az orvosi táska kellékévé válhat az állapotfelmérő készülék. A telefonra készített adatgyűjtő és megjelenítő alkalmazás képes néhány gyors elemzés elvégzésére és lehetővé teszi rövid jegyzet készítését a vizsgált személy adatainak rögzítése mellett. A vizsgálatok eredményeit aztán az orvosok az asztali
számítógépekre
készített
program
segítségével
tovább
elemezhetik,
összevethetik régebbi vagy más eredményekkel is.
40
11. Köszönet Köszönet illeti a dolgozatban felsorolt személyeket, hogy a feltaláló Dr. Kellényi Lóránd a Miskolci Egyetemet bízta meg a Bay Zoltán Alkalmazott Kutatási Közalapítvány Nanotechnológiai Kutatóintézetének akkori igazgatóján, Dr. Pungor Andráson keresztül, aki értesítette Dr. Gáti Attila egyetemi docenst az ipari feladatról. Dr. Gáti Attila élt a lehetőséggel és hallgatókat toborzott, akik számára a feladatból remek szakdolgozat és TDK téma válhat, amely eltér a szokásos feladatoktól és kézzel fogható eredményhez vezet. A valós volta miatt sokkal érdekesebb, mint egy általános szakdolgozati téma, mely talán egy fiók mélyén végzi. A feladat megoldása alatt kiváló szakmai irányításával és támogatásával segítette a lelkes hallgatók munkáját. Akkor, 2009 januárjában engem Fodor Gábor Dénes hallgatótársam hívott fel, hogy volna-e kedvem egy kutatási feladathoz. Szerencsére igennel válaszoltam, mint a csapat másik tagja Ferenc István Csaba. Szintén a csapat tagja, bár csak idén csatlakozott a PC-s program fejlesztéséhez, Simon Csaba. A nullszéria tervezésénél és gyártásánál a csapat tagja volt Tóth Gábor villamosmérnök hallgató is, aki sokat segített a tervezésben és kivitelezésben. Köszönet illeti Dr. Zambóné Benkő Máriát, aki vezette és erőforrásokat biztosított a feladat megoldásához. Továbbá az Elektrotechnikai és Elektronikai Tanszék dolgozóit és a tanszék vezetőjét, akik megengedték, hogy használjuk az V. labort a munkánk során. A feladatot belátható időn belül egyedül egyikünk sem tudta volna elvégezni, egyértelműen több ember összehangolt munkáját kívánó feladatot kaptunk és értékes útravalót az életünk további állomásaira.
41
Források • • • • • • • • • • • • • • • •
Dr. Kellényi Lóránd által rendelkezésünkre bocsájtott dokumentumok Simple and choice reaction times are prolonged following extracorporeal circulation: A potential method for the assessment of acute neurocognitive deficit, © Med Sci Monit, 2009; 15(9): CR470476, PMID: 19721398 Dr. Norbert Kovács Electrophysiological investigations in neurosorgically treated movement disorders, Ph.D. thesis, University of Pécs, 2008 Kovács Norbert, Balás István, Illés Zsolt, Kellényi Lóránt, Nagy Ferenc: A tremorometria szerepe az ablatív műtétek eredményességének előrejelzésében, Ideggyogy Sz 2006;59(11–12):438–440 www.android.com http://developer.android.com http://developer.apple.com http://nyelvek.inf.elte.hu/leirasok/MOBIL_J2ME/index.php?chapter=2 http://create.msdn.com/en-us/home/getting_started www.bluetooth.com http://en.wikipedia.org/wiki/File:Smartphone_share_current.png http://www.oracle.com/technetwork/java/javame/java-me-overview-402920.html http://www.hazipatika.com/articles/iPhone_uj_diagnosztikai_eszkoz_az_orvosok_kezeben?aid=201 01026162213 http://www.telenor.hu/uzleti-megoldas/m2m/telenor-connexion/egeszsegugy/ http://www.youtube.com/user/androiddevelopers Nyékyné Dr. Gaizler Judit: Java 2 útikalauz programozóknak 5.0 I-II. (2009) ISBN: 9789630640923 Hivatkozások ellenőrizve: 2011-11-07.
42
