Azure IoT praktycznie

14

Andrzej KowalAutor tekstu: Andrzej Kowal.

Absolwent elektroniki na Politechnice Wrocławskiej. Przygodę z programowaniem rozpoczął od jezyka BASIC na Atari 800XL. Związany z platformą .NET od 10 lat. Obecnie tworzy oprogramowanie w oparciu o ASP.NET MVC, MSSQL oraz rozwiązania chmurowe (AWS, Azure). Od roku pracuje jako programista w Objectivity Bespoke Software Specialists (http://www.objectivity.co.uk).

Wprowadzenie

Według statystyk Google kariera Internet of Things (IoT) rozpoczęła się ok. 2013 roku. Obecnie jest to temat wciąż bardzo popularny, jednak niełatwo jest znaleźć informacje kompleksowo traktujące o systemach wykorzystujących technologie IoT do rozwiązania konkretnych potrzeb biznesowych. Ten wpis ma na celu przybliżenie technologii z obszaru IoT, które można wykorzystać do zbudowania i wdrożenia systemu produkcyjnego.

Analiza przypadku

Omawiany system został zbudowany w oparciu o następujący model biznesowy:

Firma PrintPrince zajmuje się wypożyczaniem drukarek sieciowych innym firmom. Opłaty za wypożyczenie opierają się głównie o liczbę wydrukowanych stron, w związku, z czym podstawowym zadaniem serwisu PrintPrince jest utrzymanie drukarek w dobrej kondycji i ciągłej gotowości do pracy. Obecnie PrintPrince używa systemu CRM do zarządzania flotą drukarek, jednak akcje serwisowe muszą być planowane manualnie, a ewentualny brak tonera lub usterki zgłaszane są przez użytkowników końcowych. Aby usprawnić proces, a także na bieżąco monitorować stan drukarek PrintPrince postanowił zbudować system do monitorowania, prognozowania i zarządzania drukarkami w oparciu o technologie z obszaru IoT. Kluczowe było to, aby system ten współpracował z istniejącymi rozwiązaniami używanymi przez PrintPrince.

Architektura

Architektura systemu oparta jest o chmurę Microsoft Azure.

clip_image001

Czarny kolor strzałek to główne kierunki komunikacji pomiędzy komponentami systemu. Kolorem czerwonym oznaczono komunikację zwrotną (komendy wysyłane do drukarek). Wykorzystane komponenty to:

  • IoT Hub – zapewnia dwukierunkową komunikację pomiędzy drukarkami a resztą systemu. Pozwala również na kontrolę dostępu do zasobów na poziomie pojedynczego urządzenia. Oznacza to w praktyce, że każde urządzenie musi zostać zarejestrowane w IoT Hub i otrzymuje swój unikalny identyfikator oraz klucz dostępowy.
  • Service Bus – w ramach tej usługi utworzone zostały 3 komponenty typu Event Hub (niebieskie klocki na diagramie). Pozwalają one na asynchroniczną komunikację pomiędzy różnymi elementami systemu. Działają w sposób podobny do kolejek na zasadzie „publish-subscribe”. Wspierają również tzw. grupy konsumentów, które umożliwiają dostarczanie z jednego strumienia wejściowego do wielu konsumentów.
  • Machine Learning – komponent ten jest odpowiedzialny za prognozowanie czasu pozostałego do wyczerpania tonera poszczególnych drukarek. Prognoza oparta jest o model wykorzystujący algorytm „Boosted Decision Tree Regression”. „Uczenie” modelu zostało przeprowadzone przy pomocy testowego zestawu danych zawierającego 6-miesięczną historię drukowania. Po każdym zgłoszeniu drukarki do systemu czas pozostały do wyczerpania tonera jest przeliczany. Do obliczeń wykorzystywany jest obecny stan tonera, liczba dni od ostatniej wymiany tonera oraz dzień tygodnia.
  • Stream Analytics – jest to usługa służąca do strumieniowego przetwarzania danych. Umożliwia ona odbieranie danych z kilku strumieni wejściowych, agregację i analizę danych oraz przesłanie ich do wielu strumieni wyjściowych. W omawianej architekturze wyjściami są:
    • Baza danych – rejestracja wszystkich zdarzeń
    • Event Hub odpowiedzialny za kanał zwrotny (wysyłanie komend do drukarki)

Komponent ten jest programowany bezpośrednio w portalu Azure w języku bardzo przypominającym T-SQL. Ciekawą opcją jest możliwość wykorzystania funkcji opublikowanej z poziomu komponentu Machine Learning. Dzięki temu każde zdarzenie (lub grupa zdarzeń) przechodzące przez system może zostać poddane analizie przy pomocy „nauczonego” modelu.

  • Baza danych – wszystkie zdarzenia przesyłane pomiędzy drukarkami a systemem są rejestrowane w tradycyjnej bazie danych Azure SQL.
  • Web App – w ramach tej usługi hostowana jest aplikacja ASP.NET MVC służąca jako dashboard dla serwisantów. Do jej stworzenia wykorzystano Bootstrap, SlickGrid, Leaflet.js. Uwierzytelnianie typu SSO jest zrealizowane przy pomocy biblioteki Microsoft.Owin.OpenId.

clip_image002

  • Web Jobs – służą do uruchamiania logiki operującej na zdarzeniach odbieranych z komponentów typu EventHub i ewentualnego przesłania komunikatu do innych części systemu. Są to wyspecjalizowane usługi podobne do mikroserwisów. Pracują one w tle jako Continuous Web Job w ramach odrębnej instancji Web App.

Poza chmurą Azure wykorzystano:

  • Microsoft Dynamics CRM – spełnia rolę głównego magazynu danych dla aplikacji webowej oraz wizualizacji Power BI. Są to informacje o klientach, drukarkach (a także ich statusie, lokalizacji czy historii usterek), wypożyczeniach oraz finansach. Dane operacyjne zbierane urządzeń są synchronizowane do tego systemu, tak aby CRM zawierał aktualne dane o stanie drukarek.
  • Microsoft Power BI – zaimplementowany został zestaw wizualizacji wspierający analityków oraz serwisantów drukarek w ich codziennej pracy.

clip_image003

Urządzenia

Zgodnie z nazwą IoT, to nie tylko Internet. Potrzebne są nam również „Things” – w tym przypadku drukarki sieciowe. Dość trudne byłoby testowanie oraz prezentowanie możliwości systemu z użyciem prawdziwych, drukujących i ulegających awariom drukarek. Wobec tego zaimplementowane zostały dwa rozwiązania:

  • Symulator webowy – podstrona dashboardu, która symuluje prawdziwe urządzenie (wysyła i odbiera komunikaty, zmienia stan interfejsu w zależności od odebranych komend). Udostępnia funkcję uzupełnienia tonera, wygenerowania losowej usterki, a także tryb pracy – polega on na rozpoczęciu drukowania przy przyspieszonym upływie czasu aż do wyczerpania tonera. Dzięki temu możliwe jest przetestowanie wielu cykli życia tonera w przeciągu kilkunastu minut.

clip_image004

  • Symulator fizyczny – składa się z Raspberry Pi, drukarki termicznej Pipsta oraz programu napisanego w pythonie. Ten element jest przygotowany głównie z myślą o prezentacji systemu. Sterowanie tą mini drukarką odbywa się za pomocą smartfona poprzez moduł NFC. Symulator ten ma podobne funkcjonalności do wersji webowej, natomiast dodaje nieco realizmu w postaci wydruków na papierze termicznym.

clip_image005

Jak to działa?

Poniżej opisane są podstawowe rodzaje komunikatów występujących w systemie.

Connect

Podłączenie drukarki do sieci (w przypadku symulatora wystarczy jego uruchomienie) rozpoczyna pętlę generującą zdarzenie co określoną ilość czasu. Zdarzenie to aktualizuje datę ostatniego zgłoszenia drukarki w systemie CRM (poprzez CRM Event Hub i CRM Event Processor). Dzięki temu posiadamy wiedzę o tym czy dana drukarka jest podłączona do sieci i poprawnie komunikuje się z systemem.

Status

W trakcie drukowania co jakiś czas wysyłany jest komunikat o stanie drukarki – zawiera on informację o ilości tonera, liczbie wydrukowanych stron, trybie drukowania. Dane te są rejestrowane w bazie SQL za pomocą dedykowanego wyjścia w komponencie Stream Analytics. Jednocześnie drugie wyjście podłączone do CRM Event Hub synchronizuje dane o stanie drukarki w systemie CRM (poprzez CRM Event Processor).

Refill

Innym rodzajem zdarzenia jest „Refill”. Ma miejsce, gdy na symulatorze zostanie naciśnięty przycisk „Refill”. W świecie rzeczywistym miałoby to miejsce, gdy serwisant fizycznie instaluje nowy zasobnik z tonerem. Zdarzenie to jest przetwarzane podobnie jak Status, ale dodatkowo w CRM zapisywana jest data ostatniego uzupełnienia tonera. Data ta jest potrzebna później komponentowi Machine Learning w celu ustalenia ile dni pozostało do opróżnienia tonera. Dostarczenie tej informacji do Stream Analytics odbywa się poprzez Printer Event Processor oraz Printer Event Hub.

Quality Update

Jest to komunikat, który wędruje kanałem zwrotnym, od chmury do drukarki. W istocie jest komendą, nakazującą drukarce zmianę trybu drukowania na ekonomiczny. Decyzję o wysłaniu tego komunikatu podejmuje Stream Analytics na podstawie bieżącego poziomu tonera. Jeśli poziom ten jest zbyt niski drukraka powinna zostać przełączona na tryb ekonomiczny, aby wydłużyć jej czas pracy. Zdarznie to jest przesyłane do wyjścia Stream Analytics, do którego podłączony jest Printer Control Hub. Następnie Printer Control Processor podejmuje ten komunikat i za pomocą IoT Hub wysyła go do odpowiedniej drukarki. Routingiem komunikatu zajmuje się IoT Hub – wystarczy podać odpowiedni identyfikator urządzenia, do którego komunikat ma trafić. Po stronie urządzenia komunikat musi zostać odpowiednio obsłużony. W przypadku dwóch opisanych emulatorów jest to bardzo proste, ponieważ mamy pełną kontrolę nad kodem sterującym cyklem życia emulatora. W przypadku emulatora webowego zmieniony zostaje wskaźnik trybu drukowania oraz kolor interfejsu na niebieski. W przypadku drukarki Pipsta nowy tryb drukowania zostaje zgłoszony za pomocą krótkiego wydruku. W świecie prawdziwych drukarek w tym miejscu przydatny byłby tzw. Gateway, który potrafiłby przetłumaczyć komunikat z IoT Hub na protokół komunikacyjny drukarki (SNMP) tak, aby fizyczna drukarka mogła zmienić swój tryb pracy.

Dodatkową możliwością jest wygenerowanie komunikatu „Quality Update” na żądanie z poziomu interfejsu dashboardu. Komunikat taki dodawany jest do Printer Control Hub. Od tego momentu całość działa identycznie jak w przypadku wygenerowania takiego komunikatu przez Stream Analytics. Pokazuje to skuteczność architektury systemu. Odpowiednia segregacja kanałów komunikacji z wykorzystaniem kilku komponentów Event Hub pozwala na szybką i relatywnie łatwą rozbudowę systemu.

Podsumowanie

W trakcie tworzenia systemu pojawiło się sporo wyzwań i problemów. Zarówno po stronie implementacji, jak i konfiguracji czy deploymentu. Azure okazał się być ciekawym środowiskiem, jednak nie obyło się bez komplikacji.

Szczególnym wyzwaniem przy tak mocno rozproszonej architekturze jest automatyzacja testów oraz provisioningu i deploymentu wszystkich komponentów i usług. W ramach Azure istnieje Resource Manager wspierający szablony w formacie JSON – jest to tzw. ARM Template. Niestety nie wszystkie komponenty da się w prosty sposób wyeksportować do JSONa – pozostaje szukanie szablonów w sieci i dostosowanie ich do swoich potrzeb. Kolejnym ograniczeniem jest fakt, że nie da się w prosty sposób całkowicie zautomatyzować skryptów Azure Powershell. Nowy zestaw commandletów (zawierających w nazwie Rm) wymaga za każdym razem zalogowania użytkownika w oknie przeglądarki. Pewnego rodzaju obejściem jest zapisanie profilu zalogowanego użytkownika do pliku, jednak profil taki wygasa po 3 miesiącach. Tylko niektóre usługi pozwalają na pobranie przy pomocy skryptu powershella loginu i hasła dla użytkownika, który ma prawo do deploymentu (np. Web App).

Inną kwestią jest sama implementacja i stopień rozproszenia. Mamy do czynienia z dość prostym systemem, a liczba komponentów jest dość duża. Jest to cena, jaką płacimy za asynchroniczność przetwarzania danych oraz za możliwość łatwej rozbudowy systemu na późniejszych etapach rozwoju. W trakcie pisania kodu należy mieć zawsze na uwadze fakt, że wiele operacji może wykonywać się równolegle w różnych aplikacjach i na wielu różnych bazach danych. Nie mamy do dyspozycji globalnych transakcji lub sekcji krytycznych chroniących wiele zasobów (chyba, że zaimplementujemy własne mechanizmy).

Patrząc z perspektywy czasu to właśnie powyższe wyzwania sprawiają, że projekty tego typu są ciekawe i motywują do zgłębiania kolejnych technologii i poznawania nowych narzędzi.

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

14 Comments

  1. Pingback: dotnetomaniak.pl

  2. Wow, poważna rzecz.

    Jak to jest z tymi drukarkami? Używacie jednej rodziny drukarek, która w zasadzie generuje te same komunikaty, czy używacie różnych rodzajów tychże drukarek i sprowadzacie komunikaty do pewnej wspólnej postaci, która może współpracować z waszym systemem?

    Jak wyciągnąć komunikat od drukarki? Udostępniają one jakiś interfejs do tego?
    Mam nadzieję, że nie namieszałem. :)

    • Andrzej Kowal on

      Używamy dwóch “rodzin” drukarek jednak skupiliśmy się głównie na części chmurowej systemu. (architektura, usługi Azure). W naszym demonstratorze po stronie “Things” mamy tylko symulatory (webowy i fizyczny) i nie musieliśmy przejmować się formatem komunikatów ani protokołami po stronie prawdziwych urządzeń (czyli tym, co jest “na lewo” od Azure IoT Hub). W prawdziwym świecie rodzajów drukarek będzie wiele. Każdy może wspierać inne formaty komunikatów a nawet inne protokoły (nie tylko SNMP). Całość byłaby spięta przez tzw. gateway (https://azure.microsoft.com/en-us/documentation/articles/iot-hub-protocol-gateway/). Dzięki temu gateway ogarnia różnorodność w dziedzinie “Things”, podczas gdy nasz system jest całkowicie “ustandaryzowany”, korzysta z jednolitego formatu komunikatów. Oczywiście może zajść konieczność doimplementowania czegoś zarówno po stronie gateway jak i po stronie chmury np. w przypadku gdy musielibyśmy obsłużyć nową rodzinę drukarek, która nie wspiera zmiany trybu drukowania. Natomiast obecna architektura powinna to bez problemu uciągnąć.

      Co do wyciągania komunikatów od drukarek – tutaj nie jestem ekspertem, odsyłam do specyfikacji poszczególnych modeli drukarek sieciowych :) Oparliśmy nasz demonstrator na pewnych założeniach np. takim, że każda drukarka w trakcie drukowania sama zgłasza swój status co jakiś czas.

      • Czy i jaka jest oszczędność wynikająca z zastosowania Azure w porównaniu do aplikacji hostowanej na własnych serwerach?
        Co było czynnikiem powodującym wybór Azure?

      • Andrzej Kowal on

        O oszczędności w koszcie samego zakupu i utrzymania serwerów nie jestem w stanie nic powiedzieć (za mało danych, całkiem inaczej będzie to wyglądało w produkcji). Natomiast na etapie wytwarzania softu na pewno jest spora oszczędność na korzyść Azure dzięki gotowym komponenty typu PaaS (IoT Hub, kolejki, machine learning, webapp). Dodatkowo do IoT Hub jest SDK na kilka platform (C, .NET, Java, node.js, Python) więc jest mniejszy próg wejścia przy tworzeniu softu na urządzenia.

  3. Jakub Piesik on

    Bardzo dobry artykuł, ale jedno pytanie: ile macie modeli drukarek? ;)

    • Andrzej Kowal on

      Dzięki. Mamy dwa modele drukarek: mała drukarka, i duża drukarka :) Te dwa typy drukarek nieco różnią się szybkością drukowania, zasobnością tonera itp. Widać to później na wykresach w Power BI po przeprowadzeniu kilku cykli symulacji i jest uwzględniane przy wyliczeniach w ML.

      • Jakub Piesik on

        Bo się zastanawiam co w przypadku gdy taka technologie wykorzystuje firma wypozyczajaca drukarki. I taka firma ma np. 45 roznych rodzajow drukarek ;)

      • Andrzej Kowal on

        Obecna architektura to obsłuży, natomiast oczywiście będzie “trochę” roboty po stronie gateway’a (patrz moja odpowiedź do komentarza Saszy).

      • Tylko po co firmie 45 modeli drukarek? Tu jest logicznie. Małe i duże. Np. A3 i A4. Jak firma zarabia 2-3 grosze na stronie wydruku to używa maszyn o minimalnych kosztach wydruku (duże tonery, duża trwałość bębnów itp).

  4. Fajny case. My robiliśmy podobne projekty w czasach kiedy nikt nie słyszał o IoT, Azure itp. W jednym z biur mojego klienta od lat mają wypożyczoną drukarkę i firma przez sieć ściąga sobie ilość wydrukowanych stron do rozliczeń i sprawdza stan tonerów. Gwarantuję, ze w firmie właściciela drukarki nikt nie słyszał o IoT :) Kiedyś to była po prostu integracja systemów.

    • Andrzej Kowal on

      Hehe :) W IT (a pewnie nie tylko) często się zdarza, że stare pomysły są odświeżane i co jakiś czas wracają w ładniejszym opakowaniu. Do takiego “pełnego” IoT brakuje nam jeszcze komunikacji pomiędzy samymi urządzeniami (bo przecież telemetrię i zarządzanie predykcyjne w naszym demonstratorze już mamy).

  5. tomaszk-poz on

    Rany Jurek wszędzie wpychają to IoT, to już się robi obrzydliwe na nowo sprzedawanie tego samego. Już wieki temu czytałem o publicznych automatach do Coca-Coli prezentujących przez telnet, w którym slocie brakuje puszki (takie ascii -art).

    Zastanawiam sie, czy jest bezpieczne opieranie sie na technologiach Microsoft, ostatnio publikowali co nowego w Net Core i nie było zbyt cudownie, tak więc mamy: WIn10 – bieda, WinPhone-uwalone, przenośne Net – braki.