Internet Rzeczy (IoT) to zestaw technologii, które poprawiają funkcjonalność mogących się ze sobą łączyć i komunikować urządzeń IoT. IoT wraz z różnymi zaawansowanymi technologiami i urządzeniami jest źródłem szybkiej transformacji współczesnego społeczeństwa — w społeczeństwo prostsze i inteligentniejsze.

Według ostatnich badań, wśród wszystkich innych dostępnych technologii bezprzewodowych, sygnalizatory BLE (Bluetooth Low Energy) okazały się bardzo obiecującą technologią komunikacji bezprzewodowej krótkiego zasięgu, ponieważ pojawiają się bardzo często lub są bardzo powszechnie stosowane w technologii kompatybilnej z Bluetooth.

Sygnalizator BLE składa się zazwyczaj z 32-bitowego procesora ARM Cortex-M0 oraz nadajnika radiowego taktowanego zegarem 2,4 GHz z Bluetooth 4.0 Smart. Bluetooth SIG (Special Interest Group) zarządza kilkoma wersjami urządzeń Bluetooth Smart. SIG twierdzi, że te sygnalizatory mogą nadawać w promieniu do 70 metrów (230 stóp). Według naszych badań, w warunkach rzeczywistych użytkownicy w praktyce osiągali zasięg około 40–50 metrów ze względu na wpływ hałasu i przeszkód. Inteligentne urządzenia BLE mogą wykryć częstotliwość nadawanego sygnału i obliczyć odległość w drodze pomiaru siły odbieranych sygnałów (RSS). Sygnalizatory BLE to małe urządzenia, które okresowo wysyłają określone pakiety danych, aby wskazać obecność lub przeprowadzić transmisję określonych informacji. Sygnalizator jest ogólnie przydatny w wewnętrznych systemach nawigacji i pozycjonowania.

Protokoły sygnalizatorów

Obecnie istnieją dwa główne rodzaje protokołów programowych wykorzystywanych do śledzenia sygnalizatora i pozwalających sygnalizatorowi na komunikację z programem lub przeglądarką. Można je głównie sklasyfikować jako:

  • Protokół iBeacon oparty na aplikacji
  • Protokół Eddystone oparty na przeglądarce
  • Sygnalizator BLE
    Rysunek 1: Sygnalizator BLE

Zachodzi przy tym do pewnego nakładania się, ponieważ identyfikator UUID (Eddystone Universal Unique Identifier) w rzeczywistości działa z aplikacjami, ale ogólnie każdy protokół jest ograniczony do pracy z aplikacjami lub przeglądarkami. Same sygnały mogą być skonfigurowane do pracy z każdym z tych protokołów i używane do różnych celów.

  • Protokół iBeacon pozwala na wysyłanie powiadomień w tle lub w tle aplikacji, umożliwiając powiadomienie aplikacji, gdy użytkownik otrzyma wiadomość.
  • Protokół Eddystone komunikuje się z przeglądarką internetową, która musi być otwarta, aby użytkownik otrzymał wiadomość/adres URL. Powiadomienia w tle są obsługiwane przez system Android, ale nie system iOS.

Sygnalizator i interakcja BLE

Uwzględniając najpopularniejszy protokół iBeacon, sygnalizator przesyła pojedynczy pakiet danych składający się z czterech rodzajów informacji. UUID, Major, Minor, cal Tx Power — połączenie tych informacji pozwala na odnajdywanie, nawigowanie i rozpoczynanie rozmowy z użytkownikiem. Wszystkie informacje zamieszczono poniżej:

  • UUID: Jest to 16-bajtowy ciąg znaków używany do rozróżniania dużych grup powiązanych sygnalizatorów. Na przykład, jeśli Coca-Cola utrzymuje sieć billboardów w sieci supermarketów, wszystkie billboardy Coca-Coli używają tego samego UUID. Dzięki temu aplikacja Coca-Cola na smartfony może zobaczyć, które reklamy pomocnicze pochodzą ze znaczników Coca-Cola.
  • Major: Jest to 2-bajtowy ciąg używany do oznaczania mniejszego podzbioru sygnalizatorów w ramach większego zestawu. Na przykład, jeśli Coca-Cola ma cztery sygnalizatory w danym supermarkecie, wszystkie cztery światła są takie same. Dzięki temu Coca-Cola wie dokładnie, w którym sklepie znajduje się klient.
  • Minor: Jest to 2-bajtowy ciąg identyfikujący każdy sygnalizator. Dalej z przykładem Coca-Coli: sygnalizator przed sklepem Minor będzie miał przypisany unikalny element. Dzięki temu specjalny program Coca-Coli wie dokładnie, gdzie w sklepie znajduje się klient.
  • cal Tx Power: Skalibrowana moc nadawania służy do określenia bliskości sygnalizatora. Zasady działania Cal Tx Power to siła sygnału, którego źródło znajduje się dokładnie jeden metr od urządzenia. Musi być ona skalibrowana i wstępnie zakodowana. Narzędzia mogą następnie wykorzystać to jako podstawę do przybliżonego oszacowania odległości. cal Tx nie należy mylić z Tx power. Pierwsza z informacji jest przeznaczona dla Apple, natomiast druga to rzeczywista ilość mocy nadawania sygnalizatora, która w dużej mierze zależy od fizycznych ustawień i możliwości sygnalizatora.

Powyższe różni się to nieco w przypadku protokołu Eddystone, w którym wysyłane są trzy pakiety danych — UID, URL i TLM:

Eddystone‐UID ma długość 16 bajtów i jest podzielony na dwie części:

  • Namespace (10 bajtów) — jego przeznaczenie jest podobne do iBeacon UUID. W przypadku iBeacon zazwyczaj przypisywany jest unikalny UUID do wszystkich sygnalizatorów, aby łatwo odfiltrować je spośród innych sygnałów. W przypadku Eddystone-UID to samo jest możliwe z przestrzenią nazw.
  • Instance (6 bajtów) — służy temu samemu celowi, co iBeacon dużych i małych liczb, aby zidentyfikować indywidualne sygnalizatory. Dla sygnałów Estimote, które odzwierciedlają Eddystone UID, instancja jest wyświetlana jako ciąg do 12 znaków.

Eddystone‐URL
— pakiet Eddystone URL zawiera jedno pole URL. Rozmiar pola zależy od długości adresu URL.

Eddystone‐TLM
— pakiet Eddystone TLM jest przeznaczony do dystrybucji przez pilota pakietów „danych” (tj. UID i/lub URL) dla celów zarządzania flotą. Pobliskie urządzenia Bluetooth mogą odczytać te pakiety i wysłać je do usługi zarządzania flotą. Na przykład usługa ta może ostrzec właściciela przewodnika turystycznego, że bateria jest niska. Pakiet telemetryczny składa się z:

  • Wartości napięcia baterii, które może być użyte do oszacowania poziomu naładowania baterii sygnalizatora
  • Temperatura sygnalizatora
  • Liczba pakietów wysłanych od ostatniego włączenia lub ponownego uruchomienia sygnalizatora; czas działania sygnalizatora, czyli czas, jaki upłynął od ostatniego włączenia lub ponownego uruchomienia.

Istnieją inne rodzaje protokołów, ale te wymienione to dwa główne protokoły, które są wykorzystywane komercyjnie. Oprócz iBeacon i Eddystone istnieje również Altbeacon (opracowany przez iBeacon po sprawie o naruszenie patentu przez Radius Networks, czyli otwarty standard). Przed Eddystone Google pracował nad flagami URI, czyli standardem, który później doprowadził do powstania pakietu Eddystone URL. Obecnie protokół Eddystone jest jeszcze stosunkowo nowy i dlatego prawdopodobnie nastąpi szybka poprawa jego zastosowania i wydajności. Zachęcamy do zapoznania się z tematem Rozwiązania łączności bezprzewodowej dla Internetu Rzeczy (IoT) (dokumentacja), aby dowiedzieć się więcej o technologii BLE.

Możliwości badawcze sygnalizatorów BLE

Po długich studiach/badaniach nad sygnalizatorem BLE możemy być pewni, że jest on wykonalny i przydatny w zastosowaniach IoT. Elastyczność, niewielki koszt sprzętu i łatwość wdrożenia z BLE dają deweloperom więcej swobody i sprawiają, że infrastruktura jest bardziej opłacalna i skalowalna. Jednak wciąż istnieją pewne zauważalne błędy, takie jak np. ograniczona żywotność baterii, interoperacyjność między różnymi profilami BLE, słaby poziom bezpieczeństwa itd. Aby przezwyciężyć powyższe wady, po omówieniu niektórych możliwości sygnalizatorów BLE, zasugerowano przyszłe kierunki badań.

Sygnalizator musi obsługiwać oba protokoły (iBeacon i Eddystone) jednocześnie.

Protokoły detektorów BLE obsługują tylko jeden typ protokołu w tym samym czasie. Istnieją dwie ramy działań dla protokołów iBeacon i Eddystone. Wykresy dziennika są różne. Niektórzy programiści zbudowali Beacon do obsługi obu protokołów, ale w praktyce może on obsługiwać tylko jeden protokół w tym samym czasie. Deweloperzy lub użytkownicy muszą ręcznie przełączać się między protokołami. Podczas gdy większość projektantów integruje ten obwód, aby ułatwić obsługę obu protokołów, przełączanie musi być wykonane podczas fazy rozwoju lub konfiguracji. Kiedy trener jest wdrożony z określonym protokołem, bardzo trudno jest zmienić tryb protokołu. Obecnie na rynku nie ma żadnego konkretnego projektu, który obsługiwałby oba protokoły jednocześnie. Istnieje potencjał dla badań i rozwoju w tym obszarze, aby zaproponować projekt sygnalizatora BLE, który obsługuje oba protokoły jednocześnie.

Sygnalizator musi realizować interakcje typu „many-to-many” (wiele-do-wielu).

W dobie Internetu Rzeczy ważne było, aby na danym obszarze występowało wiele interakcji przy wielokrotnych wdrożeniach sygnalizatorów. Jednak w środowisku instalacji o wysokiej wiązce, zakłócenia są problemem, który odrywa od płynnej, nieprzerwanej interakcji. W takim środowisku sygnały mogą się wzajemnie zakłócać tylko wtedy, gdy znajdują się blisko siebie. Traktujemy powyższy problem jako okazję badawczą, czyli pracę, i proponujemy projekt sygnalizatorów BLE, który umożliwia interakcję między wieloma osobami w sieci.

Efektywność energetyczna sygnalizatorów BLE

W przypadku bezprzewodowych sieci czujników jest to możliwe, choć urządzenia o małej mocy zostały dobrze zbadane. Pozyskiwanie energii BLE jest użyteczne tylko w środowisku zewnętrznym. W przypadku środowiska wewnętrznego nie ma to większego sensu, wymagane jest badanie gromadzenia energii w środowiskach wewnętrznych. Ze względu na podobne ograniczenia w przechowywaniu energii wewnątrz, urządzenia IoT zazwyczaj wymagają lekkich protokołów transmisji danych optymalizujących wykorzystanie zasobów i zużycie energii. Powyższe zagadnienie traktujemy jako potencjał do dalszych badań, tzn. proponujemy pracę i projektowanie lekkich protokołów w różnych warstwach stosu IoT. Lekkie podejście do przesyłania danych zwiększa żywotność baterii urządzenia i zmniejsza opóźnienia i wpływa na jakość usługi (ang. Quality of Service — QoS). Lekkie podejście do protokołów oznacza przesyłanie tylko małych ilości danych, zmniejszając wymagania komunikacyjne, wysiłek obliczeniowy i małą pojemność pamięci masowej. Zastosowanie standardowych protokołów w obecnym systemie IoT zapewnia skalowalność, interoperacyjność i wydajność systemu. Dlatego takie lekkie protokoły muszą charakteryzować się następującymi cechami:

  • Kompatybilność z każdym innym już istniejącym protokołem.
  • Elastyczność w celu wdrożenia w obrębie sygnalizatorów, elektroniki noszonej lub bardziej wytrzymałych bramek.
  • Skalowalność, aby wspierać aplikacje na nowo zmodernizowanej platformie.

Lepsze szacowanie odległości

Zgodnie z recenzowanymi badaniami, ze względu na niestabilność sygnałów BLE, bardzo trudno było uzyskać dokładne oszacowanie odległości. Najbliższe źródła sygnału mogły być łatwo zidentyfikowane, ponieważ źródła sygnału nie były w bliskiej odległości od siebie, w przeciwieństwie do infrastruktury sygnalizatorów. W związku z tym niedokładny pomiar RSS stwarza problemy z oszacowaniem odległości sygnalizatorów. Zmiany wartości RSS są nowym wyzwaniem w rozwoju aplikacji związanych z sygnalizatorami. W przyszłości pomiar RSS wymaga stabilizacji w celu uniknięcia wahań parametrów odległości. Powyższy problem traktujemy jako szansę badawczą tj. opracowanie i zaproponowanie projektu sygnalizatora BLE, który pozwoli osiągnąć lepsze założenie dokładności, gdyż RSS sygnalizatora będzie się różniło dla każdego z urządzeń.

Zestaw sygnalizatora BLE

Projektowy zestaw referencyjny (ang. Reference Design Kit — RDK) CYALKIT-E02 sygnalizatora czujnika BLE zasilanego energią słoneczną został zaprojektowany, aby pomóc w tworzeniu miniaturowych, zasilanych energią słoneczną urządzeń IoT z łącznością bezprzewodową BLE. Zestaw RDK zawiera solarny czujnik BLE, jak również mostek BLE-USB i płytkę do debugowania. Solarny czujnik BLE jest oparty na układzie scalonym zarządzania zasilaniem (PMIC) energią pozyskiwaną S6AE103A od Cypress i module EZ-BLE™ PRoC™. Czujnik został zaprojektowany do pozyskiwania energii ze słońca lub oświetlenia wewnętrznego i pracy bez baterii.

Bądź na bieżąco


Nadążaj za najnowszymi informacjami i ekskluzywnymi ofertami!

Subskrybuj teraz

Polityka prywatności

Dzięki za subskrypcję

Dobra robota! Należysz teraz do elitarnej grupy, która otrzymuje najnowsze informacje o produktach, technologiach i aplikacjach prosto do swojej skrzynki e-mail.