Web of Things



"Architektura zorientowana na zasoby dla sieci rzeczy [Web Of Things]"
Dominique Guinard , Vlad Trifa , Erik Wilde

Wiele wysiłków koncentruje się na tworzeniu wielkoskalowych sieci "inteligentnych rzeczy" występujących w świecie fizycznym (np. bezprzewodowe sieci czujników i siłowników, urządzenia wbudowane, oznakowane obiekty). Zamiast ujawniać rzeczywiste dane i funkcjonalność za pośrednictwem zastrzeżonych i ściśle powiązanych systemów, proponujemy uczynić je integralną częścią sieci. W rezultacie łatwiej jest budować na inteligentnych rzeczach. Popularne języki internetowe (np. HTML, Python, JavaScript, PHP) mogą być używane do łatwego tworzenia aplikacji obejmujących inteligentne rzeczy, a użytkownicy mogą wykorzystywać dobrze znane mechanizmy internetowe (np. przeglądanie, wyszukiwanie, tworzenie zakładek, buforowanie, łączenie) do interakcji i udostępniania tych urządzeń . W tym artykule zaczynamy od opisu architektury Web of Things i najlepszych praktyk opartych na zasadach RESTful, które już przyczyniły się do popularnego sukcesu, skalowalności i modułowości tradycyjnej sieci Web. Następnie omawiamy kilka prototypów zaprojektowanych zgodnie z tymi zasadami w celu połączenia węzłów czujników środowiskowych i systemu monitorowania energii z siecią WWW. W końcu pokazujemy, jak inteligentne rzeczy obsługujące Internet mogą być używane w lekkich aplikacjach ad-hoc zwanych "fizycznymi mashupami"

I. WSTĘP

Głównym problemem w obszarze wszechobecnych komputerów była integracja cyfrowych artefaktów ze światem fizycznym. W szczególności "Internet przedmiotów" zasadniczo zbadał rozwój aplikacji zbudowanych na różnych obiektach fizycznych połączonych w sieć. Mieszkańcy świata fizycznego, takich jak sieci czujników i siłowników, urządzenia wbudowane, urządzenia i przedmioty codziennego użytku ulepszane cyfrowo (zwane dalej inteligentnymi rzeczami) są w większości odłączone od sieci i tworzą niezliczone ilości małych, niekompatybilnych wysp. Coraz częściej urządzenia wbudowane i elektronika użytkowa, na przykład Chumby, IoBridge lub Nabaztag, uzyskują łączność z Internetem (a czasem z siecią), ale nie można ich jednak kontrolować i monitorować bez dedykowanego oprogramowania i zastrzeżonych interfejsów. W rezultacie inteligentne rzeczy są trudne do zintegrowania z aplikacjami złożonymi, co poważnie utrudnia realizację elastycznego ekosystemu urządzeń, których można nieoczekiwanie ponownie wykorzystać. Internet rzeczy koncentruje się głównie na ustanawianiu łączności w różnych ograniczonych środowiskach sieciowych, a następnym logicznym celem jest zbudowanie łączności sieciowej poprzez skupienie się na warstwie aplikacji. W sieci rzeczy (WoT) rozważamy inteligentne rzeczy jako pierwszorzędnych obywateli sieci. Pozycjonujemy sieć rzeczy jako udoskonalenie Internetu rzeczy poprzez integrację inteligentnych rzeczy nie tylko z Internetem (siecią), ale Sieć (warstwa aplikacji). Aby osiągnąć ten cel, proponujemy ponowne wykorzystanie i adaptację wzorców powszechnie używanych w sieci oraz wprowadzenie architektury sieci rzeczy. Osadzamy serwery WWW na inteligentnych rzeczach i stosujemy styl architektoniczny REST do świata fizycznego (patrz sekcja III-A). Istota REST polega na skupieniu się na tworzeniu luźno powiązanych usług w sieci, tak aby można je było łatwo ponownie wykorzystać . REST jest w rzeczywistości rdzeniem sieci i wykorzystuje identyfikatory URI do hermetyzacji i identyfikowania usług w sieci. W swojej implementacji internetowej używa również HTTP jako prawdziwego protokołu aplikacji. Ostatecznie oddziela usługi od ich prezentacji i zapewnia klientom mechanizmy wyboru najlepszych możliwych formatów. To sprawia, że REST jest idealnym kandydatem do zbudowania "uniwersalnego" API (interfejsu programowania aplikacji) dla inteligentnych rzeczy. Ponieważ model interakcji HTTP typu "klient-ściągnij" nie w pełni odpowiada potrzebom aplikacji sterowanych zdarzeniami, sugerujemy ponadto użycie techniki dystrybucji, takie jak Atom i niektóre z najnowszych technologii internetowych czasu rzeczywistego umożliwiające interakcje z czujnikami. W konsekwencji proponowanej architektury, inteligentne rzeczy i ich funkcjonalność otrzymują przenośne identyfikatory URI, które można wymieniać, odwoływać się do witryn internetowych i zakładać. Inteligentne rzeczy są również ze sobą powiązane, umożliwiając odkrywanie po prostu przez przeglądanie. Interakcja z inteligentnymi rzeczami może również prawie całkowicie zachodzić z poziomu przeglądarki, narzędzia, które jest powszechnie dostępne i które większość użytkowników dobrze rozumie [8]. Aplikacje można budować na ich podstawie przy użyciu dobrze znanych języków i technologii internetowych (np. HTML, JavaScript, Ajax PHP, Python, narzędzia Mashup itp.) Ponadto inteligentne rzeczy mogą skorzystać na mechanizmach, które sprawiły, że sieć jest skalowalna i skuteczna, np. buforowanie, równoważenie obciążenia, indeksowanie i wyszukiwanie. Ponieważ niektóre urządzenia nie mogą połączyć się z Internetem lub w pełni zaimplementować stylu architektury REST, w końcu proponujemy użycie inteligentnych bram , które są wbudowanymi serwerami sieciowymi, które wyodrębniają komunikację i usługi urządzeń nie obsługujących sieci Web za interfejsem RESTful API . W sekcji V ilustrujemy architekturę WoT za pomocą kilku prototypów. Zaczynamy od zastosowania ich do czujników, siłowników i liczników energii i pokazujemy, jak można zbudować proste aplikacje internetowe na tych inteligentnych elementach. Następnie pokazujemy, że sieć rzeczy umożliwia zaawansowanym technicznie użytkownikom końcowym tworzenie fizycznych mashupów obejmujących inteligentne obiekty, tak jak tworzyliby mashupy internetowe.

II. POWIĄZANA PRACA

Łączenie sieci i obiektów fizycznych nie jest nowym pomysłem. Wczesne podejście rozpoczęło się od dołączania fizycznych tokenów (takich jak kody kreskowe) do obiektów, aby skierować użytkownika do stron w sieci WWW zawierających informacje o obiektach. Strony te były najpierw obsługiwane przez statyczne serwery WWW na komputerach typu mainframe, a następnie przez wczesny system bram, który umożliwiał urządzeniom o niskim poborze mocy dołączenie do szerszych sieci. Głównym zamysłem tych prac było zapewnienie wirtualnego odpowiednika fizycznych obiektów w sieci. URI do stron internetowych były skanowane przez użytkowników np. Przy użyciu urządzeń mobilnych i kierowały ich do reprezentacji online rzeczywistych rzeczy (np. zawierających status urządzeń na stronach HTML lub w instrukcjach obsługi). Wraz z postępem w technologii komputerowej, małe serwery internetowe mogą być wbudowane w większość urządzeń. Projekt Cooltown był pionierem w tej dziedzinie fizycznej sieci internetowej, łącząc strony i identyfikatory URI z ludźmi, miejscami i rzeczami oraz wdrażając scenariusze, w których te informacje można byłoby fizycznie wykryć poprzez skanowanie znaczników podczerwieni w środowisku. Chcielibyśmy pójść o krok dalej i zaproponować architekturę, która naprawdę uczyni inteligentne rzeczy częścią sieci, tak aby aktywnie służyły swojej funkcjonalności jako usługi sieciowe wielokrotnego użytku. W szeregu projektów zaproponowano rozwiązania mające na celu wyeksponowanie funkcjonalności inteligentnych rzeczy w celu budowania na nich aplikacji. Wśród nich JINI, UPnP, DNLA, itp. Pojawienie się WS- * Web Services (SOAP, WSDL itp.) Doprowadziło do szeregu prac mających na celu wdrożenie ich na urządzeniach wbudowanych i sieciach czujników . Pomagając w integracji z aplikacjami korporacyjnymi, rozwiązania te są często zbyt ciężkie dla urządzeń o ograniczonych możliwościach , nie ujawniają bezpośrednio funkcjonalności inteligentnych rzeczy w sieci, jak to robią architektury RESTful i nie są tak naprawdę luźno powiązane. Zaproponowano kilka systemów integracji systemów czujników z Internetem - na przykład SenseWeb i Pachube - które oferują platformę umożliwiającą ludziom udostępnianie swoich odczytów sensorycznych za pomocą usług internetowych do przesyłania danych na centralny serwer. W przeciwieństwie do sieci rzeczy, podejścia te opierają się na scentralizowanym repozytorium, a urządzenia są uważane za pasywne podmioty, które mogą jedynie przesyłać dane. Jednak koncentruje się głównie na wykrywaniu urządzeń, a nie na udostępnianiu ich funkcjonalności w sieci. Rozważmy wykorzystanie architektur typu REST w sieciach czujników. Opieramy się na tych podejściach i proponujemy systematyczną implementację ograniczeń RESTful oraz rozszerzamy model przy użyciu standardowej syndykacji internetowej, takiej jak Atom. Ponadto nie skupiamy się na niższym poziomie czujników, ale badamy aplikacje z punktu widzenia sieci. Proponujemy ujednolicony pogląd na dzisiejszą i przyszłą sieć rzeczy w aplikacjach zwanych "fizycznymi mashupami".

III. ARCHITEKTURA WEB OF THINGS

Realizacja sieci rzeczy wymaga rozszerzenia istniejącej sieci, tak aby obiekty ze świata rzeczywistego i urządzenia wbudowane mogły bezproblemowo wtapiać się w nią. Zamiast używać protokołów sieci Web wyłącznie jako protokołu transportowego - jak ma to miejsce na przykład w przypadku korzystania z usług internetowych WS- * - chcielibyśmy uczynić urządzenia integralną częścią sieci WWW, używając protokołu HTTP jako protokołu warstwy aplikacji. Głównym wkładem podejścia "Sieć rzeczy" jest zrobienie kolejnego logicznego kroku poza łącznością sieciową ustanowioną przez działania często określane jako "Internet rzeczy". Wiele działań w obszarze "Internetu rzeczy" kładzie nacisk na ustanowienie łączności na poziomie Internetu (często w zakresie TCP i / lub UDP), a następnie proponuje protokoły interakcji nakładane na tę podstawową łączność. Często protokoły te są zgodne z projektami RPC, wprowadzając własne funkcje, a tym samym wymagając od wszystkich użytkowników tych protokołów obsługi funkcji zapewnianych przez te platformy. Proponujemy podążanie za innym stylem architektonicznym i wykorzystanie pomysłu REST na jednolity interfejs, tak aby interakcje z inteligentnymi rzeczami można było budować wokół powszechnie obsługiwanych metod. Nie zakładamy, że urządzenia muszą oferować interfejsy RESTful dostarczane bezpośrednio przez każdą pojedynczą rzecz. W wielu przypadkach sensowne jest zabezpieczenie implementacji konkretnej platformy pod kątem specyfiki implementacji i ujawnienie zasobów udostępnionych przez tę platformę poprzez RESTful API. Interakcje za tym interfejsem RESTful są niewidoczne i często obejmują wysoce wyspecjalizowane protokoły dla określonego scenariusza implementacji. Ponieważ REST ma koncepcję pośredników jako rdzeń stylu architektonicznego, taki projekt można łatwo osiągnąć poprzez modelowanie usługi RESTful z wykorzystaniem pośredników. Używając serwerów proxy lub odwrotnych serwerów proxy , możliwe jest ponadto ustanowienie takiego pośrednika od klienta lub po stronie serwera, skutecznie wprowadzając solidny wzorzec, w jaki sposób usługi inne niż REST mogą być opakowane w abstrakcje RESTful.

A. Architektura rzeczy zorientowana na zasoby

REST to styl architektoniczny, co oznacza, że nie jest to określony zestaw technologii. W tym artykule skupiamy się na konkretnych technologiach, które wdrażają sieć jako system RESTful i proponujemy, w jaki sposób można je zastosować w sieci rzeczy. Główna idea REST obraca się wokół pojęcia zasobu jako dowolnego komponentu aplikacji, który należy wykorzystać lub rozwiązać. Zasoby mogą obejmować obiekty fizyczne (np. Czujniki temperatury) abstrakcyjne pojęcia, takie jak zbiory obiektów, ale także pojęcia dynamiczne i przejściowe, takie jak stan po stronie serwera lub transakcje. REST można opisać za pomocą pięciu ograniczeń:

C1 Identyfikacja zasobów: Sieć opiera się na jednolitych identyfikatorach zasobów (URI) do identyfikacji zasobów, dzięki czemu można ustanowić łącza do zasobów (C4) za pomocą dobrze znanego schematu identyfikacji.
C2 Uniform Interface: Zasoby powinny być dostępne poprzez jednolity interfejs z dobrze zdefiniowaną semantyką interakcji, podobnie jak Hypertext Transfer Protocol (HTTP). HTTP ma bardzo mały zestaw metod o różnej semantyce (bezpieczna, idempotentna i inne), co pozwala na efektywną optymalizację interakcji. Zdecydowana większość aplikacji internetowych oferuje interfejsy RESTful, podczas gdy backendy są implementowane przy użyciu różnych modeli interakcji (takich jak systemy baz danych) i to samo podejście można zastosować w przypadku sieci rzeczy.
Komunikaty samoopisujące C3: Uzgodnione formaty reprezentacji zasobów znacznie ułatwiają zdecentralizowanemu systemowi klientów i serwerów współdziałanie bez potrzeby indywidualnych negocjacji. W sieci WWW obsługa typów mediów w protokole HTTP i Hypertext Markup Language (HTML) umożliwia rówieśnikom współpracę bez indywidualnych umów. W przypadku usług zorientowanych na maszyny typy nośników, takie jak Extensible Markup Language (XML) i JavaScript Object Notation (JSON), zyskały szerokie wsparcie w usługach i platformach klienckich. JSON to lekka alternatywa dla XML, która jest szeroko stosowana w aplikacjach Web 2.0 i może być bezpośrednio analizowana z obiektami JavaScript.
Stan aplikacji C4 Hypermedia Driving: Klienci usług RESTful powinni podążać za linkami znalezionymi w zasobach w celu interakcji z usługami. Pozwala to klientom "eksplorować" usługę bez potrzeby stosowania dedykowanych formatów wykrywania i umożliwia klientom korzystanie ze standardowych identyfikatorów (C1) i dobrze zdefiniowanego procesu wykrywania typu nośnika (C3) do eksploracji usług. To ograniczenie musi być poparte reprezentacjami zasobów (C3) posiadającymi dobrze zdefiniowane sposoby, w jakie ujawniają linki, które można śledzić.
C5 Interakcje bezstanowe: Wymaga to, aby żądania od klientów były samodzielne, w tym sensie, że wszystkie informacje obsługujące żądanie muszą być częścią żądania. HTTP implementuje to ograniczenie, ponieważ nie ma żadnej koncepcji poza wzorcem interakcji żądanie / odpowiedź; nie ma pojęcia sesji lub transakcji HTTP. Należy zwrócić uwagę, że interakcja może być zaangażowana w stan, czy to w postaci informacji o stanie zawartej w żądaniu (pliki cookie HTTP), czy też w postaci stanu po stronie serwera, który jest powiązany z żądaniem zawartość (C3). Mimo że te dwa wzorce wprowadzają stan do usługi, sama interakcja jest całkowicie niezależna (nie zależy od kontekstu interpretacji), a zatem jest bezpaństwowa.

W protokole HTTP jednolite ograniczenie interfejsu (C2) ma cztery główne operacje: GET, PUT, POST i DELETE. W sieci rzeczy odwzorowują się one raczej naturalnie: GET służy do pobierania reprezentacji zasobu, np. aktualnego zużycia czujnika energii elektrycznej. PUT służy do aktualizowania stanu istniejącego zasobu lub tworzenia zasobu poprzez podanie jego identyfikatora. Na przykład może służyć do włączania i wyłączania diody. DELETE służy do usuwania zasobu. Można go na przykład użyć do usunięcia progu na czujniku lub do wyłączenia urządzenia. Wreszcie POST tworzy nowy zasób, np. tworzy nowy kanał używany do śledzenia lokalizacji oznakowanego obiektu. Łącząc ze sobą C2 i C3, HTTP obsługuje również negocjację treści, umożliwiając zarówno klientom, jak i serwerom komunikowanie się o żądanych i dostarczonych reprezentacjach dla dowolnego danego zasobu. Ponieważ negocjacja treści jest wbudowana w jednolity interfejs, klienci i serwery uzgodnili sposoby wymiany informacji o dostępnych reprezentacjach zasobów, a negocjacje pozwalają klientom i serwerom wybrać reprezentację, która najlepiej pasuje do danego scenariusza. REST jest aktywnym tematem badawczym, a złożone wzorce interakcji (np. Transakcje) nie zostały jeszcze ustalone jako specyfikacje lub wzorce projektowe. Chociaż cele projektowe systemów RESTful i ich zalety dla zdecentralizowanego i masowego systemu usług dobrze pokrywają się z dziedziną wszechobecnego przetwarzania danych: od milionów do miliardów dostępnych zasobów i luźno powiązanych klientów, z potencjalnie milionami jednoczesnych interakcji z jednym dostawcą usług. Na podstawie tych obserwacji twierdzimy, że architektury RESTful są najbardziej efektywnym rozwiązaniem dla Web of Things, ponieważ są lepiej skalowalne i bardziej niezawodne niż architektury oparte na RPC. Najważniejszym krokiem w każdym projekcie RESTful jest pierwszy krok polegający na zidentyfikowaniu wszystkich zasobów, które powinny zostać udostępnione, a dla sieci rzeczy same inteligentne rzeczy byłyby oczywiście głównymi kandydatami do tego celu. Jednak czasami te rzeczy nie istnieją same w sobie, ale w pewnych scenariuszach lub grupach, przez które są dostępne i zarządzane, co bardzo dobrze odzwierciedla koncepcję syndykacji opisaną w następnej sekcji.

B. Syndykowanie rzeczy

Jednym z częstych motywów wśród wielu scenariuszy z inteligentnymi rzeczami jest to, że istnieją zbiory rzeczy oparte na pewnych właściwościach lub tylko na scenariuszu aplikacji. Dzięki Atom, sieć ma ustandaryzowany i zgodny z REST model interakcji z kolekcjami, a Atom Publishing Protocol (AtomPub) rozszerza interakcje Atom w trybie tylko do odczytu o metody dostępu do zapisu w kolekcjach. Ponieważ Atom jest RESTful, interakcje z kanałami Atom mogą opierać się na prostych operacjach GET, które następnie mogą być buforowane. Bardziej zaawansowane scenariusze mogą opierać się na kanałach obsługujących funkcje zapytań, ale jest to aktywny obszar badań i nie ma jeszcze żadnych standardów . Atom umożliwia również obsługę scenariuszy asynchronicznych w WoT, w których klienci mogą monitorować inteligentne rzeczy, subskrybując źródła i pobierając serwer kanałów zamiast bezpośrednio pobierać dane z każdej inteligentnej rzeczy. Jednak wiele wszechobecnych scenariuszy musi dotyczyć informacji w czasie rzeczywistym. Jest to szczególnie przydatne, gdy trzeba połączyć przechowywane lub przesyłane strumieniowo dane z różnych źródeł w celu wykrycia wzorców przestrzennych lub czasowych, jak ma to miejsce w wielu aplikacjach do monitorowania środowiska. Protokół HTTP został zaprojektowany jako architektura klient-serwer, w której klienci mogą jawnie żądać (pobierać) danych i otrzymywać je jako odpowiedź. To sprawia, że REST dobrze nadaje się do kontrolowania inteligentnych rzeczy za pośrednictwem protokołu HTTP, ale te modele interakcji inicjowane przez klienta wydają się nieodpowiednie dla systemów opartych na zdarzeniach i przesyłania strumieniowego, w których dane muszą być wysyłane asynchronicznie do klientów natychmiast po ich wygenerowaniu. W przypadku scenariuszy wymagających bezpośredniego nacisku trwają obecnie różne prace badawcze. Jednym z nich jest model zwany Comet (nazywany również strumieniowaniem HTTP lub wypychaniem serwera) [19], który opiera się głównie na długotrwałych interakcjach HTTP i próbuje rozwiązać problem wyłącznie w oparciu o istniejącą infrastrukturę. Alternatywnym podejściem jest PubSubHubbub4, który zaczyna się od kanałów, a następnie dodaje warstwową infrastrukturę węzłów, które przekazują powiadomienia i akceptują subskrybentów. Na innym poziomie znajdują się zdarzenia wysyłane przez serwer5 HTML5, które umożliwiają otrzymywanie powiadomień push w zwykłych aplikacjach przeglądarkowych. Gniazda internetowe HTML56 zapewniają komunikację w pełnym dupleksie w postaci połączenia otwartego w przeglądarce internetowej i dostępnego za pośrednictwem interfejsu API JavaScript.

IV. PODŁĄCZANIE RZECZY DO INTERNETU

Aby inteligentne rzeczy stały się częścią sieci, możliwe są dwa rozwiązania: bezpośrednia łączność internetowa na urządzeniach lub przez proxy. Wcześniejsze prace wykazały, że wbudowane serwery internetowe na urządzeniach o ograniczonych zasobach są możliwe i jest prawdopodobne, że w najbliższej przyszłości większość platform wbudowanych będzie mieć natywną obsługę łączności TCP / IP (w szczególności z 6LowPAN ), dlatego serwer WWW na każdym urządzeniu jest rozsądnym założeniem. Takie podejście jest czasami pożądane, ponieważ nie ma potrzeby tłumaczenia żądań HTTP od klientów sieci Web na odpowiedni protokół dla różnych urządzeń, dzięki czemu urządzenia mogą być bezpośrednio zintegrowane i udostępniać ich interfejsy API RESTful bezpośrednio w sieci WWW, jak pokazano po prawej stronie na rysunku



Jednak gdy wbudowany serwer HTTP nie jest możliwy lub nie jest pożądany, integracja sieciowa odbywa się przy użyciu odwrotnego proxy, które łączy urządzenia, które nie komunikują się za pośrednictwem protokołu IP z siecią. Takie jak proxy nazywamy Smart Gateway, aby ująć fakt, że jest to komponent sieciowy, który robi więcej niż tylko przekazywanie danych. Smart Gateway to w rzeczywistości serwer sieci Web, który za pomocą RESTful API wyodrębnia rzeczywistą komunikację między urządzeniami a bramą (np. Bluetooth lub Zigbee) za pomocą dedykowanych sterowników. Z punktu widzenia klientów WWW rzeczywisty proces włączania sieci jest w pełni przejrzysty, ponieważ w obu przypadkach interakcje są oparte na protokole HTTP. Jako przykład rozważmy żądanie do węzła czujnika pochodzące z sieci WWW za pośrednictwem interfejsu API RESTful. Brama odwzorowuje to żądanie na żądanie w zastrzeżonym API węzła i przesyła je przy użyciu protokołu komunikacyjnego zrozumiałego dla węzła czujnikowego. Inteligentna brama może obsługiwać kilka typów urządzeń poprzez architekturę sterownika, jak pokazano na rysunku, gdzie brama obsługuje trzy typy urządzeń i odpowiadające im protokoły komunikacyjne. W idealnym przypadku bramy muszą mieć niewielką ilość pamięci, aby można je było zintegrować z wbudowanymi komputerami, które już znajdują się w budynkach, takich jak routery bezprzewodowe lub urządzenia Network Attached Storage (NAS).

V. PROTOTYPOWANIE SIECI RZECZY

W tej sekcji przedstawiamy kilka prototypów, które opracowaliśmy, aby zilustrować proponowaną architekturę sieci rzeczy.

A. Inteligentna bramka dla inteligentnych liczników

Z tym prototypem zaczynamy od zilustrowania zastosowania architektury WoT do monitorowania i kontrolowania zużycia energii w gospodarstwach domowych. Użyliśmy inteligentnych gniazd zasilających o nazwie Plogg, które mogą mierzyć zużycie energii elektrycznej przez podłączone do nich urządzenia. Każdy Plogg jest także bezprzewodowym węzłem czujnikowym, który komunikuje się przez Bluetooth lub Zigbee. Jednak interfejs integracyjny oferowany przez Ploggs jest zastrzeżony, co sprawia, że tworzenie aplikacji przy użyciu Ploggs jest raczej żmudne i nie pozwala na łatwą integrację w sieci. Architektura zorientowana na WWW, którą wdrożyliśmy przy użyciu Ploggs, jest oparta na czterech głównych warstwach. Pierwsza warstwa składa się z urządzeń, które chcemy monitorować i sterować za pośrednictwem systemu. W drugiej warstwie każde z tych urządzeń jest następnie podłączane do węzła czujnika Plogg. W trzeciej warstwie Ploggi są wykrywane i zarządzane przez Smart Gateway, jak opisano wcześniej. Ostatnią warstwą jest internetowy interfejs użytkownika. Ploggs Smart Gateway to wbudowany komponent, którego rolą jest automatyczne znajdowanie wszystkich Ploggów w środowisku i udostępnianie ich jako zasobów internetowych. Gateway najpierw regularnie wykrywa Ploggs, skanując otoczenie w poszukiwaniu urządzeń Bluetooth. Następnym krokiem jest udostępnienie ich funkcjonalności jako zasobów RESTful. Niewielki serwer sieciowy (Mongoose) umożliwia dostęp do funkcji Ploggów przez Internet. Odbywa się to poprzez mapowanie identyfikatorów URI na natywne żądania interfejsu API Plogg Bluetooth. Oprócz odkrywania Ploggów i mapowania ich funkcjonalności na adresy URL, brama ma dwie inne ważne cechy. Po pierwsze, oferuje lokalne agregaty usług na poziomie urządzenia. Na przykład bramka oferuje usługę, która zwraca łączne obciążenie elektryczne wszystkich podłączonych do niej Ploggów w dowolnym momencie. Drugą cechą jest to, że brama może reprezentować zasoby w różnych formatach. Domyślnie zwracana jest strona HTML z linkami do zasobów, aby zapewnić możliwość przeglądania. Korzystając z tej reprezentacji, użytkownik może dosłownie "nawigować" po strukturze inteligentnych liczników, aby zidentyfikować ten, którego chce użyć i bezpośrednio je przetestować, klikając linki (np. W przypadku metody HTTP GET) lub wypełniając formularze (np. Dla POST) metoda). Brama może również reprezentować zasoby jako wyniki JSON, aby ułatwić integrację z innymi aplikacjami sieci Web. Aby zilustrować, w jaki sposób stosujemy standardy HTTP i REST, opiszmy pokrótce przykład interakcji między aplikacją kliencką (np. Napisaną w AJAX) a inteligentną bramą RESTful firmy Ploggs. Najpierw klient kontaktuje się z głównym identyfikatorem URI aplikacji http://example.com/SmartMeters/ za pomocą metody GET. W rezultacie klient wraca do listy wszystkich SmartMeterów podłączonych do bramki. Wybór odpowiedniego formatu dla klienta następuje na etapie negocjacji treści (C2, C3), określonym w HTTP. Tak więc, wraz z żądaniem GET, klient ustawia pole Accept żądania HTTP na ważoną listę typów mediów, które może zrozumieć, na przykład: application / json; q = 1, application / xml; q = 0.5. Serwer spróbuje obsłużyć najlepszy możliwy format i opisze go w Content-Type odpowiedzi HTTP. Ponieważ wymagany format jest kluczowym parametrem, sugerujemy obsługę negocjacji treści bezpośrednio w URI, aby uczynić ją bardziej naturalną dla zwykłych użytkowników, bezpośrednio testowalną i podatną na zakładanie. Dlatego nasza brama obsługuje również żądania, takie jak http://example.com/SmartMeters.json. W drugim kroku klient wybiera urządzenie, z którym chce współpracować, identyfikowane za pomocą identyfikatora URI (C1): http://example.com/SmartMeters/RoomLamp.json. Wysyłając żądanie GET do tego zasobu, odzyskuje reprezentację JSON, jak pokazano poniżej. W wiadomości odpowiedzi poniższej klient znajduje dane dotyczące zużycia energii (np. bieżące zużycie, globalne zużycie itp.), a także hiperłącza do Powiązane zasoby. HTTP/1.1 200 OK Content-Type: application/json { "name": "RoomLamp", "watts": 60.52, "KWh": 40.3, "maxWattage": 80.56, "links": [{"aggregate": "../all"}, {"status": "/status"}, ...] } Korzystając z tych linków, klient może odkryć inne powiązane "usługi", spełniające ograniczenie (C4) i umożliwiające odkrywanie zasobów. Przykładowo, kontaktując się z http: //.../RoomLamp/status metodą OPTIONS ze standardu HTTP, klient odzyskuje metody dozwolone w zasobie stanu (np. Allow: GET, HEAD, POST, PUT). Wysyłając metodę PUT do tego identyfikatora URI wraz z reprezentacją JSON {"status " : "off" }, lampa zostaje wyłączona. Ogólnie rzecz biorąc, obsługa sieci Ploggs umożliwia budowanie w pełni internetowych aplikacji do monitorowania energii, ale także umożliwia proste, ale bardzo przydatne interakcje, takie jak tworzenie zakładek podłączonych urządzeń i możliwość ich włączania / wyłączania lub monitorowania z poziomu dowolnego urządzenia z przeglądarką internetową.

B. Bezpośredni dostęp i syndykacja bezprzewodowych sieci sensorowych

Platforma Sun SPOT to bezprzewodowa sieć czujników szczególnie nadająca się do szybkiego prototypowania aplikacji WSN (Wireless Sensor Networks). Każdy Sun SPOT posiada kilka czujników (światła, temperatury, akcelerometr itp.), Aktuatory (wyjścia cyfrowe, diody LED itp.) Oraz szereg elementów wewnętrznych (radio, bateria). Serwer WWW zgodny ze standardem REST służy do udostępniania czujników, elementów wykonawczych i komponentów wewnętrznych jako zasobów REST. Zaimplementowaliśmy dwie architektury integracji sieci Web przedstawione na pierwszym rysunku . W pierwszym przypadku wbudowany serwer internetowy działa na każdym węźle i obsługuje bezpośrednio protokół HTTP oraz (odwrotny) serwer proxy do przekazywania żądań HTTP z sieci WWW do SPOT, to jest z sieci IP sieci Web do sieci IEEE 802.15.4 Sun Spots i wzajemnie. W drugim przypadku - zwanym sterownikiem opartym na synchronizacji - korzystamy z idei Smart Gateway, która tłumaczy żądania REST na zastrzeżone protokoły. Inteligentna brama ma lokalną kopię urządzeń i minimalizuje faktyczną komunikację między urządzeniami a siecią poprzez lokalne buforowanie stanu urządzeń. W obu przypadkach dostęp do urządzeń jest przezroczysty przy użyciu rzeczywistych żądań HTTP. Podobnie jak w przypadku Ploggów, żądania usług są formułowane przy użyciu identyfikatorów URI (C1). Na przykład wpisanie adresu URL, takiego jak http: //.../spot1/sensors/light w przeglądarce, powoduje żądanie zasobu "światło" zasobu "czujnik" "spot1" z czasownikiem GET, który ilustruje, że naturalna struktura urządzeń wbudowanych całkiem dobrze odwzorowuje zasoby. Ograniczone możliwości obliczeniowe i magazynowe węzłów pozwalają na obsługę jedynie reprezentacji ich zasobów w formacie JSON. Aby uniknąć zbyt dużego obciążenia węzła, zaimplementowaliśmy również mechanizm dystrybucji dla czujników. Jak wspomniano wcześniej, to również lepiej pasuje do modelu interakcji sieci czujników. W ten sposób węzły mogą być kontrolowane (np. Włączanie diod LED, włączanie wyjść cyfrowych itp.) Za pomocą synchronicznych wywołań HTTP (pull klienta), ale jednocześnie mogą być monitorowane przez subskrybowanie kanałów (push węzła). Subskrypcja kanału polega na utworzeniu nowych "reguł" dotyczących zasobów czujników, np. Przez przesłanie POST progu i identyfikatora URI serwera Atom (Pub) na adres http: //.../spot1/sensors/light/rules. Za każdym razem, gdy próg zostanie osiągnięty, węzeł czujnika wypycha wiadomość JSON do danego serwera Atom za pomocą AtomPub. Pozwala to tysiącom klientów na monitorowanie pojedynczego czujnika poprzez outsourcing syndykacji na zewnętrzny, wydajny serwer.


Fizyczne mashupy

Wdrażając sugerowaną architekturę dla Ploggs i Sun SPOT, umożliwiamy bezproblemową integrację tych fizycznych rzeczy z siecią i udostępniamy nowy zakres aplikacji opartych na tym ujednoliconym widoku sieci. Uważamy te aplikacje za "fizyczne mashupy", w których technologie i wzorce Web 2.0 można zastosować do łatwego tworzenia aplikacji łączących zarówno zasoby wirtualne, jak i inteligentne rzeczy. Poniżej opiszemy dwie takie aplikacje.

1) Pulpit nawigacyjny uwzględniający zużycie energii: W tym pierwszym przykładzie stworzyliśmy mashup, aby odpowiedzieć na coraz ważniejszą potrzebę gospodarstw domowych, aby zrozumieć swoje zużycie energii i móc zdalnie go monitorować i kontrolować. Ideą projektu Energie Visible9 jest oferowanie internetowego pulpitu nawigacyjnego, który umożliwia ludziom kontrolowanie i eksperymentowanie z zużyciem energii przez ich urządzenia. Dzięki integracji Ploggs Web dashboard można zaimplementować przy użyciu dowolnego języka skryptowego. W tym konkretnym przypadku jest to aplikacja Google Web Toolkit (GWT), która jest solidną platformą do tworzenia stron typu mashup i oferuje dużą liczbę łatwo dostosowywalnych widżetów. Aby dynamicznie narysować wykresy zgodnie z bieżącym zużyciem energii, aplikacja musi jedynie regularnie wysyłać żądanie HTTP GET do bramki http://example.com/SmartMeters/all.json. Następnie przekazuje wynikowy dokument JSON do odpowiednich widżetów wykresów, które mogą bezpośrednio analizować JSON.
2) Fizyczny edytor typu mashup: zaawansowani technicznie użytkownicy mogą tworzyć aplikacje typu mashup w sieci Web za pomocą "edytora zespolonego", takiego jak Microsoft Popfly lub Yahoo Pipes. Te edytory zwykle dostarczają komponenty wizualne reprezentujące witryny sieci Web i operacje (dodawanie, filtrowanie), które użytkownik musi tylko połączyć, aby utworzyć nową aplikację. Chcieliśmy zastosować te same zasady, aby umożliwić użytkownikom tworzenie fizycznych mashupów bez konieczności posiadania jakichkolwiek umiejętności programistycznych. Nasza implementacja opiera się na projekcie Clickscript, wtyczce do Firefoksa napisanej na szczycie biblioteki Dojo AJAX do tworzenia stron typu mashup poprzez łączenie ze sobą zasobów (witryn internetowych) i operacji (większe niż, jeśli ... to, pętle itp.) . Ponieważ jest napisany w języku JavaScript, Clickscript nie może korzystać z zasobów opartych na usługach internetowych WS- * lub zastrzeżonych protokołach usług niskiego poziomu, ale może łatwo uzyskać dostęp do usług zgodnych z REST dostępnych w sieci WWW. Dlatego tworzenie bloków konstrukcyjnych (lub widżetów) Clickscript opartych na urządzeniach Web of Things jest proste, podobnie jak ich łączenie w mashupy. Mashup pokazany na rysunku pobiera temperaturę pokojową, pobierając źródło temperatury Sun SPOT.



Jeśli temperatura jest niższa niż 36 stopni Celsjusza, status PUT = wyłączony do Plogga, który wyłącza wentylator, do którego jest podłączony.

VI. OCENA

Nasze wyniki sugerują, że szczegółowość protokołu HTTP nie uniemożliwia implementacji wysoce wydajnych aplikacji, nawet gdy węzły bezprzewodowe o niskim poborze mocy komunikują się za pomocą protokołu HTTP zamiast wysoce zoptymalizowanych i skompresowanych wiadomości. W zastosowaniach, w których surowa wydajność i żywotność baterii są krytyczne, na przykład gdy węzły działają na baterii w dużych i długotrwałych wdrożeniach - jak to często ma miejsce w przypadku aplikacji sieci czujników bezprzewodowych - zoptymalizowane protokoły, które minimalizują połączenie sieciowe i opóźnienia pozostanie najlepszą opcją. Jednak gdy urządzenia są podłączone do źródła zasilania i można tolerować opóźnienie poniżej sekundy, zalety protokołu HTTP wyraźnie przewyższają utratę wydajności i opóźnienia. W wielu wszechobecnych scenariuszach ludzie są głównymi aktorami, którzy wchodzą w interakcję z cyfrowo rozszerzonymi środowiskami. W większości tych przypadków utrata wydajności jest prawie niewidoczna dla ludzi. Aby poprzeć to stwierdzenie, zaimplementowaliśmy prosty scenariusz, w którym użytkownik (na tej samej maszynie) wysyła żądanie GET w celu odczytania bieżącej wartości czujnika światła Sun SPOT znajdującego się jeden przeskok radiowy od bramy. Porównujemy dwie różne architektury opisane w sekcji IV i pokazujemy czas przesyłania w obie strony dla każdego żądania na rysunku.



W pierwszym przypadku każde żądanie jest kierowane przez serwer proxy do wbudowanego serwera HTTP działającego na zdalnym Sun SPOT, gdzie się znajduje. serwowane. W tym przypadku średni czas podróży w obie strony przez 10 000 kolejnych żądań wynosi 205 milisekund (min 97 ms, maks. 8,5 sekundy). W drugim przypadku używamy architektury opartej na synchronizacji - to znaczy każdy Sun SPOT okresowo wysyła odczyty swoich czujników do serwera proxy, gdzie są przechowywane lokalnie w pamięci podręcznej. Każde żądanie jest następnie obsługiwane bezpośrednio z tej pamięci podręcznej bez uzyskiwania dostępu do rzeczywistego urządzenia, w którym to przypadku średni czas przesyłania w obie strony wyniósł 4 ms (min. 2 ms, maks. 49 ms). Ma to tę zaletę, że całkowicie oddziela Sun SPOT od świata zewnętrznego, ponieważ wystarczy wysłać pakiet aktualizacji z częstotliwością dostatecznie krótką, aby zapewnić poprawność danych. Z drugiej strony, nieaktualność pobranych danych będzie zależeć od częstotliwości aktualizacji wysyłanych przez urządzenie, podczas gdy routing żądania HTTP ma tę zaletę, że zawsze zwraca najnowszy odczyt czujnika, gdy żądanie zostało przetworzone. Rysunek poinższy przedstawia wiek danych z czujnika (opóźnienie propagacji sygnału radiowego z wbudowanym serwerem oraz opóźnienie + czas od ostatniej aktualizacji za pomocą rozwiązania opartego na synchronizacji).



Wysokowydajne pamięci podręczne, które można łatwo skalować wraz z liczbą jednoczesnych żądań HTTP, są obecnie powszechne. Oznacza to, że korzystając z mechanizmu opartego na synchronizacji, tysiące klientów HTTP mogą jednocześnie pobierać dane z czujników z jednego urządzenia przy niezwykle krótkim czasie odpowiedzi, przy jednoczesnym zachowaniu aktualności danych zebranych w rozsądnych granicach dla wielu aplikacji. Oczywiście nie będzie to obowiązywać w przypadku żądań niebędących buforowaniem (zapisu), które muszą być wysyłane do urządzeń (np. włączanie diod LED, zmiana stanu aplikacji). Ponieważ wiele rozproszonych aplikacji monitorujących jest zwykle tylko do odczytu podczas pracy (czujniki zbierają dane, ale użytkownicy nie mogą zmienić ich statusu), nasza architektura wykazuje poziom skalowalności aplikacji wykrywających, który nie został wcześniej osiągnięty. Umożliwia to nowe typy aplikacji, w których fizyczne czujniki mogą być udostępniane tysiącom użytkowników przy niewielkim, jeśli w ogóle, wpływie na opóźnienia i nieaktualność danych, na przykład śledzenie transportu publicznego z dokładnością do sekundy.

a) Wczesna ocena jakościowa: Plogg RESTful Gateway i Sun SPOT były używane przez dwa zewnętrzne zespoły programistyczne, co wskazuje na niektóre korzyści jakościowe, jakie programiści mogą uzyskać dzięki proponowanej architekturze. W pierwszym przypadku chodziło o zbudowanie mobilnej aplikacji monitorującej zużycie energii w oparciu o iPhone′a i komunikującej się z Ploggami. W drugim przypadku celem było zademonstrowanie wykorzystania opartego na przeglądarce edytora JavaScript Mashup z usługami w świecie rzeczywistym. Według wywiadów, które przeprowadziliśmy z programistami, podobało im się korzystanie z inteligentnych rzeczy RESTful, w szczególności łatwość użycia internetowego "API" w porównaniu z niestandardowym "API". Dla aplikacji na iPhone′a nie istniało wówczas natywne API dla Bluetooth. Jednak, podobnie jak w przypadku prawie każdej platformy, dostępna była biblioteka HTTP (i JSON). Jeden z programistów wspomniał o krzywej uczenia się dla REST, ale podkreślił, że jest to nadal dość proste i że gdy się go nauczy, te same zasady mogą być używane do interakcji z dużą liczbą usług i prawdopodobnie wkrótce urządzeniami. W końcu zauważyli bezpośrednią integrację z przeglądarkami internetowymi jako jedną z najbardziej rozpowszechnionych korzyści.

VII. DYSKUSJA I OTWARTE WYZWANIA

Mashupy Web 2.0 znacznie obniżyły barierę wejścia dla rozwoju aplikacji internetowych. Z pewnością podejście zorientowane na zasoby nie jest uniwersalnym rozwiązaniem dla każdego problemu. Scenariusze z określonymi wymaganiami, takimi jak wysoka wydajność komunikacji w czasie rzeczywistym, mogą skorzystać na ściśle powiązanych systemach opartych na tradycyjnych podejściach opartych na RPC. Jednak w przypadku mniej ograniczonych aplikacji, w których wymagana jest interakcja ad-hoc i nieoczekiwane ponowne wykorzystanie, standardy sieciowe mogą uprościć integrację rzeczywistych danych z treścią internetową. Zastosowanie tych samych zasad projektowania, które przyczyniły się do sukcesu sieci - w szczególności otwartości i prostoty - wykorzystuje wszechstronność sieci jako wspólnej podstawy dla urządzeń i aplikacji sieciowych. Ponieważ większość urządzeń mobilnych ma już łączność internetową i przeglądarki internetowe, a większość języków programowania obsługuje protokół HTTP, korzystamy z ogromnej społeczności programistów internetowych, ponieważ potencjalni twórcy aplikacji dla sieci rzeczy i rzeczy fizycznych mogą być dodawane do zakładek, przeglądać, wyszukiwać i wykorzystywać tak jak każdy inny zasób sieciowy. Na podstawie naszego doświadczenia sugerujemy, że wady architektur sieci Web są w dużej mierze równoważone przez uproszczenie procesów projektowania, integracji i wdrażania, zwłaszcza w porównaniu z innymi protokołami dla urządzeń wbudowanych, takimi jak usługi sieciowe oparte na SOAP. Chociaż HTTP wprowadza narzut komunikacyjny i zwiększa średnie opóźnienie odpowiedzi, w wielu wszechobecnych scenariuszach ten narzut nie wpływa na doświadczenie użytkownika. Na przykład argumentowaliśmy , że wydajność korzystania z protokołu HTTP jako protokołu wymiany danych jest w większości wystarczająca dla typowych wszechobecnych scenariuszy, zwłaszcza gdy tylko kilku użytkowników uzyskuje dostęp do tego samego zasobu jednocześnie (odnotowano średni czas odpowiedzi 200 ms przy 100 równoczesnych użytkowników na serwerze 1,1 GHz). HTTP został zaprojektowany jako architektura, w której klienci inicjują interakcje. Ten model działa dobrze w aplikacjach zorientowanych na sterowanie, jednak aplikacje zorientowane na monitorowanie są często oparte na zdarzeniach, a zatem inteligentne rzeczy powinny również mieć możliwość wysyłania danych do klientów (zamiast ciągłego odpytywania). Korzystanie z protokołów syndykacji, takich jak Atom i AtomPub, poprawia model podczas monitorowania, ponieważ urządzenia mogą publikować dane asynchronicznie za pomocą AtomPub na serwerze pośrednim, niemniej jednak klienci nadal muszą pobierać dane z serwerów Atom. Adaptacja architektury klient-serwer jest obecnie głównym tematem badawczym społeczności internetowej . Normy takie jak HTML5 zmierza również w kierunku asynchronicznej komunikacji dwukierunkowej i kładzie nacisk na to, jak istotne jest dalsze poznanie lekkiego systemu przesyłania wiadomości oparte na sieci Web. Innym ważnym wyzwaniem dla globalnej sieci rzeczy jest wyszukiwanie i odkrywanie inteligentnych rzeczy. Rozważ miliardy rzeczy związanych z Internetem. Odkrycie poprzez przeglądanie stron HTML z hiperłączami staje się w tym przypadku dosłownie niemożliwe, stąd pomysł poszukiwania inteligentnych rzeczy. Wyszukiwanie rzeczy jest znacznie bardziej skomplikowane niż wyszukiwanie dokumentów, ponieważ rzeczy są ściśle powiązane z informacjami kontekstowymi, takimi jak lokalizacja, często przenoszą się z jednego kontekstu do drugiego, a ich reprezentacje HTML są mniej bogate w słowa kluczowe niż tradycyjne strony internetowe. Ten problem nie jest nieodłącznym elementem inteligentnych rzeczy, ale bardziej ogólnie jest problemem związanym z opisywaniem usług w sieci. Niedawne osiągnięcia w opisach semantycznych, które można osadzić w reprezentacjach HTML, takich jak Microformats lub RDFa, z pewnością pomogą w lepszym zrozumieniu usług oferowanych w sieci rzeczy.

VIII. WNIOSEK

W tym artykule opisujemy podstawy architektury Web of Things. Poprzez sformalizowanie różnych parametrów projektowych do rozważenia, zapewniamy użytkownikom praktyczne ramy do tworzenia własnych urządzeń i aplikacji WoT. Ilustrujemy konkretnymi przykładami, w jaki sposób można budować różne typy aplikacji na podstawie proponowanej architektury i proponujemy, w jaki sposób można zastosować pojawiające się techniki internetowe czasu rzeczywistego do tworzenia zgodnych z Internetem, wysoce interaktywnych i integrowalnych fizycznych mashupów. Na koniec zapewniamy wstępną analizę wydajności i dyskusje, aby wesprzeć przyszłe wysiłki badawcze, które sprawią, że sieć rzeczy stanie się rzeczywistością. PODZIĘKOWANIE Autorzy chcieliby podziękować Simonowi Mayerowi i Thomasowi Phamowi za ich pracę nad RESTful Sun SPOTs, a także http://www.microformats.org jako Lukas Naef za dostarczenie nam początkowego środowiska Clickscript.


Powrót