EM2019WSP12/Initiale Anforderungen: Unterschied zwischen den Versionen

Aus Verteilte Systeme - Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „<!-- = Initiale Anforderungen = --> == Initiale Anforderung == Ursprüngliche Aufgabenstellung == Rollen (Stakeholder) == * (R01…“)
 
Zeile 16: Zeile 16:
 
* (Z02) Stufenlose Variation der Töne
 
* (Z02) Stufenlose Variation der Töne
 
* (Z03) Unfallverhütungsmaßnahmen durch z.B. Neigungssensor, Erschütterungssensor, Lichtschranke
 
* (Z03) Unfallverhütungsmaßnahmen durch z.B. Neigungssensor, Erschütterungssensor, Lichtschranke
  +
* (Z04) Nutzung des Systems bei Kunstnebel.
   
 
== Anwendungsfälle ==
 
== Anwendungsfälle ==

Version vom 19. November 2019, 22:01 Uhr


Initiale Anforderung

Ursprüngliche Aufgabenstellung

Rollen (Stakeholder)

  • (R01) Entwickler (Entwickelt ein Gesamtsystem bei dem Laser in festen Intervallen getaktet werden und die Reflektion eines Laserstrahles durch optische Sensoren erfasst wird. Er programmiert einen Mikrocontroller der die erfassten Werte einem Midi Protokoll zuordnet und entwickelt eine Midi Schnittstelle zur Übertragung der Protokolle)
  • (R02) Tester (Testet das System auf Funktion und Sicherheit in Bezug auf den Endanwender)
  • (R03) Endanwender (Musiker, welcher wohldefinierte Töne durch unterbrechen der Laserstrahlen mit seinen Händen erzeugt)

Ziele

  • (Z01) Entwicklung des Instruments, implementierung des Midi-Busses und Abspielen konkreter Oktaven
  • (Z02) Stufenlose Variation der Töne
  • (Z03) Unfallverhütungsmaßnahmen durch z.B. Neigungssensor, Erschütterungssensor, Lichtschranke
  • (Z04) Nutzung des Systems bei Kunstnebel.

Anwendungsfälle

(UC01) Bau der Laserharfe durch R01

Der Entwickler wird zunächst die Laserharfe entwerfen und ein Grundgerüst bauen, an dem Laser, Sensoren, Lichtfilter und Objektiv montiert werden.

Er wird anschließend ein Programm zum zyklischen Ansteuerung der Laserdioden, sowie zur Auswertung der Sensordaten schreiben. Weiter wird er ein Midi Protokoll implementieren und die zur Anbindung an einen Midibus notwendigen Widerstände bauen.

EM2019WSP12 UC01.png

(UC02) Testen des Gesamtsystems auf Funktion und Sicherheit durch R02

Der Tester testet die Permeabilität der Lichtfilter auf die gewünschte Wellenlänge (532 nm).

Weiter testet er den zur Erfassung der Töne definierten Bereich des CCD Sensors. Er testet die Übermittlung der Midi-Protokolle mit einem Keyboard, welches diese Protokolle empfängt und auswertet. Zuletzt testet er Sicherheitskritische Zustände des Systems, die zur Verletzung des Musikers (R03) oder Dritter führen könnten.

EM2019WSP12 UC02.png

(UC03) Musizieren auf der Laserharfe durch R03

Der Musiker erzeugt unterschiedliche Töne durch unterbrechen eines Laserstrahles auf einer variablen Höhe. EM2019WSP12 UC03.png


Aktivitätsdiagramme für Anwendungsfälle

(AD01) Erkennen eines unterbrochenen Laserstrahls (UC03)

Die Laserharfe taktet die einzelnen Laserstrahlen mit einer für das Auge nicht sichtbaren Frequenz permanent durch.

Wird die Hand innerhalb eines gültigen Fensters in einen Strahl gehalten wird ein Großteil des Lichtes reflektiert und vom CCD Sensor erfasst. Nun wird die Information des gerade aktiven Strahls mit der des CCD Sensors kombiniert um das Ereignis einem Midi Protokoll (einem Ton) zu zu ordnen. Schließlich wird das Protokoll über den Midi Bus an ein Angeschlossenes Gerät (Keyboard, Synthesizer oder ähnliches) gesendet, der darauf hin den im Protokoll definierten Ton spielt.

EM2019WSP12 AD01.png

Detaillierte Anforderungen mit zugeordneten Zielen und ggf. Anwendungsfällen

nf = nicht-funktional, f = funktional

  • (A01, nf) Nutzung von BitCloud als Entwicklungsbasis (Z01, Z02)
  • (A02, nf) Realisierung auf WieDAS-Knotenhardware (Z01)
  • (A02a, nf) Beschränkung auf verfügbaren Speicher der Hardware (Z01)
  • (A02b, f) Unterstützung der WieDAS-Knoten-Sensoren (Z03)
  • (A02c, f) Aktoransteuerung von WieDAS-Knoten aus (Z03)(UC01)
  • (A03, nf) Analyse der Kompatibilität von BitCloud mit anderen ZigBee-Umsetzungen (Z02)
  • (A04, f) Konfigurationsmöglichkeit für Knoten- und PAN-Adresse (Z01)(UC02a)
  • (A05, f) Elektrische Anbindung einer Lampe an WieDAS-Knoten (Z03)

...

Tests und Simulation

  • Inbetriebnahme der Hardware
    • WieDAS-Wandknoten (AVR-Mikrocontroller) und AVR Raven
    • ZigBee Sniffer
    • LED Lampe
    • Lüfter
  • Inbetriebnahme der Software
    • deCONZ Simulationssoftware für ZigBee
      • Coordinator
      • Binding
        • (DimmableLight <--> DimmerSwitcher)
      • Security Einstellung
    • BitCloud ZigBee Stack
  • Test der ZigBee-Implementierung (OnOff)
    • Implementierung des DimmableLights aus dem HomeAutomation-Profil (OnOff-Fuktionalität)
    • Simulation des Coordinators mit deCONZ
    • Simulation des DimmerSwitchers mit deCONZ
    • Bindig der ZigBee-Implementierung mit simuliereten Knoten
    • Security Einstellung
    • Simulation der Lampe durch einfache LED
  • Test der ZigBee-Implementierung (Dimmen)
    • Implementierung des DimmableLights aus dem HomeAutomation-Profil (Dimmer-Fuktionalität)
    • Simulation des Coordinators mit deCONZ
    • Simulation des DimmerSwitchers mit deCONZ
    • Bindig der ZigBee-Implementierung mit simuliereten Knoten
    • Security Einstellung
    • Simulation des Dimmens der Lampe durch Debug-Ausgabe
  • Vollständiger Test
    • Vollständige Implementierung des DimmableLight (OnOff- und Dimmer-Funktionalität)
    • Simulation des Coordinators mit deCONZ
    • Simulation des DimmerSwitchers mit deCONZ
    • Bindig der ZigBee-Implementierung mit simuliereten Knoten
    • Security Einstellung
    • Steuerung der LED-Lampe und Lüfters durch Mikrocontroller