(WS19-01)Wetterballon Design: Unterschied zwischen den Versionen

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche
(Design)
(Beginn der Dokumentation des Softwaredesigns)
Zeile 41: Zeile 41:
  
 
[[Datei:HW Architecture.png]]
 
[[Datei:HW Architecture.png]]
 +
 +
===Software-Architektur===
 +
Für die Software-Architektur stellte sich die Frage, wie die unterschiedlichen Messzyklen der Sensoren am besten zu realisieren sind. Dazu gab es hauptsächlich zwei Vorschläge.
 +
 +
====Threads====
 +
Eine Implementierung mit Threads bietet den Vorteil, dass jeder Sensor autonom läuft, also auch in keiner Weise von den anderen Sensoren abhängig ist. Jeder Sensor muss nur eine <code>run<code>-Methode implementieren, die vom Master gestartet wird. Der Zugriff auf den Bus kann per Mutex synchronisiert werden. Beim Wechsel des Moduses kann der Master dann jeden Thread beenden.
 +
 +
Die Nachteile dieser Methode sind größtenteils erst nach einer Probeimplementierung aufgefallen. Dazu zählen neben der ohnehin höheren Komplexität paralleler Programme, dass die Abgrenzung der Sensoren untereinander auch dazu führt, dass sie auch vom Master weitestgehend entkoppelt sind. Das ist vor allem im Bezug auf Live-Datenauswertung ei Problem, da ein spezieller Sensor keinen simplen Weg hat, mit dem Master zu kommunizieren. Des weiteren führt die Anforderung der Unterbrechbarkeit in Verbindung mit der Synchronisierung per Mutex zum Problem von Race-Conditions, die, wenn nicht korrekt vorgebeugt, das komplette Programm lahmlegen könnten.
 +
 +
Aus diesen Gründen wurde sich gegen die Implementierung mit Threads entschieden.
 +
 +
====Monolithisch====
 +
Eine monolithische Implementierung als eine einzige Hauptfunktion, die alle Sensoren und andere Funktionalitäten, wie das Schreiben der Daten in Dateien, überwacht, sah zunächst nach einem uneleganteren Weg aus, da ihr Hauptvorteil nur die einfachere Programmierung im Gegensatz zu Threads zu sein schien.
  
 
===Komponentenentwurf===
 
===Komponentenentwurf===

Version vom 20. Dezember 2019, 12:32 Uhr

Design

Verbaut werden folgende Sensoren:

Messung Anzahl Name Standardadresse Erfassungsrate Bemerkung
Temperatur innen 1 Grove High Accuracy Temperature Sensor 0x18
Temperatur außen 1 TMP 117 Breakout 0x48
Luftfeuchtigkeit außen 2 SHT 31 0x44
Luftfeuchtigkeit innen 1 SHT 31 0x44
Luftdruck 3 MS5611 0x76
9-Achsen 1 IMU 10DOF mit MPU-9250 & BME280 0x68/0x69
Helligkeit 1 Si1145 0x60
UV-A und UV-B 1 ML8511
Kamera Bild 1
Kamera Video 1
GPS 1
LoRaWAN 1
Buzzer 2

Problem:

Bei den vorhandenen Sensoren sind wir auf kleinere Probleme gestoßen. Alle Sensoren sind bis zu einer Minimaltemperatur von -40°C funktionsfähig. Auf dem Flug werden diese allerdings deutlich unterschritten. Wir haben uns dennoch für den Einsatz dieser Sensoren entschieden, da auf dem Markt keine geeignerten Sensoren zu finden waren. Um Messungenauigkeiten oder gar Ausfälle zu kompensieren, werden wir die Sensoren für den Außeneinsatz mehrfach verbauen. Dabei kann es zu Adresskonflikten der einzelnen Sensoren kommen. Eine Lösung dafür steht noch aus.

Hardware-Architektur

Eine Skizze der von uns verfolgten Hardwarearchitektur:

HW Architecture.png

Software-Architektur

Für die Software-Architektur stellte sich die Frage, wie die unterschiedlichen Messzyklen der Sensoren am besten zu realisieren sind. Dazu gab es hauptsächlich zwei Vorschläge.

Threads

Eine Implementierung mit Threads bietet den Vorteil, dass jeder Sensor autonom läuft, also auch in keiner Weise von den anderen Sensoren abhängig ist. Jeder Sensor muss nur eine run<code>-Methode implementieren, die vom Master gestartet wird. Der Zugriff auf den Bus kann per Mutex synchronisiert werden. Beim Wechsel des Moduses kann der Master dann jeden Thread beenden.

Die Nachteile dieser Methode sind größtenteils erst nach einer Probeimplementierung aufgefallen. Dazu zählen neben der ohnehin höheren Komplexität paralleler Programme, dass die Abgrenzung der Sensoren untereinander auch dazu führt, dass sie auch vom Master weitestgehend entkoppelt sind. Das ist vor allem im Bezug auf Live-Datenauswertung ei Problem, da ein spezieller Sensor keinen simplen Weg hat, mit dem Master zu kommunizieren. Des weiteren führt die Anforderung der Unterbrechbarkeit in Verbindung mit der Synchronisierung per Mutex zum Problem von Race-Conditions, die, wenn nicht korrekt vorgebeugt, das komplette Programm lahmlegen könnten.

Aus diesen Gründen wurde sich gegen die Implementierung mit Threads entschieden.

Monolithisch

Eine monolithische Implementierung als eine einzige Hauptfunktion, die alle Sensoren und andere Funktionalitäten, wie das Schreiben der Daten in Dateien, überwacht, sah zunächst nach einem uneleganteren Weg aus, da ihr Hauptvorteil nur die einfachere Programmierung im Gegensatz zu Threads zu sein schien.

Komponentenentwurf

Komponentendiagramm.jpg