SENSE IOT NETINAR - SENSE-PROJEKT
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
SENSE IoT
Netinar
Vorgetragen von
Sebastian Garn (IoT connctd GmbH)
16.07.2020
Ziel des Netinars
- Überblick über die Zwischenergebnisse (ca. Projekt-Halbzeit) aus dem Forschungsprojekt Sense mit
Fokus auf Semantik und Abstraktion
- Zu SENSE:
- Semantisches, Interoperables Smart Home
- Projektpartner:
- ZVEI: Forschungsvereinigung des Zentralverbands für Elektrotechnik- und Elektronikindustrie
- DFKI: Deutsches Forschungszentrum für Künstliche Intelligenz
- Fachhochschule Dortmund - Institut für Kommunikationstechnik
- IoT connctd GmbH
- Kernfrage: Interoperabilität über Semantik
16.07.2020 2
Agenda
▪ Einführung
▪ Herangehensweise
▪ Übersicht Iterationen
▪ Fokus
▪ Ergebnisse
▪ Demos
▪ Zusammenfassung und Ausblick
15.07.20 3
Einführung
IoT – früher und heute
Silos Aggregation
Öffnung
15.07.20 4
Einführung
Möglicherweise zukünftig
▪ Idee: Schaffung von Interoperabilität durch…
▪ einheitliche Umschreibung von
Schnittstellen
▪ semantische Beschreibung von
zugrunde liegenden Datenmodellen
15.07.20 5
Einführung
Konzept ist nicht neu: Semantic Web
15.07.20 6
Einführung
Wie sieht dieser Baustein konkret aus?
15.07.20 7
Herangehensweise
▪ Austausch Projektpartner: bestehende System, gemeinsames Verständnis (z.B. Digitaler Zwilling, technische,
syntaktische und semantische Interoperabilität)
▪ Feststellung der Anforderungen aus Sicht von Geräteherstellern und Anwendungsentwicklern
▪ Identifikation und Evaluation von möglichen Lösungswegen
▪ Anreicherung existierender Datenmodelle
▪ Beschreibung existierender Datenmodelle über zusätzliche Modelle
▪ Festlegung auf bestimmten Lösungsweg und Aufteilung der Arbeit in mehrere Iterationen
▪ denn: gesuchte Komponente ist komplexes Gebilde aus Modellen und Diensten
15.07.20 8
Iteration 1
Fokus
▪ Beschreibung von Geräten und Funktionalitäten
▪ Bereitstellen von Beschreibungen
15.07.20 9
Iteration 1
Beschreibung von Geräten und Funktionalitäten über WoT TD
▪ Standardisierung durch W3C
▪ Web Of Thing Thing Descriptions definieren ein formales Modell und erlauben
▪ Abstraktion von physischen oder virtuellen Entitäten
▪ Beschreibung von Interaktionen (eng. Interactions)
▪ Beschreibung von Metadaten und Schnittstellen von Geräten/Dingen
▪ Repräsentation im JSON-Format mit JSON-LD Verarbeitung
15.07.20 10{ […] […]
"@context": [ "properties": { "actions": {
"https://www.w3.org/2019/wot/td/v1", "lamp-on": { "lamp-setOn": {
{ "type": "object", "safe": true,
"iot": "http://iotschema.org/", "@type": [ "type": "object",
"unit": "http://qudt.org/vocab/unit/", "PropertyAffordance", "@type": [
"schema": "http://schema.org/" "iot:SwitchStatus" "ActionAffordance",
} ], "iot:TurnOn",
], "forms": [ "iot:TurnOff"
"@type": [ { ],
"Thing", "op": "readproperty", "forms": [
"iot:ColourControl", "href":"https://api.connctd.io/api/...../on", {
"iot:DimmerControl", "contentType": "application/json" "op": "invokeaction",
"iot:BinarySwitchControl" } "href":"https://api.connctd.io/api/.../setOn",
], ], "contentType": "application/json"
"name": "LightTwo", "title": "on", }
"id": "uri:urn:20b458…b99-58bcfb8ea988", "writeable": false, ],
"description": "Generated TD from thing", "observable": false, "input": {
"referenceId": "85c967...e0c-887e-2fd7ad5e89dc", "properties": { "type": "object",
"schema:manufacturer": "LIFX", "value": { "properties": {
"title": "LightTwo", "type": "boolean", "on": {
"securityDefinitions": { "@type": "iot:StatusData", "type": "boolean",
"apiKeySecurityScheme": { "schema:dateModified": { "@type": "iot:StatusData"
"in": "header", "@id": "dateModified" }
"name": "Authorization", } }
"scheme": "apikey" }, },
} "lastUpdate": { "title": "setOn",
}, "@id": "dateModified", "idempotent": true
"security": [ "type": "string", },
"apiKeySecurityScheme" "@type": "schema:DateTime" […]
], } events: {
[…] }
}, }
[…] […]
15.07.20 11Iteration 1
Bereitstellen von Beschreibungen
▪ Prototypische Umsetzung zur Bereitstellung von WoT Thing
Descriptions durch DFKI, FH Dortmund und connctd
▪ Zwecks Proof-Of-Concept wurden verschiedene Gerätetypen
semantisch beschrieben und bereitgestellt
▪ Zusätzlich: Einordnung in mögliche Gesamtarchitektur
15.07.20 12Iteration 2
Fokus
▪ Modell zwecks Verortung von Thing Descriptions
▪ Entwicklung von Diensten/Agenten zur Untersuchung der
Praxistauglichkeit
▪ Plattformübergreifender Zugriff auf TDs
15.07.20 13Iteration 2
Datenmodellierung mit BOT (Building Topology Ontology)
Quelle: https://w3c-lbd-
cg.github.io/bot/assets/zones.png
15.07.20 14Demo 1
- Locations, Thing Descriptions und Regeln
15.07.20 15Demo 2
- Abgeleitetes Wissen, AI RDF Data Space erlaubt
Einsatz von standardbasierten
Frameworks:
• SPARQL
• Triple Stores
• RDF(S)/OWL Reasoning
• Anwendung von ‚semantischen‘
Regeln: z.B. SPIN (SPARQL
Inferencing Notation) etc.
• Multiagentensysteme
Umwandlung JSON-LD→ RDF
15.07.20 16Zusammenfassung
▪ Wir wissen, wie wir…
▪ Geräte beschreiben, Räumlichkeiten beschreiben, Geräte verorten
▪ Weitere große Themenkomplexe (Forschungsfelder), die von Relevanz sind
▪ Mapping
▪ Interoperable Beschreibung von Payload Datenstrukturen (Dataschemata)
▪ Schemata/Ontologie Mapping (z.B. iotschema zu KNX-IoT)
▪ Berücksichtigung von Ontologie Einschränkung (Constrains – z.B. minCardinality) und Validierung
▪ Hardwarebeschreibungen
▪ Nutzer- und Rollenmanagement
▪ Modelle und Schnittstellen auf andere Architekturen projiziert (z.B. lokale Umgebungen)
▪ Erweiterte Query APIs (SPARQL) und Reasoning
▪ Events
▪ Historien
15.07.20 17Fragen?
info@projekt-sense.de
https://www.projekt-sense.de/projekte
15.07.20 18ANHÄNGE
16.05.2019 19Vorstellung SENSE WoT
Datenmodellierung mit WoT Thing Description
Quelle: https://www.w3.org/TR/wot-thing-
description/
10.06.2020 20Einführung
Was verstehen wir unter Semantik?
▪ Allgemein: die Lehre der Bedeutung von Symbolen, Wörtern oder Sätzen [1]
▪ „Ich höre gern Musik“
▪ Wir sind uns der Bedeutung dieser Aussage durch unser implizites Wissen bewusst
▪ „Ich finde Java toll“
▪ Hier hängt die Bedeutung vom Kontext und vom Vorwissen ab
▪ Eine Maschine kann weder mit der einen noch mit der anderen Aussage etwas anfangen
▪ Voraussetzung: Wissen muss explizit und maschinenlesbar vorliegen
▪ Schemata/Ontologien: definieren und klassifizieren Entitäten und bilden ihre Beziehungen untereinander über ein
formales Modell ab
10.06.2020 21Einführung
Warum also semantische Beschreibungen?
▪ Eindeutigkeit
▪ Klassische Datenmodelle besitzen implizite Semantik, die nur im Kontext des jeweiligen Modells gilt
▪ Beispiel:
Modell A – name -> Bedeutung: Displayname für das Gerät, kann durch Benutzer geändert werden
Modell B – name -> Bedeutung: Technischer Gerätename für Systemintegrator
▪ Beispiel (semantisch):
Modell A - https://schema.org/name -> The name of the item.
Modell B - https://schema.org/name -> Selbe Bedeutung wie bei Modell A
▪ Wiederverwendbarkeit
▪ Ontologien sind in der Regel öffentlich Verfügbar und können frei genutzt werden
▪ Hersteller können mehrere Ontologien verwenden und sich auf die Verwendung einheitlicher Elemente einigen
▪ Erweiterbarkeit
▪ Durch die Verknüpfung von eindeutigen Ressourcen (URIs) in Form von RDF Triples kann ein Wissensgraph
beliebe Zusammenhänge Modellieren und jederzeit erweitert werden (Open Linked Data)
10.06.2020 22Iteration 1
Identifizierte Probleme - Ende Oktober 2019
▪ Forms und verbindungsspezifische Parameter
▪ Schnittstellen haben unterschiedliche Autorisierungskonzepte
▪ Payloadtransformation
▪ Beispiel: RGB Wert einer Lifx Lampe (HSBK) ist anders definiert als der einer Philips Hue Lampe (HSB)
▪ Schema Constraints
▪ Mozilla IoT: ColorProperty - string (hexadecimal RGB color code, e.g. #FF0000)
▪ IotSchema: Farbe besteht aus RColourData, GColourData, BColourData
▪ Unzureichendes Vokabular
▪ Automatisierte Validierung von WoT TDs
▪ Verortung von Thing Descriptions
10.06.2020 23Iteration 2
Datenmodellierung mit BOT (Building Topology Ontology)
▪ Spezifikation und Publikation durch die Linked Building Data
Community Group
▪ BOT ist eine minimale Ontologie um Zusammenhänge
zwischen Subkomponenten eines Gebäudes zu definieren
▪ Beschreibung von Grundstücken (Site), Gebäuden (Building),
Etagen (Storey), Räumen (Space) und Elementen (Elements)
▪ Repräsentation im JSON-Format mit JSON-LD Verarbeitung
▪ Es bildet eine erweitere Basis die durch domainspezifische
Ontologien ergänzt werden kann
Erweiterungen in SENSE:
▪ Erweiterung durch Elemente vom Typ: wot:Thing
▪ Erweiterung durch jsongeo Ontologie für Positionierung von
Elementen/Things
▪ Erweiterung durch Elemente aus der Product Ontologie (Wall,
Window, Door…)
10.06.2020 24Iteration 2
Beispiel einer Location
{
"@context": {
"bot": "https://w3id.org/bot#", Hinweis auf verwendete Schemata
"geo": "https://purl.org/geojson/vocab#",
"schema": "http://schema.org/"
},
"@id": "https://api.connctd.io/api/betav1/wot/locations/63ade586-3a1a-4547-a66d-5e32e29d854c",
"@type": [
"bot:Space",
],
"schema:name": "Living Room",
"bot:hasElement": [
{
"@id": "https://api.connctd.io/api/betav1/wot/locations/968f62a0-b172-482f-949c-5dc230f87767" Referenz auf Thing-Location
}
],
"geo:geometry": {
"geo:coordinates": [
[
110, Dimensionierung des Raumes
10
], …
10.06.2020 25Iteration 2
Beispiel einer Location (Thing)
{
"@context": {
"bot": "https://w3id.org/bot#",
"geo": "https://purl.org/geojson/vocab#",
"wot": "https://www.w3.org/2019/wot/td#"
},
"@id": "https://api.connctd.io/api/betav1/wot/tds/d60014ef-01ee-486e-9de2-fddfafe590bc",
"@type": [
"bot:Element", Referenz auf Thing Description
"wot:Thing"
],
"geo:geometry": {
"@id": "point:e6302ffa-74bc-4d4f-bef8-055966ac7d79",
"@type": [
"https://purl.org/geojson/vocab#Point"
], Verortung Thing
"geo:coordinates": [
5,
130
]
},
"id": "968f62a0-b172-482f-949c-5dc230f87767"
}
10.06.2020 26Iteration 2
Identifizierte Probleme
▪ Unzureichende Schemata
▪ Typisierung von Räumen
▪ Hoher Aufwand zur Nutzung in Diensten/Agenten (Query API
fehlt)
▪ „getrennte“ Modelle
▪ Thing Descriptions müssen bspw. nachgeladen werden:
einheitliche Vorgehensweise/Deklaration notwendig
10.06.2020 27Ausblick Iteration 3
▪ Locations aus TDs verweisen ▪ Beschreibung von Hardware Komponenten
▪ Automatisches Mapping
▪ Dimensionierung von Örtlichkeiten: Verweis auf weitere/bestehende Modelle (Stichwort BIM)
10.06.2020 28Ausblick Iteration 3
Automatisches Mapping
Allgemein:
▪ In der Regel ist ein Mapping auf verschieden Ebenen erforderlich. Bezogen auf WoT:
▪ Mapping der Geräteeigenschaften und Funktionen (Thing Ebene)
▪ Mapping der Zustandswerte (Payload Ebene)
▪ Es existieren unterschiedliche Mapping-Techniken, die jeweils ihre Vor- und Nachteile besitzen. Eine Universale
Lösung für jegliche Mapping-Probleme existiert nicht.
▪ Das Mapping zwischen zwei Datenmodellen kann verlustbehaftet sein
▪ Unterschiedliche Datenformate und Repräsentationen können ein Mapping erschweren
▪ Große Datenmodelle mit „komplexen Objektstrukturen“ benötigen komplexe Mapping-Vorschriften
10.06.2020 29Sie können auch lesen
