Wie IOT-Systeme miteinander sprechen (Teil 2)

Posted on Posted in Technologie

In Teil 1 wurde eine kurze Einführung in MQTT gegeben – ein sehr flexibles Protokoll, das für IOT gemacht zu sein scheint.

Also warum haben wir uns trotzdem gegen diesen Standard entschieden?
Zwar sind Sender und Empfänger bei MQTT lose voneinander gekoppelt, jedoch existiert immer ein zentraler Rechner, über den alle Nachrichten geschick werden: Der Broker.

Daraus ergibt sich eine Reihe von Nachteilen:

  • Fällt der Broker aus, kann das gesamte System nicht mehr kommunizieren.
  • Liegt der Broker in der Cloud, stellt das ein Sicherheitsrisiko dar, weil wirklich alle Daten ins Internet gelangen, auch wenn zwei miteinander sprechende Geräte direkt nebeneinander liegen. Was ein Angreifer wohl alles tun kann, wenn er die Kontrolle über den Broker erlangt?!
  • Liegt der Broker in der Cloud, sind die gekauften Module nutzlos, falls der Hersteller den Betrieb seiner Online-Dienste einstellt.
  • Soll der Broker offline in den eigenen 4 Wänden arbeiten, wird ein zusätzliches Gerät benötigt (das könnte auch ein Raspberry Pi sein).

Viele IOT-Hersteller entscheiden sich leider für die Cloud-Lösung, da sie am einfachsten umzusetzen ist und flexible Geschäftsmodelle damit möglich sind. (und vielleicht weil alle Marketing-Abteilungen überzeugt zu sein scheinen, dass Cloud in jeder Hinsicht die Zukunft ist?)

Bei den Supplets haben wir uns für ein dezentrales System entschieden, d.h. es gibt keinen zentralen Broker. Jeder zusammengesteckte Stapel ist ein eigener kleiner Server, der seine Fähigkeiten als Ressource bereitstellt. Alle Supplets bilden zusammen ein Mesh-Netzwerk, d.h. sie sind untereinander erreichbar und in der Kommunikation völlig gleichberechtigt. Fällt mal ein Supplet aus, betrifft das die übrigen Module in der Regel nicht.

Das Protokoll auf dem wir aufbauen heißt IoTivity. Es ist ein offener Standard, der auf CoAP basiert. Als Verschlüsselung kommt (auch in den eigenen 4 Wänden) TLS zum Einsatz, worauf auch die Sicherheit aktueller Webseiten und -dienste aufbaut.

Für die Experten unter euch: CoAP basiert auf dem REST-Paradigma mit Methoden und URLs. Es ist HTTP stark nachempfungen, nur deutlich effizienter, da alles binär kodiert wird und auf das nötigste reduziert wurde.
IoTivity definiert bestimmte REST-Ressourcen, damit alle Geräte eine gemeinsame Basis für die Kommunikation haben und stellt zusätzlich Mechanismen für das Finden bestimmter Ressourcen-Typen (siehe Resource-Discovery) bereit.

Aber woher wissen die Supplets, wohin sie ihre Daten schicken sollen?

Der Nutzer legt in einer App die Regeln fest. Z.b. „WENN die Haustür abgeschlossen wird DANN soll der Strom an den Steckdosen x,y UND das Licht abgeschaltet werden.“

Die Regel wird direkt auf das Supplet gespielt, das den auslösenden Sensor besitzt. Wenn also das entsprechende Supplet an der Tür feststellt, dass diese geschlossen wird (=Bewegung in bestimmte Richtung), dann sendet dieses die Nachricht „ausschalten“ direkt an die Steckdosen-Supplets x,y und das Supplet zur Steuerung einer Lampe.

Dezentrales System (Icons von flaticon.com; FreePik & madebyoliver)

Sollten mehrere Supplets als Auslöser einer Regel fungieren, wird die selbe Regel auf mehrere Module gespielt.

Verbindungen, die über die eigenen 4 Wände hinaus gehen, werden direkt getunnelt und verschlüsselt. Die Daten landen niemals auf einem Server oder in einer Cloud, solange der Nutzer das nicht ausdrücklich wünscht.

Noch Fragen? Schreibt sie einfach als Kommentar unter diesen Blog-Eintrag.

Let’s Supp!

One thought on “Wie IOT-Systeme miteinander sprechen (Teil 2)

Comment Supplets - let's supp!