Ordnung in den IoT-Dschungel bringen

Alles sauber sortiert

Christoph Czaja, Eldar Sultanow

Das Internet of Things hat inzwischen zahlreiche Frameworks, Cloud-Anwendungen, generische Plattformen und Entwicklungswerkzeuge hervorgebracht. Dieser Artikel schafft Übersicht im Java-IoT-Umfeld.

Die Digitalisierung des gesamten Lebens prägt die derzeitige Diskussion nicht nur in der Informationstechnik, sondern auch in der Gesellschaft. Durch das Vernetzen aller möglichen Geräte entstehen neue Geschäftsmodelle, diffuse Ängste bei den Menschen und vor allem massenweise technische Komponenten und sogenannte Standards, die das Ganze irgendwie handhabbar machen sollen. Den Durchblick kann man hier schnell mal verlieren.

Software-Backend und -Frontend: Für jedes Protokoll existieren Frameworks im Backend. ETL (Extract, Transform, Load) und Analyse lassen sich durch Cloud-Dienste bewerkstelligen, im Frontend erledigen JavaScript-Frameworks die Arbeit (Abb. 1).

Einige der zahllosen Bausteine dienen der Anbindung an die Cloud, andere sind reine Message-Broker, bei wieder anderen handelt es sich um Anwendungsplattformen oder für IoT ausgelegte DevOps-Programme. Das heißt, die verschiedenen Komponenten sind unterschiedlichen Architekturschichten zuzuordnen. Hier hilft eine von den Autoren erstellte Referenzarchitektur weiter (siehe Abbildung 1 und 2). Sie soll Programmierern und Architekten den Überblick über das gesamte Spektrum der Entwicklung von IoT-Anwendungen geben. Eine umfangreiche Linkliste zu den hier vorgestellten Techniken findet man unter ix.de/ix1808118.

Übertragungsstandards

Neben WLAN gibt es weitere Übertragungsstandards: ZigBee ist eine (den IEEE-802.15.4-Standard um eine Netzwerk- und Anwendungsschicht erweiternde) Spezifikation für Drahtlosnetze, die beispielsweise in der Gebäudeautomation, in Sensornetzwerken oder in der Lichttechnik eingesetzt wird. Obwohl der Schwerpunkt auf Netzen mit kurzen Reichweiten liegt, sind auch solche von mehreren Kilometern möglich. Bluetooth ist ein Industriestandard (IEEE 802.15.1) für die Datenübertragung zwischen Geräten über kurze Distanz.

Weiterhin gibt es die WiMAX/IEEE-802.16-Standards, die etwa vom IoT-Serviceanbieter Sigfox und der LoRa Alliance verwendet werden, sowie Mobilfunkstandards wie LTE. Die Mobilfunkbranche schien lange Zeit kein Interesse an industriellen Funk-IoT-Anwendungen zu haben, jedoch hat das 3GPP (3rd Generation Partnership Project – die weltweite Kooperation von Standardisierungsgremien für den Mobilfunkbereich – erstmals Derivate wie NB-IoT speziell für die Machine-to-Machine-Funkkommunikation (M2M) standardisiert. NB-IoT steht für Narrowband IoT und ist ein neuer IoT-Funkstandard, der zum Beispiel im Bereich Smart Metering für Gas- und Wasserzähler eingesetzt wird.

IoT-Anwendung mit MQTT und AWS-Cloud

Das folgende Szenario kombiniert IoT-Client, Message-Broker, Backend und Frontend. Es beschreibt einen in den Branchen Hausautomation, Lebensmittel, Pharma und Logistik typischen Anwendungsfall: die sensorische Temperaturüberwachung. Komponenten sind ein MQTT-Client (AWS IoT bietet eine eigene MQTT-Infrastruktur einschließlich eines MQTT-Clients), ein MQTT-Message-Broker (von AWS IoT), eine Datenbank (die auf Cassandra basierende Zeitreihendatenbank KairosDB) und ein Frontend zum Anzeigen der Sensordaten (Grafana).

Listing 1: MQTT-Client sendet Nachrichten an die AWS-Cloud

private AWSIotMqttClient getClient() {
  if (this.client == null) {
    KeyStorePasswordPair pair = SampleUtil.getKeyStorePasswordPair ⤦
 (this.certificateFile, this.privateKeyFile);
    this.client = new AWSIotMqttClient(this.clientEndpoint, ⤦
 this.clientId, pair.keyStore, pair.keyPassword);
    this.client.connect();
  }
  return this.client;
}
protected void publish(String topic, Map<String, Object> payload) {
  NonBlockingMessage message = new NonBlockingMessage(
                         topic, this.qos, getObjectMapper() ⤦
 .writeValueAsString(payload));
  getClient().publish(message, this.timeout);
}

Um einen Client zu entwickeln, der mit dem Message-Broker in der AWS-Cloud kommuniziert, benötigt der Entwickler das AWS IoT Device SDK. Entweder erstellt er in Eclipse ein Maven-Projekt mit den Abhängigkeiten aws-iot-device-sdk-java und aws-iot-device-sdk-java-samples oder er bezieht sie als Java Archive von GitHub. Einen Codeausschnitt für die Implementierung des IotMqttClient zeigt Listing 1.

AWS sichert die Client-Server-Kommunikation über Zertifikate ab. Dieses Feature muss nicht selbst programmiert werden, man kann (wie im Beispiel) die vorgefertigten Funktionen der AWS IoT Device SDK nehmen. Clientzertifikat und privater Schlüssel werden in das Verzeichnis src\test\resources\ kopiert.

Listing 2: Clientseitiger Start der Temperatursensoren

public class TemperatureSensorTest {
  String clientEndpoint = "<prefix>.iot.<region>.amazonaws.com";
  String clientId = "ABCDEFG1234";
  String certificateFile = "src/test/resources/⤦
 client-certificate.pem.crt";
  String privateKeyFile = "src/test/resources/ ⤦
 client-private.pem.key";
  String topic = "myIoTSensor";

  @Test
  public void evaluatesExpression() {
    List<Thread> threads = new LinkedList<>();
    for (int i = 0; i < 10; i++) {
      TemperatureSensor sensor = new TemperatureSensor ⤦
 (clientEndpoint, clientId + Integer.toString(i),
                      certificateFile, privateKeyFile, type, topic);
      Thread thread = new Thread(new ⤦
 TemperatureSensorTestRunnable(30, sensor));
      thread.start();
      threads.add(thread);
    }
    for (Thread t : threads) {
        t.join();
    }
  }
  private class TemperatureSensorTestRunnable implements Runnable {
    @Override
    public void run() {
      sensor.connect();
      for (int i = 0; i < this.loops; i++) {
        sensor.publish(6 * r.nextFloat() + 2);
      }
      sensor.disconnect();
    }
  }
}

Der Temperatursensor erbt von IotMqttClient und veröffentlicht nach dem Publish-Subscribe-Prinzip die Temperaturdaten einschließlich Seriennummer, Zeitstempel und Temperaturwert. Den Code für die eigentliche Ausführung der Sensoren zeigt Listing 2. Angestoßen wird die Routine mit dem Befehl mvn test. Zehn simulierte Sensoren erzeugen jeweils 30 zufällige Temperaturwerte, die zwischen 2 °C und 8 °C liegen. Jeder Sensor hat eine eindeutige ID, sodass sich später jeder Messwert eindeutig zuordnen lässt.

Aufsetzen der EC2-Instanz

Zur Cloud-Einrichtung benötigt man Ressourcen in einer AWS-Region. Zuerst wird eine EC2-Instanz erzeugt, die die Backend-Bausteine hostet.

Folgende vier Schritte sind notwendig:

Schritt 1 – ID der VPC-Sicherheitsgruppe anlegen: Man merkt sich die Group ID der default VPC security group. Sie hat die Form sg-XXXXXXXX und wird später beim Erstellen der Security Group für die EC2-Instanz benötigt.

Schritt 2 – EC2-Instanz erzeugen: Man wählt das Amazon Machine Image amzn2-ami-hvm-2017.12.0.20180115-x86_64-gp2 (ami-1b2bb774), den Instanztyp General purpose t2.small und fügt unter Advanced Details die in Listing 3 angegebenen User Data hinzu. Hinweis: Cassandra verweigert den Start bei weniger als 2 GByte RAM.

Listing 3: Backend und Frontend auf der EC2-Instanz

#!/bin/bash
yum install  -y java-1.8.0-openjdk
cat <<EOT > /etc/yum.repos.d/cassandra.repo
[cassandra]
name=Apache Cassandra
baseurl=https://www.apache.org/dist/cassandra/redhat/311x/
gpgkey=https://www.apache.org/dist/cassandra/KEYS
EOT
yum install -y cassandra
service cassandra start
wget https://github.com/kairosdb/kairosdb/releases/download/v1.2.0/ ⤦
 kairosdb-1.2.0-1.tar.gz
tar -xvzf kairosdb-1.2.0-1.tar.gz -C /opt
sed -i 's/kairosdb.service.datastore=org.kairosdb.datastore.h2. ⤦
 H2Module/#kairosdb.service.datastore=org.kairosdb.datastore.h2. ⤦
 H2Module/' /opt/kairosdb/conf/kairosdb.properties
/sed -i's/#kairosdb.service.datastore=org.kairosdb.datastore. ⤦
 cassandra.CassandraModule/kairosdb.service.datastore=org. ⤦
 kairosdb.datastore.cassandra.CassandraModule/'
/opt/kairosdb/conf/kairosdb.properties   / 
nohup /opt/kairosdb/bin/kairosdb.sh run &
wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/ ⤦
 grafana-5.0.3.linux-x64.tar.gz 
/opt/grafana-5.0.3/bin/grafana-cli plugins install grafana- ⤦
 kairosdb-datasource
cat <<EOT > /opt/grafana-5.0.3/conf/defaults.ini
[plugin.kairosdb]
path = /var/lib/grafana/plugins/grafana-kairosdb-datasource
EOT
cat <<EOT > /opt/grafana-5.0.3/conf/provisioning/ ⤦
 datasources/kairosdb.yaml
datasources:
 - name: KairosDB
   type: grafana-kairosdb-datasource
   access: proxy
   url: http://localhost:8080
EOT
cd /opt/grafana-5.0.3/
nohup ./bin/grafana-server web &

Das Skript enthält Installationsroutinen für Java, Cassandra und KairosDB. Yum ist das Paketmanagementsystem von Red Hat, Fedora und CentOS. Die Images basieren auf einer Amazon-eigenen Linux-Distribution, die ebenfalls yum nutzt.

cat <EOT fügt einen mehrzeiligen String (abgeschlossen mit dem Label EOT) in die Datei cassandra.repo ein. wget lädt das (binäre) KairosDB-Archiv herunter, und tar -x entpackt es, wobei -C /opt bedeutet, dass das Tool tar, bevor es irgendeine Operation (hier Extrahieren) durchführt, in das Verzeichnis /opt wechseln muss.

sed ist in der Linux-Welt kein trivialer Befehl:

sed -i 's/kairosdb.service.datastore=... kommentiert in der Konfigurationsdatei /opt/kairosdb/conf/kairosdb.properties diesen String aus:

kairosdb.service.datastore=org.kairosdb.datastore.h2.H2Module

Mit der zweiten sed-Anweisung erfolgt analog eine Einkommentierung. Abschließend wird Grafana mit der KairosDB verknüpft. Der Befehl nohup startet die Dienste und Programme im Hintergrund und trennt sie so von der Login-Shell. Das Programm läuft also weiter, auch wenn man sich abgemeldet hat.

Schritt 3 – Konfigurieren der Sicherheitsgruppe: Unter dem Punkt Create a new security group gibt man die Bezeichnung Security group name: ec2 an und definiert einige Regeln (siehe Tabelle auf der nächsten Seite).

Schritt 4 – Schlüssel für EC2-Instanz generieren: Abschließend sollte man sich die öffentliche und die private IP der Instanz aufschreiben. Zum späteren Verbinden mit der EC2-Instanz wird ein neuer Schlüssel generiert und lokal gespeichert.

Lambda-Funktion implementieren

Nachdem die EC2-Instanz erstellt ist, erzeugt der Entwickler eine Lambda-Funktion. AWS Lambda ist ein serverloser Datenverarbeitungsservice, der eine selbst erstellte Routine beim Eintreten bestimmter Ereignisse ausführt. Hier schickt die Funktion MQTT-Nachrichten an die KairosDB. Hierfür braucht der Entwickler eine neue Rolle (Choose the service that will use this role: Lambda). Anschließend erstellt er die Funktion via Author from scratch (Name: PushToKairosDBLambda, Runtime: Python 3.6, Role: Create a custom role, Role Name: RolesPushToKairosDBLambdaRole). Den Code fügt er inline ein (Listing 4).

Listing 4: Sensordaten in KairosDB übertragen

from botocore.vendored import requests
import os

def lambda_handler(event, context):
    url = "http://" + os.environ['KAIROSDB_HOST'] + ":" + ⤦
 os.environ['KAIROSDB_PORT'] + "/api/v1/datapoints"
    data = '''[{
      "name": "%(metric)s",
      "datapoints": [[%(timestamp)s, %(number)03f]],
      "tags": {
          "type":%(type)s,
          "id": %(id)s
      },
      "ttl": %(ttl)d
    }]''' % {"metric":os.environ['KAIROSDB_METRIC_NAME'],"timestamp":event[' ⤦
timestamp'],"number":float(event['temperature']),"type":event['type']," ⤦
 id":event['serialNumber'],"ttl":int(os.environ['KAIROSDB_TTL'])}
    response = requests.post(url, data=data)
    try:
        output = response.json()
    except ValueError:
        output = response.text
    return output

Beim Schreiben der Temperaturdaten in die Datenbank hilft der AWS-Lambda-Service. Er fängt die MQTT-Nachrichten ab und führt dann eigenen Code aus. Listing 4 definiert die URL der KairosDB und veranlasst per requests.post(url, data=data) das Speichern der Daten.

Vier Umgebungsvariablen sind notwendig: KAIROSDB_HOST (die private IP-Adresse der EC2 Instance), KAIROSDB_PORT (8080), KAIROSDB_METRIC_NAME (iot.sensor.temperature) und KAIROSDB_TTL (86400). Unter Basic settings wird ein Timeout auf 20 Sekunden gesetzt. Unter Network muss der Entwickler das VPC Default vpc-xxxxxxxx angeben und alle drei Subnetze unter Subnets hinzufügen. Unter Security Groups fügt er die Default-VPC security group sg-XXXXXXXX hinzu. Die Rolle benötigt noch Rechte, um Netzwerk-Interfaces anzulegen. Dazu genügt das Öffnen der Rolle und ein Klick auf Add policy und die Wahl von AWSLambdaVPCAccessExecutionRole.

Konfiguration des Message-Brokers

Der Message-Broker nimmt die Nachrichten der Sensoren entgegen und leitet sie weiter an die Lambda-Funktion. Als Topic muss myIoTSensor ausgewählt und eine Regel erstellt werden. Dies geschieht in der IoT-Konsole mit Act, gefolgt von Create a rule. Als Namen für die Regel nimmt man zum Beispiel myIoTSensorRule.

Unter Message source nun noch die neueste SQL-Version auswählen und als Attribut * angeben. Das bedeutet, dass die gesamte durch die Regel erzeugte Nachricht gesendet werden soll. Im Feld Topic filter wird myIoTSensor eingegeben und bei Set one or more actions wählt man unter Invoke a Lambda function passing the message data die Funktion PushToKairosDBLambda aus.

Im Panel unter Verwalten/Dinge dann noch das erstellte „Ding“ auswählen und aus dem Abschnitt Interact die HTTPS-Adresse kopieren. Sie hat das Format <prefix>.iot.<region>.amazonaws.com und wird später im MQTT-Client benötigt. Im Client (Listing 2) muss ein Endpoint definiert sein, der dieser HTTPS-Adresse aus dem Thing myIoTSensor entspricht.

Anzeige der Oberfläche

Zeitlicher Verlauf der gemessenen Temperaturen für alle zehn Sensoren (Abb. 3).

Die Temperaturen visualisiert das Framework Grafana, das auf der EC2-Instanz läuft. Um es aufzurufen, braucht man einen Tunnel über PuTTY auf die EC2-Instanz. In PuTTY gibt man den privaten Schlüssel an und richtet einen Tunnel von Lokal: 3000 nach Remote: localhost:3000 ein (Abbildung 3).

MQTT ist das seit 2011 verfügbare IoT-Standardprotokoll, betreut von der unabhängigen Organization for the Advancement of Structured Information Standards (OASIS). Es ist effizient, skalierbar (bis zu mehreren Hunderttausend Clients pro Server), hat kaum Overhead, setzt das Publish-Subscribe-Pattern sowie echte Push-Kommunikation um und ist für M2M-Anwendungsfälle konzipiert. MQTT ist für das Übertragen von Nachrichten über unzuverlässige (etwa mobile) Netzwerke und für den Einsatz auf Geräten mit wenig Speicher und Rechenleistung ausgelegt. Es findet sowohl in der Automobilindustrie (Connected Cars) und im Energiesektor als auch in der Gebäudeautomation Anwendung. Seit 2016 ist MQTT ISO-Standard (ISO/IEC 20922). Eine praktische Anwendung findet man im Kasten „IoT-Anwendung mit MQTT und AWS-Cloud“.

AMQP steht für Advanced Message Queuing Protocol und ist ein offener Standard, der ein binäres Netzwerkprotokoll auf Anwendungsebene etabliert. Es wickelt die Kommunikation zwischen Client und Message-Broker beziehungsweise zwischen verschiedenen Message-Brokern ab. AMQP-fähige Message-Broker sind zum Beispiel RabbitMQ, Apache ActiveMQ, Apache Qpid, SwiftMQ, Microsoft Azure Service Bus und Red Hat Enterprise MRG.

XMPP steht für Extensible Messaging and Presence Protocol, hieß früher Jabber und ist ein XML-Kommunikationsprotokoll (häufig von Instant Messengern verwendet), das aufgrund des durch XML verursachten großen Overheads im IoT-Bereich selten eingesetzt wird. Es ist sogar umgekehrt – selbst Facebook nutzt nun anstelle von XMPP das IoT-Protokoll MQTT für den Chat.

CoAP (Constrained Application Protocol) basiert auf UDP und wird oft als das „HTTP für IoT“ bezeichnet. Es implementiert das Request-Response-Pattern – das grundlegende und am weitesten verbreitete Client-Service-Interaktionsmuster – und ist effizienter als HTTP, da das Protokoll inklusive aller Header binär vorliegt. REST-APIs sind mit CoAP einfach umsetzbar und es existieren sogar HTTP-/CoAP-Proxies. Weil CoAP auf UDP basiert, kann ein Client keine bidirektionale stehende Verbindung (wie etwa im Falle von TCP) initiieren. Da jedoch CoAP in der Praxis primär für Wireless Sensor Networks verwendet wird, ist das kein Problem, denn hierbei spielen NATs (Network Address Translation) im Gegensatz zur Kommunikation über das Internet meist keine Rolle.

HTTP, das Urgestein unter den Protokollen, bleibt für Request-Response-IoT-Kommunikation – vor allem im Zusammenspiel mit HTTP RESTful APIs – immer noch die erste Wahl. Aufgrund des großen Protokoll-Overheads ist es für Anwendungen, bei denen die Menge der übertragenen Daten relevant ist (etwa wenn mobile Netzwerke im Spiel sind), eher ungeeignet. Weiterhin erlaubt zwar das Request-Response-Pattern eine 1-zu-1-, jedoch nicht eine 1-zu-n-Kommunikation. Deshalb eignet sich HTTP nicht, wenn eine Nachricht an viele Empfänger gleichzeitig versendet werden soll.

OPC UA (Unified Architecture) ist ein industrielles M2M-Kommunikationsprotokoll, das Maschinendaten (Regelgrößen, Messwerte, Parameter) transportieren und maschinenlesbar semantisch beschreiben kann. Es ist ein De-facto-Standard im Automatisierungsbereich und für Industrie 4.0 beziehungsweise für das Industrial Internet of Things (IIoT) gesetzt. OPC UA basiert auf AMQP und hat den sicheren, verlässlichen, hersteller- und plattformneutralen Austausch von Automatisierungsdaten zum Ziel. Es glänzt in Supervisory-Control-and-Data-Acquisition-Systemen (SCADA) und gilt als schwergewichtigeres MQTT. Allerdings wird OPC UA mit Publisher-Subscriber-Mechanismen per UDP und TSN (Time-Sensitive Networking) erweitert. TSN ist ein neuer Standard in der industriellen Kommunikationstechnik, dessen Entwicklung vor allem von der Automobilindustrie vorangetrieben wird. Das zuständige Team gehört zur IEEE-802.1-Arbeitsgruppe.

LWM2M ist ein von der Open Mobile Alliance (OMA) entworfenes Nachrichtenprotokoll zum Verwalten von Geräten. Es basiert auf CoAP und definiert Schnittstellen für das Bootstrapping, die Geräteerkennung und die Registrierung sowie für das Gerätemanagement. Es unterstützt die Parametrisierung und Überwachung der Geräte ebenso wie das Update der Firmware. LWM2M dient der Kommunikation zwischen LWM2M-Server und -Client. Der LWM2M-Server kann ein Knoten in einem privaten oder öffentlichen Netz sein, der Client in einem Gerät eingebettet sein.

Kommunikationswerkzeuge