Air Support

Air Support erforscht die Prognose der Luftqualität in Büroumgebungen und stellt den praktischen Teil meiner Masterthesis dar.

Motivation

Schlechte Innenraumluftqualität (IAQ) zählt zu den größten umweltbedingten Gesundheitsrisiken und fordert ebenfalls durch nicht tödliche Folgeerscheinungen finanzielle Einbußen in Milliardenhöhe. Problematisch ist, dass sich der moderne Mensch zu 90 % seiner Zeit in Innenräumen aufhält, wo oft hohe Schadstoffbelastungen der Raumluft vorliegen.

Air Support geht daher folgender Forschungsfrage mit der Perspektive der Entwicklung einer digitalen Assistenz zur Unterstützung der manuellen Fensterlüftung nach:

Können Parameter der Luftqualität in Innenräumen auf der Grundlage von Daten eines realen Anwendungsfalls einer gewöhnlichen Büroumgebung erfolgreich prognostiziert werden?

Forschungsdesign und Ergebnis

Die Erkenntnisse dieser Forschung sind ebenfalls als akademische Präsentation verfügbar.

Air Support verfolgte, inspriert von CRISP und DASC, ein fünfschrittiges Forschungsdesign, bestehend aus Business Understanding, Data Understanding, Data Preparation, Modeling und Evaluation. Gemäß des aufgebauten Business Understandings sind CO2 sowie PM (Particulate Matter) des Innenraums entscheidende Parameter der Raumluftqualität von Büroumgebungen und werden zum Ziel der Prognose gemacht. Als weitere Einflussfaktoren wurden die Fensteröffnung, Luftfeuchtigkeit, Temperatur, Windgeschwindigkeit und Windrichtung berücksichtigt. Die Parameter wurden über Sensoren und Third-Party-APIs für den Innen- und Außenraums gemessen. Zur Aufzeichnung der Daten wurde eine IoT-Infrastruktur im Bürogebäude des Kooperationspartners artiso solutions GmbH realisiert, die 10 Versuchsräume erfasste. Eine Cloud-Architektur kam zur Verarbeitung der Daten zum Einsatz. Air Support sammelte im Laufe des Projekts 2.000.000 Datenpunkte. Auf Grundlage des Data Understandings bereitete die Data Preparation ein qualitatives Dataset auf. Die nachfolgende Abbildung zeigt einen Auszug des Air Support Datasets.

Das Modeling definierte den absoluten Wert der Zielparameter in 20 Minuten als Prognosezeitraum und identifizierte Recurrent Neural Networks, Long Short-Term Memory beziehungsweise Gated Recurrent Unit, in Kombination mit einer Direct Multi Step Strategie der Prognose als geeignete Ansätze. Diese wurden mit allen Kombinationen jener Features erprobt, die am stärksten mit den Zielparametern korrelieren: CO2 und Particulate Matter des Innen- und Außenraums. Die folgende Tabelle listet die Architekturen, die während des Modelings verwendet wurden.

Obwohl die absoluten Fehler niedrig sind, werden die entwickelten Models in der Phase der Evaluation negativ bewertet. Die Prognosen stellen keine effektiven Vorhersagen der Zukunft dar, sondern verzögerte Repräsentationen der realen Werte. Die Verzögerung der Prognosen konnte trotz zahlreicher Experimente nicht behoben werden. Die nachfolgende Abbildung stellt eine CO2 Prognose und tatsächliche Werte gegenüber.

Eckdaten des Projekts

• Start: 08.02.2021
• Ende: 06.12.2021
• Status: beendet

Technische Beschreibung

Verwendete Technologien

• C++, PlatformIO: Programmierung der Mikrocontroller
• Node.js (TypeScript): Entwicklung der Azure Functions
• Python: Data Science
• Data Science
  • JupyterLab: Data Science Notebooks
  • pandas, numpy, matplotlib: Data Analysis
  • Keras, tensorflow: Deep Learning
• Docker: Development (VSCode devcontainer)
• Infrastruktur
  • Microsoft Azure: Cloud-Infrastruktur
    • IoT-Hub: Authentifizierung und Management der IoT-Devices
    • Service Bus: Entkopplung von IoT-Hub und nachgeschalteter Azure Function
    • Functions: Event-Driven Serverless Compute
      • Service Bus Trigger zur Verarbeitung der Sensordaten
      • Timer Function zum Abruf von Daten aus Third-Party APIs
      • HTTP Trigger zur Verarbeitung einer Microsoft Teams Outgoing Webhook
    • Key Vault: Speicherung von Secrets
    • Database for PostgreSQL mit TimescaleDB: Serverless Time Series Database
  • alembic: Database Migrations mit SQLAlchemy
  • Terraform: Infrastructure As Code zur Verwaltung der Azure Cloud-Infrastruktur
  • Microsoft Teams: Webhooks

Architektur

Applikation

Der IoT-Gateway fungiert als zentraler Einstiegspunkt der IoT-Infrastruktur in die Cloud. Er sorgt für Sicherheit bei der Anbindung von IoT-Geräten und routet alle Datenpakete an eine Queue.

Die Queue zwischen IoT-Gateway und dem IAQ Data & Notification Service entkoppelt den Eingang und die Verarbeitung der Daten. Die Queue ist in der Lage, Messages für längere Zeit vorzuhalten, was zu sequenzieller und asynchroner Bearbeitung befähigt. Neben geringerer Anforderungen an die Performance ist vorteilhaft, dass temporäre Ausfälle des Konsumenten entschärft werden. Messages verbleiben solange in der Queue.

Der IAQ Data Service verantwortet die Speicherung der Sensordaten in die Datenbank. Ist der IAQ Data Service verfügbar und es befindet sich eine neue Message in der Queue, wird die Speicherung der enthaltenen Messwerte in die Datenbank vorgenommen.

IAQ Notification Service und IAQ Request Service stellen Assistenzfunktionen in Microsoft Teams zur Verfügung. Die beiden Dienste sind über Webhooks in Channels integriert und können darin Nachrichten publizieren. Der IAQ Notification Service ist ein heuristischer Assistent, der Raumnutzende auf Grundlage von Schwellwerten auf problematische Luftqualität hinweist. Der IAQ Request Service bietet die Möglichkeit, per Chatfunktion in Microsoft Teams die aktuellen Werte aller Räume ad-hoc abzurufen.

Datenmodell

Die Datenstruktur besteht aus 4 fundamentalen Entitäten:

• Measurement enthält Daten aller messbaren Parameter. Die auslassbaren Attribute, mit NULL gekennzeichnet, gewähren die notwendige Flexbilität, nur die Attribute anzulegen, die ein spezifisches Sensormodul bereitstellt.
• Location ist der Ort einer Messung. Dieser kann ein Versuchsraum oder der Außenbereich sein. Durch die einfache Assoziation zu Measurement kann eine Messung auf einen Ort zurückgeführt werden. Location besitzt außerdem multiple Assoziationen zu DataSource, um mehrere Datenquellen an einem Ort zu installieren.
• DataSource ist eine Quelle von Sensordaten. Sie kann sowohl ein Sensormodul als auch eine Third-Party-API sein. Eine DataSource kann mit unlimitierten Measurements assoziiert sein. Damit kann eine Messung auch auf ein Sensormodul zurückgeführt werden und ist eindeutig lokalisierbar.
• Notification dient der Koordination des Versands von Benachrichtigungen an eine Location und darf nicht als explizite Benachrichtigung missverstanden werden. Zwischen Notification und Location gibt es eine einfache Assoziation.