demo-epb/docs/plans-md/Project-Manual.md

doc-id, version, status, datum

doc-id	version	status	datum
SLM-EPB-PM-MAN-001	1.0	Freigegeben	2026-05-12

Project Manual — demo-epb

Feld	Wert
Projekt	demo-epb (Elektrische Parkbremse)
Dokument-ID	SLM-EPB-PM-MAN-001
Version	1.0
Status	Freigegeben
Datum	2026-05-12
Zielgruppe	Neue Projektmitglieder, Auditoren

---

1. Zweck

Dieses Project Manual ist der Einstieg ins demo-epb Projekt. Es beantwortet:

• Was wird gebaut?
• Welche Dokumente gibt es, in welcher Reihenfolge lesen?
• Wer ist verantwortlich wofuer?
• Wie laeuft der Entwicklungs- und Freigabe-Zyklus?

2. Was ist demo-epb?

Eine vollstaendige Demo des slohmaier Dev Process anhand einer EPB-Steuergeraet-Software. Ziel ist nicht die produktive Software, sondern der Nachweis ASPICE 4.0 / ISO 26262-konformer Entwicklung.

Detail: docs/plaene/PID.docx.

3. Lese-Reihenfolge fuer neue Projektmitglieder

Tag	Dokument	Warum
1	dieses Project Manual	Orientierung
1	PID.docx	Was + Warum
1	User-Manual.docx	Produkt-Verstaendnis
2	HARA.docx + Safety-Case.docx	Sicherheits-Konzept
2	SWE-Plan.docx + QA-Plan.docx	Engineering-Konventionen
3	reqs/ + arch/ (Markdown)	Anforderungen + Architektur
3	src/apply_controller.c	Beispiel ASIL-D Code
4	traceability/index.html	Vernetzung der Artefakte
4	coverage/index.html	Was ist getestet
5	Diese Anleitung selber pflegen	Onboarding fuer den Naechsten

4. Dokumenten-Landschaft

demo-epb/
├── docs/plaene/        ← PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan, CM-Plan, RM-Plan
├── docs/safety/        ← HARA, Safety-Case, FMEDA, MISRA-Compliance, Verification-Report, Tool-Qualification
├── docs/manuals/       ← User-Manual, Service-Manual
├── docs/reviews/       ← Review-Protokolle
├── docs/non-conformities/  ← NC-Eintraege
├── misra/records/      ← MISRA Deviation Records
├── reqs/sys/           ← Doorstop-MD System Requirements
├── reqs/swe/           ← Doorstop-MD Software Requirements
├── arch/sys/           ← Doorstop-MD System Architecture + PlantUML
├── arch/swe/           ← Doorstop-MD Software Architecture + PlantUML
├── safety/sg/          ← Doorstop-MD Safety Goals (ASIL-Ableitung)
├── src/                ← C-Code, mit @arch + @reqs Tags im Header
├── tests/              ← Unit-Tests mit @reqs Tags
├── tools/              ← Python-Skripte (Traceability, PlantUML, Reports)
├── .gitea/workflows/   ← CI-Pipelines (validate + release)
└── docs/index.html     ← Auto-generierte Startseite

Eine klickbare Uebersicht liefert docs/index.html (Browser oeffnen).

5. Rollen und Verantwortlichkeiten

Rolle	Verantwortung	Person (Demo)
Project Owner	Strategische Entscheidungen, Freigabe Release	Stefan Lohmaier
Technical Lead	Architektur, Code-Reviews, technische Entscheidungen	Stefan Lohmaier
Safety Manager	HARA, Safety Case, ASIL-Konformitaet	Stefan Lohmaier (Demo)
QA-Beauftragter	QA-Plan-Pflege, Audit-Vorbereitung	Stefan Lohmaier (Demo)
Configuration Mgr	Baselines, Releases, Git-Repo-Hygiene	Stefan Lohmaier (Demo)
Entwickler	Implementierung gemaess Architektur + Tests	Stefan Lohmaier (Demo)
Reviewer	Code- und Dokument-Reviews	Externer Reviewer (TBD)

In der Demo ist eine Person in allen Rollen; in einem Real-Projekt mit ASIL-C/D sind diese personell zu trennen (insb. Entwickler ungleich Reviewer fuer sicherheitskritischen Code).

6. Entwicklungs-Lebenszyklus

Anforderung
  │
  ▼
Architektur (Markdown + PlantUML)
  │
  ▼
Implementation (C, mit @arch + @reqs)
  │
  ▼
Unit-Test (CppUTest-aehnliches Framework, mit @reqs)
  │
  ▼
Pull Request (Branch -> main)
  │
  ▼
CI: Build + Test + Coverage + MISRA + Traceability-Check
  │
  ▼
Code-Review (Approval-Pflicht je nach ASIL)
  │
  ▼
Merge nach main
  │
  ▼ (bei Release-Punkt)
Tag v*.*.*
  │
  ▼
CI Release-Workflow: Bundle + Gitea-Release

7. Freigabe-Strategie

• Pull-Requests brauchen mindestens 1 Approval (mehr fuer ASIL-C/D, siehe SWE-Plan)
• Tags im Format vMAJOR.MINOR.PATCH triggern den Release-Workflow
• Release-Bundle enthaelt Source + alle Reports + alle Word-Dokumente
• Audit-Faehigkeit ist jederzeit gegeben (Git-History + Doku-Lifecycle)

8. Wo Probleme melden

Problem-Typ	Wo dokumentieren
Bug	Gitea Issue (Tag bug)
Anforderungs-Aenderung	Gitea Issue (Tag requirement) + Doorstop-Update
Non-Conformity	docs/non-conformities-md/NC-XXX.md -> Word
MISRA-Abweichung	misra/records-md/MISRA-REC-XXX.md -> Word
Sicherheits-Problem	Sofort an Safety Manager + NC

9. Tools

Siehe infrastructure/ im iCloud-Workspace fuer Setup-Details. Kurzform:

• Gitea (gitea.slohmaier.com) — Source-Control + CI + Releases
• Doorstop-Stil Markdown — Anforderungen + Architektur
• PlantUML — Diagramme (eingebettet)
• Cppcheck + GCC -Werror — Statische Analyse + MISRA
• gcov/lcov — Coverage
• Doxygen — API-Doc
• pandoc — Markdown -> Word/PDF
• Python (Stdlib) — Traceability + Report-Generatoren

10. Verwandte Dokumente

Plan	Datei	Inhalt
Project Initiation	PID.docx	Was + Warum
Projekt-Management	PM-Plan.docx	Arbeitspakete, Termine, Stakeholder
Quality Assurance	QA-Plan.docx	Reviews, Audits, NC-Management
Configuration Mgmt	CM-Plan.docx	Baselines, Releases, Change Control
Risk Management	RM-Plan.docx	Risiken, Mitigation, Monitoring
Software Development	SWE-Plan.docx	Sprache, Standards, Coverage-Ziele
Test	Test-Plan.docx	Test-Strategie

11. Aenderungshistorie

Version	Datum	Aenderung	Autor
1.0	2026-05-12	Erstfreigabe	S. Lohmaier