System Lokalizacji Wewnatrzbudynkowej

Politechnika Łódzka
Instytut Informatyki
PRACA DYPLOMOWA INŻYNIERSKA
System lokalizacji wewnatrzbudynkowej

˛ z
dynamiczna˛ infrastruktura˛ Bluetooth Low Energy
Indoor localization system with dynamic Bluetooth
Low Energy infrastructure
Wydział Fizyki Technicznej, Informatyki i Matematyki Stosowanej

Promotor: dr inż. Krzysztof Lichy
Dyplomant: Antoni Karwowski
Numer albumu: 229908
Kierunek: Informatyka Stosowana
Specjalność: Inżynieria Oprogramowania i Analiza Danych
Łódź, 9.05.2023
Instytut Informatyki
90-924 Łódź, ul. Wólczańska 215, budynek B9
tel. 042 631 27 97, 042 632 97 57, fax 042 630 34 14 email: office@ics.p.lodz.pl
i
Abstract
English
The aim of the work was to create an alternative system of indoor location. The
solution is based on the Bluetooth protocol. Compared to the existing solutions, the
novelty is the use of dynamic infrastructure, i. e. the need to install dedicated devices
and instead the use of already existing electronic equipment, household appliances,
computers or mobile phones. In addition, this infrastructure can be managed in
real time via the administration interface. The system also has the ability to detect
the location of devices without dedicated software, such as wireless headphones or
watches, as long as they emit a Bluetooth Low Energy signal. As part of the project,
software for android phones and Linux computers was created. We also implemented
a server application that sets and records location history, as well as an interface
for visualizing positions on the map. A location determination algorithm has also
been designed, which, by taking into account the mutual location of users, makes
it possible to determine the position of devices even with very few reference points.
Using the implemented system, an experiment was conducted, where the accuracy
of measuring location in a living space of 120 m2 with the presence of 10 devices (6
rasperry pi, watch, keychain, desktop computer and mobile phone) was tested. As
a result of the measurements, an average measurement error of about 3 meters was
determined.
ii
Polish
Celem pracy było stworzenie alternatywnego systemu lokalizacji wewnątrzbudyn-

kowej. Rozwiązanie bazuje na protokole Bluetooth. Względem istniejących rozwią-
zań nowością jest stosowanie dynamicznej infrastruktury, a więc brak konieczności
montażu dedykowanych urządzeń a w zamian wykorzystanie istniejących już sprzę-
tów RTV, AGD, komputerów czy telefonów komórkowych. Dodatkowo, wymienioną
infrastrukturą można zarządzać w czasie rzeczywistym przy pomocy interfejsu ad-
ministracyjnego. System ma również możliwość wykrywania lokalizacji urządzeń bez
dedykowanego oprogramowania, takich jak słuchawki bezprzewodowe czy zegarki, o
ile emitują one sygnał Bluetooth Low Energy. W ramach projektu stworzone zostało
oprogramowanie na telefony z systemem android oraz na komputery z system Linux.
Zaimplementowano także aplikację serwerową, wyznaczającą i zapisującą historię lo-
kalizacji a także interfejs do wizualizacji pozycji na mapie. Zaprojektowano również
algorytm do wyznaczania lokalizacji, który, dzięki uwzględnieniu wzajemnej lokali-
zacji użytkowników, umożliwia wyznaczanie pozycji urządzeń nawet przy obecności
bardzo niewielu punktów referencyjnych. Przy wykorzystaniu zaimplementowanego
systemu przeprowadzono eksperyment, gdzie zbadano dokładność pomiaru lokali-
zacji w przestrzeni mieszkalnej o powierzchni 120 m2 przy obecności 10 urządzeń
(6 rasperry pi, zegarka, zawieszki do kluczy, komputera stacjonarnego oraz tele-
fonu komórkowego). W wyniku przeprowadzonych pomiarów ustalono średni błąd
pomiarowy wynoszący około 3 metry.
iii
Spis treści
1 Wstęp 2
1.1 problematyka i zakres pracy . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 opis problemu . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 zastosowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 hipoteza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Cele pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Metoda Badawcza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Przegląd literatury w dziedzinie . . . . . . . . . . . . . . . . . . . . . 5
1.5 Układ pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 IPS 7
2.1 definicje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 rozwiązania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Algorytmy range-based . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4 Algorytmy range-free . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 wady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Opis Technologii 13
3.1 Definicje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Sprzęt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Oprogramowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 aplikacje użytkownika . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 aplikacje administracyjne . . . . . . . . . . . . . . . . . . . . . 15
iv
SPIS TREŚCI SPIS TREŚCI
3.3.3 lista programów . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.1 Języki programowania . . . . . . . . . . . . . . . . . . . . . . 16
3.4.2 Biblioteki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.3 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Opis Projektu 22
4.1 Analiza wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1 studium możliwości . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.2 wymagania funkcjonalne . . . . . . . . . . . . . . . . . . . . . 24
4.1.3 ograniczenia projektu . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Algorytm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 źródło danych . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.2 struktura danych . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.3 wyznaczanie pozycji . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 konserwacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Implementacja 37
5.1 tribeacon-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1 Kod Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.2 Kod JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 tribeacon-emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3 tribeacon-client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.1 tribeacon-linux . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.2 tribeacon-android . . . . . . . . . . . . . . . . . . . . . . . . . 40
6 Eksperyment 41
6.1 Opis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2 Wizualizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.3 Wyniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7 Dyskusja 49
7.1 Założenia zrealizowane . . . . . . . . . . . . . . . . . . . . . . . . . . 49
v
SPIS TREŚCI SPIS TREŚCI
7.2 Założenia niezrealizowane . . . . . . . . . . . . . . . . . . . . . . . . 50

7.3 Ocena stworzonego systemu . . . . . . . . . . . . . . . . . . . . . . . 50
7.4 Porównanie z istniejącymi IPS . . . . . . . . . . . . . . . . . . . . . . 50
7.5 Ocena możliwości wdrożenia . . . . . . . . . . . . . . . . . . . . . . . 51
7.6 Dalsze badania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.6.1 Eksperymenty . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.6.2 Optymalizacja parametrów . . . . . . . . . . . . . . . . . . . . 52
7.6.3 Moc sygnału . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.7 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Bibliografia 55
Spis rysunków 57
Spis tabel 58
A Instrukcja uruchomienia 59
A.1 TriBeacon Serwer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.2 TriBeacon Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.3 TriBeacon Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.4 TriBeacon Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1
Rozdział 1
Wstęp
1.1 problematyka i zakres pracy
Niniejsza praca dotyczy zakresu inżynierii oprogramowania oraz internetu rzeczy.
Głównym przedmiotem pracy jest stworzenie oprogramowania oraz infrastruktu-

ry IPS (Indoor Positioning System) umożliwiającej określanie lokalizacji w budyn-
kach.
1.1.1 opis problemu
Lokalizacja wewnątrzbudynkowa rozwija się jako odrębna dziedzina od lokalizacji

globalnej (GPS) ze względu na ograniczenia sprzętowe rozwiązań opartych na łącz-
ności satelitarnej. Istnieje wiele zaprojektowanych i wdrożonych systemów lokalizacji
wewnątrz budynkowej, jednak każdy z nich ma pewne wady. Najczęstszą przeszko-
dą jest wysoki koszt infrastruktury oraz urządzeń pomiarowych, a także koniecz-
ność projektowania i dostosowania systemu do topologii i specyficznych właściwości
zarządzanego budynku. Dodatkowym problemem jest także konieczność utrzymy-
wania powyższej infrastruktury, co np. w przypadku stosowania urządzeń bezprze-
wodowych wiąże się z cykliczną wymianą baterii, naprawą uszkodzonego sprzętu,
kalibracją, itd. Dodatkowym utrudnieniem jest również duże zróżnicowanie w do-
kładności i mocy sygnału urządzeń pomiarowych np. w telefonach komórkowych,
oraz stosowanie różnych standardów komunikacji.
2
ROZDZIAŁ 1. WSTĘP 1.1. PROBLEMATYKA I ZAKRES PRACY
1.1.2 zastosowanie
Systemy IPS mogą być wykorzystywane w następujących dziedzinach:
1. zarządzanie przestrzenią publiczną
(a) określanie poziomu ruchu w pomieszczeniach
(b) planowanie i monitorowanie wydarzeń publicznych
(c) usprawnianie systemów rezerwacji sal, zarządzania kolejkami pacjentów

itp.
2. nawigacja
(a) szukanie produktów w sklepach
(b) usprawnianie czynności związanych z magazynowaniem towarów
(c) odnajdywanie właściwych pomieszczeń w instytucjach publicznych
(d) oznaczanie elementów infrastruktury na wydarzeniach publicznych (toa-

lety, stoiska warsztatowe, itd.)
3. bezpieczeństwo
(a) weryfikacja miejsc zajmowanych przez gości np. w teatrze, kinie, na kon-
cercie
(b) planowanie ewakuacji
(c) rejestrowanie historii poruszania się po budynkach
1.1.3 hipoteza
Przedstawiony projekt ma na celu wprowadzenie zmodyfikowanego systemu oraz

algorytmu umożliwiającego lokalizację wewnątrzbudynkową bez użycia stałej, de-
dykowanej do tego celu infrastruktury. Zamiast tego, do wyznaczania lokalizacji
użyte zostaną wszelkie stacjonarne urządzenia emitujące sygnał Bluetooth (oraz po-
tencjalnie również WiFi) dostępne już wcześniej w monitorowanej przestrzeni oraz
urządzenia mobilne noszone przez osoby poruszające się w przestrzeni budynku. Za-
prezentowany algorytm ma również na celu minimalizację skutków użycia urządzeń
o różnej mocy sygnału i dokładności odbiornika.
3
1.2. CELE PRACY ROZDZIAŁ 1. WSTĘP
Dzięki temu rozwiązaniu powstanie eksperymentalny system o dokładności więk-

szej niż GPS (w pomieszczeniach zamkniętych), a także niewymagający wdrażania
i utrzymywania dedykowanej infrastruktury.
1.2 Cele pracy

1. Budowa prototypu systemu IPS:
(a) Implementacja oprogramowania do obsługi dynamicznej infrastruktury

dla urządzeń: Telefon komórkowy, Komputer stacjonarny, Laptop i Ra-
spberry Pi.
(b) opisanie i implementacja nowego algorytmu do wyznaczania lokalizacji

na podstawie obliczeń geometrycznych oraz operacji na grafach
(c) Przeprowadzenie eksperymentu w celu pomiaru dokładności badanego

systemu.
2. dodatkowe cele badawcze:
(a) Zapoznanie się z istniejącymi rozwiązaniami w dziedzinie IPS. Studium to

obejmuje analizę stosowanych urządzeń, infrastruktury oraz algorytmów.
Istotnym elementem jest zdefiniowanie ograniczeń i słabych punktów ist-
niejących rozwiązań.
(b) Analiza działania technologii BLE (Bluetooth Low Energy). Część ta

obejmuje zdobycie informacji koniecznych do implementacji oprogramo-
wania wykorzystującego tę technologię oraz wiedzy niezbędnej do stwo-
rzenia algorytmu lokalizującego przy użyciu urządzeń bluetooth.
1.3 Metoda Badawcza

1. Studia literatury zostały przeprowadzone na zasadzie reasearchu internetowe-
go, dotyczyły studium technologii bluetooth, analizy istniejących rozwiązań
IPS, oraz motywacji do wyboru odpowiednich narzędzi.
2. Analiza budowy i działania istniejących produktów została wykonana głów-

nie na podstawie studium prac dotyczących systemów z podziałem na metody
4
ROZDZIAŁ 1. WSTĘP 1.4. PRZEGLĄD LITERATURY W DZIEDZINIE
"Range Based" [1] oraz "Range Free" [2] (zwane także "Fingerprinting"), bę-
dących przekrojowym opisem powszechnie stosowanych systemów i technik
IPS.
3. Projektowanie i prototypowanie nowatorskich rozwiązań polegało na imple-

mentacji systemu TriBeacon zgodnie z zasadami inżynierii oprogramowania.
Skuteczność stworzonej implementacji została potem zweryfikowana na pod-
stawie eksperymentu oraz analizy wizualizacji systemu lokalizacji wewnątrz-
budynkowej.
4. Algorytm TriBeacon służący do wyznaczania lokalizacji na podstawie grafu

połączonych urządzeń został zaprojektowany jako heurystyka przy użyciu pod-
stawowych operacji geometrycznych oraz na grafach.
1.4 Przegląd literatury w dziedzinie

1. strony internetowe
Głównym źródłem informacji dotyczących systemów IPS oraz specyfikacji dzia-
łania protokołu bluetooth są treści internetowe. Zdecydowana większość z nich
dostępna jest w języku angielskim.
2. istniejące IPS
Co do samych IPS przeważająca część informacji to materiały reklamowe, pro-
mujące i zachęcające do zakupu gotowych już systemów. Inforamcje tego typu
trudno uznać za wiarygodne źródło informacji. Znaleziono jednak dwie prace
naukowe [2] [3] opisujące przekrojowo stosowane systemy IPS, obie pozycje w
języku angielskim.
3. protokół bluetooth
W studium technologii bluetooth wykorzystano oficjalną dokumentację biblio-
tek i narzędzi wykorzystanych w implementacji [4], z czego więkoszść urzymy-
wana jest zarówno w wersji angielskiej jak i polskiej.
4. narzędzia i technologie
Wybór narzędzi dokonany został na podstawie oficjalnych dokumentacji bi-
bliotek i frameworków [5] [6] [7] [8] [9] oraz dotychczasowych doświadczeń
5
1.5. UKŁAD PRACY ROZDZIAŁ 1. WSTĘP
zdobytych w czasie studiów inżynierskich podczas realizacji przedmiotów, np.

Aplikacje w Językach Interpretowanych — porównanie bibliotek Vue oraz Re-
act.
1.5 Układ pracy

Tematem pracy jest system lokalizacji wewnątrz budynkowej z dynamiczną infra-
strukturą bluetooth low energy.
1. Bieżący rozdział opisuje problematykę lokalizacji wewnątrzbudynkowej, za-

stosowania, motywację stworzenia alternatywnego systemu oraz główne cele
projektu.
2. Rozdział drugi przedstawia studium technologii lokalizacji oraz istniejących

rozwiązań IPS, z uwzględnieniem ich wad oraz ograniczeń.
3. Rozdział trzeci opisuje technologie, sprzęt, definicje i podstawowe kwestie teo-

retyczne wykorzystane w dalszej części projektu.
4. Rozdział czwarty opisuje system TriBeacon z uwzględnieniem wymagań funk-

cjonalnych, ograniczeń i opisem stworzonego algorytmu.
5. Rozdział piąty zawiera opis implementacji projektu.
6. Rozdział szósty zawiera opis oraz wyniki eksperymentu mającego na celu wy-
znaczenie dokładności zaproponowanego IPS
7. Rozdział siódmy zawiera dyskusję, oraz podsumowanie wszystkich aspektów

projektu.
Najważniejszym rezultatem projektu jest kompletna implementacja systemu Tri-

Beacon gotowego do wdrożenia i możliwego do porównania z istniejącymi już rozwią-
zaniami. Wykonany eksperyment potwierdza zdatność systemu do użytku. Końcowa
analiza podkreśla punkty wyróżniające projekt od istniejących rozwiązań IPS.
6
Rozdział 2
Podstawa Teoretyczna Systemów IPS
Rozdział opisuje podstawowe zagadnienia obowiązujące w dziedzinie systemów lo-

kalizacji wewnątrzbudynkowej, oraz przedstawia analizę istniejących do tej pory
systemów.
2.1 Podstawowe definicje

— GPS - (Global Positioning System) – system nawigacji satelitarnej, zaprojekto-
wany przez Departament Obrony Stanów Zjednoczonych, obejmuje zasięgiem
całą kulę ziemską. System składa się z trzech modułów: modułu kosmiczne-
go – 31 satelitów na średniej orbicie okołoziemskiej; segmentu naziemnego –
stacji kontrolnych i segmentu użytkownika – odbiorników sygnału. Zadaniem
systemu jest obliczanie lokalizacji użytkownika oraz ułatwienie nawigacji w
terenie.
— IPS - (Indoor Positioning System) - System nawigacji wewnątrzbudynkowej.

Systemów tego typu jest wiele i znacznie różnią się między sobą pod względem
technologii, dokładności i poziomu zaawansowania. Najczęściej obejmują loka-
lizowanie urządzeń we względnym układzie współrzędnych, niepołączonym z
systemem GPS.
— Bluetooth — standard krótkozasięgowej bezprzewodowej komunikacji
— BLE - (Bluetooth Low Energy) standard krótkozasięgowej bezprzewodowej

komunikacji o niższym użyciu energii i rozbudowany o możliwość kontroli mocy
7
2.1. DEFINICJE ROZDZIAŁ 2. IPS
transmitowanego sygnału.
— Wifi - (IEEE 802.11) - grupa standardów bezprzewodowych sieci lokalnych
— RSSI - (Received Signal Strength Indication) – wskaźnik mocy odbieranego

sygnału radiowego. Bez dodatkowych informacji nie może być wykorzystywa-
ny do określania lokalizacji czy odległości, ze względu na różne parametry
odbiorników i nadajników. Np. nadajnik o większej mocy będzie generował
sygnał o podobnym RSSI do urządzenia słabszego, jeżeli będzie znajdował się
w większej odległości.
— Tx-Power -(Transmit Power) oznacza moc wysyłania. W kontekście bezprze-

wodowej sieci komputerowej jest to parametr urządzenia (nie samego sygna-
łu), który określa moc, jaką powinien mieć nadawany sygnał. W przypadku
protokołu bluetooth określa on wartość RSSI w odległości jednego metra od
nadajnika.
— LQ - (Link Quality) to wskaźnik jakości połączenia w urządzeniach Bluetooth.
— Kotwica (Beacon) - to urządzenie emitujące i/lub nadające sygnał o stałej

lokalizacji, wykorzystywane jako punkt referencyjny do wyznaczania lokalizacji
innych urządzeń w systemie.
— access point — Urządzenie transmitujące sygnał bezprzewodowy w sieci Wifi,

ich liczba w sieci jest zależna od jakości sygnału, pokrywanej powierzchni itp.
— fingerprinting — metoda wyznaczania lokalizacji, polegająca na porównywaniu

podobieństwa skanów testowych do zbioru oznaczonych, wcześniej spreparo-
wanych skanów treningowych.
— skan BLE — operacja wykonywana przez urządzenie z modułem BLE polega-

jąca na okresowym nasłuchiwaniu i wykrywaniu dostępnych urządzeń BLE w
zasięgu.
— advertisement BLE — operacja wykonywana przez urządzenie z modułem BLE

polegająca na okresowym wysyłaniu sygnału z informacjami o urządzeniu,
urządzenia z aktywnym advertisementem są możliwe do wykrycia w czasie
skanu BLE.
8
ROZDZIAŁ 2. IPS 2.2. ROZWIĄZANIA
2.2 Istniejące rozwiązania w dziedzinie
2.2.1 GPS
GPS jest oparty o połączenie satelitarne o średniej dokładności 5 metrów [10], jed-
nak błąd pomiarowy wzrasta w pomieszczeniach zamkniętych. Ze względu na zróż-
nicowaną strukturę budynków może osiągać wartości zbliżone do rozmiaru całej
budowli. Jest to dokładność uniemożliwiająca wykorzystanie GPS dla większości
systemów wykorzystujących lokalizację wewnątrzbudynkową. Pomijając jednak ten
aspekt, GPS jest najczęściej stosowaną w praktyce metodą lokalizacji, stosowaną
w nieprzerwanie od wielu lat na masową skalę w nawigacji samochodowej i pieszej,
transporcie, tworzeniu map, technologiach wojskowych itd. W większości tego ty-
pu zastosowań przybliżona dokładność 5 metrów jest w zupełności wystarczająca.
W pewnych szczególnych przypadkach, takich jak technologie wojskowe stosowany
jest GPS o większej dokładności, dochodzącej nawet do kilku centymetrów. Jest to
jednak rozwiązanie niestosowane komercyjnie ze względu na wysokie koszty oraz
ekskluzywny charakter infrastruktury GPS.
2.2.2 IPS
IPS jest zagadnieniem odrębnym od częściej stosowanego GPS ze względu na ogra-

niczenia jego stosowania wewnątrz budynków. IPS ze względu na niektóre zastoso-
wania wymaga różnorakiej dokładności — od określenia pomieszczenia — do nawet
0,1 metra. Systemy te są tworzone w oparciu o zróżnicowane technologie:
1. Wifi
2. Bluetooth
3. Kamery cyfrowe — urządzenia rejestrujące obrazy
4. Inne eksperymentalne lub rzadko stosowane protokoły komunikacji bezprze-

wodowej
(a) Li-Fi - technologia komunikacji przy użyciu światła widzialnego
(b) UWB (ultra wideband) - technika komunikacji bezprzewodowej o szero-

kim widmie emisji
9
2.2. ROZWIĄZANIA ROZDZIAŁ 2. IPS
(c) RFID - (Radio-frequency identification) - systemy zdalnej identyfikacji ra-

diowej, wykorzystywane np. w identyfikatorach personalnych, NFC (Near
Field Communication) w telefonach itp.
2.2.3 Algorytmy range-based
Algorytmy tego typu [1] polegają na wyznaczaniu lokalizacji przy użyciu pewnych
parametrów sygnału Bluetooth lub WiFi. Najczęściej stosowane parametry: RSSI,
pomiar kąta, Tx-Power, LQ. Głównym założeniem jest obliczenie pozycji urządze-
nia przy pomocy obliczeń np. trygonometrycznych uwzględniających odległości lub
kąty między odbiornikiem a nadajnikiem. Rozwiązania tego typu ściśle polegają na
parametrach transmitowanego sygnału, tak więc wymagają stosowania jednakowych
sensorów o odpowiednim poziomie zaawansowania. Np. Bluetooth 4.0 zainstalowany
w większości telefonów starszych niż 3 lata, nie obsługuje opcji takich jak Tx-power
control czy pomiar kąta między urządzeniami.
2.2.4 Algorytmy range-free
Algorytmy te stosują tak zwany fingerprinting [2], a więc metodę wyznaczania lo-
kalizacji przy pomocy wcześniej przeprowadzonych pomiarów treningowych. W tego
typu systemach również obecna jest stała sieć kotwic, jednak nie wymaga ona jed-
nolitości stosowanych urządzeń czy mocy sygnału. W algorytmach range-free po
zainstalowaniu infrastruktury przeprowadza się serię pomiarów, w których zaznacza
się rzeczywistą lokalizację urządzenia zaraz po wykonaniu skanu przez odbiornik. Te
pomiary, wraz z przyporządkowaną im lokalizacją są zwane zbiorem treningowym.
Po zakończeniu tej fazy cały zbiór treningowy trafia do bazy danych. Wyznaczanie
lokalizacji odbywa się na zasadzie przyporządkowania najbardziej podobnego skanu
ze zbioru treningowego.
10
ROZDZIAŁ 2. IPS 2.3. WADY
2.3 Wady i słabe punkty istniejących rozwiązań

1. GPS
(a) wysoki błąd pomiarowy (5 metrów)
(b) zakłócenia sygnału wewnątrz budynków
2. WiFi
(a) konieczność stałego połączenia z siecią, wymaga akcji użytkownika
(b) ograniczona liczba access pointów, zazwyczaj około 1 / 50 metrów kwa-

dratowych
3. niestandardowe lub rzadko wykorzystywane protokoły komunikacji, Kamery,

Lifi, RFID/NFC, ultra wideband itd. - brak ustandaryzowanego protokołu
lub dostępności wykorzystywanych technologii. Wysokie koszty pontencjalne-
go wdrożenia. Brak możliwości wykorzystania istniejącej infrastruktury czy
urządzeń pomiarowych. Rozwiązania tego typu są zdecydowanie mniej po-
pularne niż bluetooth czy Wifi. Niemal każdy telefon, zegarek czy komputer
posiada odbiornik i nadajnik bluetooth, natomiast np. Lifi jest dostępne tylko
w specjalnych, dedykowanych urządzeniach niemal niespotykanych do tej pory
w komercyjnych systemach.
4. Algorytmy range-based
(a) konieczność montażu stałej infrastruktury, np. 4 kotwice bluetooth na

każde pomieszczenie.
(b) utrzymywanie istniejącej infrastruktury, wymiana baterii, konserwacja,

kalibrowanie itd.
(c) Stosowanie urządzeń z zaawansowanymi odbiornikami/nadajnikami, np.

bluetooh 5.0 / 6.0, udostępniających dodatkowe parametry sygnału, jed-
nak zdecydowanie droższych i mniej popularnych od wcześniejszych wer-
sji.
(d) Uzależnianie błędu pomiaru od jakości odbiornika, np. lokalizowanie róż-

nych modeli telefonów może prowadzić do większego błędu pomiarowego.
11
2.3. WADY ROZDZIAŁ 2. IPS
(e) budowa infrastruktury dedykowanej dla monitorowanej przestrzeni, ko-

nieczonść umieszczania kotwic np. w narożnikach pomieszczeń, zapew-
nieni odpowiedniego zagęszczenia urządzeń.
5. Algorytmy range-free
(a) konieczność montażu stałej infrastruktury, np. 4 kotwice bluetooth na

każde pomieszczenie.
(b) utrzymywanie istniejącej infrastruktury, wymiana baterii, konserwacja
(c) czasochłonne przygotowanie bazy danych treningowych i konieczność po-

wtarzania pomiarów w przypadku np. montażu nowych kotwic, zmiany
układu pomieszczeń czy parametrów urządzeń.
12
Rozdział 3
Opis Technologii
Rozdział przedstawia terminologię w systemie TriBeacon, opis i uzasadnienie użycia

wykorzystanych narzędzi oraz podstawowy opis zaprojektowanych programów.
3.1 Definicje
— typy urządzeń z podziałem ze względu na zastosowanie
– Użytkownik — dowolne urządzenie (aktywne lub bierne) emitujące sy-

gnał, o nieznanej lokalizacji.
– Kotwica — dowolne urządzenie (aktywne lub bierne) o tymczasowo lub

stale określonej lokalizacji.
— typy urządzeń z podziałem ze względu na możliwości sprzętowe
– Urządzenie bierne — urządzenie możliwe do wykrycia w systemie Tri-

Beacon, ale nieposiadające dedykowanego oprogramowania. Jest wykry-
wane, jeżeli znajduje się w zasięgu urządzenia aktywnego oraz posiada
aktywny advertisement BLE.
– Urządzenie aktywne — urządzenie z zainstalowanym oprogramowaniem

TriBeacon i stałym połączeniem z serwerem. Cyklicznie wykrywa ono
wszystkie (aktywne/bierne oraz użytkowników/kotwice) urządzenia w za-
sięgu i wysyła informacje o połączeniu do serwera.
13
3.2. SPRZĘT ROZDZIAŁ 3. OPIS TECHNOLOGII
— Serwer — urządzenie z aplikacją TriBeacon serwer, przechowujące dane o sta-

nie wszystkich pozostałych urządzeń w sieci oraz obliczające lokalizację.
3.2 Sprzęt
1. Telefon Komórkowy
Urządzenie wykorzystywane jako aktywna kotwica, aktywny użytkownik oraz
narzędzie do przeprowadzania pomiarów. Wymagania sprzętowe:
— Android >= 7.0
— moduł bluetooth >= 4.0
— połączenie z internetem
2. Raspberry Pi Zero W
Urządzenie wykorzystywane jako aktywna kotwica, Zostało wykorzystane ze
względu na dostępność urzdądzeń tego modelu w laboratorium Instytutu In-
formatyki. (50 - metrowy przewód ethernetowy z rozmieszczonymi co około 7
metrów Raspberry pi)
— system Raspbian
— połączenie Ethernetowe
— moduł bluetooth >= 4.0
3. Inne urządzenia, wykorzystywane jako bierna kotwica lub bierny użytkownik
— zegarek z modułem bluetooth low energy
— słuchawki bezprzewodowe bluetooth
— lokalizator do kluczy
4. Platforma usług chmurowych Heroku — Środowisko uruchomieniowe do apli-

kacji serwerowej wykonującej obliczenia, zbierającej oraz utrwalającej na dysku
informacje odebrane od urządzeń w budynku.
— JVM >= 1.8.0
— dostęp do internetu
14
ROZDZIAŁ 3. OPIS TECHNOLOGII 3.3. OPROGRAMOWANIE
3.3 Oprogramowanie
3.3.1 aplikacje użytkownika
Nowymi rozwiązaniami zastosowanymi w projekcie były rezygnacja ze stałej, re-

gularnej infrastruktury oraz włączenie do sieci urządzeń biernych, a więc nieposia-
dających dedykowanego oprogramowania. Są to główne cele, na które został poło-
żony nacisk w trakcie implementacji. Dodatkowym kryterium była uniwersalność
implementacji, a więc pokrycie jak największej liczby różnych typów urządzeń przy
użyciu jak najmniejszej liczby implementowanych programów. Aplikacje przeglą-
darkowe czy też natywne zostały odrzucone po stronie klienta ze względu na brak
wystarczającej możliwości sterowania modułami BLE na urządzeniach. Ostatecznie
podjęto decyzję o zaimplementowaniu dwóch programów: aplikacji na system an-
droid (około 72% rynku telefonów komórkowych) [11] oraz skryptu na komputery
stacjonarne i laptopy (bash + python). W przypadku wdrożenia konieczne byłoby
również zaimplementowanie aplikacji klienta na system windows, jednak ze wzglę-
du na wysoką dostępność urządzeń z systemami operacyjnymi Linux w warunkach
testowych (komputer stacjonarny, laptop, Raspberry Pi) wykonano skrypt bash-owy.
Obie aplikacje użytkownika mają na celu zapewnić wykrywalność urządzenia

(bluetooth advertisement) oraz skany bluetooth (bluetooth scan) w stałych interwa-
łach czasowych.
3.3.2 aplikacje administracyjne
Głównym zadaniem aplikacji serwerowej jest obliczanie i zarządzanie lokalizacją w

czasie rzeczywistym oraz obsługa asynchronicznych połączeń z wieloma aplikacjami
użytkowników. Istotna jest również konieczność zapewnienia tranzakcyjności aktu-
alizacji przesyłanych przez aplikacje użytkowników. Po analizie powyższych wyma-
gań zdecydowano, iż najodpowiedniejsza będzie implementacja aplikacji serwerowej
z REST API, komunikującej się z aplikacjami użytkowników przy użyciu protokołu
HTTP.
15
3.4. TECHNOLOGIE ROZDZIAŁ 3. OPIS TECHNOLOGII
3.3.3 lista programów
1. TriBeacon Backend - Aplikacja Serwerowa napisana w języku Java, służąca

do zbierania informacji od aplikacji klienckich oraz wykonywania obliczeń. Ze
względu na ograniczenia darmowego serwisu Heroku została napisana w wersji
Java 1.8.0 LTS. Posiada ona REST API umożliwiające komunikację z pozo-
stałymi urządzeniami w sieci. Połączenie odbywa się przez internet, tak więc
nie ma wymagań dotyczących lokalizacji serwera. Zawiera implementację al-
gorytmu wyznaczającego lokalizację oraz logikę związaną z aktualizowaniem
i przechowywaniem grafu połączeń na podstawie aktualizacji odbieranych od
aplikacji klienckich.
2. TriBeacon Frontend - Aplikacja przeglądarkowa służąca do wizualizacji loka-

lizacji urządzeń oraz do zarządzania pozycją kotwic. Napisana w języku Java-
Script przy użyciu biblioteki React.
3. TriBeacon Android - Aplikacja na telefon komórkowy, napisana w Języku Java,

umożliwiająca wykorzystanie telefonu jako aktywnego urządzenia w systemie
TriBeacon.
4. TriBeacon Linux - Skrypt bashowy i pythonowy umożliwiający wykorzystanie

Raspberry pi, komputera stacjonarnego lub laptopa jako aktywnego urządzenia
w systemie TriBeacon.
3.4 Technologie i metodologie programistyczne
3.4.1 Języki programowania
1. Java [12]
Obiektowy język programowania wysokiego poziomu, stworzony przez Jamesa
Goslinga i jego zespół w Sun Microsystems (obecnie należy do Oracle Cor-
poration) w latach 90. Java jest jednym z najbardziej popularnych języków
programowania na świecie, a jego główną zaletą jest to, że jest platformą nie-
zależną, co oznacza, że kod napisany w języku Java może być uruchamiany
na każdym urządzeniu, które posiada JVM (Java Virtual Machine). Java, ze
16
ROZDZIAŁ 3. OPIS TECHNOLOGII 3.4. TECHNOLOGIE
względu na swoją popularność posiada wiele bibliotek i narzędzi, które umoż-

liwiają łatwe i szybkie tworzenie aplikacji. W prezentowanym projekcie java
została wykorzystana do aplikacji serwerowej oraz do aplikacji na telefony mo-
bilne.
2. JavaScript [13]
Interpretowany, dynamiczny język programowania, stworzony w latach 90.
przez Brendan Eich dla firmy Netscape. Jest językiem skryptowym, co ozna-
cza, że jego kod jest wykonywany przez przeglądarkę internetową. JavaScript
jest głównym językiem stosowanym do tworzenia interaktywnych elementów
na stronach internetowych, takich jak formularze i animacje. JavaScript jest
również używany poza przeglądarkami, np. jako język do tworzenia aplikacji
serwerowych (Node.js) oraz aplikacji desktopowych i mobilnych. JavaScript
jest jednym z najważniejszych języków programowania na świecie i jest wciąż
intensywnie rozwijany. W projekcie został wykorzystany do stworzenia inter-
fejsu użytkownika dla administratora. Dostępność bibliotek z gotowymi, gra-
ficznymi komponentami (takimi jak react bootstrap) pozwoliło na stworzenie
przyjaznego interfejsu użytkownika przy niewielkim nakładzie czasu.
3. Bash [14]
Bourne Again Shell jest powłoką, czyli interpreterem poleceń, dla systemów
operacyjnych z rodziny Unix. Jest to jedena z najbardziej popularnych powłok i
jest standardowo dostarczana z większością dystrybucji Linuksa. Bash umożli-
wia użytkownikom interakcję z systemem operacyjnym poprzez wprowadzanie
poleceń w linii poleceń. Jest również językiem skryptowym, co oznacza, że użyt-
kownik może napisać serię poleceń, które zostaną automatycznie wykonane, co
umożliwia automatyzację czynności i ułatwia zarządzanie systemem operacyj-
nym. Bash oferuje wiele funkcji, takich jak wsparcie dla regularnych wyrażeń,
przekierowywanie wejścia/wyjścia, programowanie funkcji i pętli. Został wy-
korzystany w celu napisania skryptu zastępującego aplikację użytkownika w
komputerach stacjonarnych, raspberry pi i laptopach posiadających system li-
nux. Uniwersalna składnia basha pozwoliła stworzyć skrypt uruchamialny na
wielu różnych systemach operacyjnych, w przypadku urządzeń wykorzystanych
w projekcie były to: Fedora 34, Ubuntu 18 oraz Raspbian.
17
4. Python [15]
Dynamiczny, wysokopoziomowy język programowania o otwartym kodzie źró-
dłowym, stworzony w latach 80. przez Guido van Rossum. Python jest jednym
z najbardziej popularnych języków programowania na świecie ze względu na
swoją czytelność i prostotę składni. Python jest często używany do tworzenia
aplikacji webowych, analizy danych, aplikacji scientific computing, automaty-
zacji i itp. Python posiada bogate biblioteki i narzędzia, które umożliwiają
łatwe i szybkie tworzenie aplikacji. Python jest również językiem, który jest
łatwy do nauki dla początkujących programistów, dlatego jest często wykorzy-
stywany jako pierwszy język programowania. W projekcie został wykorzystany
ze względu na dostępność prostych w użyciu bibliotek do obsługi protokołu blu-
etooth na komputerach stacjonarnych. Skrypt pythonowy razem ze skryptem
bashowym uruchomione równocześnie na komputerze są w stanie odtworzyć
wszystkie funkcjonalności androidowej aplikacji klienta.
3.4.2 Biblioteki
1. LocationTech JTS [7]

Java Topology Suite jest biblioteką typu open source napisaną w języku Java,
zapewniającą narzędzia do przetwarzania i analizy geometrii. JTS jest częścią
projektu LocationTech, który jest inicjatywą prowadzoną przez Fundację Ec-
lipse. JTS zapewnia wsparcie dla wielu typów geometrii, takich jak punkty,
linie, łuki i wielokąty, oraz umożliwia wykonywanie różnych operacji na tych
geometriach, takich jak znajdowanie najbliższego sąsiada, znajdowanie nakła-
dających się geometrii, itp. Biblioteka JTS jest używana przez wiele aplikacji
GIS (Geographic Information System) i aplikacji webowych, które wymagają
wsparcia dla geometrii i operacji na geometriach.
Oprogramowanie jest dostępne na licencji Eclipse Public License 2.0, zezwala-

jące na komercyjne i naukowe wykorzystanie. [16]
Wykorzystanie tej biblioteki umożliwiło prostą implementację geometrycznego

algorytmu wyznaczania lokalizacji, bazującego w dużej mierze na dodawaniu
i odejmowaniu płaszczyzn dwuwymiarowych.
18
2. React [8]
Biblioteka JavaScript, stworzona przez firmę Facebook, umożliwiająca tworze-
nie dynamicznych aplikacji przeglądarkowych. React pozwala programistom
na budowanie interfejsu użytkownika za pomocą komponentów, które są nie-
zależne i łatwe do utrzymania. React wykorzystuje koncepcję Virtual DOM,
która pozwala na szybką aktualizację interfejsu użytkownika bez konieczno-
ści przeładowywania całej strony. Dzięki temu aplikacje napisane w React są
szybkie i wydajne.
Oprogramowanie jest dostępne na licencji MIT, zezwalającej na komercyjne i

naukowe wykorzystanie [17].
Biblioteka react została wykrzystana do stworzenia nowoczesnego i prostego

w utrzymaniu interfejsu użytkownika.
3. React Bootstrap [9]

Biblioteka, która pozwala na korzystanie z komponentów Bootstrapa za pomo-
cą React. Bootstrap to popularny framework front-end, który zapewnia gotowe
stylizacje i komponenty, takie jak nawigacja, formularze, tabele i przyciski.
Oprogramowanie jest dostępne na licencji MIT, zezwalającej na komercyjne i

naukowe wykorzystanie. [18].
W projekcie został użyty w celu minimalizacji czasu implementacji interfej-

su użytkownika oraz w celu zapewnienia jego przejrzystości i nowoczesnego
wyglądu.
4. Spring Boot [9]

Framework Java opracowany przez firmę Pivotal, który umożliwia łatwe i
szybkie tworzenie aplikacji opartych na Spring Framework. Spring to popu-
larny framework Java, który umożliwia tworzenie aplikacji biznesowych i we-
bowych.Spring Boot pozwala na automatyzację wielu kroków potrzebnych do
tworzenia aplikacji, takich jak konfiguracja, uruchamianie i uruchamianie te-
stów. Spring Boot również zapewnia wiele gotowych komponentów, takich jak
REST API, bazy danych i narzędzia do monitorowania i zarządzania aplikacja-
mi. Dzięki temu programiści nie muszą pisać od podstaw tych komponentów,
19
co pozwala im na skupienie się na tworzeniu wartościowych funkcjonalności

dla aplikacji.
Oprogramowanie dostępne jest na licencji Apache, zezwalającej na komercyjne

i naukowe wykorzystanie [18].
Framework ten został wykorzystany w celu stworzenia aplikacji serwerowej,

wystawiającej REST API. Dzięki zastosowaniu Spring Boot implementacja
zawiera jedynie kod związany z logiką systemu, natomiast do minimum ogra-
niczone zostały wszelkie kwestie związane z projektowaniem samej aplikacji
serwerowej.
5. Java Android SDK (software development kit) [4]

Narzędzie umożliwiające tworzenie aplikacji na system operacyjny Android.
Jest to zestaw bibliotek, które udostępniają programistom interfejs API do
systemu Android. SDK zawiera również emulator, dzięki któremu można testo-
wać aplikacje bez konieczności posiadania fizycznego urządzenia z systemem
Android. SDK jest dostarczane przez firmę Google, która jest twórcą tegoż
systemu operacyjnego.
Dostępny jest na licencji firmy Google, zezwalającej na korzystanie z oprogra-

mowania w celach komercyjnych i naukowych [19].
Android SDK jest dostępne w języku Java lub Kotlin. Dla spójności i ograni-
czenia liczby wykorzystanych technologii wykorzystano język java i przy jego
pomocy stworzono aplikację dla klienta na telefon komórkowy, niezbędnej w
systemie TriBeacon.
3.4.3 Architektura
1. REST API
ReprEsentational State Transfer API to architektura sieci Web i styl projek-

towania interfejsów API, które pozwala na komunikację pomiędzy różnymi
systemami i aplikacjami. REST API opiera się na protokole HTTP (Hipertext
Transfer Protocol) i używa standardowych metod, takich jak GET, POST,
PUT i DELETE, do wykonywania operacji na zasobach. Zasoby te są iden-
tyfikowane przez unikalne URI (Uniform Resource Identifier) i są reprezento-
20
wane w formie danych, takich jak JSON lub XML. REST API jest prostym
i elastycznym sposobem na integrację różnych systemów i aplikacji, a jego
popularność wynika z łatwości implementacji i wszechstronności.
2. Programowanie Obiektowe
Paradygmat programowania, w którym aplikacje są tworzone jako zestaw obiek-

tów, każdy, z których reprezentuje określony aspekt problemu lub jego część.
Każdy obiekt posiada swoje właściwości (zmienne) i metody (funkcje), któ-
re opisują jego zachowanie. Programowanie obiektowe pozwala na modułowe
i złożone tworzenie aplikacji, a także ułatwia utrzymanie i rozwijanie kodu.
Wszystkie aplikacje będące częścią niniejszego projektu są napisane zgodnie z
paradygmatem programowania obiektowego.
21
Rozdział 4
Opis Projektu Tribeacon
Rozdział przedstawia analizę wymagań i możliwości prezentowanego systemu IPS

oraz wysokopoziomowy opis algorytmu i architektury.
4.1 Analiza wymagań
Poniżej przedstawiono studium możliwości projektu na bazie analizy istniejących

rozwiązań oraz wymagania funkcjonalne poszczególnych modułów systemu TriBe-
acon.
4.1.1 studium możliwości
dynamiczne kotwice
Podstawową przewagą proponowanego rozwiązania nad istniejącymi jest brak ko-

nieczności instalowania stałej infrastruktury. Zamiast tego wykorzystuje się istnieją-
ce urządzenia, komputery stacjonarne, access pointy, sprzęt RTV i AGD (np. telwi-
zory, ekspresy do kawy, głośniki bezprzewodowe itp.). W przypadku potencjalnego
wdrożenia system TriBeacon będzie atrakcyjny dla klientów ze względu na niemal
zerowe koszty montażu i brak konieczności utrzymania.
Z drugiej jednak strony błąd pomiarowy systemu rośnie wraz ze zmniejszającym
się zagęszczeniem urządzeń, tak więc w przypadku budynków o małej liczbie do-
stępnych urządzeń (np. mniej niż jedno urządzenie BLE na pomieszczenie) system
TriBeacon będzie nieefektywny.
22
ROZDZIAŁ 4. OPIS PROJEKTU 4.1. ANALIZA WYMAGAŃ
zagęszczenie użytkowników
Algorytm TriBeacon umożliwia również zwiększanie dokładności lokalizacji przy po-

mocy wzajemnych połączeń użytkowników. Wykorzystany w trakcie wydarzeń pu-
blicznych, gdzie zagęszczenie użytkowników jest większe niż 1 osoba na kilka metrów
kwadratowych, możliwe jest wyznaczanie lokalizacji urządzeń przy minimalnej licz-
bie kotwic. Potencjalnie wykryci zostaną nawet użytkownicy niebędący w zasięgu
żadnej kotwicy.
Pomimo iż funkcjonalność ta została zaimplementowana, trudno ocenić korzy-
ści z niej wynikające, ponieważ nie wykonano eksperymentów potwierdzających jej
skuteczność. Ich brak jest spowodowany wysokim kosztem przedsięwzięcia — do
pomiarów należałoby zaangażować kilkadziesiąt lub nawet kilkaset osób.
podstawy prawne
Ewentualną prawną podstawą do podważenia legalności projektowanego systemu

jest artykuł 267 kodeksu karnego:
"Kto bez uprawnienia uzyskuje dostęp do informacji dla niego nieprzeznaczonej,
otwierając zamknięte pismo, podłączając się do sieci telekomunikacyjnej lub przeła-
mując albo omijając elektroniczne, magnetyczne, informatyczne lub inne szczególne
jej zabezpieczenie, podlega grzywnie, karze ograniczenia wolności albo pozbawienia
wolności do lat 2."
Po przeprowadzeniu wstępnych konsultacji prawniczych stwierdzono, że stoso-
wanie systemu TriBeacon nie stwarza podstaw do naruszenia powyższego artykułu,
ponieważ podczas lokalizowania urządzeń biernych nie następuje łamanie zabezpie-
czeń ani połączenie z siecią telekomunikacyjną a informacje odbierane od urządzeń
(bluetooth advertisment) są publiczne i nieszyfrowane. Każda osoba znajdująca się
w obszarze działania systemu IPS może również nie wyrazić zgody na lokalizowanie
poprzez wyłączenie opcji bluetooth advertisement w posiadanych urządzeniach.
dokładność pomiarowa
Ze względu na większość analizowanych przypadków wykorzystania lokalizacji we-

wnątrzbudynkowej zdecydowano się na założenie docelowej dokładności wynoszącej
3 metry, jako że wartość ta najczęściej pozwala poprawnie określić pomieszczenie,
23
4.1. ANALIZA WYMAGAŃ ROZDZIAŁ 4. OPIS PROJEKTU
w którym znajduje się lokalizowane urządzenie.
4.1.2 wymagania funkcjonalne
1. aplikacja użytkownika (Linux)
(a) urządzenie jest stale możliwe do wykrycia
(b) urządzenie cyklicznie aktualizuje informacje o wykrytych urządzeniach w

pobliżu
2. aplikacja użytkownika (Android)
(a) urządzenie jest stale możliwe do wykrycia
(b) urządzenie cyklicznie aktualizuje informacje o wykrytych urządzeniach w

pobliżu
(c) * użytkownik ma możliwość raportowania swojej rzeczywistej lokalizacji

poprzez wskazanie jej na mapie.
3. aplikacja serwerowa
(a) aplikacja przechowuje aktualny stan połączeń wszystkich raportujących

urządzeń
(b) na żądanie administratora aplikacja aktualizuje pozycje kotwic
(c) na żądanie administratora aplikacja wyznacza estymowane lokalizacje

wszystkich użytkowników
(d) * aplikacja przechowuje historię wszystkich stanów sieci z ostatniej go-

dziny
(e) * aplikacja przechowuje historię wszystkich raportów rzeczywistej lokali-

zacji z ostatniej godziny
(f) * na żądanie użytkownika aplikacja wylicza błędy pomiarowe dla każdego

raportu rzeczywistej lokalizacji.
4. interfejs użytkownika (administracyjny)
(a) administrator ma możliwość definiowania, które urządzenia uznawane są

za kotwice oraz dynamicznego modyfikowania ich pozycji na mapie
24
ROZDZIAŁ 4. OPIS PROJEKTU 4.1. ANALIZA WYMAGAŃ
(b) administrator ma możliwość wizualizacji estymowanej lokalizacji użyt-

kowników na mapie
*funkcjonalność dodana na potrzebę eksperymentów, w celu pomiaru jakości wy-

znaczanej lokalizacji.
4.1.3 ograniczenia projektu
1. pomiar błędu
Podstawowym celem projektu było zaimplementowanie prototypu systemu

IPS. Eksperymenty służące wyznaczeniu błędu pomiarowego zostały prze-
prowadzone jedynie w podstawowej formie, brakuje również bezpośredniego
porównania z alternatywnym, wdrożonym systemem IPS. Badania tego typu
są niezbędne przed jakimkolwiek praktycznym zastosowaniem systemu TriBe-
acon, jednak ze względu na ich złożoność i wysoki koszt przedsięwzięcia nie
zostały one rozwinięte w tej pracy.
2. różnica mocy sygnału
W projekcie dla uproszczenia przyjęto założenie o istnieniu uśrednionego mini-

malnego i maksymalnego zasięgu sygnału BLE dla wszystkich urządzeń. Ozna-
cza to, że wykorzystanie urządzeń o skrajnie różniącej się mocy sygnału może
spowodować drastyczny spadek jakości wyznaczanej lokalizacji.
3. częstotliwość skanu bluetooth
Ograniczeniem sprzętowym technologii bluetooth jest częstotliwość skanu oraz

advertismentu. W praktyce wykonywanie skanu w interwałach krótszych niż
10 sekund prowadzi do niepełnych lub całkowicie niepoprawnych pomiarów. W
niektórych przypadkach użycia taka częstotliwość odświeżania lokalizacji może
być niewystarczająca. W istniejącym systemie wartość tę można modyfikować
przede wszystkim poprzez zwiększanie liczby urządzeń w sieci (np. 10 urządzeń
wykonujących asynchroniczne aktualizacje sieci w 10-sekundowych interwałach
oznacza w praktyce średnio 1-sekundowe aktualizacje lokalizacji)
25
4.2. ALGORYTM ROZDZIAŁ 4. OPIS PROJEKTU
Rysunek 4.1: Diagram wizualizujący wejściowe i wyjściowe dane algorytmu.
4.2 Algorytm
W poniższej sekcji opisano zasadę działania algorytmu do wyznaczania lokalizacji
zaimplementowanego w ramach projektu TriBeacon.
4.2.1 źródło danych
Źródłem danych do algorytmu jest odświeżana w czasie rzeczywistym baza danych

urządzeń oraz połączeń między nimi. Estymowana pozycja użytkowników może być
wyliczona w dowolnym momencie na żądanie administratora. Do obliczeń używany
jest pełny stan sieci, a więc dane o każdym urządzeniu, które zostało zarejestrowane
podczas działania programu. Na wyjściu algorytm zwraca również pełny obraz sieci,
a więc estymowane pozycje dla każdego urządzenia w systemie, jednak odfiltrowane
zostają kotwice (ich pozycje są już znane), oraz urządzenia, których pozycji nie da
się wyznaczyć (np. ze względu na brak połączeń).
4.2.2 struktura danych
Ze względu na brak wymagań funkcjonalnych dotyczących trwałego zapisu danych

zdecydowano na wykorzystanie repozytorium danych w pamięci ulotnej. Po restar-
cie systemu wszystkie dane zostają utracone. W bazie przechowywana jest lista
urządzeń w postaci mapy, unikalnymi kluczami są nazwy bluetlooth urządzenia (W
przypadku komeracjalizacji systemu należałoby uwzględnić również adresy MAC lub
IP w celu uniknięcia duplikatów w nazwach urządzeń, np. w przypadku gdy dwaj
użytkownicy posiadają ten sam model telefonu).
26
ROZDZIAŁ 4. OPIS PROJEKTU 4.2. ALGORYTM
Rysunek 4.2: Diagram przedstawiający strukturę danych połączeń.
Każde urządzenie posiada listę linków do innych urządzeń z bazy. Połączenia

posiadają również znaczniki czasu, informujące o ostatniej aktualizacji połączenia.
W trakcie działania programu zakłada się, iż połączenia są zawsze dwukierunkowe.
Oznacza to, że aktualizacja połączenia któregokolwiek z urządzeń odnawia rów-
nież połączenie drugiego użytkownika. Połączenia są automatycznie zamykane jeżeli
nie zostaną odnowione w ciągu 10 sekund. Zgodnie z powyższym modelem nie ma
możliwości, aby połączenie dwóch urządzeń było zapisane tylko w danych jednego
użytkownika.
Urządzenia mogą zostać dodane do bazy na dwa sposoby:
1. do serwera przysłana zostanie aktualizacja z nazwą nowego urządzenia oraz

listą dostępnych połączeń — w takim wypadku urządzenie jest dodane do
bazy razem ze wszystkimi połączeniami oraz dodatkowo zostaje oznaczone
jako aktywne
2. do serwera przysłana zostanie aktualizacja urządzenia a w liście połączeń obec-

ne są nazwy urządzeń niezapisanych do tej pory w bazie danych. w takim wy-
padku podczas aktualizacji listy połączeń dodane zostaną wszystkie brakujące
urządzenia. Urządzenia dodane w ten sposób oznaczone są jako bierne.
27
4.2.3 wyznaczanie pozycji
Wyznaczanie estymowanych pozycji użytkowników odbywa się na żądanie admini-

stratora i może zostać również obliczone dla danych archiwalnych. Wynikiem obli-
czeń dla jednego urządzenia jest dwuwymiarowy obszar, w którym urządzenie powin-
no się znajdować. Za estymowaną lokalizację uznano środek wyznaczonego obszaru.
Wyznaczanie obszaru dla urządzenia składa się z trzech kroków:
1. wyznaczanie obszaru zasięgiem kotwic i użytkowników
2. redukcja obszaru zasięgiem kotwic
3. redukcja obszaru zasięgiem użytkowników
28
zasięg kotwic i użytkowników
Za podstawowy obszar, w którym urządzenie się znajduje, uznano część wspólną

maksymalnego zasięgu wszystkich kotwic, z którymi urządzenie jest połączone. Tak
więc jeżeli założymy np. maksymalny zasięg urządzeń bluetooth 10 metrów, a pe-
wien telefon znajduje się w zasięgu dwóch kotwic, których lokalizację znamy, można
uznać, iż telefon znajduje się w części wspólnej kół o promieniu 10 m ze środkami o
pozycjach kotwic.
Powyższy przykład sprawdza się jednak jedynie w przypadku urządzeń znajdują-
cych się bezpośrednio w zasięgu kotwic. Załóżmy więc przypadek, w którym telefon
użytkownika u0 znajduje się w zasięgu urządzenia u1, ale nie jest w zasięgu żadnej
kotwicy. Użytkownik u1 natomiast jest wykrywany przez kotwicę b2. Na podsta-
wie analizy geometrycznej zauważono, że w takiej sytuacji urządzenie użytkownika
u1 znajduje się w odległości dwóch maksymalnych zasięgów sygnału bluetooth od
kotwicy b2. Analogicznie sytuacja przedstawia się w przypadku urządzeń połączo-
nych z kotwicą przechodnio przez n innych użytkowników — maksymalna odległość
urządzenia od kotwicy wynosi n maksymalnych zasięgów bluetooth.
W ten sposób wyznaczyć można obszary będące częścią wspólną kół o promie-
niach określonych przez bezpośrednie lub pośrednie połączenia ze wszystkimi ko-
twicami w systemie. W tym celu został wykorzystany algorytm BFS (Breath First
Search), pozwalający wykrywać nakrótsze ścieżki w grafach, jednak został on zmo-
dyfikowany w ten sposób, iż znajduje ścieżki (wraz z ich długościami) do wszystkich
kotwic w systemie, nie ograniczając wyniku jedynie do najbliższej połączonej kotwi-
cy.
29
Rysunek 4.3: Diagram przedstawiający geometryczną wizualizację pośrednich i

bezpośrednich połączeń między użytkownikami, dla przykładu: kotwica b4 jest
bezpośrednio połączona z użytkownikiem u6 oraz pośrednio z u5 (przez połączenie
z użytkownikiem u6).
Rysunek 4.4: Diagram przedstawiający części wspólne obszarów zasięgu kotwic i

użytkowników, dla przykładu użytkownik u2 znajduje się w obszarze ograniczonym
częścią wspólną zasięgów kotwic b6, b7 i b8, ponieważ jest z nimi bezpośrednio
połączony.
30
Rysunek 4.5: Diagram przedstawiający redukcję obszaru przy użyciu zasięgu

niepołączonych kotwic, dla przykładu obszar użytkownika u1 został wyznaczony
przez zasięg połączonej kotwicy b0, a następnie ograniczony poprzez zasięg
niepołączonej kotwicy b2.
redukcja zasięgiem kotwic
Drugim etapem algorytmu jest ograniczenie obszaru przy użyciu kotwic, z którymi
nie ma bezpośredniego połączenia. W tym jednak przypadku wykorzystano parametr
zasięgu minimalnego, aby wykluczyć możliwość niepoprawnej redukcji obszaru ze
względu na niestabilne połączenie.
Ograniczenie obszaru polega na odjęciu przestrzeni wyznaczającej zasięg niepo-
łączonych kotwic od wcześniej wyznaczonego obszaru lokalizacji urządzenia. Dotyczy
to wszystkich kotwic, z którymi nie znaleziono bezpośredniego połączenia. W ten
sposób można wykluczyć wszystkie obszary objęte zasięgiem kotwic, nieznajdujące
się w pobliżu urządzenia.
31
redukcja zasięgiem użytkowników
Trzeci, ostatni etap algorytmu polega na ograniczeniu wyznaczonego obszaru na

podstawie pozycji niepołączonych bezpośrednio użytkowników, jednak jest to pro-
ces bardziej skomplikowany niż ograniczanie zasięgiem kotwic, ponieważ nie znamy
dokładnej lokalizacji pozostałych użytkowników, a jedynie ich przybliżoną pozycję
w postaci obszarów.
Proces ten przebiega więc identycznie jak redukcja zasięgiem kotwic, z tą różnicą,
że od parametru "zasięg bluetooth" zostaje odjęta dodatkowa wartość odzwierciedla-
jąca niedokładność pozycji użytkowników — jest to maksymalna odległość krawędzi
obszaru lokalizacji użytkownika od jego środka.
Jak można zauważyć etap ten może być rekurencyjny — po jego zakończeniu ob-
szary lokalizacji użytkowników zostaną zmniejszone, dzięki czemu krok ten można
przeprowadzić ponownie dla jeszcze większego zwiększenia dokładności. Proces ten
ma jednak zastosowanie tylko w przypadku bardzo dużego (np więcej niż 1 urzą-
dzenie / 1m2) zagęszczenia urządzeń. Ze względu na brak jakichkolwiek problemów
wydajnościowych algorytmu postanowiono na stałe zastosować rekurencję poziomu
trzeciego.
32
Rysunek 4.6: Diagram przedstawiający redukcję obszaru przy użyciu zasięgu

niepołączonych użytkowników, dla przykładu obszar użytkownika u0 wyznaczony
poprzez połączenie z kotwicą b1 został ograniczony przez zasięgi użytkowników u2
i u3, niepołączonych bezpośrednio z u0. Obszar odjęty przez użytkownika u2 jest
większy, ponieważ wyznaczona dla niego lokalizacja jest dokładniejsza niż w
przypadku użytkownika u3.
33
4.3. ARCHITEKTURA ROZDZIAŁ 4. OPIS PROJEKTU
4.3 Architektura
System TriBeacon składa się z aplikacji serwerowej oraz z dwóch typów aplikacji
klienckich.
TriBeacon serwer
Aplikacja serwerowa napisana w języku Java jest głównym elementem systemu Tri-
Beacon. Posiada ona wbudowaną bazę danych. Ze względu na brak wymagań funk-
cjonalnych związanych z bazą zdecydowano się na przetrzymywanie danych jedynie
w pamięci podręcznej, wszystkie przeprowadzone eksperymenty i badania wymagały
zapisu danych jedynie w obrębie jednej sesji. Serwer przetwarza i zapisuje w bazie
wszystkie informacje o urządzeniach przychodzące z aplikacji użytkowników. Dzie-
je się to przez Bluetooth Scan Rest Api, wystawiające endpointy pozwalające na
przesłanie wiadomości z nazwą raportującego urządzenia oraz listą bezpośrednich
połączeń. Na podstawie tych wiadomości serwer decyduje również, czy urządzenia
uznawane są za bierne, czy za aktywne.
Drugim interfejsem udostępnionym przez serwer jest Beacon Management Rest
Api, pozwalające administratorowi na manualne ustawienie, które urządzenia pełnić
będą rolę kotwic oraz wskazanie ich dokładnej pozycji na mapie budynku.
Trzeci interfejs serwera to Estimated Position Rest Api, obliczające na żądanie
estymowane pozycje wszystkich użytkowników w systemie. W aktualnej postaci sys-
temu jest ono wykorzystywane jedynie do wizualizacji i obliczania błędu lokalizacji,
jednak w przypadku wdrożenia może zostać rozbudowane w celu dostarczania do-
wolnego rozwiązania bazującego na wyznaczonej lokalizacji (np. zliczać liczbę wejść/
wyjść z pomieszczeń, zbierać informacje o natężeniu ruchu, nawigować po budynku,
itd.).
Ostatnią funkcjonalnścią zaimplementowaną na serwerze jest Ground Truth Rest
Api, umożliwiające raportowanie informacji o rzeczywistej lokalizacji urządzeń, w
celu ich przyszłego wykorzystania do pomiaru błędu systemu.
TriBeacon Android / Linux
Aplikacje, choć zaimplementowane w zupełnie odmienny sposób, mają jednakowe

zastosowanie — służą do raporotowania informacji o połączeniach bluetooth przez
34
ROZDZIAŁ 4. OPIS PROJEKTU 4.3. ARCHITEKTURA
Rysunek 4.7: Diagram przedstawiający architekturę systemu TriBeacon.
urządzenia użytkowników. Mogą być to zarówno telefony z systemem Android jak i

dowolne komputery z systemem Linux.
Dodatkowo aplikacja TriBeacon Android posiada funkcjonalność, pozwalającą na
raportowanie rzeczywistej lokalizacji, wykorzystywanej później w eksperymenctach.
W przypadku aplikacji Androidowej kluczową kwestią w implementacji jest za-
rządzanie uprawnieniami oraz weryfikacja, czy wszystkie wymogi sprzętowe urzą-
dzenia są spełnione. Dotyczy to przede wszystkim modułu BLE, uprawnień do wy-
krywania lokalizacji oraz połączenia z internetem.
TriBeacon Frontend
Administracyjny graficzny interfejs użytkownika został stworzony w celu wizualizacji

lokalizacji oraz zarządzania systemem kotwic. Działa on w czasie rzeczywistym i jest
w pełni responsywny, umożliwia natychmiastowe reagowanie na jakiekolwiek zmiany
zachodzące w sieci. Dla uproszczenia architektury systemu jest on kompilowany
razem z aplikacją serwerową i udostępniany przez protokół HTTP na tej samej
ścieżce co pozostałe serwerowe REST API.
35
4.4. KONSERWACJA ROZDZIAŁ 4. OPIS PROJEKTU
4.4 Konserwacja i inżynieria wtórna

W poniższej sekcji przedstawiono kluczowe elementy związane z ewentualną przyszłą
rozbudową systemu.
testy
W ramach projektu zaimplementowano testy E2E (end-to-end), sprawdzające głów-

ne funkcjonalności aplikacji tribeacon-serwer. Zastosowano testy tego typu ze wzglę-
du na łatwość ich utrzymania. Jako że projekt ma charakter eksperymentu, jego
implementacja ulega intensywnym zmianom. Testy E2E są gwarancją poprawności
działania głównych funkcjonalności i nie wymagają zmian nawet w przypadku całko-
witej zmiany implementacji algorytmu, warstwy dostępu do danych czy interfejsów
modelu domenowego. Testy jednostkowe byłyby w tym przypadku trudniejsze w
utrzymaniu i w ramach wykonanej pracy nad projektem wymagałyby kilkukrotnego
przepisania. W przypadku dodawania nowych funkcjonalności zaleca się implemen-
tację scenariuszy testowych per funkcjonalność. Testy najlepiej pisać na poziomie
głównego interfejsu HTTP (klasa MainController.Java),jednak bez testowania sa-
mego protokołu HTTP, bezpośrednio wywołując publiczne metody kontrolera. Po-
prawne działanie połączenia HTTP jest zapewnione przez bibliotekę Spring Boot i
nie ma potrzeby testowania samej biblioteki.
baza danych
W razie wykorzystania aplikacji produkcyjnie niezbędne jest zaimplementowanie

trwałej bazy danych. W aktualnej implementacji cała administracyjna konfiguracja
zostaje utracona po restarcie systemu. Sugerowaną formą zapisu danych byłaby re-
lacyjna baza danych, np. Postgres czy MySql, zapewniająca tranzakcyjność operacji
oraz pozwalająca dobrze odwzorować strukturę danych.
36
Rozdział 5
Implementacja TriBeacon
Rozdział przestawia opis implementacji projektu.
5.1 tribeacon-server
Kod napisany w języku Java oraz JavaScript przy użyciu narzędzia do budowania
projektów Maven.
5.1.1 Kod Java
Kod umieszczony w katalogu src/main/java składa się z dwóch klas main (punktów
startowych programów) oraz z pakietów zawierających logikę.
1. klasa TriBeaconApplication zawiera funkcję main dla programu serwerowego.

Po uruchomieniu na porcie 8080 wystawione będzie REST API służące do
komunikacji z aplikacjami klienckimi.
2. klasa TriBeaconExperiment zawiera funkcję main dla programu wyliczającego

średni błąd dla wszystkich eksperymentów przeprowadzonych w czasie działa-
nia programu. Dla poprawnego wykonania niezbędne jest umieszczenie plików
z historią eksperymentu w katalogu ./resources. W załączonym kodzie progra-
mu zamieszczono historię eksperymentu opisanego w rozdziale 6.
3. pakiet api zawiera model wykorzystywany przez API oraz implementację wszyst-
kich REST endpointów:
37
5.1. TRIBEACON-SERVER ROZDZIAŁ 5. IMPLEMENTACJA
— /devices - zwraca listę wszystkich monitorowanych urządzeń
— /history - zwraca całą zarejestrowaną historię
— /groundTruth - zwraca wszystkie zarejestrowane raporty lokalizacji
— /postitions - zwraca aktualną obliczoną pozycję wszystkich użytkowników
— /update/groundTruth - zapisuje raport z rzeczywistej pozycji użytkow-

nika
— /update/connections - aktualizuje listę połączeń użytkownika
— /update/positions - aktulizuje pozycję kotwicy
4. pakiet algorithm zawiera implementację algorytmu Breath First Search (BFS)

na modelu domenowym oraz implementację algorytmu TriBeacon (TBA). Al-
gorytm TBA przyjmuje graf połączeń (Devices) a zwraca listę geometrii od-
wzorowywujących pozycje użytkowników (Positions).
5. pakiet model zawiera impelentację modelu domenowego, a w szczególności:
— Devices — Klasa odwzorowująca graf połączeń użytkowników. Zawiera

w sobie mapę Obiektów Device, z których każdy zawiera w sobie listę
Connections, będących linkami do pozostałych Device z sieci.
— Position — Klasa zawierająca obiekt urządzenia oraz geometrię odwzo-

rowującą obliczoną lokalizację. Pozycje nie są przechowywane w pamięci
programu, a jedynie wyznaczane w czasie rzeczywistym na żądanie użyt-
kownika (REST API /positions)
5.1.2 Kod JavaScript
Kod zawierający implementację przeglądarkowego interfejsu użytkownika do zarzą-

dzania i wizualizacji sieci urządzeń. Komunikuje się z aplikacją serwerową przy uży-
ciu REST API. Napisany przy użyciu biblioteki React. Główne części implementacji
to:
1. App.js — implementuje komponent przechowujący stan aplikacji oraz zapew-

niający cykliczną (w 1-sekundowych interwałach) synchronizację z aplikacją
serwerową.
38
ROZDZIAŁ 5. IMPLEMENTACJA 5.2. TRIBEACON-EMULATOR
2. components/Devices — komponent renderujący na obrazie listę urządzeń w

postaci kolorowych kroperk
3. components/Positions — komponent renderujący na obrazie pozycje użytkow-

ników wyliczone przez aplikację serwerową.
4. components/NavigationBar — komponent renderujący górny pasek aplikacji,

odpowiedzialny za zarządzanie widokiem (wyświetlanie paska bocznego) oraz
za sterowanie parametrami algorytmu (minPosition, maxPosition)
5. components/SideBar — komponent wyświetlający pobraną serwera listę urzą-

dzeń dostępnych w sieci. Pozwala aktywować urządzenia jako kotwice, a na-
stępnie oznaczać ich pozycje na mapie.
5.2 tribeacon-emulator
TriBeacon emulator jest klonem kodu tribeacon-server, posiada jednak modyfika-
cje umożliwiające dodawanie wirtualnych urządzeń z poziomu intefejsu użytkow-
nika oraz manipulowanie ich pozycją. Każde w ten sposób utworzone urządzenie
asynchronicznie wysyła do serwera wynik wirtualnego skanu w postaci listy innych
wirtualnych urządzeń będących w zasięgu.
Emulator służy tylko i wyłącznie do celu prezentacji działania algorytmu. Nie
zaleca się wykonywania na nim eksperymentów, ze względu na brak błędu pomia-
rowego skanu urządzeń wirtualnych.
5.3 tribeacon-client
Kod zawierający implementację dwóch aplikacji klienckich:
5.3.1 tribeacon-linux
kod napisany w języku python, składa się ze skryptu tribeacon-linux.py. Program

wykorzystuje bibliotekę bluepy w celu wykonania cyklicznych, 10-sekundowych ska-
nów BLE, oraz bibliotekę requests w celu komunikacji z serwerem przy użyciu pro-
tokołu HTTPS.
39
5.3. TRIBEACON-CLIENT ROZDZIAŁ 5. IMPLEMENTACJA
5.3.2 tribeacon-android
kod napisany w języku java, jest to projekt budowany przy pomocy narzędzia Gradle.
Najbardziej istotne elementy impelementacji to:
1. MainActivity — główna klasa aplikacji, implementuje cykliczne skany blueto-

oth oraz wifi.
2. BluetoothAdvertiser — klasa umożliwiająca rozpoczęcie advertisementu blu-

etooth, w celu zapewnienia wykrywalności przez inne urządzenia
3. BluetoothScanner — klasa umożliwiająca wykonanie skanu BLE. Przy two-

rzeniu wymaga podania obiektu DeviceConsole
4. WifiScanner — klasa umożliwiająca wykonanie skanu Wifi. Przy tworzeniu

wymaga podania obiektu DeviceConsole
5. DeviceConsole - klasa przetrzymująca stan znalezionych w pobliżu urządzeń

oraz wyświetlająca je na konsoli.
6. CommandConsole — klasa służąca do wyświetlania poleceń i informacji dla

użytkownika
7. UserDto — klasa modelowa wykorzystywana w komunikacji z serwerem.
8. ServerConnection — klasa implementująca interfejs komunikacji z serwerem

przy użyciu protokołu Https.
40
Rozdział 6
Eksperyment
Rozdział przedstawia opis i wyniki eksperymentu wykonanego w celu pomiaru do-

kładności systemu IPS.
6.1 Opis
Po zakończonej implementacji wykonano eksperyment mający na celu weryfikację

jakości systemu. Do badania wykorzystano wszystkie rodzaje urządzeń, a więc pa-
sywne/aktywne oraz kotwice/użytkowników
W ramach eksperymentu wykonano 16 raportów dotyczących lokalizacji rzeczy-
wistej, a następnie porównano ich pozycje z estymatami wyznaczonymi na podstawie
historii działania systemu TriBeacon w czasie wykonywania pomiarów.
Historię sieci TriBeacon zapisano w postaci nieprzeliczonej, a więc jako graf po-
łączeń, nie jako obliczone lokalizacje. Pozwoliło to na obliczenie estymowanej lokali-
zacji dla różnych parametrów algorytmu bez potrzeby ponownego wykonania ekspe-
rymentu. Na końcu tej sekcji zaprezentowano tabele z wynikami błędu pomiarowego
(odległości między pozycją rzeczywistą a estymowaną).
Wstępna analiza wyników pozwala zauważyć, iż najlepsze znalezione parametry
algorytmu to minRange = 2 metry oraz maxRange = 5 metrów.
Zauważono, iż przy zbyt małej wartości maksymalnego zasięgu (2 metry) wiele
urządzeń (13 na 16) nie posiada estymowanej lokalizacji — obszar wyznaczony przez
alogorytm jest pusty.
Z drugiej jednak strony, przy zbyt dużej wartości maksymalnej lokalizacji (10
41
6.1. OPIS ROZDZIAŁ 6. EKSPERYMENT
Tabela 6.1: Spis urządzeń wykorzystanych w eksperymencie.
name active/passive beacon/user

E1 (Raspberry Pi) active beacon
Samsung Mi Note 10 (Phone) active user
PC active user
iTag (key finder) passive user
Mi ColorS E538 (watch) passive user
metrów) zdecydowanie rosną błędy pomiarowe.

Nie przeprowadzono eksperymentów związanych z optymalizacją pozostałych pa-
rametrów systemu. Również optymalizacja maxRange i minRange odbyła się jedynie
na zasadzie iteracji po kolejnych wartościach. Nie podjęto także próby uwzględnienia
mocy sygnału urządzeń.
42
ROZDZIAŁ 6. EKSPERYMENT 6.2. WIZUALIZACJA
Rysunek 6.1: Diagram przedstawiający wizualizację w trakcie wykonywania

eksperymentu, urządzenia PC, Mi Note 10 Lite oraz Mi ColorS E538 pełnią rolę
użytkowników, natomiast urządzenia E1-6 kotwic.
6.2 Wizualizacja
Poniżej przedstawiono zrzuty ekranu z wizualizaji w aplikacji webowej w czasie
wykonywania eksperymentu.
43
6.2. WIZUALIZACJA ROZDZIAŁ 6. EKSPERYMENT
Rysunek 6.2: Diagram przedstawiający wykrywanie w tle urządzeń

nieuwzlgędnionych w czasie eksperymentu, np. Oclean Bluetooth (szczoteczka do
zębów) czy TV Samsung series (telewizor).
44
ROZDZIAŁ 6. EKSPERYMENT 6.3. WYNIKI
Tabela 6.2: Błędy pomiarowe dla różnych parametrów algorytmu.
minimum range (m) maximum range (m) calculated positions average error (cm)
1 2 3/16 175.4
2 5 16/16 267.3
5 10 16/16 534.7
6.3 Wyniki
Poniżej przedstawiono tabele z uśrednionymi oraz dokładnymi wynikami podczas
przeprowadzonych eksperymentów dla różnych parametrów algorytmu.
45
6.3. WYNIKI ROZDZIAŁ 6. EKSPERYMENT
Tabela 6.3: Błąd pomiarowy dla skanów przy parametrach min=2 m max=5 m.
time device position difference (cm)

2022-12-28T11:19:50Z Mi Note 10 Lite 50.37859598345924
2022-12-28T11:20:05Z Mi Note 10 Lite 270.3429213487796
2022-12-28T11:20:19Z Mi Note 10 Lite 143.83059814322988
2022-12-28T11:20:34Z Mi Note 10 Lite 187.7469046698925
2022-12-28T11:20:45Z Mi Note 10 Lite 347.8512228465481
2022-12-28T11:20:56Z Mi Note 10 Lite 428.03631704136296
2022-12-28T11:21:05Z Mi Note 10 Lite 92.92548612217571
2022-12-28T11:21:15Z Mi Note 10 Lite 332.35288834200185
2022-12-28T11:21:25Z Mi Note 10 Lite 82.35739709918518
2022-12-28T11:21:35Z Mi Note 10 Lite 398.9725318090065
2022-12-28T11:21:52Z Mi Note 10 Lite 212.80844015820594
2022-12-28T11:22:06Z Mi Note 10 Lite 367.7844685121675
2022-12-28T11:22:07Z Mi Note 10 Lite 383.2929332598441
2022-12-28T11:22:27Z Mi Note 10 Lite 362.0560832251175
2022-12-28T11:22:37Z Mi Note 10 Lite 347.46808517614284
2022-12-28T11:22:47Z Mi Note 10 Lite 269.5828262540572
46
ROZDZIAŁ 6. EKSPERYMENT 6.3. WYNIKI

2022-12-28T11:19:50Z Mi Note 10 Lite 199.5671531339685
2022-12-28T11:20:05Z Mi Note 10 Lite 0.0
2022-12-28T11:20:19Z Mi Note 10 Lite 0.0
2022-12-28T11:20:34Z Mi Note 10 Lite 0.0
2022-12-28T11:20:45Z Mi Note 10 Lite 0.0
2022-12-28T11:20:56Z Mi Note 10 Lite 0.0
2022-12-28T11:21:05Z Mi Note 10 Lite 0.0
2022-12-28T11:21:15Z Mi Note 10 Lite 0.0
2022-12-28T11:21:25Z Mi Note 10 Lite 0.0
2022-12-28T11:21:35Z Mi Note 10 Lite 0.0
2022-12-28T11:21:52Z Mi Note 10 Lite 0.0
2022-12-28T11:22:06Z Mi Note 10 Lite 0.0
2022-12-28T11:22:07Z Mi Note 10 Lite 0.0
2022-12-28T11:22:27Z Mi Note 10 Lite 206.37997751632295
2022-12-28T11:22:37Z Mi Note 10 Lite 120.13298505991624
2022-12-28T11:22:47Z Mi Note 10 Lite 0.0
47
6.3. WYNIKI ROZDZIAŁ 6. EKSPERYMENT

2022-12-28T11:19:50Z Mi Note 10 Lite 380.35281991144643
2022-12-28T11:20:05Z Mi Note 10 Lite 588.5676833682904
2022-12-28T11:20:19Z Mi Note 10 Lite 330.29259098084265
2022-12-28T11:20:34Z Mi Note 10 Lite 517.4829148033054
2022-12-28T11:20:45Z Mi Note 10 Lite 679.1864380041213
2022-12-28T11:20:56Z Mi Note 10 Lite 797.0508234275911
2022-12-28T11:21:05Z Mi Note 10 Lite 217.47821157806436
2022-12-28T11:21:15Z Mi Note 10 Lite 309.04446889806036
2022-12-28T11:21:25Z Mi Note 10 Lite 346.8608379918393
2022-12-28T11:21:35Z Mi Note 10 Lite 392.5824754498072
2022-12-28T11:21:52Z Mi Note 10 Lite 459.8057711660656
2022-12-28T11:22:06Z Mi Note 10 Lite 848.0074661580464
2022-12-28T11:22:07Z Mi Note 10 Lite 868.2427321148477
2022-12-28T11:22:27Z Mi Note 10 Lite 619.6575881968262
2022-12-28T11:22:37Z Mi Note 10 Lite 657.7647322976572
2022-12-28T11:22:47Z Mi Note 10 Lite 543.5011294781141
48
Rozdział 7
Dyskusja
Rozdział zawiera podsumowanie i wnioski wynikające z przeprowadzonej pracy.
7.1 Założenia zrealizowane
Zgodnie z założeniami zaimplementowano wszystkie wymienione elementy systemu.

Eksperymenty wykazały potencjał zaproponowanego rozwiązania, jednak zostały
przeprowadzone w zbyt uproszczonej formie aby dokonać jakiejkolwiek oceny rze-
czywistej zdatności do użytku. W wyniku eksperymentów średni błąd estymowanej
pozycji określono na 3 metry, co w większości zastosowań IPS jest dokładnością
wystarczającą.
Analiza i porównanie istniejących systemów IPS została dokonana jedynie w
zakresie teoretycznym. W przypadku większości istniejących rozwiązań nacisk kła-
dziony był na zdecydowanie większą dokładność lokalizacji (np. 0.1 metra), podczas
gdy w większości zastosowań IPS wystarczająca jest dokładność kilkumetrowa. Sys-
tem TriBeacon został zaprojektowany z założeniem dokładności do około 3 metrów,
a nacisk położony został na kompatybilność z wieloma typami urządzeń, łatwość
wdrożenia i niskie koszty infrastruktury/utrzymania.
Udało się również w pełni zaimplementować wszystkie funkcjonalności związane
z zarządzaniem infrastrukturą, liczbę i pozycję kotwic można dowolnie zmieniać w
czasie rzeczywistym. Jako kotwica służyć może dowolne urządzenie emitujące sygnał
BLE, nie określono wymagań dotyczących pozycji czy ilości kotwic.
Studium technologii Bluetooth oraz analiza technologii informatycznych w dzie-
49
7.2. ZAŁOŻENIA NIEZREALIZOWANE ROZDZIAŁ 7. DYSKUSJA
dzinie zakończyły się powodzeniem i pozwoliły stworzyć prostą i przystosowaną do

rozbudowy implementację przy użyciu nowoczesnych języków i bibliotek.
7.2 Założenia niezrealizowane

Ze względu na brak dostępnych środków i wsparcia nie udało się zrealizować ekspery-
mentów na początkowo zakładaną skalę. Do ostatecznych pomiarów wykorzystano 10
urządzeń, z czego tylko jedno służyło do pomiaru rzeczywistej lokalizacji (użytkow-
nik raportował w interwałach 10-sekundowych swoją rzeczywistą pozycję na mapie).
W celu zbadania pełnego potencjału systemu TriBeacon należałoby przeprowadzić
eksperymenty na zdecydowanie większej ilości urządzeń, od kilkudziesięciu do nawet
kilkuset, oraz zapewnić wiarygodne źródło danych do weryfikacji poprawności, np.
inny system IPS.
Dodatkowo aplikacja klienta na komputery z systemem operacyjnym Linux zo-
stała wykonana w formie bardzo prowizorycznej, tj. skryptu Python. O ile imple-
mentacja ta spełnia wszystkie wymagania funkcjonalne aplikacji użytkownika, jest
niewygodna w użytku i trudna do utrzymania w przypadku przyszłej rozbudowy
systemu. W przypadku wdrożenia systemu należy uzupełnić bazę kodową o pełną
aplikację użytkownika na systemy Linux oraz Windows.
7.3 Ocena stworzonego systemu

Nie zarejestrowano żadnych problemów związanych z wydajnością systemu TriBe-
acon, zgodnie z architekturą i założeniami w przedstawionej formie system powinien
być w stanie pracować z obciążeniem nawet kilku tysięcy urządzeń połączonych rów-
nocześnie. W razie problemów optymalizacyjnych system jest w pełni skalowalny,
jednak jego rozbudowa wymagałaby rozbudowania implementacji o współdzieloną
bazę danych.
7.4 Porównanie z istniejącymi IPS

TriBeacon nie został bezpośrednio porównany z żadnym wdrożonym IPS, jednak
zgodnie z teorią posiada on pewną przewagę zarówno nad algorytmami range-based,
50
ROZDZIAŁ 7. DYSKUSJA 7.5. OCENA MOŻLIWOŚCI WDROŻENIA
jak i range-free. Niewątpliwym atutem jest możliwość wykrywania urządzeń biernych

oraz wykorzystanie dowolnej infrastruktury. Dotychczas stosowane systemy mają
jednak plusy — uwzględniają one parametry takie jak Tx-Power czy RSSI, wpły-
wa to na większą skuteczność w przypadku małej ilości kotwic, ale z drugiej strony
wymusza stosowanie ustandaryzowanych nadajników i odbiorników. Wiele urządzeń
dostępnych na rynku nie udostępnia informacji o mocy połączenia lub jest niejedno-
licie skalibrowana, co sprawia, że nie nadają się do stosowania w systemach wyko-
rzystujących np. fingerprinting. Ostatecznie jednak istnieje możliwość uwzględnienia
danych o mocy sygnału w systemie TriBeacon oraz stosowanie wartości domyślnych
w przypadku urządzeń niepoprawnie skalibrowanych lub niedostarczających wystar-
czających informacji.
Dodatkowo większość wdrożonych do tej pory systemów oblicza lokalizację je-
dynie na podstawie danych pochodzących z jednego urządzenia, tak więc pomiary
obarczone są dużym ryzykiem błędu. W systemie TriBeacon wszystkie urządzenia
wykrywają się nawzajem i tworzą spójny graf połączeń, dzięki czemu urządzenia,
których skan jest niepełny lub zakłócony, dalej mogą zostać poprawnie zlokalizowane
dzięki danym pochodzącym z okolicznych urządzeń.
7.5 Ocena możliwości wdrożenia
System jest możliwy do natychmiastowego wdrożenia w dowolnym budynku posiada-

jącym wystarczającą ilość urządzeń emitujących sygnał BLE. Nie wykonano testów
ani symulacji pozwalających określić relację między ilością urządzeń a dokładnością
systemu TriBeacon.
W przypadku próby wdrożenia w miejscach publicznych należałoby zintegrować
aplikację TriBeacon Android np. z aplikacją do obsługi biletów czy systemu rezer-
wacji sal, tak aby użytkownicy przebywający w budynku mieli stale lub tymczasowo
uruchomiony program na telefonach, lub innych prywatnych urządzeniach.
W przypadku próby wdrożenia w miejscach takich jak hale sklepowe czy ma-
gazyny pewnym utrudnieniem może być określenie lokalizacji stałych punktów in-
frastruktury, ze względu na specyficzne miejsca ich montażu, np. na suficie czy w
zamkniętych skrzyniach z elektroniką. W powyższym przypadku należałoby zaim-
51
7.6. DALSZE BADANIA ROZDZIAŁ 7. DYSKUSJA
plementować dodatkową funkcjonalność, pozwalającą na wyznaczenie przybliżonej

lokalizacji elementów infrastruktury na podstawie skanów testowych, a następnie ich
manualną poprawę.
Budzącym największe nadzieje zastosowaniem systemu TriBeacon pozostają wy-
darzenia publiczne, gdzie kilkaset, a nawet kilka tysięcy osób przebywa w tym samym
miejscu. Zaproponowany system jest przystosowany do tego typu obciążenia i jego
wdrożenie wymaga jedynie zainstalowania aplikacji przez użytkowników.
7.6 Perspektywy dalszych badań w dziedzinie
7.6.1 Eksperymenty
Podstawową kwestią wymagającą dalszych badań są eksperymenty i porównania z

istniejącymi już systemami. Jako że głównym celem pracy było zaprojektowanie i
implementacja systemu, eksperymenty i pomiary błędu zostały wykonane jedynie
w bardzo uproszczonej formie. W celu dokładnej analizy jakości zaproponowanego
systemu należałoby wykonać szereg badań z wykorzystaniem dziesiątek bądź setek
urządzeń, sprawdzić zachowanie systemu w różnych budynkach i przy użyciu róż-
nego rodzaju urządzeń, a także dokonać analizy korelacji między błędem lokalizacji
a zagęszczeniem urządzeń w budynku czy ze specyficznymi układami urządzeń w
przestrzeni. W tej jednak kwestii najbardziej problematyczny pozostaje sposób po-
zyskania danych oznaczonych, a więc próbek rzeczywistej lokalizacji. W systemie
działającym w czasie rzeczywistym należałoby zaangażować dziesiątki osób do jed-
noczesnego raportowania swojej rzeczywistej lokalizacji przez określony czas, a nawet
w takim wypadku potencjalny błąd manualnego raportowania lokalizacji może być
większy niż docelowa dokładność systemu. Najlepszym rozwiązaniem w tej kwestii
wydaje się być porównanie systemu TriBeacon z wdrożonym już systemem IPS i
porównanie wyników estymowanej lokalizacji.
7.6.2 Optymalizacja parametrów
W systemie wykorzystany został szereg parametrów, takich jak minimalny i mak-

symalny zasięg bluetooth, częstotliwość skanu, częstotliwość wygaszania nieaktyw-
52
ROZDZIAŁ 7. DYSKUSJA 7.7. PODSUMOWANIE
nych połączeń, liczba iteracji algorytmu itd. Żaden z powyższych parametrów nie
został zoptymalizowany, a wartości wykorzystane w eksperymencie zostały dobrane
na podstawie zaledwie kilku testowych pomiarów. Ze względu na brak wystarczają-
co dużego zbioru danych testowych nie przeprowadzano optymalizacji powyższych
wartości. Kwestię tę należy rozstrzygnąć w dalszych badaniach.
7.6.3 Moc sygnału
W algorytmie TriBeacon założono, iż wszystkie urządzenia bluetooth emitują po-

dobnej mocy sygnał i zawsze mieści się on pomiędzy pewną wartością minimalną a
maksymalną. W rzeczywistości nie jest to prawda, nawet urządzenia znajdujące się
bardzo blisko siebie mogą się nie wykryć (np. ze względu na różną częstotliwość skanu
i advertisementu) a bardziej zaawansowane nadajniki bluetooth mogą emitować sy-
gnał o mocy nawet kilkudziesięciu metrów. W większości urządzeń bluetooth istnieje
możliwość odczytania teoretycznej mocy nadajnika (Tx-Power), rzeczywistej mocy
sygnału (RSSI), a czasem nawet kalibracji mocy (Tx-Power-Control). Wszystkie te
parametry zostały w algorytmie pominięte, jednak w przypadku rozbudowy projektu
należałoby przeprowadzić eksperymenty na zmodyfikowanym systemie, gdzie mini-
malny i maksymalny zasięg bluetooth byłyby przydzielane dynamicznie do każdego
połączenia między urządzeniami.
7.7 Podsumowanie
Stworzono system IPS umożliwiający lokalizowanie urządzeń ze średnią dokładnością

3 metrów. Wykonano implementację umożliwiającą wdrożenie systemu na urządze-
niach z systemem Linux oraz Android. Algorytm umożliwia również bierne rozpozna-
wanie urządzeń bez dedykowanego oprogramowania, emitujących sygnał BLE. Stwo-
rzono interfejs umożliwiający dynamiczną alokację punktów referencyjnych (kotwic)
oraz wykorzystywanie w tym celu istniejących elementów infrastruktury lub urzą-
dzeń rozmieszczonych w budynku. Zauważono wiele możliwości przyszłego rozwoju
systemu, np. uwzględnienia dodatkowych parametrów sygnału, zaimplementowa-
nie aplikacji wspierających inne popularne systemy operacyjne, takie jak Windows
czy MacOS. Estymowany błąd pomiarowy (3̃ m) został obliczony po przeprowa-
53
7.7. PODSUMOWANIE ROZDZIAŁ 7. DYSKUSJA
dzeniu jedynie podstawowych eksperymentów, w przypadku dalszych badań nad

systemem zaleca się przeprowadzenie dokładniejszych pomiarów w tym zakresie, a
także uwzględnienie większej ilości czynników.
54
Bibliografia
[1] A. Bekkelien, Michel Deriaz, and S. Marchand-Maillet. “Bluetooth Indoor

Positioning”. In: 2012. url: https://www.semanticscholar.org/paper/
Bluetooth-Indoor-Positioning-Bekkelien-Deriaz/1919037541b4a84d0b5a6dd4d425c0
(Ostatni dostęp: 11/2/2023).
[2] Josyl Mariela Rocamora et al. “Survey of CSI Fingerprinting-Based Indoor

Positioning and Mobility Tracking Systems”. In: IET Signal Processing 14.7
(2020), pp. 407–419. issn: 1751-9683. doi: 10.1049/iet- spr.2020.0028.
url: https://onlinelibrary.wiley.com/doi/abs/10.1049/iet- spr.
2020.0028 (Ostatni dostęp: 11/2/2023).
[3] Jiří Kárník and Jakub Streit. “Summary of Available Indoor Location Tech-
niques”. In: IFAC-PapersOnLine. 14th IFAC Conference on Programmable
Devices and Embedded Systems PDES 2016 49.25 (Jan. 1, 2016), pp. 311–
317. issn: 2405-8963. doi: 10.1016/j.ifacol.2016.12.055. url: https:
/ / www . sciencedirect . com / science / article / pii / S240589631632691X
(Ostatni dostęp: 11/2/2023).
[4] Android SDK documentation. Android Developers. url: https://developer.

android.com/docs (Ostatni dostęp: 11/2/2023).
[5] Spring Boot. Spring Boot. url: https://spring.io (Ostatni dostęp: 11/2/2023).
[6] Heroku Dev Center. url: https://devcenter.heroku.com/ (Ostatni dostęp:

11/2/2023).
[7] JTS Topology Suite. LocationTech, Feb. 10, 2023. url: https://github.com/
locationtech/jts (Ostatni dostęp: 11/2/2023).
[8] React – javascriptowa biblioteka służąca do tworzenia interfejsów użytkownika.

url: https://pl.reactjs.org/ (Ostatni dostęp: 11/2/2023).
55
BIBLIOGRAFIA BIBLIOGRAFIA
[9] React-Bootstrap. url: https : / / react - bootstrap . github . io/ (Ostatni

dostęp: 11/2/2023).
[10] GPS.Gov: GPS Accuracy. url: https : / / www . gps . gov / systems / gps /
performance/accuracy/ (Ostatni dostęp: 9/2/2023).
[11] Global Mobile OS Market Share 2022 | Statista. url: https://www.statista.

com / statistics / 272698 / global - market - share - held - by - mobile -
operating-systems-since-2009/ (Ostatni dostęp: 11/2/2023).
[12] Java | Oracle. url: https://www.java.com/pl/ (Ostatni dostęp: 11/2/2023).
[13] JavaScript.Com. url: https : / / www . javascript . com/ (Ostatni dostęp:

11/2/2023).
[14] Bash - GNU Project - Free Software Foundation. url: https://www.gnu.

org/software/bash/ (Ostatni dostęp: 11/2/2023).
[15] Welcome to Python.Org. Python.org. Feb. 10, 2023. url: https : / / www .
python.org/ (Ostatni dostęp: 11/2/2023).
[16] JTS Topology Suite. LocationTech, Feb. 10, 2023. url: https://github.com/
locationtech/jts/blob/436f1e8c91ebdfe9e8f76f3dc35c2aa65fa453e7/
LICENSES.md (Ostatni dostęp: 11/2/2023).
[17] React ·. Meta, Feb. 11, 2023. url: https://github.com/facebook/react/

blob/64acd3918a26d92773d3dd451a735603ef50d3a7/LICENSE (Ostatni do-
stęp: 11/2/2023).
[18] React-Bootstrap. react-bootstrap, Feb. 11, 2023. url: https://github.com/

react-bootstrap/react-bootstrap/blob/dd70349682fdbc7213c9791d8fb1e4fd2e3ca664/
LICENSE (Ostatni dostęp: 11/2/2023).
[19] android SDK license. Android Developers. url: https://developer.android.

com/studio/terms (Ostatni dostęp: 11/2/2023).
56
Spis rysunków
4.1 Diagram wizualizujący wejściowe i wyjściowe dane algorytmu. . . . . 26

4.2 Diagram przedstawiający strukturę danych połączeń. . . . . . . . . . 27
4.3 Wizualizacja zasięgu kotwic i użytkowników. . . . . . . . . . . . . . . 30
4.4 Wizualizacja części wspólnej zasięgu kotwic. . . . . . . . . . . . . . . 30
4.5 Wizualizacja redukcji zasięgiem kotwic. . . . . . . . . . . . . . . . . . 31
4.6 Wizualizacja redukcji zasięgiem użytkowników. . . . . . . . . . . . . . 33
4.7 Diagram przedstawiający architekturę systemu TriBeacon. . . . . . . 35
6.1 Wizualizacja eksperymentu, podział na użytkowników i kotwice. . . . 43

6.2 Wizualizacja eksperymentu, wykrywanie urządzeń z otoczenia. . . . . 44
57
Spis tabel
6.1 Spis urządzeń wykorzystanych w eksperymencie. . . . . . . . . . . . . 42

6.2 Błędy pomiarowe dla różnych parametrów algorytmu. . . . . . . . . . 45
6.3 Błąd pomiarowy dla skanów przy parametrach min=2 m max=5 m. . 46
6.4 Błąd pomiarowy dla skanów przy parametrach min=1 m max=2 m. . 47
6.5 Błąd pomiarowy dla skanów przy parametrach min=5 m max=10 m. 48
58
Dodatek A
Instrukcja uruchomienia
A.1 TriBeacon Serwer

1. Uruchomienie oprogramowania wymaga działającego programu java w wersji
1.8: instalacja java
2. W celu włączenia lokalnie aplikacji serwerowej należy w wierszu poleceń wpro-

wadzić następujące komendy (po przejściu do katalogu z plikami wykonywal-
nymi):
java -jar tribeacon-server.jar
3. Następnie należy otworzyć dowolną przeglądarkę internetową oraz wprowadzić

adres:
http://localhost:8080/
4. Serwer zostanie włączony domyślnie na lokalnym porcie 8080, aby uzyskać do

niego dostęp z innych urządzeń peryferyjnych, należy wykonać przekierowanie
portu, tzw. port-forwarding.
5. Propozycja udostępnienia serwera z sieci lokalnej przy pomocy tunelu z apli-

kacją LocalTunnel:
59
A.2. TRIBEACON ANDROID DODATEK A. INSTRUKCJA URUCHOMIENIA
(a) Program LocalTunnel wymaga zainstalowanego programu node.js: insta-

lacja node.js.
(b) w celu instalacji programu LocalTunnel należy wykonać polecenie:
npm install localtunnel
(c) Otwarcie lokalnego portu pod domeną https//tribeacon.loca.lt:
lt --port 8080 --print-requests --open --subdomain tribeacon
(d) W przypadku błędów "nie znaleziono polecenia npm" lub "nie znaleziono
polecenia lt" należy zrestartować komputer po instalacji oprogramowania.
A.2 TriBeacon Android

1. W celu zainstalowania oprogramowania na telefonie z systemem Android na-
leży przenieść plik tribeacon-android.apk do pamięci wewnętrznej telefonu a
następnie przy pomocy dowolnego programu do zarządzania systemem plików
otworzyć plik uruchomieniowy.
2. Podczas instalacji należy stosować się do wyświetlanych poleceń. (instalacja

może wymagać dodatkowych uprawnień do otwierania plików z nieznanych
źródeł).
3. Po uruchomieniu aplikacji należy wprowadzić adres serwera TriBeacon. Jeżeli

serwer został udostępniony przy pomocy sugerowanej aplikacji LocalTunnel,
poprawny będzie domyślnie wpisany adres.
4. Do działania wymagane jest połączenie z internetem, włączony bluetooth oraz

lokalizacja. W przypadku braku któregokolwiek z powyższych wyświetlony zo-
stanie komunikat. Aplikacja może również spytać o dodatkowe uprawnienia do
wyznaczania lokalizacji przy użyciu Bluetooth.
60
DODATEK A. INSTRUKCJA URUCHOMIENIA A.3. TRIBEACON LINUX
A.3 TriBeacon Linux

1. W celu uruchomienia oprogramowania na systemie Linux niezbędne jest opro-
gramowanie python oraz biblioteka bluepy: instalacja bluepy
2. W celu uruchomienia skryptu należy w wierszu poleceń wprowadzić następu-

jące komendy (po przejściu do katalogu z plikami wykonywalnymi):
sudo python3 tribeacon-linux.py PC https://tribeacon.loca.lt
Polecenie sudo uruchamia program z uprawnieniami administratora, jest to

niezbędne do poprawnego działania skanu bluetooth. Argumenty programu
to kolejno: nazwa skryptu, nazwa urządzenia (należy wprowadzić dowolną,
wybraną przez siebie nazwę) oraz adres serwera (taki sam jak skonfigurowany
w aplikacji serwerowej).
3. W celu zapewnienia wykrywalności urządzenia przy pomocy protokołu BLE

należy przy użyciu narzędzia bluetoothctl wykonać kolejno w wierszu poleceń
następujące komendy:
bluetoothctl
menu advertise
name "PC" // można zastąpić dowolną nazwą
discoverable on
back
advertise on
61
A.4. TRIBEACON EMULATOR
DODATEK A. INSTRUKCJA URUCHOMIENIA
A.4 TriBeacon Emulator

1. Uruchomienie oprogramowania wymaga działającego programu java w wersji
1.8: instalacja java
2. W celu włączenia emulatora należy w wierszu poleceń wprowadzić następujące

komendy (po przejściu do katalogu z plikami wykonywalnymi):
java -jar tribeacon-emulator.jar
3. Następnie należy otworzyć dowolną przeglądarkę internetową oraz wprowadzić

adres:
http://localhost:8080/
62

System Lokalizacji Wewnatrzbudynkowej

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Lokalizacji Wewnatrzbudynkowej

Uploaded by

Copyright:

Available Formats

Politechnika Łódzka

PRACA DYPLOMOWA INŻYNIERSKA

System lokalizacji wewnatrzbudynkowej

Wydział Fizyki Technicznej, Informatyki i Matematyki Stosowanej

Celem pracy było stworzenie alternatywnego systemu lokalizacji wewnątrzbudyn-

3.3.3 lista programów . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7.2 Założenia niezrealizowane . . . . . . . . . . . . . . . . . . . . . . . . 50

1.1 problematyka i zakres pracy

Niniejsza praca dotyczy zakresu inżynierii oprogramowania oraz internetu rzeczy.

Głównym przedmiotem pracy jest stworzenie oprogramowania oraz infrastruktu-

1.1.1 opis problemu

Lokalizacja wewnątrzbudynkowa rozwija się jako odrębna dziedzina od lokalizacji

Systemy IPS mogą być wykorzystywane w następujących dziedzinach:

1. zarządzanie przestrzenią publiczną

(a) określanie poziomu ruchu w pomieszczeniach

(b) planowanie i monitorowanie wydarzeń publicznych

(c) usprawnianie systemów rezerwacji sal, zarządzania kolejkami pacjentów

(a) szukanie produktów w sklepach

(b) usprawnianie czynności związanych z magazynowaniem towarów

(c) odnajdywanie właściwych pomieszczeń w instytucjach publicznych

(d) oznaczanie elementów infrastruktury na wydarzeniach publicznych (toa-

(b) planowanie ewakuacji

(c) rejestrowanie historii poruszania się po budynkach

Przedstawiony projekt ma na celu wprowadzenie zmodyfikowanego systemu oraz

Dzięki temu rozwiązaniu powstanie eksperymentalny system o dokładności więk-

1.2 Cele pracy

(a) Implementacja oprogramowania do obsługi dynamicznej infrastruktury

(b) opisanie i implementacja nowego algorytmu do wyznaczania lokalizacji

(c) Przeprowadzenie eksperymentu w celu pomiaru dokładności badanego

2. dodatkowe cele badawcze:

(a) Zapoznanie się z istniejącymi rozwiązaniami w dziedzinie IPS. Studium to

(b) Analiza działania technologii BLE (Bluetooth Low Energy). Część ta

1.3 Metoda Badawcza

2. Analiza budowy i działania istniejących produktów została wykonana głów-

3. Projektowanie i prototypowanie nowatorskich rozwiązań polegało na imple-

4. Algorytm TriBeacon służący do wyznaczania lokalizacji na podstawie grafu

1.4 Przegląd literatury w dziedzinie

zdobytych w czasie studiów inżynierskich podczas realizacji przedmiotów, np.

1.5 Układ pracy

1. Bieżący rozdział opisuje problematykę lokalizacji wewnątrzbudynkowej, za-

2. Rozdział drugi przedstawia studium technologii lokalizacji oraz istniejących

3. Rozdział trzeci opisuje technologie, sprzęt, definicje i podstawowe kwestie teo-

4. Rozdział czwarty opisuje system TriBeacon z uwzględnieniem wymagań funk-

5. Rozdział piąty zawiera opis implementacji projektu.

7. Rozdział siódmy zawiera dyskusję, oraz podsumowanie wszystkich aspektów

Najważniejszym rezultatem projektu jest kompletna implementacja systemu Tri-

Podstawa Teoretyczna Systemów IPS

Rozdział opisuje podstawowe zagadnienia obowiązujące w dziedzinie systemów lo-

2.1 Podstawowe definicje

— IPS - (Indoor Positioning System) - System nawigacji wewnątrzbudynkowej.

— Bluetooth — standard krótkozasięgowej bezprzewodowej komunikacji

— BLE - (Bluetooth Low Energy) standard krótkozasięgowej bezprzewodowej

— Wifi - (IEEE 802.11) - grupa standardów bezprzewodowych sieci lokalnych

— RSSI - (Received Signal Strength Indication) – wskaźnik mocy odbieranego

— Tx-Power -(Transmit Power) oznacza moc wysyłania. W kontekście bezprze-

— LQ - (Link Quality) to wskaźnik jakości połączenia w urządzeniach Bluetooth.

— Kotwica (Beacon) - to urządzenie emitujące i/lub nadające sygnał o stałej

— access point — Urządzenie transmitujące sygnał bezprzewodowy w sieci Wifi,

— fingerprinting — metoda wyznaczania lokalizacji, polegająca na porównywaniu

— skan BLE — operacja wykonywana przez urządzenie z modułem BLE polega-

— advertisement BLE — operacja wykonywana przez urządzenie z modułem BLE

2.2 Istniejące rozwiązania w dziedzinie

IPS jest zagadnieniem odrębnym od częściej stosowanego GPS ze względu na ogra-