‏ ‏ ‎ ‏ ‏ ‎

1. Pflichtenheft

1.1. Beschreibung der Ausgangsituation

Ein Teil der 5-jährigen Ausbildung an der HTBLA Leonding ist die Arbeit an Projekten. Es gibt einige offene und unvollendete Projekte und eines von ihnen ist Leo-IOT.

1.2. Istzustand

Die tendenziell fallende Luftqualität in den Klassenräumen führt zu schlechterer Lernqualität der Schüler und Konzentrationsmangel. Um dies zu ändern, wurde das IoT - Smart School Projekt gestartet. Es sollte die Luftqualität in den Klassen mithilfe von Sensorboxen gemessen werden und Schüler sollten auf schlechte Luftqualität aufmerksam gemacht werden. Neben der Luftqualität gibt es aber auch noch andere Faktoren, die sich auf das Klassenklima auswirken. Beispiele sind die Lautstärke, Temperatur oder Luftfeuchtigkeit. Mithilfe eines 3D Modells des Schulgebäudes werden diese Daten anschaulich präsentiert.

1.3. Problemstellung

Die aktuell genutzte Technologie bzgl. des Backends entspricht nicht unseren Ansprüchen. Auch das 3D Modell, welche die gemessenen Daten visualisiert, ist noch nicht so ausgereift und benötigt Aufarbeitung.

1.4. Aufgabenstellung

  • Inbetriebnahme des Systems

    • MQTT-Server zum Laufen bringen

  • Dokumentation erstellen

    • Milestones

    • User-Stories

    • README.md

  • 3D Modell Optimierung

1.4.1. Funktionale Anforderungen

Use-Case
User Case1
Charakterisierende Informationen Use-Case 1

Übergeordneter elementarer Geschäftsprozess:

Eine Person möchte sich ein 3D Modell der HTBLA Leonding anschauen.

Ziel des Use Cases:

Die gewünschten Daten werden auf einem 3D Modell angezeigt.

Umgebende Systemgrenze:

Von der Datenerfassung von den Klassen durch die Sensoren bis zur Veranschaulichung mithilfe des 3D Modells.

Vorbedingung:

Alle Systeme inklusive Hardware (Bildschirm, Sensoren, etc. siehe Mengengerüst) sind am Laufen.

Bedingung bei erfolgreicher Ausführung:

Die richtigen Daten werden angezeigt und veranschaulicht.

Beschreibung:

  • Sensoren messen und veröffentlichen Werte auf dem MQTT Broker

  • Der Quarkus, welcher den MQTT Broker "abonniert" hat, bekommt seine Daten

  • Über den Quarkus Server werden die angeforderten Daten aufgerufen

  • Die Werte werden dem User auf dem Client angezeigt

Beteiligte Nutzer:

  • Lehrer

  • Schüler

  • Schulinterne Fachkräfte (Sysadmin, Schulwart, …​ )

  • Schulbesucher

Auslösendes Ereignis:

Bei Datenaufruf

Charakterisierende Informationen Use-Case 2

Übergeordneter elementarer Geschäftsprozess:

Eine Person möchten einen Überblick bzgl. Leondings Straßenbahnverbindungen und einem gewünschten Klassenraum sehen.

Ziel des Use Cases:

Die gewünschten Daten werden auf einem Dashboard angezeigt.

Umgebende Systemgrenze:

Von der Datenerfassung von den Klassen durch die Sensoren bis zur Veranschaulichung einer GUI.

Vorbedingung:

Alle Systeme inklusive Hardware (Bildschirm, Sensoren, etc. siehe Mengengerüst) sind am Laufen.

Bedingung bei erfolgreicher Ausführung:

Die richtigen Daten werden angezeigt und veranschaulicht.

Beschreibung:

  • Sensoren messen und veröffentlichen Werte auf dem MQTT Broker

  • Der Quarkus, welcher den MQTT Broker "abonniert" hat, bekommt seine Daten

  • Über den Quarkus Server werden die angeforderten Daten aufgerufen

  • Die Werte werden dem User auf dem Client angezeigt

Beteiligte Nutzer:

  • Lehrer

  • Schüler

  • Schulinterne Fachkräfte (Sysadmin, Schulwart, …​ )

  • Schulbesucher

Auslösendes Ereignis:

Bei Datenaufruf

Charakterisierende Informationen Use-Case 3

Übergeordneter elementarer Geschäftsprozess:

Eine Person bekommt eine Benachrichtigung auf der Leo-iot App.

Ziel des Use Cases:

Die Person kann nun auf die Benachrichtigung die dementsprechenden Maßnahmen setzen.

Umgebende Systemgrenze:

Von der Datenerfassung von den Klassen durch die Sensoren bis zur Veranschaulichung einer GUI.

Vorbedingung:

Alle Systeme inklusive Hardware (Bildschirm, Sensoren, etc. siehe Mengengerüst) sind am Laufen.

Bedingung bei erfolgreicher Ausführung:

Das System erkennt einen Ausnahmezustand und benachrichtigt den User per Notification.

Beschreibung:

  • Sensoren messen und veröffentlichen Werte auf dem MQTT Broker

  • Der Quarkus, welcher den MQTT Broker "abonniert" hat, bekommt seine Daten

  • Über den Quarkus Server werden die angeforderten Daten aufgerufen

  • Die Werte werden dem User auf dem Client angezeigt

  • Bei einem Sonderfall soll der User benachrichtigt werden

Beteiligte Nutzer:

  • Lehrer

  • Schüler

  • Schulinterne Fachkräfte (Sysadmin, Schulwart, …​ )

  • Schulbesucher

Auslösendes Ereignis:

beim Eintreten eines Sonderfalles

1.5. Ziele

Steigerung der Lernqualität und Verbesserung des Wohlbefindens der Schüler und Lehrer

1.6. Mengengerüst

In einem bestimmten Zeitintervall werden Daten von den Sensoren and den MQTT Broker gesendet. Diese Daten werden an die Applikation weitergeleitet, welche die passenden Maßnahmen durchführt.

2. Entwurf "Wie mache ich es"

2.1. Systemarchitektur

system architecture new

2.2. Meilensteine

Meilensteine

Datum

  • Vorbereitung

12.11.2020

  • Persistence

04.3.2021

  • 3D-Model Improvement

04.03.2021

  • Simulator

01.03.2021

  • Visualisierung der Daten

19.4.2021

2.3. GANTT-Diagramm

gantt protoype1
gantt protoype2
gantt protoype3
gantt protoype4

2.4. Verantwortungsmatrix

Ecker Edlinger Klausner Knogler Kronreif Rieser

Backend

x

x

3D-Modell

x

x

Simulator

x

x

Sensor

x

x

Deployment