Seite 2: openHAB

Inhaltsverzeichnis

Ein Schritt nach vorn: openHAB

Die Herausforderung für den Entwickler besteht heute darin, diese Insellösungen, sofern sie überhaupt eine Anbindung an andere Systeme anbieten und nicht prinzipiell isolierte Silos darstellen, unter einen Hut zu bringen. Glücklicherweise ist ein großer Teil dieser Arbeit vollbracht. Das Projekt openHAB hat es sich zur Aufgabe gemacht, die vielen Protokolle und Systeme, die sich auf dem Markt der Heimautomatisierung und darüber hinaus entwickelt haben, auf einer herstellerunabhängigen Plattform zur Verfügung zu stellen. OpenHAB ist auch die Basis für das Eclipse-Smart-Home-Projekt, das zusammen mit anderen Projekten das Eclipse-IoT-Ökosystem bildet.

Interessant an der Plattform ist vor allem, dass die Steuerung der darüber verbundenen Komponenten im "Hoheitsbereich" des Benutzers, nämlich in der eigenen Wohnung, stattfindet und damit auch alle Daten, die diese Komponenten erzeugen, dort verbleiben. Der zentrale Controller, der alle vernetzten Geräte miteinander verbindet, läuft typischerweise dort, wo die Geräte stehen, zum Beispiel auf einem kleinen Einplatinen-Computer wie Raspberry Pi oder Banana Pi.

Während die herstellerspezifischen Angebote nahezu immer Gerät und Steuerungsanwendung über eine Cloud-Plattform koppeln und damit dem Eigentümer die Kontrolle über die eigenen Daten weitgehend entziehen, verlassen diese Daten bei Einsatz der Eclipse-Plattform die eigenen vier Wände nur in dem Umfang, den der Eigentümer explizit freigibt. Zwar bieten Cloud-Dienste Vorteile beim Remote-Zugriff auf die heimische Infrastruktur. Es muss sich jedoch jeder fragen, ob dieser Vorteil tatsächlich durch die weitgehende Preisgabe des eigenen Nutzerverhaltens erkauft werden soll.

Denn zweierlei Gefahren bestehen: Der Mensch wird zunehmend "gläsern" und verliert seine Autonomie. Denn ab dem Moment, in dem seine Daten das heimische Netz verlassen, hat er keinen Einfluss mehr darauf, welche Schlussfolgerungen Analysesysteme aus seinen Nutzerdaten ziehen und wie diese Rückschlüsse anschließend wiederum Einfluss auf das eigene Leben haben. Und selbst wenn, was die Anbieter ja regelmäßig behaupten, die gewonnenen Daten von diesen nur zweckbestimmt verwendet werden, zeigen die nahezu wöchentlich immer wieder bekannt werdenden erfolgreichen Hackerangriffe, dass auch die Daten vertrauenswürdiger Anbieter gelegentlich ungewollt in die falschen Hände geraten können.

Komplexität und Fehleranfälligkeit

Spätestens seit Bekanntwerden der Chaostheorie in den 1980er-Jahren ist bekannt, dass komplexe Systeme auch auf kleine Störungen mit unvorhersehbarem Verhalten reagieren können. Im Internet der Dinge sollen nun zahlreiche Komponenten zusammenwirken und sich gegenseitig beeinflussen, um Tätigkeiten zu automatisieren, die bisher unter der Kontrolle von Menschen stattfinden. Da praktisch alle technischen Geräte eine endliche Lebensdauer haben und irgendwann anfangen, sich fehlerhaft zu verhalten, ist gerade bei dieser Automatisierung besondere Sorgfalt angebracht.

Auch wenn die Folgen fehlerhafter Messwerte in einem Haus nicht so schwere Folgen haben wie in einem Flugzeug, müssen Entwickler davon ausgehen, es gelegentlich mit ungenauen oder falschen Daten umgehen zu müssen. Aus diesem Grund ist es wichtig, jede Steuerungslogik so auszurichten, dass sie diese Tatsache berücksichtigt oder zumindest erkennen kann. In vielen Situationen ist es daher sinnvoll, sich an das Motto "crash early" der "Pragmatic Programmer" Andrew Hunt und David Thomas zu halten und zu beachten: "If it can't happen, use assertions to ensure that it won't" [2].

Übertragen auf die Softwareentwicklung im IoT-Umfeld bedeutet das vor allem: Werte, auf die sich die Steuerlogik bezieht, auf ihre Sinnhaftigkeit hin zu überprüfen. Ein Beispiel: Während die meisten Temperatursensoren Messwerte von deutlich unter dem Gefrierpunkt bis jenseits der 100 Grad ermitteln können, ist das zu erwartende Temperaturspektrum bei den meisten Einsatzbereichen jedoch viel kleiner. Ein großer Teil der möglichen Messwerte lässt sich also von vornherein als unrealistisch ausschließen und deutet, falls er doch auftritt, auf einen Sensorfehler oder Probleme in der Betriebsumgebung hin.

Das Gleiche gilt für Aktoren. In vielen Fällen bildet eine Steuerung einen Regelkreis ab, bei dem ein Sensorwert (z. B. eine Temperatur oder ein Flüssigkeitspegel) bewirkt, dass ein Aktor (Heizung, Pumpe) aktiviert wird und dass dessen Wirkung dann nach einer bestimmten Zeit am Sensor erkennbar sein sollte. In solchen Regelkreisen ist das Fehlen einer Veränderung am Sensor nach einer gewissen Zeitspanne ebenfalls ein Anzeichen für ein potenzielles Problem.

Was sich zunächst selbstverständlich und logisch anhört, wird in der Praxis oft ignoriert. Und dann kommt es zu Vorfällen wie diesem: In einem Haushalt hatte sich ein Schlauch in der Waschmaschine gelöst. Dadurch floss das Wasser, das in der Trommel landen sollte, von der Maschine einfach in den Keller. Das hatte zur Folge, dass der Wasserstandsfühler in der Trommel, der den Zulauf steuert, nie aktiviert wurde. Mit dem fatalen Ergebnis: Über mehrere Stunden pumpte die Maschine Wasser in den Keller, bis die Hausherren das Problem sahen und die Maschine abschalteten. Eine etwas ausgefeiltere Logik, die berücksichtigt, wie lange die Pumpe normalerweise braucht, um die Trommel zu füllen, hätte das verhindert. Schlägt der Wasserstandsfühler nach dieser Zeit nicht an, deutet das auf ein Problem hin, und die Elektronik könnte den Waschgang abbrechen ("crash early").

Bei der Programmierung von IoT-Systemen ist also darauf zu achten, Zustände zu erkennen, die außerhalb des erwarteten Rahmens liegen, und dann so darauf zu reagieren, dass der potenzielle Schaden minimiert wird. Derartige Überlegungen beschränken sich allerdings nicht nur auf die Implementierung der Steuerlogik, sondern müssen auch das Gesamtsystem einschließlich der Aktoren und Sensoren mit einbeziehen. Insbesondere ist darauf zu achten, dass im Falle eines Versagens der Steuerung (z. B. bei einem Stromausfall) alle Aktoren automatisch in einen unproblematischen Zustand zurückfallen. Passt man an der Stelle nicht auf, kann gerade das Abschalten eines Systems aufgrund der Erkennung eines Fehlerzustandes erst recht zum Problem führen.