demo-epb/docs/plans-md/CM-Plan.md

doc-id, version, status, date

doc-id	version	status	date
SLM-EPB-CM-001	1.0	Released	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