Als wir mit den Planungen für einen Kieler Datenhub vor über einem Jahr begonnen haben, war ein einfacher Aufbau basierend auf Microservices in möglicherweise unterschiedlichen Programmiersprachen das tragende Konzept. Somit konnten wir die Basis für die Zusammenarbeit verschiedener Teams und der Anbindung unterschiedlichster Datenquellen schaffen.
Neben dem Abruf und der Aufbereitung haben wir noch die Speicherung der Daten in verschiedenen Systemen (Elasticsearch und Prometheus) und eine Visualisierung in Dashboards auf Basis von Grafana vorgesehen und implementiert.
Doch ein wichtiger Aspekt ist nicht bedacht: die Daten stehen hauptsächlich zur Visualisierung zur Verfügung - eine Bereitstellung für andere Systeme / Applikationen über eine API fehlt. Zudem bereitet jeder Microservice die Daten unabhängig und hauptsächlich für die Visualisierung auf. Ein gemeinsames, standardisiertes Datenmodell zur Nutzung und Weitergabe der Daten an andere Plattformen und Applikationen wird nicht verwendet.
FIWARE als flexible Zwischenschicht in einer IoT Architektur
FIWARE is a curated framework of Open Source platform components to accelerate the development of Smart Solutions- fiware.org
FIWARE bietet mit dem sogenannten Context Broker als Herzstück einer Architektur eine flexible und bereits in vielen Smart City Projekten verwendete Open Source Lösung für genau dieses Problem.
Mit Context ist hier ganz allgemein ein Abbild der Umgebung gemeint, auf welchem dann Algorithmen Entscheidungen treffen können oder eine Auswertung auf Basis von aggregierten Daten vorgenommen werden kann. Eine wichtige Funktion sind dabei flexible Benachrichtigungen anderer Komponenten bei bestimmten Änderungen am Context. So kann eine Architektur auf Basis von Microservices über den Context Broker mit Daten versorgt werden.
In unserer Kiel Data Hub Architektur ist der Einsatz von FIWARE im ersten Schritt auf folgende Art und Weise geplant:
Anbindung und Darstellung von LoRa Parksensoren über FIWARE
Im Rahmen einer Smart City Veranstaltung haben wir vor kurzem Zugriff auf die IoT Daten der S/W Kiel Netz GmbH bekommen, welche der Stadt Kiel LoRaWAN Parksensoren für eine Erprobung an der Kiellinie zur verfügung gestellt hat.
Das LoRaWAN System ermöglicht die Nutzung von verteilten Sensoren über eine Funkanbindung mit großer Reichweite und niedrigem Stromverbrauch. Sogenannte Gateways decken dabei ein Empfangsgebiet von mehreren Kilometern ab. Über ein Netzwerk wie The Things Network können dabei die Sensordaten in die Zielapplikation gelangen.
Im konkreten Beispiel werden die Daten von den S/W Kiel Netz eigenen Gateways empfangen und in der Plattform ELEMENT IoT erfasst. Diese bietet wiederum eine API für den regelmäßigen Abruf der aufbereiteten Daten ("Parkplatz belegt" / "Parkplatz frei").
Für die Belegung von Parkplätzen bietet FIWARE ein definiertes Datenmodell ParkingSpot (neben vielen anderen Daten, die in einer Smart City anfallen) auf der Basis von europäischen Datenstandards (Datex II). Somit können alle anderen Komponenten und auch Drittsysteme eine einheitliche Struktur verwenden.
Unsere Lösung zur Einbindung der Sensoren besteht damit aus folgenden Teilen:
- IoT Agent Microservice zum regelmäßigen Abruf der Daten von der ELEMENT IoT API, Umwandlung der Daten in das ParkingSpot Schema und Aktualisierung der Parkplatzinformation über die Context Broker API - entwickelt mit Go und deployed als Docker Container
- FIWARE Context Broker als zentrale Schaltstelle für Daten
- API Microservice für den Abruf der Daten vom Context Broker aus Grafana (Umwandlung von NGSIv2 in JSON für eine Grafana Datasource) - derzeit umgesetzt als Teil des IoT Agent Microservices
Über ein Worldmap Panel kann in Grafana damit der aktuelle Zustand der Sensoren auf app.kiel-data-hub.de visualisiert werden:
Der API Microservice ist bei der Benutzung eines Storage Services wie z.B. FIWARE Quantum Leap zur Speicherung von Zeitreihendaten in einer dafür spezialisierten Datenbank nicht umbedingt notwendig. In einer weiteren Ausbaustufe werden wir die Kontext-Daten über Subscriptions zusätzlich in eine solche Datenbank laden, um in Grafana Auswertung über die Zeit darzustellen.
Vorteile des Context Brokers
Die Lösung mag kompliziert im Vergleich zur initialen Architektur von Kiel Data Hub wirken - jedoch bietet die Vereinheitlichung des Datenmodells und die Flexibilität zur Anbindung verschiedener Systeme über Subscriptions einen großen Vorteil. Wir entkoppeln somit die Services zur Datenakquise von der konkreten Benutzung der Daten.
Ein weiterer Vorteil besteht aus unserer Sicht in der Möglichkeit des Datenaustauschs zwischen verschiedenen Plattformen auf Basis des Context Brokers. Dieser bietet mit dem Federation Feature eine Möglichkeit bestimmte Daten zwischen Instanzen über Subscriptions auszutauschen. Dies ermöglicht spannende Anwendung bei der Weiterverwendung der Daten: denn aus unserer Sicht wird es in Zukunft viele Hubs/Plattformen geben, die Daten akquirieren und verarbeiten. Ein gemeinsames Datenmodell und eine standardisierte API auf der Ebene des Context Brokers bietet hier große Vorteile und erlaubt trotzdem eine eigenständige Architektur und Weiterentwicklung jeder Lösung.
Denn um unsere Städte und unser Leben in Zukunft digitaler und smarter zu gestalten, sollten wir nicht auf große, zentrale Strukturen großer Anbieter setzen - viele dezentrale Lösungen, die miteinander verbunden sind und zusammenarbeiten, sind das, was das Internet und Web erst zu dem gemacht haben, was es heutzutage ist.