---
doc-id: SLM-EPB-CM-001
version: 1.0
status: Freigegeben
datum: 2026-05-12
---

# 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          |

---

## 1. Zweck

Beschreibt, wie Konfigurations-Items identifiziert, versioniert, freigegeben
und kontrolliert geaendert werden.

## 2. Configuration Items (CIs)

Folgende Artefakte stehen unter Konfigurationskontrolle:

| Typ                     | Pfad                                   | Versionierung                |
|-------------------------|----------------------------------------|------------------------------|
| 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     |
| Safety Goals            | `safety/sg/*.md`                        | Git                          |
| Plaene (Word)           | `docs/plaene/*.docx`                    | Git + Dokument-Versionsblock |
| Safety-Doku (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                          |
| Tools                   | `tools/*.py`                            | Git                          |

## 3. Repository-Struktur

- **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)

## 4. Baselines

Eine Baseline ist ein eingefrorener, freigegebener Stand. Baselines werden durch
Git-Tags gesetzt.

| Baseline-Typ              | Tag-Schema       | Wann                                  |
|---------------------------|-------------------|----------------------------------------|
| 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        |

Jeder Tag triggert (bei `vX.Y.Z`) den Release-Workflow, der ein Bundle erzeugt.

## 5. Versions-Schema

| Artefakt              | Schema                                  |
|-----------------------|------------------------------------------|
| 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        |

## 6. Change Control

Aenderungen an Configuration Items erfolgen ueber:

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

| Asil    | Reviewer-Mindestanzahl              |
|---------|--------------------------------------|
| QM      | 1                                    |
| ASIL-A/B| 1                                    |
| ASIL-C  | 2 (mind. 1 Technical Reviewer)       |
| ASIL-D  | 2 Technical Reviewer + Safety Manager|

Reviews werden in `docs/reviews/REV-XXX.docx` dokumentiert.

## 7. Release-Prozess

```
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 "..."
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
```

## 8. Aufbewahrung

| Artefakt                 | Aufbewahrungsdauer                    |
|--------------------------|----------------------------------------|
| 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)           |

ISO 26262 fordert 10 Jahre nach End-of-Production-Life (Annahme).

## 9. Verifikation

Alle Pull Requests laufen durch:
- `doorstop`-aequivalenter Traceability-Check (`tools/traceability.py check`)
- Build + Unit-Tests
- Static Analysis + MISRA-Check
- Coverage-Messung

Erst nach Approval und CI-Gruen kann der Merge nach `main` erfolgen.

## 10. Verantwortlichkeiten

| 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                                  |

## 11. Aenderungshistorie

| Version | Datum       | Aenderung           | Autor       |
|---------|-------------|---------------------|-------------|
| 1.0     | 2026-05-12  | Erstfreigabe        | S. Lohmaier |