Reliability Engineering WS25/26: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
| Zeile 142: | Zeile 142: | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| Modul Tests || | | '''Modul Tests''' || | ||
*Jede Funktion wird isoliert geprüft | *Jede Funktion wird isoliert geprüft | ||
*Fehlerfälle, Randbedingungen, Grenzwerte | *Fehlerfälle, Randbedingungen, Grenzwerte | ||
|- | |- | ||
| Integrationstests|| | | '''Integrationstests'''|| | ||
*Zusammenspiel mit anderen Komponenten | *Zusammenspiel mit anderen Komponenten | ||
*Schnittstellen-Fehler, Timing-Probleme | *Schnittstellen-Fehler, Timing-Probleme | ||
| Zeile 158: | Zeile 158: | ||
*Prüfen, ob Fehler korrekt behandelt werden | *Prüfen, ob Fehler korrekt behandelt werden | ||
|- | |- | ||
| Code-Review & statische Analyse || Code auf potenzielle Bugs, Memory-Leaks, Race-Conditions prüfen | | '''Code-Review & statische Analyse''' || Code auf potenzielle Bugs, Memory-Leaks, Race-Conditions prüfen | ||
|- | |- | ||
| Reliability Metrics || | | Reliability Metrics || | ||
Version vom 22. Oktober 2025, 13:52 Uhr
| Dozent: | Prof. Dr.-Ing. Schneider |
| Modul | Systementwicklung (Wahlpflichtprofil „Systems Design Engineering“), Wintersemester |
| Modulbezeichnung: | MTR-B-2-7.09 |
| Modulverantwortung: | Mirek Göbel |
| Lehrveranstaltung: | Sensortechnik |
Beispielartikel
Die gewünschten Themenabschnitte sind:
Einleitung
- Autor
- Bild
Anforderungen
Funktionaler Systementwurf
Der funktionale Entwurf beschreibt was das System tun soll, ohne sich darum zu kümmern, wie es technisch umgesetzt wird.
- Fokus: Funktionen, Prozesse, Abläufe
- Ziel: Alle Anforderungen aus der Spezifikation in funktionale Bausteine zerlegen
- Sprache/Tools: Funktionsdiagramme, Use Cases, Blockdiagramme, Datenflussdiagramme
Tipp: Hier geht es nur darum, dass die Funktion existiert, nicht wie der Sensor angeschlossen wird oder welcher Pin verwendet wird.
Technischer Systementwurf
Definition: Der technische Entwurf beschreibt wie das System umgesetzt wird, also die konkrete technische Lösung.
- Fokus: Hardware, Softwarearchitektur, Bauteile, Schnittstellen
- Ziel: Umsetzung des funktionalen Entwurfs in physische oder softwaretechnische Komponenten
- Sprache/Tools: Schaltpläne, Hardware-Blockdiagramme, Klassendiagramme, PCB-Layout, Algorithmen
Komponentenspezifikation
Eine Komponentenspezifikation ist im Ingenieurwesen und in der Elektronik eine detaillierte Beschreibung eines Bauteils, die festlegt, wie es aufgebaut ist, welche Eigenschaften es haben muss und wie es betrieben werden darf. Sie dient dazu, sicherzustellen, dass die Komponente für eine bestimmte Anwendung geeignet ist und zuverlässig funktioniert.
Zweck einer Software-Komponentenspezifikation
- Definiert Funktionalität: Welche Aufgaben erfüllt die Komponente?
- Beschreibt Schnittstellen: Welche Inputs und Outputs gibt es?
- Legt Nicht-Funktionale Anforderungen fest: Performance, Sicherheit, Zuverlässigkeit.
- Hilft bei Entwurf, Implementierung und Test: Entwickler und Tester wissen genau, was erwartet wird.
Inhalte einer Komponentenspezifikation
- Allgemeine Beschreibung: Name der Komponente, Zweck/Ziel der Komponente, Zugehörigkeit zu einem System oder Modul
- Funktionale Anforderungen: Welche Aufgaben die Komponente erfüllt, Algorithmen oder Logik, falls relevant
- Schnittstellenbeschreibung: unktionen oder Methoden, die bereitgestellt werden, Input-Parameter und Rückgabewerte, Events, Nachrichten oder APIs
- Nicht-funktionale Anforderungen: Performance (z. B. Reaktionszeit), Zuverlässigkeit, Fehlertoleranz, Speicher- oder Ressourcenverbrauch
- Abhängigkeiten: Andere Software-Module oder Bibliotheken, die benötigt werden
- Test- und Validierungshinweise: Welche Tests durchgeführt werden müssen, um die Spezifikation zu erfüllen
- Versionierung und Änderungen: Wer hat die Spezifikation erstellt, Änderungen im Laufe der Zeit
| Beispiel einer Komponentenspezifikation | ||||||||||||||||||||||||||||||||||||||||||||||||||||
Software-Komponentenspezifikation: Temperaturmessung
1. Allgemeine Beschreibung
2. Funktionale Anforderungen
3. Schnittstellenbeschreibung (Interface)
Input: Analoger Wert vom Sensor Output: Temperaturwert als float 4. Nicht-funktionale Anforderungen
5. Abhängigkeiten
6. Test- und Validierungshinweise
7. Änderungen / Versionierung
|
Programmierung
Komponententest
Ziel: Fehler früh erkennen und vermeiden, maximale Testabdeckung.
| Modul Tests |
|
| Integrationstests |
|
| Stress- / Lasttests |
|
| Recovery-Tests |
|
| Code-Review & statische Analyse | Code auf potenzielle Bugs, Memory-Leaks, Race-Conditions prüfen |
| Reliability Metrics |
|
Dokumentation: Testprotokolle & Ergebnisse: Unit-, Integration-, Stress-Tests
Zusammenfassung
Link zum Quelltext in SVN
Literaturverzeichnis
Aufgabe 1 - Artikel-Review
- Begutachten Sie einen fertigen Artikel.
- Geben Sie Feedback auf der Diskussionsseite.
- Wir besprechen das Feedback im Plenum.
Aufgabe 2 - Code Review
- Führen Sie das Review anhand der Vorlage durch und dokumentieren Sie es hier:
https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Testdokumente/CodeReviews/ - Optimieren Sie Ihren Quelltext anhand des Code Reviews.
- Besprechen Sie bis zur Deadline 20.12.19 das Ergebnis mit Prof. Schneider.
Tutorials
Aufgabe 3 - Modultest
| ID des Testfalls | Testfallname | Ersteller | Datum | ID der Anforderung | ID aus der Komponenntenspezifikation | Ausgangszustand | Aktion(en) | Erwartetes Ergebnis | Ergebnis | Bewertung | Test durchgeführt von | Test durchgeführt am | Bemerkung |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 01 | Stationären Endwert und damit den Verstärkungsfaktor prüfen | Prof. Schneider | 22.10.25 | 01 | 05 | PT1-Integratoren = 0, Eingang = 0 | Eingangssprung von 0 auf 1 bei t=0s | Stat. Endwert = 1 | xa(t=50s) = 1.4 | n.i.O. | Mustermann | 22.10.25 | Kp überprüfen |
| 02 | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel |
| 03 | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel | Beispiel |