5.4: SUP.8 Configuration Management

Configuration Management (CM) is the backbone of repeatable, auditable, and compliant development in safety-critical embedded systems. Without disciplined CM, organizations cannot reliably recreate a build, prove which version of a requirement was tested, or demonstrate to an assessor that a specific baseline was released to production. In ASPICE 4.0, SUP.8 governs how all work products -- requirements documents, architecture models, source code, test cases, build configurations, trained ML models, and documentation -- are identified, versioned, baselined, and controlled throughout the project lifecycle.

AI integration transforms CM from a manual bookkeeping exercise into an intelligent, continuous integrity service. Rather than relying on engineers to remember which files belong in a baseline or manually checking that a commit message follows convention, AI can automatically classify configuration items, validate baseline completeness, detect drift between environments, and generate compliance reports. The human retains authority over baseline approval and release decisions; the AI ensures that the underlying data is consistent, complete, and traceable.

Process Definition

Purpose

SUP.8 Purpose: To establish and maintain the integrity of all work products of the process or project.

Configuration management ensures that every artifact produced during the development lifecycle is uniquely identified, version-controlled, and protected against unauthorized or untracked changes. This is foundational for traceability (required by ASPICE, ISO 26262, and ISO/SAE 21434), reproducibility (the ability to recreate any historical build), and auditability (the ability to demonstrate compliance to an external assessor).

Outcomes

Relationship to Other Processes

SUP.8 provides essential infrastructure that other ASPICE processes depend on:

Base Practices with AI Integration

Baseline Approval Authority: AI performs completeness and consistency checks, but the Configuration Manager or designated authority retains sole approval for baseline creation. Baselines are formal snapshots that serve as legal evidence in safety-critical domains; their creation requires human judgment and accountability.

Configuration Management Strategy (BP1)

Strategy Components

A CM strategy document defines the rules, tools, and procedures that govern configuration management throughout the project. AI assists by generating strategy templates tailored to the project's technology stack and compliance requirements.

Branching Strategy

A disciplined branching model is essential for parallel development, release management, and baseline traceability. The following strategy is typical for automotive embedded projects:

Commit Message Convention

Consistent commit messages enable automated changelog generation, traceability linking, and AI-based classification. The following convention is enforced by pre-commit hooks and CI validation:

<type>(<scope>): <description>

[optional body]

[optional footer(s)]
Refs: <ticket-id>

AI Enforcement: A pre-commit hook validates the commit message format. If the message does not match the convention, the commit is rejected with a descriptive error message. AI can also suggest corrections for malformed messages.

Configuration Item Identification (BP2)

CI Catalog

The CI catalog is the master inventory of all work products under configuration control. AI assists by scanning the repository structure, file types, and project conventions to recommend items that should be tracked.

Note: Repository URL patterns (polarion://, git://, git-lfs://) are illustrative; adapt to actual infrastructure.

# Configuration Item Catalog
ci_catalog:
  project: BCM Door Lock Control
  version: 2.0
  last_updated: 2025-12-17
  maintained_by: Configuration Manager

  configuration_items:
    # Requirements
    - id: CI-REQ-001
      name: System Requirements Specification
      type: document
      format: Polarion Live Document
      location: polarion://BCM/SYS  # Adapt to actual tool URL
      owner: System Architect
      baseline: included
      safety_relevant: true
      change_control: SUP.10 CR required

    - id: CI-REQ-002
      name: Software Requirements Specification
      type: document
      format: Polarion Live Document
      location: polarion://BCM/SWE
      owner: SW Lead
      baseline: included
      safety_relevant: true
      change_control: SUP.10 CR required

    # Architecture
    - id: CI-ARCH-001
      name: System Architecture
      type: model
      format: Enterprise Architect (.eap)
      location: git://bcm-project/architecture/system_arch.eap
      owner: System Architect
      baseline: included
      safety_relevant: true
      change_control: SUP.10 CR required

    - id: CI-ARCH-002
      name: Software Architecture
      type: model
      format: Enterprise Architect (.eap) + Markdown descriptions
      location: git://bcm-project/architecture/sw_arch/
      owner: SW Architect
      baseline: included
      safety_relevant: true
      change_control: SUP.10 CR required

    # Source Code
    - id: CI-SRC-001
      name: Application Layer Source
      type: code
      format: C99 source and headers
      location: git://bcm-project/src/app/*
      owner: SW Lead
      baseline: included
      safety_relevant: true
      change_control: merge request with review

    - id: CI-SRC-002
      name: MCAL Configuration
      type: code
      format: C99 source, AUTOSAR XML configuration
      location: git://bcm-project/src/mcal/*
      owner: HW/SW Integration Lead
      baseline: included
      safety_relevant: true
      change_control: merge request with review

    - id: CI-SRC-003
      name: Board Support Package
      type: code
      format: C99 source, linker scripts
      location: git://bcm-project/src/bsp/*
      owner: HW/SW Integration Lead
      baseline: included
      safety_relevant: true
      change_control: merge request with review

    # Test Artifacts
    - id: CI-TEST-001
      name: Unit Test Suite
      type: code
      format: C test source (Unity/CMock framework)
      location: git://bcm-project/test/unit/*
      owner: Test Lead
      baseline: included
      safety_relevant: true
      change_control: merge request with review

    - id: CI-TEST-002
      name: Integration Test Suite
      type: code
      format: Robot Framework / pytest
      location: git://bcm-project/test/integration/*
      owner: Test Lead
      baseline: included
      safety_relevant: true
      change_control: merge request with review

    - id: CI-TEST-003
      name: System Test Specifications
      type: document
      format: Polarion Test Cases
      location: polarion://BCM/TEST
      owner: Test Lead
      baseline: included
      safety_relevant: true
      change_control: SUP.10 CR required

    # Build Configuration
    - id: CI-BUILD-001
      name: Build Configuration
      type: configuration
      format: CMake files, toolchain definitions
      location: git://bcm-project/tools/cmake/*
      owner: DevOps
      baseline: included
      safety_relevant: true
      change_control: merge request with review

    - id: CI-BUILD-002
      name: CI/CD Pipeline Definition
      type: configuration
      format: YAML (GitLab CI / Jenkins)
      location: git://bcm-project/.gitlab-ci.yml
      owner: DevOps
      baseline: included
      safety_relevant: false
      change_control: merge request with review

    # ML Model (if applicable)
    - id: CI-ML-001
      name: Trained ML Model
      type: binary
      format: TensorRT engine, ONNX
      location: git-lfs://bcm-project/models/*.engine
      owner: ML Lead
      baseline: included
      safety_relevant: true
      change_control: SUP.10 CR required + ML validation record

    # Documentation
    - id: CI-DOC-001
      name: Safety Manual
      type: document
      format: PDF / Word
      location: git://bcm-project/docs/safety/*
      owner: Safety Manager
      baseline: included
      safety_relevant: true
      change_control: SUP.10 CR required

    - id: CI-DOC-002
      name: Release Notes
      type: document
      format: Markdown
      location: git://bcm-project/CHANGELOG.md
      owner: Project Manager
      baseline: included
      safety_relevant: false
      change_control: automated generation from commit history

AI-Assisted CI Discovery

AI scans the repository to detect configuration items that may be missing from the catalog:

AI CI Discovery Report
──────────────────────
Project: BCM Door Lock Control
Scan Date: 2025-12-17

New Files Detected (not in CI catalog):
────────────────────────────────────────
1. src/driver/temp_sensor.c  [RECOMMENDATION: Add as CI-SRC-004]
   - Reason: C source file in tracked directory, safety-relevant path
   - Owner suggestion: HW/SW Integration Lead

2. test/integration/test_temp_compensation.py  [RECOMMENDATION: Add as CI-TEST-004]
   - Reason: Integration test file, references CI-SRC-001

3. docs/design/gpio_timing_analysis.xlsx  [WARNING: Binary in Git]
   - Reason: Binary file should use Git LFS or document management system
   - Owner suggestion: SW Architect

Orphaned CIs (in catalog but not in repository):
─────────────────────────────────────────────────
  None detected.

Stale CIs (not modified in > 180 days):
────────────────────────────────────────
1. CI-DOC-001 (Safety Manual) - Last modified 2025-06-10
   - Action: Verify document is current for next baseline

Confidence: 0.92
Human Action Required:
  □ Review recommendations and update CI catalog
  □ Confirm or reject each suggestion

Automated CM Controls (BP4)

CI/CD Integration

Automated gates in the CI/CD pipeline enforce CM rules without relying on human vigilance for routine checks. The pipeline validates commit messages, branch names, file presence, and traceability before allowing code to proceed.

# GitLab CI/CD CM Controls
stages:
  - validate
  - build
  - test
  - baseline
  - release

cm_validation:
  stage: validate
  script:
    # Check commit message format
    - |
      if ! echo "$CI_COMMIT_MESSAGE" | grep -qE "^(feat|fix|docs|refactor|test|chore)\(.+\):";
      then
        echo "ERROR: Commit message does not follow convention"
        echo "Expected: <type>(<scope>): <description>"
        echo "Example:  feat(door-lock): add temperature compensation"
        exit 1
      fi

    # Check branch naming
    - |
      if ! echo "$CI_COMMIT_BRANCH" | grep -qE "^(main|develop|feature/|bugfix/|release/|hotfix/)";
      then
        echo "ERROR: Branch name does not follow convention"
        echo "Expected: feature/<ticket>/<desc>, bugfix/<ticket>/<desc>, etc."
        exit 1
      fi

    # Check for required files
    - test -f CHANGELOG.md
    - test -f VERSION

    # Validate traceability
    - python scripts/validate_traceability.py

    # AI: Check for unauthorized modifications to protected CIs
    - python scripts/check_protected_ci_modifications.py

baseline_check:
  stage: baseline
  rules:
    - if: $CI_COMMIT_TAG
  script:
    # Verify all CIs at correct version
    - python scripts/verify_baseline.py --tag $CI_COMMIT_TAG

    # Generate baseline report
    - python scripts/generate_baseline_report.py --output baseline_report.md

    # Check baseline consistency
    - python scripts/check_baseline_consistency.py

    # AI: Verify CI catalog completeness
    - python scripts/ai_ci_discovery.py --mode verify --baseline $CI_COMMIT_TAG

  artifacts:
    paths:
      - baseline_report.md

release:
  stage: release
  rules:
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/
  script:
    # Create release package
    - ./scripts/create_release_package.sh $CI_COMMIT_TAG

    # Generate release notes
    - python scripts/generate_release_notes.py --tag $CI_COMMIT_TAG

    # Archive release artifacts
    - ./scripts/archive_release.sh $CI_COMMIT_TAG

    # AI: Generate compliance evidence package
    - python scripts/generate_compliance_evidence.py --tag $CI_COMMIT_TAG

  artifacts:
    paths:
      - release/*.zip
      - release/release_notes.md
      - release/compliance_evidence.pdf

Pre-Commit Hook Configuration

Local pre-commit hooks provide immediate feedback to developers before changes reach the server:

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      # Commit message convention
      - id: commit-msg-check
        name: Validate commit message format
        entry: scripts/hooks/check_commit_msg.sh
        language: script
        stages: [commit-msg]

      # Prevent large binary files from entering Git
      - id: no-large-binaries
        name: Block large binary files
        entry: scripts/hooks/check_binary_size.sh
        language: script
        args: ['--max-size', '1M']

      # Ensure copyright headers
      - id: copyright-header
        name: Check copyright header in source files
        entry: scripts/hooks/check_copyright.sh
        language: script
        types: [c, header]

      # MISRA compliance quick check
      - id: misra-quick
        name: MISRA C quick check
        entry: scripts/hooks/misra_quick_check.sh
        language: script
        types: [c]

      # Prevent secrets from being committed
      - id: no-secrets
        name: Detect potential secrets
        entry: scripts/hooks/detect_secrets.sh
        language: script

Merge Request Template

Merge request templates ensure that every code change includes the required CM metadata:

## Change Description
<!-- What does this change do? -->

## Related Items
- Change Request: CR-YYYY-NNN (if applicable)
- Problem Report: PR-YYYY-NNN (if applicable)
- Requirement(s): SWE-BCM-XXX

## Configuration Items Modified
<!-- List affected CIs from the CI catalog -->
- [ ] CI-SRC-001 (Application Layer Source)
- [ ] CI-TEST-001 (Unit Test Suite)

## Verification Checklist
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Static analysis clean (no new findings)
- [ ] MISRA compliance verified
- [ ] Documentation updated (if applicable)
- [ ] Traceability links updated

## Reviewer Checklist
- [ ] Code follows project coding standards
- [ ] Change is consistent with architecture
- [ ] Safety impact assessed (if safety-relevant CI modified)
- [ ] CI catalog entry updated (if new files added)

Baseline Management (BP3)

Baseline Types

Baselines are formal snapshots of the configuration at a defined point in time. They serve as reference points for development, testing, release, and audit activities.

Baseline Definition

The following diagram shows the baseline status across project milestones, indicating which configuration items are included, their versions, and the approval status of each baseline.

Baseline Consistency Verification

AI performs automated consistency checks before baseline approval:

AI Baseline Consistency Report
──────────────────────────────
Baseline: BL-BCM-3.0.0-RC1
Type: Development Baseline
Date: 2025-12-15
CI Catalog Version: 2.0

Completeness Check:
───────────────────
  [PASS] CI-REQ-001  System Requirements Specification    v2.3
  [PASS] CI-REQ-002  Software Requirements Specification  v3.1
  [PASS] CI-ARCH-001 System Architecture                  v2.1
  [PASS] CI-ARCH-002 Software Architecture                v2.4
  [PASS] CI-SRC-001  Application Layer Source              commit a1b2c3d
  [PASS] CI-SRC-002  MCAL Configuration                   commit e4f5g6h
  [PASS] CI-SRC-003  Board Support Package                commit i7j8k9l
  [PASS] CI-TEST-001 Unit Test Suite                      commit m0n1o2p
  [PASS] CI-TEST-002 Integration Test Suite               commit q3r4s5t
  [PASS] CI-TEST-003 System Test Specifications           v1.8
  [PASS] CI-BUILD-001 Build Configuration                 commit u6v7w8x
  [PASS] CI-BUILD-002 CI/CD Pipeline Definition           commit y9z0a1b
  [PASS] CI-ML-001   Trained ML Model                     v1.2.0
  [PASS] CI-DOC-001  Safety Manual                        v2.0
  [PASS] CI-DOC-002  Release Notes                        v3.0.0-RC1

  Result: 15/15 CIs present and versioned

Consistency Checks:
───────────────────
  [PASS] All open CRs resolved or deferred with documented rationale
  [PASS] No suspect traceability links remaining
  [PASS] All unit tests pass (coverage: 94.2%)
  [PASS] All integration tests pass
  [PASS] Static analysis: 0 critical, 0 high findings
  [PASS] Build reproducible from tagged commit
  [WARN] CI-DOC-001 last modified 2025-06-10 (> 90 days ago)
         → Verify Safety Manual is current

Open Change Requests Against This Baseline:
────────────────────────────────────────────
  CR-2025-018: Deferred to v3.1.0 (rationale documented)
  CR-2025-022: Closed (implemented and verified)

Overall Status: READY FOR APPROVAL (1 warning)
Confidence: 0.95

Human Action Required:
  □ Review warning for CI-DOC-001 staleness
  □ Approve baseline creation
  □ Sign baseline approval record

Baseline Approval Record

# Baseline Approval Record
baseline_approval:
  baseline_id: BL-BCM-3.0.0
  baseline_type: product
  creation_date: 2025-12-20
  tag: v3.0.0

  ci_versions:
    CI-REQ-001: v2.3
    CI-REQ-002: v3.1
    CI-ARCH-001: v2.1
    CI-ARCH-002: v2.4
    CI-SRC-001: a1b2c3d
    CI-SRC-002: e4f5g6h
    CI-SRC-003: i7j8k9l
    CI-TEST-001: m0n1o2p
    CI-TEST-002: q3r4s5t
    CI-TEST-003: v1.8
    CI-BUILD-001: u6v7w8x
    CI-BUILD-002: y9z0a1b
    CI-ML-001: v1.2.0
    CI-DOC-001: v2.0
    CI-DOC-002: v3.0.0

  ai_consistency_check:
    status: pass
    confidence: 0.95
    warnings: 1
    report: baseline_report_BL-BCM-3.0.0.md

  approvals:
    - role: Configuration Manager
      name: (Configuration Manager Name)
      date: 2025-12-20
      decision: approved

    - role: QA Lead
      name: (QA Lead Name)
      date: 2025-12-20
      decision: approved

    - role: Safety Manager
      name: (Safety Manager Name)
      date: 2025-12-20
      decision: approved
      condition: "Safety Manual confirmed current per review on 2025-12-18"

    - role: Project Manager
      name: (Project Manager Name)
      date: 2025-12-20
      decision: approved

  status: approved

Configuration Management Framework

The diagram below presents the overall CM framework, showing how configuration identification, change control, status accounting, and auditing activities interrelate.

CM Status Reporting (BP5)

Automated CM Dashboard

The following diagram shows the CM status dashboard, providing real-time visibility into configuration item counts, baseline status, pending changes, and audit results.

Status Report Structure

AI generates CM status reports at configurable intervals (weekly, per milestone, or on demand). Reports cover the following dimensions:

Example Status Report

Configuration Management Status Report
═══════════════════════════════════════
Project: BCM Door Lock Control
Period: 2025-12-01 to 2025-12-15
Generated: 2025-12-15 by AI CM Reporter

CI Inventory:
─────────────
  Total CIs:           15
  New since last:       1 (CI-SRC-004 temp_sensor.c added)
  Removed:              0
  Catalog completeness: 100%

Baseline Status:
────────────────
  Current product baseline:  BL-BCM-2.0.0 (tagged v2.0.0)
  Pending baseline:          BL-BCM-3.0.0-RC1 (in preparation)
  Baselines this period:     0

Modification Activity:
──────────────────────
  Commits (develop):    47
  Merge requests:       12 (11 merged, 1 open)
  Change requests:       3 (2 closed, 1 in implementation)
  Convention violations: 2 (both caught by pre-commit hook, corrected)

Build Reproducibility:
──────────────────────
  BL-BCM-2.0.0: [PASS] Rebuild matches original (SHA256 verified)
  develop HEAD:  [PASS] Build succeeds; all tests pass

Compliance Score: 96/100
────────────────────────
  Deductions:
    -2  CI-DOC-001: Stale (last update > 90 days)
    -2  CI-TEST-002: 1 integration test disabled without documented rationale

Anomalies:
──────────
  [WARN] Direct push to develop branch detected on 2025-12-08 (commit f3e2d1c)
         → Bypassed merge request process
         → Assignee notified; process reminder sent

  [INFO] 1 file in src/ directory not in CI catalog (temp_sensor_calibration.dat)
         → Recommendation: Add as CI-SRC-005 or move to test data directory

Version Numbering and Tagging

Semantic Versioning

All releasable artifacts follow Semantic Versioning (SemVer) 2.0.0:

MAJOR.MINOR.PATCH[-prerelease][+build]

Tag Convention

Git tags serve as the authoritative version markers and baseline identifiers:

AI Enforcement: The CI pipeline validates that release tags follow the SemVer pattern and that the VERSION file contents match the tag. Mismatches block the release pipeline.

Storage and Access Control

Repository Structure

A well-organized repository structure supports CI identification and access control:

bcm-project/
├── src/                          # Source code CIs
│   ├── app/                      # CI-SRC-001: Application layer
│   ├── mcal/                     # CI-SRC-002: MCAL configuration
│   ├── bsp/                      # CI-SRC-003: Board support package
│   └── driver/                   # CI-SRC-004: Device drivers
├── test/                         # Test CIs
│   ├── unit/                     # CI-TEST-001: Unit tests
│   ├── integration/              # CI-TEST-002: Integration tests
│   └── fixtures/                 # Test data and fixtures
├── architecture/                 # Architecture CIs
│   ├── system_arch.eap           # CI-ARCH-001
│   └── sw_arch/                  # CI-ARCH-002
├── docs/                         # Documentation CIs
│   ├── safety/                   # CI-DOC-001: Safety manual
│   └── design/                   # Design documents
├── models/                       # ML model CIs (Git LFS)
│   └── *.engine                  # CI-ML-001
├── tools/                        # Build configuration CIs
│   └── cmake/                    # CI-BUILD-001
├── scripts/                      # CI/CD and automation scripts
├── .gitlab-ci.yml                # CI-BUILD-002: Pipeline definition
├── CHANGELOG.md                  # CI-DOC-002: Release notes
├── VERSION                       # Version file
└── .pre-commit-config.yaml       # Pre-commit hook configuration

Access Control Matrix

HITL Protocol for Configuration Management

Human-in-the-Loop controls ensure that AI automation does not compromise the integrity of configuration management decisions.

HITL Gate Definitions

Escalation Rules

Multi-Standard Mapping

SUP.8 Configuration Management aligns with and supports compliance across multiple safety and quality standards:

Metrics and KPIs

Process Metrics

AI Effectiveness Metrics

Work Products

Implementation Checklist

Use this checklist when establishing or improving SUP.8 Configuration Management with AI integration.

Process Setup

• Define CM strategy and document in the CM plan (BP1)
• Establish version control repository with defined branching strategy
• Configure branch protection rules for main, develop, and release branches
• Define and document commit message convention
• Establish CI catalog with all known work products classified and assigned to owners
• Define baseline types, creation triggers, and approval workflows
• Assign Configuration Manager role with defined responsibilities
• Define access control matrix for repository and baseline operations

AI Integration

• Deploy pre-commit hooks for convention enforcement (commit messages, branch names, binary detection)
• Configure CI pipeline with CM validation stage (convention checks, traceability validation)
• Implement AI CI discovery scanner to detect untracked artifacts
• Set up automated baseline consistency verification
• Configure automated CM status report generation
• Implement anomaly detection for unauthorized changes to protected branches and CIs
• Set up build reproducibility verification in release pipeline

Tool Integration

• Connect version control to ALM tool for CR-to-commit traceability
• Configure merge request templates with CM metadata fields
• Set up Git LFS for binary artifacts (ML models, large test data)
• Configure artifact storage for release packages and compliance evidence
• Implement dashboard views for CI inventory, baseline status, and compliance score

HITL and Governance

• Document HITL gates (G1-G5) in the CM plan
• Define escalation rules for anomalies, failed baselines, and convention violations
• Establish baseline approval workflow with required signatories
• Train team on CM procedures, commit conventions, and merge request process
• Schedule periodic CM audits (internal and for external assessment readiness)

Summary

SUP.8 Configuration Management:

• AI Level: L2-L3 (high automation in CI/CD validation and reporting; human authority for baselines and releases)
• Primary AI Value: Automated convention enforcement, CI discovery, baseline consistency verification, status reporting, anomaly detection
• Human Essential: Baseline approval, release decisions, CI catalog ownership, anomaly resolution
• Key Outputs: CM plan, CI catalog, baselines, CM status reports, baseline approval records
• Integration: Connects version control, ALM, CI/CD, and artifact storage systems
• HITL Protocol: Five defined gates (G1-G5) ensuring human authority over all CM decisions that affect product integrity
• Focus: Integrity, traceability, reproducibility