Az IoT eszközök alkalmazási lehetőségeinek vizsgálata az egészségmegőrzésben

Az alábbi kézikönyv betekintést nyújt a napjainkban egyre nagyobb népszerűségnek örvendő IoT (Interntet of Things – Tárgyak Internete) koncepció alapján kialakított adatgyűjtő eszközök és Big Data koncepció alapján kialakított adatkezelő eljárások egészségügyben betöltött alkalmazhatóságáról. A továbbiakban rövid elméletet követően több gyakorlati teszttel alátámasztva igyekszem bemutatni a területre jellemző lehetőségeket. Egyre nagyobb számban találkozhatunk krónikus betegségben szenvedőkkel, melynek kialakulásához nagyban hozzájárulnak a helytelen étkezési szokások, a fizikai aktivitás hiánya, és a magas alkoholfogyasztás (Gómez, Oviedo and Zhuma, 2016). Egyes nem fertőző betegségek nem-fertőző betegségek, mint a szív- és érrendszeri betegségek, cukorbetegség, daganatos megbetegedések és krónikus légúti megbetegedések) jelentős mértékben követelnek áldozatokat (Puri et al., 2020). A hosszú távú egészségügyi ellátáshoz nélkülözhetetlen a különféle fiziológiai információk folyamatos nyomon követése a mindennapi élet különböző forgatókönyveiben, akár alszunk, akár ébren vagyunk, de ugyanúgy kültéren és beltéren (Tamura and Chen, 2017). Ennek megfelelően az aktivitás és az étkezési szokássok kulcsfontosságú faktorként befolyásolják az említett problémák felmerülését (WHO, 2003; Sikorska-Siudek, Olȩdzka-Orȩziak and Parzuchowska, 2006). A problémák leküzdése és megelőzése döntéseket igényel a fizikai aktivitást, étkezést, gyógyszeradatok meghatározását érintően, melyhez egyes paraméterek (például: vérnyomás, súly) mérésekre van szükség, ám ezen mérések sok esetben nem kerülnek kivitelezésre (McConnell et al., 2018), ám megfelelő mérések esetében sem garantált az adatok releváns alkalmazása.

Ennek megfelelően a továbbiakban az úgynevezett Smart Health (okos egészségügy) koncepció alá eső rendszerekkel fogunk foglalkozni. A digitalizációval együtt megjelent a Health 4.0 koncepció, mely jelentősen épít az Industry 4.0 koncepció meglévő pillérjeire, mint az IoT (Internet of Things), vagy Big Data koncepció, emellett hasonló elvekkel jellemezhető, mint az interoperabilitás, virtualizáció, decentralizáció, valós idejű képesség, szolgáltatás orientáltság és modularitás (Thuemmler, 2017). Bár korábban az úgynevezett lágy valós idejű szolgáltatások voltak jellemzők (Shin and Ramanathan, 1994), melyek lehetővé tettek bizonyos fokú eltolódást, manapság egyre nagyobb igény mutatkozik a teljes valós idejű lehetőségekre, mivel veszélyhelyzetek esetén, mint egy szívinfarktus vagy elesés, pár másodperc vagy perc is életmentő lehet, mégpedig a folyamatos felügyelet lehetőséget biztost az események azonosítására és a beavatkozásra (Alemdar and Ersoy, 2010).

Az egészségügyben alkalmazott, területet érintő eszközök három fő kategóriába sorolhatók:

1. Hordható eszközök
2. Asztali eszközök
3. Környezeti eszközök
4. Belső eszközök

A hordható eszközök olyan megfigyelési módszerként kerülnek definiálásra, mely rendszerint viselésre kerül a felhasználó által mindennapjaiban. Az eszközök általában integrálásra kerülnek különböző használati tárgyakba, mint órák, szemüvegek, gyűrűk, mellények, kesztyűk, övek, ingek, melltartók, cipők, nyakláncok és hajcsatok (Tamura and Chen, 2017). Ezen eszközök rendszerint elválaszthatatlanok a hordozó használati tárgytól. Számos formában találkozhatunk hordható eszközökkel, egyszerűbb esetet figyelembe véve aktivitásmérők formájában (Warraich, 2016), ám hőmérséklet, nyál, légzés, izzadság, vérnyomás, véroxigénszint, seb, könny (Lou et al., 2020) egyes paraméterei is mérésre kerülhetnek.

A technológiai fejlődés, lényeges előrelépést jelentett a hordható eszközök aspektusában. Az új MEMS (mikroelektronikai és mechanikai rendszerek) és más támogató technológiák jelentősen csökkentették egyes elektronikai, mechanikai, optikai, kémiai paraméterek mérésére alkalmas szenzorok költségeit A hatékony adattárolási megoldások szintén lehetővé teszik a kis méret mellett történő adattárolás problémáját. A számítási teljesítmény javulása lehetővé teszi eszközszintű döntések kivitelezését, valós idejű jelfeldolgozással. Az integrálható gépi tanuló algoritmusok lehetővé teszik a mintázatok felismerését, mely azonnali visszajelzést nyújt egyes helyzetek bekövetkezése esetén. A vezeték nélküli kommunikációs lehetőségek bárhol elérhetővé teszi az egyes adatokat a felhő alapú megoldások filozófiája alapján. Végül az érthetőség javítása révén, szintén köszönhetően a számítási teljesítmény javulásának, lehetőség nyílik új visszajelzési módszerek alkalmazására, beleértve tapintható, hallható, vizuális vagy haptikus jelek által (Sazonov and Neuman, 2014).

Az asztali eszközök esetében olyan mérőeszközökről beszélünk, melyek eddig is rendelkezésre álltak (vérnyomásmérő, vércukorszintmérő, EKG, véroxigénszint mérő), ám a technológia által kiegészítésre kerültek hálózati kapcsolattal a külső eszközökkel való kommunikáció megvalósítása érdekében, ezzel hozzájárulva a teljes adathalmazhoz. Mivel az asztali eszközök egy korábbi technológia kiterjesztését szolgálják, kevesebb kutatás áll rendelkezésre a területen, mivel a legnagyobb újítás a kommunikációs protokollok támogatása, mely inkább a hordható eszközöknél számít műtelt területként.

A környezeti eszközök rendszerint környezeti tárgyakba implementált mérőeszközöket jelentenek (ágyak, székek, asztalok, fürdőkádak, tükrök, lámpák), melyek rendszerint a felhasználó figyelme nélkül kerülnek alkalmazásra (Tamura and Chen, 2017). Bár nem feltétlen realizáljuk ezen eszközök hatását az egészségügyben, de a Smart Home (okos otthon) koncepciója alapján számos lehetőség rejlik az alkalmazásában. Az okos otthon koncepciója jelenleg az EU 10 prioritást élvező területe a Stratégiai energiatechnológiai terv szerint (Wilson, Hargreaves and Hauxwell-Baldwin, 2017). A terület aspektusában releváns Health Smart Home (HSH) és Healthcare Monitoring Systems (HMS) koncepció a mindenütt jelenlévő számítástechnika és kommunikációs technológiák közös halmaza, mely bíztató alternatívákat biztosít az elektronikus egészségügy területén (Mshali et al., 2018). Egyszerűbb esetben csak a belső és külső levegő minőségének felügyeletéről beszélünk, mely által többletinformáció áll rendelkezésre a szellőztetés, fűtés, hűtés, ablaknyitás, árnyékolás aspektusában (Schieweck et al., 2018), de ugyanúgy mérésre kerülhetnek a lakók aktivitásának jellemzői (Mocrii, Chen and Musilek, 2018), sőt a gyógyászati készítmények alkalmazásának időpontja és egyéb paraméterei is. (Alemdar and Ersoy, 2010), vagy más, összetettebb műveletek egységesítése, mely ezt követően osztályozó algoritmusok segítségével válik értelmezhetővé (Dawadi, Cook and Schmitter-Edgecombe, 2013). Amennyiben ezen adatok együtt kerülnek alkalmazásra fúzió által egészségügyi adatokkal (szívritmus, vérnyomás, légzés üteme, emésztőrendszeri jellemzői, ECG adatok), illetve viselkedéssel kapcsolatos adatokkal (stressz, szorongás, nyugtalanság), sokkal pontosabb riasztórendszer kialakítására van lehetőség (Verma and Sood, 2018).

Belső eszközök esetében olyan megoldásokra gondolunk, melyek a testen belül kerülnek elhelyezésre mesterséges úton, légzéssel, vagy azok lenyelésével (Lai et al., 2013). Ezek alkalmazási területe az egyszerű RFID eszközöktől (Ullah, Shah and Zhang, 2016), a lenyelhető kamerákon át egészen szofisztikált, agy stimulálására, szívprobléma felügyeletére, vércukorszint ellenőrzésére (Darwish, Ismail Sayed and Ella Hassanien, 2019), vagy épp szájban lévő baktériumok mérésére (Vellappally et al., 2019) alkalmazhatók.

A különböző koncepciók implementálása során át kell látnunk, hogy mi is történik azon idő alatt, míg a karóránkban lévő szenzor méréséből egyszer csak a telefonunk kijelzőjén lévő szöveg vagy épp diagram jelenik meg. A tananyag végére persze senkiből nem válik mérnök, nem is ez a cél, hanem sokkal inkább a folyamat megértése, mely által elkerülhetjük az irreális elvárásokat a koncepciók alkotása során, vagy épp más nézőpont alkalmazásával optimalizálhatjuk ötleteinket, mielőtt megvalósítanánk azokat vagy épp jelentős forrásokat használnánk fel a megvalósításának kísérletére. Ennek megfelelően több lépcsőn keresztül fogjuk vizsgálni a különböző szenzorokat, vezérlőket és kommunikációs lehetőségeket. Több tényező egyszerűsítve kerül bemutatásra, mely köszönhető a felhasználóbarát módon, magas absztrakció mellett kialakított eszközparknak, melyet a tananyag olvasói szabadon elérhetnek a korábbiakban közzétett hivatkozások segítségével.

Legyen az bármilyen eszköz, beleértve egy fitneszkarkötőt, vagy épp egy hálózati kapcsolattal rendelkező vérnyomás, illetve vércukorszintmérő, amikor megnyomjuk a mérés gombot (vagy épp eljön az ideje a mérésnek) az alábbi folyamat zajlik le az eszköz működésében:

Elsőre nem is tűnik bonyolultnak, igaz? Reméljük, hogy ez így is marad a kísérletek végére. Lényegében van valamilyen szenzorunk, mely paraméter mérésére alkalmas, jelen aspektusban közvetlenül vagy közvetetten befolyásolva az egészségi állapotot rövid vagy hosszútávon. Ez kapcsolatban áll egy vezérlővel, ami lényegében diktálja annak feladatát az általunk meghatározott célt ellátva. Most viszont jön egy fordulat, ugyanis egyes szenzorok úgymond passzívan vannak jelen a folyamatban (analóg szenzorok), melyek lényegében egy higanyos hőmérőhöz hasonlíthatók, ugyanis valamilyen fizikai jelenség révén közlik velünk az adott paraméter változását, tehát érzékenyek valamilyen faktorra. Ezzel szemben a digitális szenzorok saját vezérlővel rendelkeznek, tehát az esetükben mondhatjuk, hogy két eszköz beszélget. Az utóbbi szenzorok esetében hasznos a kutatás során fejlesztett Open Health Connector programkönyvtár, ugyanis ennek feladata, hogy egységes módon kezelhessünk minden rendelkezésre álló szenzort, amik amúgy a motorháztető alatt teljesen más módon működnek, ezzel megnehezítve az emberek munkáját. De mindenekelőtt vizsgáljuk meg, hogy milyen szenzorok is alkalmazhatók az egészségügy területén, illetve ezek milyen formában kerülhetnek csoportosításra. A szakirodalmat vizsgálva láthatjuk, hogy meglehetősen szerteágazó csoportosító elvekkel találkozunk, melyek során az egyes szintek keverednek egymással, ezzel meglehetősen pontatlan csoportokat eredményezve. Ennek megfelelően igyekeztem az olvasók számára egy valóságosabb csoportosító elvet kialakítani, melynek mentén fokozatosan fogunk haladni.

Az imént beillesztett ábrát szinte biztosan nem tudjuk értelmezni, mivel – valljuk be őszintén – egy káoszról beszélünk. Minden összeköttetésben van mindennel, de ez egyúttal megadja terület jellegzetességét. Balról jobbra haladva az első réteg a szenzorok elhelyezkedésére vonatkozik. Jelen esetben hordható és rögzített eszközök kerültek definiálásra a rendelkezésre álló lehetőségek alapján. Hordható eszközök esetében értelemszerűen olyan eszközökről beszélünk, melyek valamilyen módon a felhasználóhoz kapcsolódik (a korábban említett lehetőségek alapján), míg a rögzített eszközök mindazon szenzorok, melyek rendeltetésüket tekintve statikusak (példaként a korábban említett asztali és környezeti eszközök tekinthetők relevánsnak). Ez a kettő legnagobb csoport, ám fontos megemlíteni még az elején, hogy ezen csoportok nem feltétlen rendelkeznek egzakt határokkal, mivel tételezzük egy hőmérséklet mérő ugyanúgy alkalmazható testhőmérséklet, vagy épp elfogyasztás előtt álló étel hőmérsékletének meghatározása érdekében. A következő csoport a vizsgált paramétereket határozza meg, nagyobb csoportokba rendezve. Ezek közé sorolandó az egyes fiziológiai jellemzők, környezeti paraméterek, mozgás és pozíció, illetve biokémiai jellemzők meghatározására képes eszközök összessége. Ezen területek további, adott területen használt szenzorokra bonthatók, beleértve kémhatás mérőket, elektródákat, oxigénszaturáció mérőket, sphygmomanométereket (vérnyomásmérőket), hőmérséklet mérőket, alkohol érzékelőket, mikrofonokat (gyakorlatilag rezgésmérő), glukométereket, galvanikus reakcióérzékelőket, légáramlás mérőket, gyorsulásmérőket, giroszkópokat, magnetométereket, globális pozicionáló rendszereket, erő és súlymérő cellákat, hajlítás érzékelőket, spirométereket, páratartalom mérőket, légnyomásmérőket, fényerősség mérőket, UV sugárzás mérőket, CO2 és CO mérőket, optikai szenzorokat (használható por mérésére de akár képfelvételezésre is), ultrahangos, illetve lézeres távolságmérőket. Meglehetősen hosszú felsorolásról beszélünk, mégis csak pár példa került összegyűjtésre a jelentős halmazból, mely a teljes lehetőségeket jelenti. Ezt követi az adott paraméter, mely egzakt módon mérhető. Kiemelendő, hogy nem következtetett adatról beszélünk (például: futott távolság, alvásminőség, stressz szintje), mivel ezek már adatfeldolgozásból eredeztetett információk, hanem olyan paraméterekről, melyek közvetlenül meghatározhatók. Ebbe tartozik a az elektrokardiográfia (EKG) eljárás által meghatározott, szívizom összehúzódás jellemzője, az elektromiográfia (EMG) által meghatározott, vázizmok elektronikai aktivitását kifejező jellemzői, a vérnyomás, gyorsulás, szögsebesség, irány, testhőmérséklet, átfolyó levegő tömege és hőmérséklete, oxigénszaturáció, pulzusszám, izzadás mértéke (GSR), hanghatások, kémhatás, vércukorszint, véralkoholszint, páratartalom, fény intenzitása, UV sugárzás, CO2 koncentráció, CO koncentráció, levegőben lévő por mennyisége, távolság, globális pozíció és haladási irány, eszközre kifejtett erő, eszköz hajlításának mértéke, környezeti hőmérséklet, illetve légnyomás. Ezt követi az adatok használatából eredő lehetőségek összessége, pár példa kapcsán megemlítve az alvásfelügyeletet, lépésszámlálást, elégetett kalóriák mennyiségét (Shin et al., 2019) tevékenység osztályozást (Weiss et al., 2016), átalános állapotfelmérést (Dias and Cunha, 2018).

A továbbiakban áttekintésre kerülnek egyes jellemzők, melyek mérlegelése szükséges a koncepciók tervezésre során, hiszen meghatározzák és korlátozzák az elkészítendő eszközök képességét és az elkészítése során jellemző költségeket. Korábban említésre került a kommunikációs protokoll, azaz egy szenzor milyen módon képes kommunikálni a vezérlővel. Ezen tényező alapvetően nem befolyásolja a minőséget, viszont a két nagy csoport, beleértve a digitális és analóg eszközöket, fontos lehet számunkra. Digitális szenzorok esetében egzakt értékeket olvasunk ki az adott eszköztől, viszont analóg szenzorok esetében a a vezérlő szimpla hullámok digitalizálásával igyekszik meghatározni az eszköz által mért értékeket. Ennek előnye, hogy teljes rálátásunk van a feldolgozásra (a digitalizálástól a végeredményig mindent mi implementálunk), ám hátránya, hogy nem hagyatkozhatunk a gyártó által biztosított, kiforrott módszerekre, mint digitális szenzorok esetében, ahol a filterezés (jel szűrése) és egyes további műveletek a szenzor vezérlője által kerülnek elvégzésre. Épp ezért, hátrányaként említendő az ellenpéldaként említett tényezőkön felül, miszerint az implementálás körülményes, az alkalmazásához több processzoridő szükséges (tovább tart egy-egy művelet elvégzése, mely mobil eszközök esetében az üzemidő rovására is mehet). Személy szerint – mint ahogy az Open Health Controller – is kialakításra kerül, digitális kommunikációval bíró szenzorok preferáltak modern eszköz esetében. Az egyes, képességet reprezentáló paraméterek eltérnek annak függvényében, hogy mely tényező számszerűsítését végzik az eszközök. Annak érdekében, hogy ezen eszközök összegyűjtésre kerüljenek, szükségünk van az adott eszközök adatlapjára, mely minden fontos információt tartalmaz ezen tényezőkre vonatkozóan. Az pulzoximéterrel kezdve, az adatlapja áttekintése során találkozhatunk olyan paraméterekkel, mint:

A listára nem kerültek fel olyan tényezők, melyek nem befolyásolják az eredményt, beleértve üzemi feszültséget, jellemző áramfelvételt (fogyasztást) és egyebeket. A felsorolt alapvető tényezők alapján tengelyek száma döntően a mozgás mérésére képes eszközök esetén értelmezendő, mely kifejezi, hogy az eszköz hány irányba képes értelmezni annak mozgatását. Rendszerint három dimenzióról beszélünk, X, Y és Z tengelyként kifejezve, ám egyes eszközök (kombinált IMU-k, melyek giroszlópot, gyorsulásmérőt és magnetométert egy egységen belül tartalmaznak) nem ritka a "9D" kifejezés, mely egy félreérthető kifejezés, ugyanis ebben az esetben az estközön belül helyet foglaló három szenzorra jellemző tengelyek összegzéséről beszélünk, így a 3*3 tengely eredményként 9D-ként hivatkoznak a mérőszámra. A mérési tartomány kifejezni az adott eszköz azon képességét, hogy az a hatás kifejtését milyen intervallumok között képes érzékelni. Például, egy pulzoximéter esetében a megjelölt spektrális tartomány a lézerfény érzékelésének tartományát fejezi ki. A gyorsulásmérőkre jellemző gyorsulási tartomány (g értékben kifejezve) lényegében a szenzor mérési tartományát határozza meg, azaz mekkora gyorsulást tud az eszköz maximálisan detektálni. Giroszkópok esetében a mérési intervallum szögsebesség tartományként kerül meghatározásra (DPS – degree per second), mely a maximális forgási sebességet határozza meg. Magnetométer esetében hasonló logika alapján gondolkodunk, amikor a mágneses mezőt (G) vizsgáljuk mérési tartományként. Az utóbbi három eszköz esetében az adatlapok gyakran variációkat sorakoztatnak fel, mint például egy gyorsulásmérő esetében: ±2g / ±4g / ±8g / ±16g. A digitális eszközök, mint az említettek, igazából ugyanúgy analóg módon mérik az egyes környezeti tényezőket, ám ezen jelek a szenzor vezérlője által kerülnek digitalizálásra. A több értékként kifejezett mérési tartomány arra utal (leginkább gyorsulásmérő, giroszkóp és magnetométer esetében találkozunk ezzel), hogy az eszköz különböző küszöbértékek figyelembevételére képes, adott felbontás mellet. Kisebb értékek esetén szűkebb tartományhoz nagyobb felbontás, míg nagyobb értékek esetén nagyobb mérési tartomány, de kisebb felbontás jellemző. Összegezve, kisebb tartomány esetén adott felbontással részletesebb eredményre képes az eszköz, mivel nagyobb küszöbérték esetén ugyanakkora „résre kell beférnie” az effektusnak. Ha futás esetén maximum 2g erő hat az eszközre jellemzően, 16g mérési intervallum használatával a felső 14g nem kerül kihasználásra, így potenciális részletet veszítünk a digitalizálás során. A zajt reprezentáló μg/√Hz az állandó spektrális (PSD) teljesítménysűrűséget fejezi ki. Erre jellemző, hogy a frekvencia csökkentésével pontosabb mérések valósíthatók meg (a zaj csökkenése révén). Az érzékenység gyorsulásmérők esetében (mg/LSB) meghatározza, hogy egy bit változása mekkora gyorsulást reprezentál adott felbontás mellett, míg giroszkóp esetében (MDPS/LSB) szintén hasonló logika alapján határozza meg, hogy egy bit változása mekkora forgási sebesség változással jár.

Mindenekelőtt jogosan merülhet fel a kérdés, hogy mi is a nyílt forráskód? Nyílt forráskódú alkalmazás alatt olyan megoldásokat értünk, melyek szabadon (ingyenesen) hozzáférhetünk és a szabad használat mellett szabadon módosíthatjuk, integrálhatjuk és újból közzétehetjük az ennek eredményeként létrejött terméket.

A továbbiakban tekintsük át, hogy milyen formában jelennek meg a nyílt forráskódú megoldások az egészségügy és a sport területén. Ennek megvalósításához tekintsük át a szakirodalmat. Ám ahelyett, hogy órákat bújnánk a különböző aktuális irodalmat, figyelembe vettem, hogy a kézikönyvet forgató egyén nem biztos, hogy sok idővel rendelkezik, így használjuk ki a napjaink modern módszereit és adatbányászat segítségével tekintsük át a releváns lehetőségeket. A területen mondhatni kevés a releváns szakirodalmak száma, mivel hasonló elemzéseket rendszerint 10 000 bejegyzés felett alkalmazok, de az érdeklődés felkeltése érdekében ennek ellenére fontosnak láttam annak bemutatását.

Az ábra meglehetősen kevés információval szolgál, mivel a területre meglehetősen kevés a nyílt forráskódú megoldás. Pont ennek köszönhetően került megvalósításra a projekt ezen része, hogy az olvasók számára lehetőséget biztosítson a hasonló módszerek szabad kipróbálására. Az ábrát áttekintve ennek ellenére találkozhatunk ismeős fogalmakkal, mint az IoT (tárgyak internete) a hordható eszközökön és szenzorhálózatokon keresztül, az nagy volumenű adat menedzsmentje esetén alkalmazott Big Data koncepció, illetve manapság mindenki kedvenc témája, a mélytanulás (deep learning) jelenléte. Egyes paraméterek kapcsán megjelenik a tevékenység felügyelet, fizikai aktivitás, stressz csökkentés, és az esés detektálás. Fontos megemlíteni, hogy ez csak a felszín, mivel a keresése erősen korlátozta a nyílt forráskód alkalmazása, mint kulcsszó. Amennyiben a téma szélesebb kiterjedésű változatára kíváncsi, tekintse meg a pályázat során létrehozott publikációt, mely elkészítése során hasonló elemzéshez mintegy 10 000 rekord került alkalmazásra, melyek lehetővé tették a szélesebb körű elemzéseket, beleértve a klaszteranalízis és tematikus evolúciót, hogy ne csak a főbb témák és annak kapcsolatai, hanem egyes csoportok és a kapcsolat idővel történő változása is vizualizálhatóvá váljon.

Most pedig következzem az a lépés, amire feltehetően mindenki várt a tananyag kezdete óta, mégpedig a gyakorlati alkalmazás kérdésének vizsgálta. A korábbiakban említésre került, hogy milyen komponensekből tevődnek össze a különböző eszközök, illetve mi által működnek, de ismétlésként vizsgáljuk át a mérlegelendő komponenseket. Amennyiben csak az adatgyűjtésre koncentrálunk, mint jelen esetben, a hardver (vezérlő és szenzor), illetve a rajta futó szoftver elkészítése lesz a feladatunk. Természetesen nem várható el senkitől, hogy első kérésre nyomtatott áramköröket készítsen, illetve natív programot írjon, ám a tananyag célja pontosan ezen szükségletek kikerülése, hiszen a munka nehezét én, illetve egyes esetekben a közösség már elvégezte, tehát az olvasónak már csak alkalmaznia kell a rendelkezésre álló eszközöket, mindezt garantáltan felhasználóbarát módon.

Az alkalmazás logikáját meghatározó szoftver elkészítésének három módja kerül bemutatásra. Ebből két módszer egyedi, a kutatás során elkészített eszközök segítségével történik (az említett Open Health Connector), míg a harmadik különböző közösségben elérhető eszközökkel kerül prezentálásra. A választás az olvasó dolga, mivel az előbbi két alternatív egy teljesen optimalizált eredményt biztosít, míg a harmadik ilyen tényezőket tekintve szerényebb eredményt biztosít, ám bármilyen probléma esetén könnyen utánajárhatunk a problémának erre megfelelő fórumokon. Kezdjük az első két alternatíva rövid bemutatásával. a kutatás során elkészítésre került egy programkönyvtár, amely lényegében egy „csomagoló” elv. Amennyiben használjuk az említett könyvtárat, egy sor leírásával elképzelhető, hogy 30 sort váltunk ki, ugyanis a az eszközre való feltöltés előtt ezek a sorok elrejtésre kerülnek. tehát mérlegeltem a felhasználói igényeket és a különböző alapvetőnek vélt eljárásokat lerövidítettem. Ez nem újdonság a területen, ám a könyvtárak rendszerint egy-egy eszközhöz készülnek el. Tehát minden szenzorhoz rendelkezésre áll több (különböző fejlesztők által biztosított) programkönyvtár, amely különböző vezérlőkkel kompatibilis, ráadásul teljesen különböző logika mentén kerülnek kialakításra. Ebből láthatjuk, hogy meglehetősen sok kombináció figyelembevételére van szükség és ennek megismerése rengeteg időt vehet el. Ráadásul jelen esetben könyvtárakról beszélünk, mely mondhatni a „könnyített fokozat” a falhasználók szempontjából. Ennek megfelelően a felhasználóbarát kialakítást tovább támogatja, hogy a különböző utasítások egységesítésre kerültek, azaz egy adott gyártmányú gyorsulásmérőről ugyanolyan utasítással kérdezhetünk le adatot, mint az egy teljesen más elven működő, másik példány esetében jellemző. a könyvtár használata alapvetően karakteres programozással történik, bár a könyvtár révén létrehozott magas absztrakciós réteg révén ez inkább csak pár utasítás kiadását igényli, tehát pár perc alatt elsajátítható a működése jelen útmutató segítségével. Ennek ellenére második variánsként kezdtem el dolgozni egy alternatíván, mely a Google Blockly nyílt forráskódú, játékos kialakítású fejlesztői környezetbe implementálja a programkönyvtár egyes elemeit, ezzel a falhasználó számára egy ennél is könnyebb lehetőséget biztosítva a tesztelések során. A működése még meglehetősen redukált a teljes programkönyvtárhoz képest, ám oktatási célból mellékelem annak moduljait a következőkben.

Mielőtt bármilyen kísérletbe kezdenénk, fontos a megfelelő eszközök rendelkezésre állása. Az említett, nyílt forráskód és könnyű kezelhetőség jegyében a könyvtár futtatásához Arduino fejlesztői szett szükséges. Személy szerint az Arduino MKR 1010 eszközt javaslom, mely kis méretben integrál számos szükséges eszközt, emellett teljesen kompatibilis az említésre kerülő programkönyvtárral. Fontos megemlíteni, hogy a programkönyvtár elkészítése során figyelembe vettem az Arduino platform sajátosságait, ám a kiadás pillanatában a könyvtár csak az MKR széria tagjaival került tesztelésre. A kísérletek elvégzése érdekében dönthetünk úgy, hogy csak az Arduino fejlesztői szettet alkalmazzuk (például a költségek megtakarítása révén), ám ebben az esetben szükségünk lesz egy úgynevezett átmeneti kapcsolótáblára, illetve vezetékszettekre a megfelelő illesztések megvalósítása érdekében. Hazai beszerzést feltételezve az eddig említett eszközök megvásárolhatók többek között az alábbi oldalakon:

A továbbiakban döntés elé kényszerülünk, miszerint használjuk ezen egyszerűbbnek tűnő megoldást, vagy alkalmazzuk a korábban röviden bemutatott alaplapot, mely elősegíti a különböző szenzorok könnyebb csatlakoztatását az Arduino fejlesztői alaplaphoz, illetve egyes funkcionalitások bővítését eredményezi. A döntést az igények és preferencia határozza meg. Amennyiben szükségesnek érezzük az Open Health vezérlőre integrált komponenseket (SD kártyafoglalat, belső memória, óra), biztosak akarunk lenni a szenzorok csatlakozását illetően, emellett feltehetően nem egy-két alkalommal tervezzük használni az eszközt, érdemes mérlegelni az Arduino fejlesztői platform ilyen irányú bővítését. Amennyiben az eszköz alkalmazása mellett döntünk, lehetőségünk van az vezérlő gyártását elrendelni. a tervek szabadon elérhetők a kutatás GitHub projektoldalán, mely letöltést követően továbbítható bármely nyomtatott áramkörökre specializálható szolgáltató számára. Természetesen, ha bármilyen kérdés merülne fel a gyártást illetően, készségesen állok rendelkezésre a megadott elérhetőségek egyikén.

Az Open Health Controller lényegében az előbb említett Arduino fejlesztői alaplap kiterjesztet változata, kifejezetten egészségügyben alkalmazott szenzorokkal való kísérletek megvalósítása érdekében. Kialakítása során mérlegelésre kerültek a kezdő és műszaki területen kevésbé jártas felhasználók igényei, mely alapján egységesített csatlakozófelülettel van lehetőségünk a támogatott eszközök alkalmazására. Ezen fell a kommunikációs lehetőségek bővítése érdekében egy SD kártyafoglalat került integrálásra az alaplapra, mely lényeges terhet csökkent az átmenti kapcsolótáblával történő felhasználáshoz képest. Az eszköz tervei elérhetők az oldalon jelzett GitHub prfolomon, mely ezt követően legyártatható bármely nyomtatott áramkörökre specializált egységben. A következő verzió a tervek szerint egyes szenzorokat integrálva fog tartalmazni az alaplapon, ezzel elkerülve a manuális összekötések igényét teljes egészében, méginkább csökkentve a felhasználó által elvégzendő feladatok összességét.

Az első kísérlet megvalósítása érdekében a többség feltehetően az Arduino fejlesztői alaplapot választja (az Open Health vezérlő alkalmazása nélkül), míg szoftver tekintetében nehéz megállapítani a preferenciát, ennek megfelelően mindkét alternatíva bemutatásra kerül. Az egységesség érdekében ragaszkodjunk a kutatás tárgyaként elkészült eszköz által támogatott szenzorokhoz és vezérlőkhöz, hogy egységes eredménnyel záruljon kísérletünk. Ennek figyelembevételével az alábbi eszközök használatára van lehetőségünk, a kiadás pillanatában jellemző verzió (v.1.0) képességeit tekintve.

1. Gyorsulásmérő, giroszkóp és magnetométer
   1. TDK MPU-9250
   2. STMicroelectronics LSM303DLHC
   3. STMicroelectronics L3GD20
   4. NXP Semiconductors MMA7455L
2. Pulzoximéter
   1. Maxim Integrated MAX30102
3. Súlymérő
   1. Bármilyen analóg cella
4. EKG (elektrokardiográfia)
   1. AD8232

Az eszközök beszerzése során érdemes figyelembe venni annak kiszerelését, ugyanis mindenképp fejlesztői példány vásárlására van szükség, mely lehetővé teszi az eszköz vezérlővel való kapcsolatának könnyű kialakítását. Alapvetően az eszközök meglehetősen kis méretűek, ám a fejlesztői célból gyártott modulok ezen szenzort egy kezelhető méretű nyomtatott áramkörön helyezik el, mely a kezelhetőségen felül biztosítja az alapvető, individuális működést segítő komponensek jelenlétét. A bemutatott eszközök jelentős része elérhető az alábbi webáruház mellékelt alkategóriájában: https://www.hestore.hu/cat_486.html?pg=1.

A következőkben feltételezzük, hogy rendelkezésünkre áll legalább minimális szett, azaz az Arduino fejlesztői alaplap, az átmeneti kapcsolási tábla, a vezetékszett, na és persze egy vagy akár több kiválasztott szenzor. Az alábbi ábrák prezentálják a különböző szenzorok bekötését, figyelembevéve az említett konfigurációt:

Beszéljünk pár szót a szenzorok bekötéséről, amennyiben az átmeneti kapcsolótáblát használjuk. Mindenekelőtt arról, hogy hogyan is néz ki a tábla alulról. Amennyiben állítva tekintünk a táblára, a felezővonaltól a két rövidebb oldal felé haladva az ágak kontaktusban vannak egymással egészen a két szélső, láthatóan elválasztott vonalsortól, melyek hosszanti irányban kapcsolódnak egymáshoz. Ennek oda, hogy a két széleső ág rendszerint feszültséggel való ellátást szolgálják, míg a belső, rövidebb ágak bármire használhatók. Korábban említésre került, hogy léteznek analóg és digitális szenzorok. Jelenleg tananyagban digitális eszközöket fogunk használni első sorban. A digitális eszközökön belül léteznek különböző protokollok, melyek célja az egységesített adatátvitel. Számos protokoll létezik, viszont szerencsénk van, ugyanis a programkönyvtárban foglalt szenzorok mind az úgynevezett I2C protokollt támogatják. Részletekbe menően nem foglalkozunk ennek működésével, ugyanis csak a bekötés idejéig fontos számunka a kapcsolat egy jellegzetessége, miszerint két vezetéket igényel a működése. Ebből az egyik az ütemezést (SCL vagy SCK), míg a másik a tényleges adat (SDA) átvitelét szolgálja. Persze ne feledkezzünk meg a feszültséggel való ellátásról sem. Miután ismerjük a megnevezéseket, csupán elhatározás kérdése, hogy összekapcsoljuk az azonos névvel ellátott részeket. Az Arduino fejlesztői alaplap szintén rendelkezik címkézéssel, ám ez felülnézetből nem látható, ezért nem került ábrázolásra. Az I2C protokoll előnye, hogy több eszközt is használhatunk ugyanazon a „lábon”, így elkerülve a hosszadalmas bekötést, szemben az analóg eszközökkel, mely estében minden szenzor egy teljesen külön „lábat” igényel a vezérlőtől. A bemutatott ábrán kettő darab szenzor (TDK MPU-9250 gyorsulásmérő/giroszkóp, illetve egy Maxim Integrated MAX30102 pulzoximéter) került alkalmazásra, emellett egy kis kijelző, mely hamarosan implementálásra kerül az Open Health Connector programkönyvtárba a lehetőségek kibővítése érdekében, hiszen hordható eszközök esetében gyakran találkozunk a visszajelzés igényével.

Miután összeállításra került a kívánt eszközünk, a következő lépés a működési logika megállapítása, azaz annak meghatározása, hogy mit akarunk elérni az adott eszközzel. Mindenekelőtt tisztában kell lennünk azzal, hogy a programunk egy indítás után egyszer lefutó blokkból, majd egy ciklikusan ismétlődő blokkból fog állni és az egyszerűség kedvéért szekvenciálisan, azaz egymást követően történnek az események mindkét esetben. Az első, egyszer lefutó blokkban olyan feladatok elvégzésére van szükség, mely támogatja a megfelelő működést. Hangsúlyozom, hogy jelen esetben csupán a kísérletezés a cél – mint ahogy az a tananyag célja is – ennek megfelelően kevésbé szofisztikált, ám működő eljárások kerülnek implementálásra. Tipikus feladatok lehetnek az említett blokkban a szenzorok konfigurálása, beállításainak kiválasztása, kommunikációs módszerek (vezérlők) konfigurálása és egyebek, DE jelen esetben a programkönyvtáraknak köszönhetően (különösen hivatkozva az Open Health Connector, kutatás eredményként létrehozott könyvtárra) ezen műveletek mindösszesen pár sorban is elvégezhetők. Tehát a nehezén túl vagyunk.

A folyamatosan ismétlődő blokk azon eljárásokat tartalmazza, melyek a méréssel, feldolgozással és továbbítással kapcsolatosak, tehát ezen blokkban kerülnek kiolvasásra a csatlakoztatott és korábban konfigurált szenzorok, majd ugyanitt történik az adatok tárolása vagy továbbítása különböző megoldások (WiFi, Bluetooth) alkalmazásával.

Ezen folyamatnál maradva érdemes az alkalmazás elkészítésével foglalkoznunk, figyelembevéve az egységes Open Health Connector programkönyvtár és a közösség által elérhető könyvtárak alkalmazását. Az alkalmazás elkészítéséhez szükségünk van az Arduino IDE, nyílt forráskódú és több platformon futó alkalmazásra, mely segítségünkre lesz a továbbiakban. Az alkalmazás elérhető az alábbi link segítségével: https://www.arduino.cc/en/Main/Software A letöltés során preferáljuk az asztali verzió használatát (a web alapú verzióval szemben), a könyvtárak könnyebb integrálása érdekében. A telepítés folyamata nem igényel különösebb részletezést. Az alkalmazás elindítását követően az alábbi képernyő fogadja a felhasználót.

Az ábrán jelölésre kerültek a főbb komponensek, melyeket használni fogunk az elkövetkezőkben. A korábban említett konfigurációs blokk és ismételt blokk a kettő (nyitó és záró) kapcsos zárójel közé eső területet érinti, ennek megfelelően az elkészítésre kerülő sorok elhelyezkedése egyértelmű. Az elkészült alkalmazás szintaktikai megfelelősége az ellenőrzés gombbal vizsgálható meg, majd a megfelelőnek ítélt alkalmazás a feltöltés gombbal továbbítható az USB kapcsolat segítségével csatlakoztatott fejlesztői alaplap felé, mely ezt követően elkezdi annak végrehajtását az általunk meghatározott logikát követve.

Az általunk elérni kívánt célt több módon megközelíthetjük az egészségügy aspektusában, ennek megfelelően több tényező mérlegelésére van szükség a megfelelő módszer alkalmazása érdekében.

Egyrészt érintenünk kell az alkalmazott szenzorokon túl a mérések gyakoriságát, elvárt pontosságát, az esetleges előfeldolgozás lehetőségét, illetve a kommunikációs megoldásokat, melyet használni szeretnénk az adatok lekérdezése érdekében. Mindenekelőtt kezdjünk a gyakoriság kérdésével. Amennyiben jelen állapotban futtatnánk le az alkalmazást, egyrészt nem történne semmi, de ha tételezzük továbbítunk egy üzenetet Serial.print(„Nyomtatott szoveg”) utasítás segítségével számítógépünk felé a folyamatosan ismétlődő blokkban, lefuttatva azt tapasztalhatjuk, hogy az ismétlődések a hardver sebességétől függően folyamatosan kerülnek átadásra a számítógép számára, minden lehetséges szabályozás nélkül. A legegyszerűbb, legkevésbé elegáns (ám teszteléshez alkalmazható) megoldás a folyamatosan ismétlődő blokk legutolsó utasításaként egy „várakozás” utasítást, mely a delay(X); utasítás segítségével valósítható meg, ahol az X = a kívánt várakozással ezredmásodpercben kifejezve, tehát a delay(1000); utasítás egy másodperc várakozásnak felel meg. A továbbiakban a mérések ezen megoldással kerülnek lassításra a megfelelő mérési frekvencia elérése érdekében.

Információ: Szofisztikáltabb, piacképes megoldások esetén rendszerint megszakítások segítségével történik a szenzorok lekérdezésének ütemezése, mely lehetővé teszi a több szál egyidejű futtatását, ám a feladat komplexitására való tekintettel, illetve a felhasználóbarát elvtől való elrugaszkodás elkerülése érdekében nem kerül ezen megoldás bemutatásra. Az érdeklődő olvasók az alábbi linken tájékozódhatnak az eljárásról.

Tételezzük, hogy alkalmazásunk az alábbi szerint néz ki, tartalmazva az egyszerű számítőgépes kapcsolat inicializálását, egy üzenet küldését, illetve az üzenetek küldésének lassítását.:

A továbbiakban cél az egészségügyben alkalmazott szenzorokkal történő mérés és a mérések továbbítása a számítógép képernyőjére. Ennek megfelelően több szenzor kerül egyidejűleg alkalmazásra, ám igyekszem minél inkább disztinkt módon kezelni ezeket annak érdekében, hogy kevesebb – vagy akár több – eszköz mellett is követhető legyen az útmutató. Ennek megfelelően a továbbiakban két részre bontjuk a leírást, melyből az első a közösségi megoldásokat, míg a második a kutatáshoz kapcsolódó Open Health Connector alkalmazását fejti ki. Az első lépés mindkét esetben a megfelelő könyvtárak mellékelése, mely lehetővé teszi az eszközök alkalmazását. Közösségi megoldások esetén annyi könyvtár mellékelésére van szükség, ahány eszközt használunk. Ezzel szemben az Open Health Connector esetében egy könyvtár használatára van szükség, mely tartalmazza az összes szükséges szenzorhoz kapcsolódó kódot.

A könyvtárak telepítéséhez az Eszközök menüpont → Könyvtárak kezelése almenü alkalmazására van szükség. Az ablak megnyitását követően a kereső segítségével választhatjuk ki a szükséges könyvtárat (a szenzor típusára való kereséssel), majd telepíthetjük azt. Szinte minden könyvtárhoz csatolásra kerül egy minta, mely az alapvető használatot taglalja. Ezen minták a Fájl menüpont → Példák almenü segítségével érhetők el az adott eszköz nevével egyeztetett bejegyzés alatt. Az egységesség érdekében egy darab szenzor kerül alkalmazásra (majd a későbbiekben bővítésre) mindkét példa esetében, amely a TDK MPU9250 (gyorsulásmérő, giroszkóp és magnetométer), ennek megfelelően a korábban bemutatott bekötési útmutató közül érdemes eljárni, egyszerűen kihagyva a nem használt szenzorokat.

1. variáns - Közösségi megoldás

Közösségi megoldások alkalmazása esetén minden alkalmazott könyvtár mellékelésére szükség van, ám mivel jelen esetben még csak egy eszközről beszélünk, ez könnyen kivitelezhető. A letöltéseket szemrevételezve letöltésre került a programkönyvtár a szenzorhoz (szerző: hideakitai). Ezzel elkezdődik a folyamatos probléma, mely a programkönyvtárak konzisztenciájának hiányából adódóik. Jelen esetben a szerző helyesen járt el és úgynevezett osztályba rendezte alkalmazását, mint ahogy az a másik metódus során bemutatott saját alternatíva esetén is jellemző, de esetekben az implementálás lényegesen eltér, ennek megfelelően idegen könyvtár esetén érdemes megtekinteni a korábban bemutatott forrás alapján a hozzá kapcsolódó mintafeladatot. Az alábbiakban tekintsünk meg egy alapvető implementálást, majd annak magyarázatát.

Mint azt látjuk, első lépésként mellékelésre került a szükséges könyvtár. Ez két módszerrel valósítható meg. Az első a Vázlat menüpont → Könyvtár tartalmazása menüpont segítségével kijelöljük az alkalmazni kívánt könyvtárat annak neve alapján, mely automatikusa hozzáadásra kerül a felső sorhoz a mintának megfelelően. Más esetben a könyvtárak neve a mintafeladat alapján megtalálható minden könyvtár esetében így manuálisa is lehetőségünk van annek beírására. Ezt követi az adott szenzor definiálása (osztály példányosítás) mely a két jellemző blokkon kívül történik, jelen esetben az MPU9250 mpu; utasítással, melyből az első szó az osztály nevét, míg a második egy általunk megválasztott azonosítót takar, mely segítségével hivatkozunk a későbbiekben az eszközre. Ugyanitt definiálásra kerül 9 darab változó (az egyszerűsítés érdekében lebegőpontosan, emellett nem tömbként), mely tartalmazni fogja a szenzor által mért értékeket. Az egyszer lefutó blokkban megtalálhatjuk a számítógéppel való kapcsolat kialakításáért felelős Serial.begin(115200); utasítást, mely hasznunkra lesz az értékek megjelenítése érdekében. A Wire.begin(); a korábban bemutatott, szenzorral való kommunikációs protokoll kialakítását teszi lehetővé, mely sok könyvtár esetében (mint ahogy az Open Health Connector) elhagyható paraméter, ám jelen könyvtár megköveteli az alkalmazását. Az ezt követő mpu.setup(); a szenzor inicializálását teszi lehetővé. Az „mpu” megnevezés, mint az említésre kerül, az általunk megadott név. Ezzel a lépéssel megtörtént a szenzor inicializálása, majd következhet annak kiolvasása a folyamatosan ismétlődő blokkban. A kiolvasás során a létrehozott változókat töltjük meg a különböző adatokkal. jelen esetben kilenc értékről beszélünk, beleértve három tengelyen mért gyorsulást, forgást és mágneses erőt. Jelen könyvtár esetében a forgással kapcsolatos adatok mpu.getRoll(); mpu.getPitch(); illetve mpu.getYaw(); utasítással kérdezhetők le. Mivel ezek eredménye a változókban kerül tárolásra, a változót egyenlővé kell tenni az említett eljárásokkal, mely által az eljárás eredménye az adott változóban kerül tárolásra. Mivel nem ismerjük, hogy az adott eljárás milyen változót (számokon belül), biztonságosabb típuskonverziót használni, mint azt a (float) jelző reprezentálja a mérések sorában.

Amennyiben megtörténik a mérés, a képernyőre való kiírása a Serial.print(); eljárással történik, mely esetében a zárójelben lévő elem kerül kiírásra. Esetünkben ez a mérés jellege (mit mértünk) és maga az érték. A korábbiakban említettek alapján a folyamatosan ismétlődő blokk utolsó utasítása egy késleltetés a mintavételi frekvencia csökkentése érdekében.

2. variáns - Open Health Connector

Az Open Health Connector alkalmazása valamivel egyszerűbb, mint a közösségi könyvtárak alkalmazása az egységesítések révén. Ebben az esetben egy programkönyvtár kerül alkalmazásra minden szenzor esetében, kivéve, ha azt egy nem implementált szenzorhoz tervezzük használni. Abban az esetben a jele leírás párjaként tekinthető „Közösségi megoldás” szekcióban leírtak figyelembevételére is szükség van. Ám jelen esetben implementált szenzorról van szó, így elegendő az Open Health Connector könyvtár alkalmazása. Ennek melléklése érdekében szükséges a könyvtár letöltése, ám mivel nem került a könyvtár implementálásra az Arduino beépített listájára, így annak manuális letöltésére van szükség az oldal jobb oldalán lévő hivatkozás segítségével. A letöltést követően a könyvtár hozzáadása a Vázlat menüpont → Könyvtár tartalmazása menüpont → .ZIP könyvtár tartalmazása menüpont segítségével valósítható meg a letöltött tömörített állomány kijelölésével. A programkönyvtár segítségével létrehozott minta alapján láthatjuk annak alapvető felépítését

Talán elsőre bonyolultnap tűnik, sőt, bonyolultabbnak, mint a közösségi verzió annak ellenére, hogy a könyvtárat a könnyű kezelhetőség jegyében készítettem el, ám vegyük figyelembe, hogy a felvázolt példán négy különböző szenzor kerül alkalmazásra. Emellett megfigyelhető, hogy a különböző szenzorok azonos utasítások segítségével működtethetők az egységesítés révén és nem jellemző a közösségben előforduló, egy-egy szenzor működtetéséhez használt könyvtárakra jellemző szétszórtság. Emellett, ha megfigyeljük, a kód nagy része csak az eredmények listázását szolgálja.

Az alkalmazás során első lépés a könyvtár alapfunkcióinak definiálása. Jele verzió (v.1.0.) esetében ennek célja csak a kommunikációs vezérlők kezelése, ám a későbbiekben további funkciók kerülnek implementálásra az inicializálás során, ezért fontos volt ennek kezelése. A következő műveletek a két jellemző blokkon kívül kerülnek definiálásra, mivel a teljes programra kihat jelenlétük. A könyvtár inicializálása az openHealth openhealth; utasítással történik (osztály példányosítás), melyből a második kulcsszó az általunk megadott azonosító, melyet a továbbiakban használunk a rá való hivatkozás esetén. Ezt követően felsorolásra kerülnek egységesen az alkalmazott szenzorok. A jelenleg alkalmazott szenzor esetében az MPU9250 mpuSensor1 = MPU9250(); utasítással definiáljuk, ahol az mpuSensor1 egy általunk megválasztott név az előbbiekhez hasonlóan, mely segítségével az adott eszközre hivatkozunk a későbbiekben. A folyamatosan ismétlődő blokkra vonatkozóan megtörténik az eszközök inicializálása. A programkönyvtár alapfunkcióinak inicializálása az openhealth.Init(); utasítással történik meg. Fontos megemlíteni, hogy ezen utasítás minden kommunikációs vezérlőt aktivál, beleértve a legtöbb esetben külön kezelendő, számítógéppel való egyszerű kommunikációt az értékek megjelenítése érdekében. Ezt követően egymás alá felsorolva minden szenzor nevezett példányán alkalmazhatjuk az mpuSensor1.Init(); eljárást (a név megfelelő cseréjével), mely az egységesítés révén nem változik a komponensek között. Ezzel a különböző eszközök alapbeállítások alapján kerülnek konfigurálásra. Az ezt követő, folyamatosan ismétlődő blokkban lehetőségünk nyílik a különböző értékek mérésére. Az alternatívaként bemutatott közösségi könyvtárral szemben nem szükséges változók definiálásával foglalkozni (könnyítve ezzel a használatot) ugyanis minden szenzorhoz tartozó osztály tartalmazza a megfelelő adattípussal ellátott változót. Összesítésként az alábbi utasítások alkalmazhatók a különböző szenzorok esetében:

Utasítás	Funkció	Szenzor
megnevezes.ReadAcc();	Gyorsulási értékek olvasása	Gyorsulásmérők (bármelyik)
megnevezes.ReadGyr();	Forgási sebesség értékeinek olvasása	Giroszkópok (bármelyik)
megnevezes.ReadMag();	Mágneses hatások olvasása.	Magnetométerek (bármelyik)
megnevezes.ReadTemp();	Hőmérséklet olvasása.	Hőmérők (bármelyik) vagy egyes gyorsulásmérők
megnevezes.ReadEKG();	A csatlakoztatott EKG jelenlegi mérésének olvasása.	Analóg kimenettel rendelkező EKG (AD8232)
megnevezes.ReadBPM();	Pulzus mérése.	Pulzoximéterek (bármelyik)
megnevezes.ReadOxg();	Oxigén szaturáció mérése.	Pulzoximéterek (bármelyik)
megnevezes.ReadAnalog();	Analóg eszközök olvasása	Analóg súlymérő cellák, egyéb eszközök

Az utasítást követően az eszköz által mért értékek tárolásra kerülnek a rá jellemző osztályban, különválasztva ezzel a szenzorokat. Amennyiben az értéket meg kívánjuk tekinteni, az osztályban való változó (nem az általunk definiált változó, mint az a közösségi megoldásoknál jellemző, ezzel átláthatóbb kódot és felhasználóbart kezelhetőséget eredményezve). A különböző, szenzortól függő változók az alábbi szerint kerülnek megállpapításra:

Utasítás	Funkció	Szenzor
megnevezes.acc_x; megnevezes.acc_y; megnevezes.acc_z;	Gyorsulási értékek (x, y és z koordináta)	Gyorsulásmérők (bármelyik)
megnevezes.gyr_x; megnevezes.gyr_y; megnevezes.gyr_z;	Forgási sebesség (x, y és z koordináta)	Giroszkópok (bármelyik)
megnevezes.mag_x; megnevezes.mag_y; megnevezes.mag_z;	Mágneses hatások (x, y és z koordináta)	Magnetométerek (bármelyik)
megnevezes.temp;	Hőmérséklet	Hőmérők (bármelyik) vagy egyes gyorsulásmérők
megnevezes.ekg	Jelenleni jel intenzitása.	Analóg kimenettel rendelkező EKG (AD8232)
megnevezes.bpm;	Pulzus	Pulzoximéterek (bármelyik)
megnevezes.sat;	Oxigén szaturáció.	Pulzoximéterek (bármelyik)
megnevezes.av;	Jelenleni jel intenzitása.	Analóg súlymérő cellák, egyéb eszközök

Az alábbiak szerint láthatjuk, hogy mennyivel átláthatóbb kódot eredményez az egységes programkönyvtár alkalmazása, melynek előnye akkor válik igazán szembetűnővé, amennyiben több szenzort kívánunk alkalmazni, a lényegesen eltérő közösségi könyvtárak segítségével, ezzel átláthatatlanná téve az eredményt. Amennyiben megtörtént a mérés, az osztályban lévő változókban kerül tárolásra az eredmény. sikertelenség esetén -128 érték kerül tárolásra, mely által könnyen észlelhetjük a hibát. Sok közösségi könyvtár esetében a hibaa teljes alkalmazás leállásával jár, ezzel nehezítve a prototípusok készítését a hosszas hibakeresés (nem tudni, hogy mi okozza a problémát) révén. A megfelelő kiolvasás esetén például a Serial.print(megnevezes.acc_x);, azaz a Serial.print(); eljárásba ágyazott változó segítségével jeleníthetjük meg az eredményt a csatlakoztatott számítógépünkön.

Kommunikáció a külvilággal

Eddig sikerült megjeleníteni a réréseinket egyszeű kapcsolat révén, ám jelen formában a mérrések nehezen dolgozhatók fel, illetve nem reális használati szituációt feltételez. A hordható eszközök esetében gyakori kommunikációs lehetőségek közé tarozik a WiFi, és a Bluetooth, tehát mind olyan technológiák, melyet a mindennapokban is alkalmazunk. Emellett persze léteznek speciálisabb megoldások is, mint a ZigBee vagy épp LoRa, ám ezekkel nem foglalkozunk a komplex kialakítás révén. Az említett két lehetőség közül a WiFi segítségével történő vezeték nélküli kapcsolatot emeljük ki, emellett az SD kártya használatát. Kezdjük az SD kártya hazsnálatával. Amennyiben használjuk az Open Health Controller eszközt, nhardvert illetően nincs dolgunk, csupán beilleszteni a kártyát a megfelelő portba. Amennyiben átmeneti kapcsolótáblát használunk, szükség van egy külső foglalat alkalmazására, majd annak megfelelő bekötésére. Az SD kártya a már megismert I2C kapcsolattól eltérő, úgynevezett SPI kapcsolatot használ, melynek jellegzetessége, hogy valamivel több vezetéket igényel az alkalmazása. Az alábbi ábra szemlélteti a szükséges utakat.

Ám ha tételezzük, mindenképp SD kártya használatára szándékozunk a bemutatott bekötés szüksége nélkül, van lehetőség kifejezetten az általunk használt fejlesztői szetthez kapcsolódó, úgynevezett shield vásárlására, mely lehetővé teszi a gondtalan csatlakoztatást (magasabb költségek mellett), hasonlóan az Open Health Contoller-hez. Ennek beszerzése többek között az alábbi hivatkozás követésével lehetséges: MálnaPC.hu Szoftver tekintetében érdemes a jelen verzió esetében (v1.0) a közösségi programkönyvtárakat alkalmazni, mivel jelenleg ilyen vélra kiforrottabbnak tekinthetők a szenzorokkal elleneben. Az alábbiakban bemutatásra kerül egy lehetséges alkalmazás implementálása, mely során a korábbi adatgyűjté eredményét nem a számítógép felé, hanem a memóriakártyára mentjük. Próbáltam a lehető leginkább egyszerűsíteni és érthetővé tenni a kódot, emellett jegyzetekkel kiegészíteni azt az átláthatóság érdekében.

Amennyiben WiFi kapcsolatot használunk, szintén javaslom a közösségi progrmakönyvtár alkalmazását. A WiFi segítségével történő kommunikáció alapvetően nem egyszerű, ugyanis esetében rendelkezni kell egy fogadó féllel (szerver) ahol az üzenet feldolgozásra kerül. A tesztek megkönnyítése érdekében kialakításra a jelen kutatási aloldalon egy egyszerű szerver, mely egyszerű módon képes mérések fogadására, ám nagy limitációkkal, illetve szabad hozzáférés révén az adatok nem kerülnek titkosításra, ennek megfelelően csak tesztek érdekében javaslom. Mivel a WiFi vezérlő integrálásra került az Arduino fejlesztői alaplapra, nincs tennivalónk hardver oldalról. Szoftver tekintetében az előzőhöz hasonlóan igyekeztem kódba ágyazott megjegyzésekkel segíteni a megértést.

Az iménti alapján láthatjuk, hogy hogy kerül kivitelezésre egy hálózati kapcsolaton történő mérés átvitele. Piacon lévő eszközök esetében hasonló metódusok kerülnek felhasználásra, ám a szerveroldali feldolgozás lényegesen leegyzserűsítésre került a tesztelés lehetősége révén, hiszen az elsődleges cél az útmutató révén a sikerélmény elérése, nem pedig a piacképes alkalmazás fejlesztése. Amennyiben fejejeztük mérésünket, az alábbi linken található oldalon tekinthetjük meg anna eredményét: kerdoiv.abadi.major.hu/iotteszt

Tekintsük át, hogy mi tudunk elérni több szenzor gyakorlati alkalmazásával, avagy fussunk egy kicsit. A jelenlévő ábra prezentálja számunkra az eszközök elhelyezkedését. Láthatjuk az ábrán, hogy kettő darab giroszkóp (szögsebességmérő), kettő darab gyorsulásmérő, egy darab EMG (elektromyográf) és egy darab oxinométer került alkalmazásra. Mivel áttekintettük a szoftverkörnyezet működését, a vállalkozókedvűek egyedi kialakítással is dolgozhatnak. Ha első nem sikerülne, biztosítok egy „menekülőutat”, mint az említésre fog kerülni a továbbiakban. Az előrelátás érdekében, a többszöri kísérlet elvégzésének elkerülése érdekében, a továbbiakban egy mobiltelefon segítségével is méréseket fogok végezni Mivel ennek elvégzéséhez a telefon szenzorának közvetlen olvasására van szükség, speciális ismereteket és szoftverkörnyezetet követel, így az olvasóknak javaslom a korábban felvázolt útmutató követését és „csak” a natív megoldást használni. A minta adathalmaz elérhető bárki számára a kutatási aloldalról, ennek megfelelően, ha esetleg valaki csak az elemzésre kíváncsi, gond nélkül folytathatja az útmutatót a mérések kihagyásával. Nézzük az eredményeket. Annak függvényében, hogy hol kerültek tárolásra az adatok, több módunk van annak lekérdezésére és megjelenítésére, így az adatok megtekintését követően tekintsük át a különböző módszereket, hogy behozzuk a lemaradást és egy ponttól folytassuk együtt a kísérletet.

A fenti ábrán láthatjuk a fuátás és gyaloglás által létrehozott mintázatot a gyorsulásmérő és giroszkóp segítségével. Ezt követően lent láthatjuk az EKG által mért adatokat, ugyanezen időpontban meghatározva. a véroxigénszintmérő ilyen rövid idő alatt sajnos nem mutatott jelentős eltéréseket.

Az előbbi ábrán láthatjuk a mérésekből származó eredményt, egymás felé illesztve, kifejezve ezzel a mérés egységes időtengelyét a különböző eszközökön. Talán nem erre számítottunk, mikor az eredményekre vártunk, ám át kell látnunk a tényt, amivel korábban foglalkoztunk, miszerint az eszgéségügyben- mint bármely más területen - a szenzorok egzakt értéket nyújtanak számunkra, melyet saját elképzeléseink szerint formálhatunk számos módszerrel. Egyes lehetőségek rövid ismertetése a továbbiakban kerül bemutatásra.

A továbbiakban azon folyamatot fogjuk vizsgálni, mely által lehetőségünk van a különböző mérések és más forrásból származó adatok tényleges előnyét kihasználni. A hordható érzékelőkkel elérhető adatok sokasága számos kihívást eredményez a feldolgozása során, hogy annak eredménye pontos és releváns legyen. Az adatok teljes kihasználása érdekében, adatfúziós eljárások lényeges előrelépést jelentenek a kimenetek pontosságát illetően (King et al., 2017). Egyes rendszerek képesek ennek megfelelően a különböző adatbázisok, mint elektronikus betegnyilvántartás (HER), orvosi képalkotás, nem strukturált klinikai jegyzetek és generikus adatok egységes kezelésére, ezzel lehetőséget biztosítva a hatékonyabb döntésekre, megfelelő módszerek esetén (Manogaran et al., 2017). Az fenti ábra alapján láthatjuk, hogy fontos a különböző adatok közötti határterület lehatárolása. Másként szükséges a szenzoros adatok, leletek, statisztikák, historikus adatbázisok kezelése, hiszen az adatok teljesen más struktúrában vannak jelen, emellett aggregáltságuk is jelentősen eltérhet. vagyis “csak úgy” nem vethetünk össze egy orvosi leletet egy aktivitási adattal, mivel közös nevezőre van szükség. Az ábra által igyekszem kifejezni, hogy a rendszerek integrációja révén lehetőség van a meglévő egészségügy rendszerek kiegészítésére is az idő, tér résztvevők, tárgyak és szolgáltatásokat illetően (Ma et al., 2017).

Ennek megvalósítását teszi lehetővé a Big Data koncepció, mely központi szerepet tölt be a modern egészségügy területén (YIN et al., 2016), elsődlegesen a területre jellemző adattípusok diverzitása, illetve a feldolgozás sebességének igénye révén. Big Data alatt olyan adathalmazokról beszélünk, melyek túl nagyok vagy szerkezetileg komplexek ahhoz, hogy relációs adatbázisban kerüljenek tárolásra (Panesar, 2019). A Big Data magában foglal olyan karakterisztikákat, mint a terjedelem, változatosság, sebesség és az egészségügy területén különösen fontos tényezőként a valódiság, a megbízhatóság érdekében (Din and Paul, 2019), ám új megközelítés alapján a torzítások, zaj és rendellenességek szintén mérlegelendő szempontokká váltak, jelen esetben a téves adattartalom és hibás mérések hatásának mérlegelése érdekében (Seddon and Currie, 2017). Az egészségügy aspektusában is megkülönböztetünk különböző rétegeket, melyek szakirodalomként eltérnek. Egy megközelítés alapján egészségügyi észlelési réteget, szállítási réteget, illetve nagy egészségügyi felhő szolgáltatási réteget különböztetünk meg (Ma et al., 2017). Az észlelési réteg célja a környezettel kapcsolatos és fiziológiai adatok gyűjtése, melyek forrása lehet a korábban említett adatgyűjtő rendszerek összessége. A szállítási réteg egyfajta összekötő szerepet játszik az alkalmazások által kibocsátott utasítások és az érzékelési réteg által gyűjtött mérések közötti kapcsolat megteremtése érdekében, különböző hálózati technológiákkal. A legfelső, felhő szolgáltatási réteg esetében a különböző forrásból származó adatok összegyűjtésére kerül alkalmazásra azok tárolása, transzformálása és elemzése érdekében (Ma et al., 2017). Gyakorlati oldalról megközelítve a kérdést, amennyiben a korábbi kísérlet alatt WiFi kapcsolatot alkalmaztunk az adatok továbbítása érdekében, az adatunk átívelt az összes rétegen anélkül, hogy azt észrevettük volna, ugyanis az eszköz segítségével megtörtént a valós világ paramétereinek számszerűsítése, mely hálózati kapcsolaton keresztül, adott struktúrában került továbbításra egy szerver felé, mely feldolgoztam, strukturálta az adatot, ezt követően pedig elmentette újbóli visszakeresés (lekérdezés) biztosítása érdekében.

Alemdar, H. and Ersoy, C. (2010) ‘Wireless sensor networks for healthcare: A survey’, Computer Networks. Elsevier B.V., 54(15), pp. 2688–2710. doi: 10.1016/j.comnet.2010.05.003.
Darwish, A., Ismail Sayed, G. and Ella Hassanien, A. (2019) ‘The Impact of Implantable Sensors in Biomedical Technology on the Future of Healthcare Systems’, Intelligent Pervasive Computing Systems for Smarter Healthcare, pp. 67–89. doi: 10.1002/9781119439004.ch3.
Dawadi, P. N., Cook, D. J. and Schmitter-Edgecombe, M. (2013) ‘Smart Home Monitoring of Complex Tasks’, IEEE Trans on Systems, Man, and Cybernetics: Systems, 43(6), pp. 1302--1313. doi: 10.3233/THC-130734.
Dias, D. and Cunha, J. P. S. (2018) ‘Wearable health devices—vital sign monitoring, systems and technologies’, Sensors (Switzerland), 18(8). doi: 10.3390/s18082414.
Gómez, J., Oviedo, B. and Zhuma, E. (2016) ‘Patient Monitoring System Based on Internet of Things’, Procedia Computer Science. Elsevier Masson SAS, 83(Ant), pp. 90–97. doi: 10.1016/j.procs.2016.04.103.
Lai, X. et al. (2013) ‘A Survey of Body Sensor Networks’, Sensors, 13(5), pp. 5406–5447. doi: 10.3390/s130505406.
Lou, Z. et al. (2020) ‘Reviews of wearable healthcare systems: Materials, devices and system integration’, Materials Science and Engineering R: Reports. Elsevier, 140(August 2019), p. 100523. doi: 10.1016/j.mser.2019.100523.
Manogaran, G. et al. (2017) ‘Big Data Knowledge System in Healthcare’, in Bhatt, C., Dey, N., and Ashour, A. S. (eds) Internet of Things and Big Data Technologies for Next Generation Healthcare. Cham: Springer International Publishing (Studies in Big Data), pp. 133–157. doi: 10.1007/978-3-319-49736-5_7.
McConnell, M. V. et al. (2018) ‘Mobile Health Advances in Physical Activity, Fitness, and Atrial Fibrillation’, Journal of the American College of Cardiology. Elsevier, 71(23), pp. 2691–2701. doi: 10.1016/j.jacc.2018.04.030.
Mocrii, D., Chen, Y. and Musilek, P. (2018) ‘IoT-based smart homes: A review of system architecture, software, communications, privacy and security’, Internet of Things. Elsevier B.V., 1–2, pp. 81–98. doi: 10.1016/j.iot.2018.08.009.
Mshali, H. et al. (2018) ‘A survey on health monitoring systems for health smart homes’, International Journal of Industrial Ergonomics. Elsevier B.V, 66, pp. 26–56. doi: 10.1016/j.ergon.2018.02.002.
Puri, V. et al. (2020) BioSenHealth 2.0—a low-cost, energy-efficient Internet of Things–based blood glucose monitoring system, Emergence of Pharmaceutical Industry Growth with Industrial IoT Approach. Elsevier Inc. doi: 10.1016/b978-0-12-819593-2.00011-x.
Sazonov, E. and Neuman, M. R. (2014) Wearable sensors: Fundamentals, implementation and applications, Wearable Sensors: Fundamentals, Implementation and Applications. doi: 10.1016/C2013-0-06896-X.
Schieweck, A. et al. (2018) ‘Smart homes and the control of indoor air quality’, Renewable and Sustainable Energy Reviews. Elsevier Ltd, 94(February), pp. 705–718. doi: 10.1016/j.rser.2018.05.057.
Shin, G. et al. (2019) ‘Wearable activity trackers, accuracy, adoption, acceptance and health impact: A systematic literature review’, Journal of Biomedical Informatics. Academic Press, 93, p. 103153. doi: 10.1016/j.jbi.2019.103153.
Shin, K. G. and Ramanathan, P. (1994) ‘Real-Time Computing: A New Discipline of Computer Science and Engineering’, Proceedings of the IEEE, 82(1), pp. 6–24. doi: 10.1109/5.259423.
Sikorska-Siudek, K., Olȩdzka-Orȩziak, M. and Parzuchowska, B. (2006) ‘Health benefits of physical activity: the evidence’, CMAJ, 174(6), pp. 801–809.
Tamura, T. and Chen, W. (2017) Seamless healthcare monitoring: Advancements in wearable, attachable, and invisible devices, Seamless Healthcare Monitoring: Advancements in Wearable, Attachable, and Invisible Devices. doi: 10.1007/978-3-319-69362-0.
Thuemmler, C. (2017) ‘The Case for Health 4.0’, in Health 4.0: How Virtualization and Big Data are Revolutionizing Healthcare. Cham: Springer International Publishing, pp. 1–22. doi: 10.1007/978-3-319-47617-9_1.
Ullah, K., Shah, M. A. and Zhang, S. (2016) ‘Effective ways to use Internet of Things in the field of medical and smart health care’, 2016 International Conference on Intelligent Systems Engineering, ICISE 2016, pp. 372–379. doi: 10.1109/INTELSE.2016.7475151.
Vellappally, S. et al. (2019) ‘IoT medical tooth mounted sensor for monitoring teeth and food level using bacterial optimization along with adaptive deep learning neural network’, Measurement: Journal of the International Measurement Confederation. Elsevier Ltd, 135, pp. 672–677. doi: 10.1016/j.measurement.2018.11.078.
Verma, P. and Sood, S. K. (2018) ‘Fog assisted-IoT enabled patient health monitoring in smart homes’, IEEE Internet of Things Journal, 5(3), pp. 1789–1796. doi: 10.1109/JIOT.2018.2803201.
Warraich, M. U. (2016) ‘Wellness Routines with Wearable Activity Trackers : A Systematic Review’, MCIS 2016 Proceedings, (35), pp. 1–13.
Weiss, G. M. et al. (2016) ‘Smartwatch-based activity recognition: A machine learning approach’, 3rd IEEE EMBS International Conference on Biomedical and Health Informatics, BHI 2016, pp. 426–429. doi: 10.1109/BHI.2016.7455925.
WHO (2003) Diet, nutrition and the prevention of chronic diseases, WHO Technical Report Series.
Wilson, C., Hargreaves, T. and Hauxwell-Baldwin, R. (2017) ‘Benefits and risks of smart home technologies’, Energy Policy, 103(January), pp. 72–83. doi: 10.1016/j.enpol.2016.12.047.