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
This commit is contained in:
Stefan Lohmaier
@@ -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
|
||||
Reference in New Issue
Block a user