Stefan Lohmaier
1855162e6d
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
108 lines
4.9 KiB
Markdown
108 lines
4.9 KiB
Markdown
# 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
|