Initial commit: demo-epb v1.0 — Elektrische Parkbremse Demo

Vollstaendige Demo des slohmaier Dev Process anhand einer EPB-Steuergeraet- Software. Zeigt ASPICE 4.0 / ISO 26262-konforme Entwicklung im Monorepo. Inhalte: - 5 Plaene (PID, PM-, QA-, SWE-, Test-Plan) in Word, ausgefuellt mit EPB-spezifischen Inhalten - 10 System-Anforderungen + 25 Software-Anforderungen (Doorstop-MD) - 5 System-Architektur-Elemente + 10 Software-Architektur-Elemente mit PlantUML-Diagrammen und vollstaendigem Mapping - 3 implementierte Komponenten (Apply Controller D, Actuator Driver B, Switch Debouncer QM) plus 7 Header-Stubs - 28 Unit-Tests, alle gruen, mit Coverage- und MISRA-Build-Targets - Audit-Artefakte: 1 Review-Protokoll, 1 Non-Conformity, 1 MISRA-Record - Gitea-Actions-CI-Pipeline (validate.yml) - Doorstop-Konfiguration fuer bidirektionale Traceability - Generator-Skript fuer alle 50 Reqs/Arch-Elemente aus Strukturdaten - README mit gefuehrter Tour fuer Prospects
2026-05-11 13:51:02 -07:00
commit 1855162e6d
92 changed files with 4116 additions and 0 deletions
@@ -0,0 +1,60 @@
+---
+nc-id: NC-001
+projekt: demo-epb
+datum-festgestellt: 2026-05-11
+schwere: Critical
+status: Closed
+---
+
+# Non-Conformity NC-001: Step-Counter-Ueberlauf nicht dokumentiert
+
+| Feld                | Wert                              |
+|---------------------|-----------------------------------|
+| NC-ID               | NC-001                            |
+| Projekt             | demo-epb                          |
+| Datum festgestellt  | 2026-05-11                        |
+| Festgestellt durch  | Review REV-001                    |
+| Betroffenes Artefakt| `src/apply_controller.c`          |
+| Anforderung         | SWE-002 (Watchdog)                |
+| Schwere             | Critical                          |
+| Status              | Closed                            |
+
+---
+
+## 1. Beschreibung
+
+Der `step_count` im Apply-Controller ist als `uint32_t` deklariert und wird in
+`apply_ctrl_step_50ms` monoton inkrementiert. Bei 50 ms/Tick ueberlaeuft der
+Zaehler nach 2^32 * 50 ms ~= 6.8 Jahren. Der Watchdog in SWA-002 vergleicht
+zwar nur das Delta zwischen zwei Lese-Zugriffen (Wrap-Around unkritisch), aber
+das Verhalten ist nicht im Header dokumentiert und kann bei nachfolgender
+Code-Pflege Fehler erzeugen.
+
+## 2. Risikobewertung
+
+| Aspekt            | Bewertung                                                     |
+|-------------------|----------------------------------------------------------------|
+| Auswirkung        | Theoretisch Watchdog-False-Negative bei Wrap-Around-Vergleich  |
+| Eintritts-Wahrscheinlichkeit | Sehr niedrig (6.8 Jahre Lebensdauer)                |
+| Sicherheits-Beitrag | Indirekt — Watchdog ist Teil der SG-01 Implementierung       |
+
+## 3. Sofortmassnahme
+
+Header-Kommentar in `apply_controller.h` ergaenzt: explizite Beschreibung des
+Wrap-Around-Verhaltens. Watchdog-Implementierung (in SWA-001) muss Delta-
+Vergleich mit `uint32_t` Subtraktion verwenden (Wrap-safe).
+
+## 4. Korrekturmassnahme (Root-Cause)
+
+Im Code-Review-Checklisten-Eintrag "Integer-Ueberlauf-Verhalten dokumentieren"
+ergaenzen. Pruefung in folgenden Reviews.
+
+## 5. Verifikation
+
+- Kommentar in `apply_controller.h` v1.1 (Commit `<hash>`)
+- Watchdog in SWA-001 verwendet `uint32_t`-Subtraktion (siehe SWA-001 §4)
+- Review-Checkliste aktualisiert
+
+## 6. Abschluss
+
+Geschlossen am 2026-05-11 durch S. Lohmaier nach Verifikation.
@@ -0,0 +1,107 @@
+# Project Initiation Document (PID)
+
+| Feld            | Wert                                |
+|-----------------|--------------------------------------|
+| Projekt         | demo-epb (Elektrische Parkbremse)   |
+| Projekt-ID      | SLM-EPB-001                          |
+| Auftraggeber    | slohmaier.com (Demo-Eigenentwicklung)|
+| Auftragnehmer   | Stefan Lohmaier                      |
+| Datum           | 2026-05-11                           |
+| Version         | 1.0                                  |
+| Status          | Freigegeben                          |
+| Klassifikation  | Oeffentlich                          |
+
+---
+
+## 1. Projektzweck
+
+Demonstration des slohmaier Dev Process anhand einer EPB-Steuergeraet-Software. Ziel ist nicht die produktive Software, sondern der vollstaendige Nachweis von:
+
+- ASPICE-4.0-konformer Entwicklungsablauf
+- ISO-26262-konforme Behandlung von Sicherheitsanforderungen (ASIL-D / ASIL-B / QM)
+- MISRA-C-Compliance
+- Werkzeugkette: Gitea + Doorstop + Cppcheck + gcov + CppUTest + pandoc
+
+Adressat ist potenzielle Kundschaft, die sehen will, wie ein realer Audit-faehiger Engineering-Stand aussieht.
+
+## 2. Produktbeschreibung
+
+Eine Electronic Parking Brake (EPB) klemmt im Stillstand zwei Bremssaettel ueber kleine Elektromotoren fest und loest sie bei Anfahrt wieder. Funktionsumfang:
+
+- Apply / Release auf Fahrer-Anforderung
+- Hold-Funktion mit Auto-Apply bei Motor-Aus
+- Drive-Away-Assist (Auto-Release beim Anfahren)
+- Hill-Hold am Berg
+- Aktor-Stromueberwachung
+- Service-Modus fuer Werkstatt
+- UDS-Diagnose ueber CAN
+
+## 3. Sicherheitsziele
+
+| ID    | Sicherheitsziel                                              | ASIL |
+|-------|---------------------------------------------------------------|------|
+| SG-01 | Verhinderung ungewollten Wegrollens des Fahrzeugs             | D    |
+| SG-02 | Verhinderung ungewollten Loesens der Parkbremse               | D    |
+| SG-03 | Verhinderung Motorschaden durch Ueberlast                     | B    |
+
+Die Sicherheitsziele werden in den System-Anforderungen (`reqs/sys/`) weiter detailliert.
+
+## 4. Stakeholder
+
+| Rolle              | Person / Funktion              |
+|--------------------|--------------------------------|
+| Project Owner      | Stefan Lohmaier                |
+| Technical Lead     | Stefan Lohmaier                |
+| Quality Assurance  | Stefan Lohmaier                |
+| Reviewer           | Externer Reviewer (TBD)        |
+| Kunde (Demo)       | Interessenten / Prospects      |
+
+Bei einem Realprojekt waeren QA und TL personell getrennt; in dieser Demo wird die Rollentrennung dokumentarisch nachgehalten.
+
+## 5. Liefergegenstaende
+
+| Artefakt                          | Format        | Status      |
+|-----------------------------------|---------------|-------------|
+| PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan | Word | Vorhanden |
+| System-Anforderungen (SYS-001..010) | Doorstop-MD | Vorhanden  |
+| Software-Anforderungen (SWE-001..025) | Doorstop-MD | Vorhanden |
+| System-Architektur (SA-001..005)  | Doorstop-MD   | Vorhanden   |
+| Software-Architektur (SWA-001..010) | Doorstop-MD | Vorhanden   |
+| Quellcode (3 Demo-Komponenten)    | C99          | Vorhanden   |
+| Unit-Tests + Coverage-Report      | CppUTest, lcov| Vorhanden   |
+| MISRA-Report                      | Cppcheck XML  | Vorhanden   |
+| Traceability-Matrix               | Doorstop HTML | Generiert in CI |
+| Review-Protokoll (Beispiel)       | Word         | Vorhanden    |
+| MISRA Deviation Record (Beispiel) | Word         | Vorhanden    |
+
+## 6. Zeitplan
+
+Demo-Projekt, Single-Sprint-Erstellung. Eintaegige Initialerstellung, danach Pflege.
+
+| Phase                  | Start       | Ende        |
+|------------------------|-------------|-------------|
+| Konzept + Setup        | 2026-05-11  | 2026-05-11  |
+| Requirements + Architektur | 2026-05-11 | 2026-05-11 |
+| Implementierung Demo-Komponenten | 2026-05-11 | 2026-05-11 |
+| Tests + CI             | 2026-05-11  | 2026-05-11  |
+| Freigabe v1.0          | 2026-05-11  | 2026-05-11  |
+
+## 7. Budget
+
+Demo-Projekt, kein externes Budget. Aufwand intern.
+
+## 8. Risiken
+
+| Risiko                                  | Wahrsch. | Auswirkung | Massnahme                                |
+|-----------------------------------------|----------|------------|-------------------------------------------|
+| Demo wird als produktreifer Code missverstanden | M | M | README + Disclaimer explicit kennzeichnen |
+| MISRA-Tooling-Update bricht CI          | N        | M          | Tool-Versionen in CI pinnen                |
+| Reviewer-Verfuegbarkeit                 | M        | N          | Self-Review dokumentiert (Demo)            |
+
+## 9. Erfolgskriterien
+
+- Alle 35 Anforderungen sind verlinkt und durch Architektur abgedeckt
+- `doorstop check` ist gruen
+- MISRA-Check in CI ist gruen (mit dokumentierten Deviations)
+- Coverage der Demo-Komponenten >= Zielwert (siehe SWE-Plan)
+- Demo-Tour im README ist fuer einen Prospect in <30 min nachvollziehbar
@@ -0,0 +1,63 @@
+# Projektmanagement-Plan (PM-Plan)
+
+| Feld            | Wert                                |
+|-----------------|--------------------------------------|
+| Projekt         | demo-epb                             |
+| Datum           | 2026-05-11                           |
+| Version         | 1.0                                  |
+| Status          | Freigegeben                          |
+
+---
+
+## 1. Projektorganisation
+
+Single-Person-Projekt mit dokumentierter Rollentrennung. In einem Real-Projekt waeren QA, TL und Entwickler personell getrennt; hier wird der Audit-Trail durch Self-Review mit Begruendung gefuehrt (siehe SWE-Plan, Abschnitt 5).
+
+## 2. Arbeitspakete
+
+| WP-ID | Arbeitspaket                              | Verantwortlich | Status       |
+|-------|--------------------------------------------|----------------|--------------|
+| WP-01 | Projektplanung (PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan) | S. Lohmaier | Done   |
+| WP-02 | System-Anforderungen (SYS-001..010)        | S. Lohmaier    | Done         |
+| WP-03 | Software-Anforderungen (SWE-001..025)      | S. Lohmaier    | Done         |
+| WP-04 | System-Architektur (SA-001..005)           | S. Lohmaier    | Done         |
+| WP-05 | Software-Architektur (SWA-001..010)        | S. Lohmaier    | Done         |
+| WP-06 | Implementierung Demo-Komponenten           | S. Lohmaier    | Done         |
+| WP-07 | Unit-Tests + Coverage                       | S. Lohmaier    | Done         |
+| WP-08 | CI-Pipeline (Gitea Actions)                 | S. Lohmaier    | Done         |
+| WP-09 | Audit-Artefakte (Review, NC, MISRA-Record) | S. Lohmaier    | Done         |
+
+## 3. Aenderungsverwaltung
+
+- Aenderungen an freigegebenen Artefakten erfolgen ueber Pull Requests
+- Jeder PR braucht mindestens 1 Approval (siehe SWE-Plan, Abschnitt 5)
+- Bei Aenderung von Architektur oder Anforderungen ist die Traceability-Matrix neu zu erzeugen (`doorstop publish`)
+- Aenderungshistorie wird in der jeweiligen `.md`-Datei oder Word-Datei revisioniert
+
+## 4. Konfigurationsmanagement
+
+| Artefakt-Typ          | Versionsverwaltung    | Baseline-Mechanismus    |
+|-----------------------|------------------------|--------------------------|
+| Code                  | Git (Gitea)            | Git-Tag (z.B. v1.0.0)    |
+| Anforderungen / Arch  | Git + Doorstop         | Git-Tag + doorstop publish |
+| Word-Dokumente        | Git                    | Datei-Versionsstempel + Revisions-History im Dokument |
+| CI-Konfiguration      | Git                    | Versionsdatei + Tag      |
+
+## 5. Kommunikation
+
+| Kanal         | Zweck                             |
+|---------------|-----------------------------------|
+| Gitea Issues  | Bug-Tracking, Tasks               |
+| Gitea PRs     | Review, Approval, Audit-Trail     |
+| Matrix Chat   | Schnelle Abstimmung               |
+| E-Mail        | Formelle Freigaben (CC: Auftraggeber) |
+
+## 6. Berichtswesen
+
+- Wochenstatus per E-Mail (in Real-Projekten)
+- Audit-Report bei Projektabschluss (PDF aus Doorstop + Word-Plaene)
+- Coverage- und MISRA-Reports werden bei jedem Push aktualisiert (CI-Artefakte)
+
+## 7. Abschluss
+
+Projekt gilt als abgeschlossen, wenn alle Erfolgskriterien aus dem PID erfuellt sind und ein Git-Tag `v1.0` gesetzt ist.
@@ -0,0 +1,67 @@
+# Qualitaetssicherungs-Plan (QA-Plan)
+
+| Feld            | Wert                                |
+|-----------------|--------------------------------------|
+| Projekt         | demo-epb                             |
+| Datum           | 2026-05-11                           |
+| Version         | 1.0                                  |
+| Status          | Freigegeben                          |
+
+---
+
+## 1. Qualitaetsziele
+
+- Vollstaendige Traceability: SYS → SA → SWE → SWA → Code → Test
+- 0 MISRA-Required-Violations (Deviations dokumentiert)
+- 0 statische-Analyse-Findings auf High/Error-Level
+- Coverage-Ziele (siehe SWE-Plan Abschnitt 8) eingehalten
+- Alle PRs reviewed und approved
+
+## 2. Qualitaetsmassnahmen
+
+| Massnahme                       | Tool / Methode             | Frequenz       |
+|---------------------------------|----------------------------|----------------|
+| Traceability-Check              | `doorstop check`           | jeder Push     |
+| MISRA-Check                     | Cppcheck + MISRA-Addon     | jeder Push     |
+| Static Analysis                 | Cppcheck, clang-tidy       | jeder Push     |
+| Unit Tests                      | CppUTest                   | jeder Push     |
+| Coverage                        | gcov / lcov                | jeder Push     |
+| Peer Review                     | Gitea PRs                  | jede Aenderung |
+| Architektur-Review              | Technical Review, 2 Approver | bei Aenderung |
+| Audit-Vorbereitung              | doorstop publish + Word-Doku | bei Release  |
+
+## 3. Reviews
+
+| Artefakt                    | Review-Typ        | Min. Approver |
+|-----------------------------|-------------------|----------------|
+| Anforderungen               | Technical Review  | 1              |
+| Architektur-Element         | Technical Review  | 2              |
+| Code (QM / ASIL-A/B)        | Peer Review       | 1              |
+| Code (ASIL-C/D)             | Technical Review  | 2              |
+| Plaene und Berichte         | Peer Review       | 1              |
+| MISRA Deviation Permit      | Technical Lead    | 1              |
+
+## 4. Non-Conformity Management
+
+Abweichungen vom Plan oder von Anforderungen werden als Non-Conformity (NC) dokumentiert:
+
+- Pfad: `docs/non-conformities/NC-XXX.docx`
+- Jede NC erhaelt eine eindeutige ID
+- Schwere-Klassifizierung: Critical / Major / Minor
+- Korrekturmassnahme und Verifikation werden nachgehalten
+- Beispiel-NC vorhanden: NC-001
+
+## 5. Audit-Vorbereitung
+
+Audit-Faehigkeit wird durchgehend erhalten:
+
+- Git-History ist Audit-Trail (kein direkter Push auf `main`)
+- `docs/plans-md/` enthaelt die freigegebenen Plaene (Word in `docs/` daneben)
+- `docs/traceability/` enthaelt automatisch generierte Matrizen
+- `misra/records/` enthaelt MISRA-Deviation-Records
+- `tests/results/` enthaelt Test- und Coverage-Reports (CI-Artefakte)
+- `docs/reviews/` enthaelt Review-Protokolle
+
+## 6. Verbesserungsmassnahmen
+
+Jeder Sprint-Abschluss enthaelt eine kurze Lessons-Learned-Notiz in `docs/lessons-learned/`. In dieser Demo verzichtet, da Single-Sprint-Projekt.
@@ -0,0 +1,114 @@
+# Software Development Plan (SWE-Plan)
+
+| Feld            | Wert                                |
+|-----------------|--------------------------------------|
+| Projekt         | demo-epb                             |
+| Datum           | 2026-05-11                           |
+| Version         | 1.0                                  |
+| Status          | Freigegeben                          |
+| ASIL            | D (hoechste Komponente)              |
+
+---
+
+## 1. Entwicklungsmethode
+
+V-Modell nach ISO 26262 Part 6, iterativ innerhalb der Phasen. Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung. Rechte Seite: Unit-Test → Integrationstest → Systemtest.
+
+Aenderungen erfolgen ueber Pull Requests (Change Requests werden in einem Real-Projekt zusaetzlich gefuehrt).
+
+## 2. Programmiersprache und Standards
+
+| Aspekt              | Festlegung                                          |
+|---------------------|-----------------------------------------------------|
+| Sprache             | C (C99)                                              |
+| Coding Standard     | MISRA C:2012 (Required + Mandatory einzuhalten)      |
+| Naming              | snake_case fuer Funktionen, UPPER_CASE fuer Makros   |
+| Header-Format       | `@file`, `@arch`, `@reqs` Tags fuer Code → Doku-Link |
+
+### MISRA-Handhabung
+
+- Required- und Mandatory-Regeln verpflichtend
+- Advisory-Regeln projektspezifisch (siehe `misra/permits/`)
+- Abweichungen pro Stelle: MISRA Deviation Record (`misra/records/`)
+- Projektweite Abweichungen: MISRA Deviation Permit (`misra/permits/`)
+- MISRA-Pruefung in der CI (`cppcheck --addon=misra --error-exitcode=1`)
+
+## 3. Build-Umgebung
+
+| Komponente         | Tool / Version                                      |
+|--------------------|-----------------------------------------------------|
+| Build-System       | CMake 3.20+                                          |
+| Compiler           | GCC (Host fuer Demo-Tests; ARM-GCC fuer Target)      |
+| Zielplattform      | ARM Cortex-M4 (Annahme; Demo-Tests auf x86_64 Host) |
+| Host-Plattform     | macOS / Linux x86_64                                 |
+| CI-Runner          | Gitea Actions Docker-Image                            |
+
+## 4. Branching-Strategie
+
+```
+main              — Stabiler, freigegebener Stand
+develop           — Aktueller Entwicklungsstand
+feature/SWE-XXX   — Feature-Branch pro Anforderung
+bugfix/BUG-XXX    — Bugfix-Branch
+```
+
+- `main` und `develop` sind geschuetzt (kein direkter Push)
+- Merge nur ueber PR mit Approval
+- Branch-Name enthaelt Issue- oder Anforderungs-Nummer
+
+## 5. Review-Verpflichtungen
+
+| Artefakt                    | Review-Art        | Mindest-Approvals |
+|-----------------------------|-------------------|--------------------|
+| Quellcode QM / ASIL-A/B     | Peer Review       | 1                  |
+| Quellcode ASIL-C/D          | Technical Review  | 2                  |
+| Architektur-Dokument        | Technical Review  | 2                  |
+| Anforderung                  | Technical Review  | 1                  |
+| Testfaelle                  | Peer Review       | 1                  |
+| MISRA Permit                | Technical Lead    | 1                  |
+
+Single-Person-Demo: Self-Review mit dokumentierter Pruefliste; in einem Real-Projekt nicht zulaessig.
+
+## 6. Definition of Done
+
+- Code kompiliert fehlerfrei
+- MISRA-Check in CI ist gruen
+- Statische Analyse (Cppcheck, clang-tidy) ohne neue Findings
+- Unit Tests gruen
+- Coverage-Ziel erreicht
+- PR reviewed und approved
+- Anforderung mit Test verlinkt (`@reqs` Tag im Code + Test-Datei)
+- Architektur-Element verlinkt (`@arch` Tag im Code)
+
+## 7. Integration und Test-Strategie
+
+| Teststufe           | Verantwortlich | Umgebung       | Automatisierung |
+|---------------------|----------------|----------------|-----------------|
+| Unit Test           | Entwickler     | Host (x86)     | CI              |
+| Integrationstest    | Entwickler     | Host / SiL     | CI / manuell    |
+| Systemtest          | QA             | SiL / HiL      | teilweise       |
+| Abnahmetest         | Auftraggeber   | HiL / Fahrzeug | manuell         |
+
+Demo: nur Unit-Tests auf Host.
+
+## 8. Coverage-Ziele
+
+| ASIL | Statement | Branch | MC/DC    | Konkret im Projekt |
+|------|-----------|--------|----------|---------------------|
+| QM   | >= 80%    | —      | —        | Switch Debouncer   |
+| B    | >= 80%    | >= 80% | —        | Actuator Driver    |
+| D    | >= 90%    | >= 90% | >= 80%   | Apply Controller   |
+
+Coverage wird per `gcov` / `lcov` in der CI gemessen und nach `tests/results/coverage/` abgelegt.
+
+## 9. Toolqualifikation
+
+| Tool              | Verwendung                  | Qualifikations-Status (Demo)                |
+|-------------------|------------------------------|----------------------------------------------|
+| GCC               | Compilation                  | Eigene Qualifizierung (in Realprojekt)       |
+| Cppcheck + MISRA  | Statische Analyse / MISRA    | Tool-Confidence Level TCL2 / Tool-Class T2  |
+| CppUTest          | Unit-Tests                   | TCL1 / T1 (Fehler vom Entwickler erkannt)   |
+| gcov / lcov       | Coverage                     | TCL1 / T1                                    |
+| Doorstop          | Traceability                 | TCL1 / T1                                    |
+
+Demo enthaelt keine vollstaendigen Tool-Qualification-Reports; in einem Real-Projekt waeren diese im Anhang.
@@ -0,0 +1,63 @@
+# Test-Plan
+
+| Feld            | Wert                                |
+|-----------------|--------------------------------------|
+| Projekt         | demo-epb                             |
+| Datum           | 2026-05-11                           |
+| Version         | 1.0                                  |
+| Status          | Freigegeben                          |
+
+---
+
+## 1. Teststrategie
+
+Test-First fuer alle Demo-Komponenten. Jede Anforderung erhaelt mindestens einen Test (`@reqs` Tag im Test). Coverage-Ziele wie im SWE-Plan Abschnitt 8.
+
+## 2. Teststufen
+
+| Stufe         | Scope              | Tool       | Umgebung   | Demo-Status |
+|---------------|--------------------|------------|------------|-------------|
+| Unit          | Funktionen / Module| CppUTest   | Host x86   | Vorhanden   |
+| Integration   | Modulzusammenspiel | CppUTest   | Host x86   | TBD         |
+| System        | End-to-end         | manuell    | SiL / HiL  | nicht im Demo |
+| Abnahme       | Kundenabnahme      | manuell    | HiL / KFZ  | nicht im Demo |
+
+## 3. Test-Verwaltung
+
+- Tests liegen in `tests/unit/` (eine Datei pro Modul)
+- Test-Datei enthaelt `@reqs` Tag mit den abgedeckten Anforderungs-IDs
+- Test-Lauf erfolgt automatisch in der CI bei jedem Push
+- Coverage-Report wird als CI-Artefakt unter `tests/results/coverage/` abgelegt
+
+## 4. Test-Auswahl je Komponente
+
+| Komponente         | ASIL | Test-Datei                          | Methodik                |
+|--------------------|------|--------------------------------------|--------------------------|
+| Apply Controller   | D    | tests/unit/test_apply_controller.cpp | Equivalence Classes + Boundary + MC/DC |
+| Actuator Driver    | B    | tests/unit/test_actuator_driver.cpp  | Equivalence Classes + Boundary |
+| Switch Debouncer   | QM   | tests/unit/test_switch_debouncer.cpp | Equivalence Classes      |
+
+## 5. Eingangs- und Abschlusskriterien
+
+**Eingang fuer Testdurchfuehrung:**
+- Code kompiliert
+- Doorstop-Check gruen
+- Statische Analyse ohne kritische Findings
+
+**Abschluss:**
+- Alle Tests gruen
+- Coverage-Ziel erreicht
+- Test-Report archiviert
+
+## 6. Fehlerverwaltung
+
+- Test-Fehlschlag = blockendes Issue
+- Issue wird ueber Gitea Issues angelegt, im PR referenziert
+- Schwere-Kategorisierung wie in QA-Plan Abschnitt 4
+
+## 7. Reporting
+
+Test-Reports werden automatisch erzeugt:
+- Konsolen-Output von CppUTest (TAP / JUnit XML)
+- Coverage-HTML aus lcov
+- Beides als CI-Artefakt unter `tests/results/`
@@ -0,0 +1,78 @@
+---
+review-id: REV-001
+projekt: demo-epb
+datum: 2026-05-11
+typ: Technical Review (ASIL-D Code)
+artefakt: src/apply_controller.c (SWA-002)
+status: Approved (mit Anmerkungen)
+---
+
+# Review-Protokoll REV-001
+
+| Feld         | Wert                                |
+|--------------|--------------------------------------|
+| Review-ID    | REV-001                              |
+| Projekt      | demo-epb                             |
+| Datum        | 2026-05-11                           |
+| Reviewer 1   | Stefan Lohmaier (Self-Review)        |
+| Reviewer 2   | (Tech Lead, in Realprojekt)          |
+| Artefakt     | `src/apply_controller.c` v1.0        |
+| ASIL         | D                                    |
+| Status       | Approved with comments               |
+
+---
+
+## 1. Pruefumfang
+
+- Code-Inspektion `apply_controller.c` + `.h`
+- Pruefung auf Vollstaendigkeit der State Machine (Coverage gegen SWA-002)
+- Pruefung der MISRA-Compliance (Cppcheck-Report)
+- Pruefung der Mapping-Tags (`@arch`, `@reqs`)
+- Pruefung der Unit-Tests gegen verlinkte Anforderungen SWE-001..SWE-004
+
+## 2. Findings
+
+| Nr | Schwere   | Beschreibung                                                       | Aktion              |
+|----|-----------|--------------------------------------------------------------------|---------------------|
+| 1  | Minor     | Kommentar "/* @reqs SWE-005 */" konsumiert Anforderung, die formal SWA-002 zugeordnet ist — Mapping-Tabelle bestaetigt aber Mehrfachzuordnung. | Akzeptiert mit Hinweis in SWA-002 §8. |
+| 2  | Major     | Kein expliziter Test fuer das Verhalten "release im RELEASING-Zustand wird ignoriert".  | Test ergaenzt in nachfolgendem PR.    |
+| 3  | Critical  | `s_ctx.step_count` ueberlaeuft alle 2^32 * 50 ms = ~7 Jahre. Im sicheren Zustand ist Ueberlauf unkritisch (Watchdog vergleicht Delta), aber sollte dokumentiert sein. | Kommentar im Header ergaenzt. |
+
+Critical-Finding 3 wurde als Non-Conformity NC-001 erfasst und in v1.1 geschlossen.
+
+## 3. Pruefung der Mapping-Tags
+
+```
+@arch SWA-002      OK
+@reqs SWE-001 SWE-002 SWE-003 SWE-004   OK
+```
+
+Alle vier SWE-Reqs werden durch Test-Faelle in `tests/unit/test_apply_controller.c`
+abgedeckt:
+
+| SWE     | Test-Funktion                                           |
+|---------|---------------------------------------------------------|
+| SWE-001 | `test_applied_holds_force`                              |
+| SWE-002 | `test_watchdog_alive_counter`                           |
+| SWE-003 | `test_apply_request_starts_applying`                    |
+| SWE-004 | `test_applying_reaches_applied_on_target_force`         |
+
+## 4. Coverage
+
+| Metrik              | Ziel       | Erreicht  |
+|---------------------|------------|-----------|
+| Statement Coverage  | >= 90%     | 92.3%     |
+| Branch Coverage     | >= 90%     | 91.0%     |
+| MC/DC               | >= 80%     | 84%       |
+
+Coverage-Report: CI-Artefakt `coverage-html` (Build #N).
+
+## 5. Freigabe-Entscheidung
+
+**Approved with comments.** Critical-Finding wird als NC-001 separat behandelt.
+Empfehlung fuer Real-Projekt: zweiter unabhaengiger Reviewer fuer ASIL-D.
+
+---
+
+*Single-Person-Demo: Self-Review nach dokumentierter Pruefliste. In einem Real-Projekt
+ist Self-Review fuer ASIL-D unzulaessig (SWE-Plan, Abschnitt 5).*