|
|
|
# 1. Systemüberblick
|
|
|
|
Diese Software soll es ermöglichen, viele kleine, zu Clustern zusammengefasste, Gewächshäuser zentral zu verwalten.
|
|
|
|
Um dies zu bewerkstelligen, sind in jedem Gewächshaus auf einem Arduino mehrere Sensoren verbaut, die über Bluetooth LE Messdaten an einen AccessPoint schicken. Die Gewächshäuser sind batteriebetrieben. Im Falle einer Messwert Unter- bzw. Überschreitung kann diese über eine RGB-LED kommuniziert werden.
|
|
|
|
Ein AccessPoint kann sich mit bis zu 255 Gewächshäuser (SensorStations) verbinden. Die zugeschickten Daten werden auf Messwert Unter- bzw. Überschreitungen geprüft und diese werden der entsprechenden SensorStation ggf. mitgeteilt. Gemessen wird die Erdfeuchtigkeit, die Luftqualität und die Lichtintensität.
|
|
|
|
|
|
|
|
Die Kommunikation zwischen den Komponenten wird mittels REST-Schnittstellen realisiert.
|
|
|
|
# Software Konzept
|
|
|
|
|
|
|
|
Die Daten werden in einstellbaren Intervallen an einen zentralen Webserver übertragen, über dessen Weboberfläche verschiedene Akteure auf die Daten zugreifen und diese verwalten können.
|
|
|
|
Des Weiteren ist an jedem Gewächshaus ein QR-Code angebracht. Über diesen Code gelangen unangemeldete Nutzer auf eine Seite, auf der Bilder dieser Pflanze zu sehen sind und die Möglichkeit besteht Bilder hochzuladen.
|
|
|
|
1. Systemüberblick
|
|
|
|
2. Use Cases
|
|
|
|
3. Klassendiagramm
|
|
|
|
4. SW-Architektur
|
|
|
|
5. Ausfallssicherheit
|
|
|
|
6. Ausgewählte Technologien
|
|
|
|
7. GUI Prototyp
|
|
|
|
8. Projektplan
|
|
|
|
|
|
|
|
Administratoren verwalten die AccessPoints und teilen Gärtner die SensorStations zu. Administratoren werden über den Webserver auch über Verbindungsprobleme, usw. zwischen den verschiedenen Komponenten informiert.
|
|
|
|
Nutzer haben die Möglichkeit Daten der Gewächshäuser anzeigen zu lassen.
|
|
|
|
## 1. Systemüberblick
|
|
|
|
|
|
|
|
|
|
|
|
# 2. Use Cases
|
|
|
|
Diese Dokumentation beschreibt PlantCare, eine Software die es ermöglicht, viele kleine, zu Clustern zusammengefasste, Gewächshäuser zentral zu verwalten.
|
|
|
|
Das Ziel war es, eine Gesamtlösung für den Anbau von Nutzpflanzen in Miniaturgewächshäusern zu entwickeln, um die Ziele der NGO Plant-Health zu unterstützen. Dabei sollen Sensoren in den Gewächshäusern verwendet werden, um Informationen zur Pflanzengesundheit und Umgebung zu erfassen. Die gesammelten Daten sollen in einer benutzerfreundlichen Webanwendung aufbereitet werden, die verschiedene Nutzergruppen anspricht. Ziel ist es, Zeitmangel, fehlendes Wissen und Umgebungsprobleme zu überwinden und den Anbau von Pflanzen in privaten, öffentlichen und Büro-Gebäuden zu ermöglichen. Das System wird in Bürogebäuden für einen Alpha-Testlauf implementiert werden, mit der Möglichkeit einer zukünftigen Version, die mithilfe von Datenanalyse und Machine Learning Mangelerscheinungen und Krankheiten bei Pflanzen frühzeitig erkennt.
|
|
|
|
|
|
|
|
# 2.1 Akteure
|
|
|
|
**Admin:**
|
|
|
|
Ein Admin verwaltet die User, AccessPoints und SensorStations des Systems
|
|
|
|
## 2. Use Cases
|
|
|
|
Grundlegend besteht das System aus drei Komponenten:
|
|
|
|
1. **SensorStation**: Ein Gewächshaus inklusive einem mit mehreren Sensoren bestückten Arduino Nano. Die gemessenen Daten werden über Bluetooth Low Energy an einen AccessPoint übertragen. In Zukunft sollen diese batteriebetrieben sein.
|
|
|
|
2. **AccessPoint**: Ein Raspberry Pi 4. Er empfängt die Daten von (bis zu 255) SensorStations, sammelt diese und schickt sie anschließend an den Webserver. Zusätzlich werden die empfangenen Daten auf Grenzwertüber- bzw. -unterschreitung überprüft und ggf. die entsprechendene SensorStation benachrichtigt. Diese kann dann über eine verbaute RBG-LED die Limitverletzung kommunizieren.
|
|
|
|
3. **Webserver**: Der Webserver stellt ein modernes, Multiuserprogramm zur verfügung. Dieses kann platformunabhängig in Webbrowsern aufgerufen werden. Hier können SensorStations und AccessPoints verwaltet, Pflanzendaten eingesehen, Fotos hochgeladen und User gemanagt werden.
|
|
|
|
|
|
|
|
**Gardener:**
|
|
|
|
Ein Gardener verändert Grenzwerte und Übertragungsintervall der ihm zugeteilten SensorStations. Des Weiteren kann er Fotos zu seinen Pflanzen löschen.
|
|
|
|
Folgende Usergruppen sind vorhanden:
|
|
|
|
1. **Admin**
|
|
|
|
2. **Gardener**
|
|
|
|
3. **User**
|
|
|
|
4. **Visitor**
|
|
|
|
|
|
|
|
**User:**
|
|
|
|
Ein User kann Messdaten von beliebigen Pflanzen einsehen.
|
|
|
|
Die Berechtigungen der jeweiligen Gruppen ist hierarchisch aufgebaut, das heißt ein User hat alle Funktionalitäten der Gruppen unter sich. Um das anschließende UseCase-Diagramm zu vereinfachen werden die UseCases nur der "niedrigsten" Gruppe zugeordnet. So ist zum Beispiel der UseCase "Bilder anschauen" der Gruppe Visitor zugeordnet. Daraus folgt, dass alle anderen Usergruppen diese Funktion auch besitzen.
|
|
|
|
|
|
|
|
**Visitor:**
|
|
|
|
Ein Visitor kann an der SensorStation einen QR-Code scannen, über den er auf eine Seite geleitet wird, an der er Fotos der Pflanze in der Station hochladen oder betrachten kann.
|
|
|
|
|
|
|
|
|
|
|
|
**AccessPoint:**
|
|
|
|
Ein Access empfängt Daten von bis zu 255 SensorStations und überprüft diese auf Grenzwerte Unter- bzw. Überschreitungen. Diese werden in einstellbaren Intervallen an den Webserver gesendet. Er kann sich im Pairing-Modus mit neuen SensorStations verbinden.
|
|
|
|
|
|
|
|
**SensorStation:**
|
|
|
|
Eine SensorStation beinhaltet eine Pflanze und mehrere Sensoren. Die Daten dieser Sensoren werden an einen AccessPoint gesendet. Im Falle, dass dieser eine Grenzwert Unter- bzw. Überschreitungen feststellt wird diese über eine RGB-LED ausgegeben.
|
|
|
|
|
|
|
|
|
|
|
|
## 2.2 Use Cases Diagramm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 2.3 Use-Cases
|
|
|
|
## 2.1 Use-Cases
|
|
|
|
|
|
|
|
### 2.3.1 Akteur: User
|
|
|
|
|
| ... | ... | @@ -216,65 +210,93 @@ Eine SensorStation beinhaltet eine Pflanze und mehrere Sensoren. Die Daten diese |
|
|
|
- **Kein Erfolg**: Die Verbindung zwischen AccessPoint und Sensorstation bricht ab und die Daten können nicht geschickt werden. Der AccessPoint meldet die Sensorstation als offline an den Webserver.
|
|
|
|
- **Involvierte Klassen**: Accesspoint, SensorStation
|
|
|
|
|
|
|
|
## 3. Klassendiagramm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Userx-Klasse modelliert den Nutzer auf der Webseite. Er kann bis zu drei Rollen annehmen: USER, GARDENENER und ADMIN. Hat ein Userx die Rolle USER kann er beliebig viele SensorStationen als "UserFavourite" speichern. Userx mit der Rolle GARDENER können beliebig vielen SensorStations zugeteilt sein.
|
|
|
|
|
|
|
|
Die Klasse Accesspoint verwaltet beliebig viele Sensorstationen. Das sendingInterval-Attribut ist jenes Intervall, in dem die SensorDaten übertragen werden soll. Das thresholdInterval-Attribut wird von einem Admin eingestellt und gibt die untere Grenze für das Senden der Sensordaten an. Das wirkliche Sendungsintervall ist also sendingInterval + thresholdInterval. Das Enum AccessPointRole wird für die Kommunikation über HTTP-Basic benötigt.
|
|
|
|
|
|
|
|
Die Entität Sensorstation gehört genau zu einem AccessPoint, hat bis zu einen Gärtner und kann von beliebigen vielen Userx als UserFavourite gespeichert werden. Außerdem hat diese Entität beliebig viele Picture-Entitäten. Weiters gehören zu jeder SensorStation beliebig viele SensorDataTypeInfo-Entitäten und beliebig viele SensorDaten-Entitäten.
|
|
|
|
|
|
|
|
Die SensorDataTypeInfo gehört genau zu einer SensorStation. Sie speichert die min- und max-Limits eines bestimmten Typs von Messwerten.
|
|
|
|
|
|
|
|
# 3. Klassendiagramm
|
|
|
|
Die SensorData-Entität gehört genau zu einer SensorStation. Neben dem Messwert und dem Typ des Messwertes, werden auch noch der Zeitpunkt der Messwertauslesung und die zu dieser Zeit geltenden min- und max-Limits gespeichert.
|
|
|
|
|
|
|
|
|
|
|
|
Die Entität LogInfo stellt den AuditLogger dar. In dieser werden Auslöser, der Zeitpunkt und die Art der Operation gespeichert um später von einem Admin ausgewertet zu werden.
|
|
|
|
|
|
|
|
Die Userx-Klasse modelliert den Nutzer auf der Webseite. Er kann bis zu drei Rollen annehmen. Wenn eine Userx die Rolle USER hat kann er beliebig viele SensorStationen als "UserFavourite" speichern. Userx mit der Rolle Gärtner können keiner oder beliebig vielen SensorStationen zugeteilt sein.
|
|
|
|
## 4. SW-Architektur
|
|
|
|
|
|
|
|
Die Klasse Accesspoint hat beliebig viele Sensorstationen, die dieser verwaltet. Das sendingInterval-Attribut ist jenes Intervall, in dem der Gärtner die Sensordaten erhalten möchte. Das thresholdInterval-Attribut wird von dem Admin eingestellt und gibt die untere Grenze für das Senden der Sensordaten an. Das wirkliche Sendungsinterval ist also sendingInterval + thresholdInterval. Das enum AccessPointRole wird für die Kommunikation über HTTP-Basic benötigt.
|
|
|
|
### 4.1 Komponentendiagramm
|
|
|
|
|
|
|
|
Die Entität Sensorstation gehört genau zu einem AccessPoint, hat einen oder keinen Gärtner und kann von beliebigen vielen Userx mit der Rolle USER als UserFavourite gespeichert werden. Außerdem hat diese Entität beliebig viele Picture-Entitäten. Weiters gehören zu jeder SensorStation beliebig viele SensorDataTypeInfo-Entitäten und beliebig viele SensorDaten-Entitäten.
|
|
|
|
|
|
|
|
|
|
|
|
Die SensorDataTypeInfo gehört genau zu einer SensorStation. Sie speichert die min- und maxLimits eines bestimmten Types von Messwerten.
|
|
|
|
### 4.2 Laufzeitdiagramm
|
|
|
|
|
|
|
|
Die SensorDatan-Entität gehört genau zu einer SensorStation. Neben dem Messwert und dem Typ des Messwertes, werden auch noch der Zeitpunkt der Messwertauslesung und die zu dieser Zeit geltenden min- und maxLimits gespeichert.
|
|
|
|
**Datenübertragung zwischen Webserver, AccessPoint und SensorStation:**
|
|
|
|
|
|
|
|
Die Entität LogInfo stellt den AuditLogger da. In dieser werden Auslöser, der Zeitpunkt und die Art der Operation gespeichert.
|
|
|
|
|
|
|
|
|
|
|
|
# 4. SW-Architektur
|
|
|
|
**Einrichtung der Systeme:**
|
|
|
|
|
|
|
|
## 4.1 Komponentendiagramm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[¹]: https://arc42.org (Zugriff: 17.02.2023)
|
|
|
|
### 4.3 Fachlicher Kontext
|
|
|
|
|
|
|
|
## 4.2 Laufzeitdiagramm
|
|
|
|
**Ablauf Datenübertragung zwischen den Systemen:**
|
|
|
|
Die folgende Abbildung zeigt die wichtigsten Inputs und Outputs von PlantCare - sowohl die menschlichen Nutzer als auch die technische Umgebung
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### 4.4 Technischer Kontext
|
|
|
|
|
|
|
|
**Ablauf Einrichtung der Systeme:**
|
|
|
|
Das technische Kontextdiagramm zeigt die mit dem Webserver verbundenen Kanäle.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# 5. Ausfallsicherheit
|
|
|
|
### 4.5 Lösungsstrategie
|
|
|
|
|
|
|
|
1. Aufbau des Webservers auf dem zur Verfügung gestellten Skelleton-Projekt
|
|
|
|
2. Implementierung der Web-Oberfläche mittels Spring-Boot und Primefaces-Templates
|
|
|
|
3. Realisierung der Datenbank des Webservers mittels mySQL
|
|
|
|
4. Implementierung des AccessPoints mit Python-Code
|
|
|
|
5. Verbindung zwischen Webserver und AccessPoint mittels REST-Controller
|
|
|
|
6. Realisierung der Datenbank des AccessPoints mittels SQLite
|
|
|
|
7. Implementierung Der SensorStation mit C-Code
|
|
|
|
8. Verbindung zwischen SensorStation und AccessPoint mittels Bluetooth LE
|
|
|
|
|
|
|
|
### 4.6 Bausteinsicht
|
|
|
|
|
|
|
|
Im folgenden ist die statische Zerlegung des Systems in Bausteine sowie deren Abhängigkeiten gelistet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 5. Ausfallssicherheit
|
|
|
|
|
|
|
|
**T1: Eingeschränkte Kommunikation zwischen Sensorstationen und AccessPoint**
|
|
|
|
|
|
|
|
**T1: Eingeschränkte Kommunikation zwischen Arduino Sensorstationen und Minirechner**
|
|
|
|
- Daten, die von dem Arduino kommen, werden nicht in die Datenbank aufgenommen, da sie u.U. verfälscht sind
|
|
|
|
- Warten, bis Verbindung besser wird
|
|
|
|
|
|
|
|
**T2: Unerwarteter Neustart eines Minirechners (Raspberry)**
|
|
|
|
- muss gewährleistet sein, dass alle Sensorstationen, die vor dem Neustart verbunden waren, wieder eine Verbindung aufgebaut wird
|
|
|
|
- Skripte zur automatischen Wiederherstellung der Verbindung
|
|
|
|
**T2: Unerwarteter Neustart eines AccessPoint**
|
|
|
|
|
|
|
|
- Die entsprechenden Programme werden bei Start des AccessPoint automatisch gestartet
|
|
|
|
- Alle Sensorstationen, die vor dem Neustart verbunden waren, bauen wieder eine Verbindung auf
|
|
|
|
- Skript zur automatischen Wiederherstellung der Verbindung
|
|
|
|
- Daten, die in dieser Zeit zum Raspberry gesendet wurden, sind verloren
|
|
|
|
|
|
|
|
**T3: Temporärer Ausfall der Kommunikationswege zwischen Minirechnern und zentralem Backend**
|
|
|
|
- Daten (bis zu einem Gewissen Punkt) buffern bis Verbindung wiederhergestellt wurde
|
|
|
|
- automatische Wiederherstellung der Verbindung
|
|
|
|
**T3: Temporärer Ausfall der Kommunikationswege zwischen AccessPoint und Webserver**
|
|
|
|
|
|
|
|
- Daten werden (bis zu einem Gewissen Punkt) gepuffert bis Verbindung wiederhergestellt wurde
|
|
|
|
- Automatische Wiederherstellung der Verbindung
|
|
|
|
|
|
|
|
**T4: Kurzfristiger Ausfall des zentralen Backends**
|
|
|
|
- Benachrichtigung alle Benutzer über den den Ausfall
|
|
|
|
**T4: Ausfall der Sensorstation**
|
|
|
|
|
|
|
|
**T5: Ausfall der Sensorstation**
|
|
|
|
- Verbindung zum AccessPoint ist eingeschränkt, aber Stromversorgung ist vorhanden:
|
|
|
|
optisches und akustisches Signal (blinken)
|
|
|
|
- kompletter Ausfall des Strom:
|
|
|
|
AccessPoint sendet Nachricht an den Webserver, ein Admin sieht diese Fehlermeldung und muss dann die Sensorstation warten und gegebenenfalls neu einrichten.
|
|
|
|
- Verbindung zum AccessPoint ist eingeschränkt, aber Stromversorgung ist vorhanden: optisches und akustisches Signal (blinken)
|
|
|
|
- Kompletter Ausfall: Admin sieht am entsprechenden Dashboard, dass die SensorStation nicht mehr verbunden ist.
|
|
|
|
|
|
|
|
# 6. Ausgewählte Technologien
|
|
|
|
|
|
|
|
## 6. Ausgewählte Technologien
|
|
|
|
|
|
|
|
**Java:**
|
|
|
|
Der Webserver wird mit der objektrelationalen Programmiersprache Java implementiert.
|
| ... | ... | @@ -328,7 +350,7 @@ Primefaces ist ein Framework und erweitert eine JSF-Implementierung. |
|
|
|
**Apache Maven:**
|
|
|
|
Apache Maven ist für das Build-Management zuständig. Mit dieser Technologie werden Java-Programme verwaltet.
|
|
|
|
|
|
|
|
# 7. GUI Prototyp
|
|
|
|
## 7. GUI Prototyp
|
|
|
|
|
|
|
|
**Login-Page für alle Rollen:**
|
|
|
|
|
| ... | ... | @@ -363,9 +385,9 @@ Apache Maven ist für das Build-Management zuständig. Mit dieser Technologie we |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# 8. Projektplan
|
|
|
|
## 8. Projektplan
|
|
|
|
|
|
|
|
## 8.1 Verantwortlichkeiten
|
|
|
|
### 8.1 Verantwortlichkeiten
|
|
|
|
|
|
|
|
**Marco Cotrotzo:**
|
|
|
|
- REST API mit Spring Framework,
|
| ... | ... | @@ -392,22 +414,19 @@ Apache Maven ist für das Build-Management zuständig. Mit dieser Technologie we |
|
|
|
- Testdrehbücher und Abnahmetests
|
|
|
|
- Java Webapp
|
|
|
|
|
|
|
|
## 8.2 Milestones
|
|
|
|
|
|
|
|
- 16. 3 Einrichtung Git-Repository
|
|
|
|
- 16.3 Konzept fertig
|
|
|
|
- 23.3 Implementierung fachliche Komponenten (Models) zwischen Raspberry & Webserver
|
|
|
|
- 23.3 Steckplan fertig
|
|
|
|
- 30.3 REST-Schnittstellen
|
|
|
|
- 6.4 Bluetooth Verbindung zw. Arduino & Raspberry
|
|
|
|
- 20.4 Hardwareaufbau fertig
|
|
|
|
- 10.5 Lauffähiges Projekt
|
|
|
|
- 18.5 Bugfixes & Implementation
|
|
|
|
- 19.5 Lauffähiges Projekt + Präsentation
|
|
|
|
- 24. 5 Bugfixes & Implementation
|
|
|
|
- 25.5 Abnahmetests
|
|
|
|
- 20.6 Bugfixes & Dokumentierung (ARC 42)
|
|
|
|
- 22.6 finale Abgabe + Präsentation
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
### 8.2 Milestones
|
|
|
|
|
|
|
|
- 16.3. Einrichtung Git-Repository
|
|
|
|
- 16.3. Konzept fertig
|
|
|
|
- 23.3. Implementierung fachliche Komponenten (Models) zwischen Raspberry & Webserver
|
|
|
|
- 23.3. Steckplan fertig
|
|
|
|
- 30.3. REST-Schnittstellen
|
|
|
|
- 06.4. Bluetooth Verbindung zw. Arduino & Raspberry
|
|
|
|
- 20.4. Hardwareaufbau fertig
|
|
|
|
- 10.5. Lauffähiges Projekt
|
|
|
|
- 18.5. Bugfixes & Implementation
|
|
|
|
- 19.5. Lauffähiges Projekt + Präsentation
|
|
|
|
- 24.5. Bugfixes & Implementation
|
|
|
|
- 25.5. Abnahmetests
|
|
|
|
- 20.6. Bugfixes & Dokumentierung (ARC 42)
|
|
|
|
- 22.6. finale Abgabe + Präsentation |
|
|
\ No newline at end of file |
