Automotive SPICE · Traceability

ASPICE traceability: spec → test → evidence

ASPICE assesses process maturity and bidirectional traceability, not only green lab results. If Spec → Requirement → Test → Evidence breaks, audit risk remains.

Book a briefing Start demo

Context

What ASPICE asks of a battery test plan

Automotive SPICE scores process maturity and bidirectional traceability, not green lab results alone. The chain spec, requirement, test, evidence has to hold both ways. If it breaks, audit risk remains.

Typical gaps in battery programmes: free text without an ID, a standard without a section, OEM changes only in email, Excel plans without a spec page. Cevelar mints stable IDs from the source. Related: IEC 62619, validation planning.

Process hits

Where ASPICE meets validation

SYS.2 / SWE.1

Requirements

Every requirement needs an ID, owner and verification method, not a paste into Excel.

SWE.4 / SWE.5

Verification

Procedures must cite the requirement and acceptance criterion they close.

SUP.8 / SUP.10

Change

OEM deltas belong in the same chain, not only in mail threads.

Assessment

Evidence

Assessors want the path back to the spec page, not a screenshot of a green cell.

Findings board

Typical gaps before assessment

In battery and BMS programs the same breaks show up again and again, often after the lab is already booked.

F-01 Free text without a stable ID Baseline and re-verify after change become impossible.
F-02 Norm named, no section IEC 62619 or UN 38.3 without mapping → over- or under-testing.
F-03 OEM delta only in email Silent scope drift outside the ALM chain.
F-04 Excel without a source link Pass/fail without a source path stays assessment risk.
F-05 Transport and in-use mixed Duplicate campaigns because UN 38.3 and IEC 62619 were never separated.

Checklist

Signal → plan question → risk

Spec signal	Plan question	Risk if missing
REQ without ID	Can we baseline and re-verify after change?	Finding / rework
Norm without section	Which procedure closes which requirement?	Over- / under-testing
OEM annex / mail delta	Is it in the same ALM chain?	Silent scope drift
Pass/fail without source link	Why does this test exist?	Audit risk despite green labs

For heads of validation

What assessment actually probes

Matrix Spec page → REQ ID → norm → procedure → evidence
Early conflicts: OEM vs IEC / UN 38.3 / customer profiles
Cost and sequence estimates before lab booking
Export for Polarion, Jira and assessment reviews

Contact

Traceability from the spec, not from a screenshot.

Cevelar extracts structured requirements, maps norms and builds test plans with source-level traceability, EU-hosted for IP-sensitive programs.

Book a briefing Start demo

FAQ

ASPICE questions

Traceability before the assessment starts.

What does ASPICE mean for validation teams?

ASPICE requires traceable processes and bidirectional traceability between requirements, design and tests. For battery validation that means spec requirements must stay evidencable through to the test method and the report.

Where do typical ASPICE gaps appear in battery programmes?

Free-text requirements without IDs, standard references without section numbers, OEM changes only in email, and Excel test plans with no pointer back to the spec page.

How does Cevelar support ASPICE traceability?

Cevelar produces structured requirements from OEM specs with source and clause references, as the basis for auditable test plans and ALM export. EU-hosted for IP-sensitive programmes.