Standards, Open Source und Forschung

Thomas Eichstädt-Engelen

Kai Kreuzer

Auch wenn in Fachkreisen schon lange über das Smart Home diskutiert und geforscht wird und es sicher auch schon den einen oder anderen (Smart)Häuslebauer gibt, so ist das Thema “Smart Home” (leider) immer noch kein Massenphänomen. Zu umfangreich ist das Angebot schon jetzt und es kommen täglich neue Produkte auf den Markt. Zu selten finden sich echte Spezialisten, die bei der Beratung, bei der Installation und vor allem bei der unweigerlich folgenden Erweiterbarkeit helfen können (siehe auch Teil 2 dieser Artikelserie).

Die Ursache für die große Unsicherheit lässt sich dabei auf technischer Ebene recht schnell ausmachen: die meisten angebotenen Produkte sind schlicht inkompatibel und können daher nicht miteinander kombiniert werden. Zum Einen liegt das an den unterschiedlichen Protokollen auf der Transport-Ebene. Hier konkurrieren Funkprotokolle wie Z-Wave, BidCOS, EnOcean, ZigBee, Bluetooth und WiFi gegen die kabelgebundenen Systeme und unter diesen wiederum die Powerline-basierten Lösungen gegen die Systeme mit zusätzlichen Steuerleitungen. Selbst wenn man dieses Problem gelöst und sich auf ein einheitliches Transport-Protokoll wie beispielsweise IP geeinigt hätte, gäbe es auch auf den darüber liegenden Schichten derzeit noch keine guten Antworten auf offene Fragen, wie etwa nach der protokollübergreifenden Repräsentation von Geräten oder Regeln oder dem einheitlichen Einrichtungsprozess. Auch hier kochen viele Hersteller lieber ihr eigenes Süppchen anstatt an gemeinsamen Ideen zu arbeiten.

Dabei liegen die Lösungen für das Problem unterschiedlicher Protokolle und vorherrschender Inkompatibilität auf der Hand. Es könnte a) ein Standard aus der Taufe gehoben werden, der es Geräten unterschiedlicher Hersteller ermöglicht, sich in einem Netzwerk (Transport-)Protokoll-unabhängig zu finden, ihre Fähigkeiten (Capabilities) auszutauschen, sich zu verbinden/pairen und sich schließlich gegenseitig entsprechend ihrer Fähigkeiten zu benutzen. Im Gegensatz dazu könnte b) eine Integrationsplattform verwendet werden, die als zentrale Drehscheibe verschiedene Schnittstellen-Technologien adaptiert, Protokolle übersetzt und ihrerseits einheitliche Schnittstellen bereitstellt. Die wahrscheinlichste Lösung wird vermutlich c) eine Mischform aus a) und b) sein. In diesem Szenario integriert die Integrationsplattform einige, wenige Applikationsprotokolle und ermöglicht damit eine einheitliche Nutzung.

(Keine) Einigkeit auf Applikationsebene

Seien wir mal ehrlich: Wäre es nicht ein Traum, wenn alle Geräte im Smart Home dem gleichen Applikationsprotokoll gehorchen würden? Keine Inkompatibilität zwischen Farblampe und Waschmaschine, sowie zwischen Router und Garagentor? Einfach das jeweilige Gerät einstecken und der Rest geschieht automagisch? Erreicht werden könnte das durch ein einheitliches Applikationsprotokoll, dass für alle nötigen Ebenen Spezifikationen bereithält. Verantwortlich für den Erfolg des jeweiligen Applikationsprotokoll ist dann neben seiner Qualität auch die Adoption-Rate, also die Verbreitung im Markt. Um die kritische Masse dafür zu erreichen, neigen Unternehmen dazu, sich in Allianzen zusammen zu schließen. Fast 20 solcher Allianzen haben wir bei unseren Recherchen mit dem Fokus Internet-of-Things und Smart Home gefunden, deren interessanteste Vertreter wir im Folgenden etwas genauer betrachten wollen:

AllSeen

Wurde 2013 von Qualcomm als Stiftung zur Verwaltung und Betreuung des Open Source Framework AllJoyn gegründet. AllJoyn selbst wurde bereits 2011 von Qualcomm gegründet und dann 2013 an die AllSeen Alliance (unterhalb der Linux Foundation) übergeben. AllJoyn ist ein Applikations-Framework, das Funktionen anbietet, mit denen sich Geräte über alle gängigen Plattformen (Microsoft Windows, Linux, Android, iOS, OS X, OpenWRT) hinweg finden und miteinander kommunizieren und kollaborieren können. Erste AllJoyn-Geräte sind bereits auf dem Markt (siehe Backofen der Firma AEG Electrolux [1]) und viele weitere sind angekündigt. Problematisch scheint bei AllSeen zu sein, dass die verwendete ISC Open-Source-Lizenz keine Patent-Klausel hat. Auch verfolgt die Allianz scheinbar keine Pläne ihr Framework zu standardisieren, was eine Portierung bspw. in andere Programmiersprachen erschweren dürfte.

OIC - Open Interconnect Consortium

Wurde Anfang 2014 von den Branchengrößen Atmel, Broadcom, Dell, Intel, Samsung und WindRiver als direkter “Konkurrent” zu AllSeen gegründet. Neben der Standardisierung des Applikationsprotokolls, wird auch eine Referenzimplementierung angeboten. Diese wurde in diesen Tagen unter dem Projektnamen IoTivity veröffentlicht [2]. Im Gegensatz zu AllSeen veröffentlicht das OIC allen Sourcecode unter der Apache Lizenz.

Thread

Thread ist ein IPv6-basiertes Protokoll, welches in 2014 von den NEST Labs (inzwischen von Google gekauft) veröffentlicht wurde und auf dem IEEE 802.15.4 Standard aufbaut. Aufgrund seines verwendeten Software-Stacks soll Thread durch Firmware-Ersatz auf 802.15.4-kompatiblen Geräten verwendet werden können. Leider ist über die Offenheit und die Verbreitung außerhalb der NEST Gruppe noch wenig bekannt.

HomeKit

HomeKit wurde von Apple als eine der beiden großen Neuigkeiten in iOS8 auf der vergangenen WWDC vorgestellt. Es definiert Schnittstellen auf Applikationsebene, die beschreiben, wie Geräte gefunden und gesteuert werden können. Es werden Geräteprofile, wie z.B. Schalter, Thermostat, Licht und Türschloss definiert. Die so kategorisierten Geräte können dann in eine (Haus-)Hierarchie eingebunden und kontrolliert werden. Jedes einzelne Gerät, also auch einzelne Lampen, die sich hinter ein Bridge befinden, können einzeln identifiziert werden (identify me) und über Siri angesprochen werden. Das iPhone avanciert damit zur universellen, sprachgesteuerten Fernbedienung. HomeKit funktioniert wohlgemerkt nur in der “Apple-Welt”, da die Implementierung auf anderen Plattformen aus lizenzrechtlichen Gründen nicht erlaubt ist.

QIVICON

QIVICON st eine von der Deutschen Telekom initiierte Allianz vornehmlich deutscher Unternehmen, die seit 2011 gemeinsam an der Entwicklung einer Smart-Home-Plattform arbeiten. Dabei geht es nicht nur um Software, sondern um eine Gesamtlösung aus Software, Hardware und Clouddiensten, welche durch die Partner direkt an Endkunden vermarktet werden kann. Softwareseitig wird versucht, auf offene Standards und Open Source zu setzen [3].

Eclipse IoT

Die Eclipse IoT Community wurde 2013 unter dem Namen Eclipse M2M gestartet und im Laufe des Jahres 2014 aufgrund des deutlich erweiterten Fokus in Eclipse IoT umbenannt. Der Working Group gehören heute mehr als 22 Organisationen an, die in mehr als 17 Projekten engagiert sind. Das Ziel von Eclipse IoT ist es (quell)offene Frameworks und Implementierungen offener IoT-Standards anzubieten.

EEBus

Der EEBus e.V. wurde 2011 aus dem Förderprogramm E-Energy des BMWi und BMU mit dem Ziel gegründet, die Energieeffizienz durch “den Austausch von Anwendungen und Diensten” zu erhöhen. In diesem geförderten Projekt wurde in erster Linie an einer (Daten-)Spezifikation für den Datenaustausch der verschiedenen Beteiligten insbesondere im Smart-Grid-Bereich gearbeitet (der eigentliche EEBus). Darüber hinaus ist eine Integrationsplattform zur Verbindung der im EEBus spezifizierten Datenmodelle über IP-Technologien beschrieben worden (SHIP) [4]. Die meisten Ergebnisdokumente sind nur Mitgliedern des EEBus e.V. sowie einiger assoziierter Verbände (VDE, BITKOM) zugängig, so dass derzeit nur schwer Aussagen über den Status und die Relevanz für das Smart Home gemacht werden können.

Die schiere Anzahl der Allianzen lässt schon vermuten, dass es mehr gibt, als es eigentlich brauchen würde, wäre man wirklich an Interoperatiblität und dem einen Applikationsprotokoll interessiert. Häufig spielen bei kommerziellen Entscheidungen dann eben doch nicht nur die harten Spezifikationen, sondern auch weiche Faktoren wie Not-Invented-Here oder ähnliche Befindlichkeiten eine Rolle, so dass man lieber seine “eigene” Allianz gründet, statt einer existierenden beizutreten. Erfreulicherweise gibt es unter den Allianzen inzwischen dennoch erste Zusammenschlüsse. Ende letzten Jahres kündigten AGORA (Frankreich), EEBus (Deutschland) und Energy@Home (Italien) ihre Zusammenarbeit auf europäischer Ebene an [5]. Am Ende wird der Markt entscheiden - es werden sich De-Facto-Standards bilden, die langfristig zu einer Konsolidierung des Marktes führen werden.

“Scope” = Beratung (B), Hardware (H), Software (SO), Spezifikation (S), Zertifizierung (Z)

Standardisierung

Neben den eher auf kommerzielle Interessen ausgerichteten Allianzen sind auch die “klassischen” Gremien (siehe #Tabelle 2) um Standardisierung im Internet-of-Things bemüht. Bereits vor mehr als 15 Jahren startete beispielsweise die OSGi Alliance mit der Spezifikation einer modularen und flexiblen Laufzeitumgebung für Embedded-Gateways. Weitere Initiativen wie oneM2M und ETSI M2M kommen ursprünglich aus dem M2M-Bereich, haben ihren Fokus aber inzwischen auch auf das Internet-of-Things ausgeweitet. Andere eher Telko-lastige Organisation wie IETF und OMA bringen große Erfahrung in der Anbindung mobiler (Embedded-)Geräte über die Luftschnittstelle mit und können daher mit entsprechend spezialisierten Protokollen (kleiner Footprint, garantierte Zustellung) aufwarten.

Im Gegensatz zu den oben aufgeführten Industrieallianzen, deren Interesse auch manchmal nur darin besteht, den eigenen Technologien einen Vorteil zu verschaffen, bemühen sich die Standardisierungsinitiativen (SDO), Standards in Form von in der Regel technologieunabhängigen Spezifikationen bereitzustellen.

“Scope” = Beratung (B), Hardware (H), Software (SO), Spezifikation (S), Zertifizierung (Z)

Interesse der Forschung

Die Entwicklung neuer Standards ist nicht zuletzt auch das Ergebnis intensiver Forschung und der Kooperation von Bildung und Wirtschaft. Darum haben neben den Anbietern und Herstellern auch die Forschungseinrichtungen großes Interesse am Internet-of-Things bzw. am Smart Home. Die Interessensgebiete erstrecken sich dabei von der Entwicklung intelligenter und vor allem effizienter Protokolle auf allen Schichten, über Themen zur Energieeffizienz, Künstliche Intelligenz, die Optimierung der Bedienungsmöglichkeiten bis hin zur Entwicklung neuer Geschäftsfelder im Dienstleistungsbereich.

Ein besonders interessantes Forschungsgebiet ist der Bereich Ambient Assisted Living (AAL). Hier wird das Ziel verfolgt, Menschen so lange wie möglich ein selbstbestimmtes Leben in den eigenen vier Wänden zu ermöglichen. Neben den psychologischen Aspekten stehen dabei auch der Kostendruck im Pflegebereich und der fortschreitende demografische Wandel im Vordergrund. In diesem Kontext hilft die intelligente Haustechnik z.B. bei Verlassen des Hauses unnötige oder gefährliche Stromverbraucher abzuschalten oder sie entdeckt ungewöhnliche Situationen wie z.B. einen Sturz der Bewohner. Dank der allgegenwärtigen, aber für den Bewohner dezent im Hintergrund befindlichen, Technik, können bspw. Servicerufe automatisch ausgelöst werden und damit gefährliche Situation vermieden und die Rettungszeit deutlich verkürzt werden.

Gerade (aber nicht ausschließlich) bei AAL kommen viele spezialisierte Sensoren, wie Kameras, Belegungssensoren und intelligente Fußböden zum Einsatz, um ungewöhnliche Situation möglichst schnell und fehlerfrei erkennen zu können. Der praktische Einsatz dieser neuen Technologien wird häufig in so genannten “Living Labs” getestet. Praktisch jede Forschungseinrichtung mit dem Interessengebiet “Smart Home” betreibt daher ein mehr oder weniger groß ausgelegtes Lab und testet darin das Zusammenspiel der zu erforschenden Komponenten. Beispiele für solche Labs sind:

• FZI Karlsruhe
• Hochschule Ruhr West
• Fraunhofer inHaus-Zentrum
• DFKI Bremen
• TU Dortmund
• FH Köln
• RWTH Aachen
• TU Kaiserslautern

Offen und (idealerweise) Open Source

Auch wenn sich in der Leserschaft sicher leicht Konsens darüber erzielen ließe, dass Standards im weitesten Sinne “offen” sein sollten, ist das nicht der Normalfall. Einige Standardisierungsorganisationen (aus Tabelle 2) verkaufen die Spezifikationen ihrer Standards zu teils erheblichen Lizenzgebühren. Die Allianzen erheben in der Regel Mitgliedsbeiträge für welche die Mitglieder dann im Gegenzug Zugriff auf die Dokumente erhalten.

Für die gute und schnelle Verbreitung eines Standards ist es allerdings erforderlich, die Zugangshürde so niedrig wie möglich zu halten. Aus diesem Grund liefern einige Standardisierer neben der Spezifikation auch eine Referenzimplementierung (idealerweise unter einer gängigen, kommerziell-freundlichen Open-Source-Lizenz) zur freien Nutzung mit. Hiermit wird potentiellen Nutzern eine möglichst große Rechtssicherheit in Bezug auf die Verwendung und die weitere Distribution der Quellen gegeben.

Im besten Fall stehen nicht nur die Spezifikation und die Protokolle, sondern auch die Integrationsplattform selbst quelloffen zur Verfügung, um sie schnell an die Bedingungen des sich rasant bewegenden Internet-of-Thing Marktes anpassen zu können. Für Nutzer- und Anbieter gibt es dabei gleichermaßen gute Argumente für den Einsatz offener statt geschlossener Plattformen:

Aus Nutzersicht:

• keine ausschließliche Bindung an den Anbieter der Hard-/Software (Vendor Lock-In)
• Community, die neben dem Anbieter bei der (Weiter-)Entwicklung der Plattform und bei technischen Problemen hilft
• Fortbestand des Projektes auch wenn Protagonisten wechseln, da Quellen weiter verfügbar bleiben (bei vernünftiger Lizenz)
• keine Lizenzkosten
• Investitionssicherheit aufgrund der gegebenen Erweiterbarkeit

Aus Sicht der Systemanbieter wird leider häufig schon wesentlich weniger als “offene Plattform” bezeichnet. Für sie reicht es meist schon aus, dass die Plattform (technisch) grundsätzlich erweitert werden könnte. Nur in seltenen Fällen sind bei kommerziellen Lösungen jedoch die Kriterien für echte Offenheit, wie die Verfügbarkeit der Quellen unter einer anerkannten Open-Source-Lizenz, die Verfügbarkeit einer (Entwickler-)Dokumentation und die aktive Unterstützung der Community vorhanden.

Gegen die Öffnung der Plattform könnte aus Sicht der Anbieter auch sprechen:

• Kannibalisierung - wenn die Produkte austauschbar sind, ist das möglicherweise mit Umsatzeinbußen verbunden
• mehr Support - neben den “normalen” Nutzern sind plötzlich die Entwickler zu unterstützen, die mit diesem neuen Wissen dann eigene Geräte/Applikationen anbieten, was wiederum zu weiteren Umsatzeinbußen führen könnte
• fehlende Kontrolle - die Entwicklungswünsche der Community gehen vor kommerziellen Interessen des Anbieters Sicherheit - wenn die Quellen verfügbar sind, sind mögliche Sicherheitslöcher leichter zu finden und das System wird angreifbarer

Diesen vermeintlich negativen Argumenten stehen aus unserer Sicht aber eine Reihe positiver Argumente gegenüber:

• weniger Support - neben dem Anbieter selbst (wenn es denn überhaupt einen gibt) hilft auch die Community bei der Lösung technischer Probleme
• erhöhte Entwicklungsgeschwindigkeit - weil nicht mehr nur das eigene Entwicklungsteam, sondern auch externe Entwickler mithelfen, kann in Summe der Output steigen
• höhere Sicherheit - aufgrund der Quelloffenheit können alle Entwickler (nicht nur die des Anbieters) die Sicherheitsmechanismen reviewen und bewerten. Sollten Lücken vorhanden sein, werden diese schneller entdeckt und behoben, als im Closed-Source Fall.

Fazit

Um das Smart Home tauglich für den Massenmarkt zu machen, müssen die Anbieter immer noch einige Hausaufgaben erledigen. Nach den Analysten von Deloitte werden allzu oft technische Details und kostenorientierte Anwendungsfälle einer Lösung hervorgehoben, anstatt auf nutzungsorientierte Vermarktung, die Betonung des Verbaucher-Lifestyles, eine intelligente Preisgestaltung, die Bündelung von Produkt und Installation, Transparenz über Verkaufkanäle und offene Plattformen zu setzen [6].

Damit offene Plattformen entstehen können, bedarf es zunächst offener Standards und quelloffener Implementierungen dieser Standards. Und hier liegt der Hase im Pfeffer: Haben es die Standardisierungsgremien mittlerweise geschafft, relevante und gute Protokolle auf den unteren Ebenen zu spezifizieren, sieht es auf der Applikationsebene bisher sehr dünn aus. Hier bringen auch die zahlreich entstandenen (und weiterhin entstehenden) Allianzen kaum Besserung. Mit AllSeen und OIC scheinen zwei Kandidaten mit großem Potential auf dem Markt zu sein, welche erfahren genug wären, diese Mammutaufgabe der Spezifizierung eines solchen Protokolls zu stemmen. Die Zeit wird zeigen, welcher der Kandidaten dauerhaft mit den Entwicklungen des Internet-of-Things mithalten bzw. diese mitbestimmen kann.

Im nächsten Artikel wird es wieder etwas technischer und wir wollen uns mit den Aspekten Steuerung und Automatisierung beschäftigen.

Referenzen