132 lines
6.6 KiB
Markdown
132 lines
6.6 KiB
Markdown
# Roadmap
|
||
- [ ] SEND STATUS OF DEVICE OVER UART
|
||
- [ ] CONFIGURE PEERS OVER MASTER
|
||
- [ ] SAVE PIN CONFIG ON PEERS
|
||
|
||
# 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.
|
||
|
||
|