Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

LoRa bezprzewodowa łączność dla IoT - wdrożenie Etteplan we Wrocławiu.

TechEkspert 03 Mar 2017 21:25 5925 7
Computer Controls
  • LoRa bezprzewodowa łączność dla IoT - wdrożenie Etteplan we Wrocławiu.
    LoRa to sposób komunikacji pozwalający na budowę bezprzewodowej sieci LPWAN (Low Power Wide Area Network), czyli sieci pozwalającej na łączność na dużym obszarze z wykorzystaniem pasma ISM i niskiej mocy wypromieniowanej z anteny. LoRa pozwala na transmisję niewielkich ilości danych np. raportów z energooszczędnych urządzeń IoT zasilanych bateryjnie. Bramki LoRa pozwalają na agregację i przekazywanie danych z wykorzystaniem internetu. Na uwagę zasługuje też rodzaj modulacji zastosowany w LoRa, który m.in pozwala na zwiększenie odporności na zakłócenia przy umiarkowanej złożoności transceivera. Symbole oznaczające zera i jedynki to stopniowe zmiany (zwiększanie lub zmniejszanie) częstotliwości, w odróżnieniu od prostych modulacji np. FSK gdzie zmiany częstotliwości występują skokowo lub OOK gdzie symbolem jest obecność lub brak obecności sygnału. Taki sposób modulacji zapewnia mniejszą przepustowość niż np. modulacje kwadraturowe, jednak jest to kompromis zapewniający wystarczające parametry dla urządzeń o niskiej aktywności przesyłających krótkie paczki danych.
    Dodatkowo LoRa wykorzystuje kodowanie nadmiarowe. 
     
    Mamy okazję zapytać firmę Etteplan o wnioski z wdrożenia LoRa we Wrocławiu oraz skonfrontować teorię z praktyką LPWAN.
     
    elektroda.pl: Czym zajmuje się firma Etteplan, co skłoniło Państwa do podjęcia projektu związanego z LoRa? 

    Etteplan: Etteplan jest międzynarodowym biurem projektowym R&D (Badania i Rozwój) zajmującym się systemami wbudowanymi dla różnych sektorów gospodarki, takich jak przemysł, telekomunikacja, medycyna, branża zbrojeniowa, motoryzacja, automatyka budynków oraz AGD. Firma powstała w 1983 roku i obecnie Etteplan ma swoje biura w 8 krajach świata: Finlandii, Szwecji, Polsce, Niemczech, Holandii, Rosji, Chinach i USA, gdzie łącznie zatrudnia ponad 2500 specjalistów w dziedzinie elektroniki, radiokomunikacji, oprogramowania, systemów wbudowanych, Internetu przemysłowego oraz dokumentacji technicznej. W Polsce firma ma biura we Wrocławiu, gdzie funkcjonuje od 2010 roku i od tego czasu zbudowała zespół ponad 150 doświadczonych specjalistów oraz nowo otwarte biuro w Poznaniu.

    elektroda.pl: Ile bramek LoRa udało się uruchomić, jakie typowe i maksymalne zasięgi udało się uzyskać?

    Etteplan: Na bazie projektów realizowanych dla naszych Klientów uruchomiliśmy kilkanaście sieci prywatnych realizujących dedykowane zadania. Aktualnie publicznie dostępne są nasze 2 bramki we Wrocławiu, a kolejną planujemy w najbliższym czasie uruchomić w okolicach nowego biura w Poznaniu.

    W ramach naszego rozwiązania wykorzystujemy bramkę MultiConnect Conduit, zbudowaną przez naszego partnera - firmę Multitech, zmodyfikowaną o obudowę klasy IP67, odpowiedni zasilacz PoE i oprogramowanie.

    Jeżeli chodzi o część antenową to wybraliśmy antenę firmy Taoglas - antena Barracuda OMB.868.B08F21.

    Dla ww. konfiguracji sprzętowej otrzymaliśmy 100% pokrycie terenu na dystansie 3.5 – 4.5km od bramki w zależności od zurbanizowania terenu. W przeprowadzonych testach pojawiały się również transmisje na dystansach 6 do 8 km przy urządzeniu końcowym umieszczonych w pojeździe.

    elektroda.pl: Jakiego rodzaju urządzenia IoT brały udział w testach sieci, jaka jest pojemność zbudowanej sieci? 

    Etteplan:  W testach wykorzystujemy zarówno własne rozwiązania, w tym płytkę ewaluacyjną ELMO (ELMO – Etteplan LoRa MOdule) dla której oprogramowanie jest dostępne w ramach platformy mbed firmy ARM (której jesteśmy partnerem), jak i gotowe rozwiązania dostarczane przez naszego partnera technologicznego - firmę Multitech (Conduit, mDot, xDot) oraz urządzenia firm trzecich jak np. Semtech, Microchip czy Airly.

    LoRa bezprzewodowa łączność dla IoT - wdrożenie Etteplan we Wrocławiu.

    Jeżeli chodzi o ilość obsługiwanych urządzeń to warto ten temat rozpatrywać w kontekście „pojemności” pojedynczej bramki. Ilość obsługiwanych urządzeń przez bramkę zależy od wielu aspektów:
    - używanej szerokości kanału transmisyjnego,
    - ilości przesyłanych danych,
    - częstotliwości z jaką dane są wysyłane
    - używania lub nie funkcjonalności ADR (Adaptive Data Rate – dostosowywania parametrów transmisji urządzeń końcowych przez bramkę, do której są podłączone na podstawie parametrów odbieranych danych) i powiązanego z nim parametru nazywanego SF (Spreading Factor).

    Wszystkie te parametry powodują, że pojemność danej sieci waha się od kilkuset to dziesiątek tysięcy urządzeń, które mogą być obsłużone w ramach jednej bramki.

    elektroda.pl: Jaka jest konstrukcja mechaniczna i elektroniczna bramki, ile kanałów obsługuje transceiver oraz jak zrealizowane jest połączenie z Internetem? 

    Etteplan: Urządzenie typu bramka to komputer przemysłowy wyposażony w moduł rozszerzający jego funkcjonalność o komunikację w technologii LoRa. W tego typu modułach wykorzystuje się dedykowany układ radiowy SX1301, który ma możliwość równoczesnego odbioru danych na 8 różnych kanałach / częstotliwościach. Komputer ten, dodatkowo może być rozszerzony o moduły umożliwiające podłączenie go do Internetu z wykorzystaniem połączenie przewodowego czy bezprzewodowego – karty WiFi lub modemu 3G.

    elektroda.pl: Jakie jest obecne zastosowanie dla zbudowanej sieci LPWAN, kto może się z nią połączyć i jak może ją wykorzystać, czy planowana jest rozbudowa sieci?  
     
    Etteplan: Bramka uruchomiona przez Etteplan jest jedną z setek bramek dostępnych w ramach open-source’owej inicjatywy The Things Network – bramka została skonfigurowana tak, aby cały ruch był przekazywany do platformy TTN, która m.in. zarządza zasobami danej bramki, umożliwia zarządzanie urządzeniami, a także pełni funkcję brokera odbieranych danych.

    Każda osoba ma możliwość założenia konta na TTN i utworzenia aplikacji, do której będą przekazywane dane z urządzeń. Oczywiście urządzenia te musza znajdować się w zasięgu dowolnej bramki obsługującej TTN.

    elektroda.pl: Czy LoRa zapewnia poufność oraz integralność dla danych przesyłanych przez urządzenie IoT? 
     
    Etteplan: Zabezpieczenia zdefiniowane na poziomie standardu gwarantują poufność oraz integralność danych. Standard definiuje dwa typy symetrycznych kluczy unikalnych dla każdego urządzenia:
    - klucz sieciowy (NwkSkey) używany na warstwie sieciowej podczas transmisji z urządzenia do serwera/bramki i wykorzystywany jest do sprawdzenia poprawności/integralności odebranych danych;
    - klucz aplikacji (AppSkey) – AES-128 - używany do szyfrowania danych na poziomie aplikacji.

    Wyżej wymienione klucze są kluczami unikalnymi generowanymi dla każdego urządzenia każdorazowo gdy wykona operację przystąpienia (JOIN’a) do sieci. Na poniższych rysunkach przedstawiono jak ww. klucze wykorzystywane są do szyfrowania poszczególnych fragmentów całej ramki oraz które klucze na jakim poziomie sieciowym.

    LoRa bezprzewodowa łączność dla IoT - wdrożenie Etteplan we Wrocławiu.

    LoRa bezprzewodowa łączność dla IoT - wdrożenie Etteplan we Wrocławiu.

    W praktyce często funkcjonalność serwera LoRa jest uruchomiona na bramce. To samo dotyczy funkcjonalności serwera aplikacyjnego. Bezpieczeństwo przechowywania ww. kluczy powinno być zaimplementowane zarówno przez producentów bramek czy operatorów danej sieci, jak i przez producentów urządzeń końcowych (node’a).

    elektroda.pl: Czy możemy wykluczyć możliwość podszycia się pod nasze urządzenie IoT, czy możemy mieć pewność że dane pochodzą od naszego urządzenia? 
     
    Etteplan: Urządzenia komunikujące się w technologii LoRa zabezpieczone są unikalnymi kluczami generowanymi każdorazowo w momencie połączenia urządzenia do sieci, więc ataki typu „man-in-the-middle” nie powinny mieć miejsca. Natomiast istnieje wiele innych zagadnień dotyczących bezpieczeństwa zarówno po stronie serwera jak i urządzeń końcowych takich jak:
    - zabezpieczenie klucza ABP związanego z aktywacją przez personalizację (Activation By Personalization). Klucze tego typu generowane są najcześciej na etapie produkcji urządzenia, zapisywane zarówno w jego pamięci jak i po stronie serwera. Klucze te powinny być bezpiecznie przechowywane, najlepiej z wykorzystaniem dedykowanego układu szyfrującego po stronie urządzenia końcowego,
    - zabezpieczenie kluczy podczas dynamicznej aktywacji typu OTAA (Over The Air Activation) - urządzenie końcowe wysyła do bramki AppKey, który musi być przekazany do serwera sieciowego LoRa z wykorzystaniem bezpiecznego połączenia np. HTTPS. Na podstawie tego klucza generowane są 2 klucze sesyjne,
    - zarządzanie kluczami - standard LoRa definiuje klucze symetryczne na potrzeby szyfrowania I autentykacji. Klucze te muszą być przechowywane zarówno po stronie serwera, jak i urządzenia końcowego - dwa miejsca, które muszą posiadać odpowiednie zabezpieczenia,
    - osoba mająca dostęp do kluczy (appKey, NwkSKey oraz AppSKey) dla danego urządzenia może się łatwo pod nie podszyć. Dlatego też klucze muszą być bezpiecznie przechowywane, a pamięć w której są przechowywane zabezpieczona przed odczytem z zewnętrznego urządzenia.

    Ww. zagadnienia powinny być każdorazowo rozpatrzone w ramach implementowanego rozwiązania, a zagrożenia w miarę możliwości i potrzeb zminimalizowane lub wykluczone.

    elektroda.pl: Czy każda zainteresowana osoba może uruchomić swoją otwartą dla wszystkich lub prywatną bramkę LoRa czy też występują jakieś ograniczenia? 
     
    Etteplan: Oczywiście, że tak - nie ma żadnych ograniczeń prawnych co do możliwości uruchomienia takiej bramki, niezależnie czy będzie ona prywatna czy publiczna. Trzeba zwrócić jednak uwagę na stosowanie certyfikowanych urządzeń spełniających wymagania zarówno samego standardu LoRa jak i norm europejskich (w tym normy EN300220 dotyczących komunikacji w paśmie poniżej 1 GHz), które definiują m.in. dopuszczalne moce nadawania, częstotliwości użytkowe, zajętość pasma itd.
     
    elektroda.pl: Jak z punktu widzenia wykonanego wdrożenia można ocenić przyszłość i zastosowania LoRa w Polsce i globalnie oraz innych sieci LPWAN? 
     
    Etteplan: W ujęciu globalnym liderami we wdrażaniu technologii LoRa jest Francja oraz Holandia, a także Finlandia. W tych krajach operatorzy komórkowi dostrzegli duży potencjał tej technologii i rozszerzają istniejącą infrastrukturę dla technologii komórkowych (GSM/WCDMA/LTE) o sprzęt, umożliwiający komunikację w technologii LoRa.

    W Polsce na chwile obecną nie zauważamy większego zainteresowania wśród dużych operatorów komórkowych. Pojawiają się natomiast mniejsze firmy zainteresowane budową sieci działających w technologii LoRa w ujęciu lokalnym.
     
    elektroda.pl: Można zauważyć, że operatorzy komórkowi wdrażają rozwiązania dedykowane do komunikacji IoT/M2M czy jest miejsce na koegzystowanie łączności LTE-M/5G NB-IoT i sieci LPWAN typu LoRa/SIGFOX/Bluetooth 5.0? 
     
    Etteplan: Wymienione technologie będą ze sobą koegzystowały pod względem fizycznym jak i użyteczności. Jeżeli chodzi o rożne technologie – w tym LoRa i SIGFOX – działające na częstotliwościach 868/915 MHz z pewnością ich im więcej technologii tym większe ograniczenia co do swobodnej dostępności kanałów transmisyjnych i więcej potencjalnych oddziaływań zakłócających. W tym kontekście na korzyść technologii LoRa przemawia wykorzystywana w niej technika rozpraszania widma DSSS (Direct Sequence Spread Spectrum) z wykorzystaniem ciągów kodowych. Transmisja może odbywać się poniżej poziomu szumu co dodatkowo zwiększa skuteczność w przesyłaniu danych.

    Z pewnością każda z technologii posiada swoje plusy i minusy (zasięg, pobór prądu, przepustowość, koszty wdrożenia, dostępność infrastruktury itd.), które w zależności od potrzeb i funkcjonalności danego urządzenia czy rozwiązania będą musiały być wzięte pod uwagę w celu wybrania najbardziej odpowiedniego rozwiązania.
     
    elektroda.pl: Dziękujemy za rozmowę oraz dostarczenie sporej dawki praktycznych informacji o LoRa.

    Dajcie znać o wynikach swoich eksperymentów z LoRa, być może osobom zamieszkałym we Wrocławiu lub Poznaniu uda się przesłać dane z wykorzystaniem bramek uruchomionych przez firmę Etteplan?  

    Cool? Ranking DIY
    About Author
    TechEkspert
    Editor
    Offline 
    W moich materiałach znajdziecie testy i prezentacje sprzętu elektronicznego, modułów, sprzętu pomiarowego, eksperymenty. Interesuje mnie elektronika cyfrowa, cyfrowe przetwarzanie sygnałów, transmisje cyfrowe przewodowe i bezprzewodowe, kryptografia, IT a szczególnie LAN/WAN i systemy przechowywania i przetwarzania danych.
    Has specialization in: mikrokontrolery, rozwiązania it
    TechEkspert wrote 4482 posts with rating 3636, helped 12 times. Been with us since 2014 year.
  • Computer Controls
  • Computer Controls
  • #3
    TechEkspert
    Editor
    @xSzwagier ciekawe czy jesteś w zasięgu bramki?
    https://www.thethingsnetwork.org/map

    Może udałoby Ci się udostępnić tutorial jak wysłać dane do sieci TTN z wykorzystaniem modułu Semtech SX1276/77/79 lub HOPERF RFM95W ?

    Na arduino dostępna jest biblioteka Arduino-LMIC:
    https://github.com/matthijskooijman/arduino-lmic

    Patrząc na przykład dla Dragino LoRa Shield pierwsze kroki są dość proste, uproszczone implementacje działają także na Arduino Pro Mini

    Przez przypadek natrafiłem też na super tanią jednokanałową "bramkę" LoRa<->Wi-Fi oczywiście na ESP8266 :)
  • #4
    markovip
    Level 34  
    Witam,
    W artykule jest dość poważny błąd w nazewnictwie.

    LoRa jest warstwą fizyczną modelu OSI, natomiast omawiana tu LoRaWAN jest protokołem komunikacji.

    Tak przynajmniej jest dla sieci The Things Network.
    Dla sieci prywatnej Etteplan nie wiadomo, może stosują swój własny protokół(?).

    Będąc przy pytaniach do Etteplan, to jak wygląda sprawa z aktualizacjami OTA? Rzeczą dziś tak ważną w świeci IoT.


    Pozdrawiam
  • #6
    markovip
    Level 34  
    TechEkspert wrote:
    Co do OTA, przekażę pytanie, chodzi oczywiście o aktualizację klientów nie bramek?

    W rzeczy samej. W szczególności firmware.

    Pozdrawiam
  • #7
    xSzwagier
    Level 22  
    TechEkspert wrote:
    @xSzwagier ciekawe czy jesteś w zasięgu bramki?
    https://www.thethingsnetwork.org/map

    Może udałoby Ci się udostępnić tutorial jak wysłać dane do sieci TTN z wykorzystaniem modułu Semtech SX1276/77/79 lub HOPERF RFM95W ?

    Na arduino dostępna jest biblioteka Arduino-LMIC:
    https://github.com/matthijskooijman/arduino-lmic

    Patrząc na przykład dla Dragino LoRa Shield pierwsze kroki są dość proste, uproszczone implementacje działają także na Arduino Pro Mini

    Przez przypadek natrafiłem też na super tanią jednokanałową "bramkę" LoRa<->Wi-Fi oczywiście na ESP8266 :)

    Jestem. Nie mam niestety wymienionego przez Ciebie sprzętu ;/ Pomyślę nad kupnem i może dam znać :D
  • #8
    TechEkspert
    Editor
    @xSzwagier chyba się skuszę na RFM95W+jakieś arduino aby przetestować TTN.

    @markovip przekazuję obszerne wyjaśnienie od specjalistów Etteplan, muszę przyznać że dla mnie jest to bardzo ciekawe rozwinięcie tematu.

    Etteplan: Tak jak wspomnieliśmy powyżej, sieć jest dostępna publicznie w ramach TTN, wiec wykorzystuje LoRaWAN.

    Co do uprade'u firmware'u metodą Over-The-Air - nie ma metody zdefiniowanej w ramach standardu. Można zrealizować własną implementację (i takie implementacje realizowaliśmy dla Naszych klientów), ale trzeba być świadomym kilku faktów.

    Zastosowanie LoRaWAN narzuca pewne ograniczenia związane z zajętością pasma przez pojedyncze urządzenie. Zgodnie z normą EN300220 dla większości wykorzystywanych przez LoRaWAN częstotliwości jest to 1% zajętości pasma na dobę. Dla wąskiego pasma częstotliwości zajętość pasma może wzrosnąć do 10% czasu na dobę, ale w najlepszym przypadku dla LoRaWAN będą to 2 kanały transmisyjne, które jednocześnie mogą być 'okupowane' przez inne protokoły transmisyjne.

    Przy zajętości pasma rzędu 1% na dobę urządzenie nadające dane ciągiem przez 1 sekundę, przez kolejnych 99 sekund musi 'milczeć'.

    Czas 'on-Air' dla urządzeń wykorzystujących LoRaWAN mocno zależy od takich parametrów jak SF (Spreading Factor), szerokości pasma, CR (Coding Rate), długości przesyłanej paczki (w tym długości payload'u) itd. Szacunkową długość tzw. czasu 'On-Air' dla danej konfiguracji parametrów można oszacować z wykorzystaniem kalkulatora LoRa Modem Calculator Tool dostępnego na stronach firmy Semtech.

    Przykładowo:
    Chcemy uaktualnić oprogramowanie, które 'waży' 200kB. Załóżmy, że panują idealne warunki - każda wysłana paczka do i z urządzenia końcowego jest poprawnie odbierana, oraz że przesyłamy firmware w paczkach z payload'em po 100 bajtów - to oznacza 2000 paczek danych.
    Jeżeli pojedyncza transmisja zajmie ok. 1 sekundy, przez 99 sekund urządzenie nie może nadawać a to oznacza, że każda paczka będzie wysyłana
    w oknach czasowych co 100 sekund. Dla 2000 paczek cala transmisja zajmie 200000 sekund czyli ok. 55.5 godziny.

    55.5 godzin dla jednego urządzenia - jak zatem będą kształtować się te czasy w przypadku uaktualniania setek czy też tysięcy urządzeń... ?

    Powyżej przedstawiony przykład jest wyidealizowany - w rzeczywistości pojawi się wiele błędów transmisji, wiele ramek będzie musiało być retransmitowanych co najmniej raz, a to z kolei wydłuży proces przesyłania całości oprogramowania.

    Z pewnością przy operacji uaktualniania oprogramowania wzrośnie pobór prądu. Dodatkowo trzeba mieć na uwadze, że dla urządzeń działających w klasie A, każdorazowa transmisja pakietu musi być zainicjowana przez urządzenie końcowe (do którego będą przesyłane paczki nowego firmware'u) - inaczej urządzenie nie będzie w trybie nasłuchu.

    Ww. problem został częściowo wyeliminowany dla urządzeń klasy B, dla których możemy zdefiniować przedziały czasowe, w których urządzenie ma dodatkowo nasłuchiwać dane poza nasłuchem w dwóch oknach czasowych po nadaniu danych, ale w przypadku dużych odstępów pomiędzy ww. oknami czasowymi wciąż chcąc 'szybciej' uaktualnić oprogramowanie urządzenie końcowe będzie musiało inicjować wymianę danych. Dla urządzeń klasy C, które nasłuchują non-stop z wykluczeniem momentów, kiedy same wysyłają dane, ten problem nie istnieje. Dla urządzeń klasy C można pokusić się o implementację grupowego uaktualniania danych na zasadzie broadcast'u paczek do wszystkich urządzeń. Oczywiście trzeba uwzględnić sytuacje, w których nie wszystkie urządzenia będą poprawnie odbierały kolejne paczki danych i konieczność obsłużenia takich sytuacji.

    Reasumując... procedura uaktualnienia oprogramowania nie jest zdefiniowana na poziomie protokołu, ale może być zaimplementowana
    na poziomie firmware'u przy uwzględnieniu m.in. ww. zagadnień i powinna być każdorazowo uszyta na miarę.