Przyśpieszenie prac nad aplikacjami przemysłowego IoT - część 1: Symulacja danych urządzeń IoT

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. 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 dużą skalę jest źródłem wielu wyzwań, które mogą wstrzymać wdrożenie produktu i postawić pod znakiem zapytania zwrot z inwestycji w zasoby niezbędne do przeprowadzenia procesu wdrożenia. Aby zapobiec takim sytuacjom i pomóc deweloperom w szybszym identyfikowaniu korzyści płynących z wdrożenia IIoT, niezbędny jest dostęp do danych umożliwiających przeprowadzenie symulacji wdrożenia.

Wykorzystując metody symulacji do generowania realistycznych strumieni danych, deweloperzy mogą rozpocząć tworzenie aplikacji IIoT na długo przed wdrożeniem sieci IoT, a nawet udoskonalić definicję samej sieci czujników IIoT.

W niniejszym artykule pokazano w jaki sposób różne platformy IoT w chmurze umożliwiają symulację danych oraz przedstawiono przykładowe bramki firmy Multi-Tech Systems Inc., które mogą jeszcze bardziej przyspieszyć proces wdrożenia.

Kiedy wykorzystuje się symulację danych IIoT

Wykorzystanie symulowanych danych do tworzenia zastosowań i systemów napędowych nie jest oczywiście niczym nowym. Deweloperzy od dziesięcioleci stosują metody symulacji na poziomie systemowym do testowania infrastruktury obliczeniowej i usług łączności. Testy te pełnią ważną funkcję w sprawdzaniu odporności konfiguracji statycznych. Testy przeprowadzane w ramach platform usług w chmurze stanowią stosunkowo prostą metodę weryfikacji autoskalowania maszyn wirtualnych i innych zasobów chmury.

Wymagania dotyczące aplikacji IIoT są na tym samym, jeśli nawet nie na wyższym poziomie. Poza tym, że stanowi narzędzie używane w testowaniu obciążenia i autoskalowaniu, symulacja danych jest również wykorzystywana do weryfikowania integracji wielu różnych usług i zasobów potrzebnych do wdrożenia oprogramowania tak złożonego jak zastosowanie IIoT na poziomie przedsiębiorstwa. Oprócz podstawowych funkcji, symulacje danych mogą przyspieszyć rozwój złożonych zastosowań IIoT opartych na zaawansowanych platformach usługowych dostępnych u wiodących dostawców usług w chmurze.

Z perspektywy oprogramowania

Aplikacje IIoT działają na złożonych architekturach, które z perspektywy deweloperów oprogramowania aplikacji wyglądają zupełnie inaczej niż z perspektywy deweloperów systemów czujników i elementów wykonawczych. W przypadku tych ostatnich architektura IIoT na dużą skalę jawi się jako rozległy zespół czujników i elementów wykonawczych, które współdziałają z procesami fizycznymi, będącymi przedmiotem aplikacji. Dla deweloperów oprogramowania aplikacji architektura IIoT na poziomie przedsiębiorstwa obejmuje szereg usług, których skoordynowane działanie skutkuje zapewnieniem funkcjonalności aplikacji.

Architektura referencyjna Microsoft Azure IoT daje możliwość zapoznania się z reprezentatywnym obrazem typowych aplikacji IIoT (i zastosowania IoT w ogóle) z perspektywy oprogramowania aplikacji. Perspektywa ta stanowi podsumowanie wielu usług funkcjonalnych, które typowa aplikacja łączy w chmurze w celu dostarczenia informacji i działań opartych na danych z punktu końcowego i urządzeń brzegowych (ilustracja 1).

Ilustracja 1: architektura referencyjna Microsoft Azure IoT ilustruje wiele typów usług i zasobów chmury, których aplikacja IIoT wymaga zazwyczaj, aby dostarczyć użytecznych informacji i podjąć działania na podstawie danych generowanych przez sieci urządzeń brzegowych. (Źródło ilustracji: Microsoft Corp.)

Poszczególne rozwiązania wykorzystują zasoby chmury w odpowiednich kombinacjach, połączone funkcjonalnie poprzez znormalizowane mechanizmy wymiany i koordynowane przez układ logiczny aplikacji. Na przykład Amazon Web Services (AWS) w swoim rozwiązaniu zwanym „connected vehicle” (pojazdy połączone z Internetem) sugeruje, w jaki sposób usługi w chmurze mogą być łączone i dopasowywane w ramach modułów odpowiedzialnych za zapewnienie dostępu do różnych funkcji i możliwości zastosowania (ilustracja 2).

Ilustracja 2: rozwiązanie AWS „connected vehicle” daje możliwość zapoznania się z typowym mechanizmem zgrania na dużą skalę w chmurze aplikacji IoT usług mających zagwarantować dostęp do potrzebnych funkcjonalności. (Źródło ilustracji: Amazon Web Services)

Jak widać z przedstawionych powyżej architektur, rozwój oprogramowania aplikacji IIoT jest tak samo wymagający i ekspansywny jak wdrożenie obwodowych sieci systemów czujników i elementów wykonawczych. Niewiele organizacji może sobie pozwolić na opóźnianie rozwoju tego skomplikowanego oprogramowania do czasu, aż sieć urządzeń będzie w stanie wygenerować wystarczającą ilość danych. Wdrożenie sieci urządzeń może wymagać oczekiwania na dalsze procesy definiowania i udoskonalania, które mogą pojawić się w miarę postępowania prac analityków i ekspertów od uczenia maszynowego nad wynikami aplikacji. W najgorszym przypadku wdrożenie sieci urządzeń i rozwój oprogramowania utkną w martwym punkcie, jako że każde z nich będzie zależne od wyników drugiego.

Na szczęście rozwiązanie tego dylematu leży w istocie architektur IoT. Architektury usług w chmurze, takie jak te przedstawione powyżej z Microsoft i AWS, oczywiście różnią się pod wieloma względami, choć w dużej mierze są do siebie podobne. Wszystkie one wykazują podobną cechę architektoniczną typową dla platform IoT w chmurze: dobrze zdefiniowany moduł interfejsu usługi lub funkcjonalność warstwy, która oddziela sieć peryferyjną urządzeń IoT od oprogramowania aplikacji opartego na chmurze. Interfejsy usług nie tylko zapewniają jednolitą łączność, ale są również niezbędne do zarządzania urządzeniami i zabezpieczeniami, jak również innymi kluczowymi funkcjami wymaganymi w zastosowaniach IIoT na dużą skalę.

W chmurze Microsoft Azure, interfejs usługi nazywa się Azure IoT Hub (ilustracja 1), a w chmurze AWS jest to AWS IoT Core (ilustracja 2). Na platformie Google Cloud interfejs ten to Cloud IoT Core, a w IBM Cloud to IBM Watson IoT Platform Service. Inne platformy, takie jak ThingWorx IoT Platform, łączą się w podobny sposób, wykorzystując usługi takie jak ThingWorx Edge Microserver, ThingWorx Kepware Server lub zestawy narzędzi adapterów protokołu. Krótko mówiąc, każda platforma w chmurze musi zapewniać spójny interfejs usługi, który przekazuje dane z peryferii do usług w chmurze. W przeciwnym wypadku istnieje ryzyko wystąpienia plątaniny połączeń bezpośrednio między urządzeniami peryferyjnymi a poszczególnymi zasobami w głębi chmury.

Wprowadzanie symulowanych danych

Korzystając z zestawu rozwojowego oprogramowania (SDK) dostępnego dla każdej platformy IoT, deweloperzy mogą wprowadzać symulowane dane z czujników bezpośrednio do interfejsu usługi platform z zachowaniem poziomów ilości, prędkości i różnorodności potrzebnych do weryfikacji funkcjonalności i wydajności aplikacji. Symulowane dane generowane z żądaną szybkością i rozdzielczością dostarczane są do interfejsu usługi za pomocą standardowych protokołów, takich jak MQ Telemetry Transport (MQTT), Constrained Application Protocol (CoAP) i innych. Interfejs usługi (i oprogramowanie aplikacji) nie odróżnia symulowanych strumieni danych od danych pozyskanych przez sprzętowy system czujników. Gdy sieci urządzeń są gotowe do uruchomienia, strumienie danych z czujników po prostu zastępują symulowane strumienie danych dostarczane do interfejsu usługi.

Dostawcy platform w chmurze zazwyczaj wspierają takie podejście wykorzystujące symulację danych na różnych poziomach. Na przykład Google demonstruje proste zastosowanie oparte na symulacji z architekturą referencyjną i przykładowym kodem, które stosuje prostą pętlę sterowania wentylatorem sterowanym temperaturą. Podobnie jak wcześniej przedstawione architektury, również ta wykorzystuje usługi Google Cloud Platform zasilanej przez interfejs usługi Google Cloud IoT Core (ilustracja 3).

Ilustracja 3: na każdej platformie IoT w chmurze, symulatory urządzeń wykorzystują te same protokoły komunikacyjne, które są wykorzystywane przez urządzenia fizyczne do przekazywania danych do interfejsu usługi takiej jak Google Cloud IoT Core dla przedstawionej architektury aplikacji Google Cloud Platform. (Źródło ilustracji: Google)

W tej przykładowej aplikacji symulatory czujników temperatury generują dane z wybraną szybkością aktualizacji i przekazują je do interfejsu usługi Google Cloud IoT Core za pomocą protokołu komunikacyjnego MQTT. Z kolei interfejs usługi wykorzystuje standardowe protokoły publikowania/subskrybowania komunikatów (pub/sub) platformy do przekazywania danych do symulowanego serwera, który odpowiada poleceniem włączenia lub wyłączenia wentylatora w zależności od potrzeb (ilustracja 4).

Ilustracja 4: przykładowa aplikacja Google pokazuje podstawową pętlę sterowania składającą się z symulowanego urządzenia, które wysyła dane przez Google Cloud IoT Core do symulowanego serwera za pomocą standardowych metod komunikacji. (Źródło ilustracji: Google)

Google dostarcza też przykładowy kod Python, który wdraża podstawową aplikację. W ramach tego kodu wystąpienie klasy Device zawiera metodę, która aktualizuje symulowaną temperaturę w oparciu o stan symulowanego wentylatora. Główny algorytm wywołuje tę metodę z określoną szybkością i wysyła dane za pomocą usługi połączenia MQTT dostarczanej przez moduł klienta Eclipse paho-mqtt Python MQTT (listing 1).

Kopiuj
class Device(object):
     """Represents the state of a single device."""

    def __init__(self):
         self.temperature = 0
         self.fan_on = False
         self.connected = False

    def update_sensor_data(self):
         """Pretend to read the device's sensor data.
        If the fan is on, assume the temperature decreased one degree,
        otherwise assume that it increased one degree.
        """
         if self.fan_on:
             self.temperature -= 1
         else:
             self.temperature += 1
.
.
.
def main():
.
.
.
    device = Device()


    client.on_connect = device.on_connect
     client.on_publish = device.on_publish
     client.on_disconnect = device.on_disconnect
     client.on_subscribe = device.on_subscribe
     client.on_message = device.on_message


    client.connect(args.mqtt_bridge_hostname, args.mqtt_bridge_port)


    client.loop_start()


    # This is the topic that the device will publish telemetry events
     # (temperature data) to.
     mqtt_telemetry_topic = '/devices/{}/events'.format(args.device_id)


    # This is the topic that the device will receive configuration updates on.
     mqtt_config_topic = '/devices/{}/config'.format(args.device_id)


    # Wait up to 5 seconds for the device to connect.
     device.wait_for_connection(5)


    # Subscribe to the config topic.
     client.subscribe(mqtt_config_topic, qos=1)


    # Update and publish temperature readings at a rate of one per second.
     for _ in range(args.num_messages):
         # In an actual device, this would read the device's sensors. Here,
         # you update the temperature based on whether the fan is on.
         device.update_sensor_data()


        # Report the device's temperature to the server by serializing it
         # as a JSON string.
         payload = json.dumps({'temperature': device.temperature})
         print('Publishing payload', payload)
         client.publish(mqtt_telemetry_topic, payload, qos=1)
         # Send events every second.
         time.sleep(1)


    client.disconnect()
     client.loop_stop()
     print('Finished loop successfully. Goodbye!')

Listing 1: ten fragment z przykładowej aplikacji Google ilustruje, jak algorytm main okresowo aktualizuje wystąpienie klasy Device, które przechowuje aktualną wartość symulowanego czujnika temperatury i umożliwia wykorzystanie metody, która aktualizuje tę wartość w zależności od stanu symulowanego wentylatora. (Źródło kodu: Google)

Z kolei wystąpienie klasy Server dostarcza moduł, który aktualizuje stan wentylatora w zależności od danych temperaturowych otrzymanych z wystąpienia klasy Device (listing 2).

Kopiuj
class Server(object):
     """Represents the state of the server."""
.
.
.
    def _update_device_config(self, project_id, region, registry_id, device_id,
                               data):
         """Push the data to the given device as configuration."""
         config_data = None
         print('The device ({}) has a temperature '
               'of: {}'.format(device_id, data['temperature']))
         if data['temperature'] < 0:
             # Turn off the fan.
             config_data = {'fan_on': False}
             print('Setting fan state for device', device_id, 'to off.')
         elif data['temperature'] > 10:
             # Turn on the fan
             config_data = {'fan_on': True}
             print('Setting fan state for device', device_id, 'to on.')
         else:
             # Temperature is OK, don't need to push a new config.
             return

Listing 2: w tym fragmencie z przykładowej aplikacji Google, metoda_update_device_config() zdefiniowana w klasie Server (Serwer) dostarcza aplikacji warstwę logiki biznesowej, ustawiając wentylator w pozycji włączonej, gdy temperatura wzrośnie powyżej zdefiniowanej wartości i ustawiając wentylator w pozycji wyłączonej, gdy temperatura spadnie. (Źródło kodu: Google)

Oprócz przykładowego kodu Google deweloperzy mogą znaleźć dziesiątki symulatorów typu open source dla urządzeń, systemów i sieci IoT na repozytoriach takich jak GitHub. Na przykład kod symulatora systemu Raspberry Pi firmy Microsoft typu open source zawiera wbudowaną integrację z Azure IoT Hub w celu szybkiego rozwoju w chmurze aplikacji, które współpracują z płytkami Raspberry Pi. Ponadto niskokodowe narzędzia do programowania, takie jak Node-RED, obsługują wbudowane moduły (węzły) do przekazywania symulowanych danych z czujników do wiodących interfejsów usług platformy IoT w chmurze. Korzystając z tych metod, deweloperzy mogą łatwo generować strumień danych z czujników.

Przeprowadzanie symulacji na dużą skalę

Trudność w użyciu symulatorów na poziomie urządzeń i związanych z nimi narzędzi polega na tym, że zarządzanie symulacją danych może samo w sobie stać się dużym projektem. Aby uruchomić symulatory, programiści muszą zapewnić i utrzymać zasoby, tak samo jak w przypadku każdej aplikacji. Co ważniejsze, modele urządzeń wykorzystywane do generowania realistycznych danych stają się odrębnym projektem poza procesem rozwoju aplikacji IIoT. W miarę postępu prac, deweloperzy muszą sprawić, by modele urządzeń pozostawały funkcjonalnie zsynchronizowane z wszelkimi zmianami w procesie definiowania sieci urządzeń i aplikacji IIoT. W przypadku zastosowań IIoT na poziomie przedsiębiorstwa, deweloperzy mogą uznać, że skalowanie tych symulacji może być co najmniej trudne, a nawet zacząć korzystać z zasobów potrzebnych do tworzenia aplikacji.

Główni dostawcy platform IoT w chmurze starają się zaradzić tym problemom za pomocą rozwiązań symulacji urządzeń IoT zaprojektowanych tak, aby były tak łatwo skalowalne jak inne zasoby chmury na odpowiednich platformach. Przykładowo, symulator urządzeń AWS IoT Device Simulator dostarcza szablon AWS dla swojej usługi konfiguracji CloudFormation, który wykorzystuje wirtualną sieć prywatną (VPN) łączącą mikrousługi zaimplementowane w kontenerach działających na bezserwerowym silniku AWS Fargate (ilustracja 5).

Ilustracja 5: symulator AWS IoT Device Simulator łączy wiele usług AWS w celu dostarczania skalowalnego strumienia danych z urządzeń do jednego rdzenia AWS IoT Core używanego przez urządzenia fizyczne. (Źródło ilustracji: Amazon Web Services)

Deweloperzy uzyskują dostęp do symulacji w sposób interaktywny poprzez konsolę graficznego interfejsu użytkownika (GUI) działającą w usłudze Amazon S3, lub poprzez interfejs programowania aplikacji IoT Device Simulator (API) generowany przez szablon CloudFormation w usłudze Amazon API Gateway. Podczas uruchomienia symulacji, mikrousługa IoT Device Simulator pobiera konfiguracje urządzeń z bazy danych Amazon DynamoDB NoSQL zgodnie z ogólnym planem symulacji opisanym w jednostce konfiguracji.

Konfiguracje urządzeń są w formacie JSON, który definiuje m.in. nazwy atrybutów urządzenia (np. temperatura), zakres wartości (np. -40 do 85) oraz aktualizują interwał pracy urządzenia i czas trwania symulacji. Deweloperzy mogą dodawać typy urządzeń w sposób interaktywny poprzez konsolę lub korzystając z programowania w API. Za pomocą zwykłych metod DevOps, można szybko skalować typy urządzeń, konfigurację i infrastrukturę, by osiągnąć pożądane tempo aktualizacji danych, docierając do AWS IoT Core i dalszych aplikacji.

W symulatorze urządzeń Azure programiści mogą dodatkowo uzupełnić podstawową listę atrybutów o zestaw zachowań obsługiwanych przez urządzenie w czasie trwania symulacji, a także zestaw metod, które aplikacja w chmurze może bezpośrednio wywołać.

Digital Twins - Cyfrowe bliźniaki

Ten rodzaj symulacji danych urządzeń jest ściśle powiązany koncepcyjnie z podobnymi do siebie, cyfrowymi możliwościami pojawiającymi się w komercyjnych platformach IoT w chmurze. W przeciwieństwie do cieni urządzeń, które są tylko statycznym obrazem stanu urządzenia, cyfrowe bliźniaki rozszerzają wirtualny model urządzenia, by móc dopasować go do fizycznego stanu urządzenia, jak również jego zachowań.

W programie Azure firmy Microsoft, usługa Azure Digital Twins pozwala deweloperom na włączenie określonych przez użytkownika funkcji do zdefiniowania zachowania urządzenia podczas symulacji, nadal dostarczając wyniki do Azure IoT Hub, jak miało to miejsce wcześniej. Niezależnie od tego czy chodzi o dane symulowane czy rzeczywiste, są one wysyłane do usługi routingu zdarzeń w celu dalszej dystrybucji w aplikacji. Microsoft wykorzystuje bliźniacze dane cyfrowe również do tworzenia wykresów przestrzennych, które przedstawiają interakcje i stan pomiędzy elementami w złożonych, hierarchicznych środowiskach, takich jak system automatyki przemysłowej składający się z wielu sieci (ilustracja 6).

Ilustracja 6: usługa Microsoft Azure Digital Twins umożliwia deweloperom tworzenie urządzeń wirtualnych, odpowiadających urządzeniom fizycznym pod względem funkcji i zastosowań oraz stanowiących podstawę zaawansowanych usług, takich jak przestrzenne wykresy złożonych hierarchii IIoT. (Źródło ilustracji: Microsoft)

Cyfrowe bliźniaki mogą dostarczyć aplikacjom IIoT skuteczny mechanizm zdolny do obsługi całego cyklu życia aplikacji powstałego wokół tych zastosowań. Na wczesnych etapach rozwoju, cyfrowe bliźniaki mogą być stosowane na dużą skalę dzięki dostępnym na platformie usługom symulacji urządzeń. W miarę uruchamiania fizycznych sieci IIoT, strumienie symulowanych danych przesyłane do cyfrowego bliźniaka mogą zostać zastąpione przez strumienie danych z urządzeń. Następnie, w całkowicie wdrożonej aplikacji IIoT deweloperzy mogą wykorzystać wszelkie znalezione przez nich różnice między działaniem urządzenia fizycznego a jego cyfrowego bliźniaka na przykład jako dodatkowe dane wejściowe do algorytmów służących konserwacji zapobiegawczej lub detektorów naruszenia zabezpieczeń. W ciągu całego cyklu cyfrowe bliźniaki mogą chronić aplikację przed przestojami w sieci lub znaczącymi zmianami w konfiguracji sieci urządzeń IIoT.

Pojawienie się cyfrowych bliźniaków na platformach IoT niesie za sobą również drugorzędną korzyść - znormalizowane podejście do opisu atrybutów i zachowań modeli urządzeń. Serwis Azure Digital Twins firmy Microsoft w swoim języku opisu wykorzystuje format JSON-LD (JavaScript Object Notation for Linked Data). JSON-LD, wspierany przez World Wide Web Consortium (W3C), zapewnia standardowy format serializacji połączonych danych oparty na standardowym formacie JSON, który jest już używany w wielu innych segmentach zastosowań.

Znormalizowane opisy cyfrowych bliźniaków mogą jeszcze bardziej przyspieszyć rozwój wraz z pojawieniem się repozytoriów gotowych opisów cyfrowych bliźniaków dla czujników i elementów wykonawczych. Na przykład firma Bosch udostępnia już w wersji open source opisy cyfrowych bliźniaków kilku swoich czujników napisane w języku Eclipse Vorto i opublikowane na stronie Eclipse Vorto repository. Wykorzystując gramatykę znaną większości programistów, język Eclipse Vorto gwarantuje prostą metodę opisu modeli i interfejsów dla cyfrowych bliźniaków. Następnie deweloperzy mogą przekonwertować swoje opisy w języku Vorto do JSON-LD lub innych formatach, w zależności od potrzeb.

Tworzenie aplikacji IIoT

Bez względu na to, czy mamy do czynienia z dyskretnymi symulatorami zdarzeń, czy też platformami zorientowanymi na mikrousługi, symulacja danych urządzeń stanowi skuteczne, oparte na oprogramowaniu rozwiązanie przyspieszające rozwój aplikacji. W przypadku zastosowań IIoT wykorzystujących sieci złożone z wielu urządzeń, migracja symulacji urządzeń na brzeg sieci może jeszcze bardziej ułatwić wdrożenie bez konieczności poświęcania reprezentatywnych danych na wczesnym etapie rozwoju aplikacji.

Systemy przetwarzania brzegowego (edge computing) odgrywają coraz większą rolę w aplikacjach IoT na dużą skalę. Systemy te zapewniają lokalne zasoby potrzebne do spełnienia najnowszych wymagań, począwszy od wstępnego przetwarzania podstawowych danych w celu zmniejszenia ilości danych docierających do chmury, a skończywszy na zaawansowanych możliwościach klasyfikacji, takich jak modele uczenia maszynowego. Systemy przetwarzania brzegowego odgrywają również bardziej znaczącą rolę, służąc jako bramki komunikacyjne pomiędzy sieciami urządzeń polowych i szybkimi sieciami typu backhaul.

Bramki takie jak seria programowalnych bramek MultiConnect Conduit firmy Multi-Tech Systems zapewniają platformy, które łączą wsparcie komunikacyjne z możliwościami obliczeń w architekturach rozproszonych zasobów informatycznych. MTCAP-915-001A dla regionów 915MHz oraz MTCAP-868-001A dla regionów 868MHz (oba firmy Multi-Tech) zapewniają łączność LoRaWAN do agregacji danych z sieci urządzeń polowych oraz łączność Ethernet lub 4G-LTE w chmurze. Bazując na systemie operacyjnym Multi-Tech Linux (mLinux) typu open source, platformy te zapewniają również znane środowisko rozwojowe do przeprowadzania symulacji urządzeń. Jako że poszczególne sieci polowe wyposażone są w fizyczne czujniki i inne urządzenia, każda jednostka może powrócić do swojej roli bramki komunikacyjnej, przekierowując swoje działania na spełnianie wymagań takich jak wstępne przetwarzanie danych.

Podsumowanie

Aplikacje IIoT stanowią istotne wyzwanie w procesie wdrażania sieci czujników w terenie i rozwoju oprogramowania aplikacji opartego na chmurze, które jest w stanie przekształcić dane z czujników w nadające się do wykorzystania wyniki. Wzajemna zależność sieci czujników i oprogramowania aplikacyjnego może sprawić, że prace staną w miejscu, jako że rozmieszczenie czujników i wdrożenie oprogramowania pozostają w stosunku zależności i nie mogą być kontynuowane w sposób niezależny, jeśli mają osiągnąć wystarczający poziom masy krytycznej.

Jak wykazano powyżej, deweloperzy mogą przełamać ten impas i przyspieszyć rozwój aplikacji IIoT poprzez symulację strumieni danych z zachowaniem realistycznych poziomów ilości, prędkości i różnorodności.