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
4.9 KiB
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 checkist 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