Added Lastenheft as Readme
This commit is contained in:
parent
3e7c842597
commit
871bc4876e
126
readme.md
Normal file
126
readme.md
Normal file
@ -0,0 +1,126 @@
|
|||||||
|
# Machbarkeits-Studie
|
||||||
|
|
||||||
|
## 1.0 Hardware-Features
|
||||||
|
|
||||||
|
### 1.1 Hardware-Aufbau
|
||||||
|
Anforderung
|
||||||
|
Es soll eine Hardware von 20 Modulen bereitgestellt werden, welche als Basis der
|
||||||
|
grundlegenden Software-Features dient. Dabei liegt der Fokus auf der Verarbeitung von
|
||||||
|
Wifi-Nachrichten und weniger auf deren Hardware-technischen Umsetzung.
|
||||||
|
Lösungsansatz
|
||||||
|
Die Hardware besteht aus 20 ESP32-Modulen (1x Koordinator und 19 Peers) und der
|
||||||
|
entsprechenden Energieversorgung: 20x Stecker-Netzteil + USB-Leitungen
|
||||||
|
Abnahme-Kriterium
|
||||||
|
Alle Peers sind so mit Energie zu versorgen, dass sie sich in einem Radius von ca. 15m um
|
||||||
|
den versorgten Koordinator befinden.
|
||||||
|
Dokumentation
|
||||||
|
Es wird per Liste festgehalten, welches ESP32-Board benutzt wird und ob Modifikationen
|
||||||
|
bei der Spannungsversorgung (bspw. Elko an 3.3V) vorgenommen wurden.
|
||||||
|
|
||||||
|
## 2.0 Software-Features
|
||||||
|
|
||||||
|
### 2.1 Netzwerk-Aufbau
|
||||||
|
Anforderung
|
||||||
|
Das Netzwerk soll sich nach einem Power-On selbständig aufbauen und eine Teilnehmer-
|
||||||
|
Liste nach abgeschlossener Initialisierung bereitstellen.
|
||||||
|
Lösungsansatz
|
||||||
|
Der Koordinator erstellt ein MAC-Netzwerk und fügt die Peers in das Netzwerk hinzu.
|
||||||
|
Zusätzlich erstellt der Koordinator eine Liste von MAC-Adressen der Peers.
|
||||||
|
Abnahme-Kriterium
|
||||||
|
Dieses Feature wird per Systemtest verifiziert. Der Test startet den Netzwerk-Aufbau auf
|
||||||
|
dem Koordinator per Terminal-Kommando und gibt nach 5 Minuten die MAC-Adressen-
|
||||||
|
Liste zurück.
|
||||||
|
Dokumentation
|
||||||
|
Der Netzwerk-Aufbau wird per Ablauf-Diagramm dokumentiert.
|
||||||
|
|
||||||
|
### 2.2 PingPong-Feature
|
||||||
|
Anforderung
|
||||||
|
Nach dem Netzwerk-Aufbau soll jeder Peer durch den Koordinator ein Ping erhalten,
|
||||||
|
welchen dieser umgehend mit einem Pong (bzw. mit seiner Firmware-Version)
|
||||||
|
beantwortet. Sollte ein Teilnehmer auf die Anfrage nicht reagieren, soll die Anfrage sofort
|
||||||
|
wiederholt werden. Die benötigte Zeit und die Anzahl der Wiederholungen soll erfasst
|
||||||
|
werden.
|
||||||
|
ALOX Labs UG Lastenheft Pflichtenheft PowerPods 4
|
||||||
|
Lösungsansatz
|
||||||
|
Der Koordinator sendet an die hinterlegten MAC-Adressen jeweils den Ping-Befehl und
|
||||||
|
erwartet die Pong-Antwort (Firmware-Version) des jeweiligen Peers. Sollte ein Teilnehmer
|
||||||
|
nicht antworten wird die Nachricht nach 10ms wiederholt – maximale Wiederholung: 5x.
|
||||||
|
Die Zeit (Start: vor der Sendung – Stopp: nach dem Empfang) wird im Koordinator erfasst.
|
||||||
|
Abnahme-Kriterium
|
||||||
|
Dieses Feature wird per Systemtest verifiziert. Der Test startet das PingPong-Feature mit
|
||||||
|
einer erwarteten Firmware-Version und bekommt als Resultat eine Liste mit dem Status
|
||||||
|
der Firmware, der Dauer und den benötigten Versuchen pro Peer zurück.
|
||||||
|
Dokumentation
|
||||||
|
Das PingPong-Feature wird per Ablauf-Diagramm dokumentiert.
|
||||||
|
|
||||||
|
### 2.3 PingPong-Feature im definierten Raster
|
||||||
|
Anforderung
|
||||||
|
Es soll sichergestellt werden, dass die Dauer der Peer-Abfrage immer im gleichen zeitlichen
|
||||||
|
Raster stattfindet. Dies soll unabhängig von den Teilnehmern des Netzwerks sein und sich
|
||||||
|
an der Maximalen Anzahl der Teilnehmer richten. Dadurch soll sichergestellt werden, dass
|
||||||
|
die Performance bei 5 Teilnehmern sich genauso verhält wie bei 19 Teilnehmern.
|
||||||
|
Lösungsansatz
|
||||||
|
Der Koordinator sendet an die hinterlegten MAC-Adressen jeweils den Ping-Befehl in
|
||||||
|
einem vor-definierten zeitlichen Raster. Das Raster richtet sich an die in Pos. 2.2
|
||||||
|
gemachten Ergebnisse, wo die maximale Dauer einen PingPongs bestimmt wird.
|
||||||
|
Die menschl. Reaktionszeit beträgt ca. 250ms. Die maximale Abfrage-Zeit sollte unterhalb
|
||||||
|
von 200ms (bestenfalls bei 125ms) liegen um ein flüssigen Spielablauf zu gewährleisten.
|
||||||
|
- 19 Teilnehmer mit 125ms: 5ms Raster + 3 Wiederholungen (5ms + 5ms)
|
||||||
|
- 19 Teilnehmer mit 200ms: 8ms Raster + 3 Wiederholungen (8ms + 8ms)
|
||||||
|
Abnahme-Kriterium
|
||||||
|
Dieses Feature wird per Systemtest verifiziert. Der Test startet das PingPong-Feature im
|
||||||
|
vor-definierten Raster und bekommt als Resultat eine Liste mit der jeweiligen Dauer, den
|
||||||
|
benötigten Versuchen und einer Rückmeldung, ob das Raster eingehalten wurde zurück.
|
||||||
|
Dokumentation
|
||||||
|
Das PingPong-Feature im definierten Raster wird per Ablauf-Diagramm dokumentiert
|
||||||
|
|
||||||
|
### 2.4 Broadcast-Message
|
||||||
|
Anforderung
|
||||||
|
Der Koordinator soll nicht nur die Peers einzeln per MAC-Adresse, sondern auch per
|
||||||
|
globaler Nachricht direkt an alle Peers eine Nachricht versenden können.
|
||||||
|
Lösungsansatz
|
||||||
|
Durch eine spezielle Nachricht, die an alle Peers gerichtet ist, können Nachrichten per
|
||||||
|
Broadcast vom Koordinator an alle Peers versendet werden. Eine Rückmeldung der Peers
|
||||||
|
wird nicht erwartet.
|
||||||
|
ALOX Labs UG Lastenheft Pflichtenheft PowerPods 5
|
||||||
|
Hinweis
|
||||||
|
Der erfolgreiche Abschluss der Machbarkeitsstudie soll mit den aufgeführten Punkten erreicht werden.
|
||||||
|
Nach dem Abschluss soll der Status soweit sein, um mit der Produkt-Entwicklung starten zu können.
|
||||||
|
Im Rahmen der Entwicklung wird (wenn nicht anders im Unterpunkt beschrieben) immer davon
|
||||||
|
ausgegangen, dass Funktionen und Übertragungen korrekt funktionieren – sprich, es wird der Gut-Fall
|
||||||
|
abgedeckt. Sollten trotz dieser Erwartung Fehler während oder nach der Inbetriebnahme stattfinden,
|
||||||
|
werden diese nachträglich behoben.
|
||||||
|
Abnahme-Kriterium
|
||||||
|
Die Broadcast-Message wird über einen Systemtest verifiziert. Dabei wird der Test per
|
||||||
|
Terminal-Kommando gestartet und an alle Peers eine globale Nachricht mit einem Wert
|
||||||
|
gesendet. Diesen Wert fragt der Koordinator per modifiziertem PingPong (Wert statt
|
||||||
|
Firmware-Version) im zweiten Schritt ab.
|
||||||
|
Dokumentation
|
||||||
|
Der Systemtest zur Broadcast-Nachricht wird per Ablauf-Diagramm dokumentiert.
|
||||||
|
|
||||||
|
### 2.5 OTA-Update
|
||||||
|
Anforderung
|
||||||
|
Die Peers sollen vom Koordinator eine neue Firmware per Funk übertragen bekommen, so
|
||||||
|
dass eine händische Programmierung der Module nicht notwendig ist.
|
||||||
|
Lösungsansatz
|
||||||
|
Der Koordinator prüft nach jedem Neustart des Netzwerks, ob die Teilnehmer die korrekte
|
||||||
|
Firmware besitzen. Wenn dies nicht der Fall ist, wird die aktuelle Firmware übertragen.
|
||||||
|
Abnahme-Kriterium
|
||||||
|
Das OTA-Update wird über einen Systemtest verifiziert. Dabei wird der Test per Terminal-
|
||||||
|
Kommando gestartet und an alle Peers die neue Firmware übertragen. Mit einem
|
||||||
|
nachträglichen PingPong wird im zweiten Schritt die neue Version der Peers abgefragt.
|
||||||
|
Dokumentation
|
||||||
|
Der Integrationstest zum OTA-Update wird per Ablauf-Diagramm dokumentiert.
|
||||||
|
|
||||||
|
## 3.0 Abschlussbericht
|
||||||
|
|
||||||
|
### 3.1 Nach erfolgreicher Implementierung der beschriebenen Features soll ein
|
||||||
|
aussagekräftiger Abschlussbericht erstellt werden. Darin sollen die gemachten Ergebnisse
|
||||||
|
und Erkenntnisse kurz dargestellt werden. Dieser Bericht dient dann als Grundlage für
|
||||||
|
das Lasten- und Pflichtenheft der Produktentwicklung und gibt einen Ausblick, ob sich die
|
||||||
|
techn. Anforderungen hinreichend gut umsetzen lassen.
|
||||||
|
|
||||||
|
### 3.2 Eine tabellarische Auflistung, welche der aufgeführten Features wie umgesetzt wurden
|
||||||
|
und ob diese den ursprünglichen Anforderungen entsprechen.
|
||||||
|
|
||||||
|
|
||||||
Loading…
x
Reference in New Issue
Block a user