Technologia Internetu Rzeczy: architektura, protokoły, zastosowania cz. 1

Transkrypt

1 Zakład Architektur i Zastosowań Internetu (Z-3) Zakład Badań Systemów i Urządzeń (Z-1) Zakład Systemów i Sieci Bezprzewodowych w Gdańsku (Z-8) Technologia Internetu Rzeczy: architektura, protokoły, zastosowania cz. 1 Praca nr (Z-3) Praca nr (Z-1) Praca nr (Z-8) Grudzień 2012

2 Technologia Internetu Rzeczy: architektura, protokoły, zastosowania cz. 1 Praca nr: (Zakład Z-3), (Zakład Z-1), (Zakład Z-8) Kierownik pracy: dr inż. Piotr Krawiec (Z-3) Wykonawcy pracy: dr inż. Krzysztof Bronk (Z-8) dr inż. Rafał Niski (Z-8) dr inż. Jerzy Żurek (Z-8) mgr inż. Adam Lipka (Z-8) mgr inż. Błażej Wereszko (Z-8) mgr inż. Piotr Wojnicz (Z-8) mgr inż. Krzysztof Żurek (Z-8) mgr inż. Aleksander Orłowski (Z-1) inż. Arkadiusz Staszak (Z-1) mgr inż. Mariusz Woźniak (Z-1) Copyright by Instytut Łączności, 2012

3 Spis treści Wykaz skrótów Wprowadzenie Przegląd i analiza propozycji architektury dla Internetu Rzeczy ETSI M2M standard Ogólny model identyfikacji dla M2M Wnioski Literatura CASAGRAS / CASAGRAS Główne założenia i cele projektu Wnioski Literatura Projekt SmartSantander Informacje podstawowe Cele i założenia projektu Wymogi dla architektury Architektura zaproponowanego rozwiązania Bloki funkcjonalne Wnioski Literatura IoT@Work Główne założenia i cele projektu Propozycja architektury IoT@Work Wybrane wymogi systemowe w ujęciu sieciowym Wnioski Literatura IoT Podstawowe informacje o projekcie Dostępne informacje na temat planowanej architektury Internetu Rzeczy Wnioski Literatura IoT-i Model referencyjny i architektura referencyjna Uwagi podsumowujące Literatura

4 2.7 Projekt icore Wnioski Literatura Projekt AKARI Model D i E Wniosek Bibliografia Projekt ASPIRE Wniosek Bibliografia Internet of Things Architecture (IoT-A) Warstwowy model komunikacyjny Wniosek Bibliografia Projekt SENSEI SENSEI (Real World) Resource Layer Communication Service Layer Platforma testowa zrealizowana w ramach projektu Wniosek Literatura Typy komunikacji sensor-sieć i ZigBee LoWPAN Bluetooth Podsumowanie Wypracowanie koncepcji sieci testowej IoT w IŁ Wprowadzenie Platforma sprzętowa Moduł radiowy RCB128RFA Moduł RCB Breakout Board Light Moduł czujników Układ ATmega128RFA Transceiver AT86RF Interfejs procesor transceiver Architektura sieci

5 3.3.1 Model warstwowy sieci Warstwa aplikacji Aplikacja sterująca Włączenie sieci do Internetu Trudności napotkane w trakcie realizacji projektu Wypracowanie koncepcji sieci testowej IoT w IŁ - wybór interfejsu radiowego Wybór interfejsu radiowego Urządzenia wykorzystane do testów Opisy konstrukcji Stworzenie sieci testowej IoT w IŁ Zakład Z Budowa sieci testowej Potencjalne aplikacje dla zaproponowanej platformy Koncepcja integracji zaproponowanego rozwiązania z siecią w standardzie 6LoWPAN 97 6 Stworzenie sieci testowej IoT w IŁ Zakład Z Opis sieci testowej Pomiar poziomu zakłóceń Próby retransmisji danych Pomiary charakterystyk promieniowania anteny modułu ATZB-24-A Zastosowanie opracowanego modułu w IoT Wnioski Podsumowanie Bibliografia Załącznik nr

6 Wykaz skrótów 6LoWPAN A/D ACK AES BMM CBTC COMPOW CRC CSMA-CA DistRNG EEPROM FCF FCS FLSS FSL GUI I2C ID KNeigh LILT LINT LMST LQI MECN PAL PAN PCB PHY PHR PLL PSDU QMM R&M RISC RN SAL SFD SMECN SPI SRAM S-XTC STB XTC TAL TFA USART WSN IPv6 over Low power Wireless Personal Area Networks Analog-to-Digital Converter Acknowledge Advanced Encryption Standard Buffer Management Cone-Based Topology Control COMmon POWer Cyclic Redundancy Check Carrier Sense Multiple Access with Collision Avoidance Distributed Relative Neighborhood Graph Electrically Erasable Programmable Read-Only Memory Frame Control Field Frame Check Sequence Fault-tolerant Local Spanning Subgraph Free Space Loss Graphic User Interface Inter-Integrated Circuit Identification Number k-neighbors Local Information Link-state Topology Local Information No Topology Local Minimum Spanning Tree Link Quality Indication Minimum-Energy Communication Network Platform Abstraction Layer Personal area network Printed circuit board Physical Layer (Warstwa fizyczna łącza radiowego) PHY Header Phase-Locked Loop PHY Service Data Unit Queue Management Rodoplu and Meng Reduced Instruction Set Computer Routing Node Security Abstraction Layer Start-of-Frame Delimiter Small Minimum-Energy Communication Network Serial Peripheral Interface Static Random-Access Memory S-eXtreme Topology Control Security Toolbox extreme Topology Control Transceiver Abstraction Layer Transceiver Feature Access Universal Synchronous and Asynchronous Serial Receiver and Transmitter Wireless Sensor Network 6

7 1 Wprowadzenie Niniejsza praca miała na celu przeprowadzenie przeglądu i analizy stanu sztuki w zakresie propozycji architektury proponowanych dla Internetu Rzeczy (ang. Internet of Things IoT), następnie zaś opracowanie koncepcji i zbudowanie sieci testowej dla przeprowadzania badań z zakresu IoT. Praca została podzielona na trzy etapy: 1. Etap I Przegląd i analiza propozycji architektury dla Internetu Rzeczy osoba odpowiedzialna: dr inż. Piotr Krawiec (Z-3) 2. Etap II Wypracowanie koncepcji sieci testowej IoT w IŁ osoba odpowiedzialna: dr inż. Rafał Niski (Z-8) 3. Etap III Stworzenie sieci testowej IoT w IŁ osoba odpowiedzialna: mgr inż. Aleksander Orłowski (Z-1) Opracowanie prezentuje wyniki prac przeprowadzonych w ramach poszczególnych etapów (etap I rozdział 2, etap II rozdział 3 i 4, etap III rozdział 4 i 5). Przegląd i analiza propozycji architektury dla Internetu Rzeczy 7

8 2 Przegląd i analiza propozycji architektury dla Internetu Rzeczy Autorzy: dr inż. Piotr Krawiec (Z-3) dr inż. Krzysztof Bronk (Z-8) dr inż. Rafał Niski (Z-8) dr inż. Jerzy Żurek (Z-8) mgr inż. Adam Lipka (Z-8) mgr inż. Błażej Wereszko (Z-8) mgr inż. Piotr Wojnicz (Z-8) mgr inż. Krzysztof Żurek (Z-8) mgr Hanna Pawlak (Z-8) mgr inż. Roman Nierebiński (Z-8) mgr inż. Aleksander Orłowski (Z-1) inż. Arkadiusz Staszak (Z-1) mgr inż. Mariusz Woźniak (Z-1) W niniejszym rozdziale przedstawiono najważniejsze informacje na temat wybranych projektów europejskich oraz standardów poświęconych Internetowi Rzeczy, ze szczególnym uwzględnieniem analizy rozważanych koncepcji architektury IoT. W pierwszej kolejności omówiony zostanie standard ETSI TS , dotyczący komunikacji pomiędzy urządzeniami (Machine to machine), a następnie zaprezentowana zostanie grupa projektów europejskich, w kolejności: CASAGRAS/CASAGRAS2, Smart Santander, IoT@Work, IoT6, IoT-i, icore, ASPIRE, IoT-A, SENSEI oraz japoński projekt AKARI. Na koniec rozdziału zaprezentowano przegląd głównych technologii wykorzystywanych budowy bezprzewodowych sieci sensorowych ( , ZigBee, 6LoWPAN i Bluetooth). 2.1 ETSI M2M standard Kierowany przez komitet techniczny ETSI standard komunikacji pomiędzy urządzeniami (Machine to machine) mający na celu ujednolicenie komunikacji end-to-end. Prace nad standardem rozpoczęły się w styczniu 2009 roku. Główne zadania komitetu technicznego to: zbieranie i analiza wymagań dla transmisji M2M od wybranych partnerów, rozwijanie i zarządzanie architekturą wysokiego poziomu dla komunikacji M2M, oferowani informacji i ekspertyz w obszarze komunikacji M2M, koordynacja rozwoju standardu ETSI M2M z innymi grupami standaryzacyjnymi. Prace nad standardem podzielono na trzy główne etapy [1]: I. Zebranie wymagań, które muszą zostać spełnione przez standard II. Stworzenie opisu architektury M2M wysokiego poziomu III. Dokładna specyfikacja systemu i opis protokołów W chwili obecnej etapy pierwszy i drugi zostały już ukończone, a etap trzeci jest w trakcie opracowywania. Podczas pierwszego etapu prac nad standardem zebrano ogólne wymagania, jakie powinien spełniać standard dla sieci i architektury M2M [2]: możliwość komunikacji z urządzeniami w trybie uśpienia, wiele trybów komunikacji - anycast, unicast, multicast i broadcast, zarządzanie harmonogramem dostępu do sieci i przesyłania wiadomości, możliwość komunikacji z urządzeniami umieszczonymi za bramą (Gateway), wysyłanie informacji zwrotnych o poprawności transmisji wiadomości, system powinien być skalowalny w kontekście liczby połączonych urządzeń, brama M2M powinna mieć możliwość współpracy z różnymi technologiami M2M, 8

9 system powinien umożliwiać aplikacjom rozpoznawanie usług M2M oferowanych w sieci, urządzenie i brama M2M powinna mieć możliwość rejestrowania usług oferowanych przez siebie w sieci, jeśli sieć dostępu wspiera mechanizmy mobilności i roamingu system M2M powinien również je wykorzystywać, system M2M powinien móc sprawdzać integralność urządzeń M2M i bram M2M, system powinien wspierać priorytetyzację (kilka poziomów) i oferować QoS, system powinien zapewniać anonimowość, jeśli dana aplikacja tego wymaga, w przypadku dostępu radiowego system ma zapewniać monitorowanie stanu połączenia, a nawet sterowanie tym połączeniem, system powinien zapewniać mechanizmy uwierzytelniania, autoryzacji i szyfrowania w przypadkach, gdy jest to konieczne, system powinien oferować szeroko rozumianą autodiagnostykę (stany połączeń, integralności, logowanie, wykrywanie błędów i uszkodzeń elementów sieci), system powinien zapewniać możliwości taryfikacji, system powinien wspierać wiele możliwych aplikacji i zastosowań i być możliwie uniwersalny w konfiguracji dostępu do usług i restrykcji. Drugi etap rozwoju standardu M2M dotyczy architektury M2M. Architektura M2M reprezentuje podejście typu REST (REpresentational State Transfer) o scentralizowanym charakterze gdzie aplikacje są w stanie określać zasoby (np. bloki pamięci zlokalizowane na częściach składowych platformy umieszczonych w urządzeniach, bramach lub serwerach), które mogą zostać wykorzystane do transmisji. W ogólności architektura M2M opiera się na wykorzystaniu zasobów do wymiany informacji. Struktura zasobów jest standaryzowana, ale bez uwzględniania informacji jaka może w danym zasobie być zawarta. Elementy składowe platformy są zdefiniowane przy wykorzystaniu odpowiednich adresów URL (Uniform Resource Locator). Komunikacja pomiędzy aplikacjami sieciowymi, a serwerem centralnym opiera się o HTTP REST (RESTful Hypertext Transfer Protocol). Komunikacja pomiędzy urządzeniami M2M może również się opierać o HTTP, ale dodatkowo w standardzie przewidziano inne rozwiązania. Na rysunku 1 przedstawiono ogólny schemat architektury M2M. Na elementy systemu M2M składają się trzy główne elementy: urządzenie M2M (M2M Device) podstawowy element sieci biorący udział w przesyłaniu informacji. Może być to praktycznie dowolne urządzenie korzystające z transmisji M2M podłączone do sieci bezpośrednio, lub poprzez bramę M2M. Przy połączeniu bezpośrednim (Direct Connectivity) urządzenie M2M wykonuje procedury takie jak: rejestracja, uwierzytelnianie, autoryzacja oraz zarządzanie dostępem do sieci. brama M2M (M2M Gateway) element pośredniczący przy przesyłaniu informacji pomiędzy innym urządzeniem M2M bądź aplikacją M2M, a urządzeniami nie obsługujących transmisji M2M. Rolą bramy M2M jest translacja adresów i odpowiednie dostosowanie formatu przesyłanych informacji pomiędzy urządzeniami. Brama M2M pośredniczyć w połączeniu pomiędzy aplikacją M2M a siecią M2M Area Network, którą mogą stanowić sieci PAN (Personal Area Network) np. sieci sensorowe oparte o ZigBee, bądź 6loWPAN. Przy takim podejściu brama realizuje procedury uwierzytelniania, autoryzacji oraz zarządzania dostępem do sieci. 9

10 aplikacja M2M (M2M Application) aplikacja pracująca z systemem urządzeń M2M. Może brać udział w konfiguracji sieci i urządzeń M2M, zajmować się akwizycją lub ekspozycją danych, bądź tylko monitorować stan sieci i jej elementów. Ponadto w architekturze można wyróżnić domenę sieciową, na którą składa się: sieć dostępowa (Access Network), która pozwala na komunikację urządzeń z siecią szkieletową. Przykładowe sieci dostępowe to: xdsl, HFC, GERAN, UTRAN, eutran, W-LAN, WiMAX. sieć szkieletowa (Core Network) zapewnia łączność IP, obsługę i funkcje zarządzania siecią, połączenie z innymi sieciami oraz roaming. Przykładowe sieci szkieletowe to: sieci szkieletowe 3GPP, 3GPP2, ETSI TISPAN. możliwości usługowe M2M (M2M Service Capabilities) zapewniają dostęp do funkcji, które mogą być współdzielone przez różne aplikacje, umożliwia dostęp do nich poprzez szereg otwartych interfejsów, wykorzystuje funkcjonalności sieci szkieletowej, a także upraszcza i optymalizuje rozwój i wdrażanie aplikacji dzięki ukrywaniu specyfiki sieci. User Interface to application eg. Web portal interface (User monitoring, preferences, administration) M2M Applications M2M Service Capabilities M2M Core M2M Management Functions Network and Applications domain Based on existing standards (3GPP, 3GPP2, TISPAN, IETF etc.) Transport Network Core Network (CN) Access Network Network Management Functions M2M Applications M2M Applications Gateway as a network proxy M2MService Capabilities M2MService Capabilities Direct Connectivity M2M Gateway M2M Device M2M Device Domain Based on existing standards and technologies (Bluetooth, DLMS, CEN, KNX, ZigBee, M-Bus etc.) M2M Device M2M Area Network M2M Device M2M Device M2M Device Rys. 1. Model architektury M2M wysokiego poziomu [2] Ogólny model identyfikacji dla M2M W niniejszym modelu przedstawiono powiązania pomiędzy identyfikatorami wykorzystywanymi w sieci transportowej i dostępowej. Na rysunku 2 przedstawiono zestawienie identyfikatorów wykorzystywanych w rozwiązaniach M2M. 10

11 Jak można zauważyć w tym modelu, warstwy transportu i usług są oddzielone, wynika to z faktu, że wykorzystywane są różne identyfikatory w różnych warstwach. Istnieje różnica pomiędzy identyfikatorami M2M Service Device a M2M Transport Device. Identyfikatory M2M Service Device są wykorzystywane na poziomie usług, podczas, gdy identyfikatory M2M Transport Device odnoszą się do sieci dostępowej. Te dwa typy identyfikatorów można zastosować do jednego fizycznego urządzenia, żeby wspierać przypadek bezpośredniego połączenia ( Direct Connectivity w architekturze funkcjonalnej M2M) lub do dwóch urządzeń fizycznych, żeby wspierać przypadek z wykorzystaniem bramy M2M ( Gateway as a Network Proxy ). Relacje pomiędzy różnymi identyfikatorami na poziomach dostępu do sieci i usług (Service Device I Transport Device) jak również obecność/nieobecność niektórych z tych identyfikatorów zależy w dużej mierze od konkretnych scenariuszy wdrożeniowych. Rys. 2. Ogólny model identyfikacji dla M2M [2]. Definicje poszczególnych identyfikatorów: Application Identifier Jednoznacznie identyfikuje aplikację M2M, która znajduje się na urządzeniu M2M Service Device. Jego właścicielem jest dostawca usług M2M i może być zmieniony poprzez zmianę dostawcy usług M2M. Jest on używany dla zapewnienia dostępności urządzenia M2M. Identyfikator musi być unikalny globanie. Jeżeli wiele instancji tej samej aplikacji M2M w tym samym urządzeniu M2M mogą być rejestrowane poprzez tego samego dostawcę usług wtedy identyfikator aplikacji każdej instancji musi być unikatowy. Service Subscription Identifier Identyfikuje abonament, który dotyczy usług M2M dla danego urządzenia M2M. Identyfikator abonamentu usługi ma następujące cechy: o należy do dostawcy usług M2M, o identyfikuje abonament usług M2M, o umożliwia komunikację z dostawcą usług M2M, o może się różnić od M2M Access Network Subscription Identifier, o można go zmienić poprzez zmianę dostawcy usług M2M. Service Device Identifier Jednoznacznie identyfikuje fizyczne urządzenie sprzętowe M2M. Może zawierać następujące elementy: o identyfikator producenta, 11

12 o numer, który jest unikalny w domenie producenta lub typ urządzenia producenta, o przydzielony identyfikator dostępu do sieci operatora. Access Network Subscription Identifier Identyfikuje abonament, który dotyczy M2M Transport Device i operatora sieci dostępowej. Posiada następujące cechy: o należy do operatora/dostawcy sieci dostępowej, o Identyfikuje operatora/dostawcę sieci dostępowej tego M2M Transport Device, o Może być różny od M2M Service Subscription Identifier, o Można go zmienić poprzez zmianę dostawcy usług M2M. Zasady dotyczące liczby abonentów dostępu do sieci na jedno urządzenie M2M Transport Device są zależne od sieci dostępowej i regulowane przez obowiązujące przepisy dostępu do sieci. Przy wykorzystaniu sieci komórkowej jako sieci dostępowej tym identyfikatorem może być numer IMSI. Access Network Device Identifier Jednoznacznie identyfikuje urządzenie fizyczne M2M dla danego M2M Transport Device. Może zawierać następujące elementy: o identyfikator operatora, o numer, który jest unikalny w domenie producenta lub typ urządzenia producenta, o przydzielony identyfikator dostępu do sieci operatora. Przy wykorzystaniu sieci komórkowej jako sieci dostępowej, tym identyfikatorem może być numer IMEI. Access Network Address Jednoznacznie identyfikuje adres dla routingu do M2M Transport Device (przy wykorzystaniu sieci dostępowej 2G tym identyfikatorem może być numer MSISDN, natomiast dla sieci 3G może to być adres IPv6) Wnioski Standard M2M dotyczy dużo węższego obszaru zainteresowań niż IoT i skupia się głownie na umożliwieniu połączenia end-to-end pomiędzy urządzeniami systemu i wymianie informacji między nimi. Scentralizowane podejście do zarządzania elementami składowymi systemu M2M oraz transmisja w oparciu o adresowanie URL może stanowić pewne ograniczenie zastosowania w przypadku IoT. Podejście do organizowania informacji w standaryzowane struktury bez specyfikowania ich zawartości jest w pewnym stopniu zbliżone do koncepcji wirtualnych obiektów i bytów (VO - Virtual Object, VA Virtual Entity) w IoT i może być przydatne z punktu widzenia przyszłego modelowania odwzorowania informacji w IoT Literatura [1] ETSI TS V1.1.1 ( ), Machine-to-Machine communications (M2M); M2M service requirements [2] ETSI TS V1.1.1 ( ), Machine-to-Machine communications (M2M); Functional architecture 2.2 CASAGRAS / CASAGRAS 2 Cel projektu FP7 CASAGRAS ( ): stworzenie ramowego planu badań do wspierania Komisji Europejskiej oraz społeczności międzynarodowej w definiowaniu i rozwoju techniki RFID ze szczególnym uwzględnieniem IoT. Cel projektu FP7 CASAGRAS 2 ( ): Wdrożenie koncepcji IoT w kontekście globalnym w ramach współpracy międzynarodowej. Definicja Internetu Rzeczy według CASAGRAS [1]: Globalna infrastruktura sieciowa, łącząca fizyczne i wirtualne obiekty poprzez wykorzystanie możliwości pozyskiwania danych i łączności. Taka infrastruktura obejmuje istniejący 12

13 i rozwijający się Internet oraz inne rozwijające się sieci. Oferuje ona jednoznaczną identyfikację obiektów, możliwość podłączenia sensorów i łączności, które będą stanowić podstawy do rozwoju niezależnych współpracujących usług i aplikacji. Będzie ona charakteryzować się wysokim stopniem samodzielnego zbierania danych, transferu informacji o występujących zdarzeniach, łącznością sieciową oraz interoperacyjnością Główne założenia i cele projektu Celem CASAGRAS było dostarczanie materiałów i rekomendacji, które miały pomóc Komisji Europejskiej w opracowaniu strategii oraz planu rozwoju Internetu Rzeczy. Celem projektu było również uwzględnienie międzynarodowego wymiaru regulacji, standaryzacji i innych wymagań w zakresie wdrażania Internetu Rzeczy z wykorzystaniem RFID. Mając na uwadze właściwe podejście do koncepcji IoT i kwestii technologicznych cel projektu został skorygowany do przyjęcia oprócz RFID innych technologii identyfikacji, lokalizacji, komunikacji i akwizycji danych, które obecnie są wykorzystywane na świecie. Jako podstawę do realizacji IoT wyszczególniono trzy kategorie technologii sprzętowej oraz skojarzone z nią warstwy: identyfikacja i technologie akwizycji danych tworzące warstwę fizyczną interfejsu, stałe, mobilne, bezprzewodowe i przewodowe technologie komunikacyjne, wspierane odpowiednimi interfejsami, dla komunikacji głosowej i transmisji danych, technologie sieciowe (w połączeniu z technologiami komunikacyjnymi) mające na celu ułatwienia grupowania obsługiwanych obiektów dla celów aplikacji i usług. W celu utworzenia w pełni funkcjonalnego systemu konieczne jest dodanie do powyższego oprogramowania, warstw pośrednich i odpowiednich protokołów, które zapewnią możliwość łączenia i pracy sprzętu oraz wsparcia dla usług wyszukiwania. W ramach projektu położono nacisk na odpowiednie europejskie dokumenty określające kierunki polityki dotyczące powyższych struktur. Jednym z takich dokumentów jest European Policy Outlook RFID [2], który proponuje zastosowania możliwość przetwarzania wbudowanego (ang. embeded processing) jako użyteczny wyznacznik przy określaniu modeli dla IoT. W ramach projektu CASAGRAS rozpatrywano trzy modele: Model oparty na identyfikatorach RFID tylko do odczytu, Model wykorzystujący dodatkowe obiekty RFID posiadające możliwość zapisu i odczytu danych oraz dodatkową funkcjonalność przechowywania danych, Model wykorzystujący dodatkowe obiekty bazujące na RFID lub innych technologiach identyfikacji i pozyskiwania danych (ang. automatic identification and data capture - AIDC), posiadające możliwość pozyskiwania danych z sensorów, rozszerzoną funkcjonalność przechowywania danych i innych atrybutów takich jak lokalizacja czy pozycjonowanie. Najbardziej podstawowy model IoT składa się z obiektów wyposażonych w pasywne tagi RFID zawierające unikalne identyfikatory, posiadające zdolność do odpytywania i odpowiedzi za pośrednictwem bezprzewodowej transmisji. Obiekty te nie posiadają możliwości wewnętrznego przetwarzania danych oraz możliwości komunikacji z innymi obiektami. Aplikacje korzystające z tego typu obiektów wykorzystują ich identyfikatory jako odnośniki do zdalnych bazach danych, gdzie przechowywana jest informacja o danym obiekcie. Urządzenia odpytujące (ang. Interrogators) mogą być stacjonarne lub przenośne, a komunikacja pomiędzy nimi a hostem może być przewodowa lub bezprzewodowa, w zależności od typu urządzenia i wymaganych interfejsów i protokołów komunikacyjnych. Urządzenia te mogą wykonywać określone funkcje przetwarzania i mogą dodatkowo komunikować się ze sobą lub bramą oraz tworzyć sieć. Należy zauważyć, że obiekty 13

14 wyposażone w aktywne tagi RFID mogą pełnić dwie funkcje: znacznika odpowiadającego na zapytanie, a w określonych okolicznościach samemu stać się urządzeniem odpytującym, zbierającym dane od sąsiednich obiektów z RFID i tym samym tworzyć lokalną sieć ad-hoc. Taka funkcjonalność oraz odpowiednie rozmieszczenie tego typu obiektów mogą znacząco poprawić realizacje IoT. Aplikacje wykorzystują system hostów i dzięki identyfikacji obiektów realizują specyficzne dla nich funkcje wspierające oraz odbierają i przekazują odpowiednie reakcje obiektów, nawet takie, które powodują fizyczne sterowanie obiektami. System hostów może być połączony przewodowo lub bezprzewodowo oraz tworzyć sieć, a dodatkowo wykorzystywać w tym celu Internet lub WWW, w zależności od wymagań aplikacji. Aby osiągnąć taki stopień komunikacji wymagana jest standaryzacja numeracji, struktur danych, protokołów komunikacyjnych i interfejsów na poziomie globalnym, jeżeli planuje się wprowadzenie globalnego IoT. Ze względu na fakt konieczności dostosowania modelu do rzeczywistych warunków i problemów np. z łącznością bezprzewodową, które mogą powstać w praktycznych realizacjach skalowalnych systemów, konieczne jest zdefiniowanie bardziej kompleksowego modelu IoT (ang. inclusive model). Takie podejście jest bardzo wymagające zarówno pod względem opracowania architektury jak i późniejszej realizacji modelu, dlatego model ten jest traktowany jako wizja, która powinna być realizowana etapowo przy odpowiednim wsparciu w domenie standardów. Na rys. 1 przedstawiono architekturę kompleksowego modelu IoT, przy czym podzielono na nim sensory wyposażone w tagi RFID na (1) te umożliwiające komunikację tylko z urządzeniem odczytującym oraz (2) te umożliwiające komunikację miedzy innymi sensorami (oznaczone linią przerywaną). Rys. 1. Kompleksowy model IoT (ang. inclusive model). [1,5]. Rozważania dotyczące modelu można podzielić na te, które odnoszą się do ewolucji Internetu oraz do tych związanych z rozróżnialnymi warstwami w rzeczywistych obiektach. Warstwy te obejmują: Warstwę fizyczną: w której fizyczne obiekty lub przedmioty są identyfikowane i stają się funkcjonalnymi komponentami Internetu Rzeczy poprzez użycie takich technologii jak np. RFID. Obiekty tak zdefiniowane mogą być zgrupowane lub połączone w sieć, tak aby spełniać konkretne wymagania aplikacji. Urządzenia wyposażone w dodatkową funkcjonalność taką jak sensory, lokalizatory czy moduły komunikacyjne mogą być używane 14

15 zarówno jako struktura sieci oraz jako osobne urządzenia. Możliwość przetwarzania danych w urządzeniu jest postrzegana jako istotna cecha wyróżniająca urządzenia tworzące węzły IoT. Wraz ze obserwowalnym wzrostem mocy obliczeniowej urządzeń, zmniejszeniem ich wymiarów i redukcją kosztów produkcji, można oczekiwać wzrostu liczby wykorzystywanych urządzeń/węzłów z możliwość przetwarzania wbudowanego. Gama i elastyczność tych urządzeń oraz tworzonych przez nie sieci będzie miała istotny wpływ na zakres ich zastosowań. Raport Komisji Europejskiej From RFID to the Internet of Things Pervasive networked systems [3] definiuje następujące sieciowe urządzenia komunikacyjne: pasywne urządzenia RFID, które dostarczają na żądanie stałe dane wyjściowe, urządzenia z umiarkowaną mocą przetwarzania do formowania przechowywanych wiadomości, z możliwością zmiany jej treści w odniesieniu do czasu i miejsca, urządzenia wyposażone w czujniki, które są zdolne do generowania i przekazywania informacji o stanie środowiska lub pozycji podczas odpytywania, urządzenia o zwiększonej mocy przetwarzania, które, gdy jest to wymagane, umożliwiają nawiązanie komunikacji pomiędzy urządzeniami bez ingerencji człowieka wprowadzają one pewien stopień inteligencji w systemach sieciowych. Przedstawione kategorie technologiczne mają swoje odzwierciedlenie w fizycznych interfejsach i wymaganiach sieciowych, a także w innych częściach łańcucha przetwarzania i transmisji danych oraz potrzeb strukturyzacji danych. Organizacje standaryzacyjne ISO/IEC pracują nad opracowaniem międzynarodowych standardów spełniających te potrzeby. Warstwy mogą być odróżnione przez to, że odnoszą się do różnych technologiach identyfikacji i pozyskiwania danych (AIDC) oferujących różne poziomy funkcjonalności. W sposób naturalny obejmują one RFID jako warstwę, ale inne warstwy mogą obejmować całą gamę technologii AIDC, w tym m.in. jedno- lub dwuwymiarowych kodów kreskowych, urządzeń zapisu optycznego, pamięci zbliżeniowych oraz szeregu technologii identyfikacji biometrycznej. Istotne znaczenie w łączności ze światem fizycznym stanowią radiowe technologie komunikacyjne, począwszy od tych o bardzo dużym zasięgu jak np. 2G/3G, poprzez sieci WiFi, a skończywszy na sieciach bliskiego zasięgu jak Bluetooth, Zigbee, czy NFC (ang. Near Field Communication). Szerokopasmowe sieci dostępowe i sieci komórkowe oraz rozwój aplikacji w ich oparciu, stwarzają dodatkowy wymiar i możliwości w realizacji warstw IoT. Zakres i bogata funkcjonalność tych technologii stanowią istotny wyznacznik w realizacji aplikacji, ich innowacji i możliwości dalszego rozwoju. Na tej podstawie warstwy mogą być zidentyfikowane dla różnych typów urządzeń akwizycji danych. Umieszczenie ich w architekturze IoT wymaga opracowania uniwersalnego protokołu o funkcjonalności plugand-play (ang. Universal Data Capture Appliance Protocol - UDCAP). Ponadto definicja warstw w ten sposób zapewnia podstawy do migracji technologii AIDC w przyszłości. Warstwa Interrogator-Gateway zapewnia efektywne połączenia pomiędzy obiektami, urządzeniami odpytującymi oraz systemem zarządzania informacjami. Technologie łączności (stałej, szerokopasmowej i mobilnej) zapewniają komunikację niezbędną dla potrzeb IoT. Połączenie w sieć urządzeń odpytujących i bram może być również postrzegane jako istotny aspekt infrastrukturalny w tej warstwie. Interfejs do sterowania i kontroli urządzeń w rzeczywistych aplikacjach jest kolejnym ważnym elementem tej warstwy. Warstwa Information Management, Application and Enterprise zapewnia funkcjonalną platformę do wspierania aplikacji i usług dzięki interfejsowi pomiędzy warstwą Interrogator- Gateway. Warstwa Wider communications and Internet zapewnia interfejs z innymi strukturami i sieciami włączając w to Internet. Pomimo tego, że interfejsy są niezbędne pomiędzy każdymi warstwami, relacje mogą też ominąć warstwy, dodając jeszcze większą elastyczność 15

16 i możliwości dla aplikacji i usług. Struktury sieciowe, jak również te, które wymagają wsparcia bramy, również przyczyniają się do zwiększenia elastyczności. Oprócz technologii RFID i łączności bezprzewodowej wiele innych ważnych czynników ma wpływ na formę, jaką wymienione warstwy mogą przyjmować i jakie aplikacje i usługi mogą one wspierać. Do tych czynników należy m.in. architektura zorientowana na usługi (ang. Service Oriented Architecture - SOA). Architektura ta może być postrzegana jako zestaw narzędzi do rozdzielania funkcji w odrębne jednostki lub usługi, które mogą być udostępniane w sieci i wykorzystywane do tworzenia aplikacji biznesowych, dzięki czemu biblioteka funkcji biznesowych będzie tworzona jako moduły oprogramowania, które można będzie ponownie użyć, lub by wykorzystać je do tworzenia nowych aplikacji lub usług. Elastyczność takiego rozwiązania umożliwi przyspieszenie procesu rozwoju, integracji i dodawania kolejnych funkcjonalności aplikacjom na etapie ich tworzenia. Architektura SOA pozwala dodatkowo usługom na komunikowanie się między sobą oraz do koordynowania działań pomiędzy jedną lub wieloma usługami. Pozwala ona także na funkcjonowanie oprogramowania na żądanie (ang. software on demand), umożliwiając hostom automatyczne dostarczanie modułów programowych w odpowiedzi na żądania. SOA może być również łączona aplikacjami typu software-as-a-service, dzięki czemu możliwe jest tworzenie wysoce skalowalnych architektur. Takie podejście oferuje duży potencjał rozwoju aplikacji i usług IoT Wnioski Kluczowe wymagania architektoniczne do realizacji technologicznie kompleksowego IoT, opracowane w ramach projektu CASAGRAS obejmowały [1]: Rozwój zagadnień związanych z identyfikacją i zarządzaniem tożsamością Rozwój architektury i infrastruktury dla aplikacji i usług typu object-to-internet Wykorzystanie SOA i architektur sieciowych do rozwoju usług IoT Opracowanie uniwersalnego protokołu UDCAP o funkcjonalności plug-and-play Opracowanie jednolitego podejścia do wykorzystania komunikacji przewodowej i bezprzewodowej, w kontekście zarządzania tożsamością. Monitorowanie i przyjęcie odpowiednich rozwiązań we wszechobecnym przetwarzaniu i sieciach (ang. ubiquitous computing and networks) i bezprzewodowych sieciach sensorowych, a także adaptacji odpowiednich technologii i przyjęcie zunifikowanych rozwiązań. Opracowanie predykcyjnych technik analitycznych automatycznego zarządzania i samodzielnej naprawy sieci; rozwój zaawansowanego zarządzania danymi. W ramach projektu CASAGRAS 2 funkcjonowała grupa tematyczna WP2 Architecture and Platforms for the Internet of Things, której celami były [4]: Przegląd i analizy istniejących i powstających propozycji platform i architektur usługowych na rzecz rozwoju IoT, analiza systemowych i inteligentny wymagań technologicznych i ich potencjał w rozwoju IoT. Organizacja warsztatów na wszystkich kontynentach, we współpracy z lokalnymi partnerami w celu uzyskania szerszego zrozumienia lokalnych problemów oraz potrzeb każdego regionu. Wsparcie koordynacji międzysektorowej w sprawie konwergencji IT, telekomunikacji i mediów w oparciu o wszechstronne analizy rozważanych architektur i platform, co pozwoli na identyfikację i wypracowanie koncepcji oraz utworzenia masy krytycznej dla usług FI. 16

17 2.2.3 Literatura [1] CASAGRAS Final Report [2] European Policy Outlook RFID Working document for the expert conference RFID: Towards the Internet of Things, June [3] European Commission (2006) From RFID to the Internet of Things Pervasive networked systems ISBN: [4] oficjalna strona internetowa projektu CASAGRAS 2 [5] Prof. Dr. José Roberto de Almeida Amazonas, Network Virtualization and Cloud Computing: IoT enabling Technologies, Brazilian Academic Seminar, Projekt SmartSantander Informacje podstawowe SmartSantander [1,2] to jeden z pięciu dużych projektów zatwierdzonych przez Komisję Europejską w ramach 7. Programu Ramowego w dziedzinie infrastruktury dla badań eksperymentalnych na temat Internetu Przyszłości. Przy całkowitym budżecie 8,67 mln euro, projekt obejmuje piętnastu partnerów wśród instytucji publicznych i prywatnych oraz firm europejskich, jak również partnera australijskiego. Projekt jest prowadzony przez firmę Telefonica I+D, technicznym koordynatorem projektu jest Uniwersytet Cantabria, a członkami konsorcjum są m.in. Rada Miasta Santander i Rząd Kantabrii. Projekt realizowany jest w 4 fazach (fazy: 0-3), wystartował we wrześniu 2010 r. i ma być kontynuowany przez 3 lata (do sierpnia 2013 r.) Cele i założenia projektu Głównym celem projektu jest stworzenie europejskiego środowiska testowego dla badań i eksperymentów w zakresie architektury, technologii, usług i aplikacji dla Internetu Rzeczy w kontekście inteligentnego miasta (Smart City). Inicjatywa obejmuje projektowanie, wdrażanie i zatwierdzanie platformy złożonej z urządzeń (czujniki, siłowniki, kamery, terminale mobilne, itp.), zintegrowanych pod parasolem Internetu Rzeczy, w którym każdy obiekt posiada zdolność komunikowania się i przekazywania informacji, które są przydatne dla użytkownika (temperatura, ciśnienie powietrza, poziom hałasu, stężenie CO, itp.). Projekt korzysta z doświadczeń i rezultatów 2 projektów FP7, a mianowicie: WISEBED i SENSEI oraz platformy usług USN firmy Telefonica. Łącząc te 3 instalacje adresowane do badań zakresie IoT na różnych poziomach (WISEBED środowisko badawcze bezprzewodowych sieci sensorów, SENSEI łączenie heterogenicznych sieci sensorów i sterowników, USN platforma usług) z dużą liczbą urządzeń IoT zainstalowanych w 4 miastach europejskich (najpierw w Santander, a następnie w Guildford, Lubece i Belgradzie) w rzeczywistym środowisku fizycznym, co wprowadza szereg wyzwań w zakresie wdrożenia i utrzymania, projekt SmartSantander stanowić ma unikalną w świecie instalację do eksperymentowania w zakresie IoT w rzeczywistych warunkach eksploatacji Wymogi dla architektury Projekt SmartSantander zakłada trzy grupy użytkowników systemu: eksperymentatorów, dostawców usług (i projektantów aplikacji) oraz miasta/mieszkańców. Dla poszczególnych grup użytkowników zdefiniowano stosowne przypadki użycia (use cases). Przypadki użycia dla eksperymentatorów: Wielokrotne wykorzystywanie (powtarzalność) konfiguracji testowych, 17

18 Wirtualizacja środowiska testowego (powtarzalność, skalowalność). Przypadki użycia dla dostawców usług: Różnorodność systemów operacyjnych, z którymi usługi muszą współpracować, Kwarantanna oprogramowania sensorów przed jego wdrożeniem do systemu (symulator, sieć dla celów kwarantanny). Przypadki użycia dla społeczności użytkowników: Zarządzanie deficytowymi zasobami parkingowymi: dostarczanie dynamicznej informacji w czasie rzeczywistym o zasobach parkingowych w strefach ograniczonego parkowania, Zarządzanie zasobami parkingowymi dla osób niepełnosprawnych, Nadzór nad obszarami załadunku/rozładunku towarów. Świadczenie usług wymienionych w przypadkach użycia dla społeczności użytkowników wymaga wdrożenia następujących elementów sieci: Sensory pod chodnikami, Przekaźniki umieszczane w miejskich lataniach, zbierające dane z sensorów i komunikujące z innymi urządzeniami, Bramy (gateways) zlokalizowane w ograniczonej liczbie obszarów, potrzebne do łączenia klasterów sensorów i przekaźników z Internetem. Na rys. 1 przedstawiono poglądowo obraz sieci, w fazie 0, z wymienionymi wyżej elementami. Rys. 1. Elementy sieci SmartSantander w fazie 0 [2] Architektura zaproponowanego rozwiązania Projekt SmartSantander definiuje 4 podsystemy: Podsystem uwierzytelniania, autoryzacji i naliczania (Authentication, Authorization and Accounting subsystem - AAA), Podsystem zarządzania platformą testową (Testbed management subsystem), Podsystem wsparcia eksperymentowania (Experimental support subsystem), Podsystem obsługi aplikacji (Application support subsystem). Poszczególne podsystemy udostępniają swoje funkcje za pomocą interfejsów, a mianowicie: Interfejs kontroli dostępu (Access Control Interface - ACI), Interfejs wsparcia eksperymentowania (Experimental Support Interface - ESI), Interfejs wsparcia aplikacji (Application Support Interface - ASI), Interfejs wsparcia zarządzania (Management Support Interface - MSI). 18

19 Konfigurację systemu stanowić będą węzły o różnych charakterystykach i możliwościach, a mianowicie: Węzły Internetu Rzeczy (IoT nodes), Węzły bram (Gateway nodes), Węzły serwerów testowych (Testbed server nodes). Na rys. 2 przedstawiono ogólną architekturę systemu SmartSantander, uwzględniającą poszczególne podsystemy, interfejsy oraz węzły Bloki funkcjonalne Rys. 2. Architektura systemu SmartSantander [2] Elementy składowe konfiguracji związane są z poszczególnymi podsystemami. Wyróżnia się następujące bloki funkcjonalne: Kontrola dostępu i bezpieczeństwo węzłów IoT, Wsparcie eksperymentowania, Wsparcie zarządzania, Wsparcie aplikacji. Kontrola dostępu realizowana jest w ten sposób, że: Osoba chcąca uzyskać dostęp do zasobu jest identyfikowana i uwierzytelniana, Określana jest rola osoby (administrator platformy testowej, eksperymentator, dostawca usług, obywatel), Zgodnie z określoną rolą udostępniane są zainteresowanej osobie żądane funkcje. Środowisko testowe SmartSantander będzie stosowane głównie na zewnątrz, w środowisku otwartym, w związku z czym należało zapewnić pewien poziom zabezpieczeń przed możliwymi atakami. W systemie zastosowano środki zabezpieczające przed zagrożeniami, które obejmują m.in.: funkcje haszujące, stosowanie podpisu elektronicznego, szyfrowanie. Moduł wspierania eksperymentowania obejmuje następujące funkcje: Zarządzanie konfiguracją (Configuration Management), Konfiguracja zasobów (Resource Configuration), Konfiguracja eksperymentu (Experiment Configuration), Zarządzanie rezerwacją zasobów i planowanie (Resource reservation and scheduling), 19

20 Analiza rezultatów eksperymentu (Result analysis), Zarządzanie sesją (Session management). Moduł wspierania zarządzania realizuje następujące funkcje: Wykrywanie i konfigurowanie zasobów, Monitorowanie i obsługa błędów. Moduł wsparcia aplikacji dostarcza podstawowe funkcjonalności systemu, które mają ułatwiać rozwój usług na etapie zarówno eksperymentowania, jak też finalnie - korzystania przez użytkowników końcowych. Moduł wsparcia aplikacji realizuje następujące funkcje: Powiadamianie (publikowanie/abonowanie) o zmianach zasobów, Powiadamianie (publikowanie/abonowanie) o danych obserwacyjnych i pomiarowych, Wyszukiwanie informacji zawartej w bazie danych obsługi i konserwacji (O&M DB), Wyszukiwanie zasobów zapisanych w bazie danych zasobów (Resource DB), Zarządzanie zasobami, z których korzysta się podczas realizacji usług. W celu realizacji zadań przez poszczególne podsystemy SmartSantander oferuje następujące struktury danych: Baza danych zasobów (Resource DB) Baza danych eksperymentów (Experimental DB) Baza danych platformy testowej (Testbed MIB) baza danych na temat węzłów, zapewniających łączność (rutery, serwery) i inne funkcje niezbędne do właściwego funkcjonowania środowiska testowego, Baza danych kont użytkowników (nazwy, hasła, prawa dostępu, itp.), Baza danych związanych z obsługą i konserwacją (O&M DB) dane, bieżące i historyczne, z obserwacji i pomiarów, generowane przez elementy składowe sieci (wartości mierzone przez sensory, stany urządzeń, poziomy zasilania, oprogramowanie w węzłach sieci, itp.) Wnioski SmartSantander stanowi znaczący projekt wspierający badania dla wdrażania koncepcji Smart Cities z wykorzystaniem Internetu Rzeczy. Dostarcza on infrastrukturę dla eksperymentowania na różnych poziomach (protokoły komunikacyjne, architektura Internetu rzeczy, usługi dla użytkowników końcowych, itd.). Znaczenie projektu wynika z tego, że w końcowym etapie umożliwi on dostęp do ok. 20 tysięcy urządzeń Internetu rzeczy, zainstalowanych nie tylko w Santander, ale też w innych miejscach na świecie, np. w Guilford, Lubece i Belgradzie. Projekt SmartSantander przyczyni się do rozwoju nowych aplikacji Internetu rzeczy w warunkach miasta, testowanych metodą Living Lab Literatura [1] Portal projektu SmartSantander [2] First Cycle Architecture Specification, D1.1, SmartSantander, IoT@Work Zamysłem nadrzędnym twórców projektu FP7 IoT@Work ( ) jest ułatwienie pracy ekspertom automatyki i inżynierom oraz zmniejszenie kosztów operacyjnych 20

21 i inwestycyjnych przedsiębiorstw produkcyjnych. Podczas procesów projektowania i zamawiania systemów automatyki, takich jak: urządzenia automatyki, sensory i elementy wykonawcze automatyki i po ich wcześniejszym zmodyfikowaniu pozwalającemu na zaadoptowanie technologii IoT, eksperci automatyki nie będą musieli zajmować się konfiguracją mechanizmów wymiany informacji pomiędzy tymi jednostkami Główne założenia i cele projektu Calem projektu IoT@Work jest zmniejszenie kosztów operacyjnych konfiguracji, zamawiania i utrzymania rozwiązań dla sektora produkcji poprzez redukcję przestojów w przypadku rekonfiguracji elementów systemu automatyki. Projekt skupia się na poprawie infrastruktury telekomunikacyjnej oraz aplikacji pośredniczących w celu realizacji nowej, samozarządzającej i elastycznej sieci oraz architektury aplikacji zorientowanych na usługi. Elementy te ponadto powinny być dobrze adoptowalne w środowisku przemysłowym. Rezultatem projektu będzie otwarta specyfikacja interfejsów i protokołów, która zostanie zweryfikowana przez implementację, na niewielką skalę przemysłową, prototypu potwierdzającego słuszność koncepcji również w przypadku procesów występujących na dużą skalę. Główne cele techniczne projektu: 1. Oddzielenie aplikacji automatyki od konfiguracji i obsługi sieci w celu: a. Redukcji efektu procesu rekonfiguracji aplikacji na ilość manualnego planowania wymaganego na poziomie sieciowym, b. Dostarczenia zaawansowanych usług telekomunikacyjnych, które spełnią wymagania aplikacji w zakresie: wiarygodności, czasu rzeczywistego, skalowalności i bezpieczeństwa. 2. Integracja samozarządzania w sieci typu Plug&Work w celu: a. Umożliwienia wykorzystania idei Plug&Work na wszystkich poziomach a w szczególności podczas fazy konfiguracji sieci automatyki przemysłowej, b. Uwzględnienia semantyki aplikacji w trakcie strukturyzacji i optymalizacji operacji sieciowych. 3. Zapewnienie odporności i bezpieczeństwa w działających systemach automatyki w celu: a. Wsparcia adaptacyjnych i zmiennych scenariuszy produkcyjnych z równoczesną ochroną wiarygodności i odporności pracujących systemów, b. Integracji silnych mechanizmów zabezpieczających na poziomie architekturalnym i unikania nieautoryzowanego dostępu i niepożądanych zakłóceń w procesie produkcji. Dzisiejsze systemy automatyki dla przemysłu wymagają wiarygodności i bezpieczeństwa komunikacji. Uruchamianie i obsługa systemów produkcji bazuje bardzo często na złożonych procesach inżynierskich związanych z planowaniem, projektowaniem oraz konfiguracją tychże rozwiązań. Modyfikowanie i rozszerzanie funkcjonalności takich systemów jest bardzo trudne pomimo nawet korzystania z nowoczesnych technik telekomunikacji. Aktualnie rekonfiguracja lub modyfikacja systemów produkcji wymaga bardzo złożonych i czasochłonnych procesów, które bardzo często są porównywalnie wymagające jak te realizowane podczas inicjalizacji systemu. Modyfikowanie systemów automatyki przemysłowej wymaga zatem: szczegółowego planowania, restrykcyjnych zasad zamawiania, dużego wysiłku przy konfiguracji urządzeń i sieci, wysokich kosztów oraz trudnej implementacji mechanizmów bezpieczeństwa. W celu redukcji złożoności dostarczania wymaganych i wysoce wyspecjalizowanych usług telekomunikacyjnych, projektowanie i konfiguracja aplikacji automatyki musi być oddzielona od operacji sieciowych poprzez wykorzystanie dodatkowych usług i warstw IoT [1]. 21

22 Warstwy te reprezentują abstrakcyjne zasoby sieciowe IoT, które udostępnia się na żądanie programistom automatyki poprzez pewne specyficzne usługi (np. powiadamianie, zdarzenia, wiarygodna komunikacja, mechanizmy rezerwacji, usługi bezpieczeństwa). Wiarygodność aplikacji oraz przewidywalność żądań muszą być również opisane i łatwo implementowane w infrastrukturze sieciowej. W tym ujęciu projektant aplikacji automatyki będzie widzieć sieć jako tzw. czarną skrzynkę, która oferuje różne typy usług telekomunikacyjnych poprzez odpowiednio rozwinięte i zaprojektowane interfejsy. Sieć przemysłowa powinna mieć możliwości samoadaptacyjne pozwalające na odpowiedź na żądania aplikacji i procesów sterowania w automatyce. Takie podejście pozwala ukryć złożoność sieciową przed warstwami wyższymi, ale również informować sieć o celach i właściwościach bezpieczeństwa, które musza być zagwarantowane w sposób ciągły przez sieć. Nowe podejście IoT@Work pozwala na: oddzielenie planowania aplikacji od planowania zasobów, auto-konfigurację, dużo mniejszą złożoność konfiguracji oraz większą elastyczność Propozycja architektury IoT@Work Autorzy koncepcji IoT@Work w trakcie procesu tworzenia architektury przyszłego systemu posługują się czterema podstawowymi sposobami jej opisu: 1. Z wykorzystaniem warstwowego modelu odniesienia bazującego na siedmiowarstwowym modelu OSI. W tym klasycznym ujęciu łatwo pokazać, jakie są zależności pomiędzy poszczególnymi protokołami. Każda warstwa wymaga tu pewnych danych z warstwy niższej a dostarcza pewnych usług i informacji warstwom wyższym. 2. Przy użyciu ujęcia funkcjonalnego, które pozwala identyfikować poszczególne usługi, pokazywać jak są one powiązane i jakie posiadają interfejsy. Funkcjonalności takie mogą być ponadto dystrybuowane przez sieć i często są od siebie nawzajem zależne. 3. Z perspektywy zasobów modelujących fizyczne właściwości systemu. Ujęcie to pokazuje ważne zasoby systemu i sposoby zarządzania nimi (patrz rysunek 1) w taki sposób, aby istotne zasoby były dostępne zawsze, kiedy są wymagane. 4. Spojrzenie w przekroju z wykorzystaniem tzw. plastrów (ang. slices) jest specyficznym sposobem IoT@Work wizualizacji wielu różnych aplikacji czy domen aplikacji z wykorzystaniem tych samych zasobów i usług. W ten sposób plastry te pozwalają realizować wirtualizację poprzez poszczególne warstwy protokolarne, którą implementuje się z wykorzystaniem różnych mechanizmów (patrz rysunek 2). Plastry te wiąże się z poszczególnymi zasobami i zasadami bezpieczeństwa w celu modelowania systemu wielokrotnie dzierżawionego. Można tu na przykład rozważać te same usługi skonfigurowane inaczej dla poszczególnych wirtualnych dzierżawców. Jeśli chodzi o ujęcie funkcjonalne, to umożliwia ono strukturyzację przyszłej architektury IoT@Work w jednostki dostarczające odpowiednie usługi bez znaczenia jest tu sposób ich implementacji. Warto tu dodać, że z reguły usługi składają się z funkcjonalności niższego rzędu takich jak np.: funkcje sieciowe, zarządzanie zasobami, zarządzanie bezpieczeństwem, funkcje pośredniczące (np. bramy, serwery proxy, różne funkcje zarządzające, system przekazywania wiadomości i inne), bazy danych oraz funkcje typowe dla aplikacji. Z perspektywy zasobów z kolei w architekturze IoT@Work sieć dostarcza zasób (patrz Zasoby sieciowe na rysunku 1) zwany usługą transmisji, który pozwala między innymi na realizację routingu czy zapewnienie odpowiedniego QoS. Każdy węzeł sieci oferuje pewne zasoby sieciowe, natomiast większa liczba tych elementów, komunikując się ze sobą, udostępnia bardziej złożone zasoby sieciowe. Jeśli chodzi o urządzenia (np. roboty) produkcyjne (patrz rysunek 1), to składają się one często z wielu elementów, które dodatkowo wspierane są zasobami sensorów 22

23 i przetwarzania (rysunek 1). Takie jednostki mogą dostarczać zasoby jako jeden element architektury IoT w ujęciu zasobów. Rys. 1. Zarys przyszłej architektury IoT@Work z perspektywy zasobów [2]. System produkcyjny składa się z wielu aplikacji działających równolegle i korzystających często z tych samych zasobów IoT. W IoT@Work rozważa się trzy podsystemy: produkcyjny, monitorujący oraz bezpieczeństwa, na które składa się cały łańcuch aplikacji mających rozróżnialne właściwości. Podsystem produkcyjny rozumiany jest jako kombinacja zasobów produkcyjnych oraz sieciowych (rysunek 1), które są wykorzystywane przez aplikacje sterujące w celu automatyzacji produkcji. Jeśli chodzi o podsystem monitorujący, to nie korzysta on wprost z zasobów produkcyjnych, ale może chcieć uzyskać dane np. z pewnych sensorów urządzeń produkcyjnych. Podsystem ten jednak z całą pewnością wymaga zasobów sieciowych dla możliwości realizacji swych działań. Podsystem bezpieczeństwa (rysunek 1) z kolei umożliwia interakcję z systemem produkcji w celach zapewnienia bezpieczeństwa (np. awaryjne zatrzymanie jakiegoś urządzenia). Plastry (patrz rysunek 2) w ujęciu IoT@Work są określeniem między-warstwowego mechanizmu wirtualizacji pozwalającego na izolację od siebie użytkowników, aplikacji oraz domen aplikacji w kontekście zarówno bezpieczeństwa jak i zarządzania zasobami. Plastry te mogą być zaimplementowane jako kombinacja wielu mechanizmów; w ogólności jako przestrzenie nazw w poszczególnych warstwach modelu OSI (rysunek 2). Rys. 2. Zarys przyszłej architektury IoT@Work z perspektywy tzw. plastrów [2]. 23

24 2.4.3 Wybrane wymogi systemowe w ujęciu sieciowym Poniżej przedstawiono istotne z perspektywy sieciowej wymogi dla przyszłej architektury IoT@Work: Wsparcie dla automatycznej konfiguracji sieci auto-konfiguracja powinna być przynajmniej częściowo dostępna (na zasadzie wsparcia procesów manualnych) podczas projektowania, planowania, optymalizacji i zestawiania sieci, a pełne wsparcie powinno być zapewnione na etapie jej uruchamiania; Szybka inicjalizacja i restart sieci czas uruchomienia całego systemu nie jest krytyczny, ale poszczególne urządzenia muszą być inicjalizowane szybko wraz z uwzględnieniem adresacji, autoryzacji, alokacji zasobów, odkrywania usług jak i identyfikacji roli danego urządzenia w danej sieci i aplikacji; Ciągły system rekonfiguracji należy zapewnić możliwość rekonfiguracji/aktualizacji systemu w trakcie jego działania i tak, aby proces ten nie wpływał niekorzystnie na bieżące funkcjonowanie aplikacji; Wsparcie dla wielu topologii wsparcie dla struktur sieciowych typu: mesh, pierścień, magistrala, gwiazda, drzewo itd., które mogą mieć różne wymogi odnośnie QoS oraz powinny posiadać możliwość wzajemnego połączenia wraz z zapewnieniem nadmiarowości takiej finalnej topologii. Łatwość adresowania i identyfikacji wszystkie identyfikatory muszą jednoznacznie wskazywać lokalizację i funkcjonalność danego urządzenia, które dodatkowo musi być adresowalne i osiągalne z dowolnej lokalizacji w sieci; Wiarygodność sieci i usług implementacja mechanizmów nadmiarowości zarówno w obrębie samych urządzeń (nadmiarowość sprzętowa) sieciowych, ale przede wszystkim poprzez zapewnienie zapasowych ścieżek wraz z odpowiednimi mechanizmami routingu wykorzystywanymi w sytuacji przerwania ścieżki głównej; Uwierzytelnianie i integralność autoryzacja elementu sieciowego musi nastąpić za nim jakiekolwiek wiadomości, których integralność i wiarygodność musi być zawsze potwierdzona, będą mogły być akceptowane i wykorzystywane; QoS aplikacje automatyki przemysłowej wymagają często czasu rzeczywistego, co przekłada się na duże wymogi dla usług telekomunikacyjnych; szczególnie w zakresie parametrów jakościowych takich jak: przepustowość, opóźnienie transmisji oraz pakietowa stopa błędu Wnioski Architektura IoT@Work jest dopiero w trakcie tworzenia, a publikacja dokumentu z jej specyfikacją planowana jest na początek roku Projekt ten jest dość wąsko specjalizowany obejmuje aspekty związane wyłącznie z automatyką przemysłową. Cechą charakterystyczną IoT@Work jest wykorzystanie wielorakiego spojrzenia na architekturę systemu ze szczególnym uwzględnieniem aspektu między-warstwowej wirtualizacji. W ostatecznej architekturze duży nacisk położony zostanie na mechanizmy zarządzania dostępem do zasobów oraz bezpieczeństwem. Architektura IoT@Work będzie wspierać autokonfigurację (jako realizację idei Plug&Work) na wszystkich etapach (od planowania po rekonfigurację) funkcjonowania systemu Literatura [1] Szczegółowy opis projektu IoT@Work, strona internetowa projektu IoT@Work: 24

25 [2] Houyou A. M. et al., D2.2 Bootstrapping Architecture, WP2 Communication Networks, Public Report, SIEMENS, June IoT Podstawowe informacje o projekcie IoT6, którego pełna nazwa brzmi Universal integration of the Internet of Things through an IPv6-based Service Oriented Architecture enabling heterogeneous components interoperability, jest projektem badawczym współfinansowanym przez Komisję Europejską w ramach 7. Programu Ramowego [1,2]. Na potrzeby jego realizacji powołane zostało konsorcjum, w którym rolę partnera wiodącego odgrywa szwajcarska fundacja Mandat International, a dodatkowo w jego skład wchodzą dwie korporacje oraz siedem ośrodków akademickich/naukowych z różnych krajów europejskich oraz Korei Płd. Całkowity budżet projektu wynosi ok. 4 mln, z czego blisko 3 mln stanowi dofinansowanie przez struktury Unijne. Projekt IoT6 został rozpisany na 36 miesięcy i będzie zrealizowany w okresie od października 2011 do września W swojej warstwie tematycznej projekt ten łączy dwa szerokie zagadnienia: Internet Rzeczy (IoT Internet of Things) oraz protokół IPv6. Formalnie zdefiniowane w dokumentach okołoprojektowych cele i zadania projektu IoT6 można podzielić na trzy kategorie: Analiza potencjału protokołu IPv6 i powiązanych standardów, a następnie wskazanie możliwości wykorzystania tego potencjału dla rozwoju Internetu Rzeczy, który w chwili obecnej zdaniem osób odpowiedzialnych za projekt IoT6 cechuje się brakiem spójnej, całościowej wizji i nie zapewnia interoperacyjności urządzeń będących komponentami IoT; Opracowanie koncepcji architektury Internetu Rzeczy, która opierałaby się na protokole IPv6. Architektura ta winna zapewniać wysoki poziom skalowalności, a także mobilność i interoperacyjność heterogenicznych urządzeń ( rzeczy ), aplikacji i usług będących elementami IoT. Ponadto planowana architektura ma w dużym stopniu wykorzystywać tzw. chmurę obliczeniową (cloud computing). Z definicji architektura IoT stworzona w ramach omawianego tu projektu ma być architekturą typu SOA (Service Oriented Architecture), czyli architekturą zorientowaną na usługi; Analiza zagadnień związanych z możliwościami interakcji i współpracy urządzeń oraz usług, w tym problematyki dotyczącej m.in.: (a) systemów dystrybucji informacji, (b) interoperacyjności urządzeń korzystających z różnych protokołów, (c) integracji urządzeń mobilnych z sieciami komórkowymi, (d) dystrybucji usług i aplikacji poprzez chmurę obliczeniową (model SaaS Software as a Service). Z praktycznego punktu widzenia najbardziej istotnym wynikiem prac IoT6 będzie opracowanie całościowej wizji architektury Internetu Rzeczy; niestety z uwagi na wczesne stadium zaawansowania projektu, w chwili obecnej pełny opis tej architektury jeszcze nie istnieje. Wstępna jej wersja zostanie przedstawiona w raporcie, który ma być opublikowany pod koniec bieżącego roku, zaś wersja ostateczna dopiero w drugiej połowie roku W momencie opracowywania niniejszego dokumentu, jedynym konkretnym wynikiem prac w ramach IoT6 jest dokument Deliverable D1.1 IoT6 use-case scenario and requirements definition report, który m.in. opisuje konkretne założenia i wymagania techniczne, które mają stanowić podstawę przyszłej architektury IoT6. 25

26 2.5.2 Dostępne informacje na temat planowanej architektury Internetu Rzeczy Zgodnie z dokumentem D1.1, fundamentalnym celem konsorcjum IoT6 jest opracowanie (a następnie przetestowanie) architektury, który byłaby w stanie połączyć w całość najróżniejsze segmenty przyszłego Internetu Rzeczy, a także: zasoby wirtualne, np. aplikacje udostępniane zdalnie poprzez chmurę obliczeniową, narzędzia zarządzania procesami biznesowymi, usługi internetowe oraz sieci komórkowe. Aby było to możliwe, konieczne będzie uwzględnienie i powiązanie trzech typów sieci: Globalna sieć Internet (WAN) dla umożliwienia interakcji i integracji z zasobami zdalnymi (np. SaaS); Sieci lokalne (LAN) które są zarządzane przez lokalnych operatorów lub użytkowników końcowych; Sieci IoT które w ogólności mogą dzielić się na sieci wykorzystujące protokoły będące pochodnymi protokołu IP (np. 6LoWPAN) lub sieci, w których protokoły nie są oparte o protokół IP (np. ZigBee). Planowana architektura Internetu Rzeczy, która stanowić będzie bezpośredni rezultat projektu IoT6, ma uwzględnić i zintegrować trzy wymienione powyżej klasy sieci (patrz rys. 1). Architektura ta umożliwi zdefiniowanie głównych komponentów systemu i ich funkcjonalności, opisze metody interakcji, interfejsy oraz łącza komunikacyjne, a także scharakteryzuje narzędzia zapewniania bezpieczeństwa i prywatności w IoT. W skład architektury wejdą zarówno urządzenia zgodne z protokołem IP, jak również funkcjonujące według zupełnie innych protokołów, przy czym znalezienie sposobu integracji różnych typów protokołów będzie stanowić jedno z ważniejszych zadań realizowanych w ramach IoT6. Zgodnie z założeniami IoT6, proponowana architektura Internetu Rzeczy ma być zorganizowana wokół protokołu IPv6 twórcy projektu dostrzegają nieuchronność procesu, jakim jest ewolucja od IPv4 do IPv6 i traktują ten proces jako duże wyzwanie technologiczne. Jednak z uwagi na mnogość protokołów, mogących znaleźć zastosowanie w urządzeniach, które będą wchodzić w skład przyszłego IoT, architektura Internetu Rzeczy nie będzie mogła być ograniczona wyłącznie do protokołu IPv6, lecz będzie musiała zapewniać kompatybilność również z innym rozwiązaniami. Dokument D1.1 definiuje WSTĘPNĄ listę 9 protokołów komunikacyjnych, które będą uwzględnione podczas prac w ramach IoT6. Są to: IPv4 i IPv6; KNX (protokół komunikacyjny w budynkach inteligentnych); BACnet (protokół komunikacyjny integrujący systemy automatyki budynkowej i sterowania niezależnie od ich producenta); ZigBee (protokół przeznaczony dla urządzeń sieci WPAN, działających wg standardu IEEE ); 6LoWPAN (protokół umożliwiający transmisję pakietów IPv6 w sieciach WPAN ); DALI (protokół służący do kontroli oświetlenia w budynkach); NFC (standard wymiany danych na bardzo niewielką odległość do 20 cm); M-Bus (Meter-Bus standard służący do zdalnego odczytu wskazań np. licznika gazu czy wodomierza). 26

27 SaaS (Software as a Service) Usługi webowe Sieci komórkowe Sieć Internet (WAN) Sieci lokalne (LAN) Rys. 1 Sieci, które zostaną uwzględnione w przyszłej architekturze IoT6 [1] W dokumencie D1.1 znaleźć można również wstępny wykaz urządzeń, które będą zintegrowane w architekturze IoT6: Bezprzewodowy i przewodowy sprzęt korzystający z protokołu IPv6; Telefony komórkowe; Sensory (w tym: czujniki obecności, temperatury oraz czujniki medyczne, itp.); Systemy monitoringu; Urządzenia automatyki domowej (w tym: urządzenia kontrolne, systemy sterowania klimatyzacją, otwieraniem/zamykaniem okien oraz oświetleniem); SaaS narzędzia/aplikacje udostępniane w chmurze obliczeniowej, zgodnie z modelem SaaS (Software as a Service); Inne urządzenia (w tym: alarmy, ekrany TV, mikrofony/głośniki). Niezwykle ważną część dokumentu D1.1 stanowi syntetyczny wykaz konkretnych założeń i wymagań technicznych dotyczących planowanej architektury Internetu Rzeczy. Wymagania te zostały opracowane w oparciu o: (a) przegląd ogólnych uwarunkowań przyszłego Internetu Rzeczy, (b) analizę potrzeb konkretnych sektorów, w których IoT może odgrywać istotną rolę (automatyka budynkowa, smart grid, telemedycyna itp.), (c) opinie przyszłych użytkowników Internetu Rzeczy oraz (d) na podstawie analizy konkretnych scenariuszy zastosowań IoT (usecase). Należy jednak podkreślić, iż w dokumencie D1.1 wymagania te zostały przedstawione wyłącznie w formie listy, na dużym poziomie ogólności bez informacji szczegółowych, które omawiałyby np. sposób, w jaki konkretne wymagania miałyby zostać zaimplementowane w praktyce. Najważniejsze z wymagań technicznych dotyczących przyszłej architektury IoT6 zestawiono poniżej. Architektura IoT6, zgodnie z dokumentem Deliverable D1.1 powinna spełniać m.in. następujące wymagania: Zapewnienie możliwości wzajemnej komunikacji (za pośrednictwem sieci Internet) Urządzenia korzystające z protokołów opartych o IP Sieci IoT Urządzenia korzystające z protokołów innych niż IP wszystkim komponentom IoT, niezależnie od ich lokalizacji geograficznej; Zgodność z protokołem IPv6, przy jednoczesnym zapewnieniu wsparcia dla innych protokołów wykorzystywanych przez urządzenia wchodzące w skład Internetu Rzeczy (patrz lista powyżej); o Wspieranie adresacji zgodnej z IPv6, IPv4, 6LoWPAN i innymi protokołami 27

28 Wysoka skalowalność (ze względu na bardzo dużą liczbę urządzeń połączonych Internetem Rzeczy); Wsparcie dla mobilności węzłów; Integracja i interoperacyjność możliwie szerokiej klasy heterogenicznych urządzeń oraz usług (patrz lista powyżej); Obsługa trybów multicast i anycast; Łączność end-to-end (Architektura IoT6 winna zapewniać łączność end-to-end pomiędzy obiektami IoT6, niezależnie od ich aktualnej lokalizacji); Smart routing (Architektura powinna wspierać routing uzależniony od treści /contentbased routing/, czyli np. być w stanie rozróżnić wiadomości alarmowe od innych typów wiadomości); Optymalizacja rozmiaru nagłówka i danych przesyłanych przez sieć; Wsparcie dla mechanizmów wiarygodności transmisji (w tym np. możliwość weryfikacji, czy wiadomość została pomyślnie odebrana przez adresata); Mechanizmy priorytetyzacji dla obsługi szczególnie ważnych pakietów; Integracja mechanizmów QoS; Wsparcie dla mechanizmów bezpiecznej komunikacji; o Uwierzytelnianie i autoryzacja o Szyfrowanie o Kontrola dostępu Implementacja mechanizmów prywatności; Kompatybilność z trybami pull i push (przy czym pull oznacza tryb, w którym węzeł A może przekazać informację węzłowi B wyłącznie wtedy, gdy węzeł B sam bezpośrednio zażądał tych danych od węzła A; w trybie push z kolei to węzeł A (nadawca) niejako inicjuje przesłania danych); Wsparcie dla mechanizmów plug and play; Katalog zasobów (resource directory) jednym z elementów przyszłej architektury IoT6 powinien być tzw. katalog zasobów, w którym znajdowałby się wykaz wszystkich urządzeń podłączonych w danej chwili do Internetu Rzeczy; Samokonfiguracja (architektura IoT6 powinna umożliwiać samokonfigurację urządzeniom, które zostały włączone do Internetu Rzeczy w tym uzyskanie przez nie adresu IP oraz rejestrację w lokalnym rejestrze zasobów); Self-healing architektura IoT6 powinna zapewniać wykrywanie wszelkich problemów z dostępem do sieci, a także wyznaczać alternatywną trasę routingu w przypadku awarii któregoś z węzłów; Obsługa błędów (w tym mechanizmy sygnalizacji oraz rejestrowania /logowania/ wszelkich niespodziewanych zdarzeń w systemie); Narzędzia zabezpieczania węzłów przed skutkami chwilowych awarii i innych nieprawidłowości w funkcjonowaniu IoT (np. po chwilowej przerwie w zasilaniu, urządzenia IoT6 powinny być w stanie samodzielnie powrócić do stanu sprzed awarii) Wnioski Jednym z najważniejszych celów projektu IoT6 jest opracowanie pełnej architektury Internetu Rzeczy, w tym zdefiniowanie komponentów systemu i ich funkcji, interfejsów i łączy komunikacyjnych, a także metod interakcji między urządzaniami wchodzącymi w skład IoT. Niestety realizacja projektu rozpoczęła się dopiero w październiku 2011 roku, w związku z czym jego zaawansowanie jest w chwili obecnej niewielkie (projekt przewidziany jest na 36 miesięcy). Wstępnych informacji na temat architektury IoT6 spodziewać się można dopiero 28

29 pod koniec roku 2012, zaś wersji finalnej w roku Na dzień dzisiejszy sformułowany został jedynie syntetyczny zbiór wymagań technicznych, które mają definiować najważniejsze cechy tworzonej architektury (nie jest to jednak lista, którą należy traktować jako zamkniętą i ostateczną). W ogólności architektura IoT6 opierać się będzie na protokole IPv6, jednak z uwagi na konieczność zapewnienia interoperacyjności szerokiej gamie heterogenicznych urządzeń ( rzeczy ), konieczne będzie zapewnienie wsparcia również dla innych protokołów, potencjalnie wykorzystywanych przez te urządzenia (np. ZigBee). Inne ważne wymagania stawiane tworzonej architekturze to m.in. możliwie duża skalowalność, wsparcie dla mobilności węzłów, obsługa mechanizmów zapewniania jakości transmisji, a także prywatności. Ważnym elementem architektury IoT6 mają być aplikacje i usługi udostępniane poprzez tzw. chmurę obliczeniową Literatura [1] Deliverable D1.1, IoT6 use-case scenario and requirements definitions report, version 1.0, March 2012 [2] Strona internetowa projektu: IoT-i Projekt Internet of Things Initiative (IoT-i) wystartował we wrześniu 2010 roku w ramach 7. Projektu Ramowego Unii Europejskiej. Jego zakończenie planowane jest na 30 sierpnia 2012 roku. Budżet projektu określono w wysokości mln Euro, koordynatorem projektu jest dr. Francois Carrez z University of Surrey. Strona internetowa projektu: Główne zadania projektu to: 1. wypracowanie wspólnego pola działania w zakresie IoT przez główne, europejskie organizacje pracujące w dziedzinie IoT w celu opracowania wspólnej wizji IoT, 2. włączenie opracowanej wizji do procesów developerskich Future Internet, 3. działalność ponad granicami państw i branż technologicznych w dziedzinie IoT. IoT-i dąży do osiągnięcia następujących celów: 1. stworzenie całościowej, strategicznej i technicznej wizji IoT, która połączy pofragmentowaną obecnie działalność EU na polu IoT, 2. wspieranie rozwoju ekonomicznie i społecznie akceptowalnego otoczenia dla IoT, 3. wspieranie badań w dziedzinie IoT, 4. tworzenie środowiska sprzyjającego międzynarodowej adaptacji europejskiej technologię IoT. Analiza dokumentów IoT-i pozwala uogólnić działania projektu (w zakresie technicznym) do próby odpowiedzi na następujące pytania: 1. Czym jest IoT w obecnie realizowanych projektach? 2. Jakie są oczekiwania wobec IoT? 3. Jakie zadania badawcze wydają się obecnie kluczowe na drodze do zbudowania IoT? Poszukiwanie odpowiedzi na powyższe pytania odbywa się poprzez: analizę obecnych projektów z zakresu IoT, przegląd scenariuszy IoT prezentowanych w projektach, przeprowadzenie ankiet i konsultacji społecznych Model referencyjny i architektura referencyjna Model referencyjny i referencyjna architektura dostarczają opisu na poziomie abstrakcji 29

30 wyższym niż opisy aktualnych systemów i aplikacji. Obydwa są bardziej abstrakcyjne niż architektury systemów zaprojektowanych dla konkretnych zastosowań. Z literatury [1] możemy ekstrapolować zależności między architekturą referencyjną, architekturą i obecnymi systemami (rys. 1). Rys 1: Relacje między modelem referencyjnym, architekturą referencyjną, architekturą i aktualnymi systemami [1,2] W wyniku przeglądu europejskich projektów z dziedziny IoT modele referencyjne Internetu Rzeczy podzielono obecnie proponowane na następujące kategorie: Device-centic Entity-centric Technologycentric Service-based IoT Focus Technologie Projekty Komunikacja ze światem fizycznym Context-aware applications & services Automatyczna identyfikacja Real World Service Oriented Architectures Sensory, aktuatory, tagi Entities, Resources, Context RFID, AIDC, ucode REST, DPWS, CoAP ETSI TC M2M, TIA TR- 50.1, IETF: 6LoWPAN, ROLL, LWIG EU FP7 projekty SENSEI i IoT-A, OGC ISO, EPCglobal, EU FP7 Project CASAGRAS W3C, OASIS, IETF W modelu device-centric urządzenie IoT (małe urządzenia jak czujniki i siłowniki) definiowane jest jako główny element systemu i służy ono do komunikacji ze światem fizycznym. Oznacza to, że urządzenie ma możliwość monitorowania i kontroli parametrów świata fizycznego, a także dostarcza informacji identyfikującej urządzenie. Urządzenie takie jest podstawowym blokiem do budowy systemów IoT. Szczególnym przypadkiem urządzenia jest brama wyjściowa (gateway). Brama dostarcza dodatkowych funkcjonalności takich jak łączność między różnymi technologiami sieciowymi, lokalne zbieranie lub uruchamianie zadań pomiarowych i wykonawczych, zapewnienie bezpieczeństwa. W modelu entity-centric monitorowany jest obiekt rzeczywisty (paleta, ciężarówka, obora) i to on jest głównym elementem systemu. Przykładem zastosowania modelu entity-centric jest projekt SENSEI, który ma na celu budowę szkieletu architektury (architectural framework) integrującej różne bezprzewodowe sieci sensorowe w jednorodny sposób aby odwzorować świat realny w świat cyfrowy [3 i 4]. Ważnym aspektem SENSEI było połączenie obu światów na odpowiednim poziomie abstrakcji (rys. 2). Innym modelem typu entity-centric jest model zaproponowany przez projekt IoT-A [5]. W projekcie tym podkreśla się następujące wyzwania stojące przed IoT: współpraca 30

31 różnorodnych technologii, skalowalność, zarządzanie dużą liczbą urządzeń, zwłaszcza poprzez samo-zachowania i autonomiczność, mobilność, bezpieczeństwo i prywatność, niezawodność, przyszły rozwój. Rys. 2 Poziomy abstrakcji w projekcie SENSEI [6] Modele technology-centric budowane są na bazie jednej lub kilku technologii, np. technologia automatycznej identyfikacji i zbierania danych (AIDC) w szczególności RFID, EPCglobal oraz ucode. Modelem, który wydaje się spełniać oczekiwania stawiane przed IoT, jest model zorientowany na usługi (service-oriented). Bazujące na nim architektury Service-Oriented Architectures (SOA) są wiodącym paradygmatem w rozwoju aplikacji rozproszonych działających w zróżnicowanym środowisku, bazującym na różnym sprzęcie, językach programowania i gdzie wymagana jest integracja elementów różnych części [7]. W SOA funkcjonalności implementowane są w formie usług, posiadających interfejsy usług. Usługi są niezależnymi elementami, które mogą być wykrywane dynamicznie i używane w wielu różnych aplikacjach, które mają możliwość korzystania z kilku różnych usług dla swoich potrzeb. Aby była możliwa współpraca różnych usług, zarówno usługi jak i ich interfejsy powinny być formalnie zdefiniowane (opisane). Ponadto aby dać możliwość wykrywania usług, Usługa Wykrywania (Discovery Service) wymaga meta-informacji opisujących wykrywaną usługę. Na tej podstawie właściwa usługa dla danego zadania, np. będącego częścią większego procesu (algorytmu), może być znaleziona i włączona do współpracy z innymi usługami w celu realizacji całego procesu. Zalety funkcjonalności zorientowanej na usługi to: modułowość (modularity), możliwość wielokrotnego użycia (reusability), rekonfigurowalność (reconfigurability), działanie niezależne od sprzętu (interoperability). Idea SOA jest obiecującym kierunkiem dla integracji Rzeczy w większe systemy, np. jako części algorytmów (workflows). W tym przypadku funkcjonalności, dające dostęp do Rzeczy, w celu odbioru informacji, włączenia aktuatora lub umożliwienia współpracy, implementowane są jako usługi. Różnica między zwykłymi usługami SOA a usługami w IoT polega na właściwościach urządzeń dostarczających te usługi. W IoT urządzenia mogą podlegać ograniczeniom w zakresie dostępnej energii, mocy obliczeniowej, pojemności pamięci i możliwości komunikacyjnych. Ponadto w IoT usługi mogą być często niedostępne ze względu na problemy z komunikacją lub niedostępność samego urządzenia. Możliwa jest też sytuacja, w której urządzenie przez większą część czasu pracuje offline i tylko od czasu do czasu komunikuje się z siecią. Zagadnienia te muszą być brane pod uwagę podczas modelowania algorytmów i sposobów współpracy usług. Czynniki te mają wpływ na decyzje o wyborze technologii, która pozwoli je zrealizować. Typowe technologie usług internetowych (Web Service), jak bazujące na SOAP (Simple Object Access Protocol) usługi internetowe opisane przez WSDL i standard na nich oparty, 31

32 mogą być zbyt ciężkie dla usług w IoT. Aby umożliwić integrację urządzeń o ograniczonych zasobach ze środowiskiem usług internetowych, wyspecyfikowano Profil Urządzenia dla Usług Internetowych (Devices Profile for Web Services DPWS). Ponadto wydaje się, że najbardziej właściwa dla IoT jest architektura RESR (Representational State Transfer). Koncepcja REST opiera się na zasobach (resources), które mogą wykonywać cztery podstawowe operacje: utwórz (Create), czytaj (Read), odśwież (Update) i kasuj (Delete). Operacje te mogą być bezpośrednio mapowane do operacji GET, PUT, POST i DELETE protokołu http. Wiele projektów z zakresu IoT stosuje architekturę REST. Architektura SOA rozwijana jest obecnie w projektach: Hydra, EBBITS [8] i CHOREOS [9]. Ponieważ protokół http jest zbyt ciężki do technologii komunikacji stosowanej w urządzeniach o ograniczonych zasobach, jak węzły sieci sensorowej, dlatego też rozwijany jest obecnie przez IETF [10] protokół CoAP (Constrained Application Protocol). CoAP, który jest zgodny z ideą REST, charakteryzuje się małą nadmiarowością protokołu komunikacyjnego (low overhead) i ma na celu uproszczenie komunikacji dla środowiska z ograniczaniami. Podjęto kilka prób zdefiniowania modelu referencyjnego SOA jak Open-SOA Service Component Architecture (SCA) lub OASIS SOA Reference Model [11]. Mimo to model taki w praktyce nie istnieje. Rozwiązania zorientowane na usługi są więc oparte na technologiach (usługi internetowe, usługi OSGi, DPWS, UPnP), które nie pozwalają na współpracę między różnymi technologiami. Podobnie ma się sprawa z usługami IoT. IoT-i największą szansę w rozwoju IoT dostrzega w budowie Internetu Przyszłości (Future Internet - FI). Głównymi elementami FI mają być właśnie IoT oraz Internet Usług (Internet of Services IoS). FI budowany ma być w oparciu o Sieć Następnej Generacji (Next Generation Network NGN). NGN jest siecią pakietową dostarczającą usług telekomunikacyjnych i mogącą korzystać z różnych technologii szerokopasmowych. Ideą NGN jest rozdzielenie usług od technologii transportu (związanej z warstwą fizyczną). NGN może wspierać IoT na dwóch poziomach: integracji urządzeń oraz funkcjonalności sprzyjającej w rozwoju usług. Jednym z najbardziej krytycznych elementów NGN jest wsparcie dla różnych technologii łączności mobilnej i stałej, np. HFC, PLC, satelity, GPRS, CDMA, HSDPA lub xdsl. NGN ma zapewnić takie funkcjonalności jak: identyfikację, autoryzację, ochronę prywatności i bezpieczeństwo, QoS, wykrywanie i mobilność, obsługę płatności czyli funkcje wymagane również w IoT. Funkcje te wraz z innymi zdefiniowanymi przez Open Mobile Alliance (OMA) [12] mogą stanowić wydajne środowisko dostarczania usług Uwagi podsumowujące Projekt IoT-i stawia wiele pytań, na które twórcy IoT powinni szukać odpowiedzi. Pytania te podzielono na kategorie: autonomiczność, infrastruktura, sieci i komunikacja, procesy, zarządzanie danymi, prywatność i bezpieczeństwo, zarządzanie energią przez urządzenia IoT, standaryzacja, aspekty społeczne, ekonomiczne i prawne. Autonomiczność Autonomiczność rozumiana jest jako zdolność systemu do samozarządzania z użyciem obiektów wysokiego poziomu i strategii zdefiniowanej przez człowieka. Określono następujące zadania do dalszych badań: właściwości systemu autonomicznego: samoadaptacja, samoorganizacja, samooptymalizacja, samokonfiguracja, samoochrona, samonaprawa, samookreślenie, samowykrywanie, samorozpoznawanie, samozaopatrzenie w energię, tworzenie modeli systemów autonomicznych. Infrastruktura 32

33 W przyszłości IoT stanie się częścią codziennego życia. Oznacza to, że stanie się on częścią otaczającej nas infrastruktury jak np. woda, elektryczność, telefon, TV a obecnie też Internet. Jednak dziś Internet łączy komputery większych rozmiarów, zaś IoT (jako część FI) będzie łączył otaczające nas obiekty silnie zintegrowane ze światem fizycznym. W stosunku do infrastruktury można postawić następujące pytania: Jak osiągnąć funkcjonalność plug-and-play biorąc pod uwagę różnorodność technologii? Jaka powinna być infrastruktura wykrywająca, aby znajdowanie rzeczy było wydajne? Jak monitorowanie i automatyczna adaptacja będą wspierane przez infrastrukturę? Jak informacje semantyczne mogą być łatwo dodane i użyte wewnątrz infrastruktury? Jak nowe informacje semantyczne mogą być uzyskane z już istniejących, znajdujących się w dodatkowych bazach wiedzy o świecie, i jak może to być wspierane przez infrastrukturę? Jak informacja o pozycji fizycznej może być odzwierciedlona przez infrastrukturę, aby wspierać wymagane funkcjonalności? Jakie powinno być wsparcie infrastruktury dla prywatności i bezpieczeństwa? Jak infrastruktura może wspierać płatności i rozliczenia jako podstawę różnych modeli biznesu IoT? Sieć i komunikacja W czasie rozwoju IoT wzrośnie liczba połączonych z siecią urządzeń, zwiększy się liczba ich funkcji oraz wzrośnie ich zasięg geograficzny, co oznacza wzrost zapotrzebowania na zasoby komunikacyjne, infrastrukturę i sieci. Urządzenia IoT w znacznym stopniu wpłyną na te zmiany. W tej kategorii określono tematy badawcze: technologia sieciowa, jej złożoność, wzrost znaczenia sieci bezprzewodowych, sieci mobilne, przejście od sieci obecnych do sieci przyszłości, nakładanie się sieci, samoorganizacja sieci, ekologia sieci, technologia komunikacyjna, zbadanie potencjału obecnych technologii, poprawność konstrukcji, budowa modelu jednorodnej struktury komunikacyjnej, urządzenia o ograniczonych zasobach energetycznych. Procesy Zdefiniowano następujące tematy do badań: procesy adaptacyjne i reagujące na zdarzenia, procesy mające do dyspozycji niepewne dane, procesy operujące na niepewnych zasobach, procesy o dużym rozproszeniu. Zarządzanie danymi W zakresie zarządzania danymi określono następujące tematy badawcze: zbieranie danych i ich analiza, duże zbiory danych, semantyczne sieci sensorowe i semantyczne opisywanie danych, sensory wirtualne, complex event processing. Rekomendacja dalszych prac badawczych Jednocześnie IoT-i przedstawia rekomendacje do dalszych badań w dziedzinie IoT. Poniżej wymieniono wybraną część tematów obejmujących zagadnienia techniczne: wydajny i prosty mechanizm interakcji z rzeczami, tworzenie wiedzy i jej dostępność, tworzenie interdyscyplinarnych projektów z zakresu inteligentnej energetyki i mobilności, 33

34 łagodna integracja sieci sensorowych ze społeczeństwem, infrastruktura dla społecznych interakcji między obiektami podłączonymi do Internetu, chmura rzeczy, przejście od projektu do zastosowania samoświadomości, łatwa rozbudowa i podłączenie do infrastruktury, główna część infrastruktury wspierająca podejmowanie decyzji, wykrywanie, monitorowanie i adaptację, badania sieci mobilnych i sieci sieci (mobile networks of networks), modelowanie obciążenia przyszłej sieci IoT, symbioza ruchu sieciowego i przetwarzania rozproszonego (symbiosis of networking and IoT related distributed data processing), adaptacja protokołu IP (adapting the IP protocol paradigm), otwarte architektury systemów komunikacyjnych (open communication architectures), architektury dla urządzeń o ograniczonych zasobach, (communication architectures for (highly) constrained devices), lekkie protokoły czasu rzeczywistego i platformy (real-time lightweight protocols and platforms), modelowanie procesów samoświadomości IoT (modelling of IoT-aware processes), niepewność procesów samoświadomości (inherent unreliability of IoT-aware processes), wykonywanie procesów samoświadomości (execution of IoT-aware processes), duże rozproszenie procesów (large-scale distribution of process logic), niskie zużycie energii (low power communication), ultra szerokie pasmo (ultra-wide band), zasilanie słoneczne i termalne (solar and thermal energy harvesting), zasilanie energią drgań (vibration energy harvesting) Literatura [1] G. Mueller, "A Reference Architecture Primer", 2008, [stan z ] [2] Walewski, J. (Editor), Initial Architectural Reference Model for IoT, IoT-A Project Deliverable D1.2, [stan z ] [3] Barnaghi, P. (Editor), "Final SENSEI Architecture Framework", SENSEI Project Deliverable D3.6, 2011 [4] Herault, L. (Editor), "Project Final Report", SENSEI Project Deliverable D7.16, 2011 [5] EU FP7 project IoT-A, terminology definitions. On-line resource, [stan z ] [6] First Reference Model White Paper [7] Service Oriented Architectures for All (SOA4All), EU FP7 Project. [stan z ] [8] Enabling business-based Internet of Things and Services An Interoperability platform for a real-world populated Internet of Things domain (EBBITS), EU FP7 Project, [stan z ] [9] Large Scale Choreographies for the Future Internet (CHOREOS), EU FP7 Project, [stan z ] [10] Shelby, Z., Hartke, K., Bormann, C., Frank, B., Constrained Application Protocol (CoAP), IETF draft. [stan z ] [11] C. M. MacKenzie, K. Laskey, F. McCabe, P. F. Brown, R. Metz, B. A. Hamilton (Ed s), Reference Model for Service Oriented Architecture 1.0, OASIS, [stan z ] [12] OMA Service Environment Archive, [stan z ] 34

35 2.7 Projekt icore Nazwa projektu icore ( ) jest akronimem od określenia (w wolnym tłumaczeniu) Obiekty połączone przez Internet dla systemów rekonfigurowalnych (Internet Connected Objects for Reconfigurable Systems). Określa ona istotę projektu. Zasadniczych informacji udziela również motto projektu (w wolnym tłumaczeniu): Urzeczywistnienie IoT poprzez technologie kognitywne Tutaj pojawia się wątpliwość. W opisach ogólnych projektu, technologie kognitywne opisywane są jako platforma kognitywna umożliwiająca zarządzanie (kognitywne) obiektami wirtualnymi. Podczas Future Internet Week w Poznaniu w roku 2011 projekt icore organizował sesję pt. Empowering IoT through virtual objects and cognitive radio. Należy spostrzec, że w tytule sesji pojawił się termin cognitive radio, który występuje również w innych informacjach publikowanych przez projekt. Radio kognitywne jest bardzo nowoczesną, rozwijaną obecnie techniką radiokomunikacyjną i jest czymś zasadniczo odmiennym od platformy kognitywnej obiektów wirtualnych. Partnerzy w projekcie zostali podzieleni na trzy grupy: Partnerzy przemysłowi o Alcatel-Lucent Bell Labs, oddział europejski we Francji o FIAT Research Centre, o Siemens, oddział w Rumunii o Thales, o Telecom Italia, o Atos Origin, o Software AG, uniwersytety/instytuty badawcze o CREATE-NET o Joint Research Centre (JRC Ispra) centrum będące częścią Komisji Europejskiej, ma za zadanie poprzez badania naukowe wspierać decyzje polityczne o The Netherlands Organisation for Applied Scientific Research (TNO) organizacja badawcza non-profit o VTT Technical Research Centre of Finland o Uniwersytet Techniczny Delft, o Uniwersytet Surrey, o Uniwersytet Pireus, o Wuxi SensingNet Industrialization Research Institute czołowa chińska organizacja zajmująca się IoT, szczególnie problemami standaryzacji. Małe/średnie przedsiębiorstwa (Small Medium Enterprises SME) o ZIGPOS, Niemcy o Ambient Systems B.V., Holandia o InnoTec21 GmbH, Niemcy Projekt icore jest w pełni zgodny z polityką Komisji Europejskiej dotyczacej IoT zawartą w dokumencie Internet of Things - An action plan for Europe COM(2009)278. W dokumencie tym Komisja nakreśliła 14 linii działania. Projekt icore realizuje bezpośrednio 4 z nich, są to: Governance, IoT as a vital resource to economy and society, Standard mandate, International Dialogue 35

36 Badacze w projekcie icore postanowili zajmować się zagadnieniami (jak to określili) w dwóch kluczowych obszarach z dziedziny IoT: 1. Jak abstrahować od technologicznej heterogeniczności, która bezpośrednio wynika z dużej rozmaitości i heterogeniczności obiektów rzeczywistych, równocześnie podnosząc niezawodność działania systemu; 2. Jak uwzględniać punkt widzenia poszczególnych użytkowników/ udziałowców systemu (rozumianych jako właściciele obiektów i środków komunikacji) w celu zapewnienia odpowiednich aplikacji, poziomu integracji i maksymalizacji wykorzystania wszystkich możliwości systemu Jako rozwiązanie tak postawionych, ogólnych problemów, zaproponowano budowę platformy kognitywnej (nazywanej również kognitywną platformą zarządzania ) zbudowanej z trzech poziomów funkcjonalności, które mogą być wielokrotnie używane przez różne aplikacje. Poziomy te to: 1. Obiekty Wirtualne (Virtual Objects - VO). VOs są kognitywnymi, wirtualnymi reprezentacjami rzeczywistych obiektów (np. sensorów, urządzeń, rzeczy codziennego użytku), które maskują heterogeniczności technologiczne występujące pomiędzy tymi obiektami (np. różne interfejsy komunikacyjne) 2. Złożone Obiekty Wirtualne (Composite Virtual Objects - CVO). CVOs mają w założeniu być kognitywnym połączeniem semantycznie interoperacyjnych obiektów wirtualnych (VOs) i realizować usługi zgodnie z wymaganiami użytkowników/ udziałowców. 3. Bloki Funkcjonalne (reprezentujące perspektywę użytkowników/ udziałowców ) Wszystkie rozwiązania icore będą wyposażone w odpowiednie protokoły i mechanizmy zapewniające bezpieczeństwo danych, prywatność a także sterowany I kontrolowany dostęp do obiektów. Aby dokonać oceny rzeczywistych rozwiązań, postanowiono w projekcie icore zrealizować scenariusze użytkowe w czterech obszarach: 1. ambient assisted living 2. smart Office 3. smart transportation 4. supply chain management Na tej podstawie określono w projekcie cztery domeny aplikacji: Inteligentny Dom (Smart Home), Inteligentne Miasto (Smart City), Inteligentne Spotkanie (Smart Meeting) i Inteligentny Biznes (Smart Bussines). Na podstawie ogólnych zagadnień określonych w dwóch kluczowych obszarach (opisanych powyżej) postanowiono zrealizować siedem celów szczegółowych, zorientowanych na konkretne wyniki: 1. Realizacja platformy zarządzania kognitywnego, która ułatwi i wesprze łączenie obiektów przez Internet. 2. Realizacja obiektów wirtualnych (VO) w formie kognitywnych, wirtualnych reprezentacji obiektów. 3. Realizacja złożonych obiektów wirtualnych (CVO) 4. Realizacja bloków funkcjonalnych reprezentujących wymagania aplikacji oraz użytkowników/ udziałowców. 5. Realizacja protokołów i mechanizmów bezpieczeństwa 36

37 6. Weryfikacja poprzez realizację scenariuszy wykorzystujących stworzoną platformę w postaci aplikacji w najważniejszych obszarach Internetu Przyszłości. 7. Realizacja niezbędnych aktywności standaryzacyjnych I eksploatacyjnych. Popularyzacja wyników projektu Wnioski Podsumowując, projekt icore ma dostarczyć kompletną platform zarządzania dla IoT, która umożliwić operowanie różnorodnymi obiektami oraz funkcjami i usługami, które te obiekty dostarczają. Rozwiązanie to ma wspierać IoT ekosystem w którym występuje wiele różnych obiektów, użytkowników i aplikacji. Ponieważ projekt rozpoczął się osiem miesięcy temu, nie upubliczniono jeszcze żadnych konkretnych rezultatów i dokumentów W projekcie icore postanowiono wykorzystać architektury IoT opracowane już w projektach IoT-A i Santander Literatura [1] Strona internetowa projektu: Projekt AKARI Prace nad projektem o nawie AKARI rozpoczęto w Japonii w 2006 roku. Ich celem jest stworzenie architektury sieci nowej generacji (New Generation Network NWGN) oraz jej implementacja w eksperymentalnej sieci do 2015 roku. Jednym z założeń projektu AKARI było zaprojektowanie sieci od podstaw, w oderwaniu od rozwiązań istniejących obecnie. W dokumencie [1] podsumowującym rezultaty projektu AKARI uzyskane do 2010 r. wyróżniono pięć modeli architektury (pięć pod-architektur) sieci do różnych zastosowań. Model A: An integrated architecture based on layered model with cross-layer collaboration. Jest to model architektury warstwowej, obejmujący warstwy od fizycznej do aplikacji, ale stworzony z założeniem możliwości wymiany informacji pomiędzy dowolnymi warstwami. Model B: An architecture that reduces duplicated functions in lower layers (i.e., network layer or below) and simplifies the layered model. Model architektury, w którym zaproponowano nowe podejście do zadań warstw poniżej warstwy sieciowej. Model C: An architecture for QoS guaranteed and multicasting. Model architektury proponowany dla potrzeb gwarantowania QoS oraz transmisji w trybie multicast, polega na innowacyjnym zaprojektowaniu funkcji warstwy transportowej. Model D: An architecture for connecting heterogeneous devices and networks. Model architektury, w którym zakłada się możliwość dołączenia do NWGN różnorodnych (heterogenicznych) urządzeń i sieci. 37

38 Model E: An mobile access architecture for sensor-information distribution and regional / individual adaptive services. Model architektury inteligentnej sieci dostępowej dla realizacji platformy usług mobilnych integrującej w NWGN usługi sieci komórkowych, WLAN, radiowych sieci sensorowych i in Model D i E Rysunek 1: Architektura zapewniająca integrację heterogenicznych sieci dostępowych [1] Cechą charakterystyczną modelu D jest rozgraniczenie pomiędzy adresem fizycznym a numerem identyfikacyjnym (ID) hosta. Wynika ono z potrzeby zapewnienia komunikacji pomiędzy różnymi urządzeniami przemieszczającymi się w obrębie różnorodnych sieci. W modelu sieci przedstawionym na rysunek 1 pokazano nową warstwę Generic Identity Layer, która jest odpowiedzialna za określenie fizycznej lokalizacji urządzenia na podstawie jego ID. W ramach projektu AKARI wykorzystując koncepcję modelu E zaprojektowano rozproszoną sieć radiową (Regional Distributed Wireless Network), nazwaną "NerveNet", z małymi stacjami bazowymi mającą zapewnić przesyłanie informacji z/do sensorów np. w przypadku katastrofy, której skutkiem jest awaria sieci komórkowych. Warstwa Sensor Network Platform znajdująca się pomiędzy sensorami a warstwą aplikacji odpowiada za realizację funkcji sieciowych i zarządzanie. Jest ona wyposażona w dwa interfejsy: Sensor Connection Gateway Interface, który spełnia rolę bramy odpowiedzialnej za zbieranie danych z sensorów i przesyłanie ich do warst wyższych, Sensor Network Application Gateway Interface, który zapewnia współpracę z warstwą aplikacji. 38

39 Rysunek 2:. Model warstwowy sieci NerveNet zaprojektowanej w ramach projektu AKARI Wniosek Dla potrzeb tworzenia architektury testowej sieci Internetu Rzeczy można wykorzystać koncepcję modelu D, w którym zastosowano środki służące do określania fizycznej lokalizacji urządzeń działających w różnorodnych sieciach radiowych, w tym w sieciach sensorowych, na podstawie ich numerów identyfikacyjnych (ID) Bibliografia [1]. Hiroaki Harai et al. "New Generation Network Architecture AKARI Conceptual Design (ver 2.0), AKARI Architecture Design Project s deliverable, English Edition May [2] Projekt ASPIRE Celem projektu AspireRFID realizowanego w ramach FP7 jest opracowanie i promocja ogólnie dostępnego oprogramowania (AspireRfid middleware) przeznaczonego do projektowania, tworzenia i zarządzania aplikacjami wykorzystującymi systemy identyfikacji radiowej, RFID. Model architektury ASPIRE na stronie www projektu przedstawiono na rysunku 1. Na rysunku tym główne elementy oznaczają: TDT (Tag Data Translation) Proces zamiany formatu informacji zapisanych w tagu (identyfikatorze danego systemu RFID) na format zgodny ze standardem EPC 1. HAL (Hardware Abstraction Layer) Warstwa ta ma za zadanie umożliwić komunikację z czytnikami obsługującymi różne protokoły RFID. 1 Elektroniczny identyfikator produktu (Electronic Product Code) zaprojektowano jako uniwersalny globalny identyfikator każdego obiektu. Strukturę kodu zdefiniowano w standardzie opracowanym przez EPCglobal. Jego opis jest dostępny na stronie 39

40 RCP (Reader Core Proxy) Warstwa umożliwia konwersję różnych protokołów obsługiwanych przez czytniki RFID na zgodny z EPC. ALE (Filtering & Collection Server) Odpowiada za filtrowanie i zbieranie danych przesyłanych przez czytniki. BEG (Business Event Generator) Realizuje sortowanie danych otrzymanych z bloku ALE (ze względu np. na nazwę firmy, lokalizację, czas i in.) w celu utworzenia zdarzeń biznesowych. EPCIS (Information Sharing Repository) Pełni rolę bazy danych odpowiedzialnej za gromadzenie i dostęp do danych związanych z odpowiednimi zdarzeniami biznesowymi. Connector Application Umożliwia współpracę pomiędzy aplikacjami zarządzanymi przez użytkownika a bazą EPCIS. AspireRFID IDE Umożliwia zarządzanie poszczególnymi elementami systemu AspireRFID. Rysunek 1: Architektura przyjęta w projekcie AspireRFID Wniosek Projekt jest jednostronnie ukierunkowany na odczyt danych z identyfikatorów (tagów RFID), gromadzenie i przetwarzane tych danych. System mógłby być wykorzystany do odczytu 40

41 parametrów środowiska (sensor skojarzony z RFID). Jednak brak mechanizmów umożliwiających oddziaływanie na środowisko poprzez sterowanie elementami wykonawczymi (actuators) przesądza o niewielkiej przydatności tej architektury dla koncepcji demonstratora Internetu Rzeczy Bibliografia [1]. [2]. [3] Internet of Things Architecture (IoT-A) IoT-A jest projektem realizowanym w ramach 7. Programu Ramowego UE od 2010 roku. Jego celem jest stworzenie modelu referencyjnego architektury Internetu Rzeczy w oparciu o techniki obecnie istniejące. Model domenowy Na rysunku 1 przedstawiono model domenowy będący częścią modelu referencyjnego zaproponowanego w ramach projektu IoT-A [2, 4]. Kolorami: niebieskim, zielonym, żółtym i kremowym oznaczono odpowiednio: urządzenia, oprogramowanie, człowieka oraz elementy nie dające się zakwalifikować do żadnej z trzech wymienionych kategorii. Jednostki fizyczne (Physical Entity) są reprezentowane jako jednostki wirtualne (Virtual Entity) związane z konkretnymi funkcjonalnościami oraz właściwościami fizycznych obiektów. Wirtualna jednostka może mieć postać jednostki pasywnej (Passive Digital Entity) np. pliku, wpisu w bazie danych, lub jednostki aktywnej (Active Digital Entity) np. kodu wykonywalnego. Jednostka fizyczna może być reprezentowana przez kilka jednostek wirtualnych, z których każda ma przyporządkowany identyfikator (ID). Do każdej jednostki fizycznej jest dołączone (lub wbudowane) urządzenie (Device) sterujące jej elementami wykonawczymi (Actuator) i zbierające dane z czujników (Sensor) i tagów (Tag). Elementem, który zapewnia dostęp do informacji i funkcjonalności jednostki fizycznej jest zasób (Resource). Zasoby mogą należeć do następujących kategorii: On-Device Resource, oprogramowanie wbudowane do urządzenia umożliwiające dostęp, przetwarzanie i gromadzenie informacji, a także sterowanie elementami wykonawczymi; Network Resource, zasoby dostępne w sieci; Storage, np. bazy danych przechowujące informacje o jednostkach fizycznych. Usługa (Service) jest elementem umożliwiającym interakcję z zasobami poprzez określony interfejs (np. Internet). Rolę użytkownika (User) korzystającego z zasobów może spełniać zarówno człowiek jak i odpowiednie oprogramowanie. 41

42 Rys. 1: Model domenowy będący częścią modelu referencyjnego dla IoT Warstwowy model komunikacyjny W projekcie IoT-A dla potrzeb IoT zaproponowano warstwowy modelu komunikacyjny przedstawiony na rysunku 2, w którym wyróżniono następujące wartwy: Physical Layer (warstwa fizyczna) niezmieniona w stosunku do modelu OSI; Link Layer (warstwa łącza danych) dla potrzeb IoT powinna zapewnić adresowanie w sieciach heterogenicznych; Network Layer (warstwa sieci) niezmieniona w stosunku do modelu OSI; 42

43 ID Layer (warstwa ID) ma zapewniać ujednolicony system adresowania dla różnych urządzeń i technik komunikacji stosowanych w IoT. Odpowiada za zwracanie adresu urządzenia na podstawie numeru identyfikacyjnego; End-to-end Layer jest odpowiedzialna za konwersję protokołów umożliwiającą połączenie sieci heterogenicznych; Data Layer warstwa aplikacji. Data Layer End to End Layer ID Layer Network Layer Link Layer Physical Layer Rys. 2: Stos komunikacyjny IoT [3] Wniosek Domenowy model architektury przedstawia logiczne powiązania pomiędzy użytkownikiem (osobą lub aplikacją) a usługami i zasobami lub jednostkami fizycznymi, wirtualnymi i urządzeniami. Umożliwia zaprojektowanie systemu integrującego różne techniki adresowania i komunikacji Bibliografia [3]. [4]. Haller S. "A Domain Model for The Internet of Things". IoT Week. Barcelona, June [5]. Bassi A. IoT-A: main Architectural Reference Model concepts, 1st iot-forum, Berlin, Nov 23rd, [6]. Walewski W. J. (ed.), Project Deliverable D1.2 Initial Architectural Reference Model for IoT, Projekt SENSEI Projekt SENSEI (Integrating the Physical with the Digital World of the Network of the Future) był realizowany w ramach 7. Programu Ramowego UE w latach (Sensei Consortium FP7 Project Number ). Celem tego projektu było opracowanie globalnej, otwartej platformy dla radiowych sieci sensorów i elementów wykonawczych (Wireless Sensor and Actuator Networks, WS&ANs) umożliwiającej integrację rozproszonych WS&AN w jednym systemie. Uproszczony model architektury zaproponowanej w projekcie SENSEI przedstawiono na rysunku 1. 2 Kolejność warstw "ID Layer" powyżej "Network Layer" pokazana na rysunku jest taka jak na rysunku w prezentacji [3]. Natomiast w dokumencie [4] na odpowiednim rysunku "ID Layer" umieszczono poniżej "Network Layer", jednakże w opisie rysunku zastosowano kolejność taką jak w prezentacji [3]. 43

44 Rysunek 1: Architektura systemu SENSEI W modelu tym można wyróżnić następujące warstwy: SENSEI Resource Layer, warstwę zasobów SENSEI Warstwa obejmuje wirtualne jednostki będące odzwierciedleniem fizycznych obiektów oraz sposoby interakcji z tymi jednostkami. Communication Service Layer, warstwę usług komunikacyjnych Warstwa ta zawiera funkcjonalności odpowiedzialne za zbieranie danych i komunikację z punktami końcowymi zasobów (Resource Endpoints). Application Layer, warstwę aplikacji Jej zadania nie są ściśle określone w projekcie architektury SENSEI. Obejmuje aplikacje użytkownika (User applications) oraz usługi zarządzania (Management services). SENSEI Community Management zarządzanie środowiskiem SENSEI Warstwa ta jest odpowiedzialna za realizację funkcji, takich jak zarządzanie kontami użytkowników, identyfikacja, bezpieczeństwo i in SENSEI (Real World) Resource Layer W architekturze systemu SENSEI do modelowania świata rzeczywistego zastosowano dwa poziomy abstrakcji, przedstawione i opisane na rysunku 2Rysunek): abstrakcję wysokiego poziomu (Entity level poziom jednostki) np. budynek; abstrakcję niskiego poziomu (Resource level poziom zasobu) np. czujnik temperatury; przy czym zasoby są skojarzone z modelowanymi jednostkami. Schemat funkcjonalny systemu SENSEI przedstawiono na rysunku 3. Głównymi jego elementami są: Resource Directory skorowidz / katalog zasobów, element w którym gromadzone są informacje o zasobach systemu; Resource Endpoints punkty końcowe zasobów, elementy przechowujące dane o zasobach oraz umożliwiające interakcje z nimi; Rendezvous obrazuje interakcje pomiędzy ww. elementami, PnP elementy spełniające funkcję bram 3, za których pośrednictwem są dołączone różnorofme radiowe sieci sensorów i elementów wykonawczych (WS&ANs); 3 Ports and Protocols 44

45 Rysunek 2: Modelowanie świata rzeczywistego w systemie SENSEI Użytkownik zasobów (osoba lub aplikacja) może sprawdzać katalog zasobów oraz kierować zapytania i/lub polecenia do punktów końcowych (Resource Endpoints). Rysunek 3: Schemat funkcjonalny systemu SENSEI Schemat funkcjonalny warstwy zasobów SENSEI przedstawiono na rysunku 4, gdzie: Resource Directory katalog zasobów; Entity Directory katalog, w którym przechowywane są informacje o atrybutach jednostki; Semantic Query Resolver odpowiada za planowanie zadań na podstawie analizy semantycznej zapytań / poleceń skierowanych przez użytkownika; Execution Manager zarządza zasobami, monitoruje zapytania / polecenia i śledzi zmiany zasobów; Dynamic Resource Creation konfiguruje zasoby na żądanie użytkownika Communication Service Layer Warstwa usług komunikacyjnych SENSEI odpowiada za zbieranie danych i komunikację z punktami końcowymi. Można wyróżnić w niej następujące moduły, rysunek 5: Traffic Pattern Support odpowiedzialny za obsługę różnych rodzajów ruchu sieciowego np. okresowy, strumieniowany, oparty na zdarzeniach. żądanie/odpowiedź; 45

46 Delivery Methods zapewniający różne metody dostarczania danych, takie jak multicast/broadcast i unicast; Mobility Management zarządzający mobilnością w radiowej sieci sensorów i elementów wykonawczych (WS&AN): Address Resolution odpowiedzialny za zwracanie adresu zasobu na podstawie numeru identyfikacyjnego. Rysunek 4: Schemat funkcjonalny Resource Layer Rysunek 5: Moduły zawarte w warstwie Communication Service Na rysunku 6 przedstawiono przykład modelu komunikacji w systemie SENSEI, w którym uwzględniono podział na warstwy oraz wykorzystywane w nich protokoły komunikacyjne (gdzie REP, RU, RD oznaczają odpowiednio Resource Endpoint punkt końcowy zasobu, Resource User użytkownika zasobu, Resource Directory katalog zasobu) Platforma testowa zrealizowana w ramach projektu W platformie testowej SENSEI Pan-European system SENSEI zastosowano do integracji heterogenicznych sieci sensorowych z Internetem. Architekturę tej platformy testowej przedstawiono na rysunku 7R. Sieci sensorowe wykorzystujące protokóły ZigBee i 6lowpan i inne urządzenia połączono poprzez odpowiednie bramy i router/broker z serwerami systemu SENSEI. Użytkownik systemu mógł korzystać z funkcjonalności systemu za pomocą przeglądarki WWW. Sieć typu 6lowpan została zbudowana w oparciu o system operacyjny Contiki 4. 4 System Contiki, był także zastosowany w sieci testowej opracowanej w Z-1 w ramach pracy statutowej realizowanej w 2011 r. 46

47 Wniosek Rysunek 2.1: Warstwowy model komunikacji w systemie SENSEI Architektura SENSEI umożliwia zaprojektowanie sieci integrującej sieci sensorów i elementów wykonawczych (WS&AN) wykorzystujące różne systemy komunikacji radiowej. Umożliwia zarządzanie taką rozproszoną siecią. Umożliwia także uzyskiwanie i przetwarzanie informacji, dynamiczne zarządzanie zasobami oraz planowanie zadań. Użytkownik (osoba lub aplikacja) może mieć dostęp do poziomu jednostki obejmującej określony zbiór zasobów i/lub do poziomu zasobu np. pojedynczego sensora. Są to atrybuty systemu niezbędne dla realizacji koncepcji Internetu Rzeczy Literatura [1]. [2]. Bauer M. "Towards an Internet of Things: Requirements, Challenges and Initial Solutions", Second Workshop on Architectures, Services and Applications for the Next Generation Internet (WASA-NGI) June 29, 2010, Karlsruhe, Schloss Karlsruhe, NEC.pdf [3]. Bauge T. (Editor), "D.3.3 Components for End to End Networking, Management and Security and Accounting", SENSEI, Public Deliverable D.3.3, 2009, [4]. Carrez F. (Editor), "D.3.2 Reference Architecture. SENSEI, Public Deliverable D.3.2, 2009, [5]. "The SENSEI Real World Internet Architecture". Version 1.1, March SENSEI Architecture White paper. 47

48 Rysunek 7: Schemat platformy testowej zrealizowanej w ramach projektu SENSEI 2.12 Typy komunikacji sensor-sieć Niniejszy rozdział poświęcony będzie omówieniu trzech niezwykle istotnych technik wykorzystywanych w sieciach sensorowych (ZigBee, 6LoWPAN oraz Bluetooth). Każda z nich zostanie pokrótce scharakteryzowana, a ponadto przedyskutowany będzie sposób, w jaki sensory korzystające z tych technik łączą się siecią Internet i ZigBee IEEE [1] jest standardem zdefiniowanym przez IEEE (Institute of Electrical and Electronics Engineer) dla bezprzewodowych sieci osobistych (ang. PAN Personal Area Network) o niskich szybkościach transmisji. Określa on zarówno warstwę fizyczną PHY (Physical) jak i dostępu do medium MAC (Media Access Control). Wzorzec definiuje niskomocową transmisję radiową na roboczej częstotliwości 2,4 GHz z podstawową prędkością transmisji 250 kb/s. Istnieje także alternatywna specyfikacja PHY dopuszczająca pracę na częstotliwościach około 915 MHz i 868 MHz przy niższej szybkości transmisji danych. ZigBee Alliance, zarejestrowane w sierpniu 2002 roku, jest stowarzyszeniem firm pracujących nad umożliwieniem niezawodnego, ekonomicznego, energooszczędnego wykorzystania sieci bezprzewodowych na bazie otwartego globalnego standardu. Wiele instytutów badawczych i przedsiębiorstw przemysłowych opracowało platformy sensorowe oparte na rozwiązaniach ZigBee i IEEE ZigBee Alliance obejmuje wiodących producentów 48

49 półprzewodników, dostawców technologii, producentów OEM (Original Equipment Manufacturer) i użytkowników na całym świecie. Technologia ZigBee jest przystosowana do sensorów i aplikacji, które nie wymagają wysokich szybkości transmisji, ale muszą mieć niski pobór mocy i łatwość wykorzystania w platformie. Rys. 1. Warstwy zdefiniowane w specyfikacji ZigBee [3] Na podstawie rys. 1 można zauważyć, że ZigBee opiera się na standardzie IEEE Określenie warstw PHY i MAC w standardzie IEEE nie gwarantuje, że różne typy urządzeń będą w stanie się ze sobą komunikować. Było to pierwotną przyczyną prac nad ZigBee [2], które definiuje profile aplikacji umożliwiające komunikację urządzeniom wyprodukowanym przez różne firmy. Samo ZigBee jest więc rozszerzeniem standardu na o wyższe warstwy stosu protokolarnego Połączenie ZigBee z siecią IP Na chwilę obecną nie istnieje możliwość bezpośredniego podłączania urządzeń pracujących w technologii ZigBee do sieci wykorzystujących protokoły internetowe (IPv4, IPv6, TCP, UDP etc.). Format wiadomości przesyłanych w sieciach opartych o ZigBee, ani adresowanie nie są kompatybilne z sieciami Ethernet i połączenie z Internetem musi przebiegać za pośrednictwem bramy określanej w specyfikacji jako ZigBee Gateway [4]. Funkcjonowanie bramy przedstawiono na rysunku 2. Brama ZigBee zajmuje się pośredniczeniem pomiędzy siecią IP, a siecią ZigBee. Jej funkcjonowanie nie jest oparte na pojedynczym protokole, a raczej na udostępnieniu klientowi/serwerowi hosta IP swego rodzaju dwuwarstwowego API (Application Programming Interface) bazującego na protokole RPC (Remote Procedure Call). Jedną z warstw tworzą rozszerzenia obsługujące API RPC zarządzające samą bramą IP oraz elementami sieci ZigBee takimi jak Application Support Layer (APS), ZigBee Device Object (ZDO), oraz security services (SEC) wewnątrz i na zewnątrz sieci. Dodatkowo warstwa ta umożliwia interakcję pomiędzy aplikacjami internetowymi, a profilami aplikacji ZigBee przy wykorzystaniu standardowych metod np. POST. Na drugą warstwę składają się już ściśle zdefiniowane protokoły RPC mające zapewnić zewnętrzny dostęp do API. Komunikacja z bramą ZigBee i wystawianym przez nią API może przebiegać w trzech podstawowych wariantach: SOAP (Simple Object Access Protocol) czyli klasyczne przesyłanie odpowiednio sformatowanych danych w formacie XML i tunelowanie ich przy wykorzystaniu np. HTTP POST. REST (Representational State Transfer) bardziej złożona komunikacja oparta na zasadzie działania połączenia klient/serwer, generalnie zapewniająca pewną oszczędność w ilości przesyłanych danych względem SOAP [4]. GRIP (Gateway Remote Interface Protocol) transmisja binarna opierająca się na odpowiedniej enkapsulacji danych z sieci ZigBee w pakiety sieci IP. 49

50 RPC Serwer/Klient Sieć IP RPC Klient/Serwer Stos ZigBee Aplikacja Hosta Brama ZigBee Host IP Aplikacja ZigBee Stos ZigBee Węzeł końcowy ZigBee Rys. 2. Architektura połączenia pomiędzy węzłem ZigBee, a siecią IP [5] ZigBee Smart Energy 2.0 ZigBee Smart Energy [6] jest jednym z najbardziej aktywnie rozwijanych profili aplikacji. Podstawową rolą urządzeń ZigBee Smart Energy jest sterowanie miernikami energii i taryfikacja, jednak profil nie wyklucza innych zastosowań. Również w tym przypadku połączenie z siecią zewnętrzną odbywa się przez pośrednictwo bram, ale sam profil jest nakierowany głównie na zbieranie i sterowanie dużą ilością urządzeń poprzez zabezpieczone łącze internetowe, oraz rozważa wykorzystanie innych rozwiązań niż w warstwie fizycznej i transportowej. Oprócz tego ZigBee Smart Energy wspiera połączenia między poszczególnymi podsieciami niekoniecznie w technologii ZigBee (InterPAN Transmission Mechanism), ale wspierającymi Framework aplikacji ZigBee. Powyższe cechy sprawiają, że ten profil mógłby być przydatny dla koncepcji Internetu Rzeczy CAP Ze względu na rosnące znaczenie usług internetowych zauważono zapotrzebowanie na rozszerzenie możliwości ZigBee o współpracy z sieciami IP. W tym celu firma ArchRock zaproponowała protokół CAP (Compact Application Protocol), który miał te zadania realizować. Protokół został zgłoszony jako draft w IETF (Internet Engineering Task Force)[7]. CAP jest metodą odwzorowania informacji warstwy aplikacji ZigBee (ZAL ZigBee Application Layer) w datagramy protokołu UDP/IP [7]. Aby w ogóle było to możliwe warstwa aplikacji ZigBee musiała przejść kilka poważnych modyfikacji. Podstawową z nich było dodanie wsparcia dla adresacji IP w sieciach ZigBee. Warto zauważyć, że CAP nie jest metodą tunelowania IP w sieciach ZigBee, ani nie wymaga stosowania bram pośredniczących w transmisji pomiędzy sieciami obu typów. W założeniu każde podłączone do sieci urządzenie ZigBee zgodne z CAP będzie mogło być normalnie adresowane przy pomocy protokołu IP (Zarówno w wersji IPv4, jak i IPv6 ze wskazaniem raczej na to drugie rozwiązanie) i będzie wspierało transmisję danych opartą na protokole UDP. Rysunek 3. obrazuje przeniesienie profili aplikacji ZigBee w domenę protokołów UDP/IP. Takie rozwiązanie umożliwi nie tylko lepszą integrację sieci ZigBee z różnego rodzaju rozwiązaniami internetowymi, ale także umożliwi praktycznie bezpośrednią integrację 50

51 z wieloma innymi systemami takimi jak 6LoWPAN, HomePlug, czy WiFi. Porównanie pakietów klasycznego ZigBee i ZigBee z protokołem CAP przedstawiono na rysunku 4. Application Profiles Application Profiles Application Layer Security Application Layer Security Application Protocol Application Protocol NetworkProtocol Wireless Link ( ) ZigBee Protocol Stack IP Protocol Stack UDP/IP 6LoWPAN Ethernet WiFi WAN Rys. 3 Udostępnianie warstwy aplikacji ZigBee przy pomocy protokołu CAP [8] ZigBee Packet Link Network Application Security Profile Clusters MIC IP Packet Port e.g Link IP UDP Application Security Profile Clusters MIC. WiFi Link Ethernet Link Address e.g Rys 4. Porównanie pakietów ZigBee oraz ZigBee z protokołem CAP [8] Na rysunku 4 widać, że protokół CAP zmienia jedynie fragment odpowiedzialny za warstwę sieciową na zgodną IP i UDP, natomiast cały fragment warstwy aplikacji odwzorowany jest dokładnie tak samo jak w ZigBee. W praktyce oznacza to możliwość udostępnienia warstwy aplikacji ZigBee wszystkim urządzeniom zgodnym z IP i UDP, które będą potrzebowały z tego z korzystać Wnioski Przydatność technologii ZigBee w przypadku Internetu rzeczy opiera się na dość dużej popularności tego standardu w rozwiązaniach opartych o sieci sensorowe. ZigBee ze względu na brak kompatybilności z sieciami IP, oraz podobnymi rozwiązaniami (np. 6LoWPAN) może być integrowane z innymi rozwiązaniami IoT jedynie w ograniczonym stopniu poprzez warstwę aplikacji i APSDE-SAP (APSDE Service Access Point). Nie jest jednak wykluczone wykorzystanie podsieci urządzeń ZigBee, które mogą tworzyć swego rodzaju zamknięty Intranet Rzeczy (Intranet of Things) a następnie poprzez bramę być podłączone do 51

52 Internetu. W tym przypadku na szczególną uwagę zasługuje wspomniany wcześniej profil ZigBee Smart Energy Literatura [1] IEEE , Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs), 2006 [2] ZigBee Alliance, ZigBee standard specification, Dostępna pod adresem: [3] Mahalik N. P.: Sensor Networks and Configuration. Fundamentals, Standards, Platforms and Applications, Springer, 2007 [4] ZigBee Alliance, Understanding ZigBee Gateway: How ZigBee extends an IP network, Sep Dostępna pod adresem: [5] ZigBee Alliance, Understanding ZigBee Document r33 - Network Device: Gateway Specification, Mar Dostępna pod adresem: [6] ZigBee Alliance, ZigBee Smart Energy Profile Specification, Mar Dostępna pod adresem: [7] G. Tolle, A UDP/IP Adaptation of the ZigBee Application Protocol, IETF 2009 [8] William Grace, Compact Application Protocol, LoWPAN 6LoWPAN jest zbiorem standardów zdefiniowanych przez Internet Engineering Task Force (IETF). Najkrótsza definicja 6LoWPAN brzmi: standardy 6LoWPAN poprzez warstwę adaptacyjną oraz optymalizację odpowiednich protokołów umożliwiają efektywne korzystanie z protokołu IPv6 w sieciach bezprzewodowych o małej mocy i niskiej prędkości transmisji zbudowanych z urządzeń embedded [3]. W zdecydowanej większości sieci bezprzewodowe 6LoWPAN oparte są na warstwie łącza zgodnej ze standardem Architektura Architektura sieci 6LoWPAN przedstawiona jest na rys. 1. Zdefiniowano trzy różne typy sieci LoWPAN: prosta sieć LoWPAN, rozszerzona sieć LoWPAN i sieć ad hoc. Sieć LoWPAN jest zbiorem węzłów 6LoWPAN o jednakowym prefixie adresu IPv6 (najbardziej znaczące 64 bity adresu). Oznacza to, że niezależnie od aktualnej pozycji węzła w sieci jego adres pozostaje niezmieniony [3]. Sieć typu ad hoc nie jest połączona z Internetem, sieć prosta połączona jest z innymi sieciami IP poprzez edge router (ER), zaś sieć rozszerzona połączona jest z Internetem poprzez kilka ER o tym samym prefixie połączonych to tego samego backbone link. Edge router pełni w sieci bardzo ważną rolę. Kieruje on ruchem do i z sieci, wykonuje kompresję nagłówków, definiuje IPv6 prefix dla wszystkich węzłów sieci oraz dostarcza usługi Neighbour Discovery. Jeśli sieć LoWPAN połączona jest z siecią IPv4 ER dostarcza funkcjonalności do realizacji takiego połączenia. Węzeł sieci LoWPAN może pełnić rolę hosta lub routera. Każdy węzeł sieci LoWPAN musi się zarejestrować w ER. Jest to część mechanizmu Neighbor Discovery Adresowanie Sposób tworzenia adresu IPv6 dla węzła sieci LoWPAN pokazano na rys. 2. Adres budowany jest z: - prefixu (64 najbardziej znaczące bity adresu) sieci dostarczonego przez edge router, - 64-bitowego adresu MAC zdefiniowanego w standardzie z tym, że pierwsze 16 52

53 bitów adresu MAC jest poddane operacji XOR z 0x0200. Dodatkowo węzeł może otrzymać od ER adres 16-bitowy, który może być używany jako 16- bitowy adres w warstwie łącza zdefiniowany w Dzięki temu możliwa jest kompresja 128-bitowego adresu IPv6 do adresu 16-bitowego wewnątrz sieci LoWPAN. Rys. 1. Architektura sieci 6LoWPAN [3] Rys. 2. Budowanie adresu IPv6 z prefixu sieci i adresu MAC węzła. UOI identyfikator producenta transceivera 53

54 Przesyłanie pakietów (forwarding, routing) Forwarding pakietów może odbywać się w warstwie łącza (L2 forwarding Mesh-Under ) zaś routing odbywa się w warstwie IP (L3 routing Route-Over ) [3]. Aby możliwe było przekazywanie pakietów w warstwie łącza 6LoWPAN definiuje mesh header [rys. 3], czyli specjalny nagłówek zawierający adresy nadawcy i odbiorcy dodawany do nagłówka 6LoWPAN. Rys. 3. Nagłówek mesh header. Górny dla wiadomość o max. 14 skokach, dolny dla wiadomości o skokach powyżej 14 [3] Kompresja nagłówków Architektura 6LoWPAN działa w sieciach zgodnych z , gdzie długość ramki wynosi 127 bajtów, przez co pełen nagłówek IPv6 zajmowałby prawie połowę jej długości. W standardzie 6LoWPAN dąży się do tego, aby przesyłany pakiet mieścił się w jednej ramce , a jeśli nie jest to możliwe stosowana jest technika fragmentacji wiadomości. W 6LoWPAN stosuje się kompresję nagłówka IPv6, aby jak najwięcej miejsca pozostało dla danych w ramce Zdefiniowano dwie metody kompresji nagłówków [2]: - Stateless header compression, - Context-based header compression. Dzięki kompresji nagłówek IPv6 o długości 48 bajtów (rys. 4) może zostać skrócony do nagłówka 6LoWPAN o długości 6 bajtów (rys. 5). Dzięki temu w ramce o długości 127 bajtów na dane do dyspozycji zostaje 108 bajtów zamiast 53 (rys. 6). Rys. 4. Pełen nagłówek IPv6/UDP (48 bajtów) [3] 54

55 Rys. 5. Skompresowany nagłówek 6LoWPAN/UDP (6 bytes) [3] Rys. 6 Przykład kompresji nagłówka 6LoWPAN (L = nagłówek LoWPAN) Komunikacja między węzłami LoWPAN i węzłami IP innych sieci odbywa się w sposób endto-end, jak między normalnymi węzłami sieci IP. Każdy węzeł LoWPAN jest identyfikowany poprzez unikalny adres IPv6 i może wysyłać i odbierać pakiety IPv6. Standardowo węzły LoWPAN wspierają ruch ICMPv6 jako ping i jako protokołu transportowego używają UDP [3] Software Najprostszą metodą [3] uruchomienia 6LoWPAN na urządzeniu wbudowanym jest integracja z aplikacją istniejącego stosu protokołów np. na procesorze sieciowym (network processor), użycie stosu wbudowanego w system operacyjny lub dołączenie stosu protokołów do aplikacji embedded. Standardowo stos protokołów 6LoWPAN zawiera co najmniej: - drivery układu radiowego, - obsługę warstwy MAC ( ), - IPv6 z 6LoWPAN, - UDP, - ICMPv6, - Neighbor Discovery, - API do obsługi stosu (np. obsługa socket'ów). Dodatkowo stos może zawierać protokoły routingu, TCP lub inne protokoły wbudowane w aplikacje. Popularnymi stosami 6LoWPAN na licencji open-source są: - uipv6 dla systemu operacyjnego Contiki, - BLIP dla systemu TinyOS. Zaś rozwiązania komercyjne to: - Sensinode NanoStack, 55

56 - Jennic 6LoWPAN, - Nivis ISA Wnioski Standard 6LoWPAN wydaje się być idealnym rozwiązaniem pośredniczącym przy podłączaniu do Internetu sieci urządzeń o niskim poborze mocy (sieci sensorowe, sieci LoWPAN itp.). Wspiera protokoły internetowe, korzysta z nowoczesnego IPv6, umożliwia połączenia end-to-end z innymi węzłami sieci IP, a wszystkie te zalety dzięki kompresji nagłówków daje się pogodzić z niewielkim rozmiarem pakietu w sieciach Dodatkowo 6LoWPAN wspiera szyfrowanie AES co w przypadku zastosowania w aplikacjach Internetu Rzeczy jest nie bez znaczenia. Powyższe cechy sprawiają, że w dużej liczbie projektów krążących wokół tematyki IoT (Sensinode, Sensei, OGC SWE, ITU-T USN itp.) właśnie 6LoWPAN jest wybieraną/rekomendowaną metodą bezprzewodowego podłączania urządzeń [5]. Można uznać, że 6LoWPAN jest jedną z kluczowych technologii wykorzystywanych w IoT. Podczas prac nad architekturą IoT (IoT-A) zaproponowano, aby w rozwiązaniach IoT stosować właśnie 6LoWPAN lub w przypadku gdy potrzeba rozwiązań funkcjonujących bardziej dynamicznie sieci urządzeń ZigBee podłączonych do Internetu przez bramę [5] Literatura [1] How-to setup a 6LoWPAN network, Axel Vidales, [2] Transmission of IPv6 Packets over IEEE Networks, [3] 6LoWPAN: The Wireless Embedded Internet, Zach Shelby, Carsten Bormann, Wiley 2009 [4] IP Version 6 Addressing Architecture, [5] Internet of Things Architecture, IoT-A, Project Deliverable D1.1 - SOTA report on existing integration frameworks/architectures for WSN, RFID and other emerging IoT related Technologies, Bluetooth Standard Bluetooth, powstały 26 czerwca 1999 (data opublikowania przez Bluetooth Special Interest Group specyfikacji Bluetooth 1.0) jest technologią bezprzewodowej komunikacji krótkiego zasięgu (teoretycznie do 100 metrów) pomiędzy różnymi urządzeniami elektronicznymi, takimi jak komputer, telefon komórkowy, klawiatura, palmtop, drukarka itp. Jest to otwarty standard opisany w specyfikacji IEEE Jego specyfikacja obejmuje trzy klasy mocy nadawczej 1-3 o zasięgu 100, 10 oraz 1 metra w otwartej przestrzeni, przy zastosowaniu odpowiednio mocy 100 mw, 2,5 mw oraz 1 mw. Najczęściej spotykaną klasą jest klasa druga. Głównym przeznaczeniem Bluetooth jest zapewnienie łączności w sieciach PAN (Personal Area Network) w celu zastąpienia istniejących połączeń kablowych. Standard Bluetooth został zaprojektowany z myślą do realizacji głównie połączeń punktpunkt oraz tworzenia pikosieci. Pikosieci mogą składać się z maksymalnie siedmiu aktywnych węzłów pracujących w trybie podrzędnym (slave) oraz jednego węzła pracującego w trybie nadrzędnym (master) zapewniając synchronizację urządzeń pracujących w trybie podrzędnym. Ponadto standard Bluetooth zapewnia możliwość stworzenia pikosieci zawierającej do 254 modułów BT jednak tylko 7 z nich znajduje się w trybie aktywnym, a pozostałe w trybie oczekiwania - nie uczestnicząc tym samym w wymianie danych wewnątrz danej pikosieci. W momencie, gdy zajdą odpowiednie warunki moduł aktywny może przejść do trybu oczekiwania a moduł oczekujący może w tym czasie przystąpić do wymiany danych. 56

57 Warto mieć na uwadze fakt, że moduł nadrzędny jest odpowiedzialny za nadzór nad dostępem do kanałów fizycznych zarówno dla aktywnych, jak i dla oczekujących (idle) modułów podrzędnych. Więcej informacji można znaleźć w specyfikacji technicznej systemu [1]. Warstwa radiowa odpowiedzialna jest za transport danych od urządzenia master do slave i vice versa. Jest to system o małym poborze mocy, działający w zależności od klasy na różnych zasięgach, operujący w paśmie ISM (ISM Industrial, Scientific and Medical) 2,4 GHz. Pasmo jest podzielone na 79 kanałów, po 1 MHz każdy. System wykorzystuje modulacje FSK (Frequency Shift Keying). Systemy oraz Bluetooth operują na tych samych częstotliwościach z takim samym podziałem pasma na 79 kanałów. Z tego powodu zakłócają się wzajemnie. Ponieważ skoki częstotliwości są znacznie szybsze w systemie Bluetooth, jest znacznie bardziej prawdopodobne, że system ten będzie zakłócał transmisje w Profile pracy sieciowej W systemie Bluetooth wyróżniono dwa profile pracy sieciowej: profil pracy sieciowej z połączeniem komutowanym (ang. Dial-Up Networking Profile DUNP), profil dostępu do LAN (ang. LAN Access Profile LAP). Oba profile zawierają elementy pozwalające na dostęp do sieci WAN w celu wymiany danych. W procesie komunikacji urządzenie Bluetooth stanowi bramę do sieci WAN. Profil pracy sieciowej z połączeniem komutowanym oraz profil dostępu do LAN tworzą wspólnie model mostu internetowego Profil pracy sieciowej z połączeniem komutowanym Profil DUNP odnosi się do dwóch rodzajów urządzeń komputerów i telefonów. Telefon łącząc się z siecią umożliwia urządzeniom komputerowym korzystanie z powstałego łącza, a zatem pozwala im na dostęp do sieci transmisji danych. Praca sieciowa z połączeniem komutowanym zakłada użycie telefonu komórkowego (bądź modemu GSM/UMTS) wyposażonego w moduł Bluetooth jako modemu transmisji danych. Komputer korzysta z usługi modemowej telefonu oraz oprogramowania wybierania numeru w celu połączenia z punktem dostępowym sieci, przyłączonym do sieci telefonicznej, która oferuje dostęp do sieci transmisji danych, takiej jak Internet. W profilu DUNP wprowadzono ideę punktów dostępowych dla danych i podzielono je na dwa typy [2]: dostęp do sieci WAN przy użyciu modemów, łączy satelitarnych, sieci telefonii komórkowej itp. dostęp do sieci LAN z zastosowaniem punktów dostępowych przeznaczonych do bezpośredniego przyłączania się do sieci Ethernet, token-ring itp. Profil DUNP rozróżnia rolę urządzeń na bramy i terminale danych. Brama jest urządzeniem, które udostępnia usługę modemową i umożliwia łączenie z daną siecią. Bramy z reguły są telefonami komórkowymi lub modemami, ale bramą może też być bezprzewodowy modemowy punkt dostępowy przyłączany do przewodowej sieci telefonicznej. Terminale danych są urządzeniami, z reguły komputerowymi, które korzystają z oferowanej przez bramę usługi modemowej w celu przyłączenia się do sieci transmisji danych. 57

58 Do przesyłania komend AT pomiędzy terminalem danych (komputerem) a bramą (telefonem lub modemem) stosowany jest protokół RFCOMM 5. Komendy AT pozwalają na ustanawianie i zarządzanie połączeniami z siecią. DUNP uwzględnia również opcję generowania zwrotnego sygnału akustycznego. Mimo, iż jego zasadniczym przeznaczeniem jest obsługa połączeń transmisji danych. Jeżeli ta opcja jest obsługiwana dostarczają one użytkownikowi informacji o zaawansowaniu procesu łączenia w postaci sygnału akustycznego znanego z pierwszych modemów telefonicznych. Typowe czynności DUNP przedstawiono na rysunku 1. Przeznaczeniem DUNP jest umożliwienie dotychczasowym aplikacjom skorzystania z bezprzewodowych łączy Bluetooth. Po ustanowieniu połączenia z siecią przez oprogramowanie zestawiania połączenia, nowo powstałe łącze może być wykorzystywane przez niezliczoną ilość standardowych protokołów sieciowych (jak TCP/IP, http, FTP itp.) współpracujących z odpowiednimi usługami sieciowymi. DUNP pozwala więc na korzystanie z innych aplikacji, takich jak przeglądarka internetowa, klient poczty elektronicznej itp. Połączenie komórkowe Internet Terminal danych Komendy AT w protokole RFCOMM Transmisja danych ACL Brama Akustyczne sprzężenie zwrotne SCO (opcjonalnie) Rys. 1.Czynności profilu pracy sieciowej z połączeniem komutowanym [2] Profil dostępu do LAN Profil LAP jest drugim, profilem, który urzeczywistnia model mostu internetowego. Podobnie jak DUNP, umożliwiając urządzeniom komputerowym uzyskanie dostępu do sieci transmisji danych, opiera się na znanych protokołach we współpracy z bezprzewodowymi łączami Bluetooth. W przypadku LAP zamiast używanych w połączeniach komutowanych telefonów i modemów, przyłącze do sieci bazuje na sieciowym punkcie dostępowym dla danych. Profil LAP, w przeciwieństwie do DUNP, dotyczy dostępu do sieci lokalnej, a nie rozległej. Najczęściej wymienianym przez LAP modelem zastosowań jest przykład komputera przyłączanego do sieci LAN. LAP koncentruje się na szczególnym przypadku bezpośredniego łączenia dwóch urządzeń w protokole PPP (Point-to-Point Protocol), a nie na dostępie do większej sieci. Pierwotnym zadaniem zespołu problemowego ds. pracy sieciowej, zajmującego się profilem LAP, było opracowanie metod tradycyjnej pracy sieciowej z protokołem IP w ramach środowiska Bluetooth. Skoncentrowano się nad opracowaniem dostępu do LAN na bazie protokołu PPP, z dwóch powodów: PPP jest powszechnie używanym standardem internetowym, rozwiązującym problem konfiguracji hosta i przygotowania go do komunikacji IP, wiele używanych obecnie urządzeń, w tym popularne PDA, obsługuje komunikację IP poprzez PPP w komutowanym dostępie do sieci IP. 5 RFCOMM protokół emulacji portu szeregowego: umożliwia aplikacjom korzystającym z portu szeregowego, na bezproblemowe komunikowanie się poprzez połączenia Bluetooth. RFCOMM z punktu widzenia aplikacji stanowi wirtualny port szeregowy [3]. 58

59 LAP definiuje dwa rodzaje urządzeń punkt dostępowy LAN oraz terminal danych. Punkt dostępowy LAN jest urządzeniem wyposażonym w funkcje serwera PPP i przyłączonym do sieci LAN, którą może być Ethernet, token-ring, lub sieć LAN innego typu. Terminal danych jest klientem punktu dostępowego dla danych. Oznacza to, że jest wyposażony w funkcje klienta PPP, które pozwalają na zestawianie połączeń z punktem dostępowym dla danych, umożliwiającym z kolei dostęp do LAN. Protokół PPP jest kluczowym elementem LAP. PPP doskonale nadaje się do komunikacji pomiędzy punktem dostępowym dla danych i terminalem danych. W budowanych na jego bazie łączach bez problemu można przenosić ruch sieci IP. Poza tym PPP zaprojektowano z myślą o połączeniach szeregowych, dzięki czemu w LAP może on funkcjonować na bazie RFCOMM. Typowe czynności LAP w przypadku pojedynczego terminala danych przedstawiono na rysunku 2. Należy pamiętać, że o ile dopuszcza to punkt dostępowy dla danych, możliwa jest jednoczesna obsługa wielu terminali danych (w takiej sytuacji każdy z nich posiada własny, oddzielny mechanizm transportu Bluetooth oraz połączenie PPP z punktem dostępowym dla danych, a ponadto punkt dostępowy musi być równocześnie jednostką master pikosieci) [2]. LAN Terminal danych Zestawienie połączenia PPP z wykorzystaniem RFCOMM Dane IP Punkt dostępowy dla danych Rys. 2. Typowe czynności profilu dostępu do sieci LAN (punkty dostępowe dla danych mogą opcjonalnie obsługiwać większą liczbę terminali) [2]. Podobnie jak w przypadku DUNP, przeznaczeniem LAP jest udostępnianie sieci, przede wszystkim sieci IP. O ile zatem urządzenie LAP wyposażone jest w warstwę pośredniczącą PPP wraz z wymaganym stosem IP, można go użyć w tych samych aplikacjach, które wymieniono przy DUNP (przeglądarki, klient poczty elektronicznej oraz FTP itp.). Stos protokołów sieciowych IP oraz aplikacje z niego korzystające spotykane są w wielu urządzeniach. Definiowane przez LAP łącze PPP pozwala dotychczasowym aplikacjom na pracę w środowisku bezprzewodowej komunikacji Bluetooth Porównanie DUNP i LAP Zasady udostępniania usług opartych na protokole IP w DUNP i LAP są podobne. Ostatecznym celem każdego z profili jest umożliwienie zestawienia połączenia pomiędzy klientem PPP terminala danych i serwerem PPP umieszczonym na styku z siecią IP. Zasadnicza różnica pomiędzy nimi wynika z roli, jaką w całym procesie odgrywają łącza Bluetooth. Różnice i podobieństwa w obsłudze komunikacji IP zilustrowano na rysunkach 3 i 4. Przedstawiają one typowy stos protokołów używany w każdym z profili. W przypadku DUNP rolą łącza Bluetooth jest zastępowanie kabla szeregowej transmisji danych pomiędzy terminalem danych a bramą, wyposażoną w usługę modemową. W przypadku LAP nie ma potrzeby angażowania w proces modemów, natomiast łącze Bluetooth zastępuje bezpośrednie 59

60 połączenie szeregowe pomiędzy klientem PPP terminala danych i serwerem PPP, umieszczonym w punkcie dostępowym dla danych. Poza przedstawioną różnicą w sposobie wykorzystania łącza Bluetooth, komunikacja IP przy użyciu DUNP i LAP może w obu przypadkach opierać się na tych samych procedurach i aplikacjach. Mimo, iż oba profile pracują z podobnymi aplikacjami, warto przyjrzeć się jednemu modelowi zastosowań, który rozróżnia LAP i DUNP pod względem mobilności. W typowym przypadku funkcjonowania DUNP, łącze Bluetooth występuje pomiędzy komputerem a telefonem, tymczasem połączenie z siecią realizowane jest przy użyciu połączenia telefonicznego w sieci komórkowej. Ponieważ sieci komórkowe stosują technikę przełączania podczas przemieszczania się telefonu pomiędzy komórkami, utrzymanie połączenia sieciowego jest możliwe nawet w przypadku, gdy użytkownik jest w ruchu, o ile oczywiście komputer i telefon pozostają w dostatecznej bliskości (co z reguły ma miejsce, gdyż są to urządzenia osobiste przemieszczające się wraz z użytkownikiem). W przypadku LAP natomiast, łącze Bluetooth pełni rolę przyłącza sieciowego. Utrzymanie połączenia sieciowego możliwe jest więc tak długo, jak długo użytkownik pozostaje w pobliżu jednego punktu dostępowego dla danych. Aplikacja wybierania połączenia Aplikacje IP Intranet/Internet TCP/UDP IP IP PPP sieć telefoniczna PPP Sterownik modemu modem modem Interfejs szeregowy RFCOMM RFCOMM Protokoły transportowe Bluetooth Terminal danych Brama Rys. 3. Wykorzystanie łącza Bluetooth w profilu pracy sieciowej z połączeniem komutowanym (DUNP) [2] Wnioski Bluetooth nie jest technologią, która korzystałaby z protokołów internetowych bezpośrednio i wymaga zawsze jakiegoś urządzenia pośredniczącego, więc jego przydatność w kontekście Internetu Rzeczy jest ograniczona. Ze względu na bardzo dużą popularność, zwłaszcza w przypadku telefonów komórkowych, może być wykorzystana do podłączania różnych urządzeń poprzez LAP lub DUNP i wymiany danych kiedy inne możliwości będą niedostępne. Mimo tego w obliczu rosnącego trendu na wyposażanie większości nowych modeli telefonów w nadajniki WiFi przydatność Bluetooth akurat w tym kontekście będzie spadać. Dodatkowo bardzo ograniczone możliwości tworzenia podsieci (pikosieci realnie posiadające maksymalnie 7 równocześnie czynnych urządzeń), nie będących przy tym zgodnych z popularnymi protokołami internetowymi, również istotnie ograniczają ewentualną przydatność Bluetooth dla IoT. 60

61 Aplikacja wybierania połączenia Aplikacje IP Intranet/Internet TCP/UDP IP IP PPP PPP RFCOMM RFCOMM Protokoły transportowe Bluetooth Terminal danych Punkt dostępowy dla danych Rys. 4. Wykorzystanie łącza Bluetooth w profilu dostępu do LAN (LAP) [2] Literatura [1] Bluetooth Special Interest Group, Bluetooth Core, Specification of the Bluetooth System, Version 4.0, 30 June 2010 [2] Miller B. A., Bisdikian C.: Bluetooth. Uwolnij się od kabli, Helion 2003 [3] Bluetooth Special Interest Group, RFCOMM with TS 07.10, Serial Port Emulation, Bluetooth Specification Version 1.1, 5 June Podsumowanie W rozdziale zaprezentowano przegląd projektów badawczych i prac standaryzacyjnych dotyczących wypracowania architektury dla Internetu Rzeczy. Mimo iż proponowane w poszczególnych projektach rozwiązania posiadają wiele cech wspólnych, to niestety brak jest obecnie jednolitej wizji architektury dla IoT. Przez wzgląd na duży poziom ogólności, a tym samym możliwość dopasowania do różnorodnych scenariuszy zastosowania, najbardziej optymalnym wydaje się być model opracowywany w ramach flagowego projektu 7PR IoT-A. Na podstawie przeprowadzonych prac możemy wyodrębnić zbiór zaleceń i wymagań dla architektury Internetu Rzeczy, zaprezentowany poniżej: Wprowadzenie do modelu warstwowego nowej warstwy odpowiedzialnej za jednoznaczną identyfikację obiektów IoT i usług przez nie oferowanych, zapewnienie separacji pomiędzy identyfikacją a lokalizacją obiektów Możliwość uzyskania przez aplikację informacji o obiektach i usługach IoT dostępnych w sieci w sposób automatyczny (konieczność wprowadzenia mechanizów rejestracji i wyszukiwania) Automatyczna konfiguracja sieci, samozarządzanie Przez wzgląd na oszczędność energii obiektów IoT dopuszcza się ich czasową niedostępność, a zatem sieć powinna posiadać cechy sieci DTN (ang. Delay 61

62 Tolerant Network) dla zapewnienia możliwości komunikacji z urządzeniami będącymi w trybie uśpienia; Wsparcie dla różnych trybów komunikacji: unicast, multicast, anycast Zapewnienie możliwości komunikacji z urządzeniami dołączonymi do bramy (ang. gateway) spoza sieci lokalnej Skalowalność 62

63 3 Wypracowanie koncepcji sieci testowej IoT w IŁ Autorzy: dr inż. Krzysztof Bronk (Z-8) dr inż. Rafał Niski (Z-8) dr inż. Jerzy Żurek (Z-8) mgr inż. Adam Lipka (Z-8) mgr inż. Błażej Wereszko (Z-8) mgr inż. Piotr Wojnicz (Z-8) mgr inż. Krzysztof Żurek (Z-8) 3.1 Wprowadzenie Celem niniejszej pracy statutowej jest opracowanie koncepcji sieci sensorowej spełniającej założenia i realizującej wybrane zadania technologii Internetu Rzeczy. Projektowana sieć musi charakteryzować się następującymi cechami: dążyć do minimalizacji zużywanej przez węzły energii przy zachowaniu połączeniowości, aktywnie zmieniać swoją konfigurację w zależności od liczby węzłów i parametrów transmisji, być zdalnie konfigurowalna i skalowalna, służyć do monitorowania warunków środowiskowych na dużym obszarze, na którym rozmieszczone są węzły sieci. Powyższe cele proponuje się osiągnąć poprzez: samoorganizację sieci, tj. węzły poszukują ustalonej liczby sąsiadów przy zadanej jakości łącza radiowego i minimalnej energii nadajnika, przesyłanie parametrów konfiguracji sieci w komendzie żądania danych, zastosowanie architektury MASTER-SLAVE, w której jeden węzeł nadrzędny (MASTER) żąda danych, zaś pozostałe (SLAVE) przesyłają do niego własne dane pomiarowe. W kolejnych rozdziałach zostanie szczegółowo omówiona platforma sprzętowa proponowanej sieci, sposób przekazywania danych przez sieć oraz sposób samoorganizacji. Zostaną też przedstawione problemy jakie pojawiły się w trakcie testowania opisywanej sieci. Zaprezentowany zostanie także zakres zrealizowanych podczas budowy sieci zadań oraz przykładowe wyniki przeprowadzonych testów. W końcowej części niniejszej pracy przedstawione zostaną również potencjalne aplikacje zaproponowanej platformy, koncepcja jej integracji z siecią opartą o standard 6LoWPAN oraz krótkie podsumowanie. 3.2 Platforma sprzętowa W niniejszym rozdziale opisano szczegółowo komponenty proponowane do wykorzystania podczas budowy sieci. Elementy te przedstawiono na Rysunek

64 programator moduł radiowy Kabel RS-232 Rysunek 3.1 Zestaw do budowy demonstratora sieci. W skład zestawu sprzętowego wchodzą następujące elementy: 10 modułów radiowych RCB128RFA1, RCB Breakout Board 2 kable RS-232 służące do transmisji danych między modułem radiowym a komputerem, 2 płytki RCB Breakout Board Light do podłączenia programatora i kabla RS-232. Płytka ta nie będzie używana podczas dalszych prac, gdyż węzeł MASTER zostanie podłączony do komputera poprzez konwerter RS-232 USB, programator JTAG mkii przeznaczony do programowania procesorów i debugowania programów. W kolejnych podrozdziałach przedstawiono poszczególne składniki opisywanego zestawu Moduł radiowy RCB128RFA1 W projekcie planuje się wykorzystać moduł radiowy RCB128RFA1 firmy Dresden Electronic. Został on pokazany na Rysunek 3.2 z uwzględnieniem jego części składowych. Moduł radiowy RCB128RFA1 wyposażony jest w: procesor Atmega128RFA1 taktowany zegarem 16 MHz, dodatkową, zewnętrzną pamięć EEPROM zawierającą adres MAC, numer seryjny, dane identyfikujące płytkę, dane do kalibracji kwarcu, zasilanie z 2 baterii AAA 1,5 V, 3 diody LED, 1 przycisk, złącze SMA anteny, kwarc 16 MHz i 32 khz, 64

65 dwa 30-pinowe złącza z wyprowadzeniami pinów procesora. wyprowadzenie pinów procesora złącze SMA procesor dodatkowa pamięć EEPROM Rysunek 3.2 Moduł radiowy RCB128RFA1. Moduł ma wymiary 52,4 mm x 45,4 mm. Schemat blokowy modułu zawierający wymienione powyżej elementy pokazano na Rysunek 3.3 [6]. Rysunek 3.3 Schemat blokowy modułu RCB128RFA1 [6]. W Tabela 3.1 zestawiono katalogowe parametry pracy omawianego modułu. Tabela 3.1 Parametry pracy modułu RCB128RFA1 [6]. L.p. Opis Wartość Jednostka 1 Zasilanie 1,8 do 3,0 V 2 Napięcie I/O 0,3 do 3,0 V 3 Napięcie analogowe I/O 0,3 do 2,0 V 4 Max prąd baterii 0,5 A 5 Max poziom wejściowego sygnału RF 14 dbm 65

66 6 Temperatura pracy 20 do +70 C 7 Częstotliwość radiowa 2400 do 2483,5 MHz Wybrany moduł radiowy pracuje w nielicencjonowanym paśmie częstotliwości 2,4 GHz (pasmo ISM). Ponadto moduł zasilany jest napięciem 1,8V 3,6V, co umożliwia zastosowanie 2 baterii typu AAA Moduł RCB Breakout Board Light W początkowej fazie prac, czyli do chwili, kiedy wykonane zostaną moduły z czujnikami, do programowania oraz do podłączenia węzła MASTER z komputerem należy stosować płytkę RCB Breakout Board Light. Na Rysunek 3.4 pokazano podłączenie modułu radiowego poprzez Breakout Board Light z komputerem PC (kabel RS-232) i programatorem debugerem (JTAG). JTAG Kabel RS232 Rysunek 3.4 RCB Breakout Board Light Moduł czujników Węzeł budowanej sieci składa się z modułu radiowego, a także płytki z zamontowanymi czujnikami (temperatury, przyspieszenia oraz odbiornika GPS), które zostały przedstawione na Rysunek 3.5. W Tabela 3.2 przedstawiono elementy składowe modułu czujników. Poza czujnikami temperatury, przyspieszeń i GPS moduł wyposażony jest w procesor ATmega8 [12], złącza do programowania procesorów, gniazdo do podłączenia dodatkowych czujników oraz przełącznik do ustawienia adresu podłączonego czujnika. 66

67 mikrokontroler I2C akcelerometry GPS moduł radiowy ISP JTAG adresy I2C termometr Rysunek 3.5 Węzeł sieci z modułem czujników. Tabela 3.2 Wyposażenie modułu czujników. L. p. Element Opis Akcelerometr AIS226D [8] Termometr TC77 [9] GPS-FGPMMOPA4 chipset MTK 3318 [10] Mikrokontroler AVR ATmega8 5 JTAG Pomiar przyspieszenia w 2 kierunkach zakres pomiarowy +/ 6g, 16 bitów, czułość 5461 LSB/g interfejs SPI Pomiar temperatury zakres pomiarowy 40 C do +85 C, dokładność +/ 2 C, interfejs SPI 3-wire Odczyt danych GPS zgodnie ze standardem NMEA [26] interfejs UART Procesor zbierający i formatujący dane z czujników Złącze JTAG do programowania i debugowania procesora radiowego 6 ISP Złącze do programowania procesora ATmega8 7 Zasilanie Zasilanie 3,3V z 3 baterii AAA 1,2V 8 Złącze I2C Podłączenie dodatkowych czujników do interfejsu I2C 9 Adresy I2C Przełącznik ON/OFF ustawiany na ON dla danego adresu gdy do interfejsu I2C dołączono dodatkowy czujnik o adresie z zakresu od 0x02 do 0x05 Rysunek 3.6 przedstawia schemat blokowy połączeń czujników z modułem radiowym. 67

68 Rysunek 3.6 Połączenie modułu radiowego i czujników zewnętrznych. Czujniki modułu komunikują się z procesorem ATmega8, który transmituje dane (po ich odpowiednim sformatowaniu) do modułu radiowego poprzez interfejs I2C. Procesorowi ATmega8 przypisano stały adres na magistrali I2C o wartości 0x01. Możliwe jest również dołączenie do magistrali I2C maksymalnie 4 dodatkowych czujników; przewidziano dla nich adresy od 0x02 do 0x05. Czujniki te muszą przesyłać dane w formacie 32-bitowej liczby ze znakiem Układ ATmega128RFA1 Zgodnie z przyjętą koncepcją, sercem modułu radiowego będzie układ ATmega128RFA1 [4], w którym w jednej obudowie zintegrowano procesor ATmega128 i transceiver AT86RF231. Jest to produkt wprowadzony na rynek przez firmę Atmel w 2010 roku. Jest on dedykowany dla sieci sensorowych zgodnych z [3], w tym dla sieci ZigBee [14]. ATmega128 to 8-bitowy procesor AVR RISC pracujący z max. prędkością 16 MHz, posiada 128kB pamięci flash programu oraz 16kB pamięci SRAM, dodatkowo wyposażony jest w 4kB pamięci EEPROM, interfejsy cyfrowe: I2C, USART, SPI, 10-bitowe przetworniki A/D, wewnętrzny czujnik temperatury, watchdog oraz liczniki 8- i 16-bitowe Transceiver AT86RF231 Transceiver ten jest integralną częścią wykorzystywanego modułu ATmega128RFA1. Poniżej wymieniono główne katalogowe parametry transceivera AT86RF231 [7]: pasmo radiowe: 2,4 GHz, czułość odbiornika: 100 dbm, programowana moc nadajnika ustawiana na następujących poziomach: 16,5; 11,5; 8,5; 6,5; 4,5; 3,5; 2,5; 1,5; 0,5; 0,5; 1,2; 1,8; 2,3; 2,8; 3,3; 3,5 dbm, zużycie prądu podczas transmisji 14,5 ma, podczas odbioru 12,5 ma, w stanie czuwania (TRX_OFF) 0,4 ma, 128 B bufor w pamięci SRAM na dane odbierane/wysyłane, hardwarowe wspomaganie standardu , 68

69 automatyczne wysyłanie ACK, CSMA-CA z ponownym wysyłaniem danych, filtrowanie adresów, obliczanie sum kontrolnych CRC-16, pomiar jakości połączenia (LQI Link Quality Indicator), wykrywanie początku ramki (SFR-detection), 32-bitowy licznik symboli, szyfrowanie AES 128, 2-bitowy generator liczb losowych, szybkość transmisji 250 kb/s, 500 kb/s, 1 Mb/s oraz 2 Mb/s, zgodny z IEEE Producent definiuje dwa tryby pracy transceivera [7]: Tryb bazowy (Basic Operating Mode), który dostarcza funkcjonalności na poziomie wysyłania i odbierania ramek danych. Tryb rozszerzony (Extended Operating Mode), w którym: o automatycznie wysyłane są ramki ACK, jeśli odebrana ramka żądała ACK (tryb RX_AACK), o podczas wysyłania ramki: w sposób automatyczny stosowany jest algorytm CSMA-CA dostępu do kanału radiowego zgodnie z konfiguracją ustawioną w rejestrach konfiguracyjnych, obliczana jest suma kontrolna, zakończenie transmisji sygnalizowane jest po otrzymaniu ACK jeśli takie było żądanie (tryb TX_ARET). Oprogramowanie omawianej sieci sensorowej korzysta z trybu rozszerzonego transceivera Interfejs procesor transceiver Zintegrowanie w jednej obudowie procesora i transceivera pozwoliło na włączenie rejestrów transceivera i bufora danych do przestrzeni adresowej procesora. Dzięki temu odczyt 128 bajtów z bufora odbiorczego transceivera odbywa się w ciągu zaledwie 16 µs przy taktowaniu procesora 16 MHz. Dla porównania w przypadku transceivera zewnętrznego komunikującego się z procesorem poprzez interfejs SPI z maksymalną prędkością 8 MHz operacja ta wymaga 128 µs. W tabeli przerwań procesora przewidziano 15 przerwań wywoływanych przez zdarzenia transceivera (Tabela 3.3). Vector No. Program Address Tabela 3.3 Przerwania transceivera [7]. Source 57 $0072 TRX24_PLL_LOCK Transceiver PLL Lock Interrupt Definition 69

70 58 $0074 TRX24_PLL_UNLOCK Transceiver PLL Unlock 59 $0076 TRX24_RX_START TransceiverReceive Start 60 $0078 TRX24_RX_END TransceiverReceive End 61 $007A TRX24_CCA_ED_DONE Transceiver CCAED Meassurement Finished 62 $007C TRX24_XAH_AMI TransceiverFrameAddressMatch 63 $007E TRX24_TX_END TransceiverTransmit End 64 $0080 TRX24_AWAKE TransceiverWakeupfinished 65 $0082 SCNT_CMP1 Symbol CounterCompareMatch 1 66 $0084 SCNT_CMP 2 Symbol CounterCompareMatch 2 67 $0086 SCNT_CMP 3 Symbol CounterCompareMatch 3 68 $0088 SCNT_OVFL Symbol CounterOverflow 69 $008A SCNT_BACKOFF Symbol Counter Backoff Slot Counter 70 $008C AES_READY AES EncryptionReady 71 $008E BAT_LOW Batterie Monitor Allert W omawianej aplikacji wykorzystywane są 4 przerwania (pogrubione w tabeli): wektor 59 rozpoczęcie odbierania danych, do określenia dokładnego czasu nadejścia ramki danych, wektor 60 zakończenie odbierania danych, gdy dane są odebrane następuje ich przekazanie do kolejnej funkcji warstwy MAC, wektor 62 do ustalenia mocy z jaką wysyłana jest ramka ACK, wektor 63 zakończenie wysyłania danych sygnalizowane warstwie MAC. Pozostałe przerwania służą m. in. do dokładnego odliczania czasu wyrażonego w symbolach (16 µs), obsługi zdarzeń związanych z uruchamianiem transceivera oraz szyfrowaniem wysyłanych lub odbieranych danych. 3.3 Architektura sieci Prezentowana sieć sensorowa zbudowana będzie z trzech rodzajów węzłów: węzła MASTER, węzłów pomiarowych (SLAVE), węzłów przekazujących dane przesyłane w sieci, oraz komputera PC z aplikacją sterującą siecią i wizualizującą dane odebrane z sieci. Aplikacja ta udostępni graficzny interfejs do konfiguracji sieci oraz do generowania żądań przekazania danych z sieci. Zadania wykonywane przez poszczególne węzły zostały przedstawione w Tabela

71 Tabela 3.4 Zadania węzłów sieci. Typ węzła MASTER, połączony z komputerem PC SLAVE, węzeł wyposażony w czujniki SLAVE, węzeł bez czujników Zadania 1. z komputera PC odbiera komendę żądania danych i parametry konfiguracji sieci 2. wysyła do węzłów sieci żądanie przekazania danych pomiarowych dostępnych w poszczególnych węzłach 3. w żądaniach tych przesyła parametry konfiguracji sieci 4. formatuje otrzymane dane i przekazuje do komputera PC 5. nie uczestniczy w samoorganizacji sieci 1. na żądanie MASTERA przesyła wartości odczytane z czujników oraz pozycję z GPS 2. uczestniczy w samoorganizacji sieci 1. przekazuje pakiety danych innych węzłów sieci 2. uczestniczy w samoorganizacji sieci Węzeł w przesyłanej ramce danych umieszcza komendę, jest to pierwszy bajt danych. Tabela 3.5 przedstawia komendy zdefiniowane dla projektowanej sieci wraz z opisem. Tabela 3.5 Komendy przesyłane w sieci. Komenda Opis ACK W A wyszukiwanie sąsiadów, odbiorca sprawdza jakość wiadomości i jeśli jest powyżej zadanej odpowiada wysyłając komendę A odpowiedź na komendę W, zawiera wartość LQI wiadomości określającą jakość połączenia w zakresie oraz ID Liczba bajtów Nie 50 Nie 4 O dane pomiarowe węzła, w tym dane z GPS Tak max 80 o dane pomiarowe przesłane do węzła MASTER, komenda o wysyłana jest w odpowiedzi na komendę s, transmisja z mocą maksymalną Tak max 80 S żądanie danych przesłane przez węzeł sieci, konfiguracja sieci Nie 13 s żądanie danych przesłane przez węzeł MASTER, transmisja z mocą maksymalną, konfiguracja sieci Tak 4 Komenda określa typ pakietu. Węzeł, który pakiet odebrał, sprawdza jego typ i podejmuje działania odpowiednie dla danego typu. W Tabela 3.5 wyszczególniono wszystkie komendy stosowane w sieci. Pole ACK informuje czy transmisja danej komendy odbywa się z potwierdzeniem odbioru za pomocą ramki ACK, czy też bez potwierdzenia Model warstwowy sieci W niniejszym podrozdziale przedstawiono protokoły komunikacyjne warstwy łącza bazujące na standardzie , warstwy sieciowej zarządzające routingiem wiadomości oraz 71

72 warstwy samoorganizacji. Ponadto przedstawiono sposób komunikacji węzła MASTER z komputerem PC oraz parametry konfiguracji sieci. Rysunek 3.7 przedstawia model warstwowy omawianej sieci. Rysunek 3.7 Model warstwowy sieci. Między warstwą MAC a warstwą sieciową umieszczono warstwę samoorganizacji. Warstwa ta dostarcza tabelę sąsiadów dla warstwy sieciowej, która wykorzystuje ją w algorytmach routingu Warstwa łącza Warstwa łącza sieci oparta jest na standardzie , który został stworzony z myślą o sieciach sensorowych, których węzły dysponują ograniczonymi zasobami energetycznymi (zasilanie z baterii) oraz ograniczoną mocą obliczeniową. Ramka danych w warstwie łącza została przedstawiona na Rysunek 3.8. Rysunek 3.8 Ramka , warstwa fizyczna [7]. Ramka danych zdefiniowana w składa się z: preambuły 4 oktety (bajty) o wartości zero, SFD (Start-of-Frame Delimiter) bajt startu ramki o wartości 0xA7, PHR bajt, którego 7 najmniej znaczących bitów określa ilość bajtów w PSDU (dane warstwy fizycznej), bit 8. powinien mieć wartość 0, PSDU (PHY Service Data Unit) dane warstwy fizycznej, struktura o max długości 127 bajtów Warstwa MAC W warstwie MAC ramka (PSDU warstwy fizycznej) składa się z następujących pól (Rysunek 3.9): nagłówka MAC zawierającego: o FCF (Frame Control Field) 2 bajty kontrolne zawierające m.in. informacje o typie ramki (beacon, data, ACK, MAC command), o żądaniu ACK, wersji 72

73 ramki oraz trybie adresów nadawcy i odbiorcy (tryb krótki adres 16-bitowy, tryb długi adres 64-bitowy), o Sequence Number liczba inna dla każdej ramki, o pola adresów (Addressing Fields) adresy nadawcy i odbiorcy (w trybie zdefiniowanym w FCF) oraz adres sieci PAN ID, o Auxiliary Security Header w przypadki transmisji szyfrowanej dodatkowe informacje bezpieczeństwa, dane warstwy MAC (MAC Payload) dowolne dane przesyłane przez aplikację, FCS (Frame Check Sequence) 16-bitowa suma kontrolna CRC. Rysunek 3.9 Ramka danych w warstwie MAC [7]. Do implementacji standardu wykorzystano oprogramowanie MAC udostępnione bezpłatnie przez firmę Atmel. Wymaga ono jednak drobnych modyfikacji, aby możliwa była samoorganizacja zgodnie z przyjętymi założeniami. Modyfikacje te powodują, że warstwa łącza prezentowanej sieci nie będzie w pełni zgodna ze standardem Zmiany te obejmują: sposób sterowania mocą nadajnika moc nie jest przypisana do węzła, lecz zmienia się w zależności od rodzaju wysyłanej ramki, kilkukrotne powtórzenie algorytmu CSMA-CA w przypadku transmisji zakończonej błędem, dla ramki z danymi pomiarowymi, której wysłanie zakończyło się niepowodzeniem, zmieniany jest adresat i ponawiana jest próba wysłania Warstwa samoorganizacji Przez samoorganizację w prezentowanej sieci rozumiane są takie działania węzła sieci, które prowadzą do zbudowania listy adresów węzłów-sąsiadów, które połączone są z węzłem łączem radiowym o określonej jakości przy minimalnej mocy nadawczej węzła. Wynikiem procedury samoorganizacji jest tabela sąsiadów oraz moc nadajnika, z jaką będą wysyłane wiadomości żądania danych i wiadomości zawierające dane. Węzły znajdujące się na liście sąsiadów są jedynymi węzłami, z którymi dany węzeł może się komunikować. Przyjęto dwa wyjątki od tej zasady: każdy węzeł może komunikować się bezpośrednio z węzłem MASTER, 73

74 przesyłanie danych przez węzeł nie posiadający sąsiadów. Na podstawie dotychczasowych doświadczeń [2] w prezentowanej w niniejszym dokumencie koncepcji sieci zdecydowano się na zastosowanie algorytmu samoorganizacji k-neighbours. Algorytm ten jest stosunkowo prosty w implementacji oraz daje zadowalające wyniki [15]. Wykorzystanie bardziej złożonych algorytmów samoorganizacji, m.in. z wykorzystaniem informacji o pozycji z GPS, planowane jest w dalszych etapach prac. Ogólny algorytm wyszukiwania sąsiadów przedstawiono na Rysunek Rysunek 3.10 Algorytm samoorganizacji k-neighbours. Węzeł rozpoczyna wyszukiwanie po upływie czasu Ts, który jest jednym z parametrów sieci definiowanym z poziomu aplikacji sterującej. Węzeł szukający sąsiadów wykonuje następujące działania: 1. ustawia moc nadajnika osiągniętą podczas ostatniej samoorganizacji, 2. wysyła ramkę zapytania (komenda W + 45 dodatkowych bajtów dla lepszego pomiaru jakości łącza), 3. czeka ok. 1s, 4. sprawdza, ile węzłów odpowiedziało na pytanie, 5. jeśli odpowiedziało zbyt mało węzłów, zwiększa moc i ponownie wysyła zapytanie, 6. jeśli znalazł zadaną liczbę sąsiadów, zmniejsza moc i wysyła zapytanie. Węzeł, który otrzymał zapytanie, wykonuje następujące kroki: 74

75 1. sprawdza jakość otrzymanej wiadomości W, 2. jeśli jakość jest powyżej zadanej, odpowiada na nią (do nadawcy W wysyła wiadomość A ) z mocą zdefiniowaną w zapytaniu; w odpowiedzi umieszcza LQI odebranej komendy W. Zakończenie procedury samoorganizacji następuje w sytuacji, gdy: 1. osiągnięto moc minimalną lub maksymalną, 2. osiągnięto zadaną liczbę sąsiadów, a dalsze zmniejszenie mocy powoduje zmniejszenie liczby sąsiadów. Wynikiem samoorganizacji jest tabela adresów sąsiadów węzła. Tabela ta jest używana przez warstwę sieciową w procedurach routingu. Jeżeli w wyniku samoorganizacji węzeł RoutingNode przestał być sąsiadem jako RN wybierany jest inny węzeł z listy sąsiadów. Sterowanie mocą wysyłanych wiadomości W i A odbywa się w warstwie łącza, co stanowi modyfikację standardu Przykładowy scenariusz samoorganizacji Rysunek 3.11 przedstawia przebieg przykładowej procedury samoorganizacji. Przyjęto następującą konfigurację sieci: liczba szukanych sąsiadów MAX_N = 3, minimalna jakość transmisji MIN_LQI = 30. W chwili T1 węzeł w0 rozpoczyna procedurę poszukiwania sąsiadów z mocą 16,5 dbm. Wysyła komendę W. Wiadomość zostaje odebrana przez wszystkie węzły z LQI o wartościach 50 dla w1, 40 dla w2, 20 dla w3 i 18 dla w4. Ponieważ tylko w przypadku węzłów w1 i w2 LQI przekracza LQI_MIN, tylko te węzły odpowiadają, wysyłając A do węzła w0. Po 1s węzeł w0 sprawdza, ile węzłów odpowiedziało. Ponieważ odpowiedziały tylko 2, zwiększa moc nadawania do 11,5 dbm i ponownie wysyła wiadomość W w chwili T2. Dla tej wiadomości jakość połączenia została określona na 70 w1, 55 w2, 30 w3, 31 w4. Każdy z węzłów odpowiada wiadomością A węzłowi w0. w Sąsiedzi: T1 w2, w5 T2 w2, w5, w4 w w w2 w dbm dbm Rysunek 3.11 Przykładowy scenariusz samoorganizacji. 75

76 Węzeł w0, odbierając A, dopisuje do listy sąsiadów węzły o najwyższym LQI. Procedura wyszukiwania zostaje zakończona, na liście sąsiadów węzła w0 znajdują się węzły: w1, w2 i w4 zaś moc nadajnika zostaje ustalona na 11,5 dbm Warstwa sieciowa Warstwa sieciowa odpowiedzialna jest za przesyłanie (routing) pakietów z danymi pomiarowymi (komendy O i o ) oraz żądań przesłania danych (komendy S i s ). Dla omawianej sieci opracowano autorskie algorytmy routingu, które mają zapewnić: rozesłanie żądania danych i konfiguracji do maksymalnej liczby węzłów, przesłanie danych pomiarowych do węzła MASTER. Aby przesyłanie danych było możliwe, każdy węzeł sieci musi mieć zdefiniowany adres o nazwie RoutingNode (RN). Jest to adres węzła, do którego przesyłane są dane pomiarowe. Sposób wyboru RN został przedstawiony poniżej. W dalszych punktach przedstawiono proponowane algorytmy routingu dla poszczególnych komend. Żądanie danych przesłane przez węzeł MASTER Komenda żądania danych przesyłana jest przez węzeł MASTER jako broadcast na adres 0xFFFF. Komenda ma oznaczenie s i jest przesyłana z mocą maksymalną. W komendzie tej przesyłane są następujące pola: identyfikator wiadomości s, pole 8-bitowe, ID wiadomości, 16-bitowa liczba losowa, liczba przeskoków, zwiększane o 1 przy każdym kolejnym przesłaniu, pole 16-bitowe, pola konfiguracji sieci omówione w dalszej części. Algorytm routingu komendy s pokazano na Rysunek Rysunek 3.12 Routing wiadomości żądania danych od węzła MASTER. Węzeł, który odebrał wiadomość s ustawia adres MASTER-a jako RN i do niego przesyła swoje dane pomiarowe z mocą maksymalną, zaś do swoich sąsiadów przesyła komendę S. Jest to jedyny przypadek kiedy jako RN ustawiany jest węzeł nie znajdujący się na liście 76

77 sąsiadów. Węzeł MASTER nie jest wpisany na listę sąsiadów żadnego z węzłów, gdyż nie uczestniczy on w procedurach samoorganizacji. Żądanie danych przesłane przez zwykły węzeł Jako zwykły węzeł rozumiany jest każdy węzeł należący do sieci i nie będący węzłem MASTER. Jak widać z poprzedniego punktu węzeł sieci otrzymuje od węzła MASTER komendę s, przesyła swoje dane pomiarowe, a następnie, jeśli posiada sąsiadów, wysyła do nich komendę S. Komenda ta zawiera te same dane co s, lecz informuje kolejne węzły, że nie jest od MASTER-a, czyli: nie musi być wysłana z mocą maksymalną, nadawca nie musi być ustawiony jako RN, jeśli nie jest sąsiadem. Rysunek 3.13 Routing wiadomości S. Algorytm routingu komendy S pokazano na Rysunek Węzeł, który odebrał wiadomość S, wykonuje następujące czynności: sprawdza, czy liczba przeskoków jest mniejsza od max dopuszczalnej, jeśli jest większa ignoruje wiadomość, odczytuje ID i sprawdza, czy otrzymał już wcześniej wiadomość o takim ID, jeśli nie zapisuje ID do tabeli i przechodzi do kolejnych czynności; jeśli ID znajduje się już w tabeli wiadomość jest ignorowana, sprawdza, czy nadawca jest sąsiadem, jeśli tak ustawia go jako RN, 77

78 przesyła do RN swoje dane pomiarowe, zwiększa o 1 liczbę przeskoków wiadomości, przesyła S do swoich sąsiadów. Przesyłanie danych pomiarowych Dane pomiarowe (wiadomości O lub o ) przesyłane są zawsze do węzła RoutingNode z mocą nadajnika określoną podczas ostatniej samoorganizacji lub z mocą maksymalną gdy przesyłane są do węzła MASTER. Proponowany algorytm procedury przesyłania danych przedstawiony został na Rysunek Rysunek 3.14 Routing wiadomości z danymi pomiarowymi. Węzeł RoutingNode wybierany jest w następujący sposób: jest to węzeł MASTER, od którego odebrano wiadomość s, jest to węzeł z listy sąsiadów, od którego odebrano S, gdy do nadawcy wróciła wiadomość z danymi O, jako RN wybierany jest inny węzeł z listy sąsiadów, jeśli węzeł nie posiada sąsiadów, zaś otrzymał wiadomość S, nadawcę wiadomości ustawia jako RN. Wiadomości z danymi zawierają licznik przeskoków wiadomości, który zwiększany jest o 1 przy każdym kolejnym przesłaniu; gdy licznik przekroczy dopuszczalną wartość wiadomość taka jest ignorowana przez węzeł, który ją odebrał. Wiadomość o, czyli przesyłana bezpośrednio do MASTER-a, powinna mieć zawsze licznik skoków równy 0. Przykładowy scenariusz żądania danych i przesyłania danych pomiarowych W scenariuszu tym założono, że dostęp do kanału może posiadać w danym czasie tylko jeden węzeł oraz węzły posiadają następujących sąsiadów: węzeł w1: w4 i w2, węzeł w2: w3, w4 78

79 i w5, węzeł w3: w2 i w5, węzeł w4: w1, w2, w5, węzeł w5: w2, w3 i w4. Na Rysunek 3.15a przedstawiono 13 pierwszych kroków scenariusza, zaś wszystkie zdarzenia pokazane są na Rysunek 3.15b. W chwili 1 (numery w nawiasach przy symbolu komendy na Rysunek 3.15a węzeł MASTER przesyła komendę s i zostaje ona odebrana przez węzły w1, w2 i w3. Węzły te ustawiają adres MASTER-a jako RN. W chwili kolejnej węzeł w1 uzyskuje dostęp do łącza radiowego i odsyła dane odczytane ze swoich sensorów do RN. Następnie przesyła komendę S do węzła w4, który ustawia w1 jako RN. W chwili 4 węzeł w4 odsyła dane pomiarowe do w1. Dokładny przebieg w czasie dalszych zdarzeń zaprezentowany został na Rysunek 3.15b. Na rysunku tym liczby z lewej strony oznaczają numery kolejnych transmisji przesyłanych w sieci. b) a) Rysunek 3.15 Scenariusz przesyłania danych (opis w tekście). W prezentowanym scenariuszu węzeł w5 odbiera wiadomość S od węzła w4, który otrzymał ją od w1, czyli jest to 2. skok wiadomości S ( S jest wysłane od MASTER-a ze skokiem 0). Liczbę 2 węzeł w4 zapisuje do odpowiedniego pola wiadomości S. Widzimy, że najdłuższą drogę przebyła wiadomość z danymi od węzła w5, do MASTER-a dotarła ona poprzez węzły w4 i w1. Największy ruch obsłużył węzeł w1, który przesłał dane od węzłów w5 i w4 oraz swoje. Ponieważ dostęp do kanału radiowego jest zdarzeniem losowym, czyli losowa jest kolejność przesyłania komend S, podczas kolejnego zapytania przesyłanie danych może przebiegać całkowicie innymi ścieżkami Warstwa aplikacji Zgodnie z przyjętą koncepcją, w warstwie aplikacji węzeł sieci wykonuje następujące zadania: 79

80 ustawia wartości parametrów sieci zgodnie z wartościami otrzymanymi w wiadomości S (lub s ), odczytuje wyniki pomiarów czujników, steruje usypianiem i wybudzaniem odbiornika GPS, węzeł MASTER odbiera żądanie przesłania danych z komputera i przesyła je do sieci, węzeł MASTER formatuje dane otrzymane od węzłów i przesyła je do komputera PC. Konfiguracja sieci Jak już wcześniej wspomniano, ważną cechą prezentowanej sieci jest możliwość jej zdalnej konfiguracji, przez co uzyskano też pewien stopień zdalnej skalowalności sieci. Konfiguracja sieci dokonuje się poprzez rozesłanie wiadomości S ( s ), w której umieszczone zostały pola wartości parametrów sieci. Struktura wiadomości S przedstawiona została w tabeli 6. Tabl. 6. Struktura wiadomości żądania danych. L.p. Pole Opis Przykład Bajty 1 Komenda komenda żądania danych z sieci S 1 2 MAX_S max. liczba przeskoków dla wiadomości "S" MAX_O max. liczba przeskoków dla wiadomości "O" T_S czas między proc. samoorganizacji, max 72h T_GPS czas między odczytem pozycji z GPS, max 72h LQI_MIN min LQI w procedurze samoorganizacji MAX_N maksymalna liczba sąsiadów, od 1 do CRC suma kontrolna CRC 0x1C 1 suma 12 Pole MAX_S definiuje maksymalną liczbę przeskoków dla wiadomości S, dzięki temu parametrowi możliwa jest zmiana zasięgu rozsyłania zapytania, a co za tym idzie zasięgu odczytu danych z sieci. Pole MAX_O ma głównie na celu zablokowanie przesyłania w nieskończoność wiadomości z danymi, która przesyłana jest między węzłami, lecz nie może dotrzeć do MASTER-a. Przypadek taki może wystąpić, gdy po samoorganizacji stracona zostanie połączeniowość i grupa węzłów oddzieli się od reszty sieci, wówczas wiadomość z danymi nie ma drogi wyjścia z odciętej grupy. Pole T_S określa czas, jaki musi upłynąć między kolejnymi procedurami samoorganizacji. Czas ten należy dobrać biorąc pod uwagę zmiany położenia węzłów względem siebie, np. w przypadku węzłów będących w ruchu samoorganizacja powinna następować częściej, niż gdy węzły pozostają w spoczynku. Pole T_GPS określa jak często odczytywana jest pozycja z odbiornika GPS. Oczywiście gdy węzeł porusza się, odczyt pozycji powinien być odpowiednio częsty. Po odczytaniu pozycji odbiornik GPS zostaje wyłączony (lub wprowadzony w stan oszczędzania energii), przez co zmniejsza się zużycie energii węzła. Odbiornik GPS zużywa w węźle największą ilość energii: pobór prądu to ok. 50 ma podczas pomiaru oraz ok. 17 ma w stanie stand-by, 80

81 podczas gdy reszta węzła zużywa tylko ok. 20 ma. Jak widać wybór wartości T_GPS jest kompromisem między dokładnością pozycji a czasem pracy węzła. Pole LQI_MIN zawiera wartość od 1 do 255 określającą minimalne LQI, przy którym węzeł odpowiada na zapytania W (kto jest moim sąsiadem) innego węzła. Obok parametru MAX_N ma on decydujący wpływ na topologię sieci. Im niższe LQI_MIN, tym większa możliwość posiadania większej liczby sąsiadów, czyli większa połączeniowość sieci, jednak istnieje wówczas większe ryzyko niskiej jakości łącza. Pole MAX_N określa maksymalną liczbę sąsiadów, jaka może być znaleziona w procedurze samoorganizacji. Topologie sieci uzyskane w procedurach samoorganizacji są w głównej mierze pochodną parametrów MAX_N i LQI_MIN, przy ustalonych położeniach węzłów i niezmiennych warunkach terenowych. Zwłaszcza niskie MAX_N może powodować tworzenie lokalnych grup węzłów oddzielonych od reszty sieci i w niej niewidocznych. Z kolei wysokie wartości wydłużają procedurę samoorganizacji i zwiększają moc nadawczą węzłów, co może powodować duży ruch i zwiększenie zakłóceń w sieci, a to z kolei może prowadzić do mało efektywnej samoorganizacji, przez co węzeł zamiast większej liczby sąsiadów ma ich mniej. Komunikacją między węzłem MASTER i komputerem sterującym Węzeł MASTER komunikuje się z komputerem sterującym poprzez konwerter RS-232 USB (Rysunek 3.16). Konwerter ten dostarcza również zasilania dla węzła MASTER. Rysunek 3.16 Węzeł MASTER. Komenda żądania danych przesyłana z komputera sterującego ma strukturę przedstawioną w tabl. 6. Zawiera ona nagłówek w postaci komendy S oraz parametry konfiguracji sieci. Węzeł MASTER po otrzymaniu danych pomiarowych węzła formatuje je zgodnie z Tabela 3.6 i przesyła do komputera. Tabela 3.6 Dane przesyłane z węzła MASTER do komputera sterującego L.p. Opis Przykład Bajty 1 Nagłówek AA 2 2 Moc nadajnika 0x Ilość przeskoków wiadomości O ID wiadomości, liczba losowa Adres MAC nadawcy FFFF1750A8 8 6 Napięcie zasilania procesora [mv] Temperatura wewnętrzna procesora [ºC] Liczba sąsiadów

82 L.p. Opis Przykład Bajty 9 Temp. z zewnętrznego czujnika [ºC] Przyspieszenie X [5461 LSBs/g] Przyspieszenie Y Przyspieszenie Z Dane czujnika o adresie 0x Dane czujnika o adresie 0x Dane czujnika o adresie 0x Dane czujnika o adresie 0x Zarezerwowane (w testach używane do przesłania adresu RN) 0x00 0xCF 2 18 Zarezerwowane Dane z GPS (znaki ASCII) , ,N, ,E,0.06,0.00,14,3 20 Suma kontrolna CRC 0x6D Aplikacja sterująca Integralną częścią omawianej sieci jest aplikacja sterująca, która: poprzez węzeł MASTER wysyła żądanie przesłania danych do sieci, odbiera przesyłane dane, wykonuje wizualizację odebranych danych, pozwala ustawić parametry konfiguracji sieci, odebrane dane zapisuje w pliku tekstowym. Interfejs aplikacji przedstawiono na Rysunek Wizualizacja sieci obejmuje następujące elementy: pozycja węzła obliczona na podstawie danych z GPS, wielkość węzła odpowiada mocy nadajnika węzła, węzły oznaczone są dwoma kolorami: zielony węzeł nadający bezpośrednio do MASTER-a, czarny pozostałe węzły, dodatkowo jeśli napięcie procesora spada poniżej 3,225V węzeł rysowany jest w kolorze czerwonym, węzły przesyłające dane między sobą połączone są liniami. W aplikacji zaimplementowano również funkcje, które ułatwiają testowanie sieci i analizę otrzymanych danych, są to m.in.: możliwość wysyłania żądań co zadany odcinek czasu, zapis topologii (wizualizacji sieci) do plików graficznych, pomiar odległości między węzłami przy pomocy myszki. 82

83 Rysunek 3.17 Interfejs aplikacji sterującej Włączenie sieci do Internetu 6 Omawiana sieć może zostać połączona z siecią Internet poprzez włączenie do Internetu komputera PC sterującego węzłem MASTER. Komputer ten pełni rolę bramy pośredniczącej pomiędzy siecią sensorową a Internetem. Schemat takiego rozwiązania pokazano na Rysunek Ze względu na brak bezpośredniej kompatybilności standardu z sieciami IP, konieczne jest wstawienie urządzenia pośredniczącego pomiędzy węzłem MASTER a końcówką tej sieci, którą może być np. modem komórkowy 7 (UMTS, HSPA, LTE etc.). Rolą tego urządzenia jest odpowiednie sterowanie siecią i transmisja danych poprzez translację zapytań z sieci IP na polecenia obsługiwane przez węzeł MASTER. W zależności od późniejszej aplikacji systemu przewidziano umieszczenie w sieci dodatkowego serwera zajmującego się logowaniem i archiwizacją informacji z różnych podsieci na różnych obszarach ich funkcjonowania tak, aby usprawnić funkcjonowanie sieci i udostępnianie informacji ostatecznemu użytkownikowi. Oprócz danych odczytywanych z czujników serwer będzie przechowywał dane konfiguracyjne, które będą uaktualniane na bieżąco, bądź też w przypadku przerwy w łączności z którąś z sieci dopiero po ponownym połączeniu. Użytkownik końcowy będzie miał dostęp do systemu za pomocą specjalnej aplikacji zainstalowanej na terminalu z dostępem do Internetu (przykładowo komputerze bądź smartfonie), dającej mu możliwość sterowania wybranym węzłem MASTER, bądź grupą węzłów tak, jakby był do nich podłączony bezpośrednio. Dodatkowo przewidziano dostęp do bazy zagregowanych danych za pomocą odpowiednio przygotowanego serwisu webowego. 6 Koncepcja ta może zostać zrealizowana w kolejnych etapach niniejszej pracy. Poczynione zostały już pewne prace przygotowawcze patrz rozdział piąty niniejszej pracy. 7 W ramach niniejszej pracy statutowej zakupiono już modem LTE USB Access Head firmy ACTE (z modułem AirPrime MC7710 firmy Sierra Wireless) działający w technologiach GSM/GPRS/EDGE/UMTS/HSDPA/HSUPA/HSPA+/LTE. Urządzenie to wstępnie przetestowano pod kątem jego przydatności dla włączenia zaproponowanej sieci sensorowej do Internetu. 83

84 Rysunek 3.18 Połączenie sieci sensorowej z Internetem. Należy zaznaczyć, że w prezentowanym rozwiązaniu nie zastosowano komunikacji węzełwęzeł, czyli nie jest możliwa komunikacja z konkretnym węzłem sieci, lecz zastosowano komunikację MASTER-sieć, czyli wybierając MASTERA wybieramy całą jego sieć i otrzymujemy dane z całej sieci. Rozwiązanie to jest podyktowane ideą budowy sieci monitorującej parametry środowiska na dużych obszarach, kiedy najważniejsze jest zebranie danych od jak największej liczby węzłów. 3.4 Trudności napotkane w trakcie realizacji projektu Z uwagi na zastosowanie algorytmu CSMA-CA w procedurze dostępu do łącza występuje zjawisko blokowania się sieci (czyli algorytm CSMA-CA kończy się niepowodzeniem), gdy wiele węzłów chce nadawać dane w tym samym czasie. Sytuacja taka występuje, gdy rozsyłane jest zapytanie o dane (komunikat S ). Każdy węzeł, który otrzymał S, chce wysłać odpowiedź, a następnie rozesłać S do swoich sąsiadów. W międzyczasie węzły mogą rozpocząć procedurę samoorganizacji. Im większa jest gęstość sieci, tym częściej występuje opisane zjawisko. Standard [3] w takiej sytuacji przewiduje zakończenie procedury wysyłania ramki ze statusem failure. Ponieważ w budowanej sieci dążymy do jak najwyższej niezawodności konieczne były następujące modyfikacje procedur wysyłania danych (zawartych w oprogramowaniu warstwy MAC firmy Atmel): 1. Kilkukrotne powtórzenie algorytmu CSMA-CA, w przypadku wysyłania danych zakończonego niepowodzeniem. Kolejne próby transmisji oddzielone są odcinkami czasu o losowej długości. Między kolejnymi aktywacjami algorytmu CSMA-CA węzeł przechodzi w stan odbierania danych. 2. Jeśli kilkukrotne przesłanie danych zakończyło się niepowodzeniem, adresat danych zostaje zmieniony na kolejny węzeł z listy sąsiadów. 84

85 Przeprowadzone testy pokazały, że przyjęte rozwiązania w praktycznych sytuacjach rozwiązują problem blokowania się sieci. Przykładowe topologie sieci pokazano na Rysunek a) b) c) d) e) Rysunek 3.19 Przykładowe topologie uzyskane podczas testów sieci. Przedstawione rysunki są wizualizacjami sieci, jakie uzyskano w zaimplementowanej aplikacji sterującej. Czarne koła reprezentują węzły sieci, zaś ich średnica odzwierciedla moc nadajnika: im większa średnica tym większa moc. Zielone koła to węzły, które ramki danych przesyłają bezpośrednio do MASTER-a. Ich średnica reprezentuje moc uzyskaną podczas samoorganizacji, jednak transmisja do MASTER-a odbywa się zawsze z mocą maksymalną. Linie między węzłami reprezentują drogi, po których przesyłane są dane. Przykładowo na rys. b) i c) widzimy to samo rozłożenie węzłów, lecz inną drogę przejścia danych z węzła o adresie zakończonym na 0xC8 (węzeł po prawej stronie), co potwierdza dynamiczne zmiany topologii sieci. Pozostałe rysunki pokazują przykładowe topologie uzyskane podczas przeprowadzanych testów. 85

86 4 Wypracowanie koncepcji sieci testowej IoT w IŁ - wybór interfejsu radiowego Autorzy: mgr inż. Aleksander Orłowski (Z-1) inż. Arkadiusz Staszak (Z-1) mgr inż. MariuszWożniak (Z-1) 4.1 Wybór interfejsu radiowego Wybór interfejsu radiowego dla sieci testowej jest kontynuacją koncepcji przyjętej w Z-1 w 2011 r., polegającej na utworzeniu sieci urządzeń radiowych, wyposażonej w nadajniki małej mocy (Low Power Wireless Area Network, LoWPAN), w której dla potrzeb Internetu Rzeczy zastosowano rozwiązania zgodne ze standardem sieci opracowywanym przez Internet Engineering Task Force (IETF), znanym pod nazwą 6LoWPAN (IPv6 Low Power Wireless Area Network). Sieć 6LoWPAN tworzą poszczególne podsieci radiowe. Są one sieciami końcowymi IP, mają zwykle tylko jedno połączenie z inną siecią, służące do przesyłania pakietów z/do tej sieci, ale nie obsługują ruchu innych sieci nie są sieciami tranzytowymi, Rysunek 4.1. Poszczególne węzły sieci radiowej mają indywidualne adresy IPv6. Lokalny serwer przekształca adresy IPv6 stosowane w sieci radiowej na adresy IPv4 używane powszechnie w Internecie. Rysunek 4.1 Dołączenie sieci 6LoWPAN do Internetu W warstwie fizycznej i dostępu do medium w sieciach 6LoWPAN są stosowane urządzenia moduły radiowe, których interfejs radiowy jest zgodny ze specyfikacją IEEE , wykorzystujące kanały radiowe w zakresie częstotliwości ,5 MHz (tzw. pasmo 2,45 MHz). Częstotliwości środkowe tych kanałów są definiowane zgodnie z formułą: F c = (k 11) [MHz] dla k = 11, 12,, 26, gdzie k jest umownym numerem kanału. Moc nadajnika: 3 dbm (0,5 mw). 86

87 Czułość odbiornika nie powinna być gorsza niż 85 dbm. W paśmie 2,45 GHz, które jest pasmem udostępnionym dla różnych zastosowań, urządzenia radiowe zgodne ze standardem IEEE muszą współistnieć z innymi urządzeniami radiowymi. W środowisku mieszkalnym i/lub biurowym są to urządzenia WLAN (Wi-Fi) wg standardów IEEE b/g/n oraz Bluetooth. Z tego względu częstotliwości dla urządzeń IEEE wyznaczono w ten sposób, że cztery kanały (15, 16, 21 i 22) znajdują się w pasmach ochronnych kanałów systemu b/g, Rysunek 4.2. Wprawdzie nadajniki IEEE b/g emitują energię również poza granicami przydzielonego kanału, ale gęstość mocy pozapasmowej jest znacznie mniejsza, a skutkiem tego wzajemne oddziaływanie pomiędzy systemami może być mniejsze, niż w przypadku kanałów, których pasma się nakładają. 2 MHz Kanał MHz 22 MHz 2483,5 MHz MHz 2483,5 MHz Rysunek 4.2 Częstotliwości kanałów systemu i typowe wykorzystanie pasma w systemie b Warstwa fizyczna IEEE może przydzielać wolny kanał jako część algorytmu CSMA-CA korzystając z co najmniej jednej z trzech metod: detekcji energii powyżej określonego progu (ED), detekcji sygnału zgodnego z charakterystykami sygnału IEEE , kombinacji dwóch ww. metod. Stosowanie ED zapobiega zajmowaniu kanału zajętego już przez inne urządzenie niezależnie od tego, w jakim systemie ono pracuje. W standardzie IEEE zdefiniowano dwa parametry charakteryzujące poziom zakłóceń w kanale: pomiar ED służy do oszacowania mocy odbieranej w kanale radiowym i jest przeznaczony do wykorzystania w warstwie sieciowej w algorytmach wyboru kanału; pomiar LQI dla każdego odebranego pakietu informuje o energii sygnału odbieranego i/lub SNR. Kombinacja informacji o energii odbieranej w kanale radiowym oraz o SNR może wskazywać, czy błędy pakietu są rezultatem niskiego poziomu sygnału odbieranego, czy dużego poziomu sygnałów zakłócających. 87

88 4.2 Urządzenia wykorzystane do testów Dla potrzeb badań sieci testowej użyto moduły radiowe, w których są stosowane układy firmy ATMEL obsługujące protokóły transmisji zgodne ze standardem IEEE Wykorzystano dwa rodzaje modułu radiowego RAVEN: RZUSBSTICK (fotografie na Rysunek 4.3) AVRRAVEN (fotografie na Rysunek 4.4) Oprócz tego dla potrzeb własnych aplikacji zaprojektowano i wykonano uniwersalne płytki z modułem ATMEL ATZB-24-A2 (Rysunek 4.5). Rysunek 4.3 Moduł radiowy RZUSBSTICK widok obu stron płytki Rysunek 4.4 Moduł radiowy AVRRAVEN widok obu stron płytki Rysunek 4.5 Uniwersalna płytka z modułem radiowym ATZB-24-A2 Schemat układu płytki z modułem radiowym ATZB-24-A2 zamieszczono na kolejnej stronicy. 88

89 89 Rysunek 4.6 Schemat

90 4.2.1 Opisy konstrukcji Moduł RZUSBSTICK Moduł ten składa się z radiowego układu nadawczo-odbiorczego AT86RF230 oraz sterującego nim mikrokontrolera AT90USB1287, Rysunek 4.7. Antena dipolowa jest wykonana na płytce obwodu drukowanego w formie dwóch ramion zagiętych pod kątem prostym. Moduł jest wyposażony w złącze USB i interfejs JTAG. Rysunek 4.7 Schemat blokowy modułu RZUSBSTICK Charakterystyka mikrokontrolera AT90USB bitowy mikrokontroler o architekturze RISC 128 KB pamięci FLASH oraz 8 KB pamięci SRAM interfejs USB 2,0 napięcie zasilania: 2,7 V 5,5 V interfejsy: JTAG, SPI, USART, I 2 C Moduł AVRRAVEN Moduł ten składa się z dwóch mikrokontrolerów: ATmega1284P sterującego radiowym układem nadawczo-odbiorczym AT86RF230 oraz ATmega3290P zapewniającego komunikację z wbudowanymi czujnikami, przełącznikami i wyświetlaczem LCD, Rysunek 4.8. Mikrokontrolery komunikują się między sobą przez szeregowy interfejs USART. Zastosowano antenę pętlową. Moduł jest wyposażony w przetwornik elektroakustyczny, sterownik przekaźnika, interfejsy ISP i JTAG. Na płytce dostępne są wyprowadzenia przetworników A/C, interfejsów I 2 C i SPI oraz portów we/wy mikrokontrolera. Moduł może być zasilany z baterii lub z zewnętrznego zasilacza DC. Rysunek 4.8 Schemat blokowy modułu AVRRAVEN 90

91 Charakterystyka mikrokontrolera ATmega1284P 8-bitowy mikrokontroler o architekturze RISC 128 KB pamięci FLASH oraz 16 KB pamięci SRAM napięcie zasilania: 1,8 V 5,5 V interfejsy: JTAG, SPI, USART, I 2 C Charakterystyka mikrokontrolera ATmega3290P 8-bitowy mikrokontroler o architekturze RISC 32 KB pamięci FLASH oraz 2 KB pamięci SRAM napięcie zasilania: 1,8 V 5,5 V interfejsy: JTAG, SPI, USART, I 2 C sterownik LCD Moduł ATZB-24-A2 Moduł ten składa się z radiowego układu nadawczo-odbiorczego AT86RF230 oraz sterującego nim mikrokontrolera ATmega1281, Rysunek 4.9. Zastosowano specyficzną antenę dipolową na podłożu ceramicznym. Moduł jest wyposażony w interfejs JTAG. Na płytce dostępne są wyprowadzenia przetworników A/C, interfejsów I 2 C i SPI oraz portów we/wy mikrokontrolera. Moduł może być zasilany z baterii lub z zewnętrznego zasilacza DC. Rysunek 4.9 Schemat blokowy modułu ATZB-24-A2 Charakterystyka mikrokontrolera ATmega bitowy mikrokontroler o architekturze RISC 128 KB pamięci FLASH oraz 8 KB pamięci SRAM napięcie zasilania: 2,7 V 5,5 V interfejsy: JTAG, SPI, USART, I 2 C We wszystkich wykorzystywanych ww. modułach jest instalowany układ nadawczoodbiorczy AT86RF230: układ pracuje w paśmie 2,45 GHz zgodnie ze standardem IEEE programowalny poziom mocy wyjściowej doprowadzonej do anteny: w zakresie od 17 dbm do 3 dbm znamionowa czułość odbiornika: 101 dbm napięcie zasilania: 1,8 V 3,6 V pobór prądu: 15,5 ma w trybie odbiornika, 16 ma w trybie nadajnika port antenowy symetryczny impedancja 100 Ω sterowanie: interfejs SPI 91

92 Opis wykorzystywanego oprogramowania Opisane wyżej moduły pracują pod kontrolą systemu o nazwie Contiki. Jego wybór został podyktowany tym, że: zaimplementowano w nim obsługę sieci zgodnej ze standardem 6LoWPAN; dostępne są wersje systemu dla różnych platform sprzętowych, w tym dla wymienionych w poprzednim punkcie układów firmy ATMEL. System Contiki został napisany w języku C przez zespół programistów ze Swedish Institute of Computer Science, z firmy CISCO i z firmy ATMEL. System można dowolnie rozbudowywać o aplikacje użytkownika pisane w języku C, kompilowane razem z kodem źródłowym systemu i uruchamiane jako dodatkowe procesy. Do programowania mikrokontrolerów w wykorzystywanych modułach ATMEL jest używany programator AVR JTAGICE mkii. Rysunek 4.10 Programator AVR JTAGICE mkii Ze względu na małą moc nadajników radiowych stosowanych w sieci 6LoWPAN i małą skuteczność miniaturowych anten zintegrowanych z modułami radiowymi uzyskanie komunikacji między odległymi węzłami wymaga wykorzystania węzłów pośredniczących. Do testów rutingu stosowano układ jak na rysunku Rysunek Rysunek 4.11 Ruting RPL w sieci 6LoWPAN 92

93 5 Stworzenie sieci testowej IoT w IŁ Zakład Z-8 Autorzy: dr inż. Krzysztof Bronk (Z-8) dr inż. Rafał Niski (Z-8) dr inż. Jerzy Żurek (Z-8) mgr inż. Adam Lipka (Z-8) mgr inż. Błażej Wereszko (Z-8) mgr inż. Piotr Wojnicz (Z-8) mgr inż. Krzysztof Żurek (Z-8) 5.1 Budowa sieci testowej W ramach trzeciego etapu pracy statutowej wykonano następujące zadania: 1. Opracowano procedury oprogramowania mikrokontrolerów do komunikacji między czujnikami węzła sieci (termometr cyfrowy, 2 akcelerometry oraz odbiornik GPS), a modułem radiowym węzła. 2. Usprawnieniu i rozbudowie (w stosunku do rozwiązania przedstawionego w [15]) uległy algorytmy samoorganizacji (zgodnie z punktem ) i routingu (zgodnie z paragrafem ). 3. Zaprojektowano i wykonano 2 płytki węzła Master z podłączeniem do komputera PC poprzez interfejs USB (patrz Rysunek 5.1A). 4. Zaprojektowano ponadto następujące płytki PCB 8 : a. Moduł z czujnikami do pomiaru wilgotności i ciśnienia atmosferycznego (patrz Rysunek 5.2A), b. Moduł do pomiaru natężenia światła i hałasu (patrz Rysunek 5.2B), c. Węzeł Master z interfejsem Ethernet (patrz Rysunek 5.1B) dla realizacji koncepcji podłączenia sieci do Internetu (patrz paragraf niniejszej pracy), d. Drugą wersję płytki PCB węzła sieci, w której usunięto błędy oraz dodano możliwość całkowitego wyłączenia odbiornika GPS (patrz Rysunek 5.3). 5. Znacznej rozbudowie (w stosunku do rozwiązania przedstawionego w [15]) uległ program do zarządzania i testowania funkcjonowania sieci (patrz paragraf 3.3.3). 6. Wykonano wstępne 9 testy funkcjonowania sieci pod kątem: długości pracy na bateriach (z i bez odbiornika GPS patrz Rysunek 5.4) oraz zasięgu sieci. 8 Budowa tych komponentów realizowana będzie w dalszych etapach pracy. Ich schematy elektryczne, zaprojektowane w ramach niniejszej pracy, przedstawiono w Załączniku nr 1. 9 Znacznie szerzej zakrojone badania oraz prezentacja ich rezultatów planowane są w kolejnych etapach realizacji niniejszej pracy statutowej. 93

94 Rysunek 5.1 Płytka PCB węzła MASTER podłączonego do komputera PC poprzez interfejs USB (A) oraz poprzez interfejs Ethernet (B). Rysunek 5.2 Płytka PCB modułu czujników wilgotności i ciśnienia (A) oraz modułu czujników światła i hałasu (B). Rysunek 5.3 Poprawiona i rozbudowana (w stosunku do zaproponowanej i przedstawionej w [15]) wersja płytki PCB węzła sieci sensorowej. 94

95 Napięcie zasilania [mv] Czas [h] GPS wyłączony GPS włączony Rysunek 5.4 Przykładowy rezultat badania czasu pracy węzła sieci na zasilaniu bateryjnym (przy dużym obciążeniu węzła samoorganizacja co 3 minuty i odpytywanie o dane co minutę). W trakcie pomiarów czasu pracy na zasilaniu bateryjnym przy różnym obciążeniu węzłów sieci, różnych mocach ich nadajników oraz różnych procedurach obsługi odbiorników GPS uzyskiwano rezultaty od kilkunastu godzin do około dwóch dób. W kolejnych etapach pacy planowana jest dalsza optymalizacja procedur zarządzania energią, wykorzystanie akumulatorów o większej pojemności oraz ewentualne zastosowanie zasilania solarnego w celu zwiększenia autonomiczności węzłów. Jeśli chodzi o określenie zasięgu stosowalności sieci, to uzyskiwane odległości pomiędzy poszczególnymi węzłami będącymi sąsiadami, dochodziły do około 150 metrów (przy optymalnych warunkach propagacyjnych). Jednym z możliwych sposobów rozbudowy zaproponowanej platformy, pozwalającym na rozszerzenie zasięgu sieci, może być wykorzystanie transceiverów w paśmie 868 MHz, które jest również zdefiniowane w standardzie IEEE [3]. W kolejnych etapach realizacji pracy planuje się dalszą rozbudowę programową i sprzętową proponowanej platformy oraz jej przystosowanie do realizacji jednej lub kilku wybranych aplikacji przedstawionych w kolejnym rozdziale niniejszej pracy. 5.2 Potencjalne aplikacje dla zaproponowanej platformy Przykładowe zastosowania dla zaproponowanej sieci sensorowej przedstawiono poniżej. Monitorowanie i sterowanie warunkami w winnicy. Węzły sieci sensorowej zbierają informacje o wilgotności i temperaturze powietrza i gleby w winnicy. Węzły sieci 6LoWPAN pozwalają na włączanie punktów zraszania winnicy. Lokalizacja węzłów może być zmieniana w zależności od chwilowych potrzeb, zależnie od ukształtowania terenu winnicy, zmiany jej powierzchni lub zmian pogodowych. Piwnica z winami. W piwnicy, gdzie leżakowane jest wino ważne jest utrzymanie odpowiedniej, stałej temperatury. Jest ona zależna od rodzaju wina, dla czerwonego wynosi od 12 C do 18 C, zaś 95

96 dla białego od 7 C do 11 C. Sieć sensorowa pozwala monitorować temperaturę, zaś sieć 6LoWPAN pozwala na uruchamianie właściwych wentylatorów służących obniżaniu temperatury. Węzły sieci mogą być przestawiane zależnie od potrzeb w danym miejscu piwnicy i zależnie od aktualnego wypełnienia piwnicy. Monitorowanie wilgotności ściółki leśnej. Monitorowanie wilgotności ściółki leśnej i wprowadzanie zakazu wstępu do lasu w razie zbyt niskiej wilgotności mogłoby być jednym z elementów zapobiegania pożarom lasów. Dodatkowo czujniki ruchu (w połączeniu z kamerą, aby odróżnić człowieka od zwierzęcia) mogą informować czy zakaz nie jest łamany. Węzły mogą być rozmieszczone w zależności od aktualnych potrzeb. Dodatkowo system mógłby służyć do wykrywania osób wyrzucających śmieci w lasach. Inteligentny dom. Sieć pozwala na zbieranie informacji o warunkach panujących w budynku, np. temperatura, wilgotność itd. Sieć 6LoWPAN może służyć do sterowania urządzeniami produkującymi ciepło, otwierającymi okna, regulującymi pozycję rolet w oknach itd. Dodatkowo sieć może być częścią systemu ochrony przez włamaniami. Możliwość zdalnego sterowania i podglądu parametrów domu poprzez Internet. Monitorowanie poziomu wody w rzekach. Sieć sensorowa rozmieszczona wzdłuż rzek może służyć do informowania o poziomie wody. Dzięki samoorganizacji informacje przesyłane byłyby wzdłuż rzek między węzłami, dzięki czemu możliwy jest znaczny zasięg sieci. W razie wystąpienia sytuacji wyjątkowej sieć daje możliwość łatwego dodania dodatkowych węzłów np. na terenach zalewowych. Monitorowanie warunków w magazynie (np. żywności). W magazynach ze względu na zmieniające się wypełnienie jak i rodzaj składowanych towarów ciągłej zmianie ulegają warunki transmisji radiowej. Samoorganizująca się sieć sensorowa zapewniłaby stałą połączeniowość sieci. Sieć 6LoWPAN daje możliwość sterowania urządzeniami wykonawczymi np. do sterowania temperaturą, wilgotnością itp. Dodatkowo istnieje możliwość monitorowania warunków niebezpiecznych np. dym pożaru, stężenie wybranych gazów itp. Monitorowanie stanu konstrukcji. W ciągu ostatnich lat w Polsce wydarzyło się kilka katastrof budowlanych, których przyczyną było zbytnie obciążenie konstrukcji, np. obciążenie dachu śniegiem. Dlatego aktualne stały się zagadnienia związane z monitorowanie stanu obciążenia odkształcenia konstrukcji budynków. Proponowana sieć może służyć do przekazywania informacji o odkształceniach elementów konstrukcji dzięki pomiarom tensometrycznym. W przypadku dachu obciążonego śniegiem pomiar ilości śniegu dostarczałby dodatkowo informacji o obciążeniu konstrukcji. Śledzenie plamy zanieczyszczeń na morzu. Węzły sieci rozrzucone na plamie oleju poruszającej się po powierzchni morza służą do monitorowania jej wielkości oraz ruchu. Zdolność samoorganizacji zapewniałaby połączeniowość w warunkach ciągłej zmiany pozycji węzłów. Pomiar zagrożeń na polu walki. Węzły sieci rozmieszczane są na polu walki lub poruszają się na mobilnych platformach i dokonują pomiarów żądanych parametrów środowiska, dzięki czemu wojsko ma informację o stanie zagrożeń. Ponieważ pole walki może być niebezpieczne również dla węzłów sieci i można założyć, że poszczególne węzły mogą tam ulegać zniszczeniu, samoorganizacja pozwoli zachować połączeniowość w takich warunkach. Dodatkowo sieć może dokonywać perymetrii wykrywać obecność wroga na monitorowanym terenie. 96

97 Sterowanie ruchem na autostradzie. Sieć dokonuje na autostradzie pomiarów takich parametrów jak hałas, drgania, zanieczyszczenie powietrza. Informacje te przesyłane są do programu, który może poprzez sieć 6LoWPAN zmieniać informacje wyświetlane na znakach drogowych znajdujących się na autostradzie. Dzięki temu możliwe jest sterowanie ruchem zależnie od panujących warunków, np. ograniczenie prędkości gdy hałas lub stężenie spalin są zbyt wysokie. Inteligentny parking. Projekty inteligentnych parkingów zakładają umieszczanie sensorów parkingowych w jezdni parkingu. Obecność samochodu na parkingu zmienia warunki radiowe co może prowadzić do utraty połączeniowości. Dzięki samoorganizacji węzły sieci zachowują połączeniowość w zmiennych warunkach parkingu, czyli przy zmieniającej się ilości jak i pozycji pojazdów korzystających z parkingu. Dzięki sieci sensorowej możemy uzyskiwać informacje o aktualnie wolnych miejscach postojowych i sterować za pośrednictwem sieci 6LoWPAN znakami drogowymi kierującymi do tych miejsc samochody wjeżdżające na parking. Monitorowanie ładunku w kontenerach. Kontenery transportowane drogą morską przestawiane są z portu na statek, następnie ze statku do innego portu, zmieniają swoją pozycję również w samym porcie. Dlatego też proponowana sieć, dzięki możliwości adaptacji swojej topologii do aktualnych pozycji węzłów, może zapewnić połączeniowość sieci nawet w tak zmiennym środowisku jak terminal kontenerowy czy ładownia statku. Dzięki niej możliwe jest zdalne odczytywanie mierzonych parametrów dla lokalnej grupy kontenerów, która w praktyce może obejmować wszystkie kontenery portu. 5.3 Koncepcja integracji zaproponowanego rozwiązania z siecią w standardzie 6LoWPAN W rozdziale tym zaprezentowana zostanie koncepcja integracji rozwiązania zaproponowanego w niniejszej pracy z platformą przedstawioną w [16]. Na rysunku 24 zaprezentowano schematycznie sposób integracji obu tych modułów. W prezentowanym rozwiązaniu wykorzystane zostaną dwa różne typy sieci: Sieć WSN opartą na standardzie Podstawową rolą tej sieci jest zbieranie danych pomiarowych wybranego parametru środowiska na danym obszarze przy zachowaniu jak najmniejszego zużycia energii. Sieć może zostać połączona z siecią Internet poprzez włączenie do Internetu komputera PC sterującego węzłem MASTER. Komputer ten pełni rolę bramy pośredniczącej pomiędzy siecią sensorową a Internetem. Ze względu na brak bezpośredniej kompatybilności standardu z sieciami IP, konieczne jest wstawienie urządzenia pośredniczącego pomiędzy węzłem MASTER a końcówką tej sieci, którą może być np. modem komórkowy (UMTS, HSPA, LTE etc.). Rolą tego urządzenia jest odpowiednie sterowanie siecią i transmisja danych poprzez translację zapytań z sieci IP na polecenia obsługiwane przez węzeł MASTER. Należy zaznaczyć, że w prezentowanym rozwiązaniu nie zastosowano komunikacji węzełwęzeł, czyli nie jest możliwa komunikacja z konkretnym węzłem sieci, lecz zastosowano komunikację MASTER-sieć, czyli wybierając MASTERA wybieramy całą jego sieć i otrzymujemy dane z całej sieci. Rozwiązanie to jest podyktowane ideą budowy sieci monitorującej parametry środowiska na dużych obszarach, kiedy najważniejsze jest zebranie danych od jak największej liczby węzłów. 97

98 Rys. 24. Schematyczne zobrazowanie integracji zaproponowanej platformy z siecią 6LoWPAN. Sieć WSN opartą na standardzie 6LoWPAN Sieć ta działa w oparciu o rozwiązanie 6LoWPAN i w tym przypadku wykorzystywana jest do punktowego sterowania wybranymi urządzeniami oraz odczytu parametrów środowiska/urządzenia w zadanych miejscach pomiarowych. W zależności od późniejszej aplikacji systemu przewidziano umieszczenie w sieci dodatkowego serwera zajmującego się logowaniem i archiwizacją informacji z różnych podsieci na różnych obszarach ich funkcjonowania tak, aby usprawnić funkcjonowanie sieci i udostępnianie informacji ostatecznemu użytkownikowi. Oprócz danych odczytywanych z czujników serwer będzie przechowywał dane konfiguracyjne, które będą uaktualniane na bieżąco, bądź też w przypadku przerwy w łączności z którąś z sieci dopiero po ponownym połączeniu. Użytkownik końcowy będzie miał dostęp do systemu za pomocą specjalnej aplikacji zainstalowanej na terminalu z dostępem do Internetu (przykładowo komputerze bądź smartfonie), dającej mu możliwość sterowania wybranym węzłem MASTER, grupą jego 98

99 podwęzłów oraz poszczególnymi urządzeniami podłączonymi przy pomocy sieci 6LoWPAN tak jakby był do nich podłączony bezpośrednio. Dodatkowo przewidziano dostęp do bazy zagregowanych danych za pomocą odpowiednio przygotowanego serwisu webowego. 99

100 6 Stworzenie sieci testowej IoT w IŁ Zakład Z-1 Autorzy: mgr inż. Aleksander Orłowski (Z-1) inż. Arkadiusz Staszak (Z-1) mgr inż. MariuszWożniak (Z-1) 6.1 Opis sieci testowej W sieci testowej IoT wykorzystano opisane wcześniej moduły radiowe RZUSBSTICK, AVRRAVEN, ATZB-24-A2 zaprogramowane do działania w sieci 6LoWPAN. Wszystkie testy przeprowadzono na II piętrze budynku głównego IŁ Pomiar poziomu zakłóceń W korytarzach budynku IŁ znajdują się punkty dostępowe radiowej sieci lokalnej (Wi-Fi) pracujące w paśmie 2,45 GHz. W celu wybrania najlepszego, niezakłóconego kanału do transmisji testowych, wykorzystując oprogramowanie modułu RZUSBSTICK zainstalowanego w przenośnym komputerze. Wykonano pomiary poziomów sygnału RF w wielu lokalizacjach, we wszystkich kanałach sieci IEEE Przykładowe wyniki tych pomiarów przedstawiono na Rysunek Rysunek 6.4. Punkty pomiarowe nr 3 i nr 4 wybrano w bliskiej odległości od punktów dostępowych WLAN. Odczyt 92 dbm wskazuje kanał wolny od zakłóceń. Ponieważ wg standardu IEEE wymagana czułość odbiornika powinna być mniejsza niż 85 dbm, a wymagany minimalny stosunek sygnału użytecznego do zakłóceń na wejściu odbiornika wynosi ok. 10 db, przeprowadzone testy dowodzą, że w budynku IŁ ze względu na poziom zakłóceń wytwarzanych przez aktywną sieć Wi-Fi w większości kanałów działanie sieci 6LoWPAN będzie utrudnione, a w wielu miejscach nie będzie możliwe. Na podstawie uzyskanych wyników do dalszych testów wybrano kanał 26 jako jedyny, który w wielu lokalizacjach okazał się wolny od zakłóceń wspólnokanałowych. Rysunek 6.1 Poziomy sygnału RF we wszystkich kanałach sieci , punkt pomiarowy nr 1 100

101 Rysunek 6.2 Poziomy sygnału RF we wszystkich kanałach sieci , punkt pomiarowy nr 2 Rysunek 6.3 Poziomy sygnału RF we wszystkich kanałach sieci , punkt pomiarowy nr 3 Rysunek 6.4 Poziomy sygnału RF we wszystkich kanałach sieci , punkt pomiarowy nr 4 101

102 6 m Próby retransmisji danych Moduły radiowe rozmieszczono w czterech punktach jak pokazano na Rysunek Korytarz budynku IŁ 4 25 m 17 m RZUSBSTICK (ruter brzegowy, adres: aaaa::200) 2 - AVRRAVEN (aaaa::11:22ff:fe33:4455) 3 - ATZB-24-A2 (aaaa::11:22ff:fe33:4457) 4 - ATZB-24-A2 (aaaa::11:22ff:fe33:4473) Rysunek 6.5 Rozmieszczenie czterech modułów radiowych podczas testów Ruter brzegowy (1) dołączono do komputera (serwera) działającego pod systemem Linux. Kolejne moduły, o adresach IP podanych na rysunku, znajdowały się w tym samym pomieszczeniu (2), na korytarzu (3) i na tarasie (4). Następnie uruchomiono aplikacje testujące parametry sieci. Wyniki ich działania zostały przedstawione na Rysunek Rysunek 6.9. Polecenie tracert6 umożliwia śledzenie trasy pakietu wysłanego do danego węzła. W przypadku przedstawionym na Rysunek 6.6 widać, że pakiet wysłany od węzła (1) do węzła (4) jest retransmitowany kolejno przez węzły (2) i (3). Rysunek 6.6 Śledzenie trasy pakietu wysłanego z węzła (1) do węzła (4) Następnie przy użyciu polecenia ping6 uzyskano wartości czasów transmisji pakietu do określonych węzłów sieci. Średnie czasy transmisji do węzłów (2), (3) i (4) wynoszą odpowiednio 27,609 ms, 40,451 ms i 54,898 ms. Rysunek 6.7 Czas transmisji pakietu wysłanego z węzła (1) do węzła (2) 102

103 Rysunek 6.8 Czas transmisji pakietu wysłanego z węzła (1) do węzła (3) Rysunek 6.9 Czas transmisji pakietu wysłanego z węzła (1) do węzła (4) Pomiary charakterystyk promieniowania anteny modułu ATZB-24-A2 Wykonano pomiary kierunkowych charakterystyk promieniowania anteny modułu ATZB-24-A zastosowanego na uniwersalnej płytce (przedstawionej na Rysunek 4.5). Charakterystyki kierunkowe uzyskane przy pionowej i poziomej polaryzacji anteny pomiarowej przedstawiono na Rysunek 6.10 i Rysunek Zmierzone charakterystyki kierunkowe promieniowania urządzenia z modułem ATZB-24-A2 różnią się od podanych w karcie katalogowej tego modułu. Prawdopodobnie jest to wpływ sposobu wykonania płytki obwodu drukowanego. Należy zwrócić uwagę na zaobserwowaną nierównomierność charakterystyk promieniowania. "Dziury" o głębokości kilkudziesięciu db oznaczają, że wzajemna orientacja w przestrzeni instalowanych modułów nie powinna być przypadkowa. Ponadto należy pamiętać, że oprócz charakterystyk (zysku kierunkowego) anten w bilansie łącza radiowego występuje składnik losowy, jakim są właściwości propagacyjne środowiska, które nie są dokładnie znane i mogą zmieniać się dynamicznie. Zatem niewielkie zmiany miejsca lub kierunku mogą zasadniczo wpływać na natężenie pola i jakość łącza radiowego. Efekt ten występuje w przypadku urządzeń ruchomych i stacjonarnych, ponieważ każdy ruchomy obiekt znajdujący się w zasięgu sieci, np. osoba przechodząca korytarzem, może zaburzać warunki propagacji. 103

104 Rysunek 6.10 Charakterystyka promieniowania modułu ATZB-24-A uzyskana przy pionowej polaryzacji anteny pomiarowej Zastosowanie opracowanego modułu w IoT Zaprojektowane płytki z modułem radiowym ATZB-24-A2 mają charakter uniwersalny. Interfejsy mikrokontrolera: JTAG, SPI, USART, I 2 C dołączone do odpowiednich czujników (sensorów) i/lub elementów wykonawczych (ang. actuator) mogą być wykorzystane dla potrzeb różnych aplikacji. Na Rysunek 6.12 pokazano schemat ilustrujący wykorzystanie tego modułu do zdalnej kontroli wypełnienia pojemnika, np. papierowymi ręcznikami. Jeden z portów wyjściowych wykorzystano do sterowania nadajnikiem podczerwieni, a analogowy port wejściowy połączono z wyjściem odbiornika optycznego. Mikrokontroler w zadanych odstępach czasu uaktywnia nadajnik i mierzy poziom sygnału z odbiornika. Poziom sygnału z odbiornika optycznego zmienia się, gdy pojemnik jest pusty pomiędzy nadajnikiem i odbiornikiem podczerwieni nie ma materiału np. papieru przesłaniającego łącze optyczne. Odpowiednia informacja jest przesyłana drogą radiową do rutera 6LoWPAN, a za jego pośrednictwem do serwera. Stan pojemnika może być zdalnie przez Internet skontrolowany (Rysunek 6.13). Brak papieru może automatycznie inicjować wysłanie do administratora budynku (Rysunek 6.14)

105 Rysunek 6.11 Charakterystyka promieniowania modułu ATZB-24-A uzyskana przy poziomej polaryzacji anteny pomiarowej A/C OPT101P ATZB-24-A2 GPIO TSHF5210 Rysunek 6.12 Schemat układu do zdalnej kontroli wypełnienia pojemnika Legenda: ATZB-24-A2: moduł radiowy A/C: przetwornik analogowo-cyfrowy GPIO: port wyjścia sterujący nadajnikiem IR OPT101P: scalony odbiornik optyczny (przetwornik światło/napięcie) TSHF5210: nadajnik IR 105

106 Rysunek 6.13 Okna aplikacji do kontroli wypełnienia pojemnika Rysunek 6.14 Powiadomienie o stanie kontrolowanego obiektu 106