W miarę rozwoju Przemysłowy Internet Rzeczy (IIoT) podlega tym samym wyzwaniom integracyjnym, co poprzednie generacje automatyki. Poza zmieniającymi się wymaganiami mają tutaj zastosowanie różne technologie sprzętowe i oprogramowania oraz aplikacje. Obecnie, dzięki otwartym standardom, można połączyć jego różnorodne elementy w celu uzyskania odpowiednich rozwiązań.
W programowaniu produktów i aplikacji IIoT założenia programistów mogą obejmować:
→ wsparcie zróżnicowanych czujników i siłowników przez Internet,
→ zintegrowanie różnorodnych protokołów łączności przewodowej i bezprzewodowej, w tym LoRa, Sigfox, Wi-Fi, Bluetooth i innych,
→ instalację oryginalnego oprogramowania na różnych platformach sprzętowych, w tym MCU, x86/ARM CPU, GPU i innych, oraz różnych systemach operacyjnych, m.in. Microsoft Windows, Linux Distributions, mbed OS, Android,
→ przyłączenie usług w chmurze, takich jak WISE-PaaS, Microsoft Azure, IBM Bluemix i inne,
→ utrzymanie własności i integralności danych oraz rozumienie ich implikacji w zakresie prywatności i bezpieczeństwa, a także szybkie tworzenie stabilnych aplikacji,
→ stosowanie, aktualizowanie, ulepszanie i obsługę wielu urządzeń i usług,
→ przekształcanie danych typu Big Data w cenne informacje gospodarcze.
Tym samym produkt lub rozwiązanie IIoT musi sprostać wyzwaniom stawianym przed czujnikami, łącznością, bezpieczeństwem, usługami w chmurze, magazynowaniem, osprzętem urządzenia, konserwacją urządzenia, analizą końcową/w chmurze, integracją systemu, programowaniem aplikacji i tak dalej. Pierwszym wyzwaniem, przed jakim staje wiele firm, jest migracja do aplikacji IoT przy jednoczesnym zbilansowaniu takich parametrów, jak czas projektu, czas wprowadzenia na rynek oraz ryzyko.
Anatomia sieci
Dane IoT mogą mieć dużą objętość, podczas gdy aplikacje mają zazwyczaj wysokie wymagania w zakresie pracy w czasie rzeczywistym, stąd przesył olbrzymich ilości surowych danych stanowi duże obciążenie dla zasobów sieciowych. Dlatego zwykle wydajniejszym sposobem jest przetworzenie danych w pobliżu ich źródła i przesłanie wyłącznie cennej ich części do centrum w chmurze.
Edge computing to architektura rozproszonych zasobów IT, w ramach której dane klienta przetwarzane są na peryferiach sieci, jak najbliżej źródła, z którego pochodzą. Dane uwarunkowane czasowo (time-sensitive data) mogą być przetwarzane przez urządzenie inteligentne w punkcie ich pochodzenia lub przesyłane do serwera pośredniczącego, znajdującego się w niedalekiej odległości geograficznej. Dane mniej wrażliwe czasowo mogą być przesyłane do chmury w celu analizy historycznej, analizy typu Big Data bądź ich długoterminowego przechowywania.
Firmy muszą dysponować środkami do zarządzania paradygmatem edge computing niezależnie od tego, czy rozwiązaniem będzie infrastruktura, architektura, platforma czy serwer. Rozwiązanie, które firma Advantech określa jako serwer edge–intelligence (EIS), umożliwia lokalnym sieciom IIoT zastosowanie inteligencji na urządzeniach końcowych w celu zmaksymalizowania efektywności energetycznej, zmniejszenia zagrożenia prywatności, promocji prostoty wdrażania oraz modularyzacji i zminimalizowania opóźnień.
Usługi platformy oprogramowania IIoT oparte są na trzech głównych komponentach: węźle IIoT, serwerze edge-intelligence i usługach w chmurze. Poniżej opisano niektóre wybory z zakresu technologii, jakich każdy dostawca lub przedsiębiorstwo musi dokonywać w opracowywaniu swojej platformy.
W celu zaprogramowania urządzenia końcowego łączność w kierunku południowym czujnika musi obsługiwać różnorodne protokoły detekcyjne, takie jak OPC czy BACnet, oraz bezprzewodowy IP/NonIP. Protokoły te mogą być obsługiwane przez moduły wtyczkowe, które przetwarzają dane z czujnika, normalizację danych i komunikację.
Rozwiązanie obsługuje także łączność w chmurze „w górę” oraz inteligentną infrastrukturę, wykorzystując model kontenera mikrousługi w celu modularyzacji różnych połączeń w chmurze i umożliwienia zarządzania urządzeniem.
Podobnie inteligentna infrastruktura korzysta z architektury kontenera mikrousług, umożliwiając obróbkę napływających danych obejmującą ich wstępne przetwarzanie i czyszczenie.
Prawdopodobnie najcenniejszym narzędziem jest usługa analityczna czasu rzeczywistego na żądanie, która wydobywa zadane uprzednio właściwości danych w czasie rzeczywistym w miarę ich generowania. Przeglądy techniczne oraz utrzymanie najwyższej jakości służą do weryfikacji przewidywania obszaru końcowego. Stanowią one podstawowe ramy do rozbudowy modułów do analizy i przeglądów technicznych z wykorzystaniem otwartej normy architektury, w oparciu o wszechobecnie występujący protokół komunikacji MQTT oraz przy modularyzacji technologii kontenera Docker.
Pozostałe technologie, takie jak RESTful API, MQTT oraz Node-RED, umożliwiają zaprogramowanie aplikacji typu „przenieś i upuść”. Node-RED oraz narzędzie konfiguracyjne ułatwiają wdrożenie aplikacji niestandardowych. Ponadto dobrze udokumentowane SDK z przykładowym kodem MQTT oraz interfejsem RESTful API umożliwiają zaawansowanym programistom sprostanie wysokim wymaganiom.
Ostatnim komponentem są usługi w chmurze z komunikacją SSL/TLS oraz Intel Security, zarówno na urządzeniu końcowym, jak i w chmurze. Usługi danych oferują w standardzie PostgreSQL DB i Mongo NoSQL DB oraz obsługują standardowy interfejs integracyjny dzięki szerokiemu wyborowi produktów do przetwarzania i magazynowania danych. Strona internetowa pulpitu służy jako interfejs użytkownika aplikacji IoT, wyświetlając informację w przeglądarce lub na urządzeniu mobilnym dzięki narzędziom do wizualizacji, takim jak Azure Power BI lub Tableau.
W końcu platforma stanowi rynek udostępniania narzędzi programowych IoT, oferując czyste rozwiązania „chmurowe”, takie jak bazy danych, pulpit oraz narzędzia do nauki maszynowej.
Protokoły
Przyjrzyjmy się teraz nieco bliżej niektórym ze wspomnianych już technologii. MQTT to prosty, lekki protokół komunikacji publikacji/subskrypcji, wykorzystywany w odniesieniu do urządzeń ograniczonych oraz przy małej szerokości pasma, dużej latencji lub w sieciach niestabilnych. Usługa publikuje swoje zdolności i dane do brokera MQTT i subskrybuje określone tematy dla interfejsów wejściowych.
RESTful API definiuje zbiór funkcji, których programiści używają do wprowadzania zapytań i odbierania odpowiedzi przez protokoły HTTP, takie jak GET oraz POST. Ponieważ RESTful API wykorzystują do komunikacji protokół HTTP, mogą być wykorzystywane przez praktycznie każdy język programowania i są łatwe do testowania. RESTful API wymaga, aby klient i serwer pozostawały od siebie niezależne, co pozwala na zakodowanie klienta lub serwera w dowolnym języku oraz ich ulepszanie w razie konieczności, wydłużając tym samym żywotność systemu oraz usprawniając możliwość jego rozbudowy.
RESTful API określa zakres oferowanych funkcji oraz sposób użytkowania i wymaga samookreślenia wszystkich detali, takich jak parametry zapytań, forma odpowiedzi, ograniczenia zapytań, klucze publiczne/API, metody (GET/POST/PUT/DELETE), wsparcie językowe, użycie wywołań zwrotnych, wsparcie HTTPS oraz reprezentacje zasobów.
Właściwości podlegające ograniczeniom stylu architektury RESTful obejmują:
→ interakcje komponentów, które mogą stanowić dominujący czynnik w działaniach odczuwalnych przez użytkownika i wydajności sieci,
→ skalowalność obsługiwania dużej liczby komponentów oraz interakcji pomiędzy nimi,
→ prostotę ujednoliconego interfejsu,
→ modyfikowalność komponentów w celu dopasowania się do zmiennych potrzeb, także podczas pracy aplikacji,
→ widoczność komunikacji pomiędzy komponentami a agentem usług,
→ możliwość przenoszenia komponentów przez przemieszczanie kodu programu wraz z danymi,
→ odporność na awarie na poziomie systemu mimo awarii komponentów, złączy lub błędów danych.
Wzór architektury mikrousługi pozwala programiście na rozdzielenie aplikacji na grupy mniejszych, wzajemnie powiązanych usług, zamiast zastosowania pojedynczej i monolitycznej aplikacji. Usługa zwykle obejmuje różnorodne właściwości funkcji, takie jak zarządzanie łącznością, aplikacja pionowa i inne. Każda mikrousługa stanowi miniaplikację posiadającą własną architekturę, w tym logikę biznesową wraz z różnymi łącznikami.
Konteneryzacja to metoda wirtualizacji na poziomie systemu operacyjnego, bez uruchamiania całej maszyny wirtualnej (VM) dla każdej aplikacji. Zamiast tego mamy tutaj wiele izolowanych podsystemów, zwanych kontenerami, działających na jednym systemie kontrolnym hosta z dostępem do pojedynczego jądra. Kontenery mają to samo jądro systemu operacyjnego co host i są z reguły bardziej wydajne niż maszyny wirtualne, z których każda wymaga osobnej instancji systemu operacyjnego.
Kontener Docker obejmuje fragment oprogramowania w postaci niezależnego podsystemu, uzupełnionego o wszystkie właściwości wymagane do jego funkcjonowania: kod, czas pracy, narzędzia systemowe, biblioteki systemowe oraz wszelkie elementy, jakie można zainstalować na serwerze. Gwarantuje to zawsze identyczną pracę, niezależnie od środowiska.
Kontenery mają komponenty konieczne do obsługi wymaganej aplikacji, takie jak pliki, zmienne środowiskowe i biblioteki. System operacyjny hosta również ogranicza dostęp kontenera do zasobów fizycznych – takich jak CPU i pamięć – a zatem jeden kontener nie może zużyć wszystkich zasobów fizycznych hosta.
Jako źródło otwarte dostępny jest Node-RED, wdrożony przez IBM Emerging Technology. Obejmuje on edytor przepływu pracujący w oparciu o przeglądarkę, w prosty sposób łączący duży wybór węzłów na jednej palecie. Przepływy można następnie jednym kliknięciem zastosować dla czasu pracy. Przepływy utworzone w Node-RED przechowuje się przy wykorzystaniu JSON; można je importować i eksportować w celu współdzielenia z innymi. Edytor może pracować na krawędzi sieci lub w chmurze. Ekosystem menedżera pakietu węzła służy do rozszerzania palety dostępnych węzłów, umożliwiając połączenia z nowymi urządzeniami lub usługami.
Freeboard zapewnia prosty sposób wizualizacji głównych wskaźników eksploatacyjnych w czasie rzeczywistym. Ze względu na swoją prostotę, niewielki koszt, otwartość źródła oraz gotowość do rozbudowy narzędzie to otwiera wiele możliwości dla projektów IoT. Klienci mogą rozpocząć pracę za darmo, a we właściwym czasie wybrać plan, który najbardziej im odpowiada.
Układ architektury
Omawiany tutaj typ architektury można sklasyfikować w pięciu poziomach kategorii. Każdy z nich wdrażany jest jako osobna mikrousługa, przy użyciu brokera MQTT jako magistrali komunikacyjnej. Wszystkie mikrousługi są połączone z innymi mikrousługami lub klientami.
W czasie pracy każda instancja jest kontenerem Docker. Ułatwia to wdrożenie różnych doświadczeń dla określonych użytkowników, urządzeń lub przypadków specjalnego zastosowania.
1. Dolna warstwa architektury to warstwa łączności czujnika. Czujniki przewodowe obsługują różne funkcje, w tym kontrolę nadzoru i akwizycję danych (SCADA), Modbus oraz OPC UA. Warstwa łączności sieciowej gromadzi dane i zarządza centrami czujników.
2. Warstwa SDK oferuje usługi programowania, takie jak EIS RESTful API, usługę algorytmu predykcji błędów HDD itp. Programista może wywołać taką usługę poprzez RESTful API lub MQTT. Użytkownik może również dodawać własne usługi, takie jak platforma uczenia maszynowego, silnik bazy danych itp.
3. Warstwa przepływu ma Node-RED jako silnik projektowania przepływu danych wraz z dodatkami, takimi jak SUSI API, WSN i węzły predykcyjne HDD. Użytkownik projektuje ścieżki logiki poprzez proste operacje typu „przenieś i upuść” w środowisku graficznym.
4. Warstwa zarządzania i prezentacji interfejsu UI. Program Webmin do administrowania systemem i konfiguracji łączności IoT używa Node-RED-UI do prezentacji IoT/danych czujnika.
5. Warstwa chmury (Cloud) może zostać wcześniej zainstalowana, np. z WISE-Agent podłączonym do WISE–PaaS/serwera RMM Cloud.
Podsumowanie
Elastyczna i skalowalna architektura sprzętowo-programowa pomaga firmom w opracowywaniu złożonej infrastruktury IoT w zintegrowanym ekosystemie obsługującym rozmaite rynki wirtualne. Taka architektura powinna być dostosowana do użytkownika, łącząc w sobie kilka usług programowych. Następnie, w zależności od wymagań, można ją zainstalować na różnym sprzęcie.
Kurt Au jest menedżerem produktu w Advantech Embedded IoT Group.
