Im vorigen Teil unser Serie haben wir gesehen, wie vielfältig der Smart-Home-Markt ist und dass es nicht die “eine” beste Lösung gibt. Vielmehr haben alle Systeme ihre Stärken und Schwächen. Es gilt also, die jeweiligen Stärken in ein Gesamtsystem zu kombinieren. Hierbei stellt man schnell fest, dass inzwischen fast jeder Hersteller, bzw. jede Allianz, zu einer eigenen Lösung gefunden hat, wie Geräte per Software ansprechbar sind. Dabei sind auf den ersten Blick die Möglichkeiten nicht allzu vielfältig: Sensoren liefern einerseits Messdaten - also einfache (Fließkomma-)Zahlen - und Aktoren empfangen diskrete Kommandos wie “an”,“aus” oder auch Prozentwerte. Wäre es für Smart-Home-Anwendungen nicht schön, wenn dies für jedes Gerät auf ein und die gleiche Weise geschehen könnte? Wir suchen also eine Abstraktionsschicht, die uns unabhängig von der konkreten Hardware macht.
Auf der Suche nach einem universellen Typsystem
Wie uns die Informatik gelehrt hat, lassen sich alle Informationen in Form von Zahlen darstellen und in Objekten repräsentieren - was ist also einfacher, als einen Gerätetyp als abstrakte Klasse mit Properties mit primitivem Datentyp zu beschreiben? Mögliche Kommandos lassen sich als Methoden definieren, die je nach konkreter Klasse gerätespezifisch ausimplementiert sein können - fertig ist unsere Geräteabstraktion (siehe Abbildung 2a)!
Doch halt - was genau ist eigentlich der oben genannte “Gerätetyp”? Bei einer Abstraktion kann dies nicht ein konkretes Gerätemodell sein, sondern muss sich auf eine Gerätegattung beziehen, wie z.B. “Fernseher”. Wie kann man aber allgemeingültig einen Fernseher und seine Funktionen in einer abstrakten Klasse beschreiben? Zwischen dem alten Röhrenfernseher mit Einschalter, Lautstärkeregler und drei Programmen und einem aktuellen Smart-TV mit drei verschiedenen Tunern, integriertem Festplattenrecorder und eigenem AppStore liegen Welten. Eine Option wäre es, einfach den größtmöglichen Umfang zu modellieren und diverse Properties und Methoden als optional zu deklarieren. Doch wie schreibt man eine Anwendung gegen ein Objekt, bei dem 95% der angebotenen Methoden eine NotImplementedException werfen? Und wie sollte man den größtmöglichen Umfang bestimmen können? Wir müssen also einsehen, dass dies eine Sackgasse ist - die wiederverwendbaren Bestandteile müssen demnach feingranularer gewählt werden, also auf der Ebene einzelner Funktionen. Ein Gerät ist dann einfach eine Menge von Funktionen (oft auch Capabilities genannt) und unterschiedliche Fernseher haben unterschiedliche große Mengen an Funktionen (siehe Abbildung 2b).
Metadaten - die unvermeidbaren Spezifika
Können Gerätefunktionen nun mit primitiven Datentypen beschrieben werden? Ein An/Aus wird leicht zu true/false, aber schon bei offen/geschlossen ist nicht klar, ob true/false oder false/true die bessere Abbildung ist - das ist eine Frage der Perspektive. Um ein gut verständliches Mapping zu machen, bietet es sich also an, Enumerations zu verwenden. Verständlichkeit bedeutet aber nun gleichzeitig inhärentes Wissen, was am Beispiel einer Waschmaschine gut veranschaulicht werden kann: Allgemein können wir sagen, dass eine Waschmaschine als Funktion die Auswahl des Waschprogramms hat, welches über einen Integer bestimmt werden kann. Wenn wir nun aber eine Enumeration mit 1 = Wollprogramm, 2 = Buntwäsche, usw. einführen, stehen wir wieder vor dem gleichen Dilemma: Unterschiedliche Waschmaschinen haben unterschiedliche Waschprogramme - während die Repräsentation als Integer also abstrakt genug ist, können Enumerations zu spezifisch sein. Das gilt ganz allgemein für jede Einschränkung des Wertebereichs von Funktionen: Welche Frequenzbereich unterstützt ein Tuner? Welche minimale Schrittweite akzeptiert mein Thermostat? Welche maximale Helligkeit liefert meine Wetterstation? All solche Informationen sind also sehr gerätespezifisch und können nicht sinnvoll generalisiert werden - sie sollten als Metadaten an dem abstrakten Modell zur Verfügung stehen.
Sehr ähnlich verhält es sich mit den Einheiten: Liefert ein Sensor Messwerte, so macht er dies in einer bestimmten Einheit. Eine Abstraktionsebene sollte keine Einheit vorgeben, denn ein Temperatursensor im LHC bei CERN wird vermutlich lieber in Kelvin messen, während die Kühlschranktemperatur in Grad Celsius - in den USA aber gerne auch in Grad Fahrenheit - gemessen wird. Bei der Einheit handelt es sich demnach ebenfalls um Metadaten, die für die Interpretation ausgewertet werden können.
Konfiguration als zusätzliche Hürde
Eine spezielle Menge von Gerätenfunktionen bezieht sich ausschließlich auf dessen Konfiguration. Wir möchten diese explizit getrennt von den “operativen” Funktionen betrachten, da sie sich nochmals sehr viel schwieriger abstrahieren lassen. Betrachten wir den Fall eines einfachen Dimmers. Operativ lässt sich dessen Funktion recht einfach beschreiben: Er hat einen Status von x % und akzeptiert einen Wert zwischen 0 und 100, um die gewünschte Helligkeit zu wählen. Um dieses Verhalten aber zu konfigurieren, werden oft zahlreiche Optionen angeboten: Welche Art Leuchtmittel wird verwendet, welche Dimmkurve ist also am besten geeignet? Wie schnell wird der neue Wert angefahren? Darf das angeschlossene Gerät überhaupt gedimmt werden oder soll nur ein- und ausgeschaltet werden? Soll beim Einschalten auf 100% geregelt werden oder auf den zuletzt eingestellten Wert vor dem letzten Abschalten? Man sieht, selbst eine so einfache Funktion kann sehr komplex in ihren Konfigurationsmöglichkeiten sein. Aus diesem Grund ist es ratsam, die Gemeinsamkeiten von Geräten nur auf der operationellen Seite zu suchen und diese zu abstrahieren und mit der Tatsache zu leben, dass es sehr hardware-individuelle Konfigurationsoptionen gibt.
Die Essenz der Dinge
Denkt man näher über den Dimmer nach, so stellt man fest, dass das, was den Anwender interessiert, gar nicht der Dimmer selbst, sondern die daran angeschlossene Lampe ist. Auch ob ein Magnetkontakt geöffnet oder geschlossen ist, ist lediglich sekundär - die relevante Information ist hingegen, ob die Tür offen steht oder nicht. Noch offensichtlicher ist der Fall bei einem Bluetooth-Tag im Hundehalsband: Das Halsband ist auch hier nur Mittel zum Zweck, um den Hund zu lokalisieren. Ebenso interessiert nicht die Temperatur eines Sensors, sondern nur die des Raumes, in welchem er sich befindet. Eine abstrakte Beschreibung braucht also Dinge wie “Haustier”, “Person”, “Tür”, “Raum”, “Lampe” und die Geräte sind nur Hilfsmittel um Informationen über diese zu sammeln oder Aktionen auszulösen. Hierbei redet man üblicherweise von einer Ontologie - also einem festgelegten Begriffssystem, in welchem die Dinge in definierten Beziehungen zueinander stehen (siehe Abbildung 3). Die Beziehungen der Ontologie ergeben die Semantik, d.h. Informationen aus denen konkrete Aussagen abgeleitet werden können, da der Kontext “verstanden” wird.
Eine Ontologie bedeutet aber für eine Geräteabstraktion schwerwiegende Probleme: Der Gerätehersteller kann niemals das Wissen über dessen konkrete Verwendung haben und somit gibt es keine Eingliederung eines Gerätes in die Ontologie “ab Werk”. Vielmehr hat nur der Installateur bzw. Nutzer das notwendige Wissen über den Einsatzzweck, also den Kontext. Ein einfaches Beispiel lässt sich mit einem “Alles-aus”-Use-Case veranschaulichen: Keine noch so gute Geräteklassifikation kann bestimmen, welche Zwischenstecker beim Verlassen des Hauses die angeschlossenen Geräte vom Strom trennen dürfen. Beispielsweise könnte ja auch ein Kühlschrank daran angeschlossen sein, für welchen der Zwischenstecker nur dazu dient, den Energieverbrauch aufzuzeichnen. Solches Wissen muss das System also entweder initial mitgeteilt bekommen oder durch Benutzerinteraktion im Laufe der Zeit erlernen. Ein weiteres Problem ist die Kreativität der Nutzer: Wer weiß schon, wofür dieser einen Magnetkontakt verwendet? Klebt er ihn an ein Fenster, an eine Tür oder vielleicht an den Briefkasten? Oder doch eher an den Kühlschrank, den Safe oder die Mausefalle? Sollen all solche Nutzungsszenarien abgedeckt und semantisch erfasst werden, so muss das Begriffssystem quasi das komplette Vokabular aller in Häusern vorhandenen und verwendeten Dinge umfassen - eine unlösbare Aufgabe. Als Konsequenz der geschilderten Schwierigkeiten muss man ziehen, dass der Nutzer in vielen Fällen für notwendige Zusatzinformationen sorgen muss und es insofern eher Sinn macht, Applikationen so zu gestalten, dass sie nicht notwendigerweise das Wissen über den Kontext selbst benötigen, sondern den Nutzer so führen, dass er den Kontext implizit selbst einfließen lässt, während er seine Use Cases definiert.
Ortsbestimmung
Eine Folgerung aus der Trennung von Gerät (genauer: einer Gerätefunktion) und dessen Verwendung ist, dass der Ort unterschiedlich ausfallen kann. “Alle Lampen im Wohnzimmer abschalten” sollte beispielsweise auch die entsprechenden Schaltkanäle des Schaltaktors im Zählerschrank mit einbeziehen. Ein solcher Schaltaktor hat also als Gerät einen “Installationsort”, hingegen mit seinen Funktionen mehrere verschiedene “Wirkorte”. Diese Unterscheidung is sehr essentiell und deckt sich weitestgehend mit der Trennung von Konfiguration und Operation eines Gerätes: Für die Konfiguration ist dessen Installationsort der wichtige Aspekt, für die tatsächliche tagtägliche Nutzung hingegen die jeweiligen Wirkorte. Auch hier ist es wieder der Installateur oder Nutzer, der dem System mitteilen muss, welche Wirkorte es für die Funktionen eines Geräts in seinem Fall gibt.
Tücken der Laufzeit
Ist erstmal alles klassifiziert, in generischen Einzelfunktionen beschrieben und konfiguriert, gelangt man zu der nächsten Hürde: Dem Laufzeitverhalten. So schön die einmalige statische Beschreibung auch ist, die Dynamik im Betrieb kann alles sehr schnell wieder durcheinander bringen: Abhängig von der (zur Laufzeit gewählten) Betriebsart, kann sich die Menge der angebotenen Funktionen komplett verändern. Eine Heizungssteuerung im Automatikmodus hat beispielsweise deutlich weniger Optionen als im manuellen Modus. Wie kann man solche wechselnden Funktionsumfänge formal sinnvoll beschreiben? Wie oft werden Sensordaten übermittelt? Passiert das in festen Intervallen oder bei Veränderung (bei welcher Schwelle?) des Messwertes? Dieses Verhalten kann entscheidende Auswirkungen auf die Art und Weise haben, wie Applikationen mit diesen Daten interagieren. Was genau passiert nach dem Abschicken eines Kommandos an ein Gerät? Wird es überhaupt sofort übermittelt oder kann dies einige Zeit dauern, bis das Gerät wieder “lauscht”, wie dies oft bei batteriebetriebenen Lösungen der Fall ist? Wie lange dauert die Ausführung des Kommandos? Ein Rollladen braucht beispielsweise eine erhebliche Zeit, um in eine bestimmte Position zu fahren. Welche Fehlerfälle gibt es und wie und wann meldet dies das Gerät? Sind diese “recoverable”, d.h. durch geeignete Fehlerbehandlung abfangbar? Welche Zustände durchläuft ein Gerät bei einer Aktion und wie können gültige Kommandos für gewisse Zustände bestimmt werden? Braucht ein Gerät gar Transaktionalität? Zu diesen Fragestellungen gibt es in der Praxis nur selten ausgereifte Lösungen - die bevorzugte Behandlung ist eine statische Beschreibung mit dann in der Applikation implizit implementierten Fallbehandlungen. Eine wirkliche Abstraktion wird aus diesen Gründen nur selten erreicht. Vielmehr bleiben Applikationen bis zu einem gewissen Grad immer gerätespezifisch, auch wenn dies oft auf den ersten Blick nicht deutlich wird.
Fazit
Zusammenfassend darf man festhalten, dass Geräteabstraktion ein wichtiges und zugleich hochkomplexes Thema ist. Auch die EU Kommission beschäftigt sich derzeit damit und hat eine Untersuchung bestehender Abstraktionen in die Wege geleitet. Erste Berichte dazu wurden unter [1] und [2] veröffentlicht. Als Ergebnis wird eine vereinheitlichte Ontologie in Aussicht gestellt - aufgrund der zahlreichen in diesem Artikel aufgeworfenen Fragen dürfen wir darauf sehr gespannt sein. Im nächsten Teil unserer Serie werden wir uns näher mit den Allianzen, sowie dem aktuellen Stand der Forschung in Smart-Home-Bereich beschäftigen.