ba7a3ebd27
Last German folder name in demo-epb. Pairs cleanly with docs/plans-md/ (markdown source) following the project convention. All references in landing page generator, CI workflows, and cross-doc links updated.
147 lines
6.4 KiB
Markdown
147 lines
6.4 KiB
Markdown
---
|
|
doc-id: SLM-EPB-CM-001
|
|
version: 1.0
|
|
status: Released
|
|
date: 2026-05-12
|
|
---
|
|
|
|
# Configuration Management Plan (CM Plan)
|
|
|
|
| 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. Purpose
|
|
|
|
Describes how configuration items are identified, versioned, released, and controlled-change managed.
|
|
|
|
## 2. Configuration Items (CIs)
|
|
|
|
The following artefacts are under configuration control:
|
|
|
|
| Type | Path | Versioning |
|
|
|-------------------------|----------------------------------------|------------------------------|
|
|
| Source code | `src/**/*.{c,h}` | Git |
|
|
| Tests | `tests/**` | Git |
|
|
| Requirements | `reqs/{sys,swe}/*.md` | Git + Doorstop item hash |
|
|
| Architecture | `arch/{sys,swe}/*.md` | Git + Doorstop item hash |
|
|
| Safety Goals | `safety/sg/*.md` | Git |
|
|
| Plans (Word) | `docs/plans/*.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 configuration | `.gitea/workflows/*.yml` | Git |
|
|
| Build definition | `Makefile`, `Doxyfile` | Git |
|
|
| Tools | `tools/*.py` | Git |
|
|
|
|
## 3. Repository structure
|
|
|
|
- **Remote:** https://gitea.slohmaier.com/slohmaier/demo-epb
|
|
- **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
|
|
|
|
A baseline is a frozen, released state. Baselines are set via git tags.
|
|
|
|
| Baseline type | Tag scheme | When |
|
|
|---------------------------|-------------------|----------------------------------------|
|
|
| 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 |
|
|
|
|
Every tag (specifically `vX.Y.Z`) triggers the release workflow, which produces a bundle.
|
|
|
|
## 5. Versioning scheme
|
|
|
|
| Artefact | Scheme |
|
|
|-----------------------|------------------------------------------|
|
|
| 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
|
|
|
|
Changes to configuration items occur via:
|
|
|
|
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 | 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 are documented in `docs/reviews/REV-XXX.docx`.
|
|
|
|
## 7. Release process
|
|
|
|
```
|
|
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 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. Retention
|
|
|
|
| Artefact | Retention |
|
|
|--------------------------|----------------------------------------|
|
|
| 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 requires 10 years after end-of-production-life (assumption).
|
|
|
|
## 9. Verification
|
|
|
|
All pull requests pass through:
|
|
- Doorstop-equivalent traceability check (`tools/traceability.py check`)
|
|
- Build + unit tests
|
|
- Static analysis + MISRA check
|
|
- Coverage measurement
|
|
|
|
Only after approval and green CI may a merge into `main` occur.
|
|
|
|
## 10. Responsibilities
|
|
|
|
| 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. Revision history
|
|
|
|
| Version | Date | Change | Author |
|
|
|---------|-------------|---------------------|------------|
|
|
| 1.0 | 2026-05-12 | First release | S. Lohmaier|
|