10 · Capstone — Full Test Strategy for a New ECU Program¶
This capstone integrates every module across all four levels into one deliverable: a program-level test strategy for a new ECU, written the way a test architect would actually present it before a program kickoff review. Where Level 3 Module 10 scoped one feature's HIL test plan, this capstone scopes an entire new ECU program end to end.
About this module
No physical rig, real program, or real OEM/supplier relationship was used to produce this capstone. Every technique referenced traces back to a specific earlier module — treat this as a template demonstrating how those pieces compose, not a captured real program's strategy.
The program: a new Battery Management System (BMS) ECU¶
Chosen deliberately as a new (not carryover) ECU with genuine safety relevance (thermal runaway, overcharge protection are ASIL-relevant hazards) and genuine cybersecurity relevance (a networked ECU controlling energy storage), so the capstone can exercise the full breadth of the course.
1. Scope and V-model placement (Level 4 Module 1)¶
In scope: BMS software-level test strategy (CAPL/CANoe/HIL), owned by
the supplier per the collaboration model in Module 7; system
integration with the vehicle's powertrain/charging ECUs, OEM-owned.
Out of scope, explicitly: cell-chemistry-level electrochemical
validation (owned by a dedicated battery test lab, not signal-level
HIL); formal homologation testing for any regulated charging-safety
requirement (Module 8) -- this strategy produces PRE-homologation
rehearsal evidence only.
2. Requirements and ASIL allocation (Level 3 Module 4, 8)¶
| Requirement | Summary | ASIL |
|---|---|---|
| SW-REQ-501 | BMS shall disconnect the pack contactor within 200ms of detecting a cell overvoltage condition | ASIL D |
| SW-REQ-502 | BMS shall reject implausible cell-voltage/temperature sensor readings rather than acting on them | ASIL D |
| SW-REQ-503 | BMS shall authenticate charging-station communication before accepting a charge-current setpoint | ASIL B / CAL-relevant |
3. Safety mechanism and fault matrix (Level 3 Modules 4, 6; Level 4 Module 3)¶
| Mechanism | Fault(s) tested | Combined-fault case (Level 4 Module 3) |
|---|---|---|
| Overvoltage plausibility + contactor disconnect | Implausible cell-voltage jump, frame timeout on cell-voltage bus signal | Overvoltage condition occurring WHILE a comm timeout is active on an unrelated temperature signal |
| Charging-station authentication (Level 4 Module 4's Security Access pattern) | Invalid key, replayed setpoint message | Authentication failure occurring during an active overvoltage fault (does the ECU still prioritize the safety-critical disconnect over diagnostic/security processing?) |
testcase tc_ContactorDisconnectsWithinSpec()
{
testCaseTitle("[SW-REQ-501] Contactor disconnects within 200ms of overvoltage detection");
dword t0, t1;
setSignal(CellVoltage_mV, 3700); // nominal
testWaitForTimeout(200);
t0 = timeNowNS() / 1000000;
setSignal(CellVoltage_mV, 4300); // overvoltage threshold exceeded
testWaitForSignal(ContactorState, 0 /* OPEN */, 200);
t1 = timeNowNS() / 1000000;
testStepCheck("contactor opened within 200ms", (t1 - t0) <= 200);
}
testcase tc_SafetyDisconnectPrioritizedDuringAuthFailure()
{
testCaseTitle("[SW-REQ-501][SW-REQ-503] Overvoltage disconnect is not delayed by concurrent charging-auth handling");
// Combined-fault case per Level 4 Module 3's cascading-fault discipline.
StartChargingAuthenticationAttempt(INVALID_KEY);
setSignal(CellVoltage_mV, 4300);
testWaitForSignal(ContactorState, 0 /* OPEN */, 200);
testStepCheck("safety-critical disconnect not delayed by concurrent security processing", 1 == 1);
// A real implementation would assert against a captured timestamp,
// not a placeholder -- left here to flag in the exercise below.
}
4. Test data management (Level 4 Module 5)¶
Configuration baseline: BMS-v1.0.0-rc1-baseline
ECU software build: 1.0.0-rc1
DBC: BMS_Network_v3.dbc
A2L: BMS_1.0.0.a2l
Requirements set: SW-REQ-set-2026-Q3-rev1
FMEA revision: FMEA-BMS-rev2
5. Continuous testing integration (Level 4 Module 2)¶
SIL smoke (minutes, every commit): overvoltage/undervoltage plausibility
logic against a simulated cell model.
HIL smoke (tens of minutes, every commit): tc_ContactorDisconnectsWithinSpec
and equivalent core safety-mechanism checks.
Nightly full regression: full fault matrix from Section 3, including
combined-fault cases.
6. Supplier/OEM collaboration (Level 4 Module 7)¶
Evidence exchanged with OEM at each milestone: summary test report,
traceability matrix (100% coverage required for ASIL D requirements),
fault-injection coverage matrix. CAPL test source withheld as supplier
IP per the negotiated evidence boundary; test *technique* per
requirement documented instead.
7. Known gaps and risk acceptance (Level 3 Module 10 style, program scale)¶
Gap 1: No breakout-box electrical fault injection available at supplier
site for cell-voltage sensor wiring -- ASIL D coverage gap, flagged to
OEM safety assessor with target hardware-acquisition date.
Gap 2: Charging-station authentication testing (SW-REQ-503) currently
covers key-validation and lockout (Level 4 Module 4 pattern) but has
NOT yet been extended to combined-fault testing against a concurrent
overvoltage condition beyond the one testcase above -- flagged as an
open item for the next test-plan revision.
8. Team and process (Level 4 Module 6)¶
Roles assigned: 2 test engineers (CAPL authorship), 1 framework
engineer (CI/orchestration, Level 3 Module 5 style), 1 safety test
specialist (ASIL D independent review), 1 rig engineer (HIL/fault-
injection hardware). Cross-training matrix maintained to avoid single
points of failure on the BMS-specific rig.
Cheat sheet — how the capstone maps to the whole course¶
| Section | Modules it draws on |
|---|---|
| Scope/V-model | Level 4 Module 1 |
| Requirements/ASIL | Level 3 Modules 4, 8 |
| Fault matrix, combined faults | Level 3 Module 6, Level 4 Module 3 |
| Configuration baseline | Level 4 Module 5 |
| CI integration | Level 4 Module 2 |
| Supplier/OEM evidence boundary | Level 4 Module 7 |
| Honest gap disclosure | Level 3 Module 10's pattern, applied program-wide |
| Team structure | Level 4 Module 6 |
How It Actually Works¶
Why the placeholder 1 == 1 in tc_SafetyDisconnectPrioritizedDuringAuthFailure
is a genuinely dangerous thing to leave in a real test suite, not just
an incomplete exercise. A CAPL testcase that reaches
testWaitForSignal(ContactorState, 0, 200) and then asserts a tautology
reports a Passed verdict in every test-report rollup, traceability
matrix, and CI dashboard exactly as if a real, meaningful check had
been performed — there is nothing in the tooling that distinguishes a
placeholder assertion from a genuine one; both simply resolve to 1.
This means a fault-priority regression (security-handshake processing
load pushing the contactor-disconnect path past 200ms) can be
introduced later and this testcase will keep reporting green
indefinitely, giving the program false confidence on precisely the
ASIL D requirement (SW-REQ-501) that matters most. The fix isn't just
"replace 1==1 with something real" — it's capturing t0 before setting
CellVoltage_mV and t1 after testWaitForSignal returns, then
asserting (t1 - t0) <= 200 exactly as tc_ContactorDisconnectsWithinSpec
does, so the combined-fault case actually measures the same timing
budget under contention that the isolated case measures without it.
Why testing "safety disconnect during auth failure" specifically
targets a scheduler-priority bug class. On a real ECU, both the
contactor-disconnect logic and the charging-authentication handshake
typically run as tasks or interrupt handlers on a shared processor,
arbitrated by an RTOS scheduler with configured task priorities. If
the safety-critical disconnect path and the security/authentication
path are not correctly prioritized relative to each other — say, both
assigned similar priority, or the authentication handshake runs in a
long, non-preemptible critical section — a genuinely correct-looking
disconnect implementation (proven correct in isolation by
tc_ContactorDisconnectsWithinSpec) can still miss its 200ms budget
the moment it has to compete for CPU time with an in-progress
authentication attempt. This is precisely why Level 4 Module 3's
combined-fault discipline treats "safety mechanism A works" and
"safety mechanism A works while B is also active" as two structurally
different claims requiring two different tests — task-priority bugs
are invisible to single-condition testing by construction.
Why the configuration baseline's DBC/A2L/build triplet is what makes
Gap 1 and Gap 2 actionable rather than just noted. When Section 7
flags that electrical fault injection is missing for the cell-voltage
sensor wiring, that gap statement is only useful to a future engineer
if it's unambiguous which exact software behavior it applies to — a
gap noted against "the BMS" in general, without the
BMS-v1.0.0-rc1-baseline tag pinning the exact DBC/A2L/build tuple,
becomes ambiguous the moment the software is revised: does the gap
still apply to v1.0.1, or was it incidentally closed by an unrelated
change? Tagging every gap and every passing test result against the
same baseline identifier (Level 4 Module 5) is what lets a safety
assessor, months later, answer "is this specific, previously-accepted
risk still open against the software we're about to ship" with a
lookup rather than a fresh investigation.
Exercise¶
tc_SafetyDisconnectPrioritizedDuringAuthFailurecontains a placeholder assertion (1 == 1) exactly as flagged in its comment. Rewrite it with a real timing assertion that would actually catch a defect where security-processing load delays the safety-critical contactor disconnect beyond 200ms.- Using the homologation overview (Level 4 Module 8), identify which BMS requirement in Section 2 is most likely to have a real-world regulatory analog, and draft a one-paragraph note for the strategy document distinguishing this program's internal ASIL D testing from any future formal homologation activity for that requirement.
- Write Section 9 of this strategy — a "Definition of Done" for the whole program's test strategy (not one feature, per Level 3 Module 10's narrower exit criteria) — covering traceability coverage thresholds, gap risk-acceptance sign-off, and CI health criteria that must all be met before this ECU is considered test-complete for its first release candidate.