Official Purpose Statement: "The purpose of the Configuration Management Process is to establish and maintain the integrity of all the work products of a process or project and make them available to concerned parties."
SUP.8 is the infrastructure process that makes every other ASPICE process auditable. Without configuration management, you cannot prove: which version of the SRS was reviewed, what source code was compiled into the delivered binary, whether a defect fix was actually applied to the release build, or when a change was made and by whom. CL2 for every engineering process depends on SUP.8 being functional, because GP 2.2.2 and GP 2.2.3 require work products to be CM-controlled.
📋 Learning Objectives
- Define the CM plan contents required by ASPICE SUP.8
- Establish a CM system covering both code and non-code work products (documents, models, test specifications)
- Define and enforce baselines at project milestones
- Demonstrate build reproducibility as required by ASPICE
- Operate a CM audit procedure and report findings
SUP.8 Base Practices
| BP | Name | What It Requires | Evidence | Common Failure |
|---|---|---|---|---|
| BP1 | Develop a CM strategy | Configuration Management Plan (CMP) defining: which items are under CM (Configuration Items / CIs - all work products, source code, tools, and their versions), the CM system used (Git, SVN, SharePoint, PLM), naming conventions, versioning scheme, baseline policy (when, who, how), access control, backup policy. | Configuration Management Plan document | CMP either absent or covers only source code; document artifacts stored on unversioned shared drives |
| BP2 | Identify configuration items | Every work product produced in the project is assigned a CI identifier. CIs include: source code, SRS, SAD, SDDD, test specifications, test reports, AUTOSAR ARXML files, calibration files, tool configurations, BSW deliverables from suppliers. Each CI has: a unique ID, a current version, a responsible custodian. | Configuration Item list / CI registry | Source code in Git, everything else "managed" by email and file sharing; ARXML not under formal CM; calibration files overwritten without history |
| BP3 | Control modifications and releases | Changes to baselined CIs follow a controlled process: change request (SUP.10 interface) → approval → implementation → verification → CM update. No CI is modified post-baseline without a CR. Releases are tagged builds - a delivery binary can be traced to an exact tagged commit and configuration state. | Version control history showing change references; release tags; build configuration records | Hotfixes applied directly to the release branch without a CR; "we'll document it later" - later never comes |
| BP4 | Establish baselines | Baselines are established at defined project milestones (e.g., SRS baseline after M2 review, SW baseline at each prototype delivery, release baseline for production delivery). A baseline is a snapshot of a defined set of CIs at a known state - immutable after creation. Baseline records show: baseline ID, date, CI list with version per CI, authorizing role. | Baseline records: one per milestone; CI version matrix per baseline | Baselines defined in the CMP but never created in practice; or "the last tagged version" is treated as a baseline without a formal baseline record |
| BP5 | Control CM system | The CM tool is configured to enforce access control (who can commit, who can create tags, who can baseline), prevent deletion of history, and send notifications on changes to protected branches. CM system availability is ensured (backup, access during power outage / remote work). CM system version itself is documented. | Git configuration (branch protection rules, required reviews); backup records; CM tool version documented | Git used but no branch protection; force-push to main allowed; no backup policy; repository could be accidentally deleted |
| BP6 | Perform CM audits | Periodic audits verify that: the CI registry is current (all active CIs listed), baselines are intact (no post-baseline changes without a CR), work products can be retrieved in their baseline state, the build can be reproduced from the baseline. CM audit results are documented and discrepancies resolved. | CM audit records (periodic, at least once per project phase); audit findings and resolution evidence | CM audits never performed; first CM audit is the ASPICE assessment itself - at which point discrepancies are found but cannot be retroactively resolved |