+ All Categories
Home > Documents > Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware-...

Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware-...

Date post: 26-Mar-2018
Category:
Upload: dangtruc
View: 221 times
Download: 2 times
Share this document with a friend
50
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
Transcript
Page 1: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 2: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 3: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 4: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 5: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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-

Page 6: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 7: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.)

Page 8: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 9: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 10: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 11: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 12: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 13: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 14: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 15: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 16: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 17: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 18: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 19: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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)

Page 20: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 21: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 22: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 23: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 24: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 25: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 26: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 27: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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)

Page 28: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 29: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 30: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 31: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 32: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 33: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 34: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 35: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 36: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 37: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 38: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 39: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 40: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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:

Page 41: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 42: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 43: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

Page 44: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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

[email protected]

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

Page 45: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 46: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 47: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 48: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 49: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.

Page 50: Bestandsaufnahme Middleware- Plattformen für · PDF fileBestandsaufnahme Middleware- Plattformen für AAL Roadmap AAL-Interoperabilität BMBF Förderkennzeichen: 16SV5562K Dokumentenreferenz:

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.


Recommended