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

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
+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: AnforderungenArchitektur → DetailentwurfImplementierung. Rechte Seite: Unit-Test → Integrationstest → Systemtest.
V-model per ISO 26262 Part 6, iterative within phases. Left side: requirementsarchitecturedetailed designimplementation. 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.