Suche
Teil 2: Vermittlungsinstanz einer IoT-Architektur

Internet der Dinge: Aufbau eines Smart Gateways und seiner Logik

Patrick Steiner

© Shutterstock / Chesky

In einer vereinfachten Sicht umfasst eine IoT-Architektur drei Komponenten: Sensoren, die Daten erfassen, ein Gateway, das die Daten empfängt und für die Weiterleitung vorbereitet sowie eine zentrale Instanz, in der Daten eingehend analysiert und für Steuerungsaufgaben aufbereitet werden. Während sich der erste Teil dieser Miniserie schwerpunktmäßig mit den Sensoren befasste, geht es im zweiten Teil um die Abläufe und die inhaltliche Logik im Gateway.

Dem Bausteinprinzip folgend, besteht ein Smart Gateway in Form eines Raspberry Pi aus den folgenden drei Elementen: Raspbian als Betriebssystem, Docker-Containern, um die verschiedenen, auf dem Gateway ablaufenden Funktionalitäten voneinander zu isolieren, und Red Hat JBoss Fuse als Komponente des Gateways, die den MQTT-Broker für die Sensoren bereitstellt. Sie wandelt darüber hinaus die Nachrichten von einem nativen in ein generisches XML-Format um und bietet ein Content-based Routing, das die Nachrichten an die vorgesehenen zentralen Instanzen weiterleitet – seien es ein On-Premise-Rechenzentrum oder ein Cloud-Anbieter.

Während es im ersten Teil der Serie um die Konfiguration des Smart Gateways ging, stehen diesmal die Implementierungsdetails im Vordergrund. Dazu gehören der Empfang von CSV-basierten Nachrichten via MQTT, die Umwandlung der Daten vom CSV- ins XML-Format und deren Erweiterung um Metadaten aus dem MQTT Topic. Ein MQTT Topic bündelt Nachrichten zu einem bestimmten Thema. Das können beispielsweise die durch einen Sensor gemessenen Temperaturen oder andere thermodynamische und mechanische Größen sein. Zur weiteren detaillierten Analyse werden die aufbereiteten Nachrichten via JMS an ein Rechenzentrum vor Ort oder in der Cloud weitergeleitet (Abb. 1).

Artikelserie

Teil 1 : Einführung modulare IoT-Architektur

Teil 2: Aufbau des Smart Gateways und seiner Logik

Abb. 1: Die Daten werden am Device Tier erfasst, am Gateway Tier aufbereitet und dann an das Datacenter Tier weitergeleitet (Quelle: Red Hat)

Die inhaltliche Logik des Smart Gatways lässt sich mit einer Apache Camel Route in Spring XML erstellen. Apache Camel ist ein leichtgewichtiges Open-Source-Integrationsframework, das es ermöglicht, Systeme mit verschiedenen Schnittstellentechnologien und -formaten miteinander zu verknüpfen. Apache Camel übernimmt die Konvertierung der Nachrichten und sorgt für deren Routing zwischen den Systemen. Um die Nachrichten zu transformieren, anzureichern oder neu anzuordnen, stehen unterschiedliche Werkzeuge bereit. Apache Camel ermöglicht eine regelbasierte Verteilung und Zustellung der Nachrichten an die Zielsysteme.

Im Fall unseres Smart Gateways gibt es mehrere Möglichkeiten: Entweder man lässt die Camel Route als eigenständige Java-Applikation laufen oder man implementiert sie im Rahmen von Red Hat JBoss Fuse. Dabei handelt es sich um die von Red Hat unterstützte Enterprise-Version von Apache Camel. Außerdem kann die Camel Route auf der Red Hat JBoss Enterprise Application Platform implementiert werden. Der komplette Sourcecode steht in meinem GitHub Repository zur Verfügung.

Nachrichten auf der Camel Route

Die Camel Route setzt die Anforderungen des Gateways um und ist recht einfach gehalten:

<route>
<from uri="mqtt:mqtt.temp.receiver?host=tcp://localhost:1883& amp;subscribeTopicNames=iotdemo/#/#&amp;userName=admin&amp;password=change12_me"/>
<bean ref="myHelper" method="enhanceMessage" bean-Type="com.redhat.demo.smart_gateway.MyHelper"/>
<unmarshal ref="bindyDataFormat"/>
<convertBodyTo type="java.lang.String"/>
<to uri="activemqDatacener:queue:message.to.rules_cep"/> 
</route>

Eine kurze Analyse der Codefragmente veranschaulicht die Arbeitsweise. Zunächst zu dieser Zeile:

<from uri="mqtt:mqtt.temp.receiver?host=tcp://localhost:1883&amp;subscribeTopicNa-mes=iotdemo/#/#&amp;userName=admin&amp;password=change12_me"/>

Der Code verwendet die MQTT-Komponente von Apache Camel und wartet darauf, ob neue Nachrichten zum Topic iotdemo/#/# vorliegen. Die beiden #-Zeichen sind Wildcards, mit denen das Gateway Nachrichten zu allen Topics empfangen kann, die dieser Namenskonvention entsprechen. Das erste # steht für den Sensortyp, z. B. Temperatur oder Luftfeuchtigkeit, das zweite für die Unique ID des Sensors oder Geräts.

<bean ref="myHelper" method="enhanceMessage" bean-Type="com.redhat.demo.smart_gateway.MyHelper"/>

Die empfangene Nachricht und all ihre Metadaten werden zur Verarbeitung an ein benutzerdefiniertes Java Bean weitergeleitet. Es nimmt den CSV-Wert aus der MQTT-Nachricht entgegen und erweitert ihn um Details aus der Definition des MQTT-Topics, über den die Daten gesammelt wurden. Das Java Bean selbst wird später noch einmal Gegenstand einer weiteren Betrachtung sein.

<unmarshal ref="bindyDataFormat"/>
<convertBodyTo ty-pe="java.lang.String"/>

Hat das Java Bean den CSV-Wert um alle relevanten Informationen angereichert, kommt die Bindy-Komponente von Apache Camel zum Zug, um den CSV-Wert in das XML-Format zu transformieren.

<convertBodyTo type="java.lang.String"/>

Um von Anfang an möglichst flexibel zu sein, bietet es sich an, die XML-Nachricht in einen String umzuwandeln:

<to uri="activemqDatacener:queue:message.to.rules_cep"/>

Im letzten Schritt der Camel Route wird die Nachricht an den Message Broker weitergeleitet, der sich auf einem Remotesystem im Rechenzentrum oder in der Cloud befindet.

Die Java Bean als Hilfsmittel

Wer Programmcode erstellt, weiß, dass es immer viele Möglichkeiten gibt, um ein bestimmtes Ziel zu erreichen. Um den Payload einer Apache-Camel-Nachricht um Metadaten anzureichern, kommt in der Camel Route eine Java Bean zum Einsatz. Der wichtigste Teil davon ist folgender:

public class MyHelper { 

  @Handler
public String enhanceMessage( String body,  Exchange exchange  ) {     String res = null;

res = addDeviceID(body, exchange);
res = addDeviceType(res, exchange);
res = appendTimestamp(res, exchange);

return res;
}

Alle Member-Funktionen, die mit @Handler annotiert sind, können in einer Camel Route verwendet werden. Apache Camel ruft diese Handler auf, übergibt Body und Exchange der Nachricht und hält diese Informationen während des gesamten Message Routings vorrätig. Diese benutzerdefinierte Funktion lässt sich flexibel einsetzen, Grenzen werden nur durch Java gesetzt.

Abb. 2: Das IoT-Set-up im Überblick (Quelle: Red Hat)

Fazit

Zusammenfassend ist das Smart Gateway in der Lage, Nachrichten zu empfangen und weiterzuleiten (Abb. 2). Das Einzige, was dann noch zu tun bleibt, ist die Sensoren so zu platzieren, dass sie auch tatsächlich etwas messen können. Auch wenn es sich insgesamt um ein einfaches Set-up handelt, verdeutlicht das vorgestellte Beispiel anschaulich die Idee und das Konzept, wie sich ein Smart Gateway implementieren lässt.

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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.