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|