Reliability Engineering WS25/26

Dozent:	Prof. Dr.-Ing. Schneider
Modul	Mechatronik, Systementwicklung (Wahlpflichtprofil „Systems Design Engineering“), Wintersemester
Modulbezeichnung:	MTR-B-2-7.09
Modulverantwortung:	Mirek Göbel
Lehrveranstaltung:	Reliability Engineering
Zeit:	Donnerstag, 08:15 - 09:45 Uhr, uKW
Ort:	Labor L3.3-E01-180 (Autonome Systeme)
SVN-URL:	https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Reliability_Engineering/WS25/

Beispielartikel

• Simulation der Kinematik eines Fahrzeugs mit drei Rädern
• Kartierung in Matlab/Simulink
• Beispiel: berechneEntfernungPunktGerade.m

Die gewünschten Themenabschnitte sind:

Einleitung

• Autor
• Bild

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

Anforderungen

Formulierungsregeln für Anforderungen

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

1. Allgemeine Beschreibung: Name der Komponente, Zweck/Ziel der Komponente, Zugehörigkeit zu einem System oder Modul
2. Funktionale Anforderungen: Welche Aufgaben die Komponente erfüllt, Algorithmen oder Logik, falls relevant
3. Schnittstellenbeschreibung: unktionen oder Methoden, die bereitgestellt werden, Input-Parameter und Rückgabewerte, Events, Nachrichten oder APIs
4. Nicht-funktionale Anforderungen: Performance (z. B. Reaktionszeit), Zuverlässigkeit, Fehlertoleranz, Speicher- oder Ressourcenverbrauch
5. Abhängigkeiten: Andere Software-Module oder Bibliotheken, die benötigt werden
6. Test- und Validierungshinweise: Welche Tests durchgeführt werden müssen, um die Spezifikation zu erfüllen
7. Versionierung und Änderungen: Wer hat die Spezifikation erstellt, Änderungen im Laufe der Zeit

Beispiel einer Komponentenspezifikation 

Software-Komponentenspezifikation: Temperaturmessung

Version:	1.0
Autor:	Max Mustermann
Datum:	22.10.2025
System:	Arduino-basiertes Sensormodul

1. Allgemeine Beschreibung

• Zweck: Die Komponente liest periodisch die Temperatur eines Sensors aus und liefert einen kalibrierten Temperaturwert in Grad Celsius.
• Zugehörigkeit: Teil des Sensor-Moduls für Umweltmessungen.

2. Funktionale Anforderungen

Anforderung	Beschreibung
F1	Temperaturmessung am analogen Pin A0
F2	Rückgabe des Messwerts als float in °C
F3	Abtastintervall: alle 500 ms
F4	Kalibrierung: Offset-Korrektur ±2 °C möglich

3. Schnittstellenbeschreibung (Interface)

Schnittstelle	Typ	Beschreibung
float readTemperature()	Methode	Gibt aktuellen Temperaturwert zurück
void setCalibrationOffset(float offset)	Methode	Setzt Offset zur Kalibrierung
Pin A0	Hardware-Pin	Eingang für Sensorsignal

Input: Analoger Wert vom Sensor Output: Temperaturwert als float

4. Nicht-funktionale Anforderungen

Anforderung	Wert / Beschreibung
Genauigkeit	±0,5 °C
Reaktionszeit	max. 500 ms
Ressourcenverbrauch	max. 2 kB RAM, <5 % CPU bei 16 MHz Arduino
Zuverlässigkeit	Messungen stabil, keine Fehlwerte >0,1 %

5. Abhängigkeiten

• Arduino Standard Libraries (`Arduino.h`)
• Sensor-Treiber-Bibliothek (falls extern)
• Stromversorgung stabil: 5 V ±5 %

6. Test- und Validierungshinweise

1. Funktionstest: Sensorwerte mit Referenzthermometer vergleichen.
2. Grenzwerttest: Prüfen bei extremen Temperaturen (-10 °C bis +50 °C).
3. Lasttest: Messung über 24 h prüfen, auf Stabilität und Drift.
4. Fehlerfall: Sensor ausgesteckt → Komponente gibt Fehlerwert oder NaN zurück.

7. Änderungen / Versionierung

Version	Datum	Änderung	Autor
1.0	22.10.2025	Erstversion	Max Mustermann
1.1	TBD	Hinzufügen Logging-Funktion	TBD

Komponententest

Ziel: Fehler früh erkennen und vermeiden, maximale Testabdeckung.

Modultest	Jede Funktion wird isoliert geprüft Fehlerfälle, Randbedingungen, Grenzwerte
Integrationstest	Zusammenspiel mit anderen Komponenten Schnittstellen-Fehler, Timing-Probleme
Stress-/Lasttest	Hohe Frequenzen, große Datenmengen Überprüfen, ob die Komponente unter extremen Bedingungen stabil bleibt
Recovery-Test	Simulieren von Ausfällen (Sensorfehler, Kommunikationsfehler) Prüfen, ob Fehler korrekt behandelt werden
Code Review & statische Analyse	Code auf potenzielle Bugs, Memory-Leaks, Race-Conditions prüfen
Reliability Metrics	MTBF (Mean Time Between Failures) schätzen Fehlerrate pro 1.000 Transaktionen messen

Dokumentation: Testprotokolle & Ergebnisse: Unit-, Integration-, Stress-Tests

Aufgabe 1 - Artikel-Review

1. Begutachten Sie einen fertigen Artikel.
2. Geben Sie Feedback auf der Diskussionsseite.
3. Wir besprechen das Feedback im Plenum.

Aufgabe 2 - Code Review

1. 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/
2. Optimieren Sie Ihren Quelltext anhand des Code Reviews.
3. Besprechen Sie das Ergebnis mit Prof. Schneider.

Quellcode

• berechneMittellinie.m
• trackePrisma.m

Tutorials

• Anleitung_zum_Code_Review
• SVN: Code_Review_Vorlage.docx
• Regeln für Simulink-Modelle
• Was ist ein Plagiat?
• Was ist ein PAP?
• Programmierrichtlinien für MATLAB
• Programmierrichtlinie für C

Aufgabe 3 - Modultest

1. Studieren Sie das Video Erste Schritte mit dem MATLAB Unit Test Framework.
2. Weitere Informationen finden Sie im Artikel Ways to Write Unit Tests.
3. Besuchen Sie den Online-Kurs Unit Testing
4. Lassen Sie sich vom Copilot helfen einen Test zu generieren.

MATLAB Test features

• Generate Test with Copilot

Tabelle 1: Liste von Testfällen inkl. genauer Testfallbeschreibung

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

Bonus

• C-Code Generierung mit MATLAB.
• Test von C-Code mit MATLAB

---

→ zurück zum Hauptartikel: MTR SDE Praktikum WS 2025/26