Dieser Blogpost geht auf die technischen Aspekte unseres DEC4IoT Projektes ein. Als wichtige Herausforderungen adressieren wir die Sammlung und Aufbereitung von Daten im Internet der Dinge (IoT) basierend auf SenML. SenML seht für Sensor Measurement List und ist der Name des RFC8428 - ein Standard aus dem Jahr 2018, der ein einheitliches und effizientes Sensordaten-Format vorschlägt. Der zweite wichtige Standard ist für uns CAP, das steht für Common Alerting Protocol und ist ein standardisiertes XML-basiertes Format zur Übermittlung von Warnmeldungen und Notfall-Nachrichten.

Datensammlung

Der Prozess der Datensammlung startet mit dem Onboarding von Sensoren. Dazu werden als erstes die Informationen des Gerätes (derzeit Puck.js oder Bangle.js) gemeinsam mit Personendaten zur Alarmierung erfasst und mit einer eindeutigen ID versehen. Ein Service-Endpunkt (genauer eine REST API an das die Sensordaten geschickt werden) und diese eindeutige ID werden als QR Code dargestellt und können mittels App am Handy ausgelesen werden, die dann wiederum mittels Bluetooth das IoT Device initialisiert.

Beim tatsächlichen Datenfluss sendet dann der Sensor via Bluetooth Daten an einen ESP32 (ein leistungsstarker, programmierbarer Mikrocontroller). Dieser wandelt die Informationen in das standardisierte SenML Format um und leitet diese dann via HTTP Request weiter an ein sogenanntes Edge Device. In unserem Fall ist das ein RaspberryPi auf dem ein Semantic Container als transienter Datenspeicher dient. Die Aufgabe des Semantic Container ist das kompakte SenML Format in Zeitreihendaten umzuwandeln, die dann wiederum von einem kontinuierlichen Monitoring auf konfigurierbare Muster überprüft werden. In unserer derzeitigen Entwicklungsumgebung sind das:

• Drücken des Notruftasters -> löst einen Rettungsnotruf aus
• Temperatur über 40°C länger als 2 Minuten -> löst einen Feuerwehrnotruf aus
• Batteriespannung unter 10% -> verschickt 1x pro Tag ein Erinnerungsmail für den Batterietausch

Alarmierung

Im Fall einer Alarmierung (aktuell: Notruftaster oder zu hohe Temperatur) werden die im Onboarding konfigurierten Notfalldaten gemeinsam mit erfassten GPS Daten (diese kommen entweder vom Sensor selbst, oder werden vom ESP32 bereitgestellt) mit Hilfe des DEC112 SDK (Software Development Kit) an das ESINet (Emergency Service IP Network) übergeben. Das SDK sorgt dabei sowohl für die Authentifizierung der Alarmgebers (also unseres Monitoring-Systems) als auch die Umsetzung der eingehenden Informationen auf das standardisierte CAP Format.

Die auf diese Weise aufbereiteten Daten werden dann basierend auf den Ortsinformationen an die verantwortliche Leitstelle weitergeleitet und dort als Notruf signalisiert. Bei der Bearbeitung des Notrufes wird auf einer Karte der Notruf angezeigt und es stehen die vorab konfigurierten Informationen (zB Name, Zimmer, Stockwerk, eventuelle medizinische Zusatzinformationen) sofort zur Verfügung.

Nutzen & Ausblick

Durch die hier vorgestellte Architektur und die verwendeten Standards schaffen wir die Basis für weitere IoT-Services schnell und einfach sich an die bestehende Infrastruktur anzupassen. Wir haben großen Wert darauf gelegt, die einzelnen Funktionsblöcke fein-granular zu definieren, sodass diese durch alternative Ansätze ersetzt werden können. Wichtig ist uns dabei der standard-konforme Datenaustausch und das Vorhandensein einer Referenz-Implementierung als Open Source Software.

In den nächsten Wochen werden wir unsere Entwicklung weiter testen (und besser dokumentieren). Ende des Frühjahrs wollen wir dann ein komplettes Setup an erste Tester übergeben und so weiter die Stabilität des Systems evaluieren. Falls ihr Fragen oder Anmerkungen habt, schreibt unten einen Kommentar und ihr könnt uns auch unter der Email Adresse info@dec112.at erreichen.