Witajcie!

Podczas dyskusji dotyczącej IoT nie sposób nie poruszyć zagadnienia beaconów.

W przeciwieństwie do sensorów, które analizują i badają środowisko oraz aktuatorów, które reagują na potrzeby sensorów, beacony stanowią nieustanny przekaźnik informacji, która wysyłana jest w powietrze. To niewielkich rozmiarów urządzenia, których zadaniem jest nieprzerwane emitowanie  pasma informacyjnego, które może być odczytane przez znajdujące się w pobliżu urządzenia SMART np. telefony komórkowe. Beacony są swego rodzaju latarnią morską, która nadaje w powietrze licząc, że ktoś będzie mógł skorzystać z przekazywanej informacji.

Sens instalowania tych urządzeń sprowadza się do możliwości nieinwazyjnego przekazywania informacji w sposób szybki, łatwy i bezpieczny. Sygnał wykryty przez SMART t urządzenie przekazuje unikalną wartość ID beacona, którą telefon, przy pomocy Internetu i „chmury”, rozkodowuje na postać polecenia. Każdy beacon ma bowiem unikalną wartość, tak samo jak komputery mają unikalną wartość MAC, co pozwala je rozróżnić i nadać im unikalny charakter.

Co się tyczy kodowanej informacji – jest ona przekazywana w postaci paczki, która w zależności od standardu może zawierać:

• ID urządzenia
• Informację na temat zużytej energii
• Typ przekazywanych danych
• Czas życia baterii
• Dane dotyczące telemetrii
• Adres URL
• Ephemeral ID (rodzaj klucza zabezpieczającego)

Część danych służy serwisantom i analitykom, lecz z perspektywy użytkownika najważniejszy jest adres URL, który może aktywować  dla nas unikalną usługę. Unikalną w kontekście miejsca, czasu i typu klienta. W przypadku sklepów może to być np. zakodowany portal ze zniżkami na konkretne produkty. W przypadku lotnisk – informacja dotycząca najbliższego baru. W przypadku hotelu – adresy najtańszych taksówek itd.

Wszystko sprowadza się do kreatywności programistów, którzy starają się zaszyć w kodzie i zaoferować klientom unikalną wartość dodaną, która dyskretnie przyjdzie z pomocą gdy będą oni tego potrzebować.

O tę „troskę” walczą obecnie trzy standardy:

• iBeacon
• EddyStone
• AltBeacon

Pierwszy został opatentowany przez firmę Apple i prócz unikalnych adresów ID lokalizujących dany beacon (UUID, Major ID, Minor ID) w konkretnym kraju, pozycji i lokalizacji nie oferują w zamian nic więcej.

Eddystone wynaleziony został przez firmę Google, która, w przeciwieństwie do Apple, postawiła na otwarty standard. Otwarte rozwiązanie dedykowane na wiele platform (znów – w porównaniu do Apple) oprócz unikalnych adresów ID oferuje możliwość kodowania danych dotyczących URL, TLM (telemetria) oraz EID (ephemeral ID).

Ostatnim standardem jest AltBeacon – dostępne na gitHubie rozwiązanie open source , które nie przytłacza swym skomplikowaniem, jest intuicyjne w implementacji i pozwala deweloperom na szybką realizację projektów (w porównaniu do iBeacon oraz EddyStone formalności wdrażania i certyfikowania wydają się być dużo prostsze).

Rzecz jasna, jak każde rozwiązanie, i to posiada pewne wady i problemy, nad którymi trzeba się poważnie zastanowić. Po pierwsze beacony pozwalają na istnienie czegoś, co nazywa się piggybacking, a sprowadza się do doradzania klientowi na nie swoim środowisku. Dla przykładu mógłbym zainstalować beacon Sony w pobliżu sklepu sprzedającego produkty Samsung i twierdzić jak złym pomysłem jest kupno produktów koreańskich producentów. Po drugie istnieje showrooming czyli świadome przechwytywanie klientów i przekierowywanie ich  na „konkurencyjną” platformę. W końcu działa spoofing czyli imitowanie stanu np. klienta celem oszukania danego lokalu, w którym akcja wywoływana jest przez konkretną reakcję.

Stąd beacony nieustannie kojarzone są z tzw. planowanie 10P co odnosi się bezpośrednio do angielskich słów, które mają ułatwiać świadome i racjonalne montowanie beaconów w środowisku:

• Planning (gdzie dokładnie zamontujemy urządzenia, dla kogo, kto będzie z nich mógł skorzystać)
• Placement (dokładna, fizyczna lokalizacja w kontekście terenu i właściwości budynku)
• Propagation (siła sygnału, która musi trafić do określonego konsumenta)
• Procurement (świadomość, że beacon będzie rozgłaszał się wtedy i tylko wtedy gdy będzie to niezbędne; ergo sensowne umiejscowienie)
• Permission (czy lokalizacja wiąże się z dodatkowymi uprawnieniami, zgodami itp.)
• Privacy (umieszczenie widocznej notyfikacji o tym, że lokal znajduje się w obrębie działania beaconów)
• Process (prawidłowe ID i  inne aspekty techniczne)
• Power (na jak długo działa jeden cykl baterii)
• Presentation (jak prezentuje się samo urządzenie tzn. walory estetyczne dla klientów i lokalu)
• People (kto się zajmie dodatkowymi działaniami jak utrzymanie etc.)

a co w konsekwencji ma usprawnić wdrażanie beaconów do środowiska.

Poprawna implementacja beaconów wydaje się pozornie prosta. Generuje jednak szereg poważnych wątpliwości, które należy rozwiązywać na każdym etapie wdrażania. Tylko wówczas producenci, sprzedawcy oraz konsumenci zauważą potencjał ukryty w tych urządzeniach. Bo prawda jest taka, że choć beacony kojarzone są dotychczas z drobnym rozmiarem i niewielkimi technologicznymi możliwościami w praktyce, odpowiednio obsłużone, mogą wnosić sporą wartość dodaną do naszego życia.

Pozdrawiam,

Marcin Sikorski

W razie wątpliwości, pytań lub tematu do dyskusji zawsze można pisać do mnie na mail: marcin.sikorski@test-engineer.pl  lub odwiedzić stronę www.test-engineer.pl gdzie poruszam jeszcze więcej tematyki związanej z IoT.

O autorze

Fan i pasjonat Internetu Rzeczy oraz systemów wbudowanych #embedded, który profesjonalnie acz bezlitośnie weryfikuje SMART produkty światowych marek. Od 5 lat pracuje jako Test Engineer (a ostatnio również Test Lead) w firmie Tieto. Po godzinach – pasjonat szeroko pojętej optymalizacji, Chin, wspinaczki oraz kultury. Na co dzień prowadzi bloga: test-engineer.pl