Automotive SPICE (ASPICE)
Automotive SPICE (ASPICE) is the automotive industry’s process assessment model for evaluating the maturity of development processes for software-based systems. Assessments rate processes on capability levels 0 to 5 — many OEMs require level 2 or 3 from their suppliers. ASPICE is the industry-specific derivation of the standardised ISO/IEC 330xx assessment family and is maintained under the umbrella of the VDA QMC.
How does an ASPICE assessment work?
ASPICE has two dimensions. The process dimension defines process areas with outcomes and base practices — for example SYS.2 (system requirements analysis) or SWE.4 (software unit verification). The capability dimension rates how well a process is mastered:
| Level | Name | Meaning |
|---|---|---|
| CL 0 | Incomplete | Process is missing or fails to achieve its outcome |
| CL 1 | Performed | Process achieves its outcome |
| CL 2 | Managed | Process is planned, monitored, work products are managed |
| CL 3 | Established | Process follows an organisation-wide standard process |
| CL 4 | Predictable | Process is controlled quantitatively |
| CL 5 | Innovating | Process is improved continuously and systematically |
In supplier projects, levels 2 and 3 are the practically relevant targets; levels 4 and 5 play hardly any role in assessments.
The process areas: aligned with the V-model
The engineering processes follow the logic of the V-model: on the left side, requirements and architecture are refined at system and software level (SYS.1–SYS.3, SWE.1–SWE.3); on the right side, they are verified in reverse order (SWE.4–SWE.6, SYS.4–SYS.5). Added to this are supporting processes such as quality assurance, configuration management and change request management, plus management processes such as project management.
What changes with ASPICE 4.0?
Version 4.0, published in 2023, extends the model beyond software: dedicated process areas for hardware engineering (HWE) and machine learning engineering (MLE) reflect the reality of software-defined vehicles. At the same time, ASPICE 4.0 raises the formal requirements for traceability in automotive development — evidence chains must be maintained consistently across all levels of the V-model.
ASPICE and traceability
Bidirectional traceability is a base practice in ASPICE that runs through almost all engineering process areas: every system requirement must be traceable to software requirements, architectural elements, implementation and test cases — and back again from there. ASPICE thereby demands the same evidence structure that safety standards such as ISO 26262 require: anyone who wants to demonstrate process maturity cannot avoid digital traceability.
ASPICE in practice: the assessment starts in the toolchain
The biggest hurdle in assessments is rarely the understanding of the processes, but the evidence: requirements live in DOORS or Polarion, architecture in MBSE tools, code and tests in GitLab — and the assessor wants to see the chain in between. Where this evidence is gathered by hand, assessment preparation ties up engineering teams for weeks. With end-to-end requirements traceability across tool boundaries, the same evidence can be produced in hours instead of weeks — and between assessments, the trace data delivers genuine engineering value, for example for impact analyses when changes occur.