Beschleunigung der Entwicklung industrieller IoT-Anwendungen - Teil 1: Simulation von IoT-Gerätedaten

Anmerkung des Herausgebers: Projekte zur Entwicklung eingebetteter Anwendungen verzögern sich oft, da die Entwickler auf die Verfügbarkeit von Hardware-Implementierungen neuer Geräte warten. Die Anwendungsentwicklung des industriellen Internet der Dinge (IIoT) steht vor einem ähnlichen Engpass, da sie auf die Sensordaten wartet, die für Anwendungen wie industrielle vorausschauende Wartungssysteme oder auf maschinellen Lernmethoden basierende Gebäudeautomatisierungssysteme benötigt werden. Diese zweiteilige Reihe untersucht Alternativen für die Bereitstellung früher Datenströme, die zur Beschleunigung der Entwicklung von IIoT-Anwendungen benötigt werden. Hier wird in Teil 1 die Verwendung von Simulationsmethoden zur Erzeugung dieser Datenströme beschrieben. In Teil 2 werden Optionen für das Rapid Prototyping von Sensorsystemen zur Datenerzeugung diskutiert.

Groß angelegte industrielle Anwendungen des Internet der Dinge (IIoT) stellen eine Vielzahl von Herausforderungen dar, die zu einem Stillstand bei der Implementierung führen und Unternehmen die Rentabilität der vielen für die Implementierung erforderlichen Ressourcen in Frage stellen können. Um solche Situationen zu verhindern und den Entwicklern zu helfen, die Vorteile des IIoT-Einsatzes schneller zu erkennen, ist ein leichter Zugang zu den Daten für die Einsatzsimulation erforderlich.

Durch die Verwendung von Simulationsmethoden zur Erzeugung realistischer Datenströme können Entwickler mit der Entwicklung von IIoT-Anwendungen lange vor dem Einsatz des IoT-Netzwerks beginnen und sogar die Definition des IIoT-Sensornetzes selbst verfeinern.

Dieser Artikel zeigt, wie die verschiedenen IoT-Cloud-Plattformen die Datensimulation ermöglichen und stellt Beispielgateways von Multi-Tech Systems Inc. vor, die die Bereitstellung weiter beschleunigen können.

Der Fall für die Simulation von IIoT-Daten

Die Verwendung von simulierten Daten zur Entwicklung von Anwendungen und Systemen ist natürlich nichts Neues. Entwickler haben jahrzehntelang Simulationsmethoden auf Systemebene eingesetzt, um Recheninfrastrukturen und Konnektivitätsdienste zu testen. Diese Tests haben eine wichtige Funktion bei der Überprüfung der Robustheit von statischen Konfigurationen. In Cloud-Service-Plattformen bieten diese Tests eine relativ einfache Methode zur Überprüfung der automatischen Skalierung von virtuellen Maschinen und anderen Cloud-Ressourcen.

IIoT-Anwendungen haben die gleichen Anforderungen und mehr. Neben der Unterstützung von Lasttests und der automatischen Skalierung bietet die Datensimulation ein wichtiges Werkzeug zur Überprüfung der Integration der vielen unterschiedlichen Dienste und Ressourcen, die für die Implementierung einer so komplexen Software wie eine IIoT-Anwendung auf Unternehmensebene erforderlich sind. Über diese grundlegenderen Praktiken hinaus kann die Datensimulation die Entwicklung komplexer IIoT-Anwendungen beschleunigen, die auf den hochentwickelten Service-Plattformen führender Cloud-Anbieter aufbauen.

Software-Perspektive

IIoT-Anwendungen arbeiten auf komplexen Architekturen, die für Entwickler von Anwendungssoftware wesentlich anders aussehen als für Entwickler von Sensor- und Aktorsystemen. Für letztere ist eine groß angelegte IIoT-Architektur eine riesige Ansammlung von Sensoren und Aktoren, die eine Schnittstelle zu den physikalischen Prozessen bilden, die Gegenstand der Gesamtanwendung sind. Für Entwickler von Anwendungssoftware umfasst eine IIoT-Architektur auf Unternehmensebene eine Reihe von Diensten, deren koordinierte Aktivität letztlich die Funktionalität der Anwendung liefert.

Die Microsoft Azure IoT-Referenzarchitektur bietet eine repräsentative Sicht auf typische IIoT-Anwendungen (und IoT-Anwendungen im Allgemeinen) aus der Sicht der Anwendungssoftware. Diese Ansicht fasst die zahlreichen funktionalen Dienste zusammen, die eine typische Anwendung in der Cloud zusammenfügt, um auf der Grundlage der Daten vom Endpunkt und den Peripheriegeräten Erkenntnisse und Aktionen zu liefern (Abbildung 1).

Abbildung 1: Die Microsoft Azure IoT-Referenzarchitektur veranschaulicht die verschiedenen Arten von Cloud-Diensten und -Ressourcen, die eine IIoT-Anwendung typischerweise benötigt, um aus den von Gerätenetzen in der Peripherie erzeugten Daten nützliche Erkenntnisse und Aktionen zu gewinnen. (Bildquelle: Microsoft Corp.)

Spezifische Anwendungslösungen setzen diese Cloud-Ressourcen in geeigneten Kombinationen ein, die durch standardisierte Austauschmechanismen funktional verbunden und durch Anwendungslogik koordiniert werden. In seiner Lösung für das vernetzte Fahrzeug schlägt beispielsweise Amazon Web Services (AWS) vor, wie Cloud-Dienste in Modulen gemischt und abgestimmt werden können, die für die Bereitstellung verschiedener Funktionen und Fähigkeiten der Anwendung verantwortlich sind (Abbildung 2).

Abbildung 2: Die AWS Connected Vehicle-Lösung bietet einen repräsentativen Überblick über die Orchestrierung von Cloud-Diensten durch eine typische groß angelegte IoT-Anwendung, um die benötigten funktionalen Fähigkeiten zu liefern. (Bildquelle: Amazon Web Services)

Wie diese architektonischen Darstellungen nahe legen, ist der Aufwand für die Softwareentwicklung, der zur Erstellung einer IIoT-Anwendung erforderlich ist, genauso anspruchsvoll und umfangreich wie die Implementierung von peripheren Netzwerken von Sensor- und Aktorsystemen. Nur wenige Unternehmen können es sich leisten, die Entwicklung dieser komplexen Software zu verzögern, bis das Gerätenetz in der Lage ist, genügend Daten zu erzeugen. Tatsächlich muss die Bereitstellung des Gerätenetzes möglicherweise auf eine weitere Definition und Verfeinerung warten, die sich ergeben kann, wenn Analytik-Spezialisten und Experten für maschinelles Lernen mit den Anwendungsergebnissen zu arbeiten beginnen. Im schlimmsten Fall geraten die Bereitstellung von Gerätenetzen und die Software-Entwicklung in eine Sackgasse: beide sind von den Ergebnissen der anderen abhängig.

Glücklicherweise liegt die Lösung für dieses Dilemma in der Natur der IoT-Architekturen. Abgesehen von einer groben Ähnlichkeit unterscheiden sich Cloud-Service-Architekturen wie die oben abgebildeten von Microsoft und AWS natürlich im Detail. Dennoch weisen sie alle ein ähnliches architektonisches Merkmal auf, das typischerweise in IoT-Cloud-Plattformen zu finden ist: Ein wohldefiniertes Schnittstellen-Servicemodul oder eine Schichtfunktionalität, die das periphere Netzwerk von IoT-Geräten von der Cloud-basierten Software-Anwendung trennt. Neben der Bereitstellung einheitlicher Konnektivität sind diese Schnittstellendienste für das Gerätemanagement und die Sicherheit sowie für andere wichtige Funktionen, die in groß angelegten IIoT-Anwendungen benötigt werden, von entscheidender Bedeutung.

In der Microsoft-Azure-Cloud wird dieser Schnittstellendienst Azure IoT Hub genannt (siehe Abbildung 1); in der AWS-Cloud ist es AWS IoT Core (siehe Abbildung 2). In der Google-Cloud-Plattform ist diese Schnittstelle der Cloud-IoT-Kern, und in der IBM-Cloud ist es der IBM Watson IoT-Plattformservice. Andere Plattformen wie die ThingWorx IoT Plattform werden auf ähnliche Weise durch Konnektivitätsdienste wie ThingWorx Edge Microserver, ThingWorx Kepware Server oder Protokoll-Adapter-Toolkits verbunden. Kurz gesagt, jede Cloud-Plattform muss einen konsistenten Schnittstellendienst bereitstellen, der Daten von der Peripherie zu Cloud-Diensten leitet oder ein verwirrendes Gewirr von Verbindungen von Peripheriegeräten direkt zu einzelnen Ressourcen tief in der Cloud riskiert.

Verwendung simulierter Daten

Mit dem Software Development Kit (SDK) jeder IoT-Plattform können Entwickler simulierte Sensordaten direkt in den Schnittstellendienst der Plattform mit der Menge, Geschwindigkeit und Vielfalt einfließen lassen, die zur Überprüfung der Anwendungsfunktionalität und -leistung erforderlich sind. Simulierte Daten, die mit der gewünschten Rate und Auflösung generiert werden, erreichen den Schnittstellendienst unter Verwendung von Standardprotokollen wie MQ Telemetry Transport (MQTT), Constrained Application Protocol (CoAP) und anderen. Für den Schnittstellendienst (und die nachgeschaltete Anwendungssoftware) sind die simulierten Datenströme nicht von den durch ein Hardware-Sensorsystem erfassten Daten zu unterscheiden. Wenn die Gerätenetzwerke bereit sind, online zu gehen, ersetzen ihre Sensordatenströme einfach die simulierten Datenströme, die den Schnittstellendienst erreichen.

Anbieter von Cloud-Plattformen unterstützen diesen Ansatz der Datensimulation in der Regel auf verschiedenen Ebenen der Leistungsfähigkeit. Beispielsweise demonstriert Google eine einfache simulationsgesteuerte Anwendung mit einer Referenzarchitektur und Beispielcode, die einen einfachen Regelkreis eines temperaturgesteuerten Lüfters implementiert. Wie die zuvor dargestellten Architekturen nutzt diese Architektur die Dienste der Google Cloud Platform, die von der Google Cloud IoT Core Service-Schnittstelle gespeist werden (Abbildung 3).

Abbildung 3: In jeder IoT-Cloud-Plattform verwenden Gerätesimulatoren die gleichen Kommunikationsprotokolle, die von physischen Geräten verwendet werden, um Daten an einen Schnittstellendienst wie den Google Cloud IoT Core für die hier gezeigte Anwendungsarchitektur der Google Cloud-Plattform zu liefern. (Bildquelle: Google)

In dieser Beispielanwendung erzeugen Simulatoren für Sensoren in gemäßigten Zonen Daten mit einer ausgewählten Aktualisierungsrate und leiten die Daten mit Hilfe des MQTT-Messaging-Protokolls an den Google Cloud IoT Core-Schnittstellendienst weiter. Dieser Schnittstellendienst wiederum verwendet die standardmäßigen Publish-Subscribe (Pub/Sub)-Protokolle der Plattform, um die Daten an einen simulierten Server zu übermitteln, der mit einem Befehl zum Ein- oder Ausschalten des Lüfters je nach Bedarf antwortet (Abbildung 4).

Abbildung 4: Eine Google-Beispielanwendung demonstriert eine grundlegende Regelschleife, die ein simuliertes Gerät umfasst, das Daten über den Google Cloud IoT Core an einen simulierten Server unter Verwendung von Standardkommunikationsmethoden sendet. (Bildquelle: Google)

Google stellt Beispielcode in Python zur Verfügung, der diese Basisanwendung implementiert. In diesem Code enthält eine Instanz der Geräteklasse eine Methode, die die simulierte Temperatur auf der Grundlage des Zustands des simulierten Lüfters aktualisiert. Die Hauptroutine ruft diese Methode mit einer bestimmten Rate auf und sendet die Daten über einen MQTT-Verbindungsdienst, der vom Eclipse paho-mqtt Python MQTT-Client-Modul (Listing 1) bereitgestellt wird.

Kopie
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: Dieser Ausschnitt aus der Google-Beispielanwendung veranschaulicht, wie die Hauptroutine regelmäßig eine Instanz der Geräteklasse aktualisiert, die den aktuellen Wert des simulierten Temperatursensors speichert und eine Methode zur Verfügung stellt, die diesen Wert je nach Zustand des simulierten Lüfters aktualisiert. (Code-Quelle: Google)

Eine Instanz der Serverklasse wiederum bietet ein Modul, das den Lüfterstatus in Abhängigkeit von den von der Instanz der Geräteklasse (Listing 2) empfangenen Temperaturdaten aktualisiert.

Kopie
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: In diesem Ausschnitt aus der Google-Beispielanwendung stellt die in der Server-Klasse definierte _update_device_config()-Methode die Betriebslogik für die Anwendung bereit, indem sie den Lüfterstatus auf "Ein" setzt, wenn die Temperatur über einen definierten Wert steigt, und den Lüfterstatus auf "Aus", wenn sie fällt. (Code-Quelle: Google)

Neben dem Beispielcode von Google finden Entwickler auf Repositories wie GitHub Dutzende von Open-Source-IoT-Geräte-, System- und Netzwerksimulatoren. Der Open-Source-Simulatorcode des Raspberry-Pi-Systems von Microsoft beispielsweise enthält eine vordefinierte Integration in den Azure IoT-Hub für die schnelle Entwicklung von Cloud-basierten Anwendungen, die mit Raspberry-Pi-Boards zusammenarbeiten. Darüber hinaus unterstützen Low-Code-Programmierwerkzeuge wie Node-RED vorgefertigte Module (Knoten) zur Einspeisung von simulierten Sensordaten in die IoT-Service-Schnittstellen der führenden Cloud-Plattform. Mit diesen Ansätzen können Entwickler leicht einen Strom von Sensordaten erzeugen.

Ausführen von Simulationen im Maßstab

Die Schwierigkeit bei der Verwendung von Simulatoren auf Geräteebene und damit verbundenen Werkzeugen besteht darin, dass die Verwaltung der Datensimulation zu einem Projekt an sich werden kann. Um die Simulatoren zu betreiben, müssen die Entwickler wie bei jeder Anwendung Ressourcen bereitstellen und pflegen. Von größerer Bedeutung ist, dass die Gerätemodelle, die zur Erzeugung realistischer Daten verwendet werden, zu einem separaten Projekt außerhalb des IIoT-Anwendungsentwicklungsprozesses werden. Im Laufe der Entwicklung müssen die Entwickler sicherstellen, dass die Gerätemodelle funktional mit allen Änderungen in der Definition des IIoT-Gerätenetzes und der Anwendung synchronisiert bleiben. Bei IIoT-Anwendungen auf Unternehmensebene können Entwickler feststellen, dass die Skalierung dieser Simulationen bestenfalls schwierig sein kann, und sogar beginnen, die für die Entwicklung der Anwendung benötigten Ressourcen zu nutzen.

Die großen Anbieter von IoT-Cloud-Plattformen begegnen diesen Bedenken mit IoT-Bauteil-Simulationslösungen, die so einfach wie andere Cloud-Ressourcen in ihren jeweiligen Plattformen skalierbar sind. Der AWS IoT Device Simulator bietet beispielsweise eine AWS-Vorlage für seinen Konfigurationsdienst CloudFormation, der ein virtuelles privates Netzwerk zur Verbindung von Mikrodiensten, die in Containern auf der serverlosen AWS Fargate-Engine implementiert sind, bereitstellt (Abbildung 5).

Abbildung 5: Der AWS IoT Device Simulator kombiniert mehrere AWS-Dienste, um einen skalierbaren Strom von Gerätedaten an denselben AWS IoT Core zu liefern, der von physikalischen Geräten verwendet wird. (Bildquelle: Amazon Web Services)

Entwickler greifen auf die Simulation interaktiv über eine Konsole mit grafischer Benutzeroberfläche (GUI) zu, die im Amazon S3-Dienst ausgeführt wird, oder programmatisch über die IoT Device Simulator Application Programming Interface (API), die von der CloudFormation-Vorlage im Amazon API-Gateway-Dienst generiert wird. Während eines Simulationslaufs zieht der IoT Device Simulator-Mikrodienst Gerätekonfigurationen aus der Amazon DynamoDB NoSQL-Datenbank gemäß einem Gesamtsimulationsplan, der in einem eigenen Konfigurationsobjekt beschrieben ist.

Bei den Gerätekonfigurationen handelt es sich um JSON-Datensätze, die u.a. die Namen der Geräteattribute (z.B. Temperatur), den Wertebereich (z.B. -40 bis 85) sowie das Geräteintervall und die Simulationsdauer definieren. Entwickler können Gerätetypen interaktiv über die Konsole oder programmgesteuert über die API hinzufügen. Mit normalen DevOps-Methoden können die Gerätetypen, die Konfiguration und die Infrastruktur schnell skaliert werden, um die gewünschten Datenaktualisierungsraten zu erreichen, die den AWS IoT Core und die nachgelagerte Anwendung erreichen.

Im Azure-Gerätesimulator können Entwickler die Grundliste der Attribute durch eine Reihe von Verhaltensweisen ergänzen, die das Gerät während des Simulationslaufs unterstützt, sowie durch eine Reihe von Methoden, die die Cloud-Anwendung direkt aufrufen kann.

Digitale Zwillinge

Diese Art der Gerätedatensimulation ist konzeptionell eng mit den digitalen Zwillingsfunktionen verbunden, die in kommerziellen IoT-Cloud-Plattformen auftauchen. Im Gegensatz zu Geräteschatten, die typischerweise nur eine statische Darstellung des Gerätezustands liefern, erweitern digitale Zwillinge ein virtuelles Gerätemodell, um sowohl dem physischen Gerätezustand als auch seinem Verhalten zu entsprechen.

In Microsofts Azure ermöglicht der Azure Digital Twins-Dienst Entwicklern, benutzerdefinierte Funktionen zur Definition des Verhaltens während einer Gerätesimulation einzubinden, wobei die Ergebnisse wie bisher an den Azure IoT Hub weitergeleitet werden. Unabhängig davon, ob es sich um simulierte oder reale Daten handelt, werden die eingehenden Daten dann an einen Ereignis-Routing-Dienst zur weiteren Verteilung in der Anwendung gesendet. Microsoft verwendet die digitalen Zwillingsdaten auch zur Erstellung räumlicher Graphen, die die Interaktionen und den Zustand zwischen Elementen in komplexen hierarchischen Umgebungen wie einem industriellen Automatisierungssystem mit mehreren Netzwerken darstellen (Abbildung 6).

Abbildung 6: Der Microsoft Azure Digital Twins-Dienst ermöglicht es Entwicklern, virtuelle Geräte zu bauen, die ihren physischen Gegenstücken in Funktionen und Fähigkeiten entsprechen und die Grundlage für anspruchsvolle Dienste wie räumliche Graphen komplexer IIoT-Hierarchien bilden. (Bildquelle: Microsoft)

Für IIoT-Anwendungen können digitale Zwillinge einen leistungsfähigen Mechanismus bieten, der den gesamten Lebenszyklus von Anwendungen unterstützt, die auf diesen Fähigkeiten aufbauen. In frühen Entwicklungsstadien können digitale Zwillinge durch die Geräte-Simulationsdienste der Plattform maßstabsgetreu gesteuert werden. Wenn physische IIoT-Netzwerke online gehen, können diese simulierten Dateneinspeisungen in den digitalen Zwilling durch Gerätedateneinspeisungen ersetzt werden. Später können Entwickler in einer vollständig implementierten IIoT-Anwendung alle Unterschiede, die zwischen einem physischen Gerät und seinem digitalen Zwilling gefunden werden, als zusätzlichen Input für z.B. vorbeugende Wartungsalgorithmen oder Sicherheitseinbruchsmelder verwenden. Während des gesamten Lebenszyklus können digitale Zwillinge die Anwendung vor Netzwerkausfällen oder erheblichen Änderungen der Konfiguration von IIoT-Gerätenetzen schützen.

Das Aufkommen von digitalen Zwillingen in IoT-Plattformen bietet auch einen sekundären Nutzen, indem es einen standardisierten Ansatz für die Beschreibung von Eigenschaften und Verhaltensweisen von Gerätemodellen bietet. Der Microsoft-Dienst Azure Digital Twins verwendet für seine Beschreibungssprache das JSON-LD (JavaScript Object Notation for Linked Data). Mit Unterstützung des World Wide Web Consortiums (W3C) bietet JSON-LD ein Standardformat zur Serialisierung verknüpfter Daten, das auf dem Industriestandard JSON-Format basiert, das bereits in einer Reihe anderer Anwendungssegmente verwendet wird.

Standardisierte digitale Zwillingsbeschreibungen können die Entwicklung weiter beschleunigen, da es immer mehr Repositorien mit vorgefertigten digitalen Zwillingsbeschreibungen für Sensoren und Aktoren gibt. So stellt Bosch beispielsweise bereits digitale Zwillingsbeschreibungen von mehreren seiner Sensoren in der Sprache Eclipse Vorto als Open Source zur Verfügung, die im Eclipse Vorto-Repository veröffentlicht wurden. Mit einer den meisten Programmierern vertrauten Grammatik bietet die Sprache Eclipse Vorto eine einfache Methode zur Beschreibung von Modellen und Schnittstellen für digitale Zwillinge. Später können Entwickler ihre Vorto-Sprachbeschreibungen nach Bedarf in JSON-LD oder andere Formate konvertieren.

Aufbau der IIoT-Anwendung

Ob mit diskreten Simulatoren oder mikroserviceorientierten Plattformen gebaut, die Gerätedatensimulation bietet eine effektive softwarebasierte Lösung zur Beschleunigung der Anwendungsentwicklung. Bei IIoT-Anwendungen, die mehrere Gerätenetzwerke verwenden, kann die Migration der Gerätesimulationen zum Rand hin dazu beitragen, den Übergang zur Bereitstellung weiter zu erleichtern, ohne dass die Notwendigkeit repräsentativer Daten zu Beginn der Anwendungsentwicklung geopfert wird.

Edge-Computing-Systeme spielen eine immer wichtigere Rolle bei groß angelegten IoT-Anwendungen. Diese Systeme stellen lokale Ressourcen bereit, die für neu entstehende Anforderungen benötigt werden, von der grundlegenden Datenvorverarbeitung zur Reduzierung der Datenmenge, die die Cloud erreicht, bis hin zu fortgeschrittenen Klassifizierungsfunktionen wie Inferenzmodellen für maschinelles Lernen. Edge-Computing-Systeme spielen auch eine grundlegendere Rolle als Kommunikations-Gateways zwischen Gerätenetzen im Feld und Hochgeschwindigkeits-Backhaul-Netzen.

Gateways wie die programmierbare MultiConnect Conduit-Familie von Multi-Tech Systems bieten Plattformen, die Kommunikationsunterstützung mit Edge-Verarbeitungsfunktionen kombinieren. Der Multi-Tech MTCAP-915-001A für 915 Megahertz (MHz)-Regionen und der MTCAP-868-001A für 868 MHz-Regionen bieten LoRaWAN-Konnektivität für die Aggregation von Daten von Netzwerkgeräten im Außenbereich und Ethernet- oder 4G-LTE-Konnektivität auf der Cloud-Seite. Basierend auf dem Open-Source-Betriebssystem Multi-Tech Linux (mLinux) bieten diese Plattformen auch eine vertraute Entwicklungsumgebung für die Ausführung von Gerätesimulationen. Wenn separate Feldnetzwerke mit physischen Sensoren und anderen Geräten online gehen, kann jede Einheit wieder ihre Rolle als Kommunikationsgateway übernehmen und die Verarbeitungsbemühungen auf Anforderungen wie die Datenvorverarbeitung umleiten.

Fazit

IIoT-Anwendungen stellen eine große Herausforderung für den Einsatz von Sensornetzwerken im Feld und die Entwicklung von Cloud-basierter Anwendungssoftware dar, die in der Lage ist, Sensordaten in nützliche Ergebnisse umzuwandeln. Die gegenseitige Abhängigkeit von Sensornetzwerken und Anwendungssoftware kann dazu führen, dass die Entwicklung ins Stocken gerät, während der Sensoreinsatz und die Softwareimplementierung darauf warten, dass eine ausreichende kritische Masse erreicht wird.

Wie gezeigt, können Entwickler diese Sackgasse durchbrechen und die Entwicklung von IIoT-Anwendungen beschleunigen, indem sie Datenströme mit realistischen Werten für Menge, Geschwindigkeit und Vielfalt simulieren.