Azure IoT praktycznie

Autor 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.

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.

• 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.

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.

• 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.

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.