Sensornetze:
Die Sprache für das "Internet der Dinge"
Fortsetzung des Artikels von Teil 1
Was tun auf der Anwendungsschicht?
Eine weitere Herausforderung stellt sich mit der Auswahl des richtigen Protokolls auf der Anwendungsschicht. Hier wäre natürlich das http-Protokoll ideal, weil es mit den Webbrowsern weit verbreitet ist. Allerdings ist der Aufwand auf der Serverseite zur Analyse von http recht groß, weil die in ASCII codierten Befehle zerlegt werden müssen. Deswegen erscheint eine Implementierung auch nur auf leistungsfähigeren Knoten (Cortex-M3 oder aufwärts) sinnvoll. Aus diesem Grund wurde im vergangenen Jahr in RFC 7252 von der IETF das Constrained Application Protocol (CoAP) definiert, das in Bezug auf das Request-Response-Paradigma an http angelehnt ist. Im Unterschied zu http wird bei CoAP aber ein codierter Methodenaufruf auf einen Uniform Resource Identifier (URI) verwendet, der eine Zuordnung im Server zulässt.
Die CoAP-Spezifikation wurde von der Constrained RESTful environments (CoRE) Working Group erarbeitet. Wie der Name dieser Gruppe schon signalisiert, war ein Kerngedanke die Organisation durch RESTful Services, also durch Dienste, die der Representational state transfer (REST)-Abstraktion folgen. Darüber hi-naus werden auch Multicast-Dienste unterstützt, was für viele reale Anwendungen praktische Vorteile bringt. Auch werden grundsätzliche Möglichkeiten zur Diensteerkennung (Resource Discovery) und zur Beobachtung (Observing Resources) von Ressourcen unterstützt.
Für den Zugriff auf einen CoAP-Server existieren die drei in Bild 1 gezeigten Architekturen:
- Der Zugriff kann unmittelbar von einem CoAP-Client erfolgen, von denen es mittlerweile bereits viele Implementierungen gibt.
- Allerdings ist die Verfügbarkeit von http-Clients (Webbrowsern) deutlich größer, so dass es wegen der Verwandtschaft der beiden Protokolle mittlerweile auch verschiedene CoAP-Plugins für Webbrowser (Bild 2) gibt. Hier sei insbesondere das Copper-Plugin für Firefox genannt.
- Als dritte Option besteht noch die Möglichkeit, die http-Anfragen über einen so genannten http-CoAP-Proxy übersetzen zu lassen. Allerdings ist man dann nicht mehr weit von dem oben erwähnten Gateway-Ansatz entfernt, den man eigentlich durch die Einführung von 6LoWPAN vermeiden will. Der Vorteil der semantischen und syntaktischen Verwandtschaft von CoAP und http ist jedoch auch bei dieser Architektur nicht zu unterschätzen. Der Ablauf einer CoAP-Anfrage ist in Bild 3 gezeigt.
Allerdings wird zunehmend deutlich, dass die CoAP-Spezifikation allein immer noch nicht ausreichend ist, um herstellerübergreifend interoperable Produkte bereitzustellen. Der Grund: CoAP definiert nur die Struktur der Anfrage, nicht die Codierung selbst. Entsprechend müssen nun auch noch die Datenmodelle, die Profile, spezifiziert werden, um diese semantische Eindeutigkeit zu bieten. Zum Erreichen dieser Eindeutigkeit befindet sich die Branche gegenwärtig in einem lebhaften Diskussionsprozess, wobei verschiedene, teilweise konkurrierende Ansätze am Start stehen. Diese sind zwar logisch gesehen unabhängig von 6LoWPAN, werden aber eigentlich nur in diesem Zusammenhang gesehen und vorangetrieben:
- Natürlich gibt es die proprietären und herstellerspezifischen Modelle, bei denen sowohl Client als auch Server die jeweiligen Zuordnungen a-priori kennen müssen.
- Eine zweite Entwicklungsrichtung überlegt, wie bereits bestehende Anwendungsprofile aus anderen Protokollfamilien mit Hilfe von CoAP abgebildet werden können, um auf vorhandenem Anwendungs-Know-how aufzubauen. Dies ist insbesondere bei allen Profilen, die auf so genannten Key-Value-Pairs (KVP) aufbauen, unmittelbar möglich. Insbesondere sei die Möglichkeit genannt, z.B. die ZigBee-Profile unmittelbar und effizient auf die CoAP-Struktur zu übertragen. Aber auch hierbei müssen diese Profile schon vor der Inbetriebnahme bekannt sein.
- Entsprechend präsentieren sich die Ansätze z.B. der ETSI M2M, die die Verfügbarkeit und die Beschreibung von Funktionen durch einen RESTful Service Capability Layer (SCL) abbildet und so die autonome Inbetriebnahme und Konfiguration der Geräte übernimmt. Auch muss die Flexibilität typischerweise mit einer recht hohen Implementierungskomplexität erkauft werden.
-
Die ETSI-M2M-Gruppe folgt aber auch dem Ansatz, weitere eigene Profile zu definieren. Hierbei steht sie in einer gewissen Konkurrenz mit der Open Mobile Alliance (OMA), die vor allem aus der Sicht der Mobilen Geräte (Smartphones etc.) und der damit verbundenen Betriebssysteme und Entwicklungsumgebungen sowie der Bereitstellung von backend-basierten Serversystemen denkt. Diese definiert z.B. den Lightweight M2M-(LWM2M)-Stack, der die Managementebene beschreibt. Parallel dazu hat die IPSO-Alliance die Ver-sion 1.0 ihrer Objektbeschreibungen publiziert. Sowohl LWM2M als auch IPSO verwenden dieselbe Funktionsstruktur; beide Definitionen können direkt auf CoAP aufgesetzt werden.
-
Schließlich existieren auch verschiedene integrative Ansätze, die unmittelbar versuchen, eine Metaebene zu definieren, die die wichtigsten Strukturen der Implementierungsmöglichkeiten der Profile abbilden kann.
- Die Sprache für das "Internet der Dinge"
- Was tun auf der Anwendungsschicht?
- Kommissionierung/Management
