slohmaier/demo-epb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity

feat(i18n): full English translation of demo-epb
Validate / build-test (macos-latest) (push) Failing after 3s
Details
Validate / build-test (windows-latest) (push) Failing after 15s
Details
Validate / build-test (ubuntu-latest) (push) Successful in 17s
Details
Validate / reports (push) Successful in 50s
Details
Release / release (push) Successful in 50s
Details

Browse Source 
Phase 2 of the English translation:

Word documents (filled, EPB-specific):
- 8 plans (PID, PM, QA, SWE, Test, Project Manual, CM, RM)
- 6 safety docs (HARA, Safety Case, FMEDA, MISRA Compliance,
  Verification Report, Tool Qualification Cppcheck)
- 2 manuals (User, Service)
- 3 audit artefacts (Review minutes, NC-001, MISRA-REC-001)
- All regenerated via pandoc from English markdown sources

Code, tests, headers:
- All file headers, struct comments, function docstrings in English
- All test names (TEST_BEGIN strings) translated
- Inline comments translated
- 46 tests still green after translation

CI workflows:
- All step names in English
- Step descriptions, comments, release notes template in English

README.md fully rewritten in English with proper guided tour.

Phase 3 (still pending): dev-process repo templates + toolstack/setup docs.
This commit is contained in:
Stefan Lohmaier
2026-05-12 03:37:51 -07:00
parent a47e0aed3e
commit fb2c083551
54 changed files with 1528 additions and 1600 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plans-md/CM-Plan.md
+93 -95
View File
@@ -1,148 +1,146 @@
---
doc-id: SLM-EPB-CM-001
version: 1.0
status: Freigegeben
datum: 2026-05-12
status: Released
date: 2026-05-12
---
# Configuration Management Plan (CM-Plan)
# Configuration Management Plan (CM Plan)
| Feld | Wert |
|--------------|----------------------------------------|
| Projekt | demo-epb |
| Dokument-ID | SLM-EPB-CM-001 |
| Version | 1.0 |
| Status | Freigegeben |
| Datum | 2026-05-12 |
| Norm | ASPICE SUP.8 + ISO 26262-8 §7 |
| Field | Value |
|---------------|----------------------------------------|
| Project | demo-epb |
| Document ID | SLM-EPB-CM-001 |
| Version | 1.0 |
| Status | Released |
| Date | 2026-05-12 |
| Standard | ASPICE SUP.8 + ISO 26262-8 §7 |
---
## 1. Zweck
## 1. Purpose
Beschreibt, wie Konfigurations-Items identifiziert, versioniert, freigegeben
und kontrolliert geaendert werden.
Describes how configuration items are identified, versioned, released, and controlled-change managed.
## 2. Configuration Items (CIs)
Folgende Artefakte stehen unter Konfigurationskontrolle:
The following artefacts are under configuration control:
| Typ | Pfad | Versionierung |
| Type | Path | Versioning |
|-------------------------|----------------------------------------|------------------------------|
| Source-Code | `src/**/*.{c,h}` | Git |
| Source code | `src/**/*.{c,h}` | Git |
| Tests | `tests/**` | Git |
| Anforderungen | `reqs/{sys,swe}/*.md` | Git + Doorstop-Item-Hash |
| Architektur | `arch/{sys,swe}/*.md` | Git + Doorstop-Item-Hash |
| Requirements | `reqs/{sys,swe}/*.md` | Git + Doorstop item hash |
| Architecture | `arch/{sys,swe}/*.md` | Git + Doorstop item hash |
| Safety Goals | `safety/sg/*.md` | Git |
| Plaene (Word) | `docs/plaene/*.docx` | Git + Dokument-Versionsblock |
| Safety-Doku (Word) | `docs/safety/*.docx` | Git |
| Plans (Word) | `docs/plaene/*.docx` | Git + document version block |
| Safety docs (Word) | `docs/safety/*.docx` | Git |
| Manuals (Word) | `docs/manuals/*.docx` | Git |
| Reviews + NCs | `docs/reviews/`, `docs/non-conformities/` | Git |
| MISRA-Records | `misra/records/*.docx` | Git |
| CI-Konfiguration | `.gitea/workflows/*.yml` | Git |
| Build-Definition | `Makefile`, `Doxyfile` | Git |
| MISRA records | `misra/records/*.docx` | Git |
| CI configuration | `.gitea/workflows/*.yml` | Git |
| Build definition | `Makefile`, `Doxyfile` | Git |
| Tools | `tools/*.py` | Git |
## 3. Repository-Struktur
## 3. Repository structure
- **Remote:** https://gitea.slohmaier.com/slohmaier/demo-epb
- **Branch `main`:** stabil, immer freigegebener Stand
- **Branch `develop`:** aktueller Entwicklungsstand
- **Feature-Branches:** `feature/SWE-XXX-...`
- **Bugfix-Branches:** `bugfix/<issue>-...`
- **Release-Branches:** `release/vX.Y` (nur bei Real-Projekt; Demo: direkt von main)
- **Branch `main`:** stable, always released state
- **Branch `develop`:** current development state
- **Feature branches:** `feature/SWE-XXX-...`
- **Bugfix branches:** `bugfix/<issue>-...`
- **Release branches:** `release/vX.Y` (real projects only; demo: from main directly)
## 4. Baselines
Eine Baseline ist ein eingefrorener, freigegebener Stand. Baselines werden durch
Git-Tags gesetzt.
A baseline is a frozen, released state. Baselines are set via git tags.
| Baseline-Typ | Tag-Schema | Wann |
| Baseline type | Tag scheme | When |
|---------------------------|-------------------|----------------------------------------|
| Requirements Baseline | `req-vX.Y` | Nach Anforderungs-Freigabe |
| Architecture Baseline | `arch-vX.Y` | Nach Architektur-Review |
| Release Baseline | `vX.Y.Z` | Bei produktiver Freigabe |
| Internal Snapshot | `snap-YYYY-MM-DD` | Bei wichtigen Zwischenstaenden |
| Requirements baseline | `req-vX.Y` | After requirements release |
| Architecture baseline | `arch-vX.Y` | After architecture review |
| Release baseline | `vX.Y.Z` | On productive release |
| Internal snapshot | `snap-YYYY-MM-DD` | On significant intermediate states |
Jeder Tag triggert (bei `vX.Y.Z`) den Release-Workflow, der ein Bundle erzeugt.
Every tag (specifically `vX.Y.Z`) triggers the release workflow, which produces a bundle.
## 5. Versions-Schema
## 5. Versioning scheme
| Artefakt | Schema |
| Artefact | Scheme |
|-----------------------|------------------------------------------|
| Software-Release | Semantic Versioning `MAJOR.MINOR.PATCH` |
| Anforderungen | Doorstop-Level `X.Y` + Datum |
| Architektur | Doorstop-Level `X.Y` + Datum |
| Word-Dokumente | `MAJOR.MINOR` im Dokument-Header |
| Software release | Semantic Versioning `MAJOR.MINOR.PATCH` |
| Requirements | Doorstop level `X.Y` + date |
| Architecture | Doorstop level `X.Y` + date |
| Word documents | `MAJOR.MINOR` in document header |
## 6. Change Control
## 6. Change control
Aenderungen an Configuration Items erfolgen ueber:
Changes to configuration items occur via:
1. **Trivial-Aenderung** (Tippfehler, Kommentare): direkt im Branch, PR mit 1 Approval
2. **Normal-Aenderung** (Feature, Bugfix): Feature-Branch, PR mit Reviews je nach ASIL
3. **Major-Aenderung** (Architektur, Sicherheits-Konzept): Change Request + Reviewer-Quorum
1. **Trivial change** (typos, comments): directly on the branch, PR with 1 approval
2. **Normal change** (feature, bug fix): feature branch, PR with reviews per ASIL
3. **Major change** (architecture, safety concept): change request + reviewer quorum
| Asil | Reviewer-Mindestanzahl |
|---------|--------------------------------------|
| QM | 1 |
| ASIL-A/B| 1 |
| ASIL-C | 2 (mind. 1 Technical Reviewer) |
| ASIL-D | 2 Technical Reviewer + Safety Manager|
| ASIL | Minimum reviewer count |
|---------|---------------------------------------|
| QM | 1 |
| ASIL-A/B| 1 |
| ASIL-C | 2 (at least 1 technical reviewer) |
| ASIL-D | 2 technical reviewers + Safety Manager |
Reviews werden in `docs/reviews/REV-XXX.docx` dokumentiert.
Reviews are documented in `docs/reviews/REV-XXX.docx`.
## 7. Release-Prozess
## 7. Release process
```
1. Alle PRs in main gemerged
2. Branch protected, alle CI-Checks gruen
3. Release-Notes-Entwurf im PR vorbereitet
4. Tag setzen: git tag -a vX.Y.Z -m "..."
1. All PRs merged into main
2. Branch protected, all CI checks green
3. Release notes drafted in the PR
4. Set tag: git tag -a vX.Y.Z -m "..."
5. Push: git push origin vX.Y.Z
6. Release-Workflow laeuft (.gitea/workflows/release.yml):
- Build + Tests + Coverage
- Traceability + Diagrams + API-Doc
- Word-Dokumente bundlen
- Source + Artefakt-Archive packen
- Gitea-Release anlegen
7. Release manuell pruefen (Bundle herunterladen, sichten)
8. Release als "stable" markieren
6. Release workflow runs (.gitea/workflows/release.yml):
- Build + tests + coverage
- Traceability + diagrams + API doc
- Bundle Word documents
- Pack source + artefact archives
- Create Gitea release
7. Review release manually (download bundle, inspect)
8. Mark release as "stable"
```
## 8. Aufbewahrung
## 8. Retention
| Artefakt | Aufbewahrungsdauer |
| Artefact | Retention |
|--------------------------|----------------------------------------|
| Git-Repository | Unbegrenzt (Gitea + Backup) |
| Release-Bundles | 10 Jahre nach Produkt-EOL |
| Reviews + NCs | 10 Jahre nach Produkt-EOL |
| MISRA-Records | 10 Jahre nach Produkt-EOL |
| CI-Artefakte (kurzlebig) | 90 Tage (in Gitea-Artifacts) |
| Git repository | Indefinite (Gitea + backup) |
| Release bundles | 10 years after product EOL |
| Reviews + NCs | 10 years after product EOL |
| MISRA records | 10 years after product EOL |
| CI artefacts (short-lived)| 90 days (in Gitea artifacts) |
ISO 26262 fordert 10 Jahre nach End-of-Production-Life (Annahme).
ISO 26262 requires 10 years after end-of-production-life (assumption).
## 9. Verifikation
## 9. Verification
Alle Pull Requests laufen durch:
- `doorstop`-aequivalenter Traceability-Check (`tools/traceability.py check`)
- Build + Unit-Tests
- Static Analysis + MISRA-Check
- Coverage-Messung
All pull requests pass through:
- Doorstop-equivalent traceability check (`tools/traceability.py check`)
- Build + unit tests
- Static analysis + MISRA check
- Coverage measurement
Erst nach Approval und CI-Gruen kann der Merge nach `main` erfolgen.
Only after approval and green CI may a merge into `main` occur.
## 10. Verantwortlichkeiten
## 10. Responsibilities
| Rolle | Aufgabe |
|------------------|--------------------------------------------------|
| Configuration Mgr| Pflege dieses CM-Plans, Repo-Hygiene, Baselines |
| Entwickler | Korrekte Branch-Strategie, sinnvolle Commit-Msg |
| Reviewer | Pruefung vor Merge, Audit-Trail |
| Project Owner | Release-Freigabe |
| Role | Task |
|------------------|---------------------------------------------------|
| Configuration Mgr| Maintain this CM Plan, repo hygiene, baselines |
| Developer | Correct branching, meaningful commit messages |
| Reviewer | Review before merge, audit trail |
| Project Owner | Release approval |
## 11. Aenderungshistorie
## 11. Revision history
| Version | Datum | Aenderung | Autor |
|---------|-------------|---------------------|-------------|
| 1.0 | 2026-05-12 | Erstfreigabe | S. Lohmaier |
| Version | Date | Change | Author |
|---------|-------------|---------------------|------------|
| 1.0 | 2026-05-12 | First release | S. Lohmaier|
docs/plans-md/PID.md
+71 -71
View File
@@ -1,107 +1,107 @@
# Project Initiation Document (PID)
| Feld | Wert |
| Field | Value |
|-----------------|--------------------------------------|
| Projekt | demo-epb (Elektrische Parkbremse) |
| Projekt-ID | SLM-EPB-001 |
| Auftraggeber | slohmaier.com (Demo-Eigenentwicklung)|
| Auftragnehmer | Stefan Lohmaier |
| Datum | 2026-05-11 |
| Project | demo-epb (Electric Parking Brake) |
| Project ID | SLM-EPB-001 |
| Client | slohmaier.com (in-house demo) |
| Contractor | Stefan Lohmaier |
| Date | 2026-05-11 |
| Version | 1.0 |
| Status | Freigegeben |
| Klassifikation | Oeffentlich |
| Status | Released |
| Classification | Public |
---
## 1. Projektzweck
## 1. Project purpose
Demonstration des slohmaier Dev Process anhand einer EPB-Steuergeraet-Software. Ziel ist nicht die produktive Software, sondern der vollstaendige Nachweis von:
Demonstration of the slohmaier Dev Process using an EPB ECU software. The goal is not the productive software but a complete demonstration of:
- 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
- ASPICE 4.0-compliant development flow
- ISO 26262-compliant handling of safety requirements (ASIL-D / ASIL-B / QM)
- MISRA C compliance
- Toolchain: Gitea + Doorstop + Cppcheck + gcov + CppUTest + pandoc
Adressat ist potenzielle Kundschaft, die sehen will, wie ein realer Audit-faehiger Engineering-Stand aussieht.
The target audience is potential customers who want to see what a real audit-ready engineering snapshot looks like.
## 2. Produktbeschreibung
## 2. Product description
Eine Electronic Parking Brake (EPB) klemmt im Stillstand zwei Bremssaettel ueber kleine Elektromotoren fest und loest sie bei Anfahrt wieder. Funktionsumfang:
An Electric Parking Brake (EPB) clamps two rear callipers via small electric motors at standstill and releases them on drive-away. Functional scope:
- 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
- Apply / Release on driver request
- Hold function with auto-apply on engine-off
- Drive-Away-Assist (auto-release on drive-away)
- Hill-Hold on inclines
- Actuator current monitoring
- Service mode for the workshop
- UDS diagnostics via CAN
## 3. Sicherheitsziele
## 3. Safety goals
| ID | Sicherheitsziel | ASIL |
| ID | Safety goal | ASIL |
|-------|---------------------------------------------------------------|------|
| SG-01 | Verhinderung ungewollten Wegrollens des Fahrzeugs | D |
| SG-02 | Verhinderung ungewollten Loesens der Parkbremse | D |
| SG-03 | Verhinderung Motorschaden durch Ueberlast | B |
| SG-01 | Prevent unintended vehicle roll-away | D |
| SG-02 | Prevent unintended release of the parking brake | D |
| SG-03 | Prevent motor damage from overload | B |
Die Sicherheitsziele werden in den System-Anforderungen (`reqs/sys/`) weiter detailliert.
Safety goals are detailed further in the system requirements (`reqs/sys/`).
## 4. Stakeholder
## 4. Stakeholders
| Rolle | Person / Funktion |
| Role | Person / Function |
|--------------------|--------------------------------|
| Project Owner | Stefan Lohmaier |
| Technical Lead | Stefan Lohmaier |
| Quality Assurance | Stefan Lohmaier |
| Reviewer | Externer Reviewer (TBD) |
| Kunde (Demo) | Interessenten / Prospects |
| Reviewer | External reviewer (TBD) |
| Customer (demo) | Prospects / interested parties |
Bei einem Realprojekt waeren QA und TL personell getrennt; in dieser Demo wird die Rollentrennung dokumentarisch nachgehalten.
In a real project QA and TL would be separate persons; in this demo the role separation is kept on paper.
## 5. Liefergegenstaende
## 5. Deliverables
| 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 |
| Artefact | Format | Status |
|-------------------------------------------|---------------|-------------|
| PID, PM Plan, QA Plan, SWE Plan, Test Plan | Word | Available |
| System Requirements (SYS-001..010) | Doorstop MD | Available |
| Software Requirements (SWE-001..025) | Doorstop MD | Available |
| System Architecture (SA-001..005) | Doorstop MD | Available |
| Software Architecture (SWA-001..010) | Doorstop MD | Available |
| Source code (3 demo components) | C99 | Available |
| Unit tests + coverage report | CppUTest, lcov | Available |
| MISRA report | Cppcheck XML | Available |
| Traceability matrix | Doorstop HTML | Generated in CI |
| Review minutes (example) | Word | Available |
| MISRA Deviation Record (example) | Word | Available |
## 6. Zeitplan
## 6. Schedule
Demo-Projekt, Single-Sprint-Erstellung. Eintaegige Initialerstellung, danach Pflege.
Demo project, single-sprint creation. One-day initial creation, maintenance thereafter.
| 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 |
| Phase | Start | End |
|-------------------------------|-------------|-------------|
| Concept + setup | 2026-05-11 | 2026-05-11 |
| Requirements + architecture | 2026-05-11 | 2026-05-11 |
| Implementation of demo components | 2026-05-11 | 2026-05-11 |
| Tests + CI | 2026-05-11 | 2026-05-11 |
| Release v1.0 | 2026-05-11 | 2026-05-11 |
## 7. Budget
Demo-Projekt, kein externes Budget. Aufwand intern.
Demo project, no external budget. Internal effort.
## 8. Risiken
## 8. Risks
| 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) |
| Risk | Likelihood | Impact | Mitigation |
|-----------------------------------------------|------------|--------|----------------------------------------------|
| Demo is mistaken for production-ready code | M | M | Disclaimer in README + plain labelling |
| MISRA tooling update breaks CI | L | M | Pin tool versions in CI |
| Reviewer availability | M | L | Self-review documented (demo only) |
## 9. Erfolgskriterien
## 9. Success criteria
- 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
- All 35 requirements are linked and covered by architecture
- `doorstop check` is green
- MISRA check in CI is green (with documented deviations)
- Demo-component coverage meets target (see SWE Plan)
- The guided tour in the README is navigable by a prospect in < 30 min
docs/plans-md/PM-Plan.md
+44 -44
View File
@@ -1,63 +1,63 @@
# Projektmanagement-Plan (PM-Plan)
# Project Management Plan (PM Plan)
| Feld | Wert |
| Field | Value |
|-----------------|--------------------------------------|
| Projekt | demo-epb |
| Datum | 2026-05-11 |
| Project | demo-epb |
| Date | 2026-05-11 |
| Version | 1.0 |
| Status | Freigegeben |
| Status | Released |
---
## 1. Projektorganisation
## 1. Project organisation
Single-Person-Projekt mit dokumentierter Rollentrennung. In einem Real-Projekt waeren QA, TL und Entwickler personell getrennt; hier wird der Audit-Trail durch Self-Review mit Begruendung gefuehrt (siehe SWE-Plan, Abschnitt 5).
Single-person project with documented role separation. In a real project, QA, TL, and developer would be separate persons; here the audit trail is maintained through self-review with rationale (see SWE Plan, section 5).
## 2. Arbeitspakete
## 2. Work packages
| WP-ID | Arbeitspaket | Verantwortlich | Status |
|-------|--------------------------------------------|----------------|--------------|
| WP-01 | Projektplanung (PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan) | S. Lohmaier | Done |
| WP-02 | System-Anforderungen (SYS-001..010) | S. Lohmaier | Done |
| WP-03 | Software-Anforderungen (SWE-001..025) | S. Lohmaier | Done |
| WP-04 | System-Architektur (SA-001..005) | S. Lohmaier | Done |
| WP-05 | Software-Architektur (SWA-001..010) | S. Lohmaier | Done |
| WP-06 | Implementierung Demo-Komponenten | S. Lohmaier | Done |
| WP-07 | Unit-Tests + Coverage | S. Lohmaier | Done |
| WP-08 | CI-Pipeline (Gitea Actions) | S. Lohmaier | Done |
| WP-09 | Audit-Artefakte (Review, NC, MISRA-Record) | S. Lohmaier | Done |
| WP-ID | Work package | Owner | Status |
|-------|---------------------------------------------|----------------|--------|
| WP-01 | Project planning (PID, PM, QA, SWE, Test) | S. Lohmaier | Done |
| WP-02 | System Requirements (SYS-001..010) | S. Lohmaier | Done |
| WP-03 | Software Requirements (SWE-001..025) | S. Lohmaier | Done |
| WP-04 | System Architecture (SA-001..005) | S. Lohmaier | Done |
| WP-05 | Software Architecture (SWA-001..010) | S. Lohmaier | Done |
| WP-06 | Implementation of demo components | S. Lohmaier | Done |
| WP-07 | Unit tests + coverage | S. Lohmaier | Done |
| WP-08 | CI pipeline (Gitea Actions) | S. Lohmaier | Done |
| WP-09 | Audit artefacts (Review, NC, MISRA record) | S. Lohmaier | Done |
## 3. Aenderungsverwaltung
## 3. Change control
- Aenderungen an freigegebenen Artefakten erfolgen ueber Pull Requests
- Jeder PR braucht mindestens 1 Approval (siehe SWE-Plan, Abschnitt 5)
- Bei Aenderung von Architektur oder Anforderungen ist die Traceability-Matrix neu zu erzeugen (`doorstop publish`)
- Aenderungshistorie wird in der jeweiligen `.md`-Datei oder Word-Datei revisioniert
- Changes to released artefacts go through pull requests
- Every PR needs at least 1 approval (see SWE Plan, section 5)
- When requirements or architecture change, the traceability matrix must be regenerated (`doorstop publish`)
- Revision history is maintained inside the respective `.md` file or Word document
## 4. Konfigurationsmanagement
## 4. Configuration management
| Artefakt-Typ | Versionsverwaltung | Baseline-Mechanismus |
|-----------------------|------------------------|--------------------------|
| Code | Git (Gitea) | Git-Tag (z.B. v1.0.0) |
| Anforderungen / Arch | Git + Doorstop | Git-Tag + doorstop publish |
| Word-Dokumente | Git | Datei-Versionsstempel + Revisions-History im Dokument |
| CI-Konfiguration | Git | Versionsdatei + Tag |
| Artefact type | Versioning | Baseline mechanism |
|-------------------|-----------------------|------------------------------------|
| Code | Git (Gitea) | Git tag (e.g. v1.0.0) |
| Requirements / Arch | Git + Doorstop | Git tag + doorstop publish |
| Word documents | Git | File version stamp + revision history in the document |
| CI configuration | Git | Version pin + tag |
## 5. Kommunikation
## 5. Communication
| Kanal | Zweck |
|---------------|-----------------------------------|
| Gitea Issues | Bug-Tracking, Tasks |
| Gitea PRs | Review, Approval, Audit-Trail |
| Matrix Chat | Schnelle Abstimmung |
| E-Mail | Formelle Freigaben (CC: Auftraggeber) |
| Channel | Purpose |
|---------------|--------------------------------------|
| Gitea Issues | Bug tracking, tasks |
| Gitea PRs | Review, approval, audit trail |
| Matrix chat | Quick alignment |
| Email | Formal releases (cc client) |
## 6. Berichtswesen
## 6. Reporting
- Wochenstatus per E-Mail (in Real-Projekten)
- Audit-Report bei Projektabschluss (PDF aus Doorstop + Word-Plaene)
- Coverage- und MISRA-Reports werden bei jedem Push aktualisiert (CI-Artefakte)
- Weekly status by email (in real projects)
- Audit report at project closure (PDF from Doorstop + Word plans)
- Coverage and MISRA reports are refreshed on every push (CI artefacts)
## 7. Abschluss
## 7. Closure
Projekt gilt als abgeschlossen, wenn alle Erfolgskriterien aus dem PID erfuellt sind und ein Git-Tag `v1.0` gesetzt ist.
The project is considered closed when all success criteria from the PID are met and the `v1.0` git tag is set.
docs/plans-md/Project-Manual.md
+106 -110
View File
@@ -1,172 +1,168 @@
---
doc-id: SLM-EPB-PM-MAN-001
version: 1.0
status: Freigegeben
datum: 2026-05-12
status: Released
date: 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 |
| 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. Zweck
## 1. Purpose
Dieses Project Manual ist der **Einstieg** ins demo-epb Projekt. Es beantwortet:
This Project Manual is the entry point to the demo-epb project. It answers:
- Was wird gebaut?
- Welche Dokumente gibt es, in welcher Reihenfolge lesen?
- Wer ist verantwortlich wofuer?
- Wie laeuft der Entwicklungs- und Freigabe-Zyklus?
- 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. Was ist demo-epb?
## 2. What is 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.
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/plaene/PID.docx`.
## 3. Lese-Reihenfolge fuer neue Projektmitglieder
## 3. Reading order for new project members
| Tag | Dokument | Warum |
| Day | Document | Why |
|-----|----------------------------------------|----------------------------------------|
| 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 |
| 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. Dokumenten-Landschaft
## 4. Document landscape
```
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
├── 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 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
```
Eine **klickbare Uebersicht** liefert `docs/index.html` (Browser oeffnen).
A clickable overview is `docs/index.html` (open in browser).
## 5. Rollen und Verantwortlichkeiten
## 5. Roles and responsibilities
| 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) |
| 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 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).
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. Entwicklungs-Lebenszyklus
## 6. Development lifecycle
```
Anforderung
Requirement
│
▼
Architektur (Markdown + PlantUML)
Architecture (Markdown + PlantUML)
│
▼
Implementation (C, mit @arch + @reqs)
Implementation (C, with @arch + @reqs)
│
▼
Unit-Test (CppUTest-aehnliches Framework, mit @reqs)
Unit test (CppUTest-like framework, with @reqs)
│
▼
Pull Request (Branch -> main)
Pull request (branch → main)
│
▼
CI: Build + Test + Coverage + MISRA + Traceability-Check
CI: build + test + coverage + MISRA + traceability check
│
▼
Code-Review (Approval-Pflicht je nach ASIL)
Code review (approval required per ASIL)
│
▼
Merge nach main
Merge to main
│
▼ (bei Release-Punkt)
▼ (at release point)
Tag v*.*.*
│
▼
CI Release-Workflow: Bundle + Gitea-Release
CI release workflow: bundle + Gitea release
```
## 7. Freigabe-Strategie
## 7. Release strategy
- **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)
- **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. Wo Probleme melden
## 8. Where to report problems
| 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 |
| 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
Siehe `infrastructure/` im iCloud-Workspace fuer Setup-Details. Kurzform:
See `infrastructure/` in the iCloud workspace for setup details. Short list:
- **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
- **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. Verwandte Dokumente
## 10. Related documents
| 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 |
| 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. Aenderungshistorie
## 11. Revision history
| Version | Datum | Aenderung | Autor |
|---------|-------------|---------------------|-------------|
| 1.0 | 2026-05-12 | Erstfreigabe | S. Lohmaier |
| Version | Date | Change | Author |
|---------|-------------|---------------------|------------|
| 1.0 | 2026-05-12 | First release | S. Lohmaier|
docs/plans-md/QA-Plan.md
+47 -47
View File
@@ -1,67 +1,67 @@
# Qualitaetssicherungs-Plan (QA-Plan)
# Quality Assurance Plan (QA Plan)
| Feld | Wert |
| Field | Value |
|-----------------|--------------------------------------|
| Projekt | demo-epb |
| Datum | 2026-05-11 |
| Project | demo-epb |
| Date | 2026-05-11 |
| Version | 1.0 |
| Status | Freigegeben |
| Status | Released |
---
## 1. Qualitaetsziele
## 1. Quality goals
- Vollstaendige Traceability: SYS → SA → SWE → SWA → Code → Test
- 0 MISRA-Required-Violations (Deviations dokumentiert)
- 0 statische-Analyse-Findings auf High/Error-Level
- Coverage-Ziele (siehe SWE-Plan Abschnitt 8) eingehalten
- Alle PRs reviewed und approved
- Complete traceability: SYS → SA → SWE → SWA → Code → Test
- 0 MISRA Required violations (deviations documented)
- 0 static-analysis findings at High / Error level
- Coverage targets met (see SWE Plan section 8)
- All PRs reviewed and approved
## 2. Qualitaetsmassnahmen
## 2. Quality measures
| Massnahme | Tool / Methode | Frequenz |
|---------------------------------|----------------------------|----------------|
| Traceability-Check | `doorstop check` | jeder Push |
| MISRA-Check | Cppcheck + MISRA-Addon | jeder Push |
| Static Analysis | Cppcheck, clang-tidy | jeder Push |
| Unit Tests | CppUTest | jeder Push |
| Coverage | gcov / lcov | jeder Push |
| Peer Review | Gitea PRs | jede Aenderung |
| Architektur-Review | Technical Review, 2 Approver | bei Aenderung |
| Audit-Vorbereitung | doorstop publish + Word-Doku | bei Release |
| Measure | Tool / Method | Frequency |
|----------------------------------|------------------------------|------------------|
| Traceability check | `doorstop check` | every push |
| MISRA check | Cppcheck + MISRA addon | every push |
| Static analysis | Cppcheck, clang-tidy | every push |
| Unit tests | CppUTest | every push |
| Coverage | gcov / lcov | every push |
| Peer review | Gitea PRs | every change |
| Architecture review | Technical review, 2 approvers | on changes |
| Audit preparation | doorstop publish + Word docs | on release |
## 3. Reviews
| Artefakt | Review-Typ | Min. Approver |
|-----------------------------|-------------------|----------------|
| Anforderungen | Technical Review | 1 |
| Architektur-Element | Technical Review | 2 |
| Code (QM / ASIL-A/B) | Peer Review | 1 |
| Code (ASIL-C/D) | Technical Review | 2 |
| Plaene und Berichte | Peer Review | 1 |
| MISRA Deviation Permit | Technical Lead | 1 |
| Artefact | Review type | Min. approvers |
|--------------------------------|---------------------|-----------------|
| Requirements | Technical review | 1 |
| Architecture element | Technical review | 2 |
| Code (QM / ASIL-A/B) | Peer review | 1 |
| Code (ASIL-C/D) | Technical review | 2 |
| Plans and reports | Peer review | 1 |
| MISRA deviation permit | Technical lead | 1 |
## 4. Non-Conformity Management
## 4. Non-conformity management
Abweichungen vom Plan oder von Anforderungen werden als Non-Conformity (NC) dokumentiert:
Deviations from the plan or from requirements are documented as a non-conformity (NC):
- Pfad: `docs/non-conformities/NC-XXX.docx`
- Jede NC erhaelt eine eindeutige ID
- Schwere-Klassifizierung: Critical / Major / Minor
- Korrekturmassnahme und Verifikation werden nachgehalten
- Beispiel-NC vorhanden: NC-001
- Path: `docs/non-conformities/NC-XXX.docx`
- Each NC has a unique ID
- Severity classification: Critical / Major / Minor
- Corrective action and verification are tracked
- Example NC present: NC-001
## 5. Audit-Vorbereitung
## 5. Audit preparation
Audit-Faehigkeit wird durchgehend erhalten:
Audit readiness is maintained continuously:
- Git-History ist Audit-Trail (kein direkter Push auf `main`)
- `docs/plans-md/` enthaelt die freigegebenen Plaene (Word in `docs/` daneben)
- `docs/traceability/` enthaelt automatisch generierte Matrizen
- `misra/records/` enthaelt MISRA-Deviation-Records
- `tests/results/` enthaelt Test- und Coverage-Reports (CI-Artefakte)
- `docs/reviews/` enthaelt Review-Protokolle
- Git history is the audit trail (no direct push to `main`)
- `docs/plans-md/` holds the released plans (Word in `docs/` alongside)
- `docs/traceability/` holds the auto-generated matrices
- `misra/records/` holds MISRA deviation records
- `tests/results/` holds test and coverage reports (CI artefacts)
- `docs/reviews/` holds review minutes
## 6. Verbesserungsmassnahmen
## 6. Improvement actions
Jeder Sprint-Abschluss enthaelt eine kurze Lessons-Learned-Notiz in `docs/lessons-learned/`. In dieser Demo verzichtet, da Single-Sprint-Projekt.
Every sprint closure includes a brief lessons-learned note in `docs/lessons-learned/`. Skipped in this demo because it is a single-sprint project.
docs/plans-md/RM-Plan.md
+74 -77
View File
@@ -1,111 +1,108 @@
---
doc-id: SLM-EPB-RM-001
version: 1.0
status: Freigegeben
datum: 2026-05-12
status: Released
date: 2026-05-12
---
# Risk Management Plan (RM-Plan)
# Risk Management Plan (RM Plan)
| Feld | Wert |
|--------------|----------------------------------------|
| Projekt | demo-epb |
| Dokument-ID | SLM-EPB-RM-001 |
| Version | 1.0 |
| Status | Freigegeben |
| Datum | 2026-05-12 |
| Norm | ASPICE MAN.5 |
| Field | Value |
|---------------|----------------------------------------|
| Project | demo-epb |
| Document ID | SLM-EPB-RM-001 |
| Version | 1.0 |
| Status | Released |
| Date | 2026-05-12 |
| Standard | ASPICE MAN.5 |
---
## 1. Zweck
## 1. Purpose
Identifiziert, bewertet und behandelt **Projekt-Risiken** (organisatorisch,
technisch, Zeitplan, Resource). Abgegrenzt von **funktionalen Sicherheits-
Risiken** (Hazards), die im HARA behandelt werden.
Identifies, assesses, and treats **project risks** (organisational, technical, schedule, resource). Distinct from **functional safety risks** (hazards), which live in the HARA.
## 2. Methodik
## 2. Methodology
| Schritt | Aktion |
|--------------------|-------------------------------------------------|
| 1. Identifikation | Workshops, Lessons-Learned, Stakeholder-Input |
| 2. Klassifikation | Wahrscheinlichkeit (W) x Auswirkung (A) |
| 3. Bewertung | Risk Score = W * A (1-25) |
| 4. Behandlung | Vermeiden / Mindern / Akzeptieren / Transferieren |
| 5. Monitoring | Quartalsweise Review, Statusupdate |
| Step | Activity |
|-------------------|---------------------------------------------------|
| 1. Identification | Workshops, lessons learned, stakeholder input |
| 2. Classification | Probability (P) × Impact (I) |
| 3. Assessment | Risk score = P × I (1-25) |
| 4. Treatment | Avoid / Mitigate / Accept / Transfer |
| 5. Monitoring | Quarterly review, status updates |
### 2.1 Klassifikations-Skala
### 2.1 Classification scale
| Wahrscheinlichkeit | Bedeutung |
|--------------------|----------------------------|
| 1 | Sehr unwahrscheinlich |
| 2 | Unwahrscheinlich |
| 3 | Moeglich |
| 4 | Wahrscheinlich |
| 5 | Sehr wahrscheinlich |
| Probability | Meaning |
|-------------|----------------------------|
| 1 | Very unlikely |
| 2 | Unlikely |
| 3 | Possible |
| 4 | Likely |
| 5 | Very likely |
| Auswirkung | Bedeutung |
|------------|--------------------------------------------|
| 1 | Vernachlaessigbar |
| 2 | Geringe Verzoegerung / Mehraufwand |
| 3 | Spuerbare Auswirkung auf Termin/Budget |
| 4 | Erhebliche Auswirkung, Projekt gefaehrdet |
| 5 | Projekt-Stop |
| Impact | Meaning |
|--------|------------------------------------------|
| 1 | Negligible |
| 2 | Minor delay / additional effort |
| 3 | Noticeable impact on schedule/budget |
| 4 | Significant impact, project at risk |
| 5 | Project stop |
| Score-Bereich | Aktion |
|---------------|------------------------------------------|
| 1-4 | Akzeptieren, monitoren |
| 5-9 | Mindern (Plan) |
| 10-15 | Mindern (sofort, mit Eskalation) |
| 16-25 | Eskalation an Project Owner |
| Score range | Action |
|-------------|----------------------------------------|
| 1-4 | Accept, monitor |
| 5-9 | Mitigate (plan) |
| 10-15 | Mitigate (immediate, with escalation) |
| 16-25 | Escalate to Project Owner |
## 3. Risiko-Register
## 3. Risk register
| ID | Beschreibung | W | A | Score | Behandlung | Status |
|-------|---------------------------------------------------------|---|---|-------|------------------------------------------|----------|
| R-01 | Demo wird als produktreifer Code missverstanden | 3 | 3 | 9 | Disclaimer im README + Project Manual | Mitigated |
| R-02 | MISRA-Tooling-Update bricht CI (false positives) | 2 | 3 | 6 | Tool-Versionen pinnen, Regression-Suite | Mitigated |
| R-03 | Reviewer-Verfuegbarkeit fuer ASIL-D | 3 | 4 | 12 | Self-Review dokumentiert (nur Demo) | Akzeptiert (Demo) |
| R-04 | Gitea-Server-Ausfall | 2 | 4 | 8 | Lokale Klone, regelmaessige Backups | Mitigated |
| R-05 | Apple-Cert-Ablauf ohne Vorwarnung | 3 | 3 | 9 | Renewal-Reminder + 30-Tage-Vorwarnung | Mitigated |
| R-06 | Windows-Build-VM unzuverlaessig (busybox-PATH-Konflikte)| 4 | 2 | 8 | MSYS2 dokumentiert, alt PATH vorne | Open |
| R-07 | macOS act_runner host-mode Cache-Bug | 3 | 2 | 6 | continue-on-error, dokumentiert | Open |
| R-08 | Doorstop-Tooling-Kompatibilitaet bei Update | 2 | 3 | 6 | Eigenes traceability.py, kein doorstop-Dep | Mitigated |
| R-09 | Wissensverlust bei Single-Person-Setup | 4 | 4 | 16 | Project Manual + Dokumentation pflegen | Open |
| ID | Description | P | I | Score | Treatment | Status |
|-------|----------------------------------------------------------|---|---|-------|------------------------------------------|------------|
| R-01 | Demo is mistaken for production-ready code | 3 | 3 | 9 | Disclaimer in README + Project Manual | Mitigated |
| R-02 | MISRA tooling update breaks CI (false positives) | 2 | 3 | 6 | Pin tool versions, regression suite | Mitigated |
| R-03 | Reviewer availability for ASIL-D | 3 | 4 | 12 | Self-review documented (demo only) | Accepted (demo) |
| R-04 | Gitea server outage | 2 | 4 | 8 | Local clones, regular backups | Mitigated |
| R-05 | Apple certificate expiry without warning | 3 | 3 | 9 | Renewal reminder + 30-day notice | Mitigated |
| R-06 | Windows build VM unreliable (busybox-PATH conflicts) | 4 | 2 | 8 | MSYS2 documented, alt PATH ordering | Open |
| R-07 | macOS act_runner host-mode cache bug | 3 | 2 | 6 | continue-on-error, documented | Open |
| R-08 | Doorstop tool compatibility on upgrade | 2 | 3 | 6 | Own traceability.py, no doorstop dep | Mitigated |
| R-09 | Knowledge loss with single-person setup | 4 | 4 | 16 | Maintain Project Manual + documentation | Open |
## 4. Risiko-Reviews
## 4. Risk reviews
| Frequenz | Teilnehmer | Outputs |
|--------------|-------------------------|--------------------------------------|
| Quartalsweise| Project Owner + TL | Aktualisiertes Register, Action-Items |
| Bei Aenderung| Betroffene Rollen | Risiko-Score-Update |
| Bei Release | Project Owner + QA | Restrisiken-Bewertung |
| Frequency | Participants | Outputs |
|--------------|--------------------------|--------------------------------------|
| Quarterly | Project Owner + TL | Updated register, action items |
| On change | Affected roles | Risk score update |
| At release | Project Owner + QA | Residual-risk assessment |
## 5. Eskalations-Pfad
## 5. Escalation path
```
R-Owner (taeglich)
Risk owner (daily)
│ Score > 9
▼
Project Owner (woechentlich)
Project Owner (weekly)
│ Score > 15
▼
Stakeholder / Auftraggeber (sofort)
Stakeholder / Client (immediately)
```
## 6. Lessons Learned
## 6. Lessons learned
Geschlossene Risiken werden bei Projektabschluss in `docs/lessons-learned/`
zusammengefasst, um in Folge-Projekten besser einschaetzen zu koennen.
Closed risks are summarised at project closure under `docs/lessons-learned/`, to better assess follow-up projects.
## 7. Verwandte Dokumente
## 7. Related documents
- `PM-Plan.docx` — Top-Level-Risiken (Auszug)
- `HARA.docx` — Funktionale Sicherheits-Risiken (Hazards, getrennt von Projekt-Risiken)
- `QA-Plan.docx` — Non-Conformity-Management
- `PM-Plan.docx` — Top-level risks (summary)
- `HARA.docx` — Functional safety risks (hazards, separate from project risks)
- `QA-Plan.docx` — Non-conformity management
## 8. Aenderungshistorie
## 8. Revision history
| Version | Datum | Aenderung | Autor |
|---------|-------------|---------------------|-------------|
| 1.0 | 2026-05-12 | Erstfreigabe | S. Lohmaier |
| Version | Date | Change | Author |
|---------|-------------|---------------------|------------|
| 1.0 | 2026-05-12 | First release | S. Lohmaier|
docs/plans-md/SWE-Plan.md
+78 -78
View File
@@ -1,114 +1,114 @@
# Software Development Plan (SWE-Plan)
# Software Development Plan (SWE Plan)
| Feld | Wert |
| Field | Value |
|-----------------|--------------------------------------|
| Projekt | demo-epb |
| Datum | 2026-05-11 |
| Project | demo-epb |
| Date | 2026-05-11 |
| Version | 1.0 |
| Status | Freigegeben |
| ASIL | D (hoechste Komponente) |
| Status | Released |
| ASIL | D (highest component) |
---
## 1. Entwicklungsmethode
## 1. Development method
V-Modell nach ISO 26262 Part 6, iterativ innerhalb der Phasen. Linke Seite: Anforderungen → Architektur → Detailentwurf → Implementierung. Rechte Seite: Unit-Test → Integrationstest → Systemtest.
V-model per ISO 26262 Part 6, iterative within phases. Left side: requirements → architecture → detailed design → implementation. Right side: unit test → integration test → system test.
Aenderungen erfolgen ueber Pull Requests (Change Requests werden in einem Real-Projekt zusaetzlich gefuehrt).
Changes go through pull requests (change requests are tracked separately in a real project).
## 2. Programmiersprache und Standards
## 2. Programming language and standards
| Aspekt | Festlegung |
| Aspect | Decision |
|---------------------|-----------------------------------------------------|
| Sprache | C (C99) |
| Coding Standard | MISRA C:2012 (Required + Mandatory einzuhalten) |
| Naming | snake_case fuer Funktionen, UPPER_CASE fuer Makros |
| Header-Format | `@file`, `@arch`, `@reqs` Tags fuer Code → Doku-Link |
| Language | C (C99) |
| Coding standard | MISRA C:2012 (Required + Mandatory mandatory) |
| Naming | snake_case for functions, UPPER_CASE for macros |
| Header format | `@file`, `@arch`, `@reqs` tags linking code to docs |
### MISRA-Handhabung
### MISRA handling
- Required- und Mandatory-Regeln verpflichtend
- Advisory-Regeln projektspezifisch (siehe `misra/permits/`)
- Abweichungen pro Stelle: MISRA Deviation Record (`misra/records/`)
- Projektweite Abweichungen: MISRA Deviation Permit (`misra/permits/`)
- MISRA-Pruefung in der CI (`cppcheck --addon=misra --error-exitcode=1`)
- Required and Mandatory rules are mandatory
- Advisory rules are project-specific (see `misra/permits/`)
- Per-site deviations: MISRA deviation record (`misra/records/`)
- Project-wide deviations: MISRA deviation permit (`misra/permits/`)
- MISRA check runs in CI (`cppcheck --addon=misra --error-exitcode=1`)
## 3. Build-Umgebung
## 3. Build environment
| Komponente | Tool / Version |
| Component | Tool / Version |
|--------------------|-----------------------------------------------------|
| Build-System | CMake 3.20+ |
| Compiler | GCC (Host fuer Demo-Tests; ARM-GCC fuer Target) |
| Zielplattform | ARM Cortex-M4 (Annahme; Demo-Tests auf x86_64 Host) |
| Host-Plattform | macOS / Linux x86_64 |
| CI-Runner | Gitea Actions Docker-Image |
| Build system | CMake 3.20+ |
| Compiler | GCC (host for demo tests; ARM-GCC for target) |
| Target platform | ARM Cortex-M4 (assumption; demo tests run on x86_64 host) |
| Host platform | macOS / Linux x86_64 |
| CI runner | Gitea Actions Docker image |
## 4. Branching-Strategie
## 4. Branching strategy
```
main — Stabiler, freigegebener Stand
develop — Aktueller Entwicklungsstand
feature/SWE-XXX — Feature-Branch pro Anforderung
bugfix/BUG-XXX — Bugfix-Branch
main — stable, released state
develop — current development state
feature/SWE-XXX — feature branch per requirement
bugfix/BUG-XXX — bug-fix branch
```
- `main` und `develop` sind geschuetzt (kein direkter Push)
- Merge nur ueber PR mit Approval
- Branch-Name enthaelt Issue- oder Anforderungs-Nummer
- `main` and `develop` are protected (no direct push)
- Merge only via PR with approval
- Branch name includes the issue or requirement number
## 5. Review-Verpflichtungen
## 5. Review obligations
| Artefakt | Review-Art | Mindest-Approvals |
|-----------------------------|-------------------|--------------------|
| Quellcode QM / ASIL-A/B | Peer Review | 1 |
| Quellcode ASIL-C/D | Technical Review | 2 |
| Architektur-Dokument | Technical Review | 2 |
| Anforderung | Technical Review | 1 |
| Testfaelle | Peer Review | 1 |
| MISRA Permit | Technical Lead | 1 |
| Artefact | Review type | Min. approvals |
|-----------------------------|---------------------|-----------------|
| Source code QM / ASIL-A/B | Peer review | 1 |
| Source code ASIL-C/D | Technical review | 2 |
| Architecture document | Technical review | 2 |
| Requirement | Technical review | 1 |
| Test cases | Peer review | 1 |
| MISRA permit | Technical lead | 1 |
Single-Person-Demo: Self-Review mit dokumentierter Pruefliste; in einem Real-Projekt nicht zulaessig.
Single-person demo: self-review with documented checklist; not permissible in a real project.
## 6. Definition of Done
- Code kompiliert fehlerfrei
- MISRA-Check in CI ist gruen
- Statische Analyse (Cppcheck, clang-tidy) ohne neue Findings
- Unit Tests gruen
- Coverage-Ziel erreicht
- PR reviewed und approved
- Anforderung mit Test verlinkt (`@reqs` Tag im Code + Test-Datei)
- Architektur-Element verlinkt (`@arch` Tag im Code)
- Code compiles without errors
- MISRA check in CI is green
- Static analysis (Cppcheck, clang-tidy) has no new findings
- Unit tests are green
- Coverage target reached
- PR reviewed and approved
- Requirement linked to a test (`@reqs` tag in code + test file)
- Architecture element linked (`@arch` tag in code)
## 7. Integration und Test-Strategie
## 7. Integration and test strategy
| Teststufe | Verantwortlich | Umgebung | Automatisierung |
|---------------------|----------------|----------------|-----------------|
| Unit Test | Entwickler | Host (x86) | CI |
| Integrationstest | Entwickler | Host / SiL | CI / manuell |
| Systemtest | QA | SiL / HiL | teilweise |
| Abnahmetest | Auftraggeber | HiL / Fahrzeug | manuell |
| Test level | Owner | Environment | Automation |
|--------------------|----------------|---------------|------------------|
| Unit test | Developer | Host (x86) | CI |
| Integration test | Developer | Host / SiL | CI / manual |
| System test | QA | SiL / HiL | partial |
| Acceptance test | Customer | HiL / vehicle | manual |
Demo: nur Unit-Tests auf Host.
Demo: only unit tests on host.
## 8. Coverage-Ziele
## 8. Coverage targets
| ASIL | Statement | Branch | MC/DC | Konkret im Projekt |
|------|-----------|--------|----------|---------------------|
| QM | >= 80% | — | — | Switch Debouncer |
| B | >= 80% | >= 80% | — | Actuator Driver |
| D | >= 90% | >= 90% | >= 80% | Apply Controller |
| ASIL | Statement | Branch | MC/DC | Concrete in this project |
|------|-----------|--------|----------|---------------------------|
| QM | ≥ 80% | — | — | Switch Debouncer |
| B | ≥ 80% | ≥ 80% | — | Actuator Driver |
| D | ≥ 90% | ≥ 90% | ≥ 80% | Apply Controller |
Coverage wird per `gcov` / `lcov` in der CI gemessen und nach `tests/results/coverage/` abgelegt.
Coverage is measured via `gcov` / `lcov` in CI and stored under `tests/results/coverage/`.
## 9. Toolqualifikation
## 9. Tool qualification
| Tool | Verwendung | Qualifikations-Status (Demo) |
|-------------------|------------------------------|----------------------------------------------|
| GCC | Compilation | Eigene Qualifizierung (in Realprojekt) |
| Cppcheck + MISRA | Statische Analyse / MISRA | Tool-Confidence Level TCL2 / Tool-Class T2 |
| CppUTest | Unit-Tests | TCL1 / T1 (Fehler vom Entwickler erkannt) |
| gcov / lcov | Coverage | TCL1 / T1 |
| Doorstop | Traceability | TCL1 / T1 |
| Tool | Use | Qualification status (demo) |
|-------------------|------------------------------|-----------------------------------------------|
| GCC | Compilation | Own qualification (in real project) |
| Cppcheck + MISRA | Static analysis / MISRA | Tool Confidence Level TCL2 / Tool Class T2 |
| CppUTest | Unit tests | TCL1 / T1 (defects caught by developer) |
| gcov / lcov | Coverage | TCL1 / T1 |
| Doorstop | Traceability | TCL1 / T1 |
Demo enthaelt keine vollstaendigen Tool-Qualification-Reports; in einem Real-Projekt waeren diese im Anhang.
The demo does not include full tool-qualification reports; in a real project these would live in an appendix.
docs/plans-md/Test-Plan.md
+42 -42
View File
@@ -1,63 +1,63 @@
# Test-Plan
# Test Plan
| Feld | Wert |
| Field | Value |
|-----------------|--------------------------------------|
| Projekt | demo-epb |
| Datum | 2026-05-11 |
| Project | demo-epb |
| Date | 2026-05-11 |
| Version | 1.0 |
| Status | Freigegeben |
| Status | Released |
---
## 1. Teststrategie
## 1. Test strategy
Test-First fuer alle Demo-Komponenten. Jede Anforderung erhaelt mindestens einen Test (`@reqs` Tag im Test). Coverage-Ziele wie im SWE-Plan Abschnitt 8.
Test-first for all demo components. Every requirement has at least one test (`@reqs` tag in the test). Coverage targets as in the SWE Plan section 8.
## 2. Teststufen
## 2. Test levels
| Stufe | Scope | Tool | Umgebung | Demo-Status |
|---------------|--------------------|------------|------------|-------------|
| Unit | Funktionen / Module| CppUTest | Host x86 | Vorhanden |
| Integration | Modulzusammenspiel | CppUTest | Host x86 | TBD |
| System | End-to-end | manuell | SiL / HiL | nicht im Demo |
| Abnahme | Kundenabnahme | manuell | HiL / KFZ | nicht im Demo |
| Level | Scope | Tool | Environment | Demo status |
|---------------|--------------------|------------|-------------|---------------|
| Unit | Functions / modules| CppUTest | host x86 | Available |
| Integration | Module interaction | CppUTest | host x86 | TBD |
| System | End-to-end | manual | SiL / HiL | not in demo |
| Acceptance | Customer acceptance| manual | HiL / vehicle | not in demo |
## 3. Test-Verwaltung
## 3. Test management
- Tests liegen in `tests/unit/` (eine Datei pro Modul)
- Test-Datei enthaelt `@reqs` Tag mit den abgedeckten Anforderungs-IDs
- Test-Lauf erfolgt automatisch in der CI bei jedem Push
- Coverage-Report wird als CI-Artefakt unter `tests/results/coverage/` abgelegt
- Tests live in `tests/unit/` (one file per module)
- Each test file carries an `@reqs` tag with the covered requirement IDs
- Tests run automatically in CI on every push
- Coverage report is uploaded as a CI artefact under `tests/results/coverage/`
## 4. Test-Auswahl je Komponente
## 4. Test selection per component
| Komponente | ASIL | Test-Datei | Methodik |
|--------------------|------|--------------------------------------|--------------------------|
| Apply Controller | D | tests/unit/test_apply_controller.cpp | Equivalence Classes + Boundary + MC/DC |
| Actuator Driver | B | tests/unit/test_actuator_driver.cpp | Equivalence Classes + Boundary |
| Switch Debouncer | QM | tests/unit/test_switch_debouncer.cpp | Equivalence Classes |
| Component | ASIL | Test file | Method |
|--------------------|------|---------------------------------------|---------------------------------|
| Apply Controller | D | tests/unit/test_apply_controller.c | Equivalence classes + boundary + MC/DC |
| Actuator Driver | B | tests/unit/test_actuator_driver.c | Equivalence classes + boundary |
| Switch Debouncer | QM | tests/unit/test_switch_debouncer.c | Equivalence classes |
## 5. Eingangs- und Abschlusskriterien
## 5. Entry and exit criteria
**Eingang fuer Testdurchfuehrung:**
- Code kompiliert
- Doorstop-Check gruen
- Statische Analyse ohne kritische Findings
**Entry to test execution:**
- Code compiles
- Doorstop check is green
- Static analysis has no critical findings
**Abschluss:**
- Alle Tests gruen
- Coverage-Ziel erreicht
- Test-Report archiviert
**Exit:**
- All tests green
- Coverage target reached
- Test report archived
## 6. Fehlerverwaltung
## 6. Defect handling
- Test-Fehlschlag = blockendes Issue
- Issue wird ueber Gitea Issues angelegt, im PR referenziert
- Schwere-Kategorisierung wie in QA-Plan Abschnitt 4
- Test failure = blocking issue
- Issue is filed via Gitea Issues, referenced in the PR
- Severity classification per QA Plan section 4
## 7. Reporting
Test-Reports werden automatisch erzeugt:
- Konsolen-Output von CppUTest (TAP / JUnit XML)
- Coverage-HTML aus lcov
- Beides als CI-Artefakt unter `tests/results/`
Test reports are generated automatically:
- Console output of CppUTest (TAP / JUnit XML)
- Coverage HTML from lcov
- Both as CI artefacts under `tests/results/`