What Is ASPICE? (Automotive SPICE, Explained Plainly)

Ask ten people in automotive what ASPICE is and you get ten answers — usually some mix of dread, Excel, and audits. So let's be precise. ASPICE stands for Automotive SPICE, and SPICE is Software Process Improvement and Capability dEtermination. It is an assessment model: a way to grade how capable your engineering processes are. It grades you on capability levels — and most OEMs ask for a specific level as a condition of sourcing.

ASPICE was born in the 1990s, driven by the German OEMs — Mercedes, Volkswagen, Continental — through the VDA (the German automotive industry association). Back then software meant a few hundred thousand lines of low-level C on a bare-metal ECU: the first ABS, ESP, and airbag controllers. Safety-critical, and growing fast. The OEMs needed a way to judge whether a supplier's software was actually any good — and a legal backstop if it wasn't.

Technically, ASPICE is a domain-specific derivative of ISO/IEC 15504 (SPICE), now succeeded by the ISO/IEC 330xx family. That heritage matters: SPICE is a measurement framework, which is exactly why ASPICE grades processes rather than prescribing them.

Most OEMs ask for Level 1 to Level 3 on the assessed processes; in practice the contractual line is usually CL2. Levels 4 and 5 are the tip of the iceberg. The jump that trips teams up is CL1 → CL2: not doing the work, but managing the work products and traceability. (More on that in missed a capability level?.)

The scope is the whole V-model plus supporting groups. On the engineering side: system requirements (SYS.1 elicitation, SYS.2 analysis), system architecture (SYS.3), integration and qualification (SYS.4, SYS.5); and software requirements (SWE.1), software architecture (SWE.2), detailed design and construction (SWE.3), then verification back up the V (SWE.4 unit, SWE.5 integration, SWE.6 qualification).

Around that sit the supporting and management groups: quality assurance (SUP.1), configuration management (SUP.8), problem resolution (SUP.9), change request management (SUP.10), and project management (MAN.3). The newest revision, ASPICE 4.0 (2023), added machine-learning processes (MLE.*) and reworked the model. All told it's a ~130-page process reference and assessment model. We break the V down in Agile ASPICE: the V-model is a shape, not a schedule.

Here is the single most expensive misunderstanding in the industry: ASPICE is not an implementation blueprint. There is no official blueprint anywhere. It's a checklist assessors grade you against. So teams take that 130-page model and build enormous, bloated processes off it — treating an assessment framework like a build manual.

The second trap is the work products. The change records, review records, and communication records ASPICE asks for are 1990s pen-and-paper artifacts. Today they already live inside your tools automatically — in Git, in your PR history, in your issue tracker. But teams recreate them as Excel sheets and signed PDFs. That's the trap — and it's where the pain comes from.

When you treat a checklist as a build manual and recreate automatic evidence by hand, the bill is brutal: engineers spend more than 80% of their time on work that isn't code. For every one engineer doing the work, you need another to document it. A change that took ten minutes to make takes two to four weeks to land. The true cost of ASPICE, done the legacy way, runs to roughly ten times the cost of the code itself.

You stop hand-producing evidence. The modern answer is to let AI agents generate assessment-ready work products — traceability records, review records, test specifications — as a byproduct of the normal build, each with a confidence score and an audit trail. It doesn't replace your assessor or your process ownership; it removes the manual evidence production teams actually fail on. That's the whole thesis behind automating ASPICE compliance with AI agents, and it's what Vera does.