slohmaier/demo-epb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity

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

Browse Source 
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
This commit is contained in:
Stefan Lohmaier
2026-05-11 13:51:02 -07:00
commit 1855162e6d
92 changed files with 4116 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plans-md/PID.md
+107
View File
@@ -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
docs/plans-md/PM-Plan.md
+63
View File
@@ -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.
docs/plans-md/QA-Plan.md
+67
View File
@@ -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.
docs/plans-md/SWE-Plan.md
+114
View File
@@ -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.
docs/plans-md/Test-Plan.md
+63
View File
@@ -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/`