Guided Autonomic Building – IoT Interface und 3D-Visualisierung Hilko Hoffmann, Jürgen Grüninger, Markus Kuller, Ingo Kunold, Oliver Kuhn, Silke Balzert

Gefördert durch

Projektträger

Bisherige Lösungen bieten schon sehr viel, sind aber

oft nicht ausreichend modular,

oft auf eine Anwendungsdomäne spezialisiert,

ohne Expertenwissen kaum einzurichten,

nicht selbstlernend,

für die Gebäudenutzer oft komplex zu bedienen

nur teilweise nutzbar in Verbindung mit mobilen Endgeräten

Schwer durchschaubar für die Gebäudenutzer

Technisch

komplex

Relativ geschlossene

Systemwelten

Konfiguration nur

durch Experten

Automationslösungen

Automationslösungen

Existierende Lösungen

Die Verbindung von heterogenen Systemlandschaften ist nach wie

vor schwierig

Viele Feldbussysteme bieten IP-Übergänge aber keine

Interoperabilität

Feldbussystem A kann nicht mit Feldbussystem B kommunizieren

Verschiedene Feldbussysteme können nicht einfach in einer

gemeinsamen Automationsanwendung zusammenarbeiten

Verfügbare APP-Konzepte bleiben proprietär auf ein

Systemökosystem beschränkt – oft sogar herstellerspezifisch

Automationslösungen

Existierende Lösungen

• Frameworks (OpenHAB, OpenURC, OpenAAL, OpenUHCI, Fhem)

• Proprietäre Komplettlösungen (RWE, QIVICON, Siemens Gigaset,

Digitalstrom, MyGekko)

• Automationsstandards auf Feldbusebene (KNX, Zigbee, EEBus)

• Datenmodellstandards z.B. OASIS/oBIX (open building information Xchange)

• Kleine spezifische Lösungen (Viesmann, Philips Hue, Osram)

Umfassende Architekturen sind relativ schwerfällig und meist

auch plattformabhängig und systemgebunden

Vernetzte Web-Welt

Musik Streaming Dienst

Bewertungsmechanismen

Login / Registrierungs-mechanismen

Vorgefertigte APPs und Vorlagen

Cloud Plattform

Web-Anwendung, APP

Eingebetteter Spotify-Player

Soziales Netzwerk

Vernetzte Smart-Building-Welt

IP-Netzwerk In-House Internet

Dienste

Automations- lösungen

Interaktion

Gebäude

Nutzung etablierter

Standards in der

Gebäudeautomation,

Zugangsverwaltung auf

mehreren Ebenen

Intelligente

Nutzungsauswertung und

prädiktive Steuerung

Flexibel anpassbare

Konfigurationen und

Assistenzfunktionen für

Bewohner und Serviceanbieter

Flexible Einbindung

externer Dienste

„Gebäude-APPs“ und

3D-Darstellungen

Modulares

Systemkonzept, lose

Koppelung durch

allgemeingültige

Beschreibung der

einzelnen Komponenten

Anforderungen und Ziele

Guided AB Referenzschnittstellen

Referenzarchitektur

Anforderungen und Ziele

Ansätze

Lösungsansatz 1: Umfangreiches Mapping z.B. EEBus

Wenn verschiedene Systemwelten verbunden werden, ist das Mapping

sehr aufwändig

Lösungsansatz 2: Aufteilen in einzelne Dienste und semantische

Beschreibung der Dienste Guided AB

Guided-Architektur: RDF

Dienstbeschreibung mit RDF (Resource Description Framework)

• RDF dient der Beschreibung von anderen (Automations-) Daten mit

den Vokabeln: Subjekt, Prädikat, Objekt

• Eine Ressource wird über einen Uniform Resource Identifier (URI)

identifiziert, z.B. https://guided.de/building_one

• Beispiel:

– Das Subjekt ist: Hager Wetterstation

– Ein mögliches Prädikat ist: Wind

– Das Objekt/Messwert ist:

Wind 1 (in Meter pro Sekunde)

https://guided.de/building_one/Hager_Wetterstation

hat Messwert https://guided.de/rdf/wind

1 m/s

Assistenzplattform Bedienung

Execution Engine

Dual-Reality Interface

Gebäude-APPs

APP-Store

Konfigurationen

Gebäude-zustand

IP-Netzwerk … … SDC

Geräte Sensoren Aktoren

Interne Dienste

Feldbus

IoT Middleware

Smart Building Manager

Gebäude

My Home Companion

Guided-Architektur

Web-Service

Web-Service Web-Service

Konfigurationshilfen

RDF

Benutzer- management

Benutzermanagement

IP-Netzwerk

Dienste

Interaktion

IP-Netzwerk

IoT-System Komponenten in Guided AB

• Grundfunktionen des IoT Systems

• Referenzarchitektur mit Referenzschnittstellen des IoT

Systems

• Software Architektur des IoT-Systems

• Protokolle und Datenmodelle des IoT Systems und

grundlegende IT Security Aspekte

• Anforderungen an das IoT System - intern (SDC / SBM):

– Ziel ist die Integration von Sensoren und Aktoren in eine IP-Infrastruktur

(Konzeption und Implementierung eines Abstraktions-Layers),

– die Archivierung von realzeitnahen Gebäudezustandsinformationen,

– die Bereitstellung einer Service-basierte Schnittstelle (IoT-Interface /

intern) - für externe Dienste (u.a. Dual Reality, Apps) – zur Nutzung von

parametergestützten Steuer- und Regelungsfunktionen,

– die Verwendung standardisierter Übertragungstechnik, Protokollen und

Datenmodellen,

– Entwicklung eines modularen Aufbau des IoT Systems zur Realisierung

unterschiedlicher Inhouse-Vernetzungskonzepte (Gebäudetechnologie und

Vernetzung) (Smart Device Controller / Smart Building Manager) und die

– die Integration signifikanter Eigenschaften von Feldbussystemen in eine

IP-basierte Netzinfrastruktur – wie z.B.: • Funktionen, Status und Eigenschaften von Geräten

• logische Verknüpfungen von Geräten und

• Sicherheitsaspekten

Detaillierte Anforderungen an das IoT

System (Inhouse)

Integration einer Cloud Komponente (Smart Building Server) als zentrale Instanz

zur Verwaltung mehrerer IoT Inhouse Systeme

• Anforderungen an das IoT System - extern (SBS):

– Zentrale Verwaltung und Verteilung von Ressourcen (Sensoren / Aktoren)

– Systemweite Kennzeichnung/Identifikation von Ressourcen mithilfe einer

eindeutigen ID (UUID – Universally unique identifier)

– Zugriffsmanagement auf Benutzer-, Rollen- und Geräteebene

– Langzeitarchivierung von Gebäudezustandsinformationen

• Berücksichtigung von Sicherheitsstandards in das IoT System

nach BSI TR-02102-2 und DKE AK 716.0.1

Detaillierte Anforderungen an das IoT

System (Internet)

Referenzarchitektur des IoT Systems

GAB Services

(Ext.)

SBS

SBM

SDC SDC 1

Backend

System

Inh

ou

se

Sys

tem

IoT – System

SDC

A

S

Se

ns

or

/ A

ctu

ato

r

Are

a

(KN

X)

…

Intelligent, distributed Middleware internally provides near real-time

behaviour.

Standard technologies / protocols => fieldbus layer

N

1..N GAB Services

(Int.)

Smart Building Architecture

(SBA):

SDC: Smart Device Controller

SBM: Smart Building Manager

SBS: Smart Building Server

A

A

S

A

A

S

A

Se

ns

or

/ A

ctu

ato

r

Are

a (

Zig

Bee

)

Se

ns

or

/ A

ctu

ato

r

Are

a (

SM

L)

Message exchange protocols

HTTP / RESful WebService

HTTP / WebSocket

RMI

Information encodings

XML / JSON / EXI

Java binary object

Data models

DeviceData object

oBIX

(open Building Information Xchange)

Semantic Web Technologie

RDF (Resource Description Framework)

Aktueller Stand: Das IoT System als verteiltes Gateway-Konzept zur Realisierung einer Datendrehscheibe und Kommunikationsplattform zur Abbildung von Prozessen (Services) auf Basis erhobener Zustandswerte u. Steuerungsfunktionen, die über die Gebäudebussysteme zur Verfügung gestellt werden.

1. Zustands-/Messdaten werden je nach Typ des Sensor/Aktor mit einer

entsprechenden Granularität erfasst.

2. Ein DeviceLayer im Smart Device Controller (SDC) realisiert die Anbindung von

Bussystemen unterschiedlicher Ausprägung (z.B. KNX, ZigBee).

3. Der DeviceLayer überführt protokollspezifische Elemente auf ein vordefiniertes

Datenmodell – DeviceData Objekt .

4. Auf Basis eines systemweiten durchgängigen DeviceData Objekt Modells

werden mithilfe standardisierter IoT Transport Protokolle in der verteilten Smart

Building Architecture technisch hochstehende Dienste für Überwachungs- und

Steuerungsaufgaben realisiert.

Ziel: Evaluierung eines standardisierten Datenmodells (oBIX) und Konzeptionierung einer semantischen Beschreibung der GAB Schnittstellen.

Softwarearchitektur des IoT Systems

• Verfügbarkeit des IoT Systems (intern/extern)

– intern: Möglichkeit eines autarken Inselbetriebs (SBM / SDC)

– extern: Verfügbarkeitsanforderungen einer Cloud Anwendung (SBS)

• Vertraulichkeit der Daten

– Verschlüsselung von Daten bei der Kommunikation zwischen IoT System-

Komponenten (intern/extern) unter Verwendung von TLS v1.2 und aktueller

kryptographischer Verfahren (BSI TR-02102-2 Standards und DKE AK 716.0.1)

• Authentizität

– Benutzer- und Rollenbasierter Zugriff auf Ressourcen (Sensor- / Aktorfunktionen und

Eigenschaften) via SBM/SBS

• Integrität

– Verwendung von Nachrichtenauthentifizierungscodes (u.a. Hashcodes)

Ziel: Schutz vor unbefugten Zugriff auf Ressourcen des IoT Systems (intern/extern)

Anforderungen an die IT Sicherheit des

IoT Software Systems

IKT Testlabor (Guided AB)

Fragen ???