Stefan Lohmaier
ba7a3ebd27
Last German folder name in demo-epb. Pairs cleanly with docs/plans-md/ (markdown source) following the project convention. All references in landing page generator, CI workflows, and cross-doc links updated.
7.5 KiB
7.5 KiB
doc-id, version, status, date
| doc-id | version | status | date |
|---|---|---|---|
| SLM-EPB-PM-MAN-001 | 1.0 | Released | 2026-05-12 |
Project Manual — demo-epb
| Field | Value |
|---|---|
| Project | demo-epb (Electric Parking Brake) |
| Document ID | SLM-EPB-PM-MAN-001 |
| Version | 1.0 |
| Status | Released |
| Date | 2026-05-12 |
| Audience | New project members, auditors |
1. Purpose
This Project Manual is the entry point to the demo-epb project. It answers:
- What is being built?
- Which documents exist, in what reading order?
- Who is responsible for what?
- How does the development and release cycle work?
2. What is demo-epb?
A complete demo of the slohmaier Dev Process using an EPB ECU software. The goal is not the productive software, but evidence of ASPICE 4.0 / ISO 26262-compliant development.
Detail: docs/plans/PID.docx.
3. Reading order for new project members
| Day | Document | Why |
|---|---|---|
| 1 | this Project Manual | Orientation |
| 1 | PID.docx |
What + Why |
| 1 | User-Manual.docx |
Product understanding |
| 2 | HARA.docx + Safety-Case.docx |
Safety concept |
| 2 | SWE-Plan.docx + QA-Plan.docx |
Engineering conventions |
| 3 | reqs/ + arch/ (markdown) |
Requirements + architecture |
| 3 | src/apply_controller.c |
Example ASIL-D code |
| 4 | traceability/index.html |
Wiring of artefacts |
| 4 | coverage/index.html |
What is tested |
| 5 | Maintain this manual | Onboarding for the next person |
4. Document landscape
demo-epb/
├── docs/plans/ ← 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 minutes
├── docs/non-conformities/ ← NC entries
├── 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 derivation)
├── src/ ← C source, with @arch + @reqs tags in headers
├── tests/ ← Unit tests with @reqs tags
├── tools/ ← Python helper scripts (traceability, PlantUML, reports)
├── .gitea/workflows/ ← CI pipelines (validate + release)
└── docs/index.html ← Auto-generated landing page
A clickable overview is docs/index.html (open in browser).
5. Roles and responsibilities
| Role | Responsibility | Person (demo) |
|---|---|---|
| Project Owner | Strategic decisions, release approval | Stefan Lohmaier |
| Technical Lead | Architecture, code reviews, technical decisions | Stefan Lohmaier |
| Safety Manager | HARA, Safety Case, ASIL conformance | Stefan Lohmaier (demo) |
| QA Officer | QA Plan maintenance, audit preparation | Stefan Lohmaier (demo) |
| Configuration Mgr | Baselines, releases, git repo hygiene | Stefan Lohmaier (demo) |
| Developer | Implementation per architecture + tests | Stefan Lohmaier (demo) |
| Reviewer | Code and document reviews | External reviewer (TBD) |
In this demo one person fills all roles; in a real project with ASIL-C/D these are to be separated personnel-wise (developer ≠ reviewer for safety-critical code).
6. Development lifecycle
Requirement
│
▼
Architecture (Markdown + PlantUML)
│
▼
Implementation (C, with @arch + @reqs)
│
▼
Unit test (CppUTest-like framework, with @reqs)
│
▼
Pull request (branch → main)
│
▼
CI: build + test + coverage + MISRA + traceability check
│
▼
Code review (approval required per ASIL)
│
▼
Merge to main
│
▼ (at release point)
Tag v*.*.*
│
▼
CI release workflow: bundle + Gitea release
7. Release strategy
- Pull requests need at least 1 approval (more for ASIL-C/D, see SWE Plan)
- Tags of the form
vMAJOR.MINOR.PATCHtrigger the release workflow - Release bundle contains source + all reports + all Word documents
- Audit readiness is maintained continuously (git history + document lifecycle)
8. Where to report problems
| Problem type | Where to document |
|---|---|
| Bug | Gitea issue (tag bug) |
| Requirement change | Gitea issue (tag requirement) + Doorstop update |
| Non-conformity | docs/non-conformities-md/NC-XXX.md → Word |
| MISRA deviation | misra/records-md/MISRA-REC-XXX.md → Word |
| Safety problem | Escalate to Safety Manager + NC |
9. Tools
See infrastructure/ in the iCloud workspace for setup details. Short list:
- Gitea (gitea.slohmaier.com) — source control + CI + releases
- Doorstop-style Markdown — requirements + architecture
- PlantUML — diagrams (embedded)
- Cppcheck + GCC -Werror — static analysis + MISRA
- gcov/lcov — coverage
- Doxygen — API doc
- pandoc — Markdown → Word/PDF
- Python (stdlib) — traceability + report generators
10. Related documents
| Plan | File | Content |
|---|---|---|
| Project Initiation | PID.docx |
What + Why |
| Project Management | PM-Plan.docx |
Work packages, schedule, stakeholders |
| Quality Assurance | QA-Plan.docx |
Reviews, audits, NC management |
| Configuration Mgmt | CM-Plan.docx |
Baselines, releases, change control |
| Risk Management | RM-Plan.docx |
Risks, mitigation, monitoring |
| Software Development | SWE-Plan.docx |
Language, standards, coverage targets |
| Test | Test-Plan.docx |
Test strategy |
11. Revision history
| Version | Date | Change | Author |
|---|---|---|---|
| 1.0 | 2026-05-12 | First release | S. Lohmaier |