Demonstrator Sytemu

I. Warianty systemu demonstracyjnego

System demonstracyjny CyberMatryca przygotowano w kilku współpracujących ze sobą wariantach, dedykowanych różnych przeznaczeniom. Ich najważniejsze parametry przedstawia tabela:

Cecha	Outdoor	Indoor Local	Indoor Remote
Typ przeznaczenia	Plenerowy     (warunkowo   wewnętrzny)	Wewnętrzny	Wewnętrzny   (warunkowo plenerowy)
Technologia lokalizacyjna	GPS     (Global   Positioning System)	BLE Beacon     (Bluetooth Low Energy)	BLE Beacon     (Bluetooth Low Energy)
Element lokalizacyjny   (preferowane)	Smartfon z modułęm GPS	Opaska     BLE Beacon	Opaska     BLE Beacon
Element lokalizacyjny   (dopuszczalne)	Dedykowany moduł GPS	Smartfon z   włączoną funkcją BLE	Smartfon z   włączoną funkcją BLE
Typ sieci	WAN	LAN	WAN/LAN
Technologia komunikacyjna	3G/4G/5G     802.11(WiFi)	802.3   (Ethernet)     802.11(WiFi)	802.3 (Ethernet)     802.11(WiFi)     3G/4G/5G
Protokoły komunikacyjne	MySQL     (TCP)	http     (TCP, UDP)	Mqtt     (TCP)
System bazodanowy	Oparty na SQL	Oparty na   InfluxDB	Oparty na   InfluxDB
Struktura PathVector	asynchroniczny	synchroniczny	synchroniczny
Zużycie energii	średnie	niskie	niskie
Stopień anonimowości	niski	wysoki	wysoki
Bezpieczeństwo	Szyfrowanie TLS   1.2	Autentykacja i autoryzacja (rfc2617).     Agent pośredniczący miedzy klientem a silnikiem influxdb   (telegraf)     TLS przy zapisie do infuxdb2	Autentykacja i autoryzacja brokera MQTT     Agent pośredniczący miedzy klientem a silnikiem influxdb   (collectd/telegraf)     Szyfrowane polaczenie SSL MqTT

II .Składowe systemu demonstratora

Od strony konstrukcyjnej w demonstratorze wyróżnić można  następujące elementy składowe i peryferyjne (wyodrębnione fizycznie):

1. Centralna jednostka bazodanowa
2. Komputerowa jednostka zarządzająca
3. Rozproszona sieć sensoryczna wraz akcesoriami

Wyodrębnienie tych elementów związane jest z ich odmienną lokalizacją. Zostało podkreślone, że Demonstrator przyjmuje postać sieci komputerowej. W szczególności składowa nr 3 jest zdelokalizowana i rozlokowana w różnych pomieszczeniach budynku D Politechniki Świętokrzyskiej a także, w przypadku segmentu Remote BLE, może mieć lokalizację dowolną. W efekcie należy zaznaczyć, że lokalizacja urządzeń wchodzących w skład elementu nr 3 może ulegać zmianom w trakcie użytkowania, modernizacji, lub ewentualnej dalszej rozbudowy w okresie trwałości projektu.

W skład Centralnej Jednostki Bazodanowej (CJB) wchodzą:

• SERWER DELL PowerEdge R540 2xXeon 4215/128GB/8x2TB wraz  z systemem operacyjnym Windows Server 2019 Datacenter/30CAL. Server ten jest dwuprocesorowym serwerem sprzętowym o wysokości 2U przeznaczonym do montażu w szafie serwerowej, który oferuje idealną równowagę między dostępem do zasobów i przystępną ceną, ułatwiając dostosowanie go do różnych wymagań.
• Konsola sterująca  KVM LCD Slideaway CL5708, 17 cali,  to moduł sterujący, który zapewnia dostęp do wielu komputerów z jednej konsoli PS/2 lub USB
• Zasilacz awaryjny UPS ORVALDI V3000+sinus 2U LCD/ rack kit
• Przełącznik sieciowy CISCO Catalyst 2960-X WS-C2960X-24PS-L. Przełącznik ten jest  wielowarstwowym, zarządzalnym w warstwach: L2 oraz L3, profesjonalnym przełącznikiem sieciowym z obsługą MIB (Management Information Base), QoS (Quality of Service) i Multicast, W zakresie łączności urządzenie zostało wyposażone w 24 porty Gigabit Ethernet, 4 porty SFP oraz 2 porty USB typu 2.0.

Elementy zamontowane są w standardowej szafie serwerowej typu  rack 19” 22U

W skład Komputerowej Jednostki sterującej wchodzi:

• Komputer stacjonarny Petrosoft PCS Aer X399B. z 16 wątkowym procesorem Intel i7  8 generacji, 16GB RAM, 240GB SSD, 1TB HDD,  
• Monitor Iiyama ProLite XUB2792UHSU-B1 27″ IPS LED, 4K, format 16:9, z funkcją obrotu ekranu (PIVOT)– 2 szt.
• Urządzenia peryferyjne typu mysz i klawiatura standardowa

Rozproszona sieć sensoryczna składa się z maksymalnie 30 jednostek skanujących pełniących rolę bramek IoT, dedykowanych segmentowi Indoor Local oraz Indoor Remote. W niniejszym rozwiązaniu rolę tę pełnią mikrokomputery jednopokładowe (SBC) Raspberry Pi w wersji 4B lub równoważne. Funkcję tranzytową pełni dedykowana sieć uczelniana. Ponadto użyto 4 urządzeń sieciowych w postaci routerów bezprzewodowych typ Linksys WRT3200acm.

W skład każdej bramki IoT wchodzi:

• Raspberry Pi4 Mod.B Wifi Dualbandblutooth 4GB 1,5
• Obudowa Raspberry Pi4 Model 4B
• Karta Pamięci Goodram Microsd 16GB 100mb/S+Noobs 
• Zasilacz USB C.5.1v/3a do Raspberry Pi4

III. Działanie i testy systemu

3.1 Testy wariantu wewnątrzbudynkowego

Przykładowy test wariantu Indoor local przeprowadzono dnia 2 lutego 2021r.  W sieci sensorycznej aktywnych było 13 skanerów, rozlokowanych w 7 pomieszczeniach budynku D Politechniki Świętokrzyskiej. W co najmniej 3 pomieszczeniach był więcej niż jeden skaner, co oznacza prawdopodobieństwa zaistnienia zjawiska multilokacji.  Łącznie 8 osób z opaskami BLE Moko pokonało wirtualną trasę zwiedzania wg własnego uznania, odwiedzając przynajmniej raz każde pomieszczenie. Segment pracował w architekturze IoT (LR-based) z oknem czasowym (TimeSlot) równym 5 sekund. System skonfigurowano w taki sposób, aby w czasie rzeczywistym eksponowane były te lokalizacje, dla których sygnał ilevel był najsilniejszy. Oznacza to eliminację zjawisku overlappingu i multilokacji – w danym slocie czasowym jedne uczestnik przyporządkowany mógł być jedynie do jednej lokalizacji (POI).

Zgodnie z założeniami, system w czasie rzeczywistym wygenerował wektory ścieżki dla poszczególnych zwiedzających (MAC-ów). Następnie, z wykorzystaniem funkcjonalności wizualizatora Grafana możliwe jest zwizualizowanie wektora ścieżki. Poniżej przedstawiono przebieg zwiedzania dla jednego ze zwiedzających. Różnymi kolorami przedstawione zostały zakresy czasowe, odpowiadające przebywaniu danego zwiedzającego w poszczególnych pomieszczaniach (POI) – poszczególne lokalizacje oznaczane są różnymi kolorami. Po zaznaczeniu wybranego pomieszczenia ukazuje się podgląd osi czasu tylko dla tego pomieszczenia. Z tego poziomu w sposób przyjazny można określić ramy czasowe pobytu danej osoby przy danej atrakcji.

W powyższym przykładzie osoba identyfikowana przez MAC E9::DC przebywała w pomieszczeniu 2.22 4 krotnie w trakcie 60-minutowego procesu zwiedzania. Z wykresu można odczytać (z dokładnością do 5s) ramy czasowe pobytu. Należy zauważyć, że wizualizacja zaprezentowana na powyższym rysunku zawiera informację o parametrach takich jak FLT (First Login Time) oraz LLT (Last Login Time). Ponadto, dane te mogą zostać wykorzystane w określeniu ostatniej znanej lokalizacji danej osoby.

Parametry TIL (Total Interest Level) oraz VP (Visit Period) odzwierciedlają poziom zainteresowania poszczególnych atrakcji. Visit Period to wyznaczony na podstawie wektora ścieżki czas przebywania w pobliżu atrakcji, natomiast TIL integruje (sumuje) wartość sygnału, w efekcie np. bliższe podejście do atrakcji powinno być „nagradzane” poprzez przewidywany wzrost poziomu sygnału. Wartość sygnału ilevel w LR może zmieniać się w przedziale 1 – 100. Natomiast VP w rozważanym przypadku jest szczególnym przypadkiem TIL, w którym ilevel ma zawsze stałą wartość równą rozmiarowi slotu czasowego.

Podejście TIL charakteryzuje się dużo większą kontrastowością, w porównaniu z podejściem VP. Natomiast zaletą profilu o charakterze VP jest jego większa kompatybilność z innymi rozwiązaniami lokalizacyjnymi, w tym z GPS. Rozwiązania takie nie zawsze dostarczają informacji, będące zgodne z profilem TIL (pominięta lub nieistotna  siła sygnału). Natomiast wartości Visit Period mogą być dostarczane bez większego problemu, np. przez rozwiązania oparte o GPS.

Na poniższym rysunku przedstawiono porównanie średniego profilu TIL dla wszystkich zwiedzających z profilem TIL zwiedzającego o identyfikatorze E9::DC. Z przedstawionych wartości wysuwa się hipoteza, że wskazana osoba więcej uwagi poświęcała większości „atrakcjom” niż przeciętny zwiedzający, wyjątek dotyczy jednak „atrakcji” zlokalizowanej w pomieszczeniu 3.19.   

3.2 Testy wariantu plenerowego

Testy wariantu GPS outdoor prowadzono na terenie kieleckiego rezerwatu geologicznego „Kadzielnia” w dniach 15-18 marca 2021.  Na jego terenie oznaczono 17 różnych „atrakcji” m.in.: „Murek ze skamieniałościami”, „Podziemna trasa turystyczna”, „Wzgórze harcerskie”, „Leje Krasowe” czy „Przyroda ożywiona”. Użytkownicy eksperymentu wyposażeni byli w smartfony z zainstalowana aplikację mobilną  Smartfony pełniły dwojaką rolę lokalizatora GPS oraz zwrotnego interfejsu lokalizacyjno-informacyjnego. Użytkowanie aplikacji wymaga standardowej zgody na zbieranie danych lokalizacyjnych oraz dostępu do sieci Internet. W celu zapewnienia większej stopnia poufności, w ostatecznej wersji aplikacji zrezygnowano z konieczności logowania się do systemu. Sam system logowania został przeznaczony w przypadku chęci rezerwacji wizyty czy zakupu biletu.

Interfejs lokalizacyjno-informacyjny pozwala zainteresowanym użytkownikom na dostęp do mapy atrakcji z zaznaczoną bieżącą lokalizacją użytkownika na tle położeń atrakcji. Użytkownik może wybrać interesującą go atrakcję i uzyskać o niej podstawowe informacje wraz z ewentualnymi linkami do źródeł zewnętrznych. Dodatkowa funkcjonalność aplikacji pozwala na wykreślenie proponowanej ścieżki zwiedzania – zwiedzający może podążać tą ścieżką obserwując na bieżąco zmianę swojego położenia – rys. 4.

W trakcie procesu zwiedzania pozyskiwane były informacje lokalizacyjne w postaci współrzędnych GPS (longitude/lattitude), które odnoszone są do indywidualnie zdefiniowanych wcześniej obszarów detekcji (DA).  Osoby mającą aktywną aplikację są na bieżąco informowane o aktualnej pozycji na interaktywnej mapie, a także w przypadku pojawienia się w obszarze DA danej atrakcji poprzez specjalny indykator oraz poprzez system powiadomień.  

Działanie systemu opiera się na bieżącej transmisji danych lokalizacyjnych, które wysyłane są do zdalnej bazy, gdzie są według odpowiednich procedur przekształcane w wektory ścieżki złożone z   asynchronicznych LR-ów. W niniejszym przypadku dane rejestrowane były w tabeli visit_path. W tabeli tej zapisywane są identyfikatory LR-a (Id), atrakcji (poi_id) i wizyty (visit_id),  oraz LTin (date_in) i LTout (date_out) czyli czasy wejścia i wyjścia z obszaru DA atrakcji. Identyfikatora wizyty nie należy mylić z identyfikatorem użytkownika, gdyż zakłada się, że jedna osoba może wizytować obiekt wielokrotnie.  W tabeli zapisywane są również tzw. okresy „silent period”, tj. interwały czasowe, dla których zwiedzający znajduje się poza jakimkolwiek DA. W takim przypadku pole poi_id jest ustawiane na NULL (/N)

Przykładowy wektor ścieżki dla jednego ze zwiedzających przedstawia poniższy rysunek. Z tabeli wynika, że zwiedzający rozpoczął wizytę o 9:55:56 od „atrakcji” 36 (wejście/wyjście) i zakończył o godz. 10:34:04 w tej samej lokalizacji. Zwiedzający odwiedził następnie atrakcje o numerach 37, 39, 42, 40, 43 i 33.

Podobnie jak w wariancie wewnątrzbudynkowym, zarejestrowane dane pozwalają na wyznaczenie profilu VP dla użytkownika statystycznego (średnie wartości dla każdego z użytkowników) – rys. 6.

Podczas eksperymentu monitorowano również stan wskaźników oraz parametry dynamiczne aplikacji. Jednym ze wskaźników jest podawana na bieżąco informacja o obciążeniu poszczególnych atrakcji z listy. Stwierdzono, że wskazywany moment czasowy wkroczenia w obszar DA może być opóźniony w stosunku do czasu rzeczywistego o nie więcej niż 10-15s, co jest wartością dopuszczalną. Natomiast moment opuszczenia DA może być opóźniony o 20-30 sekund co związane jest z zaimplementowanym algorytmem wygładzającym niwelującym ryzyko fałszywie pozytywnych sygnałów o opuszczeniu DA. Uwzględniając konieczność zaimplementowania mechanizmów typu „KeepAlive”, dopuścić należy większą wartość opóźnienia. W związku z tym okres 30s również jest akceptowalny. W rezultacie średni zmierzony czas przebywania  w atrakcji może być obarczony błędem systematycznym na poziomie 15s, co w przypadku dłuższych kilkunastominutowych wizyt jest wartością pomijalną, lub poddającą się korekcie.