--- doc-id: SLM-EPB-PM-MAN-001 version: 1.0 status: Released date: 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.PATCH` trigger 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|