Change Request Management Process

Revision History

1. Purpose

This document defines the change request management process for the foxBMS 2 POSIX vECU project in accordance with ASPICE SUP.10 (Change Request Management). It establishes how changes to baselined configuration items are proposed, analyzed, approved, implemented, and verified.

2. Scope

The process covers changes to all baselined configuration items: foxBMS source patches, POSIX HAL stubs, plant model, test scripts, build scripts, and ASPICE documentation. It does not cover the upstream foxBMS v1.10.0 source (which is treated as an immutable dependency).

3. References

4. Change Categories

5. Change Request Workflow

5.1 Process Flow

  REQUEST (describe change, category, rationale)
      |
      v
  IMPACT ANALYSIS
  - Which patches affected?
  - Which DIAG IDs affected?
  - Which test criteria need re-run?
  - Which documents need update?
      |
      v
  APPROVAL (code review + smoke test pass)
      |
      v
  IMPLEMENTATION
  - Modify patch file(s) or source
  - Update affected tests
  - Update affected documentation
      |
      v
  VERIFICATION
  - apply_all.sh passes
  - test_smoke.py PASS
  - Affected test suites pass
      |
      v
  CLOSURE (commit, update GAP-ANALYSIS if applicable)

5.2 Step Details

5.2.1 Request

A change request is initiated when: - A gap in GAP-ANALYSIS.md requires a code change - A new feature or capability is needed for the next phase - A test failure reveals a needed correction - An ASPICE assessment finding requires a process or artifact change

The request is documented in the Git commit message and, for significant changes, in GAP-ANALYSIS.md.

5.2.2 Impact Analysis

Before implementing a change, the following impact analysis is performed:

5.2.3 Approval

Changes are approved through:

5.2.4 Implementation

Changes follow the patch workflow:

For foxBMS source modifications: 1. Identify which patch file to modify (or create new patch) 2. Apply change to working copy 3. Regenerate patch file with diff -u 4. Update apply_all.sh if patch count or order changes 5. Verify: ./apply_all.sh on clean foxBMS checkout

For POSIX-specific source files (src/): 1. Modify source directly 2. Ensure compilation with -Wall -Wextra (zero warnings) 3. Run affected unit tests

For test scripts: 1. Add or modify test criteria 2. Ensure test still runs within timeout 3. Verify pass/fail verdicts are correct

For documentation: 1. Update affected ASPICE work product 2. Update revision history 3. Verify cross-references

5.2.5 Verification

5.2.6 Closure

• Commit to Git with descriptive message
• Update GAP-ANALYSIS.md if change resolves a gap
• Update COVERAGE.md if change affects feature status

6. Patch Change Register

The following table records significant changes to the patch set:

7. Change Impact on DIAG IDs

When a change affects diagnostic behavior, the following matrix is consulted:

8. Emergency Change Process

For CRITICAL severity problems requiring immediate resolution:

1. Fix is implemented directly on main branch
2. Smoke test must pass before commit
3. Full test suite (integration + ASIL) run immediately after commit
4. GAP-ANALYSIS.md updated with resolution
5. Change documented retroactively in this register

9. CL2 Gaps for SUP.10