Teil 1: Einführung in eine modulare IoT-Architektur

Die Dreifaltigkeit des Internets der Dinge

Patrick Steiner

©Shutterstock / chombosan

Eine IoT-Architektur besteht aus drei Bausteinen: erstens einem Device, an dem Daten gemessen werden, zweitens einem Gateway, das die erfassten Daten auf Konsistenz überprüft und für die Weiterleitung aggregiert sowie drittens dem Rechenzentrum oder der Cloud, wo die entscheidungsrelevante Aufbereitung der Daten erfolgt. Ein einfaches und schrittweise weiter verfeinertes Beispiels zeigt die einzelnen Komponenten und deren Zusammenspiel.

So verschieden die diversen IoT-Anwendungsszenarien auch sind, fast immer lassen sich bestimmte Kernkomponenten unterscheiden: Device, Gateway und Datacenter beziehungsweise die Cloud. Ausgangspukt ist ein Edge-Device, an dem die Daten entstehen, die im Rahmen der IoT-Applikation erfasst werden. Ein Controllergateway – ausgestattet mit bestimmten Softwarefunktionalitäten – inspiziert die Konsistenz der eingehenden Daten, nimmt eine Aggregation vor und übermittelt die Daten an eine Applikation im Rechenzentrum oder in der Cloud. Dort erfolgt eine detaillierte Analyse und Aufbereitung der Daten für konkrete Aktionen, beispielsweise das Ändern und Anpassen von Maschinen- oder Device-Parametern.

Abb. 1: Skalierbar, zuverlässig und sicher: Das Schichtenmodell mit Geräteebene (Device Tier), Steuerungsebene (Gateway Tier) und Rechenzentrums- oder Cloud-Ebene (Data Center Tier) (Quelle: Red Hat)

Abb. 1: Skalierbar, zuverlässig und sicher: Das Schichtenmodell mit Geräteebene (Device Tier), Steuerungsebene (Gateway Tier) und Rechenzentrums- oder Cloud-Ebene (Data Center Tier) (Quelle: Red Hat)

Unser Beispiel zeigt die Kommunikation zwischen Edge-Device und Controllergateway. In einer Fertigungsumgebung sind Produktionsmaschinen mit Sensoren ausgestattet, die ihre Daten an ein Controllergateway übermitteln. Auf dem Gateway läuft Docker mit Red Hat JBoss Fuse als Container. Vom Gateway aus werden die Daten an OpenShift Enterprise von Red Hat weitergeleitet. Dabei handelt es sich um eine containerbasierte Anwendungsplattform auf der Grundlage von Docker und Red Hat Enterprise Linux. Die Containerapplikationen lassen sich beispielsweise auf einem Notebook erstellen, testen und anschließend im Rechenzentrum betreiben.

Überblick über das Demo-Set-up
Das Szenario besteht aus:

  • Edge Device, das einen Dummysensor zur Datenerfassung simuliert
  • Controller, der die Edge Messages in XML-Format umwandelt, die Messages, basierend auf der Quelle, weiterleitet, um unterschiedliche Aktionen einzuleiten, und der Messages mithilfe von Complex Event Processing filtert
  • Rechenzentrumsfunktionalität, um anhand von Geschäftsregeln zu entscheiden, ob vorliegende Daten aufbewahrt werden sollen, um ausgewählte Daten beispielsweise in einer PostgreSQL-Datenbank zu speichern, um Daten mittels Geschäftsregeln zu überprüfen und – falls erforderlich – einen manuellen Eingriff auszulösen, und um die Daten in einem Dashboard grafisch aufzubereiten.

Zur Kommunikation zwischen Edge Device und Controller lassen sich unterschiedliche Protokolle wie DDS (Data Distribution Service), AMQP (Advanced Message Queuing Protocol) oder MQTT (Message Queue Telemetry Transport) verwenden. Hier soll MQTT zum Einsatz kommen. Die Kommunikation zwischen Controller und Rechenzentrum erfolgt via JMS (Java Message Service). In diesem Modell wird als Edge-Device ein einfacher Dummysensor implementiert, der als Temperatur- oder Drucksensor fungiert. Im einfachsten Fall startet er mit einem Initialwert. Er ändert die Daten für die Dummyapplikation mithilfe einer Zufallszahl zwischen 1 und 1 000. Wenn die Zufallszahl kleiner gleich 10 ist, wird der Datenwert um 1 reduziert. Wenn die Zufallszahl größer gleich 990 ist, wird der Datenwert um 1 erhöht. Dann werden die Daten per MQTT an den Controller gesendet. Dabei spielt es keine Rolle, ob die Daten im XML- oder im CSV-Format übertragen werden. MQTT unterstützt beide Formate.

Der Controller empfängt die Daten via MQTT, wandelt die Daten – falls sie im CSV-Format ankommen – von einem sensorspezifischen Format in XML um. Dann leitet er die Daten abhängig vom Sensortyp weiter. Er nutzt dazu Complex Event Processing, um Messages zu filtern. Ist der Wert der gleiche wie in der vorhergehenden Message, wird die Message gelöscht. Abschließend sendet er den Datensatz via JMS ins Rechenzentrum.

In der einfachsten Ausführung gibt es im Rechenzentrum Services, die Messages vom Controller empfangen, die erhaltene Daten in einer PostgreSQL-Datenbank speichern und die Daten an eine Kontrolleinheit weiterleiten, um festzustellen ob manuelle Eingriffe erforderlich sind. Dazu wird ein entsprechender Alert ausgelöst. Diese und gegebenenfalls weitere Services laufen jeweils in einem eigenen Container.

Diese Modellarchitektur bildet den Ausgangspunkt für eine realitätsnähere Erweiterung des Modells. Anstatt eines Dummysensors kommen reale, dumme Sensoren zum Einsatz, die beispielswiese mit einem Raspberry Pi als Smart-Edge-Komponente verbunden sind. Eine weitere Möglichkeit sind smarte Sensoren, die direkt auf einem Mikrokontroller wie dem ESP8266 angebracht sind. Die Smart-Edge-Komponente wird um Technologien wie Eclipse Kura und Rhiot erweitert. Ein Smart-Gateway, wiederum ein Raspberry Pi, übernimmt die Vorverarbeitung der Daten, die schließlich an ein Rechenzentrum weitergeleitet werden. Dort nehmen Services, die auf OpenShift von Red Hat basieren, die eigentliche Verarbeitung und Analyse der Daten vor.

Ein Schritt näher an die Realität: Edge-Device mit Mikrocontroller und Sensor

Der ESP8266 ist ein kostengünstiger WLAN-Baustein, der in unterschiedlichen Varianten erhältlich ist, beispielsweise mit einer unterschiedlichen Anzahl an GPIOs (General Purpose Input/Output)-Pins. Es gibt mehrere Möglichkeiten, um den ES8266 zu programmieren oder die Firmware zu flashen. Für diesen Zweck eignet sich etwa die Arduino-IDE. Eine gute Einführung zur Einrichtung einer IoT-Entwicklungsumgebung gibt es im IoT-Playground. Der Sensor DHT22 misst die Temperatur und die Luftfeuchtigkeit in der Umgebung. Wie die Daten vom DHT22 gelesen werden zeigt Listing 1.

void gettemperature() {
  humidity = dht.readHumidity(); // Read humidity (percent)
  temp_f = dht.readTemperature(); // Read temperature as Celsius

  // Check if any reads failed and exit early (to try again).
  if (isnan(humidity) || isnan(temp_f)) {
    Serial.println("Failed to read from DHT sensor!");
    return;
  }
}

Um die Kombination aus ESP8266 und DHT22 als Edge-Device einsetzen zu können, existieren verschiedene Optionen. Auf dem Markt sind beispielsweise Entwicklerboards erhältlich, die sich direkt an einen PC anschließen lassen. Andere verbinden den ESP8266 über einen USB-2-TTl-Adapter und eine Steckkarte. Das hier vorgestellte Szenario folgt einem beschriebenen Setup.

Der Sensor stellt die Verbindung zu einem vorhandenen WLAN her (Listing 2). Er misst im Sekundentakt die Temperatur sowie die Luftfeuchtigkeit und schickt die Temperaturwerte in einem MQTT-Topic namens iotdemo/temperature/ an das Gateway (Listing 3 und 4). deviceType repräsentiert dabei das, was gemessen wird (z. B. Temperatur, Luftfeuchtigkeit) und deviceID eine eindeutige ID des Sensors. Und damit steht unser smarter Sensor.

const char* ssid = ;
const char* password = ;

WiFiClient wifiClient;

// Connect to WiFi network
WiFi.begin(ssid, password);

// Wait for connection
while (WiFi.status() != WL_CONNECTED) {
  delay(500);
}
char* mqtt_server = "192.168.178.80"; // IP Addresse des Ziel MQTT Brokers
int mqtt_server_port = 1883; // Port des Ziel MQTT Brokers
const char* mqtt_user = "admin"; // User-ID zum authentifizieren auf dem Ziel MQTT Broker
const char* mqtt_password = "admin"; // Passwort zum authentifizieren auf dem Ziel MQTT Broker

PubSubClient client(mqtt_server, mqtt_server_port, wifiClient );

while (!client.connected()) {
  // Attempt to connect
  if !(client.connect(mqtt_server, mqtt_user, mqtt_password)) {
    // Wait 5 seconds before retrying
    delay(5000);
  }
}
client.publish(topicTemp.c_str(), message.c_str());

Der zweite Teil des Beitrags befasst sich im Detail mit dem Raspberry-Pi-basierten Smart-Gateway und dessen inhaltlicher Logik.

Verwandte Themen:

Geschrieben von
Patrick Steiner
Patrick Steiner
Patrick Steiner ist seit mehr als sechzehn Jahren in der IT-Branche tätig. Den größten Teil seiner professionellen Laufbahn hat er für IBM Deutschland gearbeitet, davon die letzten zehn Jahre als Senior-IT-Architekt im Industrial Sector. Seit Mai 2013 ist er als Solution Architect für Red Hat Deutschland tätig.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: