Blogthemen filtern:

Unsere Blogthemen

Ein Architektur-Update des Kiel Data Hub auf Basis von FIWARE, und wie wir LoRa Parksensoren integriert haben

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.

Kiel Data Hub Architektur auf Basis von Microservices

Die initiale Architektur von Kiel Data Hub

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:

Kiel Data Hub Architektur mit FIWARE Context Broker

Erweiterung der Architektur mit dem FIWARE Context Broker

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:

Visualisierung der Parksensoren in einer Worldmap in Grafana

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.

6. September 2019

Es ist vollbracht: Werkzeit ist offiziell im AppStore erhältlich!

Werkzeit ist eine von uns entwickelte, ausfallsichere software-as-a-service-Plattform, die verschiedene Anwendungsfälle abdeckt und mehrere Apps umfasst:

Entstanden ist Werkzeit aus unserem Wunsch heraus eine faire Software zu nutzen, die es ermöglicht individuelle Arbeitszeiten zu tracken, Überstunden automatisch zu berechnen und den gesetzlichen Dokumentationspflichten gerecht zu werden.

Da wir bei networkteam nach dem Gleitzeit-Arbeitszeitmodell arbeiten, viele von uns bereits Kinder haben und der ein oder andere gelegentlich auch von Zuhause -oder im Außendienst- arbeitet, benötigten wir eine flexible und unkomplizierte Anwendung, die diesen Anforderungen gerecht wird.

Was macht man also, in einer Digitalagentur? Na klar: man entwickelt seine eigene App!

Statusboard Standort
11. März 2019

Im Rahmen der digitalen Woche Kiel

Vom 18. bis 22.9. haben wir einen Code-Sprint für das Neos Projekt bei uns in der Agentur veranstaltet. Im Rahmen der digitalen Woche Kiel haben wir die Chance genutzt und langjährige Mitglieder des Neos Teams sowie Gäste zu uns eingeladen, um eine Woche an einem speziellen Thema zu arbeiten: der Umstellung des sogenannten Content-Repositories auf eine Event-Sourced Architektur.

Das hört sich erst einmal kompliziert an und bei einigen Diskussionen sind wir auch sehr tief in die Materie abgestiegen, um grundlegende Konzepte in Neos weiter zu definieren und zu durchdenken. Für die technischen Details hat Sebastian Kurfürst einen sehr umfangreichen Blog-Eintrag zum Event Sourced Content Repository erstellt. Aber was bedeutet das eigentlich für Anwender von Neos (Redakteure, Integratoren und Entwickler)?

26. September 2017