Bestandsaufnahme Middleware-
Plattformen für AAL
Roadmap AAL-Interoperabilität
BMBF Förderkennzeichen: 16SV5562K
Dokumentenreferenz: D3.1.2, D3.2.2, D3.1.3, D3.2.3
Version: 1.1
Autor/ Organisation: M. Lipprandt (OFFIS), A. Marinc (IGD), T. Dutz, G. Moritz
(URO)
Datum: 18.07.2013
Status: Final
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite ii
1 EINLEITUNG 1
2 METHODIK 1
3 SCHRITT 1: AAL-MIDDLEWARE-PLATTFORMEN - EINE MARKTÜBERSICHT 3
3.1 BEGRIFFSABGRENZUNG AAL-MIDDLEWARE-PLATTFORM 3
3.2 INITIALE LISTE DER AAL-MIDDLEWARE-PLATTFORMEN 4
4 SCHRITT 2: ANWENDUNG DER KRITERIEN ZUR FILTERUNG 8
5 EVALUATION DER VERBLEIBENDEN AAL-MIDDLEWARE-PLATTFORMEN 10
5.1 HERANGEHENSWEISE 11
5.1.1 INFORMATIONEN ÜBER ERWEITERUNG UND SENSORANBINDUNG 11
5.1.2 USE CASE 11
5.1.3 PROZESSPLAN DER EVALUATION 12
5.2 TESTUMGEBUNG 12
6 EINZELBESCHREIBUNG DER EVALUIERTEN PLATTFORM 14
6.1 PLATTFORM IP-SYMCON 14
6.1.1 WAS IST IP-SYMCON? 14
6.1.2 KONKRETE FEATURES 15
6.1.3 INSTALLATION UND EINSTIEG 16
6.1.4 UMSETZUNG DES USE CASE 17
6.1.5 ERWEITERUNG DER SOFTWARE 18
6.1.6 FAZIT 19
6.2 PLATTFORM OPENHAB 20
6.2.1 WAS IST OPENHAB? 20
6.2.2 KONKRETE FEATURES 22
6.2.3 INSTALLATION UND EINSTIEG 23
6.2.4 UMSETZUNG DES USE CASE 23
6.2.5 ERWEITERUNG DER SOFTWARE 24
6.2.6 FAZIT 25
6.3 OPENREMOTE 26
6.3.1 WAS IST OPENREMOTE? 26
6.3.2 INSTALLATION UND EINSTIEG 28
6.3.3 UMSETZUNG DES USE CASE 28
6.3.4 ERWEITERUNG DER SOFTWARE 29
6.3.5 FAZIT 29
6.4 PLATTFORM MUNDOCORE (UMUNDO) 31
6.4.1 WAS IST MUNDOCORE? 31
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite iii
6.4.2 INSTALLATION UND EINSTIEG 32
6.4.3 UMSETZUNG DES USE CASE 32
6.4.4 ERWEITERUNG DER SOFTWARE 33
6.4.5 FAZIT 34
6.5 UNIVERSAAL 35
6.5.1 WAS IST UNIVERSAAL? 36
6.5.2 INSTALLATION UND EINSTIEG 37
6.5.3 ERWEITERUNG DER SOFTWARE 39
6.5.4 FAZIT 39
6.6 OPENURC 40
6.6.1 WAS IST OPENURC? 40
6.6.2 ERWEITERUNG DER SOFTWARE 41
6.6.3 FAZIT 42
6.7 PROSYST MBS SMART HOME SDK 43
6.7.1 WAS IST MBS SMART HOME? 43
6.7.2 ERWEITERUNG DER SOFTWARE 44
6.7.3 FAZIT 44
7 DISKUSSION 45
8 ZUSAMMENFASSUNG UND AUSBLICK 46
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite iv
Urheberrecht
Das Copyright liegt beim RAALI-Konsortium.
Projektkonsortium: OFFIS-Institut für Informatik (OFFIS) FuE-Bereich Gesundheit, Dr. Marco
Eichelberg Deutsche Kommission Elektrotechnik Elektronik Informationstechnik (DKE), Dr. Stefan
Heusinger Fraunhofer Institut für Graphische Datenverarbeitung (IGD) Fraunhofer Ambient Assisted
Living Alliance, Dr. Reiner Wichert Technische Universität Dresden (TUD) Institut für Angewandte
Informatik, Prof. Dr.-Ing. habil. Klaus Kabitzsch Universität Rostock (URO) Institut für Angewandte
Mikroelektronik und Datentechnik, Dr. Frank Golatowski Universitätsmedizin Göttingen (UMG)
Medizinische Informatik, Prof. Dr. Otto Rienhoff Embedded Network Solutions UG (ENS) als
Unterauftragnehmer Prof. Dr.-Ing. Ralph Welge
Über RAALI
Um den Herausforderungen des demografischen Wandels entgegenzutreten, werden derzeit eine
Vielzahl von AAL-Systemen entwickelt. Diese Systeme sind aufgrund der unterschiedlichen
Anwendungsgebiete und der vielschichtigen Ansprüche, die an sie gestellt werden, sehr spezialisiert.
Auf diese Weise entstehen Insellösungen, die nicht flexibel sind. Dabei ist gerade ein „Mitwachsen“
des AAL-Systems notwendig, um den sich ändernden Anforderungen, bspw. der Multimorbidität im
Alter, gerecht zu werden. Diese Anpassungsfähigkeit kann nur durch Interoperabilität, also die
Möglichkeit der Kommunikation zwischen den einzelnen Systemen und Teilsystemen, erreicht
werden. Die Interoperabilität ist eine essenzielle Rahmenbedingung zur Integration von AAL-
Systemen in das Gesundheitswesen. Ein Grund für den derzeit noch weitgehend unbeachteten Aspekt
der Interoperabilität ist die hohe Komplexität des Themas: Es existieren sehr viele Standards und
Normen, die in diesem Bereich zum Einsatz kommen könnten. Teilweise werden durch diese
überlappende Gebiete abgedeckt, größtenteils schließen sie einander jedoch aus. Ein weiterer
wichtiger Punkt ist die Zugänglichkeit zu den Angeboten wie bspw. die Middleware, wodurch derzeit
jedes FuE-Vorhaben seine eigene Infrastruktur entwickelt.
Um die Interoperabilität von AAL-Systemen gewährleisten zu können, müssen diese Fragen
angegangen werden. Das vorliegende Projekt wird zur Lösung der Problematik im Wesentlichen die
folgenden drei Punkte ausarbeiten: (1) Aufstellung einer deutschen Roadmap für AAL-
Interoperabilität, (2) Entwicklung von Integrationsprofilen für AAL-Systeme und (3)
Bestandsaufnahme der am Markt verfügbaren Middleware-Plattformen. So soll für FuE-Vorhaben ein
leichterer Zugang zur Umsetzung der Interoperabilität erreicht werden.
Die Projektpartner stammen aus unterschiedlichen Bereichen und spiegeln die Heterogenität des AAL-
Umfeldes wider. Das Projekt wird von der als Beirat fungierenden VDE Arbeitsgruppe
„Schnittstellenintegration und Interoperabilität“ unterstützt. Ziel dieser Arbeit ist es, durch die
Bereitstellung der Ergebnisse, eine stärkere Durchdringung des AAL-Marktes zu unterstützen und
gleichzeitig die Zukunftssicherheit der AAL-Systeme zu gewährleisten.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 1
1 Einleitung
Auf internationaler Ebene gab und gibt es eine Vielzahl von Initiativen und Projekte, die sich um die
Etablierung einer Middleware-Plattform für AAL bemühen. Zu nennen sind hier u. a. universAAL,
OpenAAL und OpenURC. Aus der Sicht eines Systementwicklers, ist die Wahl einer passenden AAL-
Middleware-Plattform nicht ohne eine Marktrecherche zu beantworten. Hierbei stellen sich Anforde-
rungen an Funktionalität, Weiterentwicklung, Wartbarkeit und benötigte Hardware-Ressourcen. In
dem vom BMBF geförderten RAALI-Projekt wurde deshalb eine Bestandsaufnahme von verfügbaren
AAL-Middleware-Plattformen erarbeitet. Durch diese Analyse soll es Entwicklern möglich sein, sich
über den aktuellen Stand der Forschung in Bezug auf die Entwicklung von AAL-Anwendungen zu
informieren. Hierbei steht vor allem die praktische Anwendung der entsprechenden Softwarelösungen
im Vordergrund.
Um der Vielfalt verfügbarer Softwarelösungen gerecht zu werden, wurde ein dreistufiges Verfahren
gewählt. Im ersten Schritt wurde eine Markanalyse über die existierenden AAL-Middleware-
Plattformen erstellt (siehe Abschnitt 3.2). Für den zweiten Schritt der Evaluation sollte die Software
den Kriterien der Verfügbarkeit, der Lebendigkeit und der ausreichenden Flexibilität genügen. Alle
Plattformen die 1.) nicht (mehr) verfügbar sind, 2.) seit mind. 2,5 Jahren keine Aktivität mehr aufzei-
gen oder 3.) zu spezifisch nur ein bestimmtes Szenario abdecken, haben sich für eine Evaluation nicht
qualifiziert. In einem dritten Schritt wurden die als geeignet identifizierten Plattformen tiefer gehend
evaluiert und bei einigen Plattformen beispielhaft ein Referenzszenario prototypisch umgesetzt. Darü-
ber hinaus wurde die Erweiterbarkeit der jeweiligen Plattform untersucht, um abschätzen zu können,
ob und mit welchem Aufwand die jeweilige Plattform sich um neue Komponenten erweitern lässt.
Es ist hervorzuheben, dass die untersuchten Plattformen im Rahmen der Evaluation bewusst nicht
miteinander verglichen wurden. Es hat sich gezeigt, dass die untersuchten Plattformen in der Konzep-
tion und in der zu erreichenden Zielstellung stark voneinander abweichen. Während einige Plattfor-
men speziell für AAL-Systeme entworfen wurden, stellen andere Systeme eher grundlegende Middle-
ware-Funktionalitäten bereit, auf die ein AAL-System aufgesetzt werden kann. Eine Bevorzugung
einer konkreten Plattform ist somit nur unter Berücksichtigung von anwendungsspezifischen Rahmen-
bedingungen möglich. Eine ausführlichere Diskussion hierzu findet sich am Ende dieses Dokuments
in Abschnitt 7.
2 Methodik
In diesem Kapitel wird die Herangehensweise, die zu den Ergebnissen der Evaluation geführt hat,
beschrieben. In einem ersten Schritt (siehe Abschnitt 3) wurde eine initiale Liste mit verfügbaren
AAL-Middleware-Plattformen aus dem Bereich der vornehmlich frei verfügbaren Software erstellt.
Dabei wurde der Suchfokus ausgeweitet, da die Suche nach „reiner“ AAL-Software keine realistische
Markübersicht erzielt hätte. Vielmehr verbirgt sich AAL-spezifische Funktionalität wie z. B. Daten-
abstraktion hinter einer Vielzahl von Schlagwörtern. Darüber hinaus lag der Fokus bei der Suche auf
frei verfügbarer Software. Lediglich zwei kommerzielle Produkte wurden in die Liste aufgenommen,
um die Funktionalität kommerzieller Produkte exemplarisch aufzuzeigen.
Zentral für eine AAL-Middleware-Plattform, vor allem für einen im entstehen begriffenen Markt, ist
die Frage nach der Aktualität und der Weiterentwicklung der Software. Es wurden daher in einem
zweiten Schritt (siehe Abschnitt 4) kategorisch Plattformen ausgeschlossen, bei denen sowohl über die
Homepage als auch in der Version der Software in den letzten zwei Jahren (Stand 11/2012) keine Er-
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 2
neuerung/Update/Bug-Fix mehr vorgenommen wurde. Die Festlegung auf zwei Jahre unterliegt der
Annahme eines sich schnell entwickelnden IT-Marktes, der im Bereich von AAL mit der Heterogeni-
tät dieses Anwendungsfeldes stetig mitwachsen muss. Des Weiteren wurde die Verfügbarkeit einer
Plattform vorausgesetzt. Software, die nicht verfügbar war, wurde nicht weiter betrachtet.
Der dritte Schritt (siehe Abschnitt 6) bestand aus einer tabellarischen Auflistung von Informationen
zum Projektkontext (Randbedingungen), einer Neuinstallation des Systems, einer Literaturrecherche
über die Funktionalität, Sensoranbindung und Erweiterbarkeit der Plattform. Darüber hinaus wurde bei
4 von den 7 Plattformen ein Use Cases exemplarisch umgesetzt. Diese Umsetzung ging über die ge-
planten Arbeiten und Ressourcen hinaus. Das bei drei der 7 Plattformen kein Use Case umgesetzt
wurde, sagt nichts über die Fähigkeit der Plattform aus. In einer Nachbetrachtung wurde der Fokus auf
die jeweiligen Stärken und Schwächen der Plattform gelegt, es werden die Plattformen nicht miteinan-
der verglichen. In Abschnitt 5.1 wird die Herangehensweise bei der Evaluation der verbleibenden
Plattformen ausführlicher beschrieben.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 3
3 Schritt 1: AAL-Middleware-Plattformen - eine Marktübersicht
In diesem Kapitel wird zunächst eine Übersicht über die existierenden AAL-Middleware-Plattformen
in Form einer initialen Liste gegeben. Diese Übersicht erhebt nicht den Anspruch auf Vollständigkeit!
Entsprechend der vagen Abgrenzung von Middleware-Plattformen im Allgemeinen und AAL im Spe-
ziellen wurde nach Plattformen aus dem Bereich der Forschung, proprietäre Projekte aus der Wirt-
schaft und Frameworks gesucht. Die Übersicht ist daher als beispielhaft anzusehen, sie zeigt die Viel-
fältigkeit der möglichen Plattformen, die eine Schnittmenge mit den Domänen Hausautomation oder
Health-Care haben können.
3.1 Begriffsabgrenzung AAL-Middleware-Plattform
Um eine Liste aller möglichen Plattformen zur Unterstützung der Entwicklung von AAL-
Anwendungen zu erstellen, muss zunächst einmal der Begriff „Plattform“ genauer spezifiziert werden.
Allgemein stellt eine Plattform eine Basis für die Entwicklung von Software bereit. Im Vergleich mit
einer einfachen Softwarebibliothek oder einem bereitgestellten Framework rechnen wir dem Begriff
der Plattform eine etwas umfassendere Bedeutung zu. Neben der Unterstützung durch eine API wer-
den einem Entwickler zum Beispiel spezialisierte Entwicklungsumgebungen bereitgestellt und/oder
eine ganze Sammlung von hilfreichen Werkzeugen.
Bezüglich der Heterogenität und der Verteiltheit der Anwendungsdomänen „AAL“ können viele
Softwarefunktionalitäten und –techniken in einer AAL-Anwendung Verwendung finden. Ohne An-
spruch auf Vollständigkeit und ohne den expliziten Ausschluss von Überlappungen wird in diesem
Dokument von den folgenden Domänen ausgegangen:
Home Automation (Bussysteme, Homeserver, usw.)
Embedded Systems (Mikrocontroller, Smart Grid, usw.)
Netzwerke (offene Systeme, Kommunikation, Protokolle, usw.)
Robotik (Steuerungstechnik, Mechanik, usw.)
Sensortechnik (Entwicklung neuer Sensoren, Wireless Sensor Networks, usw.)
Multimedia (Distributed Media, CloudStreaming, usw.)
Data Mining / Datenbanken (Activities of Daily Life, Profiling, Rule-Mangement, usw.)
HCI / explizite Interaktion (GUI-Design auf PC/Tablet/Telefon, multimodale Interaktion, usw.)
Simulation (Virtuelle Avatare, Synchonized Realities, usw.)
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 4
3.2 Initiale Liste der AAL-Middleware-Plattformen
Die initiale Liste enthält neben dem Namen einen Link zur Homepage und die Anwendungsdomäne
sowie den Entstehungskontext der Software. Die Abkürzung WSN bedeutet Wireless Sensor Networks
und AmI bedeutet Ambient Intelligence.
Name der Plattform
URL
Anwendungsdomäne
Entstehungskontext
AMIGO
http://www.hitech-projects.com/euprojects/amigo
AmI/AAL
EU-Projekt
M-POWER
http://www.sintef.no/Projectweb/MPOWER/
AmI/AAL
EU-Projekt
Netcarity
http://www.netcarity.org
AmI/AAL
EU-Projekt
openAAL
http://openaal.org
eigenes Forschungsprojekt
OASIS
http://www.oasis-project.eu/
AmI/AAL
EU-Projekt
PERSONA
http://cordis.europa.eu/search/index.cfm?fuseaction=pr
oj.document&PJ_RCN=9076901
AmI/AAL
EU-Projekt
SOPRANO
http://www.soprano-ip.org
AmI/AAL
EU-Projekt
universAAL
http://universaal.org
AmI/AAL
EU-Projekt
ANGEL
ftp://ftp.cordis.europa.eu/pub/ist/docs/dir_c/ems/angel-
v1.pdf
WSN/Embedded
EU-Projekt
EMMA (nicht mehr vorhanden)
http://www.emmaproject.eu/test/summary.php
WSN/Embedded
EU-Projekt
GENESYS
http://www.genesys-platform.eu/
WSN/Embedded
EU-Projekt
HYDRA
http://www.hydramiddleware.eu
AmI/AAL
EU-Projekt
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 5
i2home
http://www.i2home.org/
AmI/AAL
EU-Projekt
IP-Symcon
http://www.ip-symcon.de
Heimautomatisierung
Industrieprojekt
IST-MUSIC
http://ist-music.berlios.de/site/
AmI/AAL
EU-Projekt
MisterHouse
http://misterhouse.sourceforge.net/
eigenes Forschungsprojekt
MonAMI
http://www.monami.info/
AmI/AAL
EU-Projekt
Mundo
http://umundo.tk.informatik.tu-darmstadt.de/
AmI/AAL
eigenes Forschungsprojekt
openHAB
http://code.google.com/p/openhab/
Heimautomatisierung
Open-Source-Projekt
OXYGEN
http://oxygen.csail.mit.edu/
AmI/AAL
eigenes Forschungsprojekt
openURC
http://myurc.org/
Heimautomatisierung
Forschungsprojekt
Premise
http://www.cocoontech.com/wiki/Premise
Heimautomatisierung
eigenes Forschungsprojekt
RUNES
http://runesmw.sourceforge.net/java.html
WSN/Embedded
EU-Projekt
SENSEI
http://www.ict-sensei.org/
WSN/Embedded
EU-Projekt
SIMS
http://cordis.europa.eu/search/index.cfm?fuseaction=pr
oj.document&PJ_RCN=11439155
WSN/Embedded
EU-Projekt
SOCRADES
http://www.socrades.eu
WSN/Embedded
EU-Projekt
TinyOS
http://www.tinyos.net/
WSN/Embedded
eigenes Forschungsprojekt
Crestron
http://www.crestron.com/
Heimautomatisierung
Industrieprojekt
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 6
Digital Life
https://my-digitallife.att.com/learn/
Heimautomatisierung
Industrieprojekt
OSAmI
http://en.wikipedia.org/wiki/OSAMI
Forschungsprojekt
HomeMatic
http://www.HomeMatic.com
Heimautomatisierung
Industrieprojekt
Homescenario
http://www.homescenario.com/home/index.html
Heimautomatisierung
Industrieprojekt
LonWorks
http://www.echelon.de/technology/lonworks/default.htm
Heimautomatisierung
Industrieprojekt
mBS Smart Home SDK
http://www.prosyst.com/index.php/de/html/content/136/
Smart-Home-%7C-Products-%7C-Device-Software/
AmI/AAL
Industrieprojekt
Mediola
http://www.mediola.de/
Heimautomatisierung
Industrieprojekt
myGEKKO
http://www.my-gekko.com/de/front-page/
Heimautomatisierung
Industrieprojekt
OpenCable/PacketCable
http://www.cablelabs.com/opencable/
Framework
Industrieprojekt
OpenHome
http://www.icontrol.com/
Heimautomatisierung
Industrieprojekt
OpenRemote
http://openremote.org
Sontiges
Open-Source-Projekt
ReCon
http://www.recon-home.de
Heimautomatisierung
Industrieprojekt
RocketHome
http://www.rockethome.de/
Smart-Metering
Industrieprojekt
RWE SmartHome
http://www.rwe-smarthome.de
Heimautomatisierung
Industrieprojekt
Savant
http://www.savantsystems.com
Heimautomatisierung
Industrieprojekt
URC
http://www.universalremote.com/
Heimautomatisierung
Industrieprojekt
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 7
android@home
http://www.android-at-home.com/
Framework
Industrieprojekt
Apache River Project
http://river.apache.org/concepts.html
Framework
Open-Source-Projekt
OSGi
http://osgi.org
Framework
Industrieprojekt
RMI
http://www.oracle.com/technetwork/java/javase/tech/
Framework
Industrieprojekt
ROS
http://www.ros.org/wiki/
Framework
Open-Source-Projekt
UPnP
http://www.upnp.org
Framework
Industrieprojekt
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 8
4 Schritt 2: Anwendung der Kriterien zur Filterung
Im ersten Schritt wurde eine Markanalyse über die existierenden AAL-Middleware-Plattformen er-
stellt und in einer Liste aufgeführt (siehe Abschnitt 3.2). Für den zweiten Schritt der Evaluation wur-
den die Ausschlusskriterien auf die Liste mit den 50 Plattformen angewendet. Diese Kriterien bestan-
den aus drei Aspekten:
1. Software ist nicht (mehr) verfügbar
2. seit mind. 2,5 Jahren keine Aktivität (Update)
3. Plattform deckt nur einen spezifischen Anwendungsfall ab
Hat eine Plattform diese Kriterien erfüllt, hat sie sich für die weitere Evaluation nicht qualifiziert.
Nach der Anwendung dieser Kriterien ist eine Liste mit 10 Plattformen übrig geblieben.
Name der Plattform
URL
Anwendungsdomäne
Entstehungskontext
Download-Link
openAAL
http://openaal.org
AAL
Eigenes Forschungsprojekt
http://openaal.org/download
universAAL
www.universaal.org
AAL
EU-Projekt
http://forge.universaal.org
Hydra
http://www.hydramiddlewar
e.eu
AmI
EU-Projekt
http://sourceforge.net/projects/linksm
art
IP-Symcon
http://www.ip-symcon.de
AmI
Industrieprojekt
http://www.ip-
symcon.de/service/downloads/
Mundo
http://umundo.tk.informatik
.tu-darmstadt.de/
AmI
Eigenes Forschungsprojekt
http://umundo.tk.informatik.tu-
darmstadt.de/installer/
openHAB
http://code.google.com/p/ope
nhab/
AmI
Eigenes Forschungsprojekt
http://code.google.com/p/openhab/
openURC
http://www.openurc.org
AmI
Eigenes Forschungsprojekt
http://myurc.org/tools/
OpenRemote
http://openremote.org
AmI
Open-Source-Projekt
http://openremote.org
mBS Smart Home
http://www.prosyst.com
AmI
Industrieprojekt
http://www.prosyst.com
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 9
OSAmI
http://thewiki4opentech.org/
index.php/Portal:OSAmI
Forschungsprojekt Keine Software mehr verfügbar
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 10
5 Evaluation der verbleibenden AAL-Middleware-Plattformen
Durch die Anwendung der Ausschlusskriterien (siehe Abschnitt 4) wurde die Liste mit den einst 50
Plattformen auf eine Liste mit 10 zu evaluierenden Plattformen reduziert.
Bei Forschungsprojekten war deutlich erkennbar, dass nach Ende der Projektlaufzeit die Aktivität bei
der Softwareentwicklung sich einstellten. Ältere Plattformprojekte wie Amigo und M-Power sind auf
diese Weise direkt herausgefallen. Auch OSAmI wurde nicht näher getestet, da es eine Sammlung von
Werkzeugen für verschiedene Anwendungsfälle ist, aber nicht als Plattform fungiert. Darüber hinaus
war zum Zeitpunkt der Testung die Webseite des Projektes bereits nicht mehr erreichbar. Bei anderen
Projekten wie PERSONA und OASIS gelang es nicht, aktuelle Software aus dem Netz zu erhalten.
Die PERSONA Homepage war offline und im Fall von OASIS konnte kein Download auf der Home-
page gefunden werden. OpenAAL ist aus der Evaluation herausgefallen, da es auf universAAL auf-
setzt und zum Zeitpunk der Testung eine veraltete Version von universAAL verwendete. Hydra konn-
te nicht getestet werden, da es sich nicht kompilieren ließ. Insgesamt blieben von den 50 Plattformen 7
Plattformen für die vertiefte Evaluation übrig.
Name der Plattform
URL
Anwendungsdomäne
Entstehungskontext
Download-Link
universAAL
www.universaal.org
AAL
EU-Projekt
http://forge.universaal.org
IP-Symcon
http://www.ip-symcon.de
AmI
Industrieprojekt
http://www.ip-
symcon.de/service/downloads/
Mundo
http://umundo.tk.informatik
.tu-darmstadt.de/
AmI
Eigenes Forschungsprojekt
http://umundo.tk.informatik.tu-
darmstadt.de/installer/
openHAB
http://code.google.com/p/ope
nhab/
AmI
Eigenes Forschungsprojekt
http://code.google.com/p/openhab/
openURC
http://www.openurc.org
AmI
Eigenes Forschungsprojekt
http://myurc.org/tools/
OpenRemote
http://openremote.org
AmI
Open-Source-Projekt
http://openremote.org
mBS Smart Home
http://www.prosyst.com
AmI
Industrieprojekt
http://www.prosyst.com
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 11
5.1 Herangehensweise
In diesem Kapitel wird die Methode zur vertieften Evaluation der verbleibenden Plattformen beschrie-
ben. In Abschnitt 5.1.1 wird die Erweiterbarkeit der Plattformen beschrieben und in Abschnitt 5.1.2
die Umsetzung eines Use Cases. Abschnitt 5.1.3 beschäftigt sich mit der tabellarischen Auflistung der
Information zu der jeweiligen Plattform.
5.1.1 Informationen über Erweiterung und Sensoranbindung
Da AAL-Anwendungen durch ein hohes Maß an Heterogenität und Diversität geprägt sind, ist die
Möglichkeit der Erweiterung der Plattform um eigene Komponenten, Protokolle und Technologien
eine essenzielle Voraussetzung. Im Rahmen der Evaluation wurde zu jeder Plattform eine Recherche
durchgeführt, um die Erweiterbarkeit zu erfassen und ggfs. bewerten zu können.
Diese Recherche beschränkt sich dabei auf eine Literaturrecherche der zur Verfügung stehenden In-
formationen des Herstellers/Anbieters (Dokumentation, Wiki, Code Review). Die Implementierung
einer konkreten Erweiterung erfolgte nicht.
5.1.2 Use Case
Zur Identifizierung der Stärken und Schwächen wurde ein konkreter Use Case versucht mit den Platt-
formen umzusetzen. Die Umsetzung des Use Cases ist aber nicht mit einem Erfolg verbunden, der
dann als positiv oder negativ gewertet wird. Vielmehr zeigt die Umsetzung des Use Cases zwar den
praktischen Einsatz aber auch die möglichen Limitationen. Plattformen, die keine konkreten Geräte
unterstützen aber ein Konzept zur universellen Anbindung und Erweiterung realisieren, werden im
Evaluationsergebnis nicht schlechter bewertet. Schließlich würden sonst kleinere Anwendungen mit
einem sehr begrenzten Fokus in dem zufällig gewählten Use Case sehr gut abschneiden, obwohl sie
für flächendeckende breiter gestreute Anwendungsfälle völlig ungeeignet wären. Die Herausforderung
hierbei besteht darin den Anwendungsfall zwar komplex genug zu gestalten, um auf der einen Seite
weitgehend anwendungstreu zu bleiben, auf der anderen Seite ihn aber auch so generisch zu definie-
ren, dass alle Plattformen gleiche Chancen haben.
Es wurde ein Szenario gewählt, in dem ein Sensor und ein Aktuator an die Plattform angebunden wer-
den soll. Anschließend sollten diese angebundenen Geräte über eine Logik miteinander interagieren.
Das Anbinden von Sensoren und/oder Aktuatoren ist grundlegend für die meisten AAL-Anwendungen
(z. B. in der Klassifikation der Activities of Daily Living, Notfallmeldung, Well-being und medizini-
scher Analyse). Wie schnell sich ein entsprechendes Gerät anbinden lässt, hängt von der Liste der
unterstützten Hardware ab, deshalb wird die Unterstützung bei der Anbindung neuer Geräte auch
untersucht.
Gleiches gilt für die Verbindung der Sensoren bzw. Aktoren. Hier kann aufgezeigt werden, wie leicht
sich die hierfür nötigen Regeln in das System einpflegen lassen, ob diese z. B. per Skript, GUI mit
Drag&Drop oder Java-Code programmiert werden, oder ob solche Regeländerungen auch während der
Laufzeit möglich sind. Auch hier wird ein Eindruck über die Arbeit mit der Plattform vermittelt.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 12
5.1.3 Prozessplan der Evaluation
Alle Plattformen werden nach einem fixen Schema getestet. Zunächst werden die wichtigsten, allge-
meinen Kenndaten zu der Plattform tabellarisch erhoben. Diese sind:
Name der Plattform
URL:
Anwendungsdomäne
Entstehungskontext
Verfügbarkeit von Ansprechpartnern
Verfügbarkeit der Software
Entwicklung seit
Zeitpunkt des letzten Updates
Konkrete Einsatzorte der Plattform
Dokumentation:
Bug Tracking:
Anzahl der Downloads:
Lizenz:
Anschließend werden die Eigenschaften der Plattform, die konkreten Funktionen, die Installation des
Systems und die Umsetzung des Use Case (bei 4 von 7 Plattformen) prosaisch beschrieben. In einem
abschließenden Abschnitt wird zu jeder Plattform ein extra Augenmerk auf die Erweiterbarkeit der
Plattform gerichtet, um somit einen Eindruck zu vermitteln, wie generisch sich diese einsetzen lässt.
5.2 Testumgebung
Die Tester und Autoren dieses Dokumentes sind im Einzelnen:
Myriam Lipprandt: Hat ihr Diplom in Informatik 2007 an der Universität Hamburg abgeschlossen
und arbeitet seit 5 Jahren als wissenschaftliche Mitarbeiterin am OFFIS – Institut für Informatik in
Oldenburg. Sie ist Mitglied der VDE/DKE AAL Arbeitsgruppe STD 1811.0.12 „AAL-
Interoperabilität” und ihre Forschungsinteressen liegen im Bereich der medizinischen Standards
im Besonderen der Dokumentenstandards und der Interoperabilität im Gesundheitswesen.
Alexander Marinc: Hat seinen Master of Science in der TU Darmstadt im Fach Informatik
abgeschlossen und ist seit drei Jahren als wissenschaftlicher Assistent am Fraunhofer IGD
angestellt und im Bereich AAL aktiv. Als ein aktives Mitglied des universAAL Projektes kennt er
die Arbeit an der universAAL-Plattformen sowohl vonseiten des Benutzers als auch von Seiten
des Entwicklers. Da universAAL mit in den Test vertreten ist, wird es bewusst nicht von ihm
getestet.
Guido Moritz: Hat seinen Dipl.-Ing. sowie seinen Dr.-Ing. Elektrotechnik an der Universität
abgeschlossen und ist seit 2007 wissenschaftlicher Mitarbeiter am Institut für Angewandte
Mikroelektronik und Datentechnik der Uni Rostock. Sein Forschungsschwerpunkt liegt auf der
Anwendung von Internettechnologien wie IP und Web Services im gerätenahen Umfeld. Im
Rahmen der Promotion wirkte er somit aktiv an der Standardisierung diverser Protokolle bei der
IETF sowie der OASIS mit.
Als Testumgebung wurden ausschließlich Rechner auf der Basis von Microsoft Windows 7 verwen-
det. Dies ist zum einen angepasst an die Erfahrungen der Entwickler und zum anderen sind alle getes-
teten Plattformen hierfür verfügbar. Als Komponenten für den Test des Use Case wurden verfügbare
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 13
Elemente aus dem Bereich der Hausautomation verwendet. Im Einzelnen aufgelistet werden diese in
den jeweiligen Tests.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 14
6 Einzelbeschreibung der evaluierten Plattform
6.1 Plattform IP-Symcon
Projektstatus
Name der Plattform IP-Symcon
URL: http://www.ip-symcon.de/
Anwendungsdomäne
Entstehungskontext
Hausautomation, Industrielles Produkt
Verfügbarkeit von
Ansprechpartnern
Die Symcon GmbH ist sehr gut über Telefon, Fax und e-mail zu
erreichen (http://www.ip-symcon.de/impressum/).
Verfügbarkeit der
Software
Die Software ist kostenpflichtig, eine kostenlose Testversion ist auf
Anfrage verfügbar gewesen.
Entwicklung seit Die Symcon GmbH wurde im Dezember 2012 gegründet, die
Entwicklung an der Software findet jedoch schon länger statt.
Zeitpunkt des letzten
Updates
Es finden ständig Updates statt um sich den kompatiblen Protokollen
anzupassen und neue einzubinden.
Konkrete Einsatzorte
der Plattform
Industrielle Großanlagen sind weniger im Fokus, sondern Haustechnik
von Einzelbereichen oder auch Wohnblöcken. Geschäfts- aber auch
Privatkunden sollen von dem Angebot angesprochen werden, um
Gebäudautomatisierungen gezielt ansprechen zu können. Im Zielbereich
sind hier vor allem heterogene Umgebungen mit verschiedenen
verwendeten Bus-Systemen.
Dokumentation: http://www.ip-symcon.de/service/dokumentation/ (oder Download unter
http://www.ip-symcon.de/downloads/doku/IP-Symcon-
Dokumentation.pdf) und im Forum unter http://www.ip-
symcon.de/forum/forum.php
Bug tracking: Nicht gefunden
Anzahl der Downloads: Kein Information vorhanden
Lizenz: Proprietär
6.1.1 Was ist IP-Symcon?
IPS bietet die Möglichkeit, verschiedenste auf dem Markt aktuell verfügbarer Busse für
Hausautomations-Systeme gezielt von einer zentralen Stelle ansprechen zu können, sowie das auto-
nome Zusammenwirken zu konfigurieren. Hierfür wird eine Software auf Basis einer Plug-In
Architektur verwendet, welche es erlaubt verschiedene Module für Systeme wie z. B. KNX, FS20, und
EnOcean einzubinden. IP-Symcon wird lokal als ein Server gestartet und die sogenannte
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 15
Verwaltungskonsole (siehe Abbildung 1) ist dann an diesem Rechner oder auch via Remote verfügbar,
von der aus die gesamte Konfiguration angelegt wird.
Abbildung 1: IP-Symcon Verwaltungskonsole
6.1.2 Konkrete Features
IP-Symcon ist als kommerzielles Produkt in drei verschiedenen Produktversionen verfügbar. Alle drei
Versionen unterstützen identische Funktionen und unterscheiden sind im Kern durch die zur Verfü-
gung stehende Komplexität des umzusetzenden Szenarios (Bsp: maximale Anzahl der Geräte).
Als konkrete Schnittstellen die IP-Symcon anbietet, wird in der Produktdokumentation zwischen drei
Gruppen wie nachfolgend aufgelistet unterschieden (siehe auch http://www.ip-
symcon.de/service/dokumentation/komponenten/dienst/schnittstellen/).
Hardware Module
FS10, FS20, HMS, FHT, KS300 (ELV)
Xcomfort (Eaton)
HomeMatic (ELV)
Z-Wave (u. a. ACT, Popp, Düwi, Merten, Innovus, Fibaro)
EnOcean (EnOcean Alliance)
1-Wire (Maxim Dallas)
LCN (Issendorff)
EIB/KNX (u.a. Siemens AG, EIBMarkt, Gira, Jung, Merten, Weinzerl)
Siemens/Vipa SPS (Siemens AG VIPA)
ModBus TCP, ModBus RTU, ModBus RTU over TCP (z.B. Wago/Beckhoff SPS)
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 16
M-BUS (z.B. ALLMESS)
DMX (a.u. DMX4ALL)
UVR1611 (Technische Alternative)
IR-Fernbedienungen (u.a. IRtrans)
ISDN Modul (diverse)
Virtuelle Module
Media Player
Text to Speech
Systeminformationen
RRDTool (Plotter Graphen für z.B. Temperatursensoren)
Shutter Modul
Cutter (Verarbeitet Binärdaten und zerschneidet/synchronisiert diese.)
Text Parser
Event Control
Schnittstellen Module
Serial Port (Com Port)
FTDI
USBXpress
HID
Client Socket
Server Socket
WWW Reader
6.1.3 Installation und Einstieg
Die Installation von IP-Symcon ist intuitiv durchführbar. Im Rahmen der Installation ist die Eingabe
des Produkt-Keys nötig, der dann darüber entscheidet, wie viel Funktionalität für die jeweilige Instal-
lation zur Verfügung steht. Im Rahmen der Evaluation stand eine vollwertige Lizenz zur Verfügung.
Der zentrale Punkt für die Konfiguration von IP-Symcon ist die Verwaltungskonsole. Die Konsole
kann verwendet werden, um einen Überblick über die aktuell verbundenen Komponenten zu gewinnen
oder natürlich auch neue hinzuzufügen. Diese sogenannten „Objekte“ können nun zunächst erst
einmal alles sein, was mit einem intelligenten Wohnsystem zusammenhängt und von IPS unterstützt
wird. Hierzu zählt ein offener TCP-Port (für z. B. eine KNX-Gateway-Verbindung) genauso wie auch
die konkrete Instanz einer steuerbaren Lampe oder eine Variable mit dem Status einer Instanz. Für z.
B. KNX/EIB ist auch ein Konfigurator-Objekt vorhanden, welches eine leichtere Anbindung von IPS
an das bestehende KNX/EIB System erlaubt. Erstellt man die konkrete Instanz eines Objektes, fällt der
erste Schritt zunächst sehr leicht. Einfach das gewünschte Bussystem heraussuchen und eine
unterstützte Komponente auswählen.
Ist die konkrete Instanz erst einmal erstellt, muss sie zunächst noch konfiguriert werden. IP-Symcon
macht einem dies so leicht wie möglich. Es wird für die jeweilige Komponente eine passende Maske
vorgeschlagen. Die nötige Fachkenntnis, um die jeweiligen Parameter (wie eine KNX Adresse)
auszufüllen, werden allerdings vom Nutzer vorausgesetzt. Grundlegende Hilfe hierzu ist in der
Dokumentation zu finden. Für tiefer gehende Details wird allerdings auf den Hersteller verwiesen.
Einer Instanz übergeordnete Objekte (wie Angaben für einen Gateway) werden automatisch erstellt,
müssen jedoch auch noch manuell ausgefüllt werden. Ohne Fachkenntnisse über das jeweilige
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 17
Bussystem kann man hier jedoch leicht erst einmal etwas hilflos vor dieser Aufgabe stehen. Mit ein
wenig Recherche ließen sich im Rahmen der Evaluierung die Probleme jedoch lösen. Auffällig wer
lediglich, dass die Möglichkeiten der Eingabemaske für einen EnOcean Funkschalter nicht mit den
Bedürfnissen übereinstimmte. Während der Stecker eine mehrstellige Hexadezimalzahl zugewiesen
bekommen hatte, konnte innerhalb der IP-Symcon Software nur eine ID zwischen 0 und 127
angegeben werden. Auf Nachfrage beim Support von IP-Symcon wurde lediglich auf den Hersteller
für Fragen verwiesen.
Sind alle Komponenten des System in der Verwaltungskonsole erfasst, können Ereignisse und Skripte
erstellt werden. Ereignisse werden verwendetet, um Skripte unter bestimmten Bedingungen
aufzurufen. Hierzu zählen zum Beispiel zyklisch Aufgaben (bestimmte Tageszeit, einmal im Monat,
…) wie auch der Stand von Variablen (auf den Sonnensensor fällt volles Licht, …). Die Skripte führen
bestimmte Aktionen aus und müssen in PHP geschrieben werden. Dort sind spezielle Methoden
vorhanden, um z. B. KNX Instanzen zu steuern. Natürlich können Skripte auch manuell ausgeführt
werden.
Der von IP-Symcon gestartete Server erstellt außerdem automatisch eine Web-Ansicht auf das
System, welche für die meisten Benutzer auch ohne jede Kenntnis über das technische System
verständlich sein sollte (siehe Abbildung 2).
Diese spiegelt die in der Verwaltungskonsole angegebene Topologie wieder (hier sind nur Büro und
Wohnzimmer angegeben) und die eingetragenen Komponenten werden mit ihren jeweiligen
Parametern angezeigt. Ebenso könnten vorbereitete Skripte abgespielt werden. Die Aufbereitung und
der Inhalt der Ansicht sind in gewissen Grenzen über die Verwaltungskonsole konfigurierbar.
Abbildung 2: Web-Ansicht der IP-Symcon Software
6.1.4 Umsetzung des Use Case
In dieser Umsetzung wurde versucht eine vereinfachte Version einer Sturzprävention zu
implementieren. Es sollte bei Auslösung eines Türkontakt-Events das Licht eingeschaltet werden. Es
wurden bewusst zwei verschiedene nicht kompatible Geräte aus der Gebäude-Systemtechnik
verwendet: KNX und FS20.
Sensor
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 18
FS20 Schalter
Aktor
KNX Deckenlampe sowie FS20 Steckdose
Test
Für den Test wurde IP-Symcon auf einem Laptop installiert, der in das lokale IP-Netzwerk eines intel-
ligenten „Raumes“ integriert war. Die Anbindung der FS20-Funk-Komponenten erfolgte über FS20-
spezifische Koppler, die an den Laptop per USB/FTDI angeschlossen werden.
Im Rahmen des Tests stellte sich heraus, dass die Installation der benötigten Treiber für die Anbin-
dung von FS20 an den Rechner wesentlich aufwendiger war als die nachfolgende Konfiguration in IP-
Symcon, da die Dokumentation des Herstellers vergleichsweise unvollständig ist. Weiterhin muss
beachtet werden, dass sich IP-Symcon als Dienst im Hintergrund auf dem Hostrechner startet und der
Dienst bei jeder Änderung der installierten Hardware neu gestartet werden muss, damit die neu instal-
lierten Anbindungen in der IP-Symcon-Konsole zur Verfügung stehen.
Es war allerdings dennoch möglich, ohne jede Vorkenntnis über IP-Symcon, FS20 sowie KNX inner-
halb von ca. 3-4 Stunden das exemplarische Szenario umzusetzen. Der weitaus größte Teil der Zeit
war nötig, um die benötigten technologiespezifischen Parameter (z. B. FS20 Adresse) zu ermitteln
bzw. sich das benötigte, grundlegende Verständnis hierfür anzueignen.
IP-Symcon ist somit in der Lage technologieübergreifende Szenarien sehr gut abzubilden. Von Spezi-
fika der jeweiligen Technologie zu abstrahieren gelingt allerdings nicht vollständig.
6.1.5 Erweiterung der Software
Die Plattform IP-Symcon bietet von Haus aus bereits einen vergleichsweise großen Funktionsumfang.
Dies beinhaltet die Unterstützung einer Vielzahl von üblichen Protokollen aus dem Bereich der Ge-
bäude bzw. Heimautomatisierung. Um IP-Symcon zu erweitern, stehen grundsätzlich drei verschiede-
ne Ansätze zur Verfügung: (1) Anbindung mittels SOAP, (2) Erweiterung mittels PHP und (3) Erwei-
terung durch ein natives IP-Symcon-Modul.
Die Anbindung an IP-Symcon via SOAP stellt dabei die Lösung bereit, die am stärksten entkoppelt ist
und somit z. B. von der Programmiersprache unabhängig bleibt. Die Befehle und Parameter von IP-
Symcon werden dabei via SOAP abgerufen bzw. geändert. Der SOAP Aufruf kann sowohl lokal als
auch von einer entfernten Entität erfolgen. Durch letzteres kann IP-Symcon auch in verteilten Umge-
bungen eingesetzt werden. Zur Einbindung der Befehlsreferenz in eine andere Anwendung steht eine
für SOAP Web Services übliche WSDL als Schnittstellenbeschreibung zur Verfügung. Nachteilig bei
dieser Lösung ist aber, dass keine direkte Integration in IP-Symcon stattfindet, sondern lediglich die
bestehenden Funktionen von außen erreichbar gemacht werden.
Eine bessere Integration bietet die Möglichkeit der Erweiterung mittels PHP. PHP wird bei IP-Symcon
ebenfalls genutzt, um beispielsweise bestimmte Reaktionen auf Ereignisse zu implementieren. Hierzu
verfügt die IP-Symcon Laufzeitumgebung über Funktionalitäten ähnlich einer üblichen LAMP Instal-
lation auf Web Servern (LAMP: Linux, Apache, MySQL, PHP). PHP kann darüber hinaus aber auch
genutzt werden, um gänzlich neue Komponenten und Protokolle in IP-Symcon zu integrieren. Der
Zugriff auf andere Module und Befehle von IP-Symcon erfolgt über eine definierte API. Ein großer
Vorteil der Nutzung der PHP Skripte gegenüber der Verwendung von SOAP Schnittstellen liegt darin,
dass mittels PHP ebenfalls Elemente im WebFront und/oder der MobileGUI von IP-Symcon generiert
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 19
werden können. Dadurch fügen sich die Erweiterungen für den Endanwender unsichtbar in die Be-
dienoberfläche ein. Die in der Erweiterung implementierten Module und Funktionen stehen aber in der
IP-Symcon Verwaltungskonsole für die Konfiguration des Gesamtsystems nicht zur Verfügung. Ver-
bindungen zwischen nativen IP-Symcon Komponenten und eigenen Erweiterungen müssten somit
ggfs. ebenfalls als PHP Skript abgebildet werden. Weiterhin ist PHP als Skriptsprache zur Implemen-
tierung von dynamischen Webseiten oder Webanwendungen entwickelt worden. Daher wird der Zu-
griff auf Hardwarekomponenten wie Sensoren oder Aktoren nicht immer vollständig unterstützt und
muss u. U. über Umwege erfolgen.
Eine vollständige Integration von eigenen Erweiterungen in IP-Symcon ist somit nur als natives IP-
Symcon Modul möglich, wodurch die eigenen Komponenten als Objekte in der IP-Symcon Verwal-
tungskonsole zur Verfügung stehen. Die Implementierung dieser nativen Module erfolgt mittels eines
kostenlos bereitgestellten SDKs in der Programmiersprache Delphi.
6.1.6 Fazit
Die Software ist ein integriertes Gesamtkonzept, um verschiedenste Hausautomationssysteme zentral
zu konfigurieren und zu bedienen bzw. autonome Prozesse einzurichten.
Obgleich nicht für alle Szenarien zwingend Programmierkenntnisse vorhanden sein müssen und die
Konfiguration vollständig in der grafischen Verwaltungskonsole erfolgen kann, gelingt die Abstrak-
tion gegenüber den verwendeten Technologien nicht vollständig. Es werden viele Möglichkeiten
geboten das Verhalten von intelligenten Wohnumgebungen mit vergleichsweise geringem Aufwand
abzubilden, aber es ist technisches Wissen nötig.
Etwas unklar ist die Entscheidung für die Verwendung von Delphi als Programmiersprache für die
Entwicklung nativer IP-Symcon Module als zusätzliche Plug-Ins. Gerade von Seiten der Forschung
gibt es hier sehr wenig freie Bibliotheken.
Somit bleibt die Frage offen, ob man mit IP-Symcon vollwertige AAL-Anwendungen schreiben kann.
Einfache Regeln und Szenarien aus dem Bereich der Gebäude- und Heimautomatisierung, gerade für
heterogene Umgebungen, dürfte man (teilweise ohne Programmierkenntnisse) sehr schnell umsetzen
können.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 20
6.2 Plattform openHAB
Projektstatus
Name der Plattform openHAB (Version 1.2.0)
URL http://code.google.com/p/openhab/
Anwendungsdomäne
Entstehungskontext
Hausautomation flexibel Erweiterbar für alle Komponenten
Verfügbarkeit von
Ansprechpartnern
Der Hauptkontaktpunkt scheint das Diskussionsforum zu sein
(https://groups.google.com/forum/?fromgroups#!forum/openhab). Sehr
rege Beteiligung im Forum. Es wird sehr schnell und kompetent
geantwortet.
Verfügbarkeit der
Software
Die Software lässt sich ohne Probleme von der vorgesehenen
Downloadseite herunterladen:
http://code.google.com/p/openhab/downloads/list
Entwicklung seit Gestartet 2010
Zeitpunkt des letzten
Updates
15.04.2013
Konkrete Einsatzorte
der Plattform
Das Ziel ist die Steuerung der Hauselektronik, der Elektrogeräte und der
Unterhaltungselektronik, also die Verknüpfung aller in einem modernen
Haushalt vorhandenen Geräte durch Bereitstellung entsprechender
Schnittstellen.
Dokumentation: http://code.google.com/p/openhab/wiki/Architecture?tm=6
Bug tracking: http://code.google.com/p/openhab/issues/list
Anzahl der Downloads: Die neueste Version 1.1.2 wurde am selben Tag der Testung
heruntergeladen, daher kann zu diesem Zeitpunkt keine Aussagen über
die Anzahl der Downloads gemacht werden. Die Version 1.1.0 wurde
bisher fast 2000 Mal heruntergeladen.
Lizenz GPLv3
6.2.1 Was ist OpenHAB?
openHAB stellt eine Art von Konkurrent zu der kostenpflichtigen Software IP-Symcon dar. Der Fokus
liegt sehr stark auf der Hausautomation, wobei dieser Begriff hier allerdings etwas weiter gefasst wird.
Neben der Anbindung verschiedener Bus-Systeme stehen hier auch Wake-on-LAN und die Steuerung
von Multimediageräten wie z. B. TV im Fokus. Diese Funktionalitäten werden über sogenannte
Bindings bereitgestellt und können bei Bedarf mit in das System geladen werden. Möglich wird dies
durch die auf OSGi-basierende Architektur, welche das dynamische Einbinden von zusätzlichen
Funktionalitäten erlaubt. Den Kern des Systems stellt ein auf Jetty basierender Web-Server dar,
welcher mit verschiedenen Konfigurationsdateien eingestellt werden muss. Die wichtigste Konfigura-
tionsdatei ist die „openhab.cfg“, in welcher grundlegende Daten wie die IP-Adresse des KNX IP
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 21
Gateways eingetragen werden müssen. Aber auch die Angabe über existierende Geräte im System,
Regeln oder die Benutzeroberfläche können entsprechend angegeben werden.
OpenHAB Designer
Mit dem openHAB Designer können die existierenden Geräte mittels einer domänenspezifischen
Sprache beschrieben und durch eine regelbasierte Skript-Sprache verarbeitet werden. Der Designer
basiert auf Eclipse SDK und bietet Syntaxhervorhebung und Fehlersuche für die
Konfigurationsdateien.
User Interfaces
Um mit OpenHAB zu kommunizieren gibt es eine Web-UI (siehe Abbildung 3), die über die Adresse
(http://localhost:8080/openhab.app?sitemap=demo) aufgerufen werden kann. Wurde die Installation
und Konfiguration richtig ausgeführt, kann über die Adresse die „Demo“ gestartet werden. Neben der
Web-UI gibt es User Interfaces für iOS, Android (HABDroid), GreenT für Smartphones und Tablets
(http://localhost:8080/greent/) und einen XAMPP (Jabber) Instant Messaging Console.
Abbildung 3: Beispiel der openHAB Web-GUI
Persistenz
Es ist möglich in OpenHAB die Zustände der Geräte (Sensoren und Aktoren) nach zeitlichen Vor-
kommen (Zeitreihen) zu speichern. Je nach Anforderung ist es möglich unterschiedliche Persistenz-
Dienste nebeneinander und voneinander unabhängig konfigurierbar zu nutzen.
Items
Die Geräteabstraktion wird mittels einer domänenspezifischen Sprache realisiert. Sie gibt dem Ent-
wickler die Möglichkeit mit dem Konzept eines „Items“ verschiedene Aktoren wie Schalter, Num-
mern, Kontakte, Dimmer zu definieren, mit denen dann z. B. die KNX-Adressen verknüpfen kann. D.
h. an die abstrakte Gerätebeschreibung werden die konkreten Geräteinstanzen gebunden.
Beispiel
Switch Light_GF_Living_Table "Table" (GF_Living, Lights)
{knx="1/0/15+0/0/15"}
UI Definition
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 22
Ebenso ist es möglich, eine grafische Nutzungsoberfläche flexibel mit den jeweils definierten Aktoren
zu erstellen.
Automation
Mittels einer skriptbasierten Sprache ist es möglich, auf die eigens definierten Aktoren und Sensoren
programmatisch zuzugreifen. Die Auslöseregeln (Trigger_Conditions) können folgende Form haben:
Item(-Event)-based trigger: Reaktion auf Events auf dem Event-Bus (Statusänderungen)
Time-based triggers: Reaktionen zu einer bestimmten Uhrzeit (z. B. zu jeder Stunde, um
Mitternacht)
System-based triggers: Reaktion auf einen bestimmten Systemstatus
Security
OpenHAB unterstützt zwei Kommunikationsmechanismen:
HTTPS: Über https://127.0.0.1:8443/openhab.app?sitemap=demo# Verschlüsselung per SSL
Authentifikation: Über JAAS wird der Log-in geregelt. Mit den Parametern -
Djava.security.auth.login.config=./etc/login.conf wird JAAS konfiguriert
In der users.cfg Datei können "user=pwd" Paare eingetragen werden, die dann für die Authentifikation
verwendet werden. Die Security Optionen werden dann in der openhab.cfg gesetzt.
6.2.2 Konkrete Features
Die Erweiterungen (Bindings) werden separat angeboten. Über eine Konfigurationsdatei können die
Features eingebunden und angesprochen werden. Jedes Feature entspricht einem OSGi-Bundle. Durch
die aktive Community wird das Angebot externe Hardware anzubinden ständig erweitert. In der unten-
stehenden Liste sind nur einige der Erweiterungen aufgeführt.
Asterisk Binding
Bluetooth Binding
CUPS Binding
DMX512 Binding
Exec Binding
Fritz!Box Binding
HomeMatic Binding
HTTP Binding
IHC / ELKO Binding
KNX Binding
Koubachi Binding
Modbus TCP Binding
MPD Binding
Network Health Binding
Novelan Heatpump Binding
NTP Binding
One-Wire Binding
OSGi Configuration Admin Binding
Philips Hue Binding
Plugwise Binding
PLCBus Binding
Pulseaudio Binding
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 23
RFXCOM Binding
Samsung TV Binding
Serial Binding
Snmp Binding
Sonos Binding
TCP/UDP Binding
VDR Binding
Wake-on-LAN Binding
6.2.3 Installation und Einstieg
Der initiale Installationsaufwand ist als relativ gering einzuschätzen. Die Anbindung an das bei uns
vorhandene KNX-Gateway ließ sich anhand der Beschreibung schnell realisieren. Die erzeugte
Weboberfläche zum Steuern der registrierten Geräte ließ sich auch ohne Probleme starten und
verwenden. Einen ersten Eindruck der Software erhält man am besten mit dem „Quick Setup“ auf der
Wiki-Page (http://code.google.com/p/openhab/wiki/Setup). Die Anleitung ist auf das nötigste reduziert
und zugleich verständlich umgesetzt.
Hardware-Anforderungen
Die OpenHAB-Runtime ist in Java geschrieben und braucht daher eine JVM (>=1.6). Derzeit laufen
noch die Arbeiten, um die Plattform auch auf low-end embedded Geräten wie dem Raspberry Pi in-
stallieren zu können.
6.2.4 Umsetzung des Use Case
In dieser Umsetzung wurde versucht eine vereinfachte Version einer Sturzprävention zu
implementieren. Es sollte bei Auslösung eines Türkontakt-Events das Licht eingeschaltet werden. Es
wurden mit Absicht zwei verschiedene nicht kompatible Geräte aus der Gebäudesystemtechnik ver-
wendet: KNX und HomeMatik.
Hardware
Die OpenHAB-Runtime und der Designer wurden auf einem Fujitsu-Siemens Lifebook E-Serie instal-
liert. Der Rechner hatte folgende Leistung:
Prozessor: Intel(R) Core(TM)2 Duo CPU T8100 2.10 GHz
Arbeitsspeicher: 4 GB RAM
System: Windows 7, 64 Bit-Betriebssystem
Sensor
HomeMatic Türkontakt
Aktor
KNX Deckenlampe
Konfiguration
Anbindung KNX und HomeMatik in der initialen Konfigurationsdatei openhab.cfg:
################################ KNX Binding ###########################
# KNX gateway IP address
# (optional, if serialPort or connection type 'ROUTER' is specified)
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 24
knx:ip=192.xx.x.xx
Gerätebeschreibung und Binding
Als erstes wurde mithilfe des Designers die Datei demo.items angepasst.
Es wurden die Deckenlampe und der Türkontakt in Form eines Schalters (Switch) beschrieben, denen
ein Namen und ein Binding zugeordnet wurden. Der Schalter Tuer_Schlafzimmer wurde mit dem
Binding (HomeMatic) und dem konkreten Gerät GEQ0080535 verbunden. Diese Gerätenummer kann
über die HomeMatic Web UI herausbekommen werden. Der zweite Schalter namens
Light_FF_Bath_Ceiling wurde der KNX Deckenlampe mit der Adresse 11/0/0 zugeordnet.
Switch Tuer_Schlafzimmer "Tüer Schlafzimmer" { HomeMatic="GEQ0080535:1#STATE" }
Switch Light_FF_Bath_Ceiling "Ceiling" (FF_Bath, Lights) { knx="11/0/0" }
Steuerung
In der Datei demo.rules wurde eine sehr einfach Regel verwendet, die bei auslösen des Türkontakts
das Licht einschaltet.
rule Tuerkontakt when Item Tuer_Schlafzimmer changed then sendCommand(Light_FF_Bath_Ceiling, ON) end
Test
Nachdem openHAB gestartet wurde, wurde durch das Auslösen des Türkontakts die Regel angewen-
det und das Licht eingeschaltet. Der Test war somit erfolgreich.
6.2.5 Erweiterung der Software
Die interne Kommunikation zwischen den einzelnen Komponenten einer OpenHAB Laufzeitumge-
bung findet mittels eines Event Busses statt. Dieser Event Bus nutzt den in OSGi bereits vorhandenen
OSGi EventAdmin Service. Dies ist ein interessanter Ansatz, denn der OSGi EventAdmin Service ist
in der Lage, auch entfernte OSGi Umgebungen über Remote Services miteinander zu koppeln. Da-
durch können verschiedene OpenHAB Laufzeitumgebungen auf getrennten physikalischen Geräten
über den zentralen Event Bus miteinander kommunizieren.
Die Erweiterung um eigene Protokolle zur Sensoranbindung findet mittels sogenannter Bindings statt.
Jedes Binding realisiert dabei die konkrete Vermittlung zwischen dem externen Protokoll und dem
internen Event Bus.
Da OpenHAB auf OSGi aufsetzt wird jedes Binding als eigenständiges OSGi Bundle implementiert,
wodurch jedes Binding zur Laufzeit dynamisch geladen und entfernet werden kann. Zur Konfiguration
des Binding, wie beispielsweise protokollspezifische Adressierung der Sensoren und Aktoren, wird
der OSGi Configuration Admin Service genutzt.
Um sich in die OpenHAB Architektur zu integrieren müssen Protokoll Bindings zustandslos imple-
mentiert werden. Das bedeutet, dass keinerlei Zustände der Sensorik oder der Aktorik im Bundle des
Bindings verwaltet werden. Es dürfen lediglich solche Zustandsinformationen im Bundle selbst bereit-
gehalten werden, um eine Verbindung über das implementierte Protokoll zu ermöglichen. Für alle
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 25
weiterführenden Zustände, wie beispielsweise Anwendungsdaten, steht das OpenHAB Repository zur
Verfügung. Dieses Repository ist die einzige zustandsbehaftete Komponente im System und kann über
den zentralen Event Bus von allen anderen Komponenten angesprochen werden.
Abbildung 4: Eventmechanismus (Quelle der Abbildung:
http://code.google.com/p/openhab/wiki/Architecture)
6.2.6 Fazit
OpenHAB ist eine sehr erfolgversprechende Plattform. Sie bringt alles mit was die Steuerung von
Hausautomationskomponenten braucht. Eine Geräteabstraktion für die wichtigsten Steuerungselemen-
te, einen flexiblen Binding-Mechanismus, viele bereits unterstütze Komponenten und eine Persisitenz-
schicht sowie eine aktive Community machen openHAB zu einer sehr flexiblen zukunftsträchtigen
Plattform für AAL-Anwendungen.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 26
6.3 OpenRemote
Projektstatus
Name der Plattform Open Remote
URL http://www.openremote.org
Anwendungsdomäne
Entstehungskontext
Fernsteuerung / Controll Panel für Heim- und Gebäudeautomatisierung
Verfügbarkeit von
Ansprechpartnern
Sehr gut via: Forum, E-Mail, F.A.Q., Social Media
Verfügbarkeit der
Software
Die Software lässt sich ohne Probleme von der vorgesehenen
Downloadseite herunterladen:
http://www.openremote.org/display/HOME/Download
Entwicklung seit Unbekannt
Zeitpunkt des letzten
Updates
29.04.2013
Konkrete Einsatzorte
der Plattform
Fernsteuerung von Geräten, Sensoren und Aktoren im häuslichen Umfeld.
Also Panel dienen Smartphones, Tablets und PCs/Laptops. Unterstützt
werden diverse Protokolle der Heim- und Gebäudeautomatisierung.
Dokumentation: http://www.openremote.org/display/docs/OpenRemote+Documentation
Getrennt nach Anwendern und Entwicklern.
Bug tracking: Via Forum
http://www.openremote.org/display/forums/OpenRemote+Forums
Anzahl der Downloads: Ca. 150 pro Tag bei Source-Forge
Lizenz Kombination aus Open Source (Controller) und Closed Source (Designer
für Panels). Affero GNU Public License , GNU General Public License
version 2.0 (GPLv2)
6.3.1 Was ist OpenRemote?
OpenRemote ist eine Plattform mit dem Schwerpunkt auf der Heimautomatisierung. Der Fokus liegt
darin, eine Lösung unabhängig von der am Markt verfügbaren Lösungen bereitzustellen, um auch
Laien die volle Kontrolle über autonome/intelligente Systeme zu ermöglichen. Es fällt daher in eine
Gruppe mit den ebenfalls getesteten Plattformen openHAB und IP-Symcon. Zumindest entsprechend
dem eigenen Anspruch, geht es OpenRemote darum eine Plattform für das „Internet der Dinge“ zu
sein. Entsprechend sollten sich beliebige Geräte integrieren lassen und hierfür auch Methoden bereit-
gestellt werden. Im Gegensatz zu den anderen Plattformen aus dem Bereich der Heimautomatisierung
sieht OpenRemote „Assisted Living“ sogar als ein festes Anwendungsgebiet und wirbt mit einer Refe-
renz für ein Projekt, in welchem Lichter durch Eye-Tracking gesteuert werden können1.
1 http://www.openremote.com/references/, Stand 13.05.2013
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 27
OpenRemote bietet in einer Kombination aus freier und lizenzierter Software Komponenten der Platt-
form an. Der Web-Auftritt des freien Teils ist zu finden unter http://www.openremote.org und der
kommerzielle unter http://www.openremote.com. Die grundlegende Architektur ist in Abbildung 5 zu
sehen.
Abbildung 5: Architektur von OpenRemote (Quelle: http://www.openremote.com/)
In einem lokalen Netzwerk wird ein Controller verwendet, welcher die verschiedenen Protokolle und
Technologien der jeweiligen Geräte im Heimnetz als Plug-In implementiert. Dieser Controller ist frei
verfügbar und kann kostenlos lokal auf einem Rechner installiert werden. Der Controller dient als
zentrale Schaltstelle und ermöglicht den Zugriff auf die einzelnen Funktionen. Es gibt aber auch
entsprechende Apps für Android und iOS.
Durch die Spaltung in kommerzielle und freie Komponenten, ist der Controller und der Konfigurator
nur in der Basisversion frei verfügbar. Der Designer ist aber in seiner Funktionalität eingeschränkt.
Um erweiterte Funktionen und Zugriff auf alle unterstützten Protokolle über die Benutzeroberflächen
zu erhalten, müssen hier die kostenpflichtigen Versionen verwendet werden. Indem Interfaces immer
nur in der Cloud bleiben, sichert sich OpenRemote die volle Kontrolle über die Verwendung ihrer
Software, obwohl weite Teile dieser frei verfügbar sind.
Der nachfolgende Test bezieht sich auf die kostenlos verfügbare Version.
6.3.1.1 Konkrete Features
OpenRemote stellt eine umfassende Plattform bereit, welche sowohl Entwickler als auch Endbenutzer
ansprechen soll. Dies bedeutet auf der einen Seite die Bereitstellung von entsprechenden Dokumenta-
tionen und Schnittstellen zum Controller, um es Entwicklern zu erlauben den Controller zu erweitern.
Auf der anderen Seite sind ebenso Tutorien und Handbücher vorhanden, um Benutzer in der Verwen-
dung zu unterstützen. Der Funktionsumfang reicht von der Bereitstellung der Kontrolloberflächen für
Browser, iPhone und Android, über die Unterstützung zahlreicher Protokolle aus dem Bereich der
Hausautomation und Netzwerktechnik, bis zur Unterstützung verschiedener Hardware-Elemente wie
Raspberry Pi oder QNAP NAS. Eine vollständige Auflistung findet sich auf der Seite von OpenRemo-
te auf Sourceforge.net2.
2 http://sourceforge.net/projects/openremote/, Stand 15.05.2013
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 28
6.3.2 Installation und Einstieg
Der Einstieg und die Installation in OpenRemote wird einem relativ einfach gemacht, da die entspre-
chenden Anleitungen und Tutorien eindeutig und vollständig sind3. Im Grunde müssen drei Teile ein-
gerichtet werden. Zum einen muss der Controller lokal installiert und gestartet werden. Herunterladen
lässt sich dieser als ein ZIP-File mit den entsprechenden Dateien und einem Batch-File zum Ausfüh-
ren. Technisch wird ein Apache Tomcat als Laufzeitumgebung verwendet. Eine Installation von Java
ab einer Version 1.6.0 wird benötigt. Der nächste Teil ist die App um die Interfaces von OpenRemote
empfangen und anzeigen zu können. Diese sind als APK-Datei für Android und im iStore als Down-
load verfügbar. Als letztes ist schließlich eine Registrierung für den Online-Designer notwendig.
6.3.3 Umsetzung des Use Case
Die Umsetzung des Use Case erfolgte mit KNX Deckenlichtern und EnOcean Bewegungsmeldern.
FS20 wird nativ momentan nicht unterstützt. Zur Umsetzung war zunächst eine Konfiguration des
Controllers notwendig. Die einzelnen Schritte werden hierfür in der Dokumentation ausführlich be-
schrieben4. Es muss die Adresse des KNX IP-Gateways in eine Konfigurationsdatei eingetragen und
der Controller neu gestartet werden. Mit dem verwendeten Gira IP Router 103000, welcher sich im
gleichen Subnetz wie der Testrechner befand, konnte eine Verbindung aufgebaut werden. Nicht unter-
stützt wurde der Thermokon 467445 STC-Ethernet Gateway zur Anbindung der vorhandenen EnOce-
an Sensoren. Ein offiziell unterstütztes Gateway mit USB Anschluss stand zum Testen leider nicht
bereit. Ebenso scheint EnOcean generell auch nur von der professionellen und somit kostenpflichtigen
Variante des Designers angeboten zu werden.
Der Designer selbst unterstützt grundlegend zunächst drei Typen von Komponenten, welche hinzuge-
fügt werden können: Devices, Macros und Konfigurationen für den Controller. Makros sind ein Werk-
zeug um mehrere Befehle zusammenzufassen. Ein gutes Beispiel hierfür ist eine Methode, welche alle
Geräte im Haus ausschaltet. Dieses Feature wurde aber nicht weitergehend getestet.
Ein Device entspricht einem Container für sogenannte „Kommandos“ und „Sensoren“. Die Komman-
dos abstrahieren hierbei von der Protokollebene, die Parameter sind entsprechend vom gewählten Pro-
tokoll abhängig. Im Fall der KNX-Lichter sind dies die KNX-Adresse, der KNX-Befehl und die KNX-
Kennung des Befehlstyps. Wer mit dem KNX-Protokoll vertraut ist, dürfte an dieser Stelle schnell zu
Ergebnissen kommen. Ansonsten wäre eine entsprechende In-Line Hilfe sehr hilfreich, zumal auch bei
anderen Protokollen nicht alle Parameter selbsterklärend sind. Im User-Tutorial werden allerdings die
meisten Protokolle ausreichend erklärt, um zumindest simple Fälle gut abdecken zu können. Sensoren
benötigen ein Kommando als Basis und bekommen einen Typ zugeordnet. Um den Test an dieser
Stelle nicht direkt zu beenden, wurde im Online-Designer ein Dummy für den Sensor angelegt. Dieser
basiert auf der Statusmeldung eines KNX-Deckenlichtes. Die Idee ist hierbei das eine Licht automa-
tisch angehen zu lassen, wenn ein anderes seinen Status wechselt.
Die entsprechende Regel für diesen Vorgang ließ sich mit den sogenannten „Rules“ umsetzen, welche
ein Teil der Controller-Konfiguration darstellt. Die Rule Engine verwendet eine auf den ersten Blick
an Java erinnernde Sprache. Die einfache Regel für das Beispiel ließ sich recht schnell durch Anpas-
sung des Beispiels „Command Execution Example“ von der Seite des entsprechenden Tutorials um-
setzen. Kompliziertere Beispiele dürften hier jedoch größere Probleme bereiten, zumal keine zusam-
3 http://www.openremote.org/display/docs/Get+Started, Stand 13.05.2013
4 http://www.openremote.org/display/docs/OpenRemote+2.0+How+To+-+KNX, Stand 13.05.2013
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 29
menhängende Beschreibung der Programmiersprache zu finden ist (nur Beispiele). Benutzer ohne
Programmiererfahrung dürften der Aufgabe eine solche Regel zu erstellen nicht gewachsen sein.
6.3.4 Erweiterung der Software
Die Plattform OpenRemote steht in zwei verschiedenen Konfigurationen zur Verfügung. Die kostenlo-
se Konfiguration ist vollständig Open Source zugänglich und kann frei genutzt werden. Die kosten-
pflichtige Version umfasst typische Open Source Zusatzdienstleistungen wie beispielsweise Support,
Branding der GUIs um das Produkt als OEM zu vertreiben. Daher wird die kostenpflichtige Variante
in die Kundenrollen Distributor, OEM und Integrator unterteilt.
Um OpenRemote um eigene Protokolle bzw. Sensorik und Aktorik zu erweitern müssen die beiden
Komponenten Designer und Controller angepasst werden. Detaillierte Informationen hierzu können
auch den entsprechenden Tutorials entnommen werden5.
Der Controller bildet die zentrale Steuerungseinheit, die im lokalen Netzwerk installiert wird. Die
Daten und Kommandos, die an einen Sensor bzw. Aktor gesendet werden, müssen zur Einbindung
mittels der abstrakten Kommandos Read (eingehend) und Write (ausgehend) abgebildet werden. Diese
Kommandos inkl. der dazugehörigen Parameter werden in XML beschrieben. Die beschriebenen
Kommandos werden dann, unter Berücksichtigung der Abstraktion mittels Read/Write Kommandos,
in Java für den Controller implementiert und diesem als Komponente hinzugefügt. Durch die ver-
gleichsweise triviale Abbildung aller Befehle auf einfache lesende und schreibende Aufrufe ist es bei
OpenRemote möglich, ähnlich wie bei IP-Symcon, Kommandos der Laufzeitumgebung übers Netz-
werk aufzurufen. OpenRemote nutzt hierfür eine einfache HTTP REST API und nicht wie IP-Symcon
SOAP.
Die gesamte Konfiguration des Controllers findet mittels des Designers statt. Alle Prozesse und Ereig-
nisse werden im Designer modelliert. Der Controller verbindet sich mit dem Designer und ruft die
Konfiguration ab. Um neue Protokolle bzw. Geräte im Designer hinzuzufügen, müssen diese inkl. der
Kommandos in XML beschrieben werden. Eine weiterführende Implementierung für den Designer ist
nicht nötig, da die Funktionalität ausschließlich vom Controller bereitgestellt wird.
OpenRemote stellt einen Designer auf seinen eigenen Servern kostenlos zur Verfügung. Nach der
Registrierung kann man dort seine eigene Umgebung modellieren. Es ist nicht möglich eigene Proto-
kolle zu diesem Designer hinzuzufügen, außer das Protokoll wird offiziell vom Betreiber von Open-
Remote hinzugefügt. In der kostenlosen Version muss daher ein Designer auf einem eigenen Server
installiert werden. Im Gegensatz zum Installieren des Controllers steht für die Installation des Desig-
ners bislang aber keine Dokumentation zur Verfügung. In der kostenpflichtigen Variante von Open-
Remote wiederum wird pro Kunde ein eigener Designer genutzt, der dann entweder auf einem eigenen
Server oder dem Server von OpenRemote installiert ist. Da diese Designer von der kostenlosen Va-
riante getrennt laufen und kundengebunden sind, können auch hier die eigenen Protokollbeschreibun-
gen hinzugefügt werden.
6.3.5 Fazit
OpenRemote macht zusammenfassend einen guten Eindruck in Bezug auf die Gesamtpräsentation.
Hierzu zählen vor allem die gute Dokumentation und ein überzeugendes Geschäftsmodell, was bei
5 http://www.openremote.org/display/docs/OpenRemote+2.0+Developer+Tutorial, Stand 15.05.2013
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 30
wissenschaftlichen Plattformen oft weniger der Fall ist. Wer überlegt OpenRemote für seine Anwen-
dung zu benutzen, sollte dennoch genau die Liste der unterstützen Hardware untersuchen. Gerade die
kostenlose Variante hat hier relativ starke Einschränkungen, vor allem auch, weil der Designer nicht
ohne Weiteres um eigene Komponenten erweitert werden kann. AAL-Anwendungen lassen sich ent-
sprechend mit OpenRemote als Basis umsetzen, um die kostenpflichtige Variante wird man hierbei
jedoch kaum herumkommen. Ggf. bietet es sich als Lösung an, den Kontroller lediglich als eine Art
Middleware zu betrachten und diesen über entsprechende HTTP Requests in einer externen Anwen-
dung als Proxy für die dort angeschlossenen Komponenten zu verwenden (siehe API Dokumentation).
Hier hängt der Nutzen sicherlich davon ab, wie viele der zu verwendeten Geräte von OpenRemote
schon unterstützt werden.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 31
6.4 Plattform MundoCore (uMundo)
Projektstatus
Name der Plattform MundoCore, jetzt „uMundo“
URL http://umundo.tk.informatik.tu-darmstadt.de/ bzw.
https://github.com/tklab-tud/umundo
Anwendungsdomäne
Entstehungskontext
Middleware für verteilte Anwendungen, Forschungsprojekt
Verfügbarkeit von
Ansprechpartnern
Kontakt zu den Entwicklern über die Seiten der TU Darmstadt möglich
Verfügbarkeit der
Software
Frei zum Download auf dem Projekt-Wiki
Entwicklung seit Ältester Nachweis auf der Homepage stamm aus dem jahr 2008
Zeitpunkt des letzten
Updates
Version 0.3.4-pre vom 01.05.2013, letzte GidHub Update am
14.05.2013
Konkrete Einsatzorte
der Plattform
Allgemein handelt es sich bei Mundo Core um eine Middleware für
verteilte Umgebungen. Die einfache Möglichkeit, Knoten miteinander
Kommunizieren und Daten austauschen zu lassen steht im
Vordergrund. Hierzu gehören Publish/Subscribe Methoden genauso wie
Methoden zur Serialisierung von Objekten und Remote Service-Calls.
Dokumentation: https://github.com/tklab-tud/umundo und auch Java-Doc unter
http://umundo.tk.informatik.tu-darmstadt.de/docs/
Bug tracking: Nicht gefunden
Anzahl der Downloads: Kein Information vorhanden
Lizenz Open-Source (MPL license)
6.4.1 Was ist MundoCore?
MundoCore ist ein Projekt, welches von der Gruppe Telecooperation der TU Darmstadt entwickelt
und bereitgestellt wurde. Direkt vorwegzunehmen ist an dieser Stelle, dass es von den getesteten Pro-
jekten am wenigsten die Kriterien an eine Plattform erfüllt. MundoCore ist vielmehr eine Middleware
für verteilte Umgebungen, um auf einer sehr großen Anzahl von Knoten zu funktionieren. Zum Funk-
tionsumfang gehören Publish/Subscribe Methoden genauso wie Methoden zur Serialisierung von Ob-
jekten, Remote Service-Calls und Methoden zur Einbindung eigener Protokolle und Routingverfahren.
MundoCore wurde komplett überarbeitet und nennt sich nun „uMundo“. Das Ziel dieser Version war
die Entwicklung einer leichtgewichtigeren Software. Sie sollte überschaubarer und entsprechend bes-
ser wartbar sein. Erreicht werden sollte dies vor allem durch die Verwendung bekannter offener Bi-
bliotheken aus der Netzwelt. Im Wesentlichen ist uMundo jetzt eine Möglichkeit zur Umsetzung von
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 32
auf Publish/Subscribe Algorithmen basierenden Anwendungen zum Versenden von Byte-Arrays und
Objekten unter der Verwendung von Bonjour/Avahi, ZeroMQ und Protobuf.
Auch wenn die Plattform von der Ausrichtung her damit noch weiter aus dem Fokus AAL heraus-
rutscht, adressiert sie immer noch ein Kerngebiet vieler AAL Systeme: Verteilte Systeme. Eine Stärke
ist hier die hohe Anzahl an unterstützten Betriebssystemen inklusive passender Serialisierung. Zumin-
dest auf nativer Ebene und gemessen am Umfang steht uMundo damit in den von uns dargestellten
Plattformen alleine da. Wer demnach für seine AAL-Anwendung auf einer low-level Komponenten
mit verschiedenen Laufzeitumgebungen verknüpfen möchte, kann einen Blick auf uMundo werfen.
6.4.1.1 Konkrete Features
uMundo stellt Bibliotheken zur Umsetzung von Publish/Subscribe Algorithmen und der Serialisierung
von Nachrichten auf den verwalteten Kanälen bereit. uMundo ist verfügbar für MAC OSX, iOS, Win-
dows, Debian Linux, Raspberry Pi und Android. Der Code ist frei verfügbar, aber es stehen auch
kompilierte Versionen für alle aufgeführten Betriebssysteme zur Verfügung. Weiterhin sind Vorlagen
für die eigene Kompilierung und Programmerstellung für Eclipse, XCode und Visual Studio vorhan-
den.
Für das Discovery wird Bonjour6 (Max OS) oder Avahi
7 verwendet. Beide sind kompatibel und stellen
Bibliotheken zum Aufbau von Netzen ohne eine Art der initialen Konfiguration dar. Daten werden als
Byte-Array mit ZeroMQ8 übertragen. Letzteres ist eine Softwarebibliothek, welche durch die Verwen-
dung verschiedener Protokolle (inproc, IPC, TCP und Multicast) effizient Daten in einem verteilten
System übertragen kann. Die Serialisierung von Objekten kann alternativ verwendet werden. Hierfür
wird eine Lösung auf der Basis von Protocol Buffers9 bereitgestellt. Die entsprechende Komponente
existiert für C++, Java, C# und Objective-C.
6.4.2 Installation und Einstieg
uMundo braucht zumindest für die Verwendung in Java keine Installation, da es als kompilierte Libra-
ry zum Download bereitsteht. Im durchgeführten Test gab es mit dieser auch keine Probleme. Zusätz-
lich sind aber auch Installer für alle Versionen verfügbar10
. Als Startpunkt wurde das in GitHub be-
reitgestellte Beispielprojekt für Eclipse verwendet11
. In Kombination mit einer JDK 1.6.0_30 und der
vorkompilierten uMundo-Bibliothek konnte das Beispiel ohne Problem kompiliert und gestartet wer-
den.
6.4.3 Umsetzung des Use Case
uMundo bringt von Haus aus keinerlei Anbindung irgendeiner Hardware mit sich, da der Fokus auf
der Verwaltung von Netzwerken liegt. Die Idee für den Test bestand daher darin vorhandene Projekte
6 https://developer.apple.com/bonjour/, Stand 03.06.2013
7 http://avahi.org/, Stand 03.06.2013
8 http://www.zeromq.org/, Stand 03.06.2013
9 https://code.google.com/p/protobuf/, Stand 03.06.2013
10 http://umundo.tk.informatik.tu-darmstadt.de/installer/, Stand 04.06.2013
11 https://github.com/tklab-tud/umundo/tree/master/examples/java, Stand 04.06.2013
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 33
und Bibliotheken zur Steuerung der benötigten Komponenten zu verwenden, um ein Client-Server
basiertes System aufzubauen. Der Server hat hierbei die Kontrolle über Lampen und der Client, an
welchen Bewegungsmelder angeschlossen wurde, spricht den Server bei Bewegung an. Es konnte auf
entsprechende Java-Anbindungen für EnOcean, KNX und FS20 zurückgegriffen werden, welche in
der Lage sind Befehle der einzelnen Busse abzugreifen oder einzuspeisen. Tatsächlich verwendet
wurde als Hardware eine Gira IP Router 103000 zum Zugriff auf ein dimmbares KNX-Deckenlicht
und ein FHZ1300 PC zum Empfangen von Meldungen eines ELV FS20 Funkbewegungsmelders. Das
FHZ1300 kann über die serielle Schnittstelle mit RXTX angesprochen werden. Die verwendete Bi-
bliothek für das FS20 Protokoll ist ein Teil des NetHome Server12
. Letzterer stellt eine Software zur
Anbindung diverser Funkgeräte aus der Hausautomation dar und beinhaltet auch eine offene Schnitt-
stelle für FS20. Im Grunde kann man den NetHome Server selbst als eine simple Art von Plattform
betrachten. Eine volle Featureliste ist der Doku der Homepage zu entnehmen. Zum Ansprechen von
KNX wurden die Calimero 2 Bibliotheken13
in einem vorkonfigurierten Bus verwendet.
Das von uMundo bereitgestellt Beispiel eines Chat-Clienten wurde mit dieser Basis so ausgebaut, dass
der sogenannte Greeter (Bus-Publisher in uMundo) Nachrichten über einen als „FS20“ bezeichneten
Kanal sendet, sobald der Bewegungsmelder eine Aktivität meldet. Der Receiver (Bus-Subscriber in
uMundo) empfängt diese und schaltet entsprechend unter Verwendung von Calimero das Deckenlicht
ein (wenn es nicht schon an ist). Dieses Minimalbeispiel lief ohne Problem auf einem und mehreren
Rechnern.
Wie bereits beschrieben erfüllt uMundo am wenigsten die Kriterien an eine Plattform und der durch-
geführte Test beruht rein auf klassischer Programmierarbeit und nicht wie bei anderen Plattformen auf
der Konfiguration eines Systems. Dennoch ist die beschriebene Umsetzung ein gutes Beispiel dafür,
wie Plattformfunktionalität erreicht werden kann, ohne wirklich eine Plattform zu verwenden. Viel-
mehr sucht man sich Komponenten in der gewünschten Programmiersprache, die die benötigte Funk-
tionalität bietet (hier FS20 und KNX steuern, sowie ein verteiltes System zu beherrschen) und verbin-
det sie mit möglichst minimalem Programmieraufwand. Als Vorteil zeigt sich schnell, dass man als
erfahrener Programmierer so schnell einen Zugang findet und sehr viele (bzw. alle) Möglichkeiten hat
die Anwendung frei zu gestalten. Als Nachteil ergibt es sich entsprechend direkt, dass man für jede
Funktionalität, welche das Programm zusätzlich noch beherrschen soll, sich wieder eine neue Biblio-
thek suchen muss und sich in diese einarbeiten.
Ob sich dieser Weg lohnt, hängt in einem hohen Maß davon ab, inwieweit eine andere Plattform benö-
tigte Funktionalitäten bereits bereitstellt und wie gut diese ggf. erweiterbar ist. Problematisch wird es
aber auf jeden Fall, wenn das System nach oben skaliert. Ohne eine klare Architektur, welche eine
Plattform normalerweise bereitstellt, droht schnell nicht mehr wartbarer Code oder sehr viel zusätzli-
che Arbeit.
6.4.4 Erweiterung der Software
Die Kommunikation der Komponenten in MundoCore findet, ähnlich wie bei OpenHAB, mittels eines
zentralen Busses statt. MundoCore nutzt hier einen Publish/Subscribe Bus und implementiert diesen
selbst, da es nicht wie z. B. OpenHAB auf OSGi aufsetzt. Dies hat den Vorteil, dass eine OpenHAB
Laufzeitumgebung auch in anderen Programmiersprachen implementiert und dann über das Netzwerk
12
http://wiki.nethome.nu/doku.php/start, Stand 04.06.2013
13 http://sourceforge.net/p/calimero/wiki/Home/, Stand 05.06.2013
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 34
mit anderen MundoCore-Installationen verbunden werden kann. Die Java-Laufzeitumgebung ist aber
aktuell die verbreitetste.
Eine Komponente bzw. ein Plug-In in MundoCore wird in Java als einzelne JAR Datei implementiert.
Die JAR Datei enthält alle notwendigen Dienste, alle Klasse, RMC Stubs usw. Die Komponente im-
plementiert ebenfalls die Verbindung zum zentralen Publish/Subscribe Bus. Der Vorteil die Kompo-
nenten als einzelne JAR Datei abzubilden ist, dass diese dynamisch zur Laufzeit nachgeladen werden
können. Damit wird ein ähnliches Verhalten wie der Bundles in OSGI ermöglicht. Für die Konfigura-
tion der Komponenten zur Laufzeit müssen spezielle Schnittstellen implementiert werden. Dies ist
ähnlich zum OSGi Configuration Admin Service, wie er z. B. von OpenHAB verwendet wird. Zur
Einbindung der Komponente muss diese mittels XML Konfigurationsdateien beschrieben werden.
Eine Erweiterung um zusätzliche Protokolle wird mittels spezieller Protocol Handler realisiert. Solche
Protocol Handler sind MundoCore Komponenten, die spezifische, zusätzliche Schnittstellen zum Pu-
blish/Subscribe Bus haben. Es ist möglich für die Einbindung eigener Protokolle mehrere Protocol
Handler aneinanderzureihen. Dadurch kann stufenweise die Abstraktion von sehr konkret und proto-
kollspezifisch zu allgemeingültig und abstrakt realisiert werden. Die Aneinanderreihung ist dabei nur
logisch zu sehen. Der Datenaustausch zwischen den Stufen findet über den zentralen Pu-
blish/Subscribe Bus statt. Dazu kann jede Stufe in der Kette der Protocol Handler eigene Mime-Types
für die übergebenen Daten definieren. Ähnlich wie bei den Mime-Types bekannt aus Internet Anwen-
dungen klassifiziert der Mime-Type eines Protocol Handlers die Daten im Rumpf einer Nachricht auf
dem Publish/Subscribe Bus.
6.4.5 Fazit
Das hier getestete uMundo spielt in diesem Zusammenhang insofern eine interessante Rolle, als dass
es sich von den vorgestellten Produkten am wenigsten in den schwammigen Begriff „Plattform“ pres-
sen lässt, weil es eher die Kriterien einer klassischen Middleware erfüllt. Da verteilte, selbstorganisie-
rende und eventbasierte Systeme ein wichtiger Teil von AAL-Anwendungen sind und uMundo hier
wichtige Bereiche abdeckt.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 35
6.5 universAAL
Projektstatus
Name der Plattform universAAL
URL http://universaal.org/
http://depot.universaal.org http://forge.universaal.org/gf/
Anwendungsdomäne
Entstehungskontext
Middleware für die Entwicklung verteilter AAL-Applikationen.
Entstanden im Rahmen eines EU-Forschungsprojektes.
Verfügbarkeit von
Ansprechpartnern
Nach der Anmeldung unter http://forge.universaal.org/gf/ kann man in
den Foren der einzelnen Projekte Kontakt mit dem universAAL-Team
aufnehmen.
War die Autorisierung als Benutzer erfolgreich, darf auf Entwickler-
Ressourcen wie z. B. Wikis und Feature- bzw. Bug-Tracker zugegriffen
werden. Es ist auch möglich dabei neue Tickets zu erstellen.
Verfügbarkeit der
Software
universAAL kann kostenlos heruntergeladen werden.
Entwicklung seit 01.02. 2010 (baut auf Ergebnisse seit 1999 auf)
Zeitpunkt des letzten
Updates
Version 2.0.0 vom 30.04.2013. Das Trunk-Verzeichnis im SVN erhält
täglich Aktualisierungen.
Konkrete Einsatzorte
der Plattform
Die Plattform ermöglicht es, heterogene AAL-Knoten in einem oder
mehreren AAL-Räume miteinander zu verknüpfen und somit die Basis
für eine einheitliche AAL-Platform zu schaffen, wodurch die
Entwicklung komplexer und verteilter AAL-Applikationen ermöglicht
wird.
Dokumentation: http://forge.universaal.org/gf
http://forge.universaal.org/wiki/support:Reference_Documentation
Umfasst Architekturbeschreibungen, Anforderungsbeschreibung,
Design-Entscheidungen, Entwicklerhandbuch und Tutorials.
Bug tracking: Ja, sofern die Registrierung und Autorisierung als Entwickler
abgeschlossen ist. Die Bug-Tracking-Seiten befinden sich auf den
einzelnen Projekt-Seiten.
http://forge.universaal.org/gf/project
Anzahl der Downloads: Nicht bekannt
Lizenz Open Source Lizenz – Apache 2.0
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 36
6.5.1 Was ist universAAL?
Die universAAL-Middleware ist das Ergebnis eines EU-Forschungsprojektes, an der sich insgesamt
21 Hochschulen, außeruniversitäre Forschungseinrichtungen und Unternehmen aus zehn europäischen
Ländern sowie Israel und Taiwan beteiligt haben. Es handelt sich dabei um eine Middleware zur Ver-
netzung verschiedenster AAL-Knoten auf Basis einer serviceorientierten Architektur. Die AAL-
Knoten, die sich sowohl vom verwendeten Betriebssystem als auch von der Anbindung an das Netz
unterscheiden können, werden in zwei Kategorien unterteilt. Hauptknoten, auf denen der Middleware-
Footprint aufgespielt werden kann und Nebenknoten, auf denen keine Fremdsoftware ausgeführt wer-
den darf. Damit auch die Dienste der Nebenknoten dem Netz zur Verfügung gestellt werden können,
muss entweder ein entsprechender Adapter verwendet werden oder eine der Fertiglösungen von uni-
versAAL. Letzteres ist möglich, sofern die Knoten über einen Netzwerkstandard wie z. B. KNX,
IEEE-11073 über Bluetooth oder ZigBee (das Home Automation Profil von ZigBee ist vollständig
implementiert worden) angesprochen werden können. Das Living Lab von Fraunhofer IGD in Darm-
stadt unterstützt zusätzlich die FS20 und EnOcean Protokolle.
Die Middleware stellt drei Busse zur Verfügung über die Applikationen Informationen austauschen
und Dienste konsumieren bzw. bereitstellen können. Im Einzelnen sind das der Context-Bus, der UI-
Bus und der Service-Bus. Der Context-Bus ist ein eventbasierter Bus, der nach dem Prinzip des Pu-
blish/Subscribe-Musters arbeitet. Über den Context-Bus können sog. Kontextinformationen über den
Nutzer und seine Umwelt bezogen werden, wie z. B. in welchem Raum er sich gerade befindet.
Bei dem Service-Bus, wie dem UI-Bus, handelt es sich um einen aufruforientierten Bus, der nach dem
Prinzip des Request/Response-Musters arbeitet; d. h., auf die Anfrage nach einem Service folgt immer
eine Antwort. Damit Service-Provider und -Consumer miteinander kommunizieren können, bedarf es
einer gemeinsamen Schnittstelle. Typischerweise wird hierfür eine Methodensignatur verwendet, die
Auskunft darüber gibt, welche Parameter zu übergeben sind und was als Antwort zurückgeliefert wird.
universAAL geht allerdings einen anderen Weg und setzt auf sog. Service-Profile. Diese Profile be-
schreiben semantisch, welche Funktionalitäten ein Service zur Verfügung stellt. Technisch gesehen
wird dies durch einen RDF-Graphen realisiert, der auf eine oder mehrere bestimmte Ontologie(n) auf-
baut. Wenn ein Service-Consumer einen Dienst benötigt, formuliert er auf einer ähnlichen Art und
Weise seinen Wunsch bei der Middleware, die anschließend über Vergleich des Anfragegraphen mit
den registrierten Profilgraphen herausfindet, ob es in dem verteilten System einen entsprechenden
Service gibt. Falls ja, wird der passende Service von der Middleware in Anspruch genommen; das
Ergebnis dieser Operation wird von der Middleware als Response an die anfragende Komponente
geliefert. Ontologien und RDF-Graphen kommen auch bei dem Context-Bus zum Einsatz, um z. B.
nach bestimmten Events zu filtern.
Implementiert ist die universAAL-Middleware in Java auf Basis der OSGi Service Plattform, die es
ermöglicht, zur Laufzeit OSGi Komponenten, sog. Bundles, dynamisch hinzuzufügen, zu löschen oder
auszutauschen. Die Verwendung von OSGi erlaubt nicht nur die Entwicklung modularer Anwendun-
gen, sondern berücksichtigt auch die Dynamik von AAL-Installationen. Beispielsweise entspricht der
Ausfall oder die Installation eines neuen Sensors der Hinzu- bzw. Wegnahme eines OSGi-Bundles im
System. OSGi ist allerdings nicht für verteilte Anwendungen ausgelegt. Dennoch stellt dies mithilfe
der Middleware kein Problem dar, da sie von den physikalischen Gegebenheiten abstrahiert. Für Ap-
plikationen, die auf der Middleware aufsetzen, ist die physikalische Verteilung der AAL-Plattform
vollkommen transparent.
Über die Merkmale ihrer Middleware hinaus weist die gesamte universAAL Plattform zusammenfas-
send folgende wichtige Features auf:
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 37
Durch Vermeidung anwendungsspezifischer Maßgaben unterstützt universAAL den Betrieb von
beliebigen AAL Applikationen; somit wird universAAL der Diversität und Erweiterbarkeit der
AAL-Domäne gerecht.
Der Betrieb von Anwendungen wird auch administrativ unterstützt, um die Installation,
Aktualisierung und Konfiguration von Komponenten über das Internet zu ermöglichen.
Das Thema der Software-Plattform wird von universAAL holistisch angegangen, indem sie
zusätzlich zur Unterstützung des Betriebs von Anwendungen durch http://depot.universaal.org/
sowie http://ustore.universaal.org/ auch Tools für die Entwicklung und Vermarktung von
Lösungen bereitstellt.
universAAL unterstützt semantische Interoperabilität auf der höchsten Abstraktionsebene, so dass
unabhängig von dem Zweck die Einführung von neuen Abstraktionsebenen überflüssig wird.
Basierend auf semantische Interoperabilität bietet die universAAL Plattform mit ihren Reasoning-
und Service-Composition-Mechanismen Unterstützung für die Zusammensetzung von Daten bzw.
Funktionen zu höherwertigeren Daten bzw. Funktionen.
6.5.1.1 Konkrete Features
Die für diese Untersuchung relevanten Features von universAAL sind laut Dokumentation14
die Fol-
genden:
Ein allgemeines Design-Pattern für die Anbindung von beliebigen Geräten an die universAAL-
Middleware
Basierend auf das obige Design-Pattern, die Realisierung einer Reihe von Software-Modulen für
die Integration von KNX-, ZigBee- (Home Automation Profil), Bluetooth- (Continua-Geräte) und
FS20-Geräten.
Die Module für die Integration von EnOcean-Geräten so, wie sie in dem Living Lab des Fraunhofer
IGD verwendet werden, sind nicht veröffentlicht worden.
6.5.2 Installation und Einstieg
Nach der Installation der Eclipse-Version Indigo Service Release 2 (Eclipse Modeling Tools) und dem
hinzufügen der AAL-Tool namens AAL Studio über die Update-Site
http://depot.universaal.org/eclipse-update/ steht einem Entwickler die gesamte Funktionalität der
Middleware (siehe Abbildung 6) zur Verfügung.
Abbildung 6: Eclipse Plug-in der universAAL Studio Tools
Die AAL Studio Tools beinhalten folgende Funktionen zur Unterstützung des Lebenszyklus einer
AAL-Applikation (siehe auch Abbildung 7):
Project und Item Wizard: Der Project und Item Wizard unterstützt die Erstellung von
universAAL-Programmelementen wie Projekte mit allen Maven und OSGi Abhängigkeiten und
Klassen
14
http://forge.universaal.org/wiki/support:Reference_Documentation
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 38
Transformation: Das Transformations-Werkzeug generiert UML oder OWL basierte Dateien und
transformiert sie in universAAL Java-Code oder umgekehrt.
Build support: Dieses Werkzeug unterstützt den Build-Prozess einer universAAL-Applikation
Configuration: Unterstützung bei der Bestimmung von Variablen, die der Nutzer verändern
können soll
Conformance: Das Conformance-Tool unterstützt bei der Entwicklung valider und robuster
universAAL-Applikationen
Runtime support: Werkzeug zur Unterstützung der „Ausführung“ einer universAAL-
Applikation
Deployment: Veröffentlichung der Applikation auf einem der „universAAL App-Servern“
Abbildung 7: Funktionen der AAL Studio Workbench
Das universAAL-Dashboard (siehe Abbildung 8) zeigt den Lebenszyklus einer universAAL-
Entwicklung von der Erstellung eines Projektes bis hin zu deren Publikation.
Abbildung 8: universAAL Dashboard
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 39
6.5.3 Erweiterung der Software
Zur Einbindung von Sensorik und Aktorik bzw. spezifischer Protokolle zur externen Kommunikation
ist in universAAL eine 3-stufige Architektur vorgesehen. Die drei Schichten umfassen (1) Access, (2)
Abstraction und (3) Integration.
Die Access-Schicht bildet quasi den Treiber für die spezifische Technologie und realisiert somit die
grundlegende Integration der Technologie in die zugrunde liegende OSGi-Plattform. Die Abstraction-
Schicht überführt die Spezifika der jeweiligen Technologie in eine abstraktere, verallgemeinerte Ab-
bildung, die mit der generellen universAAL-Architektur kompatibel ist. Für diese Abstraction-Schicht
werden dazu unter anderem allgemeingültige APIs für OSGi definiert, die mit der universAAL-
internen Ontologie kompatibel sind.
Die dritte Schicht (Integrationsschicht) setzt auf die abstrakte Abbildung auf und bindet die abstrakten
Schnittstellen an die universAAL-Middleware an, um universAAL-konform auf die Daten und Funk-
tionen der Sensoren bzw. Aktoren zugreifen zu können. Die Abstraktionsschicht dient dazu, basierend
auf dieselben OSGi-spezifischen Schnittstellen und parallel zur Anbindung an universAAL, diese
Geräte auch in andere Netzwerke wie UPnP und Web Services einbinden zu können.
Werden die drei genannten Schichten auf dem gleichen physikalischen Gerät implementiert, dann ist
die Funktionsweise klassischen Gateways, die proprietäre Technologien mit IP-basierten Netzwerken
verbinden, sehr ähnlich.
6.5.4 Fazit
universAAL ist die Plattform mit dem umfassendsten Konzept und einer Referenzarchitektur, die die
Aspekte der Verteiltheit und Heterogenität adressiert. Darüber hinaus werden Dienste mittels einer
Ontologie beschrieben. Dieser semantische Ansatz bietet die Möglichkeit Diensteanfragen auf einer
abstrahierten Ebene zu stellen, anstatt konkrete Methoden aufzurufen. Damit ist universAAL die ein-
zige AAL-Middleware-Plattform, die semantische Technologien verwendet, um neue AAL-
Applikationen zu entwickeln.
Die Dokumentation zur Installation ist sehr ausführlich und gut verständlich beschrieben. Ein Bei-
spielszenario ist verfügbar, um die Fähigkeiten dieser Plattform zu vermitteln. Die Konzepte von uni-
versAAL sind in einer Referenzimplementierung umgesetzt. Für die Umsetzung einer AAL-
Applikation wird dem Entwickler eine sehr mächtige Plattform mitgegeben, die sich für komplexe
Anwendung mit unterschiedlichen Akteuren und Komponenten eignet.
Durch die Komplexität der Konzepte und die Verwendung semantischer Technologien kann die Ein-
arbeitungszeit etwas länger dauern. Genau das hat die von dem Untersuchungsteam reservierte Zeit für
universAAL aufgebracht. Aus diesem Grunde reichte die Zeit für die praktische Umsetzung des Use
Case nicht aus15
.
15
Ein weiterer Grund war die Tatsache, dass die universAAL-Plattform sich noch in der Entwicklung befindet
und es immer noch eine zeitliche Verzögerung gibt, bis die neuesten Entwicklungen in der Dokumentation re-
flektiert werden
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 40
6.6 openURC
Projektstatus
Name der Plattform openURC
URL http://www.openurc.org und http://www.openurc.org/TR/
Anwendungsdomäne
Entstehungskontext
Fernsteuerung / Controll Panel für Geräte und Dienste
Verfügbarkeit von
Ansprechpartnern
Verfügbarkeit der
Software
http://www.openurc.org/tools/ und http://www.openurc.org/tools/uch-trace-java-
3.0/
Entwicklung seit Unbekannt
Zeitpunkt des letzten
Updates
28.05.2013
Konkrete Einsatzorte
der Plattform
Fernsteuerung/Monitoring von Diensten, Informationen, Geräten, Sensoren und
Aktoren.
Dokumentation: http://sourceforge.net/projects/traceurcsdk/,
http://sourceforge.net/p/traceurcsdk/wiki/Home/ und http://www.openurc.org
Bug tracking: Nein
Anzahl der Downloads: Ca. 80 im Mai 2013
Lizenz Lizenzfrei
6.6.1 Was ist openURC?
Die Plattform openURC hatte länger keine Aktivitäten mehr zu verzeichnen. Dennoch wurde kurz vor
Ende der Evaluationsphase eine neue Version der Software herausgegeben, so dass openURC an die-
ser Stelle nur kurz dargestellt wird.
openURC ist insofern von großer Relevanz, als das es sich im Kern auf das Protokoll Universal Remo-
te Console (URC) stützt, welches seit 2008 als Standard ISO/IEC 24752 spezifiziert ist. Seit 2005
werden die Forschungs- und Entwicklungsarbeiten rund um die URC-Technologie bzw. ISO/IEC
24752 in der openURC-Alliance gebündelt. Die openURC-Alliance versteht sich dabei selbst als ein
Forum, in dem verschiedene Interessengruppen zusammenkommen, um Ideen und Ergebnisse im Be-
reich der Forschung, Entwicklung, Bildung, Zertifizierung und Normierung auszutauschen.
URC soll es dem Nutzer ermöglichen, Geräte und Dienste zu Nutzen bzw. Daten und Informationen
dieser Endpunkte darzustellen. Hierfür können für den Nutzer bzw. Nutzergruppen personalisierte
Controller erstellt werden. Der Begriff Controller umfasst sowohl einfache Bedienelemente wie Taster
und Schalter, aber auch komplexe Bedienelemente wie grafische Benutzeroberflächen auf Tablets,
Smartphones, TV-Geräten uvm. Die Bedienung mittels Sprache oder Gesten ist ebenfalls Bestandteil
des Gesamtkonzeptes. URC hat somit weniger den Anspruch eine vollständig autonome Intelligenz
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 41
der Geräte und Dienste bereitzustellen, sondern eher die Bedienung eines heterogenen Ensembles aus
Geräten und Diensten durch den Nutzer zu ermöglichen, bei der die Bedienungselemente auf die Gerä-
te, Dienste und ebenfalls auf den Nutzer angepasst werden können. Dadurch ist es möglich die Be-
dienkomponenten auch an Personen mit spezifischen Krankheitsbildern und/oder Einschränkungen
anzupassen, wodurch openURC auch im Kontext von AAL interessant ist.
Abbildung 9: Konzeptionelle Sicht einer URC Infrastruktur
Abbildung 9 zeigt eine konzeptionelle Sicht auf eine URC-basierte Infrastruktur. Die zu bedienenden
Geräte und Dienste werden als Targets bezeichnet. Diese Targets werden durch eine spezielle Adap-
tionsschicht (Target Adapter Layer) in eine abstraktere Form der Abbildung dieser Endpunkte und
deren Funktionen sowie Informationen überführt. Die Controller auf der anderen Seite werden eben-
falls mittels einer speziellen Adaptionsschicht (UI Protocol Layer) in eine allgemeingültige Abbildung
gebracht, um die diversen Eingabemöglichkeiten (Schalter, grafische Benutzeroberflächen, Gesten,
Sprache) in eine homogenisierte Darstellungsform zu überführen. Die eigentliche Verknüpfung zwi-
schen den Targets und den Controller findet mittels sogenannter Sockets statt. Ein Socket ist dabei
eine XML-Beschreibung des semantischen Modells der spezifischen Targets und umfasst Informatio-
nen wie Hersteller, Kommandos, Variablen usw., die durch die Controller angesprochen werden kön-
nen. Die genaue Struktur dieser XML-Dokumente ist Bestandteil des URC Standards ISO 24752.
Für Controller oder Targets, die nicht direkt mittels URC angesprochen werden können, wurden spe-
zielle Vermittler konzipiert. Diese Vermittler werden als Universal Control Hub (UCH) bezeichnet
und sind ebenfalls Bestandteil des URC Standards.
6.6.2 Erweiterung der Software
Neue Controller sowie Targets können durch die Bereitstellung entsprechender Komponenten für die
jeweilige Adaptionsschicht erfolgen. Einige solcher Komponenten werden als Vorlage im Rahmen der
openURC Alliance als Open Source zur Verfügung gestellt. Ein weiterer Bestandteil der Erweiterung
ist die Bereitstellung der Socket-Beschreibungen in Form eines XML-Dokumentes.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 42
6.6.3 Fazit
Die Technologie URC sowie die openURC Alliance als übergreifendes Konsortium zur Pflege und
Verbreitung dieser Technologie wirken auf den ersten Blick sehr ausgereift. Hierzu trägt nicht zuletzt
der Fakt bei, dass URC als bei der ISO/IEC standardisiert ist, sowie das eine entsprechende Referenz-
implementierung Open Source bereitgestellt wird. Dies ist ein enormer Vorteil gegenüber der Lösung
von openRemote, welches ein sehr ähnliches Einsatzszenario fokussiert.
Im Vergleich mit openRemote wirkt ebenfalls die konzeptionelle Grundstruktur von URC ausgereifter.
Hierzu tragen nicht zuletzt der modulare Aufbau und die flexible Erweiterbarkeit um sowohl
URC-kompatible als auch nicht URC-kompatible Targets und Controller bei. Im Rahmen der Evaluie-
rungen konnte die Implementierung von URC nicht weiter evaluiert werden und daher ist eine Bewer-
tung der Umsetzung des grundlegenden Konzeptes/Standards nicht möglich.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 43
6.7 ProSyst mBS Smart Home SDK
Projektstatus
Name der Plattform mBS Smart Home SDK
URL http://www.openurc.com
Anwendungsdomäne
Entstehungskontext
Smart Home, Smart Energy
Verfügbarkeit von
Ansprechpartnern
Über ProSyst Developer Zone
Verfügbarkeit der
Software
Kommerzielles Produkt, kostenlose Evaluationsversion möglich
Entwicklung seit Unbekannt
Zeitpunkt des letzten
Updates
aktuelle Version 7.3.0
Konkrete Einsatzorte
der Plattform
Zentrale Steuerungskomponente im Bereich Smart Home/Smart Energy,
Home Gateway Middleware
Dokumentation: http://dz.prosyst.com/pdoc/introduction_mbs_sh.html
Bug tracking: Nicht bekannt.
Anzahl der Downloads: Nicht bekannt.
Lizenz Kommerziell
6.7.1 Was ist mBS Smart Home?
Das mBS Smart Home SDK ist ein kommerzielles Produkt der Firma ProSyst. mBS zielt auf ein brei-
tes Spektrum von Anwendungen ab, da es als sogenannte Home Gateway Middleware konzipiert ist.
Als grundlegende Basis für mBS dient OSGi. Ein entsprechendes OSGi Framework wird von der Fir-
ma ProSyst ebenfalls vertrieben. Mit mBS wird dieses native OSGi um die Einbindung von Geräten
(Sensorik und Aktorik) erweitert. Als konkrete Technologien, die mittels mBS verfügbar sind, stehen
beispielsweise Z-Wave, ZigBee, EnOcean, UPnP, KNX, X10, HomeMatic, Web Cameras, Bluetooth,
wMBus, DECT und digitalSTROM zur Verfügung. Dies deckt bereits ein vergleichsweise breites
Spektrum ab. Die konkreten Technologien werden für mBS mittels einer integrierten Geräteabstrak-
tion für höhere Schichten bzw. auf mBS aufsetzende Anwendungen technologieunabhängig gekapselt.
Ein Vorteil von mBS gegenüber anderen Plattformen ist es, dass mBS bereits integrierte Remotezu-
griffs-Feature bietet. Ein solcher Zugriff kann mittels Java, JCA, JMS, Web Services (SOAP, REST)
oder JSON-RPC erfolgen und dient beispielsweise zum Remote Device Management sowie als Soft-
ware Provisioning System. Für das dafür nötige Backend stellt die Firma ProSyst ebenfalls eine Lö-
sung unter dem Begriff mPRM zur Verfügung. Einen Überblick über das Gesamtsystem ist in
Abbildung 10 dargestellt.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 44
Abbildung 10: Überblick ProSyst mBS Smart Home SDK
Zur Entwicklung von mBS-basierten Anwendungen wird das Smart Home SDK bereitgestellt. Dieses
beinhaltet auf Basis von Eclipse-Plugins diverse Entwicklungstools zur Entwicklung von OSGi/mBS
Bundles, Java Profiling und Runtime Validation.
6.7.2 Erweiterung der Software
Da mBS auf OSGi aufsetzt, können Erweiterungen der Plattform stets mittels OSGi Bundles erfolgen.
Die in OSGi integrierten Funktionen wie das Laufzeitmanagement und die Serviceverwaltung stehen
somit auch für Erweiterungen zur Verfügung.
Obgleich die Dokumentation zu mBS sowie den damit verbundenen Produkten, Komponenten und
Tools von ProSyst vergleichsweise ausführlich ist, wird aus diesen Informationen nicht klar, wie eige-
ne/weitere Protokolle bzw. Technologien zu mBS hinzugefügt werden können. Details über die ver-
wendete Geräteabstraktionsschicht sind daher nicht bekannt.
6.7.3 Fazit
Die Plattform mBS Smart Home hinterlässt einen sehr positiven Eindruck. Zum einen basiert mBS auf
OSGi und entspricht dabei eher einem „generellen“ Framework für Anwendungen, die nicht zwingend
auf eine spezielle Domäne beschränkt sind. Durch die Nutzung von OSGi sind daher Erweiterungen
und Anpassungen in Form von eigenen OSGi Bundles möglich. Mittels mBS werden die generellen
OSGi-Features um Funktionen zur Geräteanbindung erweitert, was die Plattform für den Einsatz im
Bereich AAL qualifiziert. Somit stellt mBS eine sehr gute Synthese aus genereller, domänenunabhän-
giger Plattform und konkretisierter, domänenspezifischer Plattform dar. Die Einbettung von mBS in
weitere Produkte von ProSyst, wie beispielsweise Entwicklungstools und –komponenten sowie für das
Remote Management, ist dabei besonders hervorzuheben.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 45
7 Diskussion
Die AAL-Domäne liegt aus Sicht der Anwendungen in einem thematischen Querfeld aus den Berei-
chen eHealth, Telemedizin, Unterhaltung, Social Media und Hausautomatisierung. Die AAL-
Anwendungen reichen von Komfortfunktionen aus dem Wellness-Bereich bis hin zu medizinischen
Applikationen, bei denen eine gesicherte Datenübertragung von Vitaldaten lebenswichtig sein kann.
Aus technischer Sicht adressiert AAL unterschiedliche Technologien aus dem Bereich der Robotik,
Integrationstechnik, Datenabstraktion, Fernwartung und Verteiltheit.
Da AAL verschiedene technische Anforderungen an die Anbindung heterogener Komponenten und
Kommunikation über Systemgrenzen hinaus stellt, adressieren viele der Plattformen Funktionen zur
Geräteabstraktion und Verteiltheit. Ohne Zweifel besteht hier die Komplexität und die Schwierigkeit
in der Definition einer offenen, erweiterbaren, allgemeingültigen und dennoch domänenspezifischen
Plattform.
Damit eine AAL-Plattform am Markt bestehen kann, sollte sie die Flexibilität besitzen z. B. einen
Herzschrittmacher genauso einzubinden wie einen FS20 Funkstecker. Somit müsste eine solche Platt-
form medizinische Qualitätsstandards genauso sicherstellen können, wie das Anzeigen und Steuern
von Heimautomatisierungskomponenten in einem Smart Home. Sie müsste die Raumtemperatur ge-
nauso messen und verarbeiten können, wie den Blutzucker eines Diabetespatienten. Ergebnisse einer
Fitnessanalyse müssten speicherbar sein und genauso an einen Arzt weitergeleitet werden können, wie
der Statusbericht der Haustechnik an den lokalen Handwerker. Neben den immensen Anforderungen,
die sich hieraus für die Interoperabilität ergeben, müssen vor allem im medizinischen Kontext auf-
wendige rechtliche Implikationen ebenfalls beachtet werden. Zusätzlich darf dieses Gesamtsystem
nicht nur für den Programmierer handhabbar sein, sondern muss auch für den Benutzer zugänglich
sein. Entsprechende Schnittstellen für die Kommunikation, wie GUIs und Audio müssen unterstützt
und einheitlich angesprochen werden können.
In unseren Tests standen sich Plattformen, die sehr konkrete Ansätze zur Anbindung bestimmter
Komponenten umsetzten mit Plattformen, die generische Konzepte zum Umgang mit Geräteabstrak-
tion anbieten, gegenüber. Hierbei zeigt sich ein Kernproblem bei der Umsetzung einer Plattform für
die Domäne AAL. Auf der einen Seite besteht die Möglichkeit eine Plattform eng angelehnt an vor-
handene Standards aufzubauen. Gezielt wird hier die Anbindung unterstützter Geräte aus z. B. dem
Bereich der Hausautomation, wie bei IP-Symcon, OpenHAB und OpenRemote, leicht gemacht und
vereinheitlicht. Spezialisierte GUIs erlauben hier selbst mit geringem Know-how bzw. ohne jegliche
Programmierkenntnisse Verknüpfungen oder sogar Programme zu erstellen. Medizinische Aspekte,
Analyse großer Datenmengen, selbstorganisierende, verteilte Netze oder einen semantischen Zugang
zum System unterstützt jedoch keine Hausautomations-Plattform. Auf der anderen Seite stehen vor
allem wissenschaftliche Ansätze wie universAAL oder openURC für einen ganzheitlichen Anspruch.
Die Ansätze aus der Forschung sind zukunftsweisend, dennoch besteht die Herausforderung darin eine
Weiterentwicklung der Software nach Projektende aufrechtzuerhalten.
D3.1.2-D3.1.3-D.3.2.2-D3.2.3 Bestandsaufnahme funktionale und semantische Plattformen
Copyright RAALI-Konsortium Seite 46
8 Zusammenfassung und Ausblick
Die betrachteten Plattformen geben ein sehr vielfältiges Bild über die Konzepte und Lösungsansätze
wieder. Durch die unterschiedlichen Herangehensweisen und Schwerpunkte ist es nicht möglich, die
AAL-Plattformen gegeneinander abzuwägen oder einen klaren Gewinner auszumachen. Ein Entwick-
ler ist gezwungen die Vor- und Nachteile der jeweiligen Plattformen zu analysieren, in Bezug auf die
gewünschten Funktionalitäten. Eine allumfassende Lösung ist derzeit nicht vorzufinden.
Wenn man viele Komponenten aus dem Bereich der Hausautomation anbinden möchte und bereit ist
Geld dafür auszugeben, dann sind entsprechend den Erfahrungen unserer Test IP-Symcon sowie mBS
eine sehr gute Wahl, weil beide momentan mit Abstand die meisten Protokolle unterstützen. Ähnliches
gilt für OpenRemote. OpenHAB als freie Software erfreut sich einer sehr aktiven Community, die sehr
viele neue Geräte für die Plattform implementiert. OpenHAB bringt darüber hinaus einen sehr ausge-
reiften Mechanismus zur Erweiterung und Anbindung neuer Geräte mit. Bei uMundo wurde die De-
moapplikation mit verschiedenen Java-Bibliotheken umgesetzt. Für kleinere und eher statische An-
wendungen kann man hiermit sicher schnell Erfolge erzielen. Fraglich ist die Skalierbarkeit dieses
Ansatzes, da durch die Komplexität der Anwendung die eingebundenen Bibliotheken mit anwachsen
können. Mit der universAAL-Plattform wird ein Konzept für ein AAL-Ökosystem aufgebaut. Dieser
Ansatz wird seine Stärken bei übergreifenden Systemen mit vielen Komponenten haben. Die Grund-
idee, der Komplexität und den Problemen der Interoperabilität mit semantischen Techniken auf Ebene
der Middleware zu begegnen, ist vielversprechend und man kann hoffen, dass universAAL es schafft,
eine bleibende Community auch nach der Projektlaufzeit zu erhalten, welche die Software weiter
pflegt. Die Idee, die volle Kette eines Softwarelebenszyklus vom Design (durch die Architektur), über
das Programmieren (mit Tools für Eclipse) bis zum Test und sogar Deployment beim Endkunden zu
unterstützen, ist in der Form momentan für den AAL-Markt einzigartig.
Aktuell ist die Anzahl an kommerziellen, privaten und wissenschaftlichen Lösungen sowie Standards
und Normen in der technischen Welt noch unüberschaubar groß, dass sich bisher nicht, wie bei den
Betriebssystemen (Posix, Windows, Android) eine kleine überschaubare Anzahl herausgebildet hat.
Für eine Firma, die eine AAL-Applikation aufsetzen möchte, bleibt die schwierige Entscheidung nach
einer geeigneten Plattform bestehen. Alle von uns getesteten Plattformen unterscheiden sich im Li-
zenzmodel, in der Wartbarkeit, im Anwendungsfokus (z. B. Hausautomation) und in den Konzepten
zum Umgang mit Erweiterbarkeit und Anbindung von Geräten. Keine der untersuchten Plattformen
unterstützen konkrete Protokolle und Technologien mit medizinischer Ausprägung. Schlagwörter wie
beispielsweise Bluetooth Health Device Profile, ZigBee Health Care, ISO 11073 oder HL7 finden sich
in keiner der Dokumentationen bzw. Produktbeschreibungen der jeweiligen Plattform. Solche Features
müssen durch Entwickler stets selbstständig hinzugefügt werden. Ausgehend von den vorangegange-
nen Diskussionen verbleibt somit die Frage, ob eine Plattform ohne jegliche Unterstützung von Tech-
nologien aus dem medizinischen Kontext überhaupt für den Bereich AAL geeignet ist.
Die Prozesse der Bestandsaufnahme wurden von verschiedenen Projektpartner zu unterschiedlichen
Zeiten umgesetzt. Die Erstellung der initialen Liste zu den AAL-Middleware-Plattformen wurde Ende
2012 finalisiert und die vertiefte Evaluation der verbleibenden Plattformen bis Mitte 2013. Wenn sich
innerhalb der Zeit zwischen Ende 2012 und Mitte 2013 neue Updates ergeben haben wurden diese bei
der Testung der verbleibenden Plattformen nicht beachtet.
Top Related