#5 Interoperabilität: UPnP, DLNA, URC 02.06.2014 Dr.-Ing. Christoph Stahl
Übersicht Interoperabilität von AAL Services Digital Living Network Alliance (DLNA) Universal Plug and Play (UPnP) Architektur Beispiele Cling Framework Universal Remote Console (URC)
Interoperabilität AAL Services
Interoperabilität von AAL Services Def.: Interoperabilität Die Fähigkeit eines Systems, Services zu unterstützen bzw. Services von anderen Systemen zu akzeptieren und effektiv zu nutzen [DIN CEN ISO/TS 14907-1:2011-08] Vorbedingung: Konformität mit Standards Quelle: VDE Verlag
Assistenzfunktionen Typische Assistenzfunktionen von AAL Systemen sind Erinnerungsfunktionen z. B. zur Einnahme und Bestellung von Medikamenten Aufforderung zum Handeln z. B. Durchführung eines Bewegungsprogrammes Training kognitiver Fähigkeiten und geistigen Kapazität Wahrnehmen (Sinnesorgane), Lernen (Langzeitgedächtnis), Erinnern, Motivation, Konzentration Ambientes Verhaltensmonitoring. Sammlung von Sensordaten, die auf Abweichungen vom Normalzustand untersucht werden. Unterstützung der Fortbewegung zu Hause und draußen
Motivation für Interoperabilität Derzeit müssen Geräte für AAL von Fachleuten geplant und installiert werden. Gebäudeinfrastruktur, Gebäudeautomation, Sensorik/Aktorik Ziel: Anwender kaufen neue Komponenten selbst und integrieren diese in ein bestehendes System. Geräte sollten im (Lampen-, Möbel-, Sanitär-, Medizin-...) Fachhandel oder Elektronhandel angeboten werden. Mit einer minimalen Schulung der Verkäufer könnten diese auch bei Bedarf die Konfiguration übernehmen.
Motivation für Interoperabilität Anforderungen an AAL Systeme aus Nutzersicht Kombinierbarkeit von Produkten verschiedener Hersteller Übernahme von Konfigurationseinstellungen bei Austausch oder Neuinstallation ähnlicher Geräte Viele Geräte werden nur gemietet (z.b. Router) und bei Anbieterwechsel getauscht Bei Umzug neue Infrastruktur der Gebäudeautomation BACnet, KNX, LON, ZigBee, Z-Wave, EnOcean,..» Abstraktionsebene von Bussystemen notwendig für Dienste
Motivation für Interoperabilität Anforderungen aus technischer Sicht Hohes Maß an Interdisziplinarität (Elektro, Heizung, Medizin) Erfassung der Eingangsdaten mit Sensoren Sensoren sollten allen Assistenzdiensten zur Verfügung stehen, keine mehrfache Anschaffung. Identifikation von Anwender und Aufenthaltsort zur Anpassung an die individuellen Vorlieben, Fähigkeiten und Einschränkungen des Nutzers. z.b. Anpassung von Audioausgaben an die Hörfähigkeit Benutzerprofile zwischen Anwendungen teilen Semantische Beschreibung von Kontextinformationen Ich brauche mehr Licht statt Mach Licht über der Küchenspüle : tieferes Wissen über den Kontext notwendig
Aktuell fehlen Standards Kommunikation zwischen AAL-Systemen und IT-Systemen des Gesundheitswesens. Fernwartung von AAL-Systemen und Komponenten. Abstrakte Softwareschnittstellen zur Ansteuerung der Gebäudeautomation. Anbindung von AAL-Systemen an Hausnotrufdienste. Sprachen zur Beschreibung von Kontextinformationen für AAL. Standard-Ausführungsumgebung für AAL-Dienste. Planungssysteme für AAL.
Ebenen der Interoperabilität Vier Ebenen der Interoperabilität [ETSI Technical Report ETR 130] Protokoll-Interoperabilität ist die Fähigkeit eines verteilten Systems, Protokolldateneinheiten (Datenpakete) über das zugrundeliegende Kommunikationssystem auszutauschen. Dienst-Interoperabilität ist die Fähigkeit eines verteilten Systems, eine Untermenge eines verteilten Dienstes gemäß einer funktionalen Spezifikation anzubieten. Anwendungs-Interoperabilität (auch semantische Interoperabilität genannt) ist die Fähigkeit eines verteilten Systems, eine konsistente Implementierung der Syntax und Semantik der ausgetauschten Daten zu gewährleisten. Interoperabilität aus Anwendersicht ist gegeben, wenn der Anwender mittels des verteilten Systems Informationen austauschen kann.
Semantische Interoperabilität Ein vielversprechender Weg zur Realisierung von AAL Systemen sind Integrationsassistenten auf der Basis von semantischen Metamodellen. Sie unterstützen nicht nur bei der Planung und Durchführung der Erstinstallation, sondern auch bei späterer Ergänzung sowie über Konfigurationsdialoge bei der Anpassung an die vorhandenen Geräte und räumlichen Gegebenheiten Sie generieren selbsttätig ggf. notwendige Transformationen der Datenformate und Schnittstellen zur Anpassung an unterschiedliche Standards, um die Interoperabilität auch über einen längeren Zeitraum zu gewährleisten. Für die Modellierung kommen vor allem Terminologie- Hierarchien mit Querbeziehungen und logischer Formalisierung sowie Prozessmodelle in Frage.
Interoperabilität Digital Living Network Alliance (DLNA)
Anwendungsbeispiel Buffalo NAS 2TB 24.000 Fotos 3800 mp3 s 300 Videos LG Smart TV
Anwendungsbeispiel Buffalo NAS 2TB 24.000 Fotos 3800 mp3 s 300 Videos LG Smart TV ipad mit Twonky Beam App
Browse SetAVTransportURI Anwendungsbeispiel Transcoding STREAM
DLNA Digital Living Network Alliance DLNA Interoperability Guidelines seit 2003. Basiert auf Universal Plug and Play (UPnP) Zahlreiche Mitglieder der Unterhaltungselektronik Microsoft, Sony, Samsung, LG,.. Zertifizierung von Produkten gemäß DLNA Profilen Compliance Test Tools Anwendungsbeispiele Medien von mobilen Geräten auf TV abspielen Medien von Servern auf HiFi Geräten abspielen Fotos von mobilen Geräten Drucken
DLNA Profile Digital Media Server (DMS): These devices store content and make it available to networked digital media players (DMP) and digital media renderers (DMR). Some digital media servers can also help protect your content once stored. Examples: PCs and network attached storage (NAS) devices. Digital Media Player (DMP): These devices find content on digital media servers (DMS) and provide playback and rendering capabilities. Examples: TVs, stereos and home theaters, wireless monitors and game consoles. Digital Media Renderer (DMR): These devices play content received from a digital media controller (DMC), which will find content from a digital media server (DMS). Examples: TVs, audio/video receivers, video displays and remote speakers for music. Digital Media Controller (DMC): These devices find content on digital media servers (DMS) and play it on digital media renderers (DMR). Examples: Internet tablets, Wi- Fi enabled digital cameras and personal digital assistants (PDA).
Interoperabilität Universal Plug and Play (UPnP)
UPnP Ursprünglich von Microsoft entwickelt. Inzwischen entwickelt das UPnP-Forum den Standard weiter und führt die Zertifizierung UPnP-konformer Geräte durch. UPnP verwendet IP-Kommunikation Ethernet, WLAN, 3G, Bluetooth.. UPnP-Geräte können sich selbstständig miteinander verbinden, sich voneinander trennen und auf Ereignisse reagieren. Diese Möglichkeit kann genutzt werden, um bspw. Ports an einem Router zu öffnen, oder eine Mediensammlung auf einem Network Attached Storage (NAS) zu durchsuchen und wiederzugeben.
UPnP Architektur Discovery SDDP Message Format Advertisement Search Device and Service Description Actions, State Variables Control Remote Procedure Calls mit SOAP Eventing Multicast Events Presentation
Discovery Jedes Gerät bekommt seine IP-Adresse im Netz entweder durch einen DHCP Dienst zugeteilt oder sucht sich selbst eine freie Adresse (Auto-ID Verfahren) Geräte in mehreren Netze nennt man multi-homed Hat ein Gerät seine IP-Adresse bekommen, informiert es alle anderen Geräte über seine IP-Adresse, UUID und Dienste. Geräte melden sich ab, wenn sie vom Netz gehen Ein ControlPoint kann aktiv nach bestimmten Geräten oder Diensten suchen Alle passenden Geräte antworten darauf
Discovery SSDP (Simple Service Discovery Protocol) Basiert auf HTTP Header, aber UDP statt TCP Multicast IP-Adresse 239.255.255.250:1900 NOTIFY informiert über ein verfügbares Gerät und seine Dienste M-SEARCH Sucht nach Geräten oder bestimmten Diensten
Description Discovery liefert Adresse und Typ eines Geräts Zur Kommunikation ist eine Beschreibung der Verfügbaren Methoden und Argumente notwendig Notification enthält URL zur Description
Description UPnP Geräte beschreiben sich selbst Geräte Beschreibung Hersteller, Modellbezeichnung, Seriennummer» Darin enthaltene logische Geräte Presentation (Webseite des Geräts) Service Beschreibung Typ, Name URL mit Beschreibung URL zur Ansteuerung URL für Events
Description UPnP Device Schema (XML) UPnP Device Template (Standardisiert vom UPnP Forum) UPnP Device Description (spezifisches Produkt) UPnP Service Schema (XML) UPnP Service Template UPnP Service Description Templates gibt es bei http://www.upnp.org/ Hersteller können Standard-Templates um eigene Funktionen ergänzen
Description: Actions und State Variables Actions haben Name Liste von Argumenten State Variables Name Entweder IN oder OUT Verweis auf zugehörige State Variable Name Können optional bei Änderung Events senden Datentyp String, char, int, float, date, datetime, boolean Liste erlaubter Werte bzw. Wertebereich min/max
Description Beispiel Device Description MediaRenderer1.xml eines LG TVs
Description Beispiel Service Description AVTransport1.xml eines LG TV Actions
Description Beispiel Service Description AVTransport1.xml eines LG TV State Variables
Control Architektur zur Steuerung von UPnP Geräten
Control Control is Step 3 in UPnP networking Given knowledge of a device and its services, a control point can ask those services to invoke actions and receive responses indicating the result of the action. remote procedure call; a control point sends the action to the device's service, and when the action has completed (or failed), the service returns any results or errors. To control a device, a control point invokes an action on the device's service. To do this, a control point sends a suitable control message to the fully qualified control URL In response, the service returns any results or errors from the action. The effects of the action, if any, MAY also be modeled by changes in the variables that describe the runtime state of the service. When these state variables change, events are published to all interested control
Control: Actions Aufruf einer Aktion Simple Object Access Protocol (SOAP) definiert die Verwendung von XML und HTTP für Remote Procedure Calls. UPnP 1.1 nutzt HTTP POST um SOAP 1.1-codierte Nachrichten an Geräte zu senden und Ergebnisse oder Fehler zu Empfangen. Von XML reservierte Zeichen in Argumenten MÜSSEN durch ihre HTML-Bezeichnungen ersetzt werden & = & < = < etc..
Control: Actions SOAP Action Invocation Schema
Control: Actions SOAP Action Response Schema
Control: Beispiel Beschreibung laut UPnP Service Template
Control: Beispiel ControlPoint ruft Aktion GetPositionInfo bei TV auf <SOAP-ENV:Envelope xmlns:soap- ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:getpositioninfo xmlns:m="urn:schemas-upnporg:service:avtransport:1">» <InstanceID xmlns:dt="urn:schemas-microsoftcom:datatypes" dt:dt="ui4">0</instanceid> </m:getpositioninfo> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Control: Beispiel TV antwortet an ControlPoint <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"> <s:body> </s:body> </s:envelope> <u:getpositioninforesponse xmlns:u="urn:schemas-upnporg:service:avtransport:1">» <Track>0</Track>» <TrackDuration>00:00:00</TrackDuration>» <TrackMetaData></TrackMetaData>» <TrackURI></TrackURI>» <RelTime>00:00:00</RelTime>» <AbsTime>NOT_IMPLEMENTED</AbsTime>» <RelCount>2147483647</RelCount>» <AbsCount>2147483647</AbsCount> </u:getpositioninforesponse>
Eventing ControlPoints können sich für Events registrieren, um über alle Änderungen von Zustandsvariablen sofort informiert zu werden. Multicast Events gehen an ALLE Geräte im Netzwerk
Eventing
Presentation UPnP Geräte können eine Web-basierte Benutzerschnittstelle implementieren z.b. zur Konfiguration mittels Browser
CLING UPnP Tools CLING ist eine Java Bibliothek, welche die UPnP Device Architecture 1.0 implementiert http://4thline.org/projects/cling/ Cling Core ermöglicht die Implementierung von UPnP Services UPnP Control Points, die Geräte erkennen und nutzen Funktionsaufrufe sind stets Asynchron Callback-Mechanismus Geräte melden sich teils mit 10-20 sec. Verzögerung Ergebnisse kommen nicht unbedingt in der Reihenfolge der Funktionsaufrufe! Umgebung ist hoch dynamisch, je nach aktiven Geräten
CLING Core Fazit Bedeutung der Argumente bleibt teilweise unklar Metadaten zu Medien sind umfangreich Semantik geht nicht aus UPnP Spezifikation hervor Samsung benötigt keine Metadaten, aber LG unbedingt Reihenfolge der Aktionen nicht hinreichend spezifiziert Nachsehen was ControlPoints so machen» Wireshark erlaubt Analyse von IP Kommunikation (HTTP, SSDP,..)» Reverse engineering
Wireshark
Beispiel Interaktion WMP - TV GetTransportInfo <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"><s:body> <u:gettransportinforesponse xmlns:u="urn:schemas-upnporg:service:avtransport:1"> <CurrentTransportState>STOPPED</CurrentTransportState> <CurrentTransportStatus>OK</CurrentTransportStatus> <CurrentSpeed>1</CurrentSpeed> </u:gettransportinforesponse> </s:body> </s:envelope>
Beispiel Interaktion WMP - TV GetCurrentTransportActions <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"><s:body> <u:getcurrenttransportactionsresponse xmlns:u="urn:schemas-upnporg:service:avtransport:1"> <Actions>Play,Stop,Pause,Seek,X_DLNA_SeekTime</Actions> </u:getcurrenttransportactionsresponse> </s:body> </s:envelope>
Beispiel Interaktion WMP - TV GetMediaInfo <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"><s:body> <u:getmediainforesponse xmlns:u="urn:schemas-upnp-org:service:avtransport:1"> <NrTracks>1</NrTracks> <MediaDuration>0:04:31.177</MediaDuration> <CurrentURI>http://192.168.2.238:10246/MDEServer/E7AA9C55-A080-47D4-A10A- 04C5E8201880/1000.mp3?formatID=00000008-A9AF-4584-84E2-55BFEF0A7D7E</CurrentURI> <CurrentURIMetaData><DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"; <NextURI>NOT_IMPLEMENTED</NextURI> <NextURIMetaData>NOT_IMPLEMENTED</NextURIMetaData> <PlayMedium>NETWORK</PlayMedium> <RecordMedium>NOT_IMPLEMENTED</RecordMedium> <WriteStatus>NOT_IMPLEMENTED</WriteStatus> </u:getmediainforesponse> </s:body> </s:envelope>
Beispiel Interaktion WMP - TV Play <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"><s:body> <u:playresponse xmlns:u="urn:schemas-upnporg:service:avtransport:1"></u:playresponse> Notification <e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0"> <e:property> <LastChange><Event xmlns="urn:schemas-upnp-org:metadata-1-0/avt/"><instanceid val="0"><transportstate val="playing"/></instanceid></event></lastchange> </e:property> </e:propertyset>
Interoperabilität Universal Remote Console (URC)
URC Grundlagen Ziel von Universal Remote Console sind Benutzerschnittstellen, die den individuellen Bedürfnissen der Nutzer entsprechen und geeignete Modalitäten zur Interaktion (z.b. Sprache) bieten. Trennung von Geräten, Diensten und Oberflächen Targets sind Geräte und Dienste Controller und Benutzerschnittstellen sind Universal Remote Consoles" (URCs). Das URC Framework [ISO/IEC 24752] spezifiziert nicht die Kommunikation zwischen URC und Target. Ein Zentraler Hub kann über Target-Adapter mit verschiedenen Protokollen umgehen. [ http://myurc.org/tr/urc-tech-primer/ ]
Universal Remote Console Resource Server A Resource Server B UCH (Universal Control Hub) URC/HTTP DLNA SVG Enocean ODP UPnP WSDL Assistance System other plugin KNX Controller UI Protocol Layer Socket Layer Target Adapter Layer Targets Internationaler Standard nach IEC/ISO 24752
Socket-Beschreibung Ein Target Gerät muss seine Funktionen als Sockets beschreiben: Variablen repräsentieren den Zustand eines Targets; sie können als read-only oder auch Konstantwert definiert werden Commands repräsentieren die Funktionen eines Targets, die von einem Client aufgerufen werden können. Optional mit Parametern Notifications benachrichtigen den Nutzer über Zustandsänderungen welche Aufmerksamkeit erfordern (info, alert, error) Die Socket-Beschreibung sagt nichts über die Darstellung der Nutzerschnittstelle aus.
Beispiel einer Socket-Beschreibung <uisocket about="http://example.com/thermometer/socket" id="socket > <constant id="modelnumber" type="xsd:double"> 570 <dependency> <relevant>false()</relevant> </dependency> </constant> <variable id="temperature" type="xsd:double"> <dependency> <write>false()</write> </dependency> </variable> <variable id="maximum" type="xsd:double"> <dependency> <write>false()</write> </dependency> </variable> Eine konstante Modellbezeichnung Die Modellbezeichnung ist nicht relevant für den Nutzer Variable repräsentiert Temperatur als readonly Wert doppelter Genauigkeit (double)
Beispiel einer Socket-Beschreibung <notify id="checkreset" category="alert"> <dependency> <explicitack> false() </explicitack> <acknowledge> (uis:hasdefinedvalue('confirmreset') and uis:value('confirmreset') eq 'done') or (uis:hasdefinedvalue('cancelreset') and uis:value('cancelreset') eq 'done') </acknowledge> </dependency> </notify> Benachrichtigung mit Anfrage zur Bestätigung des Resets, bzw. Abbruch der Ausführung Methode zum Rücksetzen von Min/Max Temp. Ausführung nur nach Bestätigung <command id="reset"/> <command id="confirmreset" type="uis:basiccommand"> <dependency> <relevant>uis:hasdefinedvalue('checkreset') and uis:value('checkreset') eq 'active' </relevant> <write>uis:hasdefinedvalue('checkreset') and uis:value('checkreset') eq 'active'</write> </dependency> </command>
Pluggable User Interfaces (PUI) Konkrete Nutzerschnittstellen (PUIs) verbinden sich mit abstrakten Sockets ( Binding" bzw. Grounding ). PUI verbinden sich bidirektional mit Targets: Lesen von Zustandsvariablen des Targets Zustandsänderung des Targets durch Aufruf von Methoden PUIs können realisiert werden durch Beliebige Plattformen, z.b. Android, ios, HTML5, Java (Swing), Flash, Silverlight.. Beliebige Modalitäten, z.b. Grafik, Sprache, Touch, Gestik..
Lokalisierung mittels Resource Sheets Die Nutzerschnittstelle soll leicht an sog. Locale (spezifische geographische Region und Kultur) angepasst werden können. URC speichert dazu alle Bezeichnungen und Icons in externen Resource Sheets unabhängig von den funktionalen Socket Beschreibungen Es kann für jede Region (z.b. USA, GB, Deutschland) ein eigenes Resource Sheet hinterlegt werden. Erlaubt sind text, image, video, oder jedes andere digitale Medium mit bekanntem MIME Typ.
OSGi Ein UCH wurde u.a. vom DFKI auf Basis von OSGi Implementiert Open Service Gateway Initiative (OSGi) Ein hardwareunabhängiger Middleware-Standard für die Verwaltung und Verteilung von Diensten, 1999 von der OSGi Alliance entwickelt. Entsprechende Middleware-Frameworks werden als OSGi-Plattform bezeichnet und sind kommerziell, aber auch als Open Source Freeware verfügbar. Basis ist eine Java Virtual Maschine (JVM) Ermöglicht Updates von Paketen im laufenden Betrieb, ohne den Server neu zu starten» wichtig für Home-Server» Ähnlich Linux runlevel Konzept» Konfiguration braucht etwas Erfahrung über Java hinaus
URC im BAALL
Vergleich UPnP / URC Beide trennen Geräte, Dienste und User Interface Beide beschreiben Dienste mittels XML Aktionen, Variablen und Events URC geht bei GUI mehr ins Detail Multilinguale Bezeichnungen für Kommandos Beiden FEHLT semantische Ebene In welcher Reihenfolge müssen/dürfen Aktionen erfolgen? Was macht eine Aktion genau? Geht nur für menschlichen Leser aus dem Standard hervor (wenn überhaupt)! Beide basieren auf Remote Procedure Calls UPnP spezifiziert exakt die Protokolle UPnP unterstützt gezielt Discovery Phase URC überlässt diese Ebene dem Entwickler
Übungsaufgabe Zur Vorbereitung auf die nächste Übung am Mi.: Mit Cling Core vertraut machen Mit UPnP Service Templates vertraut machen Rendering Control Content Directory AV Transport
Literatur Leitfaden interoperable Assistenzsysteme - vom Szenario zur Anforderung Arbeitsgruppe. Teil 2 der Reihe Interoperabilität von AAL-Systemkomponenten, VDE Verlag, 2013. UPnP Forum Device Architecture 1.1, 2008 www.upnp.org Cling Core Manual, 2014 http://4thline.org/projects/cling/core/manual/ URC Technical Primer 1.0, 2008 http://myurc.org/tr/urc-tech-primer/