Przyśpieszenie prac nad aplikacjami IIoT - część 2: szybkie wdrożenie czujników IIoT

Uwaga od redakcji: w projektach tworzenia wbudowanych aplikacji często występują opóźnienia, ponieważ deweloperzy czekają na dostępność implementacji nowych urządzeń. Rozwój aplikacji przemysłowego Internetu rzeczy (IIoT) napotyka podobne trudności czekając na dane z czujników stosowanych na przykład w przemysłowych systemach utrzymania predykcyjnego lub systemach automatyzacji obiektów opartych na metodach uczenia się maszyn. W dwóch częściach niniejszego artykułu przeanalizowano alternatywne sposoby dostarczania strumieni danych niezbędnych do przyspieszenia rozwoju aplikacji IIoT.W części 1 opisano wykorzystanie metod symulacyjnych do generowania strumieni danych. Z kolei w części 2 omówiono możliwości szybkiego prototypowania systemów czujników służących do generowania danych.

Zastosowanie przemysłowego Internetu rzeczy (IIoT) na szeroką skalę zasadniczo zależy od analizy strumieni danych generowanych przez sieci czujników rozmieszczonych w środowisku docelowym oraz reakcji na nie. Bez gotowych strumieni danych na wczesnym etapie prac, proces tworzenia aplikacji IIoT może ulec opóźnieniom w stosunku do napiętego harmonogramu, a jego efekty mogą nie spełnić oczekiwań firmy.

Chociaż w przypadku wielu aplikacji metody symulacyjne mogą spełniać wymogi związane z pracą na danych, inne aplikacje mogą wymagać danych dokładnie odpowiadających środowisku docelowemu. W związku z tym uzyskanie skutecznych wyników symulacji może wymagać nieproporcjonalnie dużych nakładów wysiłku. Zastosowanie łatwo dostępnych czujników i bram otwiera potencjalnie łatwiejszą drogę do szybkiego dostarczania danych. Urządzenia te, zaprojektowane specjalnie dla środowisk przemysłowych, obsługują szeroki zakres typów czujników i opcji połączeń przy niewielkim nakładzie wysiłku użytkownika.

W niniejszym, drugim artykule z serii dotyczącej przyśpieszenia prac nad aplikacjami IIoT, opisano wiele typów wstępnie skonfigurowanych czujników i bram IIoT umożliwiających generowanie danych potrzebnych do przyspieszenia prac nad aplikacjami IIoT.

Ograniczenia symulacji danych IIoT

Dane z czujników mają zasadnicze znaczenie dla aplikacji IIoT, ale pełne ich wdrożenie zależy zarówno od dostępności systemu czujników dostarczających te dane, jak i od oprogramowania niezbędnego do przekształcenia ich w użyteczne informacje. W przypadku niektórych zastosowań IIoT symulacja może nie dostarczyć wystarczająco użytecznych danych. Jeśli nie zwrócimy wystarczającej uwagi na parametry symulacji, symulowane strumienie danych mogą wykazywać właściwości zniekształcające działanie aplikacji w kierunku konkretnego zakresu roboczego.

Na przykład, symulacja danych skonfigurowana tak, aby dostarczać dane o losowej temperaturze z równomiernym rozkładem w zakresie od -40°C do +125°C może zniekształcić działanie aplikacji w kierunku skrajnych wartości temperatury wykraczających poza rzeczywisty zakres temperatury otoczenia panujący w środowisku docelowym. Dodatkowo tego typu naiwna symulacja mogłaby również z łatwością dostarczyć dane dotyczące temperatury, które przeskakują o dziesiątki stopni między jednym pomiarem a drugim. W typowym zastosowaniu IIoT tak radykalne i nierealistyczne zmiany temperatury mogą wprowadzić chaos w pętli sterowania procesem i innych wynikach aplikacji.

Jakość danych i to, jak dobrze odzwierciedlają one realistyczne warunki, to czynniki, które mają szczególne znaczenie, jeżeli oczekujemy, że aplikacja będzie zawierała modele wnioskowania w ramach uczenia maszynowego. Naukowcy wyspecjalizowani w analizie danych rozumieją, że modele wnioskowania oparte na słabych danych dadzą równie słabe wyniki. W związku z tym nakłady wysiłku potrzebne do stworzenia efektywnych symulacji danych dla takich modeli mogą szybko wzrosnąć.

W większości projektów IIoT opóźnianie procesu tworzenia aplikacji do momentu wdrożenia systemów czujników po prostu nie wchodzi w grę. Oczekiwanie na rozmieszczenie czujników może być w rzeczywistości nawet niewykonalne, kiedy oczekuje się, że uruchomienie aplikacji ujawni potrzebne informacje lub uzasadni pełne wdrożenie. Na przykład, naukowcy wyspecjalizowani w analizie danych mogą potrzebować wyników złożonych algorytmów, żeby określić, czy do doprecyzowania niejednoznacznych wyników, a co za tym idzie zoptymalizowania aplikacji, potrzebne są dane o wyższej rozdzielczości, częstotliwości aktualizacji czy też wręcz dane z różnego rodzaju czujników.

Dlatego też organizacje niechętnie skłaniają się ku decyzji, że opóźnienie tworzenia aplikacji IIoT jest lepszym rozwiązaniem niż tworzenie aplikacji z wykorzystaniem danych symulowanych, które słabo reprezentują docelowy proces przemysłowy i docelowe środowisko. Na szczęście rosnąca dostępność gotowych systemów czujników IIoT i przypisanych do nich bram umożliwia organizacjom przy minimalnym nakładzie pracy szybkie wdrożenie najbardziej kluczowego zestawu czujników wymaganych do tworzenia aplikacji.

Szybkie wdrożenie sieci czujników

Czujniki IIoT zawierają czujniki, procesory i interfejsy połączeniowe w obudowie zaprojektowanej tak, aby wytrzymała obciążenia w typowym środowisku przemysłowym. Poza pojedynczymi czujnikami temperatury, drgań, ciśnienia i wilgotności, programiści mają do dyspozycji jednostki wielosensorowe składające się z czujników potrzebnych do konkretnych zastosowań, takich jak konserwacja zapobiegawcza.

Metody konserwacji zapobiegawczej monitorują właściwości służące jako wskaźniki potencjalnych usterek urządzeń. Na przykład w silnikach specyficzne zmiany częstotliwości drgań i temperatury świadczą o konkretnych rodzajach awarii. Zaprojektowane do wychwytywania tych danych, czujniki IIoT, takie jak czujnik konserwacji zapobiegawczej NCD (National Control Devices) PR55-20A, łączą wymagane czujniki z mikrokontrolerem o niskiej mocy i dostępem do bezprzewodowej sieci DigiMesh (ilustracja 1).

Ilustracja 1: czujnik konserwacji zapobiegawczej NCD PR55-20A zawiera wiele czujników z połączeniem do sieci mesh wymaganym do dostarczania danych do lokalnych węzłów bezprzewodowych. (Źródło ilustracji: National Control Devices)

Aby przyspieszyć proces tworzenia aplikacji IIoT, programiści mogą z łatwością połączyć specjalistyczne czujniki, takie jak czujnik konserwacji zapobiegawczej NCD, z innymi czujnikami, takimi jak bezprzewodowy czujnik środowiskowy NCD PR49-24G, który zawiera czujniki temperatury, wilgotności i gazu w jednym urządzeniu zasilanym dwiema bateriami AA.

Wraz z różnymi konkretnymi typami czujników IIoT producenci dostarczają gotowe bramki komunikacyjne zaprojektowane tak, aby uprościć integrację czujników z lokalnymi sieciami. Deweloperzy mogą korzystać z dostępnych bram, które są wstępnie skonfigurowane tak, żeby łączyły się z określonymi komercyjnymi chmurami albo żeby obsługiwały protokoły komunikacyjne powszechnie używane do łączenia się z platformami IoT w chmurze.

W przypadku bezprzewodowych czujników DigiMesh, seria bram NCD PR55-21 wykorzystuje połączenie Wi-Fi do połączenia się z określonymi usługami w chmurze, w tym Microsoft Azure IoT (PR55-21_AZURE), Amazon Web Services IoT (PR55-21_AWS) lub platformą Losant IoT (PR55-21_LOSANT). Ponadto brama PR55-21_MQTT obsługuje komunikację z dowolnym hostem za pomocą protokołu MQ Telemetry Transport (MQTT) w standardzie ISO. Podobnie jak inne produkty z serii PR55-21, brama PR55-21_MQTT zawiera przemysłowy mikrokontroler niskiej mocy oraz podsystemy do lokalnej łączności bezprzewodowej DigiMesh oraz do szyfrowanego połączenia Wi-Fi typu backhaul z lokalnym lub zdalnym serwerem MQTT (ilustracja 2).

Ilustracja 2: brama NCD PR55-21_MQTT obsługuje bezprzewodowe połączenie z lokalną siecią DigiMesh oraz wymianę wiadomości MQTT z serwerem poprzez połączenie Wi-Fi. (Źródło ilustracji: National Control Devices)

Deweloperzy mogą szybko skonfigurować sieć lokalną DigiMesh i połączenie Wi-Fi MQTT za pomocą narzędzia w menu dostarczanego w ramach wbudowanego serwera WWW bramki. Na przykład ekran urządzenia pokazuje urządzenia podłączone do sieci DigiMesh, jak również siłę ich sygnału i aktywność oraz stanowi centralny punkt zarządzania ich konfiguracją (ilustracja 3).

Ilustracja 3: wbudowany w bramę NCD PR55-21_MQTT serwer WWW pozwala użytkownikom na zmianę ustawień i badanie aktywności czujników podłączonych do sieci lokalnej. (Źródło ilustracji: National Control Devices)

Sieć mesh DigiMesh umożliwia skuteczne poszerzanie efektywnego zasięgu nadajniko-odbiorników niskiej mocy wymaganych w systemach czujników z zasilaniem bateryjnym. Jest to oczywiście tylko jedna z kilku opcji połączeń, które można spotkać w środowiskach przemysłowych, a producenci oferują podobne kombinacje czujników i bram dla wielu z nich. Na przykład seria Laird Sentrius RS1xx zawiera czujniki przemysłowe przeznaczone do obsługi łączności Bluetooth i LoRaWAN. Seria Sentrius RG1xx zawiera odpowiednie bramy komunikacyjne zaprojektowane tak, aby wspierały regionalne częstotliwości potrzebne do wdrożenia LoRaWAN. Ponadto bramy obsługują lokalne połączenia Bluetooth oraz bezprzewodowe łącze internetowe typu backhaul Wi-Fi.

W niektórych aplikacjach silne źródła zakłóceń elektromagnetycznych (EMI) mogą pogarszać integralność sygnału w komunikacji bezprzewodowej. W takich przypadkach ważną zaletą może być możliwość oddzielenia funkcjonalności komunikacyjnych od działania czujnika. Wraz z bezprzewodowymi czujnikami przemysłowymi firma Banner Engineering oferuje czujniki przeznaczone do podłączenia do oddzielnego węzła bezprzewodowego poprzez interfejs szeregowy RS-485 lub 1-Wire. W rezultacie operatorzy mogą umieścić bezprzewodowy węzeł komunikacyjny w pewnej odległości od czujnika podłączonego do silnego źródła EMI, takiego jak silnik wysokoobrotowy (ilustracja 4).

Ilustracja 4: w przypadku występowania znacznych zakłóceń elektromagnetycznych, takich jak pomiar drgań silnika, deweloperzy mogą podłączyć czujnik drgań firmy Banner Engineering do montażu na silniku z bezprzewodowym węzłem umieszczonym w pewnej odległości od źródła zakłóceń. (Źródło ilustracji: Banner Engineering)

Obsługujący tego typu konfigurację, węzeł bezprzewodowy DX80N9Q45VTP firmy Banner Engineering jest przeznaczony do połączenia z czujnikiem drgań i temperatury typu 1-Wire QM30VT1 tej samej firmy, natomiast węzeł bezprzewodowy DX80N9Q45TH łączy się z czujnikiem temperatury i wilgotności M12FTH4Q typu 1-Wire. Jeśli wymagania interfejsu czujników są szersze, DX80N9Q45U posłuży jako uniwersalny węzeł bezprzewodowy typu 1-Wire, a seria węzłów bezprzewodowych DX80G9M6S obsłuży połączenie czujników RS-485 z sieciami typu multihop.

Przetwarzanie lokalne

Nawet przy szybkim wdrożeniu sieci czujników IIoT programiści mogą być zmuszeni do uwzględnienia pewnego stopnia lokalnego przetwarzania danych w celu zmniejszenia ilości danych lub odciążenia dalszych zasobów przetwarzania. Zaawansowane czujniki przemysłowe, takie jak czujnik drgań i temperatury QM30VT2 firmy Banner Engineering, umożliwiają użytkownikom podział mierzonej częstotliwości drgań na nawet 20 pasm częstotliwości. Funkcja ta jest szczególnie ważna w aplikacjach konserwacji zapobiegawczej, gdzie zmiany w poszczególnych zakresach częstotliwości wskazują na określone rodzaje usterek.

Poza wstępnym przetwarzaniem danych przez czujniki, może się zdarzyć, że wczesne wdrożenie sieci czujników nałoży szereg wymagań dotyczących lokalnego przetwarzania danych. Kontroler i brama DXM700 firmy Banner Engineer dają tę możliwość. Urządzenie DXM700, o wymiarach zaledwie 70 x 86 x 55mm, oferuje wiele opcji lokalnych połączeń bezprzewodowych i przewodowych, a także połączenie Ethernet typu backhaul z serwerami macierzystymi (ilustracja 5).

Ilustracja 5: sterownik i brama DXM700 firmy Banner Engineering oferują wiele opcji połączeń lokalnych i internetowych, jak również obsługę lokalnego przetwarzania ScriptBasic. (Źródło ilustracji: Banner Engineering)

Jako że odbiera on dane z lokalnych sieci czujników, kontroler może uruchamiać programy napisane w języku ScriptBasic do badania danych wejściowych, aktywować wyjścia na podstawie danych na wejściu lub wykonywać proste transformacje danych. Dokumentacja Banner Engineering zawiera próbki w języku ScriptBasic ilustrujące typowe działania, takie jak reagowanie na zmiany w danych z czujników (Listing 1).

Copy   .
.
.
'Funkcja odczytu czujnika T/H FUNCTION GetTempHumidityData    LastValueTempC = TempC    LastValueHumidity = Humidity    Humidity =GETREG(SensorHumidity_reg, TH_SID, MBtype)    TempC = GETREG(SensorTempC_reg, TH_SID, MBtype)    IF Humidity > 65535 or TempC > 65535 THEN          PRINT "Błąd odczytu - odczyt wilgotności / temperatury...", Wilgotność"  ",TempC,"\n\r"    END IF    WrErr = SETREG (Humidity_reg, Humidity, LocalRegSID, MBtype)    WrErr = SETREG (TempC_reg, TempC, LocalRegSID , MBtype)   FUNCTION StateMachine 'Podać definicje do okresowego odczytu temperatury/wilgotności ' TH_State = 0  aktualny stan maszyny stanów ' TH_Idle= 0  stan początkowy ' TH_Wait= 1  czas oczekiwania między próbkami ' TH_Sample= 2  pobranie próbki ze zdalnego czujnika ' TH_Error= 3 stan błędu - stan nieznany    LOCAL StartState    StartState = TH_State    WrErr = SETREG (SM_reg, TH_State, LocalRegSID, MBtype)       IF TH_State = TH_Idle THEN           StartTime = NOW           TH_State = TH_Wait    ELSEIF TH_State = TH_Wait THEN       IF NOW >= (StartTime + WaitTime) THEN          TH_State = TH_Sample       ELSE          TH_State = TH_Wait       END IF    ELSEIF TH_State = TH_Sample THEN       GetTempHumidityData       TH_State = TH_Idle    ELSE       TH_State = TH_Error    END IF    IF StartState <> TH_State THEN       PRINT "\r\n Czas ",TERAZ,"  Start SM-> ",Stan TH[StartState],"  Koniec->",Stan TH[TH_State]," \r\n"    END IF END FUNCTION FUNCTION LED_driver IF LastValueTempC < TempC THEN    WrErr = SETREG (TempGoingUp_LED2_reg,1,DisplaySID, MBtype)    ELSE       WrErr = SETREG (TempGoingUp_LED2_reg,0,DisplaySID, MBtype)    END IF       IF LastValueTempC > TempC THEN    WrErr = SETREG (TempGoingDown_LED3_reg,1,DisplaySID, MBtype)    ELSE       WrErr = SETREG (TempGoingDown_LED3_reg,0,DisplaySID, MBtype)    END IF       IF (Humidity > 65535 ) OR (TempC > 65535) THEN    WrErr = SETREG (CommsError_LED4_reg,1,DisplaySID, MBtype)    ELSE       WrErr = SETREG (CommsError_LED4_reg,0,DisplaySID, MBtype)    END IF        IF GETREG(ScriptRunnning_LED1_reg, DisplaySID, MBtype) THEN       WrErr = SETREG (ScriptRunnning_LED1_reg,0,DisplaySID, MBtype)    ELSE       WrErr = SETREG (ScriptRunnning_LED1_reg,1,DisplaySID, MBtype)    END IF    END FUNCTION ‘Główna pętla programowa BEGIN:    PRINT „Start skryptu\r\n"    ITERATE:       'PRINT "\r\n Czas = „,TERAZ," \r\n"       StateMachine       LED_driver       Sleep(1)    GOTO ITERATE END 

Listing 1: powyższy fragment kodu ScriptBasic firmy Banner Engineering pokazuje, w jaki sposób można zaprogramować urządzenie DXM700 tak, aby reagowało lokalnie na dane z czujników, w tym przypadku włączając i wyłączając diody LED w odpowiedzi na zmiany w danych z czujników temperatury i wilgotności. (Źródło kodu: Banner Engineering)

Bramy takie jak te z serii Multi-Tech Systems MTCAP-Lxxx zapewniają jeszcze większą elastyczność w zakresie przetwarzania lokalnego. Zaprojektowane z myślą o spełnieniu różnorodnych wymagań w zakresie łączności, bramy z tej serii obsługują lokalne połączenia LoRaWAN po stronie czujników, a także połączenie Ethernet i opcjonalne szerokopasmowe połączenia LTE dla kanałów typu backhaul. Ta seria bram oparta jest na otwartym systemie operacyjnym Multi-Tech Linux (mLinux). Dlatego też programiści mogą tworzyć lokalne procedury oprogramowania przetwarzającego przy użyciu znanego im środowiska rozwojowego. Ponadto bramy te obsługują Node-RED, oferując opcję niskokodowego programowania, która jest przydatna w przypadku aplikacji sterowanych konkretnymi zdarzeniami, takich jak IIoT. Więcej na temat Node-RED w dalszej części tego artykułu.

Szybkie prototypowanie niskokodowe

Szybkie wdrożenie fizycznych sieci czujników może pomóc przyspieszyć proces tworzenia aplikacji IIoT poprzez dostarczenie źródła kluczowych danych na etapie znacznie wyprzedzającym projektowanie, opracowywanie i uruchamianie pełnych sieci czujników. Szybkie wdrożenie może być trudne, jeśli wiąże się z istotnymi wymaganiami dotyczącymi zabezpieczenia procesu tworzenia oprogramowania. Opisane powyżej wstępnie skonfigurowane czujniki i bramki IIoT pozwolą w wielu przypadkach na uniknięcie takiej sytuacji, ale specyficzne wymagania dotyczące danych, wykraczające poza możliwości czujników typu drop-in i bram, mogą pociągnąć za sobą wymagania dotyczące oprogramowania.

Aby spełnić opisane powyżej specyficzne wymagania dotyczące danych, platformy do szybkiego prototypowania, takie jak Arduino i Raspberry Pi oferują szeroką gamę specjalistycznych czujników i elementów wykonawczych, takich jak płytki rozszerzające. Łącząc i dopasowując takie płytki, deweloperzy mogą szybko zbudować prototyp, który spełni praktycznie wszystkie wymagania dotyczące danych z czujników.

W przypadku aplikacji IoT producenci ułatwili ich prototypowanie poprzez wprowadzenie płytek wielosensorowych o minimalnym zasięgu i możliwościach funkcjonalnych potrzebnych zazwyczaj w tych aplikacjach. Płytki rozwojowe, takie jak zestawy ewaluacyjne ON Semiconductor RSL10-SENSE-GEVK lub zestawy rozwojowe SensorTile STMicroelectronics STEVAL-STLKT01V1 integrują wysokowydajny procesor z szeroką gamą czujników zwykle wymaganych w urządzeniach ubieralnych i urządzeniach IoT. Na przykład SensorTile zawiera procesor STM32L4 firmy STMicroelectronics z nadajniko-odbiornikiem BLUENRG-MS również firmy STMicroelectronics oraz matrycę czujników, w skład której wchodzi czujnik ciśnienia mikroukładów elektromechanicznych (MEMS) LPS22HBTR, inercyjna jednostka pomiarowa MEMS (IMU) z przyspieszeniomierzem i żyroskopem LSM6DSMTR oraz e-kompas MEMS z czujnikami przyspieszenia liniowego i czujnikami magnetycznymi LSM303AGRTR (ilustracja 6).

Ilustracja 6: oparty na procesorze STM32L4 firmy STMicroelectronics, czujnik SensorTile stanowi elastyczną platformę sprzętową do budowy systemów czujników, które są w stanie spełnić wyjątkowe wymagania wykraczające poza te obsługiwane w gotowych systemach czujników IIoT. (Źródło obrazu: STMicroelectronics)

Popularne niskokodowe środowisko rozwojowe Node-RED pozwala deweloperom, poprzez rysowanie wykresów (przepływów) łączących elementy funkcjonalne (węzły), na programowanie takich płytek, jak również innych systemów sprzętowych, takich jak urządzenia NCD i bramy Multi-Tech. Przepływy te wiążą się z interakcjami pomiędzy węzłami odpowiadającymi określonym możliwościom funkcjonalnym, w tym z odczytywaniem danych z czujników, wykonywaniem operacji na danych, przesyłaniem danych do innych elementów funkcjonalnych, takich jak bramy chmury, oraz wyświetlaniem danych (ilustracja 7).

Ilustracja 7: środowisko rozwojowe Node-RED umożliwia tworzenie aplikacji poprzez łączenie węzłów pochodzących z rozległego repozytorium open source. (Źródło ilustracji: National Control Devices)

Dzięki ponad 225 tysiącom modułów dostępnych w repozytorium Node-RED open source, środowisko to oferuje bogaty ekosystem tworzenia aplikacji sterowanych zdarzeniami, takich jak aplikacje zbierające dane z czujników i przesyłające je do chmury. Choć środowisko Node-RED dostarcza metody integrowania przepływów w zastosowania produkcyjne, to fakt, że opiera się ono na Node.js może sprawić, że nie będzie odpowiednie dla niektórych aplikacji lub środowisk produkcyjnych.

DK IoT Studio firmy Digi-Key oferuje kolejne niskokodowe środowisko rozwojowe, które w dużej mierze eliminuje potrzebę ręcznego tworzenia oprogramowania, dostarczając jednocześnie kod źródłowy w języku C. Korzystając z DK IoT Studio, deweloperzy tworzą wymagane możliwości funkcjonalne, upuszczając na kanwie DK IoT Studio odpowiednie komponenty związane z każdą z funkcji SensorTile (ilustracja 8).

Ilustracja 8: DK IoT Studio firmy Digi-Key automatycznie generuje kod (po lewej stronie) z aplikacji utworzonych poprzez połączenie komponentów funkcjonalnych umieszczonych jako ikony na kanwie (po środku) i modyfikowanie związanych z nimi cech (po prawej stronie) w zależności od potrzeb. (Źródło ilustracji: Digi-Key/STMicroelectronics)

Poza obsługą konkretnych komponentów sprzętowych, środowisko to zapewnia podobne komponenty funkcjonalne związane z transferem danych do chmury lub działaniem zasobów chmury, które można upuścić na kanwę. Po narysowaniu wykresu opisującego przepływ danych i operacje, deweloperzy mogą pobrać wygenerowany kod w celu przesłania go do SensorTile. Podczas budowania typowych prototypów, proces ten nie wymaga opracowania dodatkowego kodu lub wymaga tego w ograniczonym zakresie. Więcej informacji o opisanym powyżej szybkim procesie tworzenia prototypów można znaleźć w artykule „Szybkie wdrożenie zasilanego bateryjnie wielosensorowego urządzenia IoT z certyfikatem Bluetooth 5”.

Podsumowanie

Tworzenie aplikacji IIoT na dużą skalę zależy w znacznym stopniu od dostępności danych, które wiernie odzwierciedlają środowisko docelowe. Jak zauważono w części 1, metody symulacyjne mogą spełniać wymagania dotyczące danych dla wielu aplikacji, podczas gdy inne mogą wymagać danych, które dokładnie odpowiadają środowisku docelowemu. W związku z tym uzyskanie skutecznych wyników symulacji może wymagać nieproporcjonalnie dużych nakładów wysiłku. Alternatywą są łatwo dostępne czujniki i bramki będące jeszcze prostszym sposobem na szybkie dostarczanie danych.

Jak wykazano w części 2 artykułu, urządzenia te obsługują szeroki zakres typów czujników i opcji połączeń przy niewielkim wysiłku użytkownika. Korzystając z tych produktów, deweloperzy mogą szybko wdrożyć sieci czujników zdolne do dostarczania danych wymaganych do przyspieszenia tworzenia aplikacji IIoT.