IoT aus Sicht eines Service-Entwicklers Chancen und ... · Chancen und Herausforderungen systemübergreifender Interoperabilität Mathias Runge IoT connctd GmbH IoT aus Sicht eines

Chancen und Herausforderungen systemübergreifender Interoperabilität

Mathias Runge

IoT connctd GmbH

IoT aus Sicht eines Service-Entwicklers

VitaMathias Runge

Frankfurt am Main, 10. November 2017 –

Mathias Runge – IoT connctd GmbH Folie 2

§ Geboren 03.11.1979 in Berlin Mitte, wohnhaft in Berlin, verheiratet, 3 Kinder (16, 14, 4)

§ 2008: Studium der Informatik (TU– Berlin)

§ Schwerpunkte: Software Entwicklung, Künstliche Intelligenz, Kognitionswissenschaften

§ 2008 – 2012: Forschung TU-Berlin

§ Usability, Interaktion Smart Home

§ 2013-2014: Co-Founder & CTO DomoOne

§ Entwicklung Technologie-übergreifender Lösungen

§ 2014-2015: Entwickler yetu AG

§ Backend Schwerpunkt Abstraktion

§ Seit 2015: Co-Founder & Senior Entwickler IoT connctd GmbH

§ Schwerpunkt Abstraktion, Service Entwicklung



Die Idee



Kai - Uwe

Die Idee



Kai - Uwe

§ Kai-Uwe besitzt ein Babyfon, dass Geräusche auch auf sein Smartphone senden kann

Die Idee



Kai - Uwe

§ Kai-Uwe verfügt auch über eine Heim-Automation, die es ihm ermöglicht, das Licht über das Smartphone zu steuern

Die Idee



Entwickler Kai - Uwe

Die Idee




§ Kai-Uwe hat eine Idee: Beide Systeme sind über das Smartphone erreichbar, also kann

man sie einfach mit einander kombinieren.

Die Idee



Entwickler

Wenn Geräusche im Kinderzimmer,dann Licht im Wohnzimmer an!

Kai - Uwe

€

Die Idee



Entwickler

€Kai - Uwe

€

€ €>>

Die Idee




?§ Warum kostet die Umsetzung der Idee so viel mehr als gedacht?

Die Idee




Das ProblemAufwand

Das Problem



§ Unterschiedliche, nicht kompatible Technologien

§ Schnittstellen für 3rd-Party-Entwickler zugänglich?

§ heterogene Informationen in Datenstrukturen!

§ Lösung ist so individuell, dass sie nicht mehrfach

verkauft werden kann, dadurch können

Entwicklungskosten nicht aufgeteilt werden.

Die Lösung



Die Lösung



Entwickler

GeräteRäume Regel

Die Lösung



Geräte

Die Lösung



Geräte

TypFähigkeiten

Name...

Die Lösung



Geräte Räume

Die Lösung



Geräte Räume

Zuordnung

Die Lösung



Es wird ein Datenmodel benötigt, welches Geräte beschreibt und mit Räumen inRelation setzt.

Die Lösung



TypFähigkeiten

Name...

Model A

Die Lösung



TypFähigkeiten

Name...

TypFähigkeiten

Name...

Model A Model B

§ Modelle die im Grunde das Gleiche beschreiben müssen nicht zwangsläufig kompatibel

sein.

Die Lösung



Modelle beschreiben Informationen oft unterschiedlich. Daten können nicht ohne weitere Informationen von einem

Modell in ein anderes Modell überführt werden.

Es fehlt Semantik!

Semantik



type: Sensorvalue: 17,4valueType: temperature

class: TemperatureSensor

value: 17,4

unitOfMeasure: grad_celsius

Modell A Modell B

Semantik





value: 17,4

unitOfMeasure: grad_celsiusmapping

Modell A Modell B

Semantik

§ Ontologie:

§ Formale, explizite Spezifikation einer gemeinsamen Konzeptualisierung



Semantik



mapping



value: 17,4

SI - Ontologie

temperature

grad_celsius


Semantik



mapping



value: 17,4

Device - Ontologie

Sensor


Semantik



Middle Layer



value: 17,4


Gemeinsames Model

Ontologie

Semantik



Das Problem mit den Klassen

Typ und Fähigkeiten eines Gerätes sindoft im Klassennamen kodiert.

Semantik



TypFähigkeiten

Name...

class: Lamp

Semantik



TypFähigkeiten

Name...

class: Lamp

class: DimmableLamp

Semantik



TypFähigkeiten

Name...

class: Lamp

class: DimmableLamp

class: DimmableColorableLamp

Semantik



TypFähigkeiten

Name...

class: Lamp

class: DimmableLamp


class: SpecialFeatureDimmableLamp

Semantik



TypFähigkeiten

Name...

class: Lamp

class: DimmableLamp



Semantik



class: Lamp

class: DimmableLamp



Wird keine Ontologie verwendet,So muss ein Entwickler alle KlassenKennen, um Geräte vom Typ Lampenidentifizieren zu können

Semantik



class: Lamp

class: DimmableLamp



KLASSENHÖLLE!Bitte vermeiden!

Semantik



class: Lamp Es ist eine Lampe, und man kannsie einschalten und dimmen.

capabilitiy: Switch

capabilitiy: Dimm

Typ

Semantik



class: Lamp Es ist eine Lampe, und man kannsie einschalten und dimmen.

capabilitiy: Switch

capabilitiy: Dimm

Fähigkeiten

Semantik



class: Lamp

capabilitiy: Switch

capabilitiy: Dimm

class: Socket

capabilitiy: Switch!

Device - Ontologie

Lamp Socket

Aktion - Ontologie

Switch Dimm

Nützliche Links

§ Web Of Things

§ https://www.w3.org/WoT/IG/

§ Vorto

§ https://www.eclipse.org/vorto/

§ IoT connctd GmbH

§ http://www.connctd.com



Fazit

§ Was müssen Gerätehersteller tun, damit die Entwicklung von

Technologie-übergreifenden Services/Apps einfacher, generischer

und somit günstiger werden?

§ Schnittstelle für 3rd-Party-Entwickler

§ Gerätebeschreibung (Model)

§ Ideal:

§ Nutzung von Ontologien

§ Aufteilung der Geräte in Typ und Fähigkeiten (Vermeidung „Klassenhölle“)



Fazit

§ IoT Dienste können auch unabhängig der darunter liegenden Technik entwickelt

werden. Bei der Umsetzung wird geschaut, ob vorhandene Infrastruktur genutzt werden

kann.

§ Kundennutzen und Preis einer Lösung sind proportional zueinander -> Dienste mit

geringem Kundennutzen dürfen nicht viel kosten.

§ Verwendung von vorhandener Infrastruktur zur Umsetzung des Dienstes muss

günstiger sein, als der Einsatz zusätzlicher proprietärer Geräte.



Documents

IoT aus Sicht eines Service-Entwicklers Chancen und ... · Chancen und Herausforderungen systemübergreifender Interoperabilität Mathias Runge IoT connctd GmbH IoT aus Sicht eines