}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Technologie iBeacon a její využití pro lokalizaci a komunikaci mezi mobilními zaˇrízeními D IPLOMOVÁ PRÁCE
Bc. Adam Štˇepánek
Brno, jaro 2015
Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Bc. Adam Štˇepánek
Vedoucí práce: RNDr. Jaroslav Škrabálek ii
Podˇekování Chtˇel bych podˇekovat panu RNDr. Jaroslavu Škrabálkovi za vedení diplomové práce a panu RNDr. Bc. Jonáši Ševˇcíkovi za zapujˇ ˚ cení Estimote beaconu˚ pro praktickou cˇ ást.
iii
Shrnutí Diplomová práce se zabývá problematikou technologie iBeacon. Díky ní lze vytváˇret lokální navigaˇcní a poziˇcní systémy, které se zaˇcínají využívat v ruzných ˚ odvˇetvích. Tato oblast je zkoumána jak z teoretického hlediska, tak z praktického hlediska. Jsou provedena a prezentována mˇerˇ ení beaconu˚ dvou ruzných ˚ výrobcu˚ a na základˇe tˇechto mˇerˇ ení je navrhnut a implementován systém využívající iOS aplikaci s podporou webového serveru. Práce diskutuje rovnˇež možnosti rozšíˇrení a zlepšení pˇresnosti lokalizace takového systému.
iv
Klíˇcová slova iBeacon, beacon, maják, iOS, Bluetooth, indoor lokalizace, indoor navigace
v
Obsah 1 2
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . Technologie iBeacon . . . . . . . . . . . . . . . . . 2.1 Bluetooth . . . . . . . . . . . . . . . . . . . . . 2.2 Podpora v zaˇrízeních a specifika platforem . 2.3 Beacon zaˇrízení . . . . . . . . . . . . . . . . . 2.4 Energetická nároˇcnost . . . . . . . . . . . . . 2.5 Reálné možnosti využití iBeacon . . . . . . . 2.6 Problémy a omezení technologie . . . . . . . 3 iBeacon a urˇcování vzdálenosti . . . . . . . . . . . 3.1 Síla signálu . . . . . . . . . . . . . . . . . . . . 3.2 Praktická mˇerˇ ení . . . . . . . . . . . . . . . . 3.2.1 Jaalee . . . . . . . . . . . . . . . . . . . 3.2.2 Estimote . . . . . . . . . . . . . . . . . 3.3 Vyhlazování signálu . . . . . . . . . . . . . . 4 Implementace ukázkového systému . . . . . . . . 4.1 iOS aplikace . . . . . . . . . . . . . . . . . . . 4.1.1 MultipeerConnectivity . . . . . . . . . 4.1.2 Komunikace s API serverem . . . . . 4.1.3 D3.js a vizualizace dat . . . . . . . . . 4.2 API a prezentaˇcní server . . . . . . . . . . . . 4.3 Testování . . . . . . . . . . . . . . . . . . . . . 5 Možnosti rozšíˇrení a úplná rekonstrukce pohybu 6 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . A Seznam elektronických pˇríloh . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
6 7 11 12 13 14 16 18 21 22 24 24 30 32 37 39 42 45 46 50 52 57 61 69
1
Seznam obrázku˚ 2.1 2.2
3.1 3.2
3.3
3.4
3.5
3.6
3.7
3.8
Znázornˇení základních úrovní vzdálenosti u technologie iBeacon (angl. proximity). 11 Ukázky iBeacon zaˇrízení ruzných ˚ výrobcu. ˚ Vlevo Estimote bez pouzdra z obou stran, vpravo Jaalee beacon s pouzdrem ve dvou odlišných barvách. 15 Ukázková situace pˇrenášených a poˇcítaných hodnot s jedním beaconem a dvˇema smartphony. 23 Poˇcet úspˇešných mˇerˇ ení beaconu Jaalee z celkových šedesáti pˇri periodˇe vysílání 1000 ms a vysílacím výkonu 0 dBm v závislosti na ruzných ˚ vzdálenostech. 25 Poˇcet úspˇešných mˇerˇ ení beaconu Jaalee z celkových šedesáti pˇri periodˇe vysílání 100 ms a vysílacím výkonu 0 dBm v závislosti na ruzných ˚ vzdálenostech. 26 Poˇcet úspˇešných mˇerˇ ení beaconu Jaalee z celkových šedesáti pˇri periodˇe vysílání 1000 ms a vysílacím výkonu 4 dBm v závislosti na ruzných ˚ vzdálenostech. 27 Závislost skuteˇcné vzdálenosti beaconu Jaalee v metrech na mˇerˇ ené vzdálenosti na mobilním telefonu, taktéž v metrech, pro dvˇe série mˇerˇ ení za stejných podmínek. 28 Závislost skuteˇcné vzdálenosti beaconu Jaalee v metrech na obrácené síle signálu v dBm pro dvˇe série mˇerˇ ení za stejných podmínek. 29 Poˇcet úspˇešných mˇerˇ ení beaconu Estimote z celkových šedesáti pˇri periodˇe vysílání 1000 ms a vysílacím výkonu 0 dBm v závislosti na ruzných ˚ vzdálenostech. 31 Závislost skuteˇcné vzdálenosti beaconu Estimote v metrech na mˇerˇ ené vzdálenosti na mobilním telefonu, taktéž v metrech, pro dvˇe série mˇerˇ ení za stejných podmínek. 32 2
˚ SEZNAM OBRÁZK U 3.9
Závislost skuteˇcné vzdálenosti beaconu Estimote v metrech na obrácené síle signálu v dBm pro dvˇe série mˇerˇ ení za stejných podmínek. 33 3.10 Porovnání fluktuace obrácené síly signálu RSSI (dBm) v cˇ ase pro beacon Jaalee ve vzdálenosti jednoho a tˇrí metru. ˚ 34 3.11 Porovnání fluktuace obrácené síly signálu RSSI (dBm) v cˇ ase pro beacon Jaalee ve vzdálenosti jednoho a tˇrí metru˚ s aplikací klouzavého prumˇ ˚ eru o hodnotˇe pˇeti sekund. 35 3.12 Porovnání fluktuace obrácené síly signálu RSSI (dBm) v cˇ ase pro beacon Estimote ve vzdálenosti jednoho a tˇrí metru. ˚ 36 4.1
4.2
4.3 4.4
4.5
4.6
4.7 4.8
Pˇrehled základních obrazovek jednotlivých záložek aplikace. Vlevo záložka Map, uprostˇred záložka Data a na posledním místˇe záložka Status. 38 Ukázková situace výmˇeny dat mezi beaconem, API serverem a dvˇema uživateli v systému, kteˇrí si mohou navzájem vymˇenovat ˇ data, ale z nichž pouze jeden má spojení se serverem. 40 Model perzistentního úložištˇe dat CoreData využívaný pro ukládání beacon dat. 41 Ukázka komunikace mezi zaˇrízeními, která nedisponují kompatibilní technologií, v prostˇredí frameworku MultipeerConnectivity. Data jsou v takovém pˇrípadˇe pˇreposílána pˇres dalšího úˇcastníka, který technologie obou komunikujících stran podporuje. 43 Schéma volání funkcí pro komunikaci mezi aplikací napsanou ve Swiftu a komponentou WKWebView obsahující kód napsaný v JavaScriptu. 47 Ukázka zobrazení beaconu 2|1 ve vzdálenosti 5,8327 metru˚ od telefonu Adam’s iPhone a druhého beaconu 4|1, u nejž není znám žádný vzdálenostní vztah k ostatním zaˇrízením v systému. 50 ER diagram databáze MySQL pro ukládání beacon záznamu˚ na serveru. 51 Ukázka rozhraní prezentaˇcního serveru. 52 3
˚ SEZNAM OBRÁZK U 4.9
První praktický test aplikace se dvˇema mobilními zaˇrízeními a cˇ tyˇrmi beacony. Na levé stranˇe je skuteˇcné rozložení komponent, na pravé stranˇe je vizualizace v aplikaci. 55 4.10 Druhý praktický test aplikace se dvˇema mobilními zaˇrízeními a tˇremi beacony. Na levé stranˇe je skuteˇcné rozložení komponent, na pravé stranˇe je vizualizace v aplikaci. 56 5.1
Porovnání aktuálního stavu zobrazení beaconu˚ se znalostí vzdáleností k mobilnímu zaˇrízení (vlevo) a možné rozšíˇrení pro pˇresnˇejší lokalizaci se znalostí konkrétního umístˇení beaconu˚ a vzdálenostních vztahu˚ mezi nimi (vpravo). 59
4
Seznam tabulek 2.1
Pˇrehled identifikaˇcních parametru˚ používaných v technologii iBeacon 10
3.1
Pˇrehled konstant útlumu signálu pro jednotlivá prostˇredí (pˇrevzato z [10]) 24
5
Kapitola 1
Úvod Diplomová práce se zabývá problematikou pomˇernˇe mladé technologie nazvané iBeacon (nebo jednoduše beacon, cˇ esky také maják), pˇredstavenou v polovinˇe roku 2013 firmou Apple. Pojmem iBeacon se oznaˇcují malá zaˇrízení postavená na bázi Bluetooth 4.0 Low Energy napájená vˇetšinou pouze knoflíkovou baterií, která mají nízkou spotˇrebu a oˇcekávanou životnost od jednoho mˇesíce do nˇekolika let. Tato malá zaˇrízení vysílající v krátkých intervalech signál pak ve spolupráci s mobilními zaˇrízeními, které signál zachytí, dokážou vytvárˇ et lokální navigaˇcní a poziˇcní systémy, které se zaˇcínají využívat v ruzných ˚ odvˇetvích. Cílem práce je tuto technologii dukladnˇ ˚ e prozkoumat, zjistit její vlastnosti a omezení, a na základˇe tˇechto omezení vytvoˇrit aplikaci pro iOS s podporou webového serveru, která by prezentovala možnosti této technologie. V kapitole 2 je technologie iBeacon dukladnˇ ˚ e popsána vˇcetnˇe její návaznosti na technologii Bluetooth, jsou popsány požadavky na kompatibilní zaˇrízení a ruzné ˚ druhy iBeacon hardwaru. Dále jsou uvedeny reálné pˇríklady použití a problémy technologie, se kterými je nutné pˇri nasazení poˇcítat. V další samostatné kapitole 3 se práce vˇenuje pˇredevším problematice urˇcování vzdálenosti, která je pˇri lokalizaci zásadní. Souˇcástí jsou praktická mˇerˇ ení dvou beaconu˚ od výrobcu˚ Jaalee a Estimote. Další kapitola 4 již popisuje samotnou implementaˇcní cˇ ást diplomové práce vˇcetnˇe implementace iOS aplikace a webového serveru. Pˇredposlední kapitola 5 diskutuje problematiku úplné rekonstrukce zobrazení pohybu uživatelu˚ a možnosti budoucího rozšíˇrení této práce. Poslední kapitola 6 shrnuje výsledky této práce a hodnotí její pˇrínos v oblasti technologie iBeacon.
6
Kapitola 2
Technologie iBeacon Lidstvo se ruznými ˚ formami navigace zabývá již mnoho staletí. Nejprimitivnˇejší formy navigace zapoˇcaly již v dobˇe pˇred našim letopoˇctem, kdy nebyly k dispozici žádné specializované nástroje, ani sofistikované techniky. Jednalo se pˇredevším o navigaci podle polohy Slunce a hvˇezd. Pˇresnˇejší formy navigace pak pˇricházely postupnˇe s ruznými ˚ vynálezy. Zˇrejmˇe prvním nejvýznamnˇejším vynálezem byl magnetický kompas, který se v ruzných ˚ zdokonalených a miniaturizovaných podobách (gyrokompas, magnetometr apod.) používá dodnes. S rozmachem moˇreplavby a následného objevování nových koutu˚ planety Zemˇe v 15. století se pak objevovaly další pˇrístroje, jako sextant nebo kvadrant, a matematické postupy zdokonalující navigaci. Tradiˇcní metody doplnily v moderní dobˇe techniky jako rádiová navigace, radarová nebo satelitní navigace. Dalo by se rˇ íci, že mnoho technik a postupu˚ se navzájem prolíná a doplnuje ˇ ai v dnešní dobˇe nacházejí tradiˇcní metody navigace stále své místo v nejruznˇ ˚ ejších odvˇetvích. Ze všech tˇechto technik se ale pˇrece jenom jedna z nich co do významnosti vymyká. Touto technikou je satelitní navigace, která se v dnešní dobˇe nachází prakticky ve všech chytrých mobilních telefonech a dalších bˇežnˇe používaných elektronických zaˇrízeních. Aˇckoliv se pod pojmem satelitní navigace skrývá mnoho systému, ˚ dva nejvýznamnˇejší globální systémy jsou dnes GPS (Global Positioning System) pod správou USA a ménˇe známý GLONASS pod správou Ruska. První pokusy se satelitní navigací zaˇcaly již v 60. letech 20. století, avšak vˇetší rozmach probˇehl až po roce 1983, kdy byla, do té doby uzavˇrená GPS navigace, zpˇrístupnˇená veˇrejnosti. Zˇrejmˇe proto se dnes u laické veˇrejnosti, ale nejenom u ni, cˇ asto setkáváme se zámˇenou pojmu GPS pro obecný pojem satelitní navigace. Protože je 7
2. T ECHNOLOGIE I B EACON oznaˇcení GPS v tomto významu natolik bˇežné, je používáno i v dalších referencích v této práci. GPS je dnes bˇežnˇe využívána v mnoha oblastech, od vojenských úˇcelu˚ pˇres námoˇrní navigaci a civilní využití pro úˇcelnou navigaci (napˇr. v autˇe) až po volnoˇcasové aktivity (napˇr. celosvˇetovˇe oblíbená outdoorová hra Geocaching1 ). Princip samotného urˇcování polohy je koncepˇcnˇe pomˇernˇe jednoduchý. Je zapotˇrebí, aby mˇel GPS pˇrijímaˇc pˇrímou viditelnost na minimálnˇe 4 satelity. Každý z nich vysílá v pravidelných intervalech informace o své aktuální poloze a aktuální cˇ as. Tyto informace putují rychlostí svˇetla k GPS pˇrijímaˇci. Ten je zachytí a dokáže z nich podle zpoždˇení, s jakou zprávu obdržel, vypoˇcítat vzdálenost každého ze satelitu. ˚ V momentˇe, kdy má k dispozici tyto informace, lze pomocí techniky geometrické triangulace vypoˇcítat aktuální polohu na zemi. Jak již bylo rˇ eˇceno, aby takový systém mohl fungovat, musí být zajištˇena pˇrímá viditelnost na minimálnˇe 4 satelity. Tˇech krouží kolem planety dostateˇcný poˇcet, a tedy na jakémkoliv místˇe na zemˇekouli je tato podmínka ve venkovních lokacích zajištˇena. Problém nastává v místech, kde je výhled na oblohu blokován. To je pˇredevším pod povrchem zemˇe, uvnitˇr budov, v hustém lese, ale i v hustˇe osídlených urbanistických zástavbách, pˇredevším s velkým poˇctem výškových budov. V takových situacích dokáže GPS systém fungovat bud’ velice omezenˇe a nebo vubec. ˚ Pro navigaci v mobilních telefonech, kterému se v pˇrední rˇ adˇe vˇenuje tato diplomová práce, se jako náhradní rˇ ešení používá triangulace pomocí signálu z telekomunikaˇcních vˇeží, doplnˇená o pˇrípadnou Wi-Fi navigaci2 . Ani jeden z tˇechto pˇrístupu˚ však není zdaleka tak pˇresný jako GPS, které poskytuje ve vˇetšinˇe pˇrípadu˚ vyšší pˇresnost než 3,5 metru [26]. Kromˇe zmínˇených dvou metod, které se v dnešní dobˇe v mo1. http://www.geocaching.com 2. Wi-Fi navigace funguje na stejném principu triangulace (pˇrípadnˇe trilaterace) jako ostatní metody navigace. Pˇredpokladem je pomˇernˇe hustá sít’ Wi-Fi pˇrístupových bodu, ˚ která se obvykle nachází ve vˇetších mˇestech a v hustˇe obydlených oblastech. Mnoho telekomunikaˇcních poskytovatelu˚ a výrobcu˚ telefonu˚ vlastní v souˇcasné dobˇe pomˇernˇe rozsáhlé databáze tˇechto bodu˚ spolu s informacemi o GPS souˇradnicích, které získaly od uživatelu, ˚ popˇrípadˇe vlastními silami (napˇr. Google Street View auta monitorují tyto Wi-Fi pˇrístupové body). Pokud je tedy v dosahu více Wi-Fi sítí se známými pozicemi, lze pomˇernˇe jednoduše urˇcit vlastní pˇribližnou polohu, aˇckoliv ne pˇríliš pˇresnou.
8
2. T ECHNOLOGIE I B EACON bilních telefonech pro indoor navigaci používají, pˇredstavila firma Apple v cˇ ervnu 2013 na každoroˇcnˇe poˇrádané konferenci WWDC v Kalifornii indoor poziˇcní systém iBeacon postavený na technologii Bluetooth. iBeacon by se však dal popsat spíše jako mikronavigaˇcní systém, protože jeho dosah je pomˇernˇe omezený a nedosahuje ani vysokého stupnˇe pˇresnosti. Stejnˇe jako je GPS navigace neocenitelným pomocníkem u venkovních aktivit, indoor navigace si klade za cíl usnadnit navigaci pˇredevším uvnitˇr budov nebo na místˇe, kde není GPS navigace použitelná. Takovými místy mohou být moderní vícepodlažní nákupní stˇrediska, veletrhy, festivaly, konference, prostory nemocnic a úˇradu, ˚ továrny nebo i ruzné ˚ zábavní parky. Pro nasazení technologie iBeacon je potˇreba mít dvˇe základní komponenty. Tˇemi jsou iBeacon vysílaˇc a iBeacon pˇrijímaˇc. iBeacon pracuje na energeticky velmi nenároˇcném standardu Bluetooth 4.0 Low Energy (BLE), díky nˇemuž umožnuje ˇ beaconum ˚ dlouhou operaˇcní životnost na baterie. Beacon je cˇ asto miniaturní lehké zaˇrízení, mˇerˇ ící v prumˇ ˚ eru pouhých nˇekolik centimetru. ˚ Toto zaˇrízení vysílá v pravidelných intervalech Bluetooth pakety se speciální strukturou (angl. advertisments), které obsahují UUID, hodnotu Major a hodnotu Minor. UUID (Universally unique identifier) je identifikaˇcní standard používaný pro identifikaci systému˚ bez nutnosti správy centrální databází. Jedná se o rˇ etˇezec 32 hexadecimálních znaku˚ oddˇelených cˇ tyˇrmi pomlˇckami ve tvaru 8-4-4-4-12 (poˇcet znaku˚ mezi pomlˇckami). Pˇríkladem takového identifikátoru je rˇ etˇezec B0702880A295-A8AB-F734-031A98A512DE. Oznaˇcením „universally unique“ v názvu se nemyslí faktická jedineˇcnost každého vygenerovaného UUID, ale spíše fakt, že takových rˇ etˇezcu˚ muže ˚ být pˇribližnˇe 3.4 × 38 10 , a kolize v reálném svˇetˇe tedy nastávají spíše výjimeˇcnˇe. U technologie iBeacon se jedineˇcnosti UUID identifikátoru˚ využívá pro odlišení vlastní skupiny beaconu˚ od cizích systému. ˚ Bˇežnou praxí je, že má skupina beaconu˚ stejné UUID a k rozlišení se používají další hodnoty vysílané v beacon paketu, tedy Major a Minor. V obou pˇrípadech se jedná o bezznaménková cˇ ísla o velikosti 2 bajty, tedy hodnoty 0 až 65535. Všechny tˇri hodnoty jsou pˇrehlednˇe popsány a shrnuty v tabulce 2.1. Beacon je sám o sobˇe „hloupé“ zaˇrízení, které nemá jakoukoliv možnost komunikace s okolním svˇetem. Neví nic o svém prostˇredí, 9
2. T ECHNOLOGIE I B EACON Pole
Velikost
Hodnota napˇr. B0702880A295-A8AB-F734031A98A512DE
UUID
16 bytu˚
Major
2 byty
0 až 65535
Minor
2 byty
0 až 65535
Popis Hlavní identifikaˇcní rˇ etˇezec spoleˇcný pro celou sadu beaconu. ˚ Slouží pro rozdˇelení sady beaconu˚ na menší regiony. Slouží pro ještˇe jemnˇejší rozdˇelení na subregiony.
Tabulka 2.1: Pˇrehled identifikaˇcních parametru˚ používaných v technologii iBeacon
kde se nachází, a neví ani o žádných zaˇrízeních v okolí. Jeho jedinou úlohou je v pravidelných intervalech vysílat Bluetooth pakety s výše popsanými identifikaˇcními údaji. Dosah tˇechto zaˇrízení se liší od výrobce k výrobci a dle konkrétního typu, ale v zásadˇe je dán omezením BLE technologie. Teoreticky se jedná o vzdálenost do sta metru˚ v otevˇreném prostoru. Reálnˇe je však tento dosah mnohem menší a velmi jej, kromˇe fyzických pˇrekážek, ovlivnují ˇ také elektromagnetické interference a další externí vlivy. Druhou komponentou technologie iBeacon je pˇrijímaˇc. V našem pˇrípadˇe se bude jednat o mobilní komunikaˇcní zaˇrízení (chytrý telefon, tablet apod.), opˇet vybavený technologií BLE. Telefon má tedy aktivovaný režim Bluetooth a naslouchá paketum ˚ v okolí (v angliˇctinˇe se tento proces oznaˇcuje jako ranging for beacons). Pokud se v dosahové vzdálenosti nachází beacon, telefon pˇrijímá jeho pakety, ze kterých dokáže vyˇcíst (kromˇe jiných, viz dále) již tˇri zmínˇené identifikaˇcní údaje, a dokáže urˇcit sílu pˇrijatého signálu (RSSI). Pro indoor navigaci je tato hodnota zˇrejmˇe nejduležitˇ ˚ ejší, protože se z ní vypoˇcítává odhadovaná vzdálenost od beaconu. Tato vzdálenost se dá vyjádˇrit pˇrímo v metrech, ale iBeacon pracuje spíše s tˇremi základními hladinami vzdálenosti (angl. proximity). Tˇemi jsou immediate (bezprostˇrední, cca do 50 cm), near (blízká, nˇekolik metru) ˚ a far (vzdálená, od vzdálenosti nˇekolika metru˚ dále)3 . Kromˇe toho se vzdále3. Konkrétní vzdálenosti nejsou v žádné specifikaci pevnˇe urˇceny. Ruzné ˚ zdroje uvádˇejí ruzné ˚ hodnoty.
10
2. T ECHNOLOGIE I B EACON nost vyjadˇruje hodnotou unknown (neznámá), která nám rˇ íká, že je možné pˇrijmout signál, ale není možné rozpoznat vzdálenost takového zaˇrízení. Hladiny vzdálenosti jsou zobrazeny na náˇcrtku 2.1, kde se v levé cˇ ásti nachází beacon a kolem nˇej vytyˇcují jednotlivé kružnice cˇ tyˇri úrovnˇe. Signálem a z ní vypoˇcítávané pˇresnosti se zabývá kapitola 3.
Obrázek 2.1: Znázornˇení základních úrovní vzdálenosti u technologie iBeacon (angl. proximity).
2.1 Bluetooth Jak již bylo zmínˇeno, dostupnost iBeacon závisí technologicky na dostupnosti Bluetooth 4.0 Low Energy (BLE), standardu, který byl schválen 30. cˇ ervna 2010. Oproti Bluetooth starších verzí se jedná v podstatˇe o zcela nový standard, který byl puvodnˇ ˚ e vyvinut experty v Nokia a uveden na trh pod názvem Wibree. Po jednání s Bluetooth SIG4 a po integrování dalších technologií pro snížení spotˇreby od firmy Nordic Semiconductor došlo k vytvoˇrení standardu BLE [25]. BLE muže ˚ fungovat ve dvou módech: periferní a centrální. U periferního zaˇrízení je podle standardu oˇcekáváno, že bude vysílat data nebo poskytovat informace o svém stavu a bude energeticky velmi nenároˇcné. U zaˇrízení v centrálním módu se naopak tato informace 4. Bluetooth Special Interest Group je skupina dohlížející na vývoj standardu Bluetooth vˇcetnˇe udˇelování licencí a ochranných známek výrobcum. ˚
11
2. T ECHNOLOGIE I B EACON pˇrijímá, zpracovává a zaˇrízení je vˇetšinou napájeno z baterie s vyšší kapacitou (telefon, tablet atd.). Návrh tˇechto zaˇrízení muže ˚ být (a cˇ asto i je) velmi odlišný a odráží tak rozdílnosti v nárocích na výrobní náklady, energetickou úspornost a celkovou složitost. U mobilních telefonu˚ se však tyto rozdíly stírají podporou obou módu˚ v jediném zaˇrízení. BLE vysílá na frekvenci 2.4 GHz s 40 kanály o šíˇrce 2.0 MHz. Z 40 kanálu˚ je 37 použito pro výmˇenu dat u spárovaných zaˇrízení a 3 pro zasílání advertisementu. ˚ Pouze tyto 3 kanály se používají u iBeaconu. ˚ Ty byly zámˇernˇe zvoleny, aby nekolidovaly s kanály pro Wi-Fi a pˇri vysílání se paket postupnˇe odesílá na všech tˇrech kanálech. Pro monitorující zaˇrízení staˇcí paket zachytit na jednom z nich, cˇ ímž se tato technologii stává o nˇeco robustnˇejší a ménˇe náchylnou na rušivé vlivy okolí [25].
2.2 Podpora v zaˇrízeních a specifika platforem U firmy Apple byly prvními pˇrístroji s podporou BLE, a tedy i s podporou iBeacon, telefon iPhone 4S a tablet iPad 3. generace uvedené v roce 2012. Softwarová podpora iBeacon však pˇrišla až s operaˇcním systémem iOS 7 v cˇ ervnu 2013. U ostatních výrobcu˚ mobilních telefonu˚ a tabletu˚ je situace ponˇekud roztˇríštˇenˇejší, ale obecnˇe lze rˇ íci, že v souˇcasnˇe dobˇe (jaro 2015) jsou již prakticky všechna produkovaná zaˇrízení vybavena technologií BLE, jelikož již v roce 2013 bylo odhadované, že se poˇcty zaˇrízení s BLE pohybují ve stovkách milionu˚ kusu˚ [25]. Operaˇcní systém Android zavedl podporu iBeacon ve verzi 4.3. V této verzi však telefon dokázal pouze pˇrijímat iBeacon zprávy, ale nedokázal vysílat. Podpora pro vysílání byla pˇridána ve verzi 5.0 [11]. Nejedná se o vlastnost váznou pˇrímo na technologii iBeacon, ale pouze o specifika Bluetooth implementace, kdy ve verzi 5.0 pˇribyla podpora periferního módu. Je duležité ˚ zmínit, že Apple do iOS zavedl omezení, které neumožnuje ˇ mobilnímu zaˇrízení zachytávat zprávy všech beaconu˚ v okolí, ale pouze tˇech se známým UUID. Nejedná se o hardwarové omezení, protože Bluetooth dokáže zpracovat veškeré pakety, které zachytí. Jedná se pouze o softwarové omezení, které vývojáˇrum ˚ nedovoluje k tˇemto paketum ˚ pˇres API pˇristupovat. Pˇri odblokování te12
2. T ECHNOLOGIE I B EACON lefonu (tzv. jailbreak) lze zachytávat i na Apple zaˇrízeních informace o všech beaconech v okolí bez pˇredem známého UUID, stejnˇe jako u operaˇcního systému Android. Duvodem ˚ tohoto omezení muže ˚ být pˇredevším obava z možného zneužití. Dobˇre lze takovou situaci ilustrovat na hypotetickém obchodu s instalovanými beacony, kam pˇrichází zákazníci s nainstalovanou aplikací tohoto obchodu, které je má upozornovat ˇ napˇríklad na probíhající slevové akce. Pokud pˇrijde do obchodu konkurence se zaˇrízením, které dokáže odposlouchávat všechny beacony, dokáže také rozpoznat UUID tohoto obchodu a vysílat následnˇe falešné iBeacon zprávy, které aplikace zákazníka zpracuje stejnˇe jako originální pakety z beaconu˚ obchodníka. Podrobnˇeji o problémech technologie iBeacon v kapitole 2.6. Z dalších mobilních OS je iBeacon podporován i pomˇernˇe minoritním systémem BlackBerry (verze 10) [16]. Naopak Windows Phone (ve verzi 8.1) podporuje BLE pouze omezenˇe a provoz iBeacon aplikací není možný. Situace by se mˇela zmˇenit až ve verzi 10, která by s sebou mˇela pˇrinést spoleˇcný codebase pro desktopovou i mobilní verzi operaˇcního systému, a kde se již s iBeacon podporou poˇcítá [21]. Kromˇe mobilních zaˇrízení je iBeacon zprávy možné zachytávat také na bˇežných poˇcítaˇcích s Bluetooth modulem, avšak reálné nasazení pro indoor navigaci je v tomto pˇrípadˇe velmi omezené, protože s poˇcítaˇcem (i pˇrenosným) se uživatel vˇetšinou nepohybuje prostorem, a využití se tak omezuje spíše na stacionární monitorování. Pro poˇcítaˇce Apple pˇrišla podpora s operaˇcním systémem OS X 10.9 Mavericks.
2.3 Beacon zaˇrízení iBeacon zaˇrízení je obvykle složeno z Bluetooth cˇ ipsetu, baterie zajišt’ující pˇrísun energie a firmwaru. V souˇcasné dobˇe jsou hlavními producenty cˇ ipu˚ firmy Texas Instruments, Nordic Semiconductor, Bluegiga a Gimbal. Ponˇevadž se jedná o miniaturní zaˇrízení, použity jsou vˇetšinou lithiové knoflíkové baterie (angl. button cell nebo coin battery). Ty se vyrábí v nˇekolika velikostech a poskytují dostateˇcnou kapacitu pro nˇekolikamˇesíˇcní provoz. Více o výdrži na baterie je popsáno v kapitole 2.4. 13
2. T ECHNOLOGIE I B EACON Firmware je pak specifický kus kódu, který beaconum ˚ zajišt’uje operabilitu (vysílání signálu) a možnost konfigurace. Tato konfigurace je podle výrobce zajištˇena bud’ danou proprietární aplikací, která provede pˇripojení k beaconu, nebo muže ˚ beacon podporovat proto5 kol GATT . V takovém pˇrípadˇe lze použít nˇekterou z volnˇe dostupných aplikací podporujících tento protokol (napˇr.gattool6 ). Výrobcu˚ iBeaconu˚ je celá rˇ ada. Mezi nejznámˇejší patˇrí Estimote, RedBear, Radius Networks nebo SensorTag. Existuje ale celá rˇ ada jiných, mezi kterými se nachází jak znaˇckové modely, tak neznaˇckové ˇ e. iBemodely pocházející vˇetšinou z továren v Asii, pˇredevším v Cínˇ acony se liší vzhledem, velikostí, hmotností, dostupností7 a samozˇrejmˇe také cenou. Neznaˇckové modely lze poˇrídit od nˇekolika dolaru˚ za kus. Znaˇckové modely od významnˇejších firem pak stojí i $30, nebo více. Existují mezi nimi rozdíly v kvalitˇe zpracování, maximální síle vysílaného signálu i ve výdrži na baterie. Pˇríklady takových zaˇrízení jsou na obrázku 2.2. Na levé stranˇe jsou dva iBeacony znaˇcky Estimote bez vnˇejšího pouzdra. Lze tedy vidˇet jak knoflíkovou baterii z jedné strany, tak cˇ ipy a anténu (lomená cˇ ára v hoˇrní cˇ ásti beaconu) z druhé strany. Na pravé stranˇe je pak ukázka dvou Jaalee beaconu˚ ruzných ˚ barev vˇcetnˇe originálního pouzdra. Tato diplomová práce se zabývá spíše obecnˇejšímu náhledu na problematiku indoor navigace a detailnˇejší informace a rozdílnosti jednotlivých znaˇcek tedy pˇresahují rámec této kapitoly.
2.4 Energetická nároˇcnost Standard Bluetooth 4.0 existuje ve tˇrech specifikacích: Classic Bluetooth, Bluetooth High Speed a Bluetooth Low Energy. První dvˇe jmenované nejsou pro naše úˇcely pˇríliš pˇrínosné. Jejich opodstatnˇení lze najít napˇríklad u bezdrátových medicínských pˇrístroju˚ nebo v aplikacích pro real-time streaming audia/videa, kde se uplatní vyšší pˇrenosové rychlosti, vyšší dosah a robustnost. Naopak spotˇreba tako5. GATT (Generic Attribute Profile) je protokol definující vzájemnou komunikaci dvou zaˇrízení pˇres protokol Bluetooth [23] 6. Distribuováno spoleˇcnˇe s BlueZ, oficiálním Linux BT protokolovým zásobníkem. http://www.bluez.org 7. Nˇekteré modely se standardnˇe objednávají v jednotkách kusu, ˚ jiné lze objednávat ve stovkách až tisících pro opravdu komplexní nasazení.
14
2. T ECHNOLOGIE I B EACON
Obrázek 2.2: Ukázky iBeacon zaˇrízení ruzných ˚ výrobcu. ˚ Vlevo Estimote bez pouzdra z obou stran, vpravo Jaalee beacon s pouzdrem ve dvou odlišných barvách.
vých zaˇrízení je nˇekolikanásobnˇe vyšší a iBeacon tedy využívá energeticky úspornou specifikaci Low Energy [18]. Energetická nároˇcnost se dá posuzovat ve dvou oblastech. Jednak u samotných beaconu, ˚ jednak u zaˇrízení skenujících okolní beacony. Pro první skupinu, tedy beacony, provedla v roce 2014 kanadská spoleˇcnost Aislelabs pomˇernˇe detailní a ve své dobˇe zatím jedineˇcnou analýzu porovnávající 16 beaconu˚ ruzných ˚ výrobcu˚ [3]. Ve všech zarˇ ízeních se standardnˇe používají knoflíkové baterie ruzných ˚ kapacit. Nejˇcastˇeji se jedná o modely CR2032 (pˇribližnˇe 210 - 240 mAh), CR2450 (kolem 620 mAh) nebo vysokokapacitní CR2477 (kolem 1000 mAh). Jednotlivé modely mají vˇetšinou pˇresnˇe urˇcený typ baterie, který podporují a nelze ji nahradit jiným typem, at’ už s nižší nebo vyšší kapacitou. Je duležité ˚ tedy tomuto parametru pˇri výbˇeru vˇenoˇ vat pozornost, pokud je cílem dlouhodobá výdrž. Casto totiž vyšší kapacita odpovídá vyšší živnosti beaconu, pˇresto i výjimky by se daly nalézt. V rámci testu byly všem beaconum ˚ nastaveny frekvence vysílání 100ms, 645ms a 900ms, a ruzné ˚ síly signálu, pokud výrobce tato nastavení podporoval. Mˇerˇ ení probíhala po dobu tˇrí mˇesícu. ˚ Jelikož je reálná výdrž vˇetšiny modelu˚ vyšší než tˇri mˇesíce, odhady výdrže byly stanoveny na základˇe mˇerˇ ení zbývající kapacity a odbˇeru proudu. Rozdíly mezi jednotlivými modely beaconu˚ byly pomˇernˇe významné. Nejhorší model dokázal pracovat pouhý mˇesíc, nejlepší 15
2. T ECHNOLOGIE I B EACON je pak odhadován na úctyhodných 24 mˇesícu. ˚ Prumˇ ˚ er všech beaconu˚ vychází na 11.625 mˇesícu, ˚ tedy necelý rok provozu. Stejná spoleˇcnost Aislelabs provedla také analýzu spotˇreby baterie v telefonech s operaˇcním systémem iOS [2] a Android [4]. Z výsledku˚ vyplývá, že novˇejší telefony mají obecnˇe nižší spotˇrebu kvuli ˚ novˇejším cˇ ipum ˚ a jejich optimalizacím. Duležité ˚ také je množství iBeaconu˚ v okolí, kdy opˇet obecnˇe platí, že pˇri nízkém nebo nulovém poˇctu je spotˇreba baterie nižší. Naopak pˇri vˇetším poˇctu skenovaných beaconu˚ je spotˇreba vyšší, a to v nˇekterých pˇrípadech až pˇetinásobnˇe. Z analýzy také vyplynulo, že dopad na baterii u Android zaˇrízení je cˇ asto významnˇe nižší než u iOS zaˇrízení. Tvurci ˚ spekulují, že by tato odlišnost mohla být zpusobena ˚ rozdílným principem vzorkování pˇrímo na Bluetooth cˇ ipech daných telefonu. ˚ V absolutních cˇ íslech se pak spotˇreba za hodinu pˇri testech podepsala cˇ asto cˇ tyˇrmi i více procenty. Analýza však probíhala s aplikacemi, které provádˇely skenování každou sekundu, a v reálných aplikacích by tato frekvence mˇela být nižší. Tvurci ˚ tedy odhadují, že reálný dopad na baterii telefonu nebude u žádného modelu vyšší než 1% bˇehem 12 hodinové periody. Spotˇrebu baterie smartphonu˚ ovlivnují ˇ ve výsledku pˇredevším následující parametry: Nejvýznamnˇejším ukazatelem je samotné zarˇ ízení a Bluetooth hardware, dále frekvence skenování a poˇcet beaconu˚ v okolí. Zajímavˇejší ovšem je, že spotˇrebu ovlivnuje ˇ také frekvence vysílání iBeaconu. ˚ Pokud vezmeme v potaz beacon A a beacon B s frekvencemi 100ms a 500ms, zachytí telefon bˇehem sekundy spojitého skenování beacon A desetkrát, zatímco beacon B pouze dvakrát. Vyšší frekvence vysílání je výhodná z hlediska pˇresnˇejšího mˇerˇ ení signálu a jeho vyhlazování, ale vyžaduje vyšší spotˇrebu pro zpracování. Vyšší frekvence vysílání tedy snižuje životnost baterie nejen iBeaconu, ale i smartphonu [4].
2.5 Reálné možnosti využití iBeacon Možnosti využití technologie iBeacon jsou vskutku rozmanité. Od svého uvedení se objevila celá rˇ ada oˇcekávaných i zcela netradiˇcních zpusob ˚ u, ˚ jakým tuto všestrannou technologii nasadit. Nejˇcastˇeji se jedná o odvˇetví týkající se fyzického prodeje zboží a s ním související 16
2. T ECHNOLOGIE I B EACON marketing produktu. ˚ Spoleˇcnosti Carrefour a Nisa napˇríklad využívají v nˇekterých svých obchodech vozíky osazené beacony, které mají za úkol sledovat pohyb zákazníku˚ po obchodˇe [6]. Kromˇe celkového cˇ asu stráveného na poboˇcce získávají prodejci anonymní informace také o délce setrvání v ruzných ˚ sekcích obchodu a další užiteˇcná data. Nejvˇetší výhodou tohoto rˇ ešení je, že si zákazník na svuj ˚ smartphone nemusí instalovat žádnou aplikaci a dokonce ani žádný smartphone nemusí vlastnit. Nemusí tedy mˇenit své návyky a systém není vázán na zákazníkovu jakoukoliv aktivní participaci. Naopak pro využití systému, který zavedl PayPal v kavárnˇe ve svém sídle v Kalifornii, je nutné vlastnit chytré hodinky (angl. smartwatch) [17]. Zákazník, který vstoupí do kavárny, je identifikován nainstalovaným beaconem a systém poskytne obsluze zajímavé údaje, jako napˇríklad jméno s fotografii, aby mohl zákazníka pozdravit, nebo seznam pˇredešlých objednávek, aby zákazníkovi rovnou nabídl jeho nejˇcastˇeji konzumované jídlo nebo oblíbený nápoj. Pˇri placení pak obdrží zákazník na své chytré hodinky potvrzení objednávky, které muže ˚ jediným dotykem potvrdit. Letecká spoleˇcnost EasyJet testuje již nˇekolik mˇesícu˚ na letištích ve Velké Británii a Francii systém postavený na technologii iBeacon, která pomáhá cestujícím v orientaci na letištích London Luton, London Gatwick a Paris Charles de Gaulle. Pro využití je ovšem nutné mít nainstalovanou pˇríslušnou EasyJet aplikaci [8]. Velmi podobného nasazení se tato technologie doˇckala i na letišti Heathrow, taktéž ve Velké Británií, kde chce letecká spoleˇcnost Virgin Atlantic pomáhat svým zákazníkum ˚ pˇri pruchodu ˚ letištˇem [27]. Na festivalu v Cannes byl nasazen systém, který umožnoval, ˇ kromˇe navigace po areálu festivalu, kontaktování dalších návštˇevníku˚ v okolí. Opˇet byla pˇredpokladem nainstalovaná festivalová aplikace využívající zprávy vysílané z rozmístˇených beaconu˚ [12]. Zajímavé bývají také projekty využívající gamifikaci. Na výstavˇe CES v Las Vegas rozestavili organizátoˇri nˇekolik beaconu˚ na ménˇe populárních místech, kam normálnˇe velký poˇcet lidí nezavítá [22]. Po stáhnutí aplikace se uživatel dozví obecné informace o jednotlivých beaconech, v jaké budovˇe se nachází a mužou ˚ zaˇcít hledat. Jakmile se dostanou do bližší vzdálenosti, aplikace je na to upozorní, a uživatelé získávají za nalezené beacony odznaky. Také v muzeu New Museum v New Yorku využili urˇcitou formu gamifikace. Tento17
2. T ECHNOLOGIE I B EACON krát ke zvýšení povˇedomí o výskytu skrytých min na zemˇekouli [13]. Rozestavením beaconu˚ v muzeu tak vytvoˇrili organizátoˇri virtuální minové pole, kterým procházeli návštˇevníci. Pokud si do svého smartphonu stáhli aplikaci Sweeper pro iOS nebo Android, tak v pˇrípadˇe detekce polohy v tˇesné blízkosti nˇekteré z virtuálních min (beaconu) probˇehl na displeji (opˇet virtuální) výbuch a byl spuštˇen zvukový záznam exploze. Následnˇe si mohli návštˇevníci poslechnout nˇekteré zajímavé informace a pˇrípadnˇe vˇenovat drobný finanˇcní obnos. Na otázku bezpeˇcnosti v ulicích se pak zamˇerˇ ila telekomunikaˇcní spoleˇcnost O2 spoleˇcnˇe s reklamní agenturou Plan.Net v nˇemeckém Mnichovˇe [1]. Iniciátoˇri kampanˇe si povšimli pomˇernˇe rozšíˇreného nešvaru dnešní mládeže chodit po ulicích, kdy nesledují dˇení kolem sebe a vˇenují se pouze svému mobilnímu telefonu. Takové chování muže ˚ být velmi nebezpeˇcné, pokud dítˇe nebo teenager vstoupí do vozovky aniž by se rozhlédli, zda se neblíží automobil. V rámci kampanˇe tedy na nˇekolik desítek kˇrižovatek umístili beacony, které osobˇe s nainstalovanou aplikací Watch Out! zobrazí v blízkosti tˇechto kˇrižovatek na displeji upozornˇení. Teoreticky tak muže ˚ takový systém zabránit fatálním následkum, ˚ kdy se uživatel vˇcas probere zpˇet do reality a rozhlédne se kolem sebe než vykroˇcí do vozovky. Tyto pˇríklady jsou pouze zlomkem skuteˇcného nasazení technologie iBeacon. Lze objevit celou rˇ adu dalších využití a každým dnem se množství takových projektu˚ zvyšuje. Aˇckoliv by se mohlo zdát, že se jedná o vyspˇelou technologii, opak je pravdou a žádné nasazení v masivním mˇerˇ ítku zatím nebylo uskuteˇcnˇeno. Vˇetšina projektu˚ je spíše menších a jejich cílem je technologii otestovat a stanovit hranice využitelnosti. Situace se ale zlepšuje mílovými kroky a zdá se, že technologie zraje skuteˇcnˇe rychle. Ponˇevadž dnes již prakticky všechny mobilní telefony iBeacon podporují, mohli bychom se velice brzy setkat opravdu významného nasazení, at’ již v zahraniˇcí nebo u ˇ nás v Ceské republice.
2.6 Problémy a omezení technologie iBeacon pakety v sobˇe neobsahují žádný mechanismus šifrování a jsou tedy volnˇe viditelné pro všechna zúˇcastnˇená zaˇrízení v okolí. Útoˇcník muže ˚ teoreticky takové pakety zachytit a následnˇe pˇrehrát 18
2. T ECHNOLOGIE I B EACON potenciálním obˇetem (tzv. replay útok). Tím muže ˚ docílit neúmyslné spuštˇení interakce, pro kterou je odpovídající aplikace, nainstalovaná na mobilním zaˇrízení obˇeti, naprogramována (angl. spoofing). Vzhledem k tomu, že se pˇrenáší pouze tˇri identifikaˇcní údaje, nelze pˇrímo spouštˇet žádný škodlivý kód, pokud se souˇcasnˇe nezneužije ještˇe další chyba v mobilní aplikaci. Celkovˇe je ale pravdˇepodobnost reálného škodlivého zneužití pomˇernˇe nízká. Možné je také zasílat nesprávné nebo nerelevantní identifikaˇcní údaje. V takovým pˇrípadˇe se lze útoku pomˇernˇe efektivnˇe bránit jednoduchou ignorací tˇechto chybných paketu. ˚ Je však duležité ˚ upozornit, že možnost zachycení paketu˚ kýmkoliv v okolí není chybou v návrhu protokolu. Jedná se o vlastnost, se kterou se musí poˇcítat pˇri návrhu vlastní implementace. Kýženého cíle se dosáhne nejlépe tak, že se aplikace navrhne tím zpu˚ sobem, aby byly následky pˇrípadného spoofingu jednoduše nerelevantní nebo aby nijak neovlivnovaly ˇ následné operace v systému. Další možností je pak použít iBeacon v kombinaci s dalšími technologiemi nebo mechanismy. Touto cestou se vydala firma PayPal, která se snaží beacony použít pro zjednodušení platebních operací v kamenných obchodech. Samotné beacony jsou v procesu použity pouze pro iniciaci. Následná komunikace pak probíhá jinými kanály a hlavnˇe v procesu dochází k ovˇerˇ ování identity uživatele skrze zabezpeˇcené servery PayPal [25]. Urˇcitým úskalím muže ˚ být taktéž jedineˇcnost UUID identifikátoru˚ v rámci více systému. ˚ Jednotliví výrobci cˇ asto používají pouze jedno UUID pro všechny své beacony a problém nastane v situaci, kdy vývojáˇr nebo správce iBeacon systému tento identifikátor nezmˇení. Z tohoto duvodu ˚ a samozˇrejmˇe také z duvodu ˚ hypotetické možnosti kolize generovaného UUID, vznikla na internetu iniciativa OpenUUID8 , která si klade za cíl vytvoˇrit ucelenou databází pro pˇridˇelování skuteˇcnˇe jedineˇcných identifikátoru˚ – alesponˇ v rámci tohoto systému. Bohužel nejsou dohledatelné pˇresné statistiky ohlednˇe využívanosti této služby a je nutno ji chápat pouze jako pokus zajistit urˇcitou standardizaci v pˇridˇelování UUID. Další oblasti již nejsou ani tak problémy, jako spíše omezení dané technologie. V první rˇ adˇe se jedná o dosah signálu a oblast pokrytí. 8. https://openuuid.lime-company.eu
19
2. T ECHNOLOGIE I B EACON Hodnoty se liší model od modelu, ale obecnˇe se nejedná o vzdálenosti vyšší než 100 metru, ˚ jelikož se zde již naráží na možnosti samotné technologie Bluetooth. Na volném prostranství udávají výrobci hodnoty mezi 20 až 70 metry, které uvnitˇr budov nebo kvuli ˚ fyzickým pˇrekážkám ještˇe klesají. Pro stabilní pokrytí vˇetší oblasti je tedy nutné pomˇernˇe velké množství beaconu, ˚ což muže ˚ být finanˇcnˇe nároˇcná investice. Stejnˇe tak výdrž na baterie nemusí být ve všech pˇrípadech ideální, jak bylo popsáno v sekci 2.4. Samostatnou oblastí je pak urˇcování vzdálenosti od iBeacon vysílaˇce, které muže ˚ být (a je) v mnoha pˇrípadech velmi nepˇresné. Aˇckoliv se opˇet nejedná o problém samotné technologie, jelikož ta nebyla pro získávání pˇresných lokalizaˇcních informací primárnˇe stavˇena, jedná se o velmi zajímavou oblast, které se z velké vˇetšiny vˇenuje tato DP. Více je proto tato problematika rozepsána v následující kapitole 3.
20
Kapitola 3
iBeacon a urˇcování vzdálenosti Urˇcování vzdálenosti pomocí technologie iBeacon je pomˇernˇe komplexní oblast, která si zasluhuje samostatnou kapitolu. Pˇri monitorování okolních beaconu˚ mužeme ˚ jednoduše získat údaj o síle pˇrijatého ˚ er hodnot získaných od signálu (RSSI1 ), což je ve skuteˇcnosti prumˇ posledního mˇerˇ ení. Toto prumˇ ˚ erování je pˇred vývojáˇrem ukryto na nižších vrstvách a není možné nijak pˇristupovat k puvodním ˚ hodnotám [5]. Protože je ale síla signálu v bˇeženém prostˇredí silnˇe fluktující hodnota, pˇrístup k tˇemto puvodním ˚ hodnotám zachyceným Bluetooth modulem by stejnˇe pro reálné situace nebyl pˇrínosný. Hodnoty síly signálu se odeˇcítají s frekvencí 1 Hz a, jak se následnˇe pˇresvˇedcˇ íme, ani tak nedokáže mobilní zaˇrízení poskytnout stabilní a spolehlivé hodnoty. Kromˇe RSSI je možné pˇrímo vyˇcíst odhadovanou vzdálenost v metrech (angl. accuracy). Tato hodnota je poˇcítána ze síly signálu, ale Apple ve své dokumentaci upozornuje, ˇ že by se nemˇela používat pro stanovení pˇresné lokace beaconu. Je pochopitelné, že tato hodnota nemusí (a cˇ asto také není) odpovídající, ponˇevadž jde o pouhou interpretaci síly signálu zaˇrízením. Význam této hodnoty vyniká v situacích, kdy se v okolí nachází více beaconu˚ ve stejné vzdálenostní hladinˇe (angl. proximity, viz kapitola 2) a chceme urˇcit blíže položený beacon. Protože se však dnes již mnoho vývojáˇru˚ a spoleˇcností více cˇ i ménˇe úspˇešnˇe snaží iBeacon nasadit právˇe pro pˇresnou lokalizaci, bude v této kapitole problém podrobnˇe prozkoumán, budou popsány problémy, se kterými se lze pˇri takovém nasazení setkat, a také nastínˇena možná rˇ ešení.
1. Received Signal Strength Indication. Jednotka dBm.
21
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI
3.1 Síla signálu Jak bylo zmínˇeno v pˇredchozích kapitolách, každý beacon lze bˇežnˇe konfigurovat hodnotami vysílací síly signálu (angl. TX Power) a frekvencí vysílání. TX Power se udává v dBm a u Estimote beaconu˚ je nastavitelná od hodnoty −30 dBm do 4 dBm (u ostatních výrobcu˚ jsou hodnoty podobné). Vyšší hodnota udává vyšší výkon. S tím souvisí vˇetší dosah a, jak si v další cˇ ásti ukážeme, cˇ asto i vyšší pˇresnost, ale zárovenˇ se úmˇernˇe s ní zkracuje výdrž na baterie. Kromˇe toho se na beaconu konfigurují hodnoty UUID a cˇ ísla Major a Minor sloužící k identifikaci. Zajímavˇejší je ovšem další hodnota, která nemusí být ve všech pˇrípadech uživatelsky nastavitelná. Jedná se o tzv. Measured Power 2 , což je výrobcem spoˇcítaná hodnota síly pˇrijatého signálu ve vzdálenosti 1 metr od beaconu. Pro lepší pochopení tˇechto hodnot je ukázková situace ilustrována na obrázku 3.1. V levé cˇ ásti se nachází beacon, který vysílá se silou −4 dBm a frekvencí 1 Hz. Posílané zprávy obsahují hodnoty UUID, Major, Minor a Measured Power. Tyto hodnoty jsou pouze pˇreneseny a pˇreˇcteny na stranˇe smartphonu. Hodnotu RSSI telefonu poskytne jeho hardware. Z té se následnˇe se znalostí Measured Power spoˇcítá Accuracy a Proximity. Tento pˇrevod není žádným zpusobem ˚ zdokumentovaný ani v Apple dokumentaci, ani v jiných zdrojích a není tedy zcela jasné, jaký vzorec je použit nebo jaké další faktory hrají v tomto procesu roli [5]. Standardní vzorec[19] pro výpoˇcet RSSI je RSSI = −10n log10 d + MP, (3.1) kde n je konstanta útlumu signálu, d je vzdálenost od beaconu a MP je referenˇcní hodnota v dané vzdálenosti, v našem pˇrípadˇe Measured Power. Konstanta útlumu signálu je nejˇcastˇeji hodnota mezi 2 a 4, která se používá v závislosti na prostˇredí, ve kterém se mˇerˇ ení provádí. Po vyjádˇrení vzdálenosti dostaneme: d = 10
MP− RSSI 10n
(3.2)
Obecnˇe lze rˇ íci, že RSSI je velmi fluktující hodnota. Kromˇe po2. Ruzné ˚ zdroje nazývají tuto hodnotu ruznými ˚ pojmy. Napˇríklad [16] ji oznaˇcuje jako Calibrated Signal Strength. Programovˇe se jedná o osmi bitový znaménkový integer.
22
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI
Obrázek 3.1: Ukázková situace pˇrenášených a poˇcítaných hodnot s jedním beaconem a dvˇema smartphony.
mˇernˇe stabilních faktoru˚ jako je síla vysílaného signálu, citlivost pˇrijímaˇce nebo zisk antén na obou koncích systému, jsou mnohem huˇ ˚ re predikovatelné externí vlivy [24]. Z deseti ruzných ˚ beaconu˚ stejných výrobcu˚ tak lze získat pˇri testování deset ruzných ˚ hodnot. Záleží pˇri tom nejen na jejich umístˇení, ale i na denní dobˇe. Významnou roli zde hraje všudypˇrítomná elektromagnetická interference, na kterou je tato technologie velmi citlivá. Ruzná ˚ místa mohou mít ruznou ˚ intenzitu vyzaˇrování, stejnˇe tak v ruzných ˚ cˇ asech se muže ˚ lišit intenˇ zita. Cím dále se beacon nachází, tím více signálu˚ muže ˚ do pˇrenosu ˇ zasahovat a ovlivnovat ˇ jeho hodnotu. Cím blíže se beacon nachází, tím jsou výsledky vˇetšinou pˇresnˇejší. Kromˇe interference pak do hry pˇrichází i okolní pˇredmˇety, které mohou signál pohlcovat. Dokonce i lidské tˇelo pomˇernˇe významnˇe sílu signálu ovlivnuje. ˇ Stejnˇe tak natoˇcení telefonu a natoˇcení beaconu, tedy umístˇení antén. Míru interference a prostˇredí se snaží ve vzorci cˇ ásteˇcnˇe kompenzovat právˇe konstanta útlumu signálu. Jedná se ovšem o experimentálnˇe získanou konstantu mˇerˇ enou pro konkrétní prostˇredí, která se muže ˚ lišit v závislosti na aktuálních podmínkách. Ukázkový pˇrehled pro jednotlivá prostˇredí uvádí tabulka 3.1. Jelikož ruzné ˚ zdroje uvádí 23
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI
ruzné ˚ hodnoty, nelze brát tuto tabulku jako dogmatickou a celá situace názornˇe ilustruje komplikovanost mˇerˇ ení síly signálu. Konstanta Prostˇredí 2.0 Volný prostor 1.6 – 1.8 Uvnitˇr budovy, pˇrímá viditelnost Typická konferenˇcní místnost se stolem a židlemi 2.09 (15m × 7.6m) 2.2 Kamenná prodejna 2–3 Uvnitˇr továrny, bez pˇrímé viditelnosti 2.7 – 4.3 Typická kanceláˇrská budova, bez pˇrímé viditelnosti Tabulka 3.1: Pˇrehled konstant útlumu signálu pro jednotlivá prostˇredí (pˇrevzato z [10])
3.2 Praktická mˇerˇení V rámci praktických mˇerˇ ení se provádˇelo mnoho experimentu˚ v ruz˚ ných konfiguracích. Prostˇredí pro mˇerˇ ení se sestávalo z dlouhé pásky umístˇené na zemi se zakreslenými body urˇcujícími vzdálenosti. Konkrétnˇe se jednalo o vyznaˇcení pulmetrových ˚ úseku˚ od 0 do 3 metru˚ a dále metrové úseky až do vzdálenosti 9 metru. ˚ Pˇri mˇerˇ ení byl položen na zaˇcátek pásky telefon (iPhone 4S) a na znaˇcky byl umist’ován beacon postupnˇe v ruzných ˚ vzdálenostech a s ruznými ˚ parametry. Bˇehem každého mˇerˇ ení bylo uloženo celkem 60 vzorku˚ za 60 sekund. 3.2.1 Jaalee Prvním testovaným beaconem byl Jaalee Beacon:iB001-N. Jedná se o levnˇejší beacon, papírovˇe s prumˇ ˚ ernými hodnotami. Udávaný dosah výrobcem cˇ iní 25 metru. ˚ Provádˇela se 4 základní mˇerˇ ení s ruznými ˚ nastaveními. První mˇerˇ ení se provádˇelo s hodnotami zadanými výrobcem, konkrétnˇe se jednalo o vysílací výkon 0 dBm a periodou vysílání 1000 ms. Pˇri tomto nastavení pˇri mˇerˇ ení ve vzdálenosti 1,5 m a dále byla síla signálu témˇerˇ nemožná zjistit. Telefon sice beacon i 24
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI
pˇri 3 metrech rozpoznal, nedokázal však ani v jediném pˇrípadˇe urcˇ it RSSI a tedy ani vzdálenost. Poˇcet úspˇešných pokusu˚ mˇerˇ ení se nachází v grafu 3.2.
Úspěšná měření
60
59 49
45
38
30 15 0
0
0,5
1
3
1
0
0
1,5
2
2,5
3
Skutečná vzdálenost [m]
Obrázek 3.2: Poˇcet úspˇešných mˇerˇ ení beaconu Jaalee z celkových šedesáti pˇri periodˇe vysílání 1000 ms a vysílacím výkonu 0 dBm v závislosti na ruzných ˚ vzdálenostech. Dalo by se usoudit, že k cˇ astým výpadkum ˚ mohlo docházet kvuli ˚ nízké frekvenci beaconu, jelikož aplikace oznámení doruˇcuje právˇe v intervalech jedné sekundy. V každém cyklu je tedy nutné, aby telefon signál správnˇe pˇrijal a zpracoval, a pokud jej zrovna nezachytí nebo signál nedokáže správnˇe zpracovat, není již další šance výpadek napravit a aplikace ohlásí neznámou sílu signálu. Kvuli ˚ prozkoumání tohoto vlivu frekvence odesílání na síle signálu byla perioda snížena na minimálních 100 ms. Výsledky pˇri stejném výkonu 0 dBm se nachází na grafu 3.3. V tomto pˇrípadˇe se poˇcet úspˇešných pokusu˚ zvýšil a celkovˇe se zvýšila i vzdálenost, kde bylo ještˇe možné zachytit mˇerˇ itelnou odezvu. Nad vzdálenost 2 m je ale situace rovnˇež velmi špatná a telefon ve vˇetšinˇe pˇrípadu˚ nedokázal sílu signálu urˇcit. Dalo by se tedy konstatovat, že frekvence vysílání má urˇcitý vliv na poˇcet úspˇešných cˇ tení v závislosti na vzdálenosti, tento vliv však není pˇríliš významný. Pro další mˇerˇ ení byla zachována perioda 100 ms, avšak síla signálu byla zvýšena na 4 dBm, což je nejvyšší nastavení, kterého je Jaalee schopen. Celkovˇe se jedná o nejagresivnˇejší nastavení, kterého lze s tímto beaconem dosáhnout, a mˇelo by teoreticky poskytovat udá25
1
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI
Úspěšná měření
60
60
60 49
45
45
30
13
15
3 0
0
0,5
1
1,5
2
2,5
0 3
Skutečná vzdálenost [m]
Obrázek 3.3: Poˇcet úspˇešných mˇerˇ ení beaconu Jaalee z celkových šedesáti pˇri periodˇe vysílání 100 ms a vysílacím výkonu 0 dBm v závislosti na ruzných ˚ vzdálenostech.
vaný maximální dosah 25 metru. ˚ Jak se mužeme ˚ pˇresvˇedˇcit na grafu 3.4, poˇcty úspˇešných mˇerˇ ení byly ve všech vzdálenostech témˇerˇ stoprocentní. Velkou nevýhodou tohoto nastavení je však nízká výdrž na baterie. Nejsou známé konkrétní údaje pro tento typ beaconu a praktická mˇerˇ ení výdrže by byla nad rámec této DP. Podle mˇerˇ ení jiných výrobcu˚ lze rˇ íci, že má frekvence zásadní vliv na výdrž. Od pouhých nˇekolika málo mˇesícu˚ pˇri 100 ms lze zvýšením periody na 1000 ms zvýšit výdrž na baterie 8 až 10 krát [3]. Vliv síly signálu není také zanedbatelný, ale pro zachování použitelnosti pro vyšší vzdálenosti byla hodnota zachována a pouze perioda byla prodloužena na 500 ms. Pro všechny mˇerˇ ené vzdálenosti zustal ˚ poˇcet úspˇešných pokusu˚ témˇerˇ stoprocentní, pouze s náhodnými výpadky, podobnˇe jako na grafu 3.4. Toto nastavení bylo tedy zvoleno jako optimální pro další mˇerˇ ení (dále jako „optimální nastavení“). Jak bylo zmínˇeno v pˇredchozí sekci 3.1, je možné mˇerˇ it pouhou hodnotu RSSI nebo lze nechat na telefonu, aby nám hodnotu interpretoval jako vzdálenost v metrech. Pro správnou funkci je však nutné mít na beaconu korektnˇe nastavenou hodnotu Measured Power. V pˇrípadˇe Jaalee jsou beacony dodávány s pˇrednastavenou hodnotu −53 dBm, což však neodpovídalo experimentálnˇe získaným hodnotám síly signálu pˇri vzdálenosti telefonu 1 metr od beaconu, a aplikace hlásila zcela nepˇresné vzdálenosti. Pˇri optimálním nastavení 26 1
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI
Úspěšná měření
60
59
60
60
60
58
59
58
0
0,5
1
1,5
2
2,5
3
45 30 15 0
Skutečná vzdálenost [m]
Obrázek 3.4: Poˇcet úspˇešných mˇerˇ ení beaconu Jaalee z celkových šedesáti pˇri periodˇe vysílání 1000 ms a vysílacím výkonu 4 dBm v závislosti na ruzných ˚ vzdálenostech.
byla zjištˇena prumˇ ˚ erná hodnota −78 dBm (dle prostˇredí tady hodnota kolísala od −70 dBm až po −83 dBm). Po nastavení snížené hodnoty −78 dBm byly udávané hodnoty vzdálenosti mnohem blíže realitˇe, avšak stále výsledky mezi jednotlivými mˇerˇ eními kolísaly v rˇ ádech nˇekolika metru. ˚ S optimálními hodnotami se provedlo další rozsáhlejší mˇerˇ ení, kde se kromˇe síly signálu zaznamenávaly taky údaje o odhadované vzdálenosti z oficiálního API. Mˇerˇ ilo se celkem 10 stanovišt’ ve vzdálenostech od 0 do 9 metru˚ po jednom metru. V každém mˇerˇ ení bylo zaznamenáno celkem 60 vzorku, ˚ z nichž se vypoˇcítal prumˇ ˚ er a byly pˇritom zanedbány nulové hodnoty. Celkem se provedly dvˇe série mˇerˇ ení, jejíž výsledky jsou zaznamenány na grafech 3.5 a 3.6. První graf ukazuje závislost skuteˇcné vzdálenosti v metrech na odhadované vzdálenosti, taktéž v metrech. Lze vidˇet, že výsledky odpovídají realitˇe spíše cˇ ásteˇcnˇe a spíše v bližších vzdálenostech do tˇrí metru. ˚ Je zajímavé si všimnout napˇríklad deviace u druhého mˇerˇ ení pˇri vzdálenosti 4 metry, kdy byla prumˇ ˚ erná namˇerˇ ená vzdálenost 7,7 m. Dále u vzdáleností 6 metru˚ a výše je znatelný skok, kdy se namˇerˇ ené hodnoty liší od skuteˇcných o témˇerˇ dvojnásobky. Kromˇe toho je u druhého mˇerˇ ení pˇri osmi metrech prumˇ ˚ erná hodnota vypoˇcítávána z pouhého jednoho úspˇešného vzorku z šedesáti. Zajímavé pak je, že u tohoto druhého mˇerˇ ení je ve vzdálenosti 9 metru, ˚ tedy metr dále, 27
1
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI
úspˇešných výsledku˚ rovná polovina. 1. m ení
2. m ení
16
M ená vzdálenost [m]
14 12 10 8 6 4 2 0
0
1
2
3
4
5
6
7
8
9
Skute ná vzdálenost [m]
Obrázek 3.5: Závislost skuteˇcné vzdálenosti beaconu Jaalee v metrech na mˇerˇ ené vzdálenosti na mobilním telefonu, taktéž v metrech, pro dvˇe série mˇerˇ ení za stejných podmínek. U druhého grafu 3.6 je vykreslena skuteˇcná vzdálenost v metrech v závislosti na nezpracovaných hodnotách síly signálu RSSI v dBm, pro snazší orientaci pouze otoˇcené znaménkem mínus do kladných hodnot. Z tohoto grafu, spoleˇcnˇe s poznatky z pˇredchozího, lze usoudit, že jedním z problému nepˇresného mˇerˇ ení vzdálenosti (kromˇe již zminovaných ˇ omezení samotné technologie) by mohla být hodnota Measured Power experimentálnˇe získaná pˇri mˇerˇ ení ve vzdálenosti jednoho metru. I když není stupnice RSSI lineární, je tato hodnota pomˇernˇe vysoká, a jelikož iPhone rozpoznává nejnižší hodnotu -99 dBm, zustává ˚ pomˇernˇe málo prostoru pro pˇresnˇejší urˇcení vzdálenosti v metrech na pouhých pˇribližnˇe 21 jednotkách dBm (od -78 dBm, hodnota u vzdálenosti 1 metru, do -99 dBm, nejnižší možná hodnota). Beacon Jaalee muže ˚ být jednoduše nedostateˇcnˇe výkonný i pˇri nejsilnˇejším nastavení, aˇckoliv výrobce uvádí dosah 25 metru. ˚ Takového dosahu nelze pˇri nastavení -78 dBm Measured Power dosáhnout. Pokud si totiž dosadíme do vzorce 3.2 hodnoty Measured 28
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI 1. m ení
2. m ení
100 90
– RSSI [dBm]
80 70 60 50 40 30 20 10 0
0
1
2
3
4
5
6
7
8
9
Skute ná zdálenost [m]
Obrázek 3.6: Závislost skuteˇcné vzdálenosti beaconu Jaalee v metrech na obrácené síle signálu v dBm pro dvˇe série mˇerˇ ení za stejných podmínek.
Power, nejnižší možnou hodnotu poskytovanou API -99 dBm a nejnižší možnou hodnotu útlumu 1.6 podle tabulky 3.1, stále dostáváme pouze 20,53 m: d = 10
MP− RSSI 10n
= 10
−78−(−99) 10×1,6
= 20, 53
Není ovšem známo, zda je v API pro výpoˇcet použit takový nebo podobný vzorec, a na jakých dalších mˇerˇ eních závisí výsledná hodnota vzdálenosti. Jelikož i pˇri stejných hodnotách RSSI dodává API cˇ asto ruzné ˚ hodnoty vzdálenosti, lze odhadovat, že se pro její urcˇ ování používají ještˇe další parametry. V první rˇ adˇe by pˇricházely v úvahu senzory typu gyroskop nebo akcelerometr (pohybový senzor nacházející se v modernˇejších telefonech není v modelu iPhone 4S pˇrítomen), ovšem v prubˇ ˚ ehu experimentu˚ leželo mobilní zaˇrízení (i beacon) bez pohybu na zemi. Dále by mohla hrát roli nˇekterá z metod vyhlazování signálu, kdy telefon pˇreˇcte urˇcitý poˇcet po sobˇe jdoucích hodnot a pokud se od sebe zásadnˇe liší, provede se vy29
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI
hlazení signálu v závislosti na minulých hodnotách. Reálnˇe je totiž možný pouze omezený pohyb telefonu a nemuže ˚ se stát (s výjimkou obskurních pˇrípadu), ˚ že by byl telefon 2 m od beaconu a za sekundu by se nacházel ve vzdálenosti 10 metru. ˚ Hodnota RSSI dodávaná API tedy nemusí být nezpracovaná hodnota, ale již zpracovaná. Jedná se ovšem pouze o spekulaci a zamyšlení, jelikož dokumentace k pu˚ vodu tˇechto hodnot je nejasná a neúplná. V tomto pˇrípadˇe není tato situace specifikem Apple dokumentace. Podobnˇe nejasná je dokumentace pro Android. 3.2.2 Estimote Druhým testovaným beaconem byl Estimote. Oba zakladatelé této spoleˇcnosti jsou puvodem ˚ z Polska. Nyní však pusobí ˚ po celém svˇetˇe, s poboˇckami v New Yorku, San Franciscu a Krakovˇe, a v oblasti iBeacon technologií se jedná o pˇredního výrobce. Mˇerˇ ení probíhala stejnˇe jako u beaconu Jaalee. Nejprve se tedy zkoumal vliv nastavení periody vysílání a síly signálu na poˇcet úspˇešných mˇerˇ ení. V této disciplínˇe si Estimote vedl rˇ ádovˇe lépe než Jaalee, u nˇehož bylo pˇri vzdálenostech vˇetších jak 1,5 m témˇerˇ nemožné zmˇerˇ it sílu signálu. Estimote ani s nejdelší periodou (1000 ms) a s nejslabším testovaným vysílacím výkonem (0 dBm) neprojevil výraznˇejší pˇri žádné ze vzdáleností mezi 0 a 3 metry výraznˇejší propad. Výsledek lze vidˇet na grafu 3.7. Pro všechny vzdálenosti je prumˇ ˚ er necelých 56 z 60 mˇerˇ ení. U tohoto modelu není tedy nutné prezentovat další grafy poˇctu úspˇešných mˇerˇ ení, protože se zvyšováním frekvence a zvýšením výkonu na 4 dBm se neúspˇešná cˇ tení ve vzdálenostech do 3 metru˚ v podstatˇe nevyskytovala. Pro konzistenci prezentovaných výsledku˚ byla i pro Estimote beacon zvolena optimální konfigurace vysílacího výkonu 4 dBm a periody 500 ms. Podobnˇe jako u Jaalee se dají oba parametry volitelnˇe konfigurovat, pro vysílací výkon v rozmezí −30 dBm až 4 dBm, pro periodu od hodnoty 50 ms. Zde je vhodné upozornit na opravdu významný vliv vysílacího intervalu, kdy byly dva zkušební Estimote beacony osazeny novými bateriemi knoflíkového typu CR2450 se 620 mAh. Beacony byly cca 2 týdny provozovány pˇri nejvyšším vysílacím výkonu a nejkratším intervalu 50 ms. Po této dobˇe hlásil hardware obou beaconu˚ zbývající kapacitu baterie kolem 50%. Aˇckoliv se 30
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI
Úspěšná měření
60
60
60
52
58 48
54
58
45 30 15 0
0
0,5
1
1,5
2
2,5
3
Skutečná vzdálenost [m]
Obrázek 3.7: Poˇcet úspˇešných mˇerˇ ení beaconu Estimote z celkových šedesáti pˇri periodˇe vysílání 1000 ms a vysílacím výkonu 0 dBm v závislosti na ruzných ˚ vzdálenostech.
jednalo o pˇredprodukˇcní vývojáˇrskou verzi tohoto zaˇrízení a ve finálním produktu nebo v novˇejší generaci muže ˚ být správa napájení rˇ ešena lépe, stále je nutné pˇri reálném nasazení iBeacon technologie tento fakt zohlednovat. ˇ Estimote, na rozdíl od Jaalee, neumožnuje ˇ uživatelsky nastavovat hodnotu Measured Power, která je kalibrovaná z výroby a pouze pro cˇ tení [20]. U testovaných modelu˚ se jednalo o −60 dBm. Bohužel pˇri mˇerˇ ení s mobilním telefonem iPhone 4S hodnota neodpovídala experimentálnˇe namˇerˇ ené síle signálu ve vzdálenosti 1 metr a tudíž odhadované vzdálenosti byly zcela nepˇresné. Graf 3.8 je zde pro ukázku nekorelace s výsledky mˇerˇ ení Jaalee beaconu a pro názornost, jak vskutku duležitým ˚ parametrem pˇri prácí s iBeacony je tato v mnoha odborných cˇ láncích pˇrehlížená hodnota. Lze vidˇet, že hodnoty ani v jednom mˇerˇ ení nereflektují realitu a výsledné vzdálenosti tak nelze použít ani jako orientaˇcní. Více vypovídající je pak graf 3.9, který urˇcuje sílu signálu v závislosti na vzdálenosti pro dvˇe nezávislá mˇerˇ ení. V celém prubˇ ˚ ehu je síla signálu u Estimote beaconu rámcovˇe o rˇ ád vyšší (rozdíl cca 10 dBm). Tento výsledek není pˇrekvapivý, jelikož Jaalee beacon garantuje dosah 25 metru, ˚ kdežto u Estimote beaconu je udávaný dosah až 70 metru˚ a tudíž se tyto rozdílnosti musí zákonitˇe projevit i v síle signálu. Kromˇe vlivu vzdálenosti bez okolních rušivých jevu, ˚ který zde byl v pˇrední rˇ adˇe testován, je vhodné upozornit na další vlivy, které 1
31
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI 1. m ení
2. m ení
50
M ená vzdálenost [m]
43.75 37.5 31.25 25 18.75 12.5 6.25 0
0
1
2
3
4
5
6
7
8
9
Skute ná vzdálenost [m]
Obrázek 3.8: Závislost skuteˇcné vzdálenosti beaconu Estimote v metrech na mˇerˇ ené vzdálenosti na mobilním telefonu, taktéž v metrech, pro dvˇe série mˇerˇ ení za stejných podmínek.
mohou mˇerˇ ení ovlivnit. Muže ˚ se jednat o nˇeco tak pˇrirozeného jako lidé chodící okolo vysílaˇce nebo pˇrijímaˇce. Lidské tˇelo je totiž složeno kolem 60% z vody a rádiové vlny jsou vodou velmi dobˇre pohlcovány. Stejnˇe tak, ne-li ještˇe lépe, dokážou vlny pohltit ruzné ˚ kovové materiály. Ponˇevadž je Bluetooth anténa pouze miniaturní oblast v jedné cˇ ásti zaˇrízení, svou roli pˇri cˇ tení signálu hraje také vzájemné natoˇcení vysílaˇce a pˇrijímaˇce. Ruzné ˚ konstrukce a citlivosti antén pak dávají ruzné ˚ výsledky. To se týká nejen beaconu˚ rozdílných výrobcu, ˚ ale také znaˇcek mobilních zaˇrízení. iPhone 4S tedy nemusí pˇrijímat signál se stejnou citlivostí jako Samsung Galaxy SIII a podobnˇe.
3.3 Vyhlazování signálu Jak již bylo zmínˇeno v pˇredchozí kapitole, signál muže ˚ v cˇ ase pomˇernˇe výraznˇe fluktuovat, a to i pokud jsou beacon a mobilní zarˇ ízení stacionární. Znázornˇení této fluktuace je zobrazeno na grafu 3.10. Jedná se o porovnání cˇ tených hodnot obrácené síly signálu RSSI 32
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI 1. m ení
2. m ení
100 90
– RSSI [dBm]
80 70 60 50 40 30 20 10 0
0
1
2
3
4
5
6
7
8
9
Skute ná zdálenost [m]
Obrázek 3.9: Závislost skuteˇcné vzdálenosti beaconu Estimote v metrech na obrácené síle signálu v dBm pro dvˇe série mˇerˇ ení za stejných podmínek.
z prvního mˇerˇ ení Jaalee beaconu pˇri vzdálenostech jednoho a tˇrí metru. ˚ Z celkových šedesáti sekund se beacon vzdálený tˇri metry hlásil jako blíže položený než beacon vzdálený metr po souhrnnou dobu sedmi sekund. Pˇrerušená místa v grafu oznaˇcují chybˇející hodnoty, tedy cˇ asy, ve kterých mˇerˇ ení nevrátilo hodnotu. Zpusob ˚ u˚ jak takový signál vyhladit je celá rˇ ada. Jedním z nejjednodušších rˇ ešení je použití klouzavého prumˇ ˚ eru (angl. moving average nebo rolling average). Jedná se o statistickou metodu, kdy z puvodní ˚ série vzorku˚ vznikají nové hodnoty jako prumˇ ˚ er nˇekolika po sobˇe jdoucích vzorku. ˚ Poˇcet vzorku, ˚ které se vezmou v potaz pro vytvoˇrení prumˇ ˚ eru se muže ˚ lišit dle daného vzorkování a výsledku, který od tohoto zpracování požadujeme. Více vzorku˚ vede na jednu stranu k hladšímu výslednému signálu, na druhou stranu zpusobuje ˚ u real-time aplikací, jakým indoor navigace bezesporu je, zpožd’ování pˇri skuteˇcných zmˇenách vzdáleností mezi zaˇrízeními. Pokud dojde k nárustu vzdálenosti, hodnota RSSI zaˇcne klesat. Pˇri aplikaci klouzavého prumˇ ˚ eru se však tato zmˇena díky prumˇ ˚ erování 33
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI 1 metr
3 metry
100
– RSSI [dBm]
90
80
70
58
55
52
49
46
43
40
37
34
31
28
25
22
19
16
13
7
10
4
1
60
Čas [s]
Obrázek 3.10: Porovnání fluktuace obrácené síly signálu RSSI (dBm) v cˇ ase pro beacon Jaalee ve vzdálenosti jednoho a tˇrí metru. ˚
s pˇredchozími hodnotami projeví až po nˇekolika sekundách, podle ˇ velikosti zmˇeny a poˇctu vzorku˚ k prumˇ ˚ erování. Cím více vzorku, ˚ tím déle trvá, než se zmˇena projeví. Pro lepší znázornˇení výsledku˚ této filtrace je zobrazen graf 3.11 s aplikací klouzavého prumˇ ˚ eru s hodnotou 5 sekund. Místo sedmi sekund, kdy se vzdálenˇejší beacon hlásil jako bližší, se doba zkrátila na tˇri sekundy. Vylepšení tedy teoreticky pˇresáhlo 50%, ovšem za cenu pomˇernˇe výrazného zpožd’ování. Pro eliminaci zpožd’ování lze využít modifikované metody klouzavého prumˇ ˚ eru, a to vážený klouzavý prumˇ ˚ er (angl. weighted moving average). U této metody se novˇejší výsledky zohlednují ˇ s vyšší vahou a pro dynamický systém beaconu, ˚ kdy se v reálném prostˇredí zaˇrízení pohybují, je tato metoda vhodnˇejší a vˇetšinou pˇresnˇejší. iBeacon není jediná technologie, která ve svém procesu operace poskytuje nespolehlivé výsledky. Napˇríklad i u GPS se jednotlivé vzorky mohou velice významnˇe lišit a nemuže ˚ se každému vzorku pˇrikládat stoprocentnˇe pravdivá váha. V takových situacích nastupují další vyhlazovací techniky. U GPS se cˇ asto jedná o Kalmanuv ˚ filtr, který byl poprvé popsán na pˇrelomu 50. a 60. let 20. století. Jedná se o komplexní matematický aparát, který pro sérii mˇerˇ ení za 1
34
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI 1 metr
3 metry
100
– RSSI [dBm]
90
80
70
58
55
49
52
46
43
40
37
34
31
28
25
22
19
13
16
7
10
4
1
60
as [s]
Obrázek 3.11: Porovnání fluktuace obrácené síly signálu RSSI (dBm) v cˇ ase pro beacon Jaalee ve vzdálenosti jednoho a tˇrí metru˚ s aplikací klouzavého prumˇ ˚ eru o hodnotˇe pˇeti sekund.
urˇcitý cˇ as a obsahující nepˇresné hodnoty (šum) dokáže vypoˇcítat odhad neznámých. Tento odhad je pochopitelnˇe pˇresnˇejší než pokud by se vzala v potaz jednotlivá mˇerˇ ení. Kalmanuv ˚ filtr se cˇ asto používá u navigace dopravních prostˇredku, ˚ vˇetšinou letadel nebo vesmírných raket, ale jeho uplatnˇení je velmi obecné [14]. Pokud se vrátíme zpˇet k mˇerˇ ení signálu a provedeme stejný experiment s Estimote beaconem, zjistíme, že je výsledek zcela odlišný, jak je vidˇet na grafu 3.12. Pro jeden metr se fluktuace pohybuje pouze v rozmezí −68 dBm až −71 dBm, tedy 3 dBm. U Jaalee beaconu se jednalo o 19 dBm. Pro tˇri metry je pak rozmezí vytyˇceno hodnotami −75 dBm a −84 dBm, tedy 9 dBm. U Jalee beaconu cˇ inil rozdíl pro stejnou vzdálenost 16 dBm. Kromˇe fenoménu celkovˇe silnˇejšího signálu zmínˇeného již v pˇredchozí sekci, je tedy signál daleko stabilnˇejší, pˇredevším ve vzdálenosti jednoho metru, a dokonce se zde nevyskytla ani žádná místa, kde by došlo k pˇrekˇrížení hodnot. Ze všech mˇerˇ ení je tedy zˇrejmé, že pro interní urˇcení vzdálenosti je podstatná správnˇe zkalibrovaná hodnota Measured Power, ale také, že záleží na kvalitˇe zpracování iBeacon hardwaru. Posuzování konkrétního vlivu kvality jednotlivých komponent je nad rámec této DP, 35
ˇ 3. I B EACON A UR COVÁNÍ VZDÁLENOSTI 1 metr
3 metry
100
– RSSI [dBm]
90
80
70
58
55
52
49
46
43
40
37
34
31
28
25
22
19
16
13
7
10
4
1
60
Čas [s]
Obrázek 3.12: Porovnání fluktuace obrácené síly signálu RSSI (dBm) v cˇ ase pro beacon Estimote ve vzdálenosti jednoho a tˇrí metru. ˚
avšak muže ˚ se jednat pˇredevším o konstrukci a typ antény. Pˇri nasazení technologie v produkˇcním prostˇredí je vhodné si pˇred nákupem velkého množství beaconu˚ zajistit vzorek tohoto hardwaru a vyzkoušet nˇekterá z mˇerˇ ení, pˇredevším test stability síly signálu.
1
36
Kapitola 4
Implementace ukázkového systému Na základˇe vlastností a omezení technologie iBeacon byl navržen a implementován systém využívající iOS aplikaci a serverovou cˇ ást, se kterou aplikace komunikuje. Celý systém je složen z nˇekolika vzájemnˇe spolupracujících cˇ ástí. iOS aplikace je napsána ve Swiftu, pomˇernˇe mladém jazyce vytvoˇreném spoleˇcností Apple, veˇrejnˇe pˇredstaveném v záˇrí 2014. Postupem cˇ asu by mˇel tento jazyk vytlaˇcit zatím masivnˇeji používaný Objective-C, kterému však v posledních letech zaˇcínají chybˇet nˇekteré duležité ˚ vlastnosti a bˇehem rozšiˇrování se stal pomˇernˇe tˇežkopádný s ohledem na pˇríliš kvˇetnatou syntaxi. Bˇehem vývoje byl používán Swift verze 1.1, v závˇereˇcné fázi pak byl kód upraven pro plnou podporu verze 1.2 vydanou v dubnu 2015. S ohledem na hardwarové požadavky je iOS aplikace optimalizovaná jak pro iPhone (verze 4S nebo novˇejší), tak pro iPad 2 a novˇejší. Pro bˇeh je nutný operaˇcní systém iOS verze 8.0 nebo novˇejší. Aplikace je rozdˇelena na 3 základní sekce, mezi kterými je možné se jednoduše pˇrepínat pomocí záložek. První záložka nazvaná Map tvoˇrí základní modul, kde je možné si vizualizovat zaznamenaná nebo real-time beacon data. Druhou záložku Data tvoˇrí jednoduchý tabulkový pohled, kde si lze všechny záznamy prohlížet a provádˇet jednoduché filtrace dle uživatele, který signál beaconu zachytil, nebo dle jednotlivých beaconu. ˚ Poslední záložkou Status je kolekce informaˇcních a diagnostických údaju˚ vˇcetnˇe jednoduchého nastavení. Ukázka základních obrazovek jednotlivých záložek se nachází na obrázku 4.1. Serverová cˇ ást vˇcetnˇe prezentaˇcního i API serveru je napsána v PHP ve frameworku Nette. Data jsou ukládána v MySQL databázovém systému. Kromˇe toho je pro prezentaˇcní vrstvu využíván HTML 5, CSS 3 a JavaScript s vícero knihovnami, z nichž nejduležitˇ ˚ ejší je 37
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU
Obrázek 4.1: Pˇrehled základních obrazovek jednotlivých záložek aplikace. Vlevo záložka Map, uprostˇred záložka Data a na posledním místˇe záložka Status.
D3.js, framework pro vizuální prezentaci dat, který je v této diplomové práci použit pro real-time a historické zobrazení beacon dat. Všechny cˇ ásti budou podrobnˇeji z implementaˇcního hlediska popsány v následujících kapitolách. Nejprve je však nutné popsat základní strukturu systému s ohledem na výmˇenu dat a funkce provádˇené jednotlivými cˇ ástmi. Stˇežejní cˇ ástí systému a vstupním bodem pro data pˇricházející do systému je iOS aplikace. Její základní funkcí je monitorování okolních beaconu˚ a ukládání dat do lokální databáze. Po spuštˇení se pokouší navázat kontakt s API serverem. V pˇrípadˇe úspˇechu server vygeneruje major a minor cˇ íslo jedineˇcné v rámci systému a vrátí je spolu s odpovˇedí. V pˇrípadˇe, že se tato autorizace podaˇrí, muže ˚ aplikace kromˇe monitorování zaˇcít sama beacon data vysílat. Kromˇe komunikace se serverem se aplikace snaží navázat kontakt také s ostatními uživateli v okolí. Pokud dojde ke spojení, obˇe zúˇcastnˇené strany si vymˇení chybˇející záznamy a doplní jimi vlastní lokální databázi pro pozdˇejší rekonstrukci co možná nejpˇresnˇejšího pohledu na beacony a uživatele v systému vˇcetnˇe vzdálenostních vztahu˚ mezi nimi. Pro jasnˇejší popis systému je ukázková situace se dvˇema uživateli, jedním beaconem a API serverem zobrazena na obrázku 4.2. 38
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU Uživatelé 1 i 2 jsou v dosahu iBeaconu a do své lokální databáze si zaznamenávají získané informace. Na rozdíl od uživatele 1 má uživatel cˇ íslo 2 možnost komunikace s API serverem. API server jej tedy autorizuje a odešle mu major a minor cˇ ísla, v našem pˇrípadˇe 65535 a 65534. V tento moment muže ˚ uživatel 2 aktivovat vysílání beacon zpráv a stává se tedy dalším, byt’ virtuálním beaconem, jehož signál muže ˚ zachytit uživatel 1. Uživatel 2 dále v pravidelných intervalech odesílá získané záznamy z fyzického beaconu (2, 1). Uživatel 1 v našem hypotetickém pˇríkladˇe spojením se serverem nedisponuje, avšak je možné navázat spojení s uživatelem 2, po kterém dojde k výmˇenˇe chybˇejících záznamu. ˚ Uživatel 2 odesílá uživateli 1 záznamy získané z beaconu (2, 1). Opaˇcným smˇerem posílá uživatel 1 záznamy jednak z beaconu (2, 1), tak z virtuálního beaconu (65535, 65534). Mohlo by se zdát, že záznamy z virtuálního beaconu posílá uživatel 1 zpˇet ke zdroji a tedy tento pˇrenos není nutný. Bez tˇechto pˇrenesených záznamu˚ by však uživatel 2 nemˇel žádné povˇedomí o vzdálenosti mezi ním a svou vlastní polohou. Aˇckoliv tedy uživatel 1 sám beacon signál nevysílá, zpˇetnˇe je možné tento vztah zrekonstruovat právˇe výmˇenou dat mezi uživateli.
4.1 iOS aplikace Jak již bylo rˇ eˇceno, iOS aplikace je stˇežejní cˇ ástí celého systému. Stejnˇe jako je každý beacon identifikován svým UUID, tak i každá instance aplikace po svém spuštˇení vygeneruje jedineˇcný identifikátor UUID. Tato jedineˇcná identifikace je nutná kvuli ˚ spárování uživatele s major a minor cˇ ísly na stranˇe serveru. Obecnˇe je pˇrípustné, aby v rámci jednoho systému mˇelo vícero zaˇrízení shodná major a minor cˇ ísla. S ohledem na využití pˇri lokalizaci jedineˇcných subjektu˚ systému je však vhodné se takové situaci vyhnout. V decentralizovaném systému, kde se jednotliví uživatelé dynamicky pˇripojují a odpojují, a kde o sobˇe nemusí mít povˇedomí, by bylo obecnˇe obtížné generovat jedineˇcné identifikátory. Server, jakožto centrální jednotka, má však o všech tˇechto uživatelích pˇrehled a uchovává si záznamy o již pˇridˇelených cˇ íslech. Fyzické beacony jsou v systému cˇ íslovány v rámci konvence od (1, 1) a postupují smˇerem nahoru. Pˇridˇelované identifikátory zaˇcínají naopak na (65535, 65535) a postupují dolu. ˚ Po39
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU komunikace s API serverem výměna záznamů mezi zařízeními
1
Záznamy z beaconu (2,1) a (65535, 65534)
Beacon (65535, 65534)
iBeacon signál
Záznamy z beaconu (2,1)
2
Beacon (2,1)
Autorizace (65535, 65534)
Záznamy z beaconu (2,1)
Obrázek 4.2: Ukázková situace výmˇeny dat mezi beaconem, API serverem a dvˇema uživateli v systému, kteˇrí si mohou navzájem vymˇenovat ˇ data, ale z nichž pouze jeden má spojení se serverem.
kud server obdrží autorizaˇcní požadavek, nejprve zkontroluje, zda tento uživatel v systému existuje. Pokud ano, vrátí mu již pˇridˇelená cˇ ísla. Pokud ne, provede se kontrola nejvyšší volné kombinace obou cˇ ísel a identifikátor se spáruje s UUID uživatele. Souˇcasnˇe se odpovˇed’ vrátí uživateli a ten muže ˚ zaˇcít vysílat bez rizika kolizí. Samotný UUID si generuje sama aplikace ihned po spuštˇení z duvodu ˚ nutnosti identifikace pˇri komunikaci s ostatními uživateli. Ponˇevadž je UUID identifikátoru˚ pˇres 3.4 × 1038 , kolize je velmi nepravdˇepodobná. UUID identifikátor se po prvním spuštˇení uložení do nastavení aplikace a uživatel je tedy jedineˇcnˇe identifikovaný i mezi jednotlivými spuštˇeními aplikace. Pokud však dojde ke smazání a opˇetovnému nainstalování aplikace, vygeneruje se nové UUID a z pohledu serveru i ostatních zaˇrízení se bude jednat o nového uživatele. Ihned po spuštˇení aplikace zaˇcíná monitorování okolních beaconu. ˚ Vzorkování a tedy získávání informací o okolních beaconech je frameworkem CoreLocation, zajišt’ujícím mimo jiné navigaˇcní služby a služby spojené právˇe s technologií iBeacon, nastaveno pevnˇe na 40
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU jednu sekundu. Záznamy jsou ukládány do lokálního perzistentního úložištˇe nazvaného CoreData. Jedná se o standardní Apple framework, který si lze v urˇcitých ohledech pˇredstavit jako databázový systém. Data jsou modelována jako vzájemnˇe propojené entity s cˇ etnostmi obsahující atributy ruzných ˚ datových typu. ˚ A aˇckoliv na fyzické úrovni jsou data skuteˇcnˇe do databáze ukládány (SQLite), o databázový systém se nejedná. CoreData je speciálnˇe navržen pro spolupráci s aplikacemi založenými na architektuˇre MVC (Model-ViewController) a ve své podstatˇe nepracuje se záznamy relace, avšak s objekty (tzv. managed objects). Ponˇevadž je však strukturu možné modelovat pomocí entit a atributu, ˚ na obrázku 4.3 se nachází model využívaný v aplikaci, do nˇejž jsou ukládány veškeré informace získané od okolních beaconu˚ a uživatelu. ˚
Obrázek 4.3: Model perzistentního úložištˇe dat CoreData využívaný pro ukládání beacon dat.
Entita User pˇredstavuje uživatele (resp. zaˇrízení) v systému. uuid je jedineˇcný identifikátor popsaný výše a name je cˇ itelný název zaˇrízení získávaný z operaˇcního systému (napˇr. Adam’s iPhone). Entita Beacon pˇredstavuje beacon v systému identifikovaný svými cˇ ísly major a minor. Spojení mezi entitami User a Beacon typu one-to-one je volitelné a existuje kvuli ˚ možné figuraci zaˇrízení jako virtuálního beaconu. Relace je nutná právˇe kvuli ˚ spárování zaˇrízení s vysílanými beacon identifikátory. Poslední entitou je Stats. Ukládají se zde informace o jednotlivých mˇerˇ eních, a to konkrétnˇe accuracy, tedy odhadovaná vzdálenost v metrech, proximity, tedy hladina vzdálenosti (Immediate, Near, Far, 41
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU Unknown), rssi, jakožto síla signálu v dBm a datetime, což je datum a cˇ as daného mˇerˇ ení. Kromˇe toho se ukládá datum a cˇ as vytvoˇrení záznamu (created) a pravdivostní hodnota indikující stav synchronizace daného záznamu se serverem (synced). Relace s entitami User a Beacon jsou ve vztahu one-to-many smˇerem ke Stats. V samotném procesu ukládání je použit efektivní mechanismus pro optimalizaci množství záznamu˚ v úložišti. Kvuli ˚ vysoké nepˇresnosti jednotlivých vzorku˚ se pro uložení aktuálního záznamu musí lišit jeho hodnota proximity od naposledy uložené nebo se musí hodnota accuracy lišit o více než 0,5 m. Dále se neukládají opakované záznamy obsahující proximity s hodnotnou Unknown, které znamenají, že se beacon nachází v systému, ale není mezi ním a zaˇrízením znám vzdálenostní vztah. Pˇri vizualizaci je uvažován dvacetisekundový limit pro expiraci beaconu. Tedy pokud se v úložišti po dobu vˇetší jak 20 sekund do minulosti nenachází žádný záznam k danému beaconu, je situace vyhodnocena jako stav, kdy beacon opustil systém. Z toho duvodu ˚ se pˇri chybˇejících záznamech s mˇerˇ itelnou vzdáleností uloží záznam s proximity Unknown nejpozdˇeji každých 20 sekund, což potvrzuje jeho pˇrítomnost v systému. 4.1.1 MultipeerConnectivity Komunikace s okolními uživateli je realizována pomocí frameworku MultipeerConnectivity, standardního Apple frameworku uvedeného s iOS 7, který zajišt’uje komunikaci pomocí lokální Wi-Fi sítˇe, peer-to-peer Wi-Fi pˇripojení nebo pomocí Bluetooth. Jedná se o vysokoúrovnový ˇ framework a vývojáˇrum ˚ nedovoluje zasahovat do mechanismu˚ samotného propojení. Není možné napˇríklad zjistit, který ze tˇrí zpusob ˚ u˚ pˇripojení se v dané chvíli používá, protože je zvoleno vnitˇrní logikou frameworku na základˇe optimálnosti a dostupnosti dané technologie. Avšak pro nasazení v aplikacích, kde samotný mechanismus pˇripojení není pˇríliš duležitý ˚ a pˇrednost je vˇenována spíše vysoké dostupnosti tohoto pˇripojení, je MultipeerConnectivity velmi vhodný. Dokáže mezi sebou totiž propojit uživatele, kteˇrí by se sebou za normálních okolností nebyli schopní komunikovat, a to skrze tˇretího uživatele. Vzorovým pˇríkladem muže ˚ být situace na obrázku 4.4, tedy uživatel 1, který disponuje pouze Wi-Fi pˇripojením, uživatel 2 disponující Wi-Fi i Bluetooth pˇripojením a uživatel 3 disponující 42
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU pouze Bluetooth. S MultipeerConnectivity je možná „pˇrímá“ komunikace mezi uživatelem 1 a 3, kdy si mohou navzájem vymˇenovat ˇ data, avšak fyzicky se tato data pˇreposílají pˇres druhého uživatele, který z jedné strany komunikuje pomocí Wi-Fi a z druhé strany pomocí Bluetooth. V souˇcasné dobˇe je komunikace omezena frameworkem na 8 zaˇrízení, což by pro rozsáhlejší nasazení v reálné situaci mohlo být nedostaˇcující, avšak pro potˇreby implementace aplikace pro tuto DP se jedná o velkorysý limit.
Obrázek 4.4: Ukázka komunikace mezi zaˇrízeními, která nedisponují kompatibilní technologií, v prostˇredí frameworku MultipeerConnectivity. Data jsou v takovém pˇrípadˇe pˇreposílána pˇres dalšího úˇcastníka, který technologie obou komunikujících stran podporuje. MultipeerConnectivity obsahuje dva módy provozu, a to režim skenování (angl. browser) a režim oznamování (angl. advertiser). Aplikace na zaˇcátku aktivuje oba módy, cˇ ímž hledá okolní zaˇrízení a zárovenˇ vysílá svou vlastní pˇrítomnost. Aˇckoliv je komunikace pro pˇripojení oboustranná, samotnou inicializaci pˇripojení je možné provést pouze jednostrannˇe. V opaˇcném pˇrípadˇe se toto spojení ihned po navázání odpojuje. V pˇrípadˇe nalezení kompatibilního zaˇrízení je tedy nutné ustanovit pravidlo, podle kterého bude jedno zaˇrízení žádat o spojení a druhé zaˇrízení bude na tuto žádost cˇ ekat. Tímto pravidlem je v našem pˇrípadˇe opˇet UUID. Provede se rˇ etˇezcové porovnání a pokud je vlastní UUID lexikálnˇe menší než UUID druhého zaˇrízení, odesíláme pozvánku. V opaˇcném pˇrípadˇe vyˇckáváme na pˇrijetí pozvánky. Tímto zpusobem ˚ je zajištˇeno korektní ustanovení spojení. MultipeerConnectivity podporuje tˇri základní typy pˇrenosu: ˚ stream, resource a data (spolehlivý nebo nespolehlivý pˇrenos). Stream 43
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU je odesílání proudových dat, napˇríklad streamování videa. Resource je posílání vˇetších bloku˚ dat, zejména souboru, ˚ a data se využívá pro pˇrenos menších datových bloku. ˚ Puvodnˇ ˚ e zamýšlené využití pouze datového spolehlivého pˇrenosu nemohlo být realizováno, jelikož tento typ má omezenou maximální velikost pˇrenesených dat, jak bylo experimentálnˇe zjištˇeno. Samotné beacon záznamy mohou být velké, zvláštˇe pokud jsou iniciálnˇe vyžadovány od zaˇrízení, které se již v systému po delší dobu vyskytovalo. Následné inkrementální pˇrenosy jsou pak již rˇ ádovˇe menší. V každém pˇrípadˇe bylo nutné ustanovit jednoduchý protokol pro výmˇenu informací, v našem pˇrípadˇe založený na formátu JSON. V prvním poli type se definuje typ dotazu (request, response) a ve druhém poli content pak samotná data. Struktura tedy vypadá následovnˇe: { " type " : " request | response " , " content " : < data > } Po navázání spojení se obˇe zaˇrízení pokouší vymˇenit chybˇející záznamy. Nebylo by efektivní posílat všechny, protože spojení muže ˚ být realizováno nepˇrímo pˇres tˇretího úˇcastníka a pˇrenos tak muže ˚ být pomˇernˇe pomalý. První dotaz typu request tedy obsahuje ve svém tˇele seznam všech uživatelu˚ uložených v CoreData spoleˇcnˇe s datem a cˇ asem posledního záznamu a odesílá se spolehlivým datovým pˇrenosem, jelikož taková struktura nebude nikdy pˇríliš velká. Protistrana po obdržení této informace vytáhne ze své CoreData databáze všechny záznamy s UUID uživatelu, ˚ kteˇrí v request zprávˇe nejsou vubec ˚ obsaženy, a záznamy novˇejší než udávané datum u uživatelu, ˚ kteˇrí se ve zprávˇe nachází. Všechny záznamy jsou uloženy do výše popsané JSON struktury s typem response a ta je pomocí serializace pˇrevedena do NSData objektu, který obsahuje všechny potˇrebné informace pro rekonstrukci záznamu na stranˇe pˇríjemce a uložení do CoreData. Tento objekt je následnˇe uložen do doˇcasného souboru a odeslán pomocí resource pˇrenosu. I po úspˇešném pˇrenesení záznamu˚ zustavá ˚ relace aktivní a celý proces s žádostí se opakuje každých 30 vteˇrin. 44
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU 4.1.2 Komunikace s API serverem Odesílání dat na API server je provádˇeno výhradnˇe puvodním ˚ zarˇ ízením, které data lokálnˇe získalo (tedy ne data, která byla získána pomocí výmˇeny s okolními uživateli). Jedná se pouze o implementaˇcní rozhodnutí z hlediska optimalizace dat pˇrenášených na server a odesílání všech nesynchronizovaných dat by bylo možné zmˇenou jediné podmínky. V takovém pˇrípadˇe by se ovšem stávalo, že záznamy vymˇenˇené pomocí MultipeerConnectivity s atributem synced nastaveným na false by byly (pˇri funkˇcním spojení) na server odeslány vícekrát. Jednak puvodním ˚ zaˇrízením a dále všemi zaˇrízeními, které by takové záznamy pˇrijaly do svého úložištˇe. Zmˇenou na stranˇe serveru by tedy musela být explicitní kontrola duplicity pˇridávaných záznamu, ˚ která se v souˇcasném systému nenachází právˇe z duvodu ˚ nepotˇrebnosti dle aktuálního nastavení. Implementaˇcnˇe je REST klient pro komunikaci s API serverem vytvoˇren pomocí frameworku Alamofire. Pokus o odeslání záznamu˚ je provádˇen každých 10 vteˇrin. Záznamy jsou vytaženy z úložištˇe a stejnˇe jako v pˇrípadˇe výmˇeny mezi uživateli, je i v tomto pˇrípadˇe použit pro pˇrenos formát JSON. Konkrétnˇe se jedná o následující strukturu: { " uuid " : < uuid > , " stats " : [ { " rssi " : < rssi > , " accuracy " : < accuracy > , " proximity " : < proximity > , " datetime " : < datetime > , " major " : < major > , " minor " : < minor > } , ... ] } Tedy atribut uuid pro identifikaci odesílajícího uživatele a následnˇe atribut stats, který ve svém tˇele obsahuje pole vlastních záznamu˚ se všemi potˇrebnými údaji. Server standardnˇe odpovídá zprávou status s hodnotou OK a zaˇrízení muže ˚ po pˇrijetí takové zprávy oznaˇcit atribut synced odeslaných záznamu˚ v úložišti na hodnotu true. Více 45
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU o zpracování záznamu˚ na stranˇe serveru se nachází v sekci 4.2. 4.1.3 D3.js a vizualizace dat Pro vizualizaci dat byla zvolena JavaScriptová knihovna D3.js. Jedná se o knihovnu pro manipulaci dokumentu˚ založených na datech a jejich vizualizaci pomocí HTML, CSS a SVG. Ponˇevadž se D3.js skládá z mnoha ruzných ˚ modulu, ˚ její využití je opravdu všestranné, sahající od vykreslování triviálních statických koláˇcových a sloupcových grafu, ˚ pˇres interaktivní Voroného diagramy, barvení map, práci s Beziérovými kˇrivkami až po azimutální projekce mapových podkladu˚ a 3D vizualizace. Zábˇer je tedy vskutku široký a v oficiální galerii je k dispozici mnoho desítek konkrétních pˇríkladu˚ implementace1 . Použití JS knihovny bylo zvoleno zámˇernˇe, protože se tímto krokem významnˇe unifikovala prezentaˇcní vrstva serverové cˇ ásti a prezentaˇcní vrstva iOS aplikace. U serverové cˇ ásti je použití JS bˇežné. U iOS aplikace bylo pro propojení s touto knihovnou využito API WKWebView, kde zkratka WK v názvu znaˇcí WebKit, vykreslovací jádro webových stránek, které je použito napˇríklad u prohlížeˇce Safari. Komunikace s JS ve WKWebView je pomˇernˇe snadno implementovatelná a je realizovatelná oboustrannˇe. Schéma volání funkcí je zachyceno na obrázku 4.5. Pro vyvolání JS funkce z iOS je nutné zavolat metodu evaluateJavaScript:completionHandler:. Prvním argumentem je rˇ etˇezec obsahující název funkce (vˇc. parametru), ˚ kterou chceme vyvolat a která je na stranˇe JS vyhodnocena pomocí funkce eval(). Druhým argumentem je callback, jež je zavolán po dokoncˇ ení JS funkce a v nˇemž je rovnˇež možné pˇreˇcíst návratovou hodnotu. Pro opaˇcnou komunikaci, tedy pro zavolání Swift metody z JS, je nutné zavolat window.webkit.messageHandlers.«name».postMessage(), kde placeholder «name» v názvu znaˇcí libovolný název handleru, který si ve Swiftu vytvoˇríme. Handleru˚ si mužeme ˚ vytvoˇrit libovolné množství a pˇri volání zmínˇené JS funkce se ve Swiftu vždy vyvolá metoda userContentController:didReceiveScriptMessage:. 1. https://github.com/mbostock/d3/wiki/Gallery
46
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU Swift
JavaScript
evaluateJavaScript:completionHandler:
eval()
userContentController:didReceiveScriptMessage:
window.webkit.messageHandlers.<
>.postMessage()
Obrázek 4.5: Schéma volání funkcí pro komunikaci mezi aplikací napsanou ve Swiftu a komponentou WKWebView obsahující kód napsaný v JavaScriptu.
Pro samotnou vizualizaci byla použita komponenta Force Layout. Jedná se o implementci speciální techniky kreslení grafu, ˚ tzv. force-directed, což bychom mohli do cˇ eštiny pˇreložit jako silovˇe smˇeˇ rovaný. Casto se tato technika používá pro grafy, které mají splnoˇ vat vysoká estetická hlediska, pˇredevším co nejnižší poˇcet kˇrížení a dostateˇcné rozestupy mezi jednotlivými uzly. Force Layout využívá pro samotnou implementaci silovˇe smˇerovaného grafu další techniky jako Verletova metoda integrace nebo algoritmus Barnes-Hut, avšak není nutné je podrobnˇeji popisovat. Duležitým ˚ výsledkem této implementace jsou pˇredevším její dynamické vlastnosti jako pseudo gravitace a odpudivá síla uzlu. ˚ Gravitace se (v naší implementaci) využívá u uzlu, ˚ které nedisponují propojením k ostatním cˇ ástem systému, a brání tak potenciálnímu úniku mimo viditelnou oblast vykreslování. Odpudivá síla uzlu˚ je pak vhodná pro vzájemné odpuzování, aby nedocházelo k vykreslování dvou nebo více uzlu˚ na stejnou pozici. Vizualizaci je možné provozovat ve dvou režimech: procházení a filtrace historických dat nebo real-time pohled na systém. U historických dat si mužeme ˚ vyfiltrovat libovolné období, které chceme zobrazit a tímto obdobím procházet. Procházení je možné manuálnˇe po sekundových krocích nebo si mužeme ˚ šoupátkem nastavit konkrétní cˇ as v rámci vyfiltrované oblasti, popˇr. je možné spustit automatické procházení, kdy nám aplikace pˇrehraje urˇcitý úsek vývoje stavu systému v minulosti. Real-time pohled na systém pak pˇredstavuje vizualizaci s ménˇe jak sekundovým zpoždˇením. Stejnˇe jako pˇrenos záznamu˚ na API server a výmˇena mezi uživateli, i pro pˇrenos dat do vizualizaˇcní knihovny je použit formát JSON vhodný pro zpracování knihovnou D3.js. U filtrace historických dat 47
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU se zvolí období, které se má zobrazit, a aplikace pak pro toto období vytvoˇrí po sekundových intervalech tzv. snapshoty. Každý snapshot je vytvoˇren tak, že se vezme daný cˇ as, prochází se záznamy 20 sekund do minulosti a ke každé dvojici zaˇrízení – beacon se uloží nejaktuálnˇejší informace ohlednˇe vzdálenosti. Pokud bˇehem tohoto dvacetisekundového okna neexistuje jediný záznam s mˇerˇ itelnou vzdáleností, beacon se stejnˇe uloží, pouze bez odpovídajícího virtuálního spoje se zaˇrízením. Tímto zpusobem ˚ mužeme ˚ beacon zobrazit, avšak bez konkrétního vztahu s daným zaˇrízením. Beacony, které se v záznamech neobjeví po dobu delší jak 20 sekund jsou považoˇ vány za neaktuální a na snapshotu se nezobrazují. Casový interval je možné jednoduše pˇrizpusobit ˚ a byl zvolen s ohledem na optimální vizualizaci v dané aplikaˇcní doménˇe. Pro lepší popis fungování komponenty Force Layout je zde ukázka JSONu pˇredávaného ze Swift kódu do JS: { " 2 0 1 5 -0 4 -1 2 1 5 : 3 6 : 2 8 " : { " nodes " : [ { " id " : " B 0 7 0 2 8 8 0 -A 2 9 5 -A 8 AB - F 7 3 4 -0 3 1 A 9 8 A 5 1 2 DE " , " isBeacon " : false , " name " : " Adam ’ s iPhone " , " main " : true } , { " id " : " 2 | 1 " , " isBeacon " : true , " name " : " 2 | 1 " , " main " : false } , { " id " : " 4 | 1 " , " isBeacon " : true , " name " : " 4 | 1 " , " main " : false } ], " links " : [ { " source " : 0 , " target " : 1 , " distance " : 5 . 8 2 3 7 } ] 48
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU }, ... } Na koˇrenové úrovni jsou hlavními klíˇci datumy a cˇ asy jednotlivých snapshotu. ˚ Uvnitˇr se pak nachází samotná data pro Force Layout, tedy seznam uzlu˚ (nodes) a seznam spojení (links). U každého uzlu je poznaˇceno, zda se jedná o fyzický beacon, cˇ i nikoliv (isBeacon). Dále obsahuje id, což je v pˇrípadˇe zaˇrízení UUID a v pˇrípadˇe beaconu rˇ etˇezec cˇ ísel major a minor oddˇelené svislou cˇ arou. Pro lepší orientaci na vizualizaˇcní mapˇe se pak do pole name ukládá název zarˇ ízení v cˇ itelné podobˇe, pokud existuje. Pokud neexistuje, uloží se UUID, a pokud se jedná o beacon, uloží se opˇet cˇ ísla major a minor. Posledním atributem je main, jehož boolean hodnota true vyjadˇruje mateˇrské zaˇrízení, tedy zaˇrízení, na kterém probíhá zaznamenávání a prezentace dat. Údaj je duležitý ˚ pro vykreslení sebe sama jako hlavního zaˇrízení uprostˇred mapy. Aˇckoliv se pˇri prezentaci každého cˇ asu používá jedineˇcený záznam z této JSON struktury, kontinuita mezi vykreslováním uzlu˚ je ve Force Layout zajištˇena vazbou na jejich id. Pokud by tato vazba neexistovala, pˇri každém cˇ asovém posunu by se všechny uzly vykreslily znovu, nezávisle na pˇredchozí poloze. Seznam links pak zajišt’uje, že Force Layout správnˇe propojí odpovídající uzly. Atributy source a target obsahují indexy do pole uzlu, ˚ distance pak udává vzdálenost mezi tˇemito uzly. Ve vztahu k výše uvedené JSON ukázce by tedy situace 12. dubna 2015 v 15:36:28 vypadala následovnˇe: Adam’s iPhone (naše zaˇrízení) se nachází ve vzdálenosti 5,8327 metru˚ od beaconu 2|1 a v systému se nachází taktéž druhý beacon 4|1, u kterého však v tomto cˇ ase není známa pozice vzhledem k ostatním uzlum. ˚ Ukázka, jak by takové rozložení vypadalo, je na obrázku 4.6. Hodnota distance odpovídá hodnotˇe Accuracy ukládané v CoreData (viz obrázek 4.3). Duvodem, ˚ proˇc se pˇri urˇcování vzdálenosti nepoˇcítá s hodnotou RSSI, ale pˇrímo s hodnotou Accuracy dodávanou CoreLocation frameworkem, je skuteˇcnost, že RSSI samo o sobˇe v kontextu iBeacon lokalizace je témˇerˇ nicneˇríkající hodnotou. Bez Measured Power se jedná pouze o cˇ íslo urˇcující sílu signálu, ale není možné z ní odvodit vzdálenost, jelikož nevíme, s jakým výkonem iBeacon vysílá. CoreLocation zcela jistˇe s Measured Power pra49
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU
Obrázek 4.6: Ukázka zobrazení beaconu 2|1 ve vzdálenosti 5,8327 metru˚ od telefonu Adam’s iPhone a druhého beaconu 4|1, u nejž není znám žádný vzdálenostní vztah k ostatním zaˇrízením v systému.
cuje, avšak nejedná se o programátorsky pˇrístupnou hodnotu, a tudíž hodnota Accuracy je jediný zpusob, ˚ jak nepˇrímo obdržet Measured Power skrze odhadovanou vzdálenost v situaci, kdy neznáme pˇresné parametry komunikujících stran (pˇredevším vysílací výkon).
4.2 API a prezentaˇcní server API i prezentaˇcní server byly implementovány v rámci jednoho serveru jako samostatné moduly ve frameworku Nette. API server byl implementován jako REST server s podporou zpracování nˇekolika požadavku. ˚ Jedná se o POST požadavek na /api/user, který na server odesílá aplikace pˇri autorizaci. Mechanismus byl popsán v pˇredešlé kapitole 4.1. Pro pˇripomenutí jde pˇredevším o vytvoˇrení uživatele v databázi, pokud neexistuje, a vrácení jedineˇcných identifikátoru˚ major a minor, aby mohla aplikace vysílat bez rizika kolizí. Dalším voláním je POST na /api/stats, kam aplikace posílá seznam beacon záznamu˚ pro uložení do databáze ve formátu JSON (opˇet popsáno vˇcetnˇe ukázky JSON v kapitole 4.1). Posledním voláním je GET na /api/stats se dvˇema parametry from a to udávající datum a cˇ as prvního a posledního záznamu, které se mají naˇcíst z databáze. Jedná se o funkcionálnˇe ekvivalentní cˇ ást jakou je implementace ve Swiftu pro spolupráci s CoreData, zde pou50
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU ze s drobnými modifikacemi transformována do PHP kódu pro spolupráci s databází MySQL. Toto volání nevyužívá aplikace, ale D3.js knihovna pˇri filtraci záznamu˚ na prezentaˇcním serveru. Databáze pro ukládání záznamu˚ má podobnou strukturu jako úložištˇe CoreData v iOS aplikaci. ER diagram je zachycen na obrázku 4.7. Jedná se o relaci User s atributy uuid, major, minor, last_login, name a primární klíˇc id. Atribut uuid je identifikace vygenerovaná na stranˇe aplikace a zaslaná API serveru, cˇ ísla major a minor se naopak generují na stranˇe serveru a zasílají zpˇet aplikaci. Atribut last_login je spíše diagnostický údaj a volitelný název name je cˇ itelné jméno zaˇrízení, opˇet zasílané z aplikace. Relace Beacon obsahuje primární klíˇc id a identifikátory major a minor. Kromˇe toho obsahuje nepovinný cizí klíˇc user_id, který odkazuje na relaci User pro spárování virtuálního beaconu s identifikací konkrétního uživatele. Poslední relaci je pak Stats, která obsahuje primární klíˇc id a atributy rssi, accuracy, proximity a datetime. Pˇres cizí klíˇce beacon_id a user_id propojuje Stats relace User a Beacon s kardinalitou M:N (modelováno jako dvojice vztahu˚ 1:M a 1:N).
Obrázek 4.7: ER diagram databáze MySQL pro ukládání beacon záznamu˚ na serveru. Stejnˇe jako u iOS aplikace je i u prezentaˇcního serveru pro vizualizaci využita knihovna D3.js. Kromˇe ní je pro tvorbu rozhraní použita knihovna jQuery UI a ovládání vˇcetnˇe filtrace odpovídá rozhraní v aplikaci. Jedinou výjimkou je absence real-time zobrazení, 51
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU ponˇevadž je server v systému považován za podpurný ˚ prvek (pˇredevším pro pˇridˇelování beacon identifikátoru) ˚ a jeho primární rolí je ukládání, prezentace a filtrace historických dat. Ukázka rozhraní prezentaˇcního serveru je na obrázku 4.8.
Obrázek 4.8: Ukázka rozhraní prezentaˇcního serveru.
4.3 Testování Testování probíhalo prubˇ ˚ ežnˇe v rámci tvorby aplikace na úrovni jednotlivých komponent a komunikace mezi komponentami, pˇredevším mezi mobilním zaˇrízením a API serverem a mezi mobilními zaˇrízeními navzájem. Pro vývoj i testování byl dostupný telefon iPhone 4S, v rámci testu˚ pak ještˇe iPad 4. generace a iOS simulátor2 . Kromˇe toho 2. Softwarový simulátor operaˇcního systému iOS a telefonu iPhone bˇežící pod operaˇcním systémem OS X. Pro úˇcely testování byl zvolen model iPhone 5S.
52
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU dva Estimote beacony a tˇri Jaalee beacony, které byly použity také v praktických mˇerˇ eních v kapitole 3. V rámci testu˚ byla také zkoumána interakce s API serverem. Nejprve byla testována korektní komunikace se serverem. Pokud byl server dostupný a mobilní zaˇrízení bylo pˇripojeno k síti, autentizace probˇehla víceménˇe okamžitˇe po startu. Server ve všech pˇrípadech odeslal správné hodnoty major a minor. V pˇrípadˇe, že se jednalo o nové zaˇrízení, byla vygenerována nová jedineˇcná dvojice. V pˇrípadˇe, že existující, byla vrácena cˇ ísla major a minor spárovaná s UUID uživatele/aplikace. Stejnˇe tak byl testován pˇrípad, kdy byla špatnˇe nastavena poˇcáteˇcní adresa serveru, kterou lze manuálnˇe konfigurovat v nastavení aplikace. Po pˇrenastavení na správnou hodnotu, bylo opˇet spojení se serverem korektnˇe navázáno. Taktéž odesílání záznamu˚ probíhalo korektnˇe, což bylo ovˇerˇ eno jednak aktualizací cˇ asového údaje na poslední záložce aplikace Status, jednak pˇrímou kontrolou v databázi na serveru. Záznamy pˇribývaly ve správném poˇctu i se správným obsahem, což bylo zase ovˇerˇ eno porovnáním s výpisem na druhé záložce Data. Posledním testem v rámci interakce se serverem byla doˇcasná nedostupnost serveru. Pˇri tomto výpadku se aplikace pokoušela v periodických intervalech spojení obnovit. V momentˇe, kdy se toto podaˇrilo, byly opˇet korektnˇe odeslány všechny chybˇející záznamy nasbírané v meziˇcase. Další duležitou ˚ oblastí byla výmˇena informací mezi zaˇrízeními v dosahu. Jednou z hlavních výhod frameworku MultipeerConnectivity je automatické použití vhodného zpusobu ˚ propojení v závislosti na dostupných zdrojích. Nejprve byl tedy otestován pˇrenos mezi zarˇ ízeními s aktivovanou Wi-Fi sítí, kde vše probˇehlo bez problému. ˚ Poté byla Wi-Fi sít’ deaktivována a aktivováno pouze Bluetooth. I v tomto pˇrípadˇe probˇehl pˇrenos v poˇrádku, aˇckoliv subjektivnˇe mírnˇe pomaleji, což je však standardní oˇcekávané chování. Ponˇevadž byla k dispozici pouze dvˇe fyzická zaˇrízení, proklamovaná funkce pˇrenosu pˇres tˇretího úˇcastníka (viz sekce 4.1.1) byla otestována s podporou iOS simulátoru. Ponˇevadž ten nepodporuje BT, byla na nˇem aktivována pouze Wi-Fi sít’. Na iPhonu byl naopak aktivován pouze Bluetooth režim a iPad sloužil jako prostˇredník s aktivním Wi-Fi i BT. Nejprve došlo k navázání spojení iPhone –iPad a iPad –iOS simulátor, následnˇe se pak úspˇešnˇe spojil i iPhone s iOS simulátorem. Pˇrenos byl v tomto pˇrípadˇe nejpomalejší, ale kromˇe omezené pˇrenosové 53
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU rychlosti k žádným komplikacím nedošlo. Spojení zustalo ˚ ve všech pˇrípadech dlouhodobˇe navázáno a inkrementální pˇrenosy probíhaly ve stanovených intervalech. Poslední zajímavou oblastí byla samotná vizualizace na mapˇe. Zde bylo trochu komplikované stanovit koncept testování. Nakonec se testovaly dvˇe ruzné ˚ konfigurace v klasickém kanceláˇrském prostˇredí se stoly, židlemi a nábytkem s ruznými ˚ prostorovými rozloženími mobilních zaˇrízení a beaconu. ˚ Na obrázku 4.9 lze vidˇet ukázku výsledku˚ prvního testování. Na levé stranˇe je zachyceno skuteˇcné rozložení komponent v místnosti vˇcetnˇe vzdáleností mezi nimi. Pro pˇrehlednost byly beacony i mobilní zaˇrízení umístˇeny do pravidelné mˇrížky. Na pravé stranˇe je pak výsledek rekonstrukce za použití kombinace vlastních dat i dat získaných od druhého mobilního zaˇrízení. Aˇckoliv se pˇri pˇrímém porovnání vzdáleností nejedná o pˇríliš pˇresná data, vizuální výsledek by se dal oznaˇcit jako pomˇernˇe odpovídající umístˇení komponent v rámci daného systému. Zatímco beacon 1|1 se hlásil blíže, než se skuteˇcnˇe nacházel, beacony 2|1 a 3|1 se naopak hlásily o nˇeco dále. Tato tˇri zaˇrízení byla od výrobce Jalee. Problémovým prvkem byl v tomto testování Estimote beacon 43888|1. Ten se na náhledu nenachází a smˇerˇ ují k nˇemu pouze linky smˇerem do pravého horního rohu se zjištˇenou vzdáleností 26,2 m od iPhonu a 25,11 m od iPadu (druhá hodnota není vidˇet na obrázku). Tento výsledek byl oˇcekávaný, jelikož nebylo možné nastavit korektnˇe hodnotu Measured Power. Jak bylo zjištˇeno v kapitole 3, je bez ní celý odhad naprosto nepoužitelný. Pˇri ignoraci tohoto deviantního prvku by se však dalo konstatovat, že v závislosti na aplikaˇcní doménˇe by mohl být získaný odhad prakticky použitelný. U druhého testu byl odebrán Estimote beacon, který do systému zanášel pouze šum, a byla permutována jednotlivá umístˇení prvku. ˚ Výsledek lze vidˇet na obrázku 4.10. Ani v tomto pˇrípadˇe vizualizace neodpovídá stoprocentnˇe realitˇe. Nejvˇetší vinu na zkreslení mˇelo chybné mˇerˇ ení beaconu 2|1, který iPad hlásil ve vzdálenosti pouhých 0,67 m, aˇckoliv skuteˇcná vzdálenost byla více než cˇ tyˇrnásobná, konkrétnˇe 3,1 m. Naopak beacon 1|1, který se nacházel ve vzdálenosti 3,1 m od iPhonu, byl tímto zaˇrízením hlášen ve vzdálenosti více než trojnásobné, a to 9,48 m. Pˇri porovnání s výsledky pˇredchozího testu, kdy se beacon 1|1 hlásil blíže a beacon 2|1 dále, jsou nepˇresnosti obrácené. Tím však nelze vyvodit žádný závˇer. Lze pouze 54
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU
Obrázek 4.9: První praktický test aplikace se dvˇema mobilními zaˇrízeními a cˇ tyˇrmi beacony. Na levé stranˇe je skuteˇcné rozložení komponent, na pravé stranˇe je vizualizace v aplikaci.
konstatovat, že se projevily oˇcekávané fluktuace závislé na vnˇejších podmínkách a nepˇredvídatelných interferenˇcních vlivech. Celkovˇe však i výsledek druhého test podává užiteˇcnou informaci o stavu systému v daném okamžiku a mohl by být za jistých okolností praktický využitelný.
55
4. I MPLEMENTACE UKÁZKOVÉHO SYSTÉMU
Obrázek 4.10: Druhý praktický test aplikace se dvˇema mobilními zarˇ ízeními a tˇremi beacony. Na levé stranˇe je skuteˇcné rozložení komponent, na pravé stranˇe je vizualizace v aplikaci.
56
Kapitola 5
Možnosti rozšíˇrení a úplná rekonstrukce pohybu Z pˇredešlých kapitol pomˇernˇe jasnˇe vyplývá, že iBeacon má daná svá omezení a jedná se o mladou technologii v zaˇcátcích. Úplná podpora indoor navigace a tedy kompletní rekonstrukce pohybu uživatelu˚ tak, jak ji známe ze systému GPS, je u iBeaconu˚ pomˇernˇe problematická z duvod ˚ u˚ vysoké nepˇresnosti. Firmy jako Estimote indoor lokalizaci pomocí svých beaconu˚ nabízí [9]. Jedná se však o cˇ ásteˇcnˇe jiný typ lokalizace, než jakou rˇ eší tato DP. Estimote dokázal pomocí svého hardwaru na míru a kalibraˇcní aplikace na mobilním telefonu vytvorˇ it demo, které v reálném cˇ ase ukazuje na displeji pohyb uživatele po místnosti. Ke správné funkcionalitˇe jsou potˇreba cˇ tyˇri beacony, plus volitelnˇe další dva pro složitˇejší typy místností a pro vylepšení pˇresnosti. Každý beacon se umístí uprostˇred jedné stˇeny pˇribližnˇe ve výšce oˇcí. Následnˇe uživatel spustí aplikaci, která jej provede kalibraˇcním procesem. Ten spoˇcívá v umístˇení telefonu vedle prvního z beaconu a následnˇe chuzi ˚ kolem stˇen místnosti k dalšímu beaconu. U nˇej se rovnˇež na krátkou chvíli umístí telefon do tˇesné blízkosti a pokraˇcuje se podél stˇeny k dalšímu beaconu v poˇradí. Proces je zakonˇcen umístˇením telefonu k beaconu, u nˇejž se zaˇcínalo. Tím je kalibrace dokonˇcena a aplikace dokáže zpracovávat signál z beaconu˚ takovým zpusobem, ˚ že v reálném cˇ ase ukazuje polohu uživatele. V souˇcasné dobˇe funguje demo pouze pro jedinou cˇ tvercovou nebo obdélníkovou místnost. S atypickými tvary se podle tvurc ˚ u˚ pocˇ ítá do další verze. Dále je tato lokalizace dostupná pouze pro operaˇcní systém iOS. Udávaná pˇresnost je 0,5 až 1 metr. Tvurci ˚ upozornují ˇ na vliv interference a právˇe z tohoto duvodu ˚ jsou v nˇekterých pˇrípadech doporuˇcovány další dva beacony. ˇ Cím se zásadnˇe liší aplikace Estimote od rˇ ešení navrhovaného v 57
ˇ 5. M OŽNOSTI ROZŠÍ RENÍ A ÚPLNÁ REKONSTRUKCE POHYBU
této DP je pˇredevším statické a známé umístˇení všech iBeaconu˚ u Estimote, které navíc musí projít kalibraˇcním procesem. V aplikaci této DP se s žádným kalibraˇcním procesem nepoˇcítá, naopak poˇcítá se s dynamickým ad-hoc systémem, který dokáže pružnˇe reagovat na zmˇeny v poˇctu beaconu˚ i klientu, ˚ a který muže ˚ být nasazen v libovolném prostˇredí, leˇc za cenu snížené pˇresnosti. Úplnou rekonstrukcí pohybu se zabývají také nˇekteré odborné cˇ lánky, napˇríklad Improving Indoor Positioning Accuracy with Dense, Cooperating Beacons [7] nebo Demo Abstract: An iBeacon Primer for Indoor Localization [15]. U prvního cˇ lánku se jedná o dvoufázovou lokalizaci, kdy se v první fázi využívá pro urˇcení polohy mobilního zaˇrízení trilaterace pomocí známých Wi-Fi pˇrístupových bodu˚ (AP). Teprve ve druhé fází se výsledky zpˇresnují ˇ pomocí iBeacon signálu od okolních uživatelu, ˚ kteˇrí mají také pˇrístup k informacím o poloze všech pˇrístupových bodu. ˚ Aˇckoliv tedy cˇ lánek poˇcítá se stacionárním umístˇením AP zaˇrízení, objevuje se zde element komunikace s okolními uživateli, stejnˇe jako v aplikaci této DP. U druhého cˇ lánku se pak, podobnˇe jako u systému Estimote, vypoˇcítává poloha mobilního zaˇrízení pomocí trilaterace. V tomto pˇrípadˇe pomocí pouhých tˇrí beaconu. ˚ Nepostradatelnou souˇcástí systému je server, kam se informace zasílají a kde probíhá veškeré zpracovávání a vyhodnocování polohy pomocí techniky particle filtering. Podle autoru˚ je dosažená pˇresnost 0,53 metru. ˚ Je však možné výše uvedené techniky aplikovat na náš ad-hoc systém pro zpˇresnˇení lokalizace? Víceménˇe všechny souˇcasné odborné cˇ lánky i techniky jsou postaveny na znalosti umístˇení jednoho nebo více prvku˚ systému. Toto rozšíˇrení by v zásadˇe mˇelo být proveditelné. Pˇredpokladem je umístˇení beaconu˚ na pˇredem urˇcená pevná místa v prostoru. Dále by bylo nutné modifikovat vykreslovací cˇ ást (knihovna D3.js), abychom mohli tyto beacony stacionárnˇe zobrazit na mapˇe. Jelikož aplikace v souˇcasné verzi nepodporuje reálné mapové podklady a umístˇení se nepoˇcítá v závislosti na souˇradnicovém koordinaˇcním systému, bylo by umístˇení beaconu˚ modelováno dle vzájemných konstantních vzdáleností. Pokud tedy máme k dispozici tˇri beacony a známe vzdálenosti mezi nimi, dokážeme ve 2D prostoru vytvoˇrit jedineˇcný trojúhelník, pouze s libovolnou rotací. Zaˇrízení, které by se nacházelo v dosahu všech tˇechto beaconu˚ by se pak na mapˇe vykreslilo daleko pˇresnˇeji právˇe z duvodu ˚ vzdálenost58
ˇ 5. M OŽNOSTI ROZŠÍ RENÍ A ÚPLNÁ REKONSTRUKCE POHYBU
ních omezení mezi beacony. Tato vzdálenostní omezení není možné zadat jiným zpusobem ˚ než manuálnˇe, jelikož není možné vytvoˇrit pˇrímý automatický spoj mezi dvˇema hardwarovými iBeacony (nedokážou spolu pˇrímo komunikovat). Vizuální ukázka takového modelu je na obrázku 5.1. Na levé stranˇe je aktuální situace, kdy vztahy mezi jednotlivými beacony nejsou známy, tzn. neexistuje mapování na konkrétní prostor. Ve druhém pˇrípadˇe byly tyto vztahy doplnˇeny a pozice mobilního zaˇrízení je tak daleko pˇresnˇejší a více odpovídající realitˇe rozmístˇení beaconu˚ v místnosti.
Obrázek 5.1: Porovnání aktuálního stavu zobrazení beaconu˚ se znalostí vzdáleností k mobilnímu zaˇrízení (vlevo) a možné rozšíˇrení pro pˇresnˇejší lokalizaci se znalostí konkrétního umístˇení beaconu˚ a vzdálenostních vztahu˚ mezi nimi (vpravo). Další možností optimalizace by mohla být práce pˇrímo s hodnotami Accuracy dodávanými frameworkem CoreLocation. S rozmachem nových chytrých telefonu˚ se stále více zaˇcínají uplatnovat ˇ ruzné ˚ senzory: akcelerometr, gyroskop a další. Ty nám mužou ˚ poskytnout zajímavá data o stavu mobilního zaˇrízení v prostoru – napˇríklad aktuální zrychlení ve smˇeru os X, Y a Z. Z posledních nˇekolika vzorku˚ Accuracy by byl odhadován stav ve vztahu k danému beaconu – pˇribližování se, oddalování se nebo nehybnost, vˇcetnˇe koeficientu, který by urˇcoval, jak výrazný je tento jev. Ve spojení se senzorovými daty by pak byl takový výsledek bud’ utvrzován nebo 59
ˇ 5. M OŽNOSTI ROZŠÍ RENÍ A ÚPLNÁ REKONSTRUKCE POHYBU
zmírnován. ˇ V prvním pˇrípadˇe by se mohlo jednat o stav nehybnosti se senzory hlásícími nulový pohyb nebo stav pˇribližování se s akcelerometrem hlásícím zrychlení. Ve druhém pˇrípadˇe by se mohlo jednat o situaci, kdy dle beacon dat by se mˇel telefon oddalovat, avšak akcelerometr žádné zrychlení nehlásí. Ponˇevadž je akcelerometr senzor dodávající teoreticky pˇresnˇejší hodnoty než beacon, ve vizualizaci bychom telefon mírnˇe oddalovali, avšak s nižší rychlostí než by napovídala samotná beacon data. K takovému zpˇresnování ˇ je však vždy potˇreba vyšší poˇcet dostupných iBeaconu˚ v okolí. Pokud by totiž beacon data hlásily v posledních nˇekolika vzorcích stacionární stav a akcelerometr napovídal pohyb zaˇrízení, je v pˇrípadˇe jednoho beaconu nemožné urˇcit, kterým smˇerem (zda od nˇej nebo k nˇemu) zaˇrízení posouvat. V pˇrípadˇe vˇetšího poˇctu beaconu˚ pak lze teoretizovat, že by takový odhad mˇelo být možné provést, minimálnˇe s jistou mírou pravdˇepodobnosti, díky vˇetšímu množství dostupných dat. Je nutné také poˇcítat s dalšími zaˇrízeními v systému, které nejsou, na rozdíl od hardwarových beaconu, ˚ stacionární. Stav, kdy by beacon data napovídala pohyb zaˇrízení a akcelerometr zrychlení nehlásil, by tak mohl být právˇe v situaci, kdy by se pˇribližovalo nebo oddalovalo další mobilní zaˇrízení v systému, zatímco vlastní zaˇrízení by zustávalo ˚ na místˇe. Podobnˇe jako akcelerometr nebo gyroskop by se dal použít i krokomˇer, který dokáže díky kombinaci senzoru˚ odhadovat pˇrímo pocˇ et kroku˚ a uraženou vzdálenost. Ne všechna v souˇcasnosti používaná zaˇrízení však disponují potˇrebnými komponentami. Napˇríklad hlavní testovací model, iPhone 4S, neobsahuje pohybový koprocesor M7 (nebo vyšší) starající se o zpracování dat z akcelerometru, gyroskopu a kompasu pro využití k mˇerˇ ení kroku˚ a uražené vzdálenosti. Zpˇresnování ˇ touto cestou by tudíž nepˇripadalo v úvahu. U systému iOS a Apple zaˇrízení pˇrichází podpora s modely iPhone 5S (2014), iPad Air (2014) a iPad mini 2 (2013), nebo novˇejšími.
60
Kapitola 6
Závˇer V rámci této DP byla zkoumána technologie iBeacon a její využití pro lokalizaci a komunikaci mezi zaˇrízeními. V teoretické cˇ ásti byly rozebrány principy, na kterých technologie funguje, byly popsány vlasnosti a typy zaˇrízení nutných pro provoz systému postavených na technologií iBeacon a byly prezentovány praktické projekty soucˇ asného nasazení. V další cˇ ástí se práce zamˇerˇ ila na praktická mˇerˇ ení lokalizaˇcních schopností s ohledem na urˇcování vzdálenosti u dvou typu˚ iBeacon zaˇrízení v ruzných ˚ konfiguracích a podmínkách. Na základˇe zjištˇených vlastností a omezení technologie byla navržena a implementována aplikace pro iOS pro zobrazení real-time a historických dat s podporou webového serveru. Aplikace komunikuje nejen se serverem, ale také s ostatními uživateli v okolí pro výmˇenu dat a pro získávání více informací o stavu systému a potenciální zpˇresnování ˇ umístˇení ve vztahu k okolním entitám. V poslední cˇ ásti pak práce diskutuje možnosti rozšíˇrení pro pˇresnˇejší rekonstrukci pohybu uživatelu˚ systému. Aˇckoliv je iBeacon stále relativnˇe mladou technologií, již nyní lze vypozorovat celosvˇetové trendy smˇerˇ ující k masivnˇejšímu rozšíˇrení. Jak bylo ale v rámci této DP zjištˇeno, technologie má zcela jistˇe své limity. Pˇredevším je to fluktuace signálu. Tento problém je obecnˇe známý, ale v rámci kapitoly praktických mˇerˇ ení 3 bylo chování beaconu˚ zkoumáno za stabilních podmínek, a mohly tak být vypozorovány konkrétní situace, v nichž urˇcování vzdálenosti s iBeaconem selhává. Muže ˚ se jednat o nevhodné nastavení vysílacího výkonu nebo intervalu vysílání ve vztahu k pˇredpokládané oblasti pokrytí. Ruzné ˚ beacony jsou vytvoˇreny s ruznou ˚ kvalitou hardwaru a u nˇekterých modelu˚ se muže ˚ vyskytovat slabý vysílací výkon nebo muže ˚ signál v cˇ ase silnˇe kolísat. Podstatnou roli v pˇresném urˇcení vzdálenosti hraje 61
ˇ 6. Z ÁV ER
také hodnota Measured Power. Jak bylo zjištˇeno, správná kalibrace této hodnoty je naprosto zásadní pro získání korektních výsledku. ˚ Bohužel každé mobilní zaˇrízení má jinou citlivost a není tak možné tuto hodnotu nastavit zcela univerzálnˇe. Díky jiné citlivosti se u každého zaˇrízení provede jiný odeˇcet hladiny RSSI a tedy je odhadována jiná vzdálenost. U dynamického systému, kde není pˇredem známo jaká zaˇrízení se mohou úˇcastnit, nemá tento problém zcela jasné rˇ ešení a musí se s ním poˇcítat jako s vlastností dané technologie. V praktické cˇ ásti pak byla vytvoˇrena funkˇcní iOS aplikace, která mˇerˇ ení signálu z iBeacon majáku˚ využívá pro sbírání dat a vykreslování tˇechto dat jako real-time nebo historické vizualizace stavu systému v daných cˇ asových okamžicích. Vzhledem k tomu, že aplikace není vázána na konkrétní mapové podklady, ale pracuje pouze s iBeacon daty, lze ji využít ve zcela neznámých prostorech bez pˇredchozí nutnosti kalibrace. Jediným pˇredpokladem je pokrytí oblasti iBeacony. Jedná se o implementaci, která není vázána na specifický pˇrípad využití. Pro konkrétní aplikaci tohoto systému by byla nutná modifikace vzhledem k oˇcekávaným výstupum. ˚ Mezi tyto aplikace patˇrí napˇríklad využití na veletrzích, výstavách, muzeích nebo v obchodních domech. Jednoduše ve všech prostorech, kde je oˇcekáván pohyb vˇetšího množství osob na ne pˇríliš rozsáhlé ploše. Je však nutné si uvˇedomit, že pro opravdu praktické využití systému˚ tohoto typu (napˇríklad sledování pohybu osob kolem konkrétních stánku˚ na festivalu), je nutné, aby uživatelé mˇeli naši aplikaci nainstalovanou a spuštˇenou na svých mobilních zaˇrízeních. Kromˇe samotné nutnosti instalace aplikace, musí být brána v potaz i otázka ochrany soukromí uživatelu. ˚ Aˇckoliv se nejedná o problém principu fungování samotného systému, jde zcela jistˇe o nezanedbatelná hlediska, které by mohly být pˇrekážkami pro masivnˇejší nasazení technologie iBeacon v této oblasti.
62
Seznam zkratek BLE DP GATT MP MVC RSSI UUID
Bluetooth Low Energy Diplomová práce Generic Attribute Profile Measured Power Model View Controller Received Signal Strength Indication Universally Unique Identifier
63
Literatura [1] A DEEVEE. Telefónica Germany OHG Mobile App: Watch Out! [online]. April 16, 2015 [cit. 2015-04-22]. Dostupné na: . [2] A ISLELABS. IBeacon Battery Drain on Apple vs Android: A Technical Report [online]. 13 Aug 2014 [cit. 2014-12-20]. Dostupné na: . [3] A ISLELABS. The Hitchhikers Guide to iBeacon Hardware: A Comprehensive Report by Aislelabs [online]. 3 Nov 2014 [cit. 2014-12-20]. Dostupné na: . [4] A ISLELABS. IBeacon and Battery Drain on Phones: A Technical Report [online]. 7 Jul 2014 [cit. 2014-12-20]. Dostupné na: . [5] A PPLE I NC .. CLBeacon Class Reference [online]. 2013-09-18 [cit. 2014-12-24]. Dostupné na: . [6] B ODEN, R. Carrefour and Nisa track shoppers via Bluetooth beacons in trolleys and baskets [online]. 26 June 2014 [cit. 2014-12-21]. Dostupné na:
LITERATURA carrefour-nisa-track-shoppers-via-bluetoothbeacons-trolleys-baskets/>. [7] B RASSIL, J. Improving Indoor Positioning Accuracy with Dense, Cooperating Beacons. Procedia Computer Science. 2014, roˇc. 40, cˇ . 1. S. 1 – 8. Fourth International Conference on Selected Topics in Mobile & Wireless Networking (MoWNet ’2014). ISSN 1877-0509. [8] C HANTAL, T. EasyJet is latest airline testing iBeacons for speedier airport experiences [online]. July 9, 2014 [cit. 2014-12-21]. Dostupné na: . [9] E STIMOTE , I NC .. Estimote Indoor Location [online]. 2015 [cit. 2015-04-23]. Dostupné na: . [10] FARAHANI, S. ZigBee Wireless Networks and Transceivers. 1. vyd. Burlington (MA, USA): Newnes, 2008. 360 s. ISBN 978-0-7506-8393-7. [11] G OOGLE I NC .. Android 5.0 APIs: Bluetooth Low Energy [online]. 2014 [cit. 2015-02-28]. Dostupné na: . [12] K AHN, J. Cannes Lions Festival app will use iBeacons to let attendees network [online]. June 11, 2014 [cit. 2014-12-21]. Dostupné na: . [13] K AHN, J. United Nations uses iBeacons to simulate a minefield & raise awareness at NY museum [online]. March 31, 2014 [cit. 2014-12-22]. Dostupné na: . 65
LITERATURA [14] L EVY, L. The Kalman Filter: Navigation’s Integration Workhorse [online]. 3/29/2002 [cit. 2014-12-25]. Dostupné na: . [15] M ARTIN, P. e. a. An iBeacon Primer for Indoor Localization: Demo Abstract. In Proceedings of the 1st ACM Conference on Embedded Systems for Energy-Efficient Buildings. New York, NY, USA: ACM, 2014. S. 190 – 191. BuildSys ’14. ISBN 978-1-4503-3144-9. [16] M URRAY, J. Where’s My Beacon? Using Beacon Technology in Mobile App Development [online]. 05.07.14 [cit. 2015-02-28]. Dostupné na: . [17] N ESBIT, T. PayPal Lets Employees Pay For Lunch With Their Smartwatches [online]. April 25, 2014 [cit. 2014-12-22]. Dostupné na: . [18] N ILSSON, B. Bluetooth Low Energy vs. Classic Bluetooth: Choose the Best Wireless Technology For Your Application [online]. June 08, 2012 [cit. 2014-12-20]. Dostupné na: . [19] O GUEJIOFOR, O., O KOROGU, V., A DEWALE, A. et al. Outdoor Localization System Using RSSI Measurement of Wireless Sensor Network. International Journal of Innovative Technology and Exploring Engineering (IJITEE). 2013, roˇc. 2, cˇ . 2, s. 1–6. ISSN 2278-3075. [20] P UCHTA, O. Broadcasting Power, RSSI and Measured Power explained [online]. December 16, 2014 [cit. 2015-04-19]. Dostupné na:
LITERATURA articles/201636913-Broadcasting-Power-RSSI-andMeasured-Power-explained>. [21] S URUR. Windows 10 will support iBeacon technology [online]. Oct 25, 2014 [cit. 2015-02-28]. Dostupné na: . [22] T ERDIMAN, D. At CES, a hunt for hidden treasure [online]. January 8, 2014 [cit. 2014-12-22]. Dostupné na: . [23] T OWNSEND, K. GATT [online]. 2014-12-20 [cit. 2014-12-20]. Dostupné na: . [24] V ERIS I NDUSTRIES. Veris Aerospond Wireless Sensors: Received Signal Strength Indicator (RSSI) [online]. 2013 [cit. 2015-02-28]. Dostupné na: . [25] V LUGT, E. Bluetooth Low Energy, Beacons and Retail [online]. 2013 [cit. 2015-02-28]. Dostupné na: . [26] W ILLIAM J. H UGHES T ECHNICAL C ENTER. Global Positioning System (GPS) Standard Positioning Service (SPS) Performance Analysis Report [online]. July 31, 2014 [cit. 2014-12-02]. Dostupné na: . [27] W OODS, B. Virgin Atlantic will use Apple’s iBeacon tech to help passengers passing through Heathrow [online]. 1 May ’14 [cit. 2014-12-22]. Dostupné na:
LITERATURA atlantic-will-use-apples-ibeacon-tech-helppassengers-passing-heathrow/>.
68
Pˇríloha A
Seznam elektronických pˇríloh ∙ iosapp.zip – ZIP archív zdrojových kódu˚ iOS aplikace ∙ webapp.zip – ZIP archív zdrojových kódu˚ API a prezentaˇcního serveru vˇcetnˇe SQL skriptu pro vytvoˇrení databáze
69
