Introduction
Ask an automotive Tier 1 supplier's engineering lead what keeps them up at night before an OEM audit, and ASPICE comes up more often than ISO 26262 does. Not because process maturity matters more than functional safety, it doesn't, but because ASPICE compliance for automotive software suppliers has become a hard sourcing gate: many OEMs simply won't award a software-relevant program to a supplier that can't demonstrate the required capability level, regardless of how good the engineering itself is. What is ASPICE and who requires it? is a question every supplier new to automotive software eventually has to answer, usually under time pressure once a request for quotation names a required capability level.
In short: ASPICE (Automotive SPICE) is a process assessment model, based on ISO/IEC 33002, that OEMs use to evaluate how mature and disciplined a supplier's software development process is, scored across defined process areas at capability levels from 0 to 5, and increasingly, a supplier's ASPICE capability level is a contractual precondition for being awarded automotive software work at all.
What ASPICE Actually Assesses
ASPICE doesn't assess whether a specific piece of software works correctly, that's what testing and functional safety validation are for. It assesses whether the process used to develop that software is defined, managed, measured, and controlled well enough to reliably produce good outcomes on the next project too, not just this one. An assessor examines defined process areas, requirements elicitation and management, software architecture and detailed design, unit verification, integration and testing, configuration management, problem resolution, and rates each against specific process attributes: is the process performed, is it managed, is it defined at an organizational level, is it measured, is it controlled and continuously improved. This process-versus-product distinction is the single most common point of confusion for engineering teams new to ASPICE.
Automotive SPICE Capability Levels Explained
Automotive SPICE capability levels explained from the ground up: Capability Level 0 means the process isn't performed or fails to achieve its purpose. Capability Level 1 (Performed) means the process achieves its intended outcomes, work gets done, but not necessarily in a controlled or repeatable way. Capability Level 2 (Managed) adds planning, monitoring, and adjustment, the process is performed according to a plan, with defined work products and stakeholder involvement tracked. Capability Level 3 (Established) requires the process to be based on a standardized, organization-wide process definition, not just something one project team happens to do well. Levels 4 (Predictable) and 5 (Innovating) add quantitative process control and continuous, data-driven improvement, and are rarely required outside the most safety- and quality-critical automotive software programs. Most OEM RFQs today specify a required capability level of 2 or 3 for the relevant process areas, with Level 3 increasingly the baseline expectation for software-intensive ECU programs.
The VDA Scope: Which Process Areas Actually Get Assessed
Full ASPICE defines dozens of process areas across acquisition, supply, engineering, and management categories, but in practice, almost no automotive assessment covers all of them. The VDA (German Association of the Automotive Industry) scope defines a practical subset that most German OEMs and increasingly OEMs globally actually require: the SYS (system engineering) and SWE (software engineering) process groups covering requirements through testing, MAN.3 (project management), SUP.1 (quality assurance), SUP.8 (configuration management), SUP.9 (problem resolution management), SUP.10 (change request management), and ACQ.4 (supplier monitoring, relevant when a Tier 1 itself sources from a Tier 2). Understanding that an assessment will realistically focus on this VDA scope, rather than the full ASPICE process reference model, makes preparing for one a far more tractable exercise.
Automotive Embedded Software Compliance Testing Within an ASPICE Framework
Automotive embedded software compliance testing sits at the center of several ASPICE process areas simultaneously: SWE.4 (software unit verification), SWE.5 (software integration and integration test), and SWE.6 (software qualification test) each define specific expected work products, test specifications, test cases with traceability back to requirements, test results, and defect records, that an assessor will sample directly. A team that tests thoroughly but can't produce traceable evidence linking each test case to the requirement it verifies will still score poorly on these process areas, because ASPICE assessors are evaluating the discipline and traceability of the compliance process, not just whether the tests eventually passed. This is precisely why the testing regime has to be planned as a traceable, documented process from the requirements phase onward, not bolted on before a submission deadline.
ASPICE and ISO 26262: Two Different Questions for Automotive Software
ASPICE vs ISO 26262 for automotive software is a comparison worth being precise about, because the two standards answer genuinely different questions and neither substitutes for the other. ASPICE asks: is your development process mature, controlled, and repeatable? ISO 26262 asks: is this specific software safe enough for its assigned ASIL, given the hazards it could cause if it fails? A supplier can have a highly mature ASPICE Level 3 process and still ship software with an inadequate safety case if functional safety requirements weren't correctly derived and verified. Conversely, a team can produce technically safe software through an immature, undocumented process that would fail an ASPICE assessment even though the specific deliverable passed safety validation. In practice, the two standards reinforce each other, ASPICE's traceability and configuration management discipline makes ISO 26262's safety case documentation dramatically easier to assemble, which is why most automotive software organizations pursue both together rather than treating them as separate compliance tracks.
Why OEMs Increasingly Make ASPICE a Sourcing Gate
From an OEM's perspective, ASPICE capability level is a proxy for a question that's otherwise expensive to answer directly for every potential supplier: can this organization reliably deliver quality software on a multi-year, multi-release automotive program without the OEM having to closely manage every development decision. A supplier that can demonstrate an established, organization-wide Level 3 process, backed by an independent assessment, gives an OEM confidence that quality and delivery risk on a new program are lower than with a supplier whose process maturity is unproven or informal. This is why RFQs increasingly specify a minimum required capability level as a qualification criterion before technical evaluation even begins, ASPICE has become a gate a supplier has to clear to be considered, not just a nice-to-have differentiator once in the room.
Common Gaps That Cause Suppliers to Fail an Assessment
Assessors see the same gaps repeatedly across suppliers new to formal ASPICE assessment. Requirements traceability is incomplete, requirements exist, and tests exist, but the explicit links between them, required by SWE.1 and SWE.6, were never systematically maintained. Configuration management is informal, source code and requirements live in version control, but baselines, change history, and the ability to reconstruct exactly what was delivered at a given point aren't rigorously controlled. Problem resolution lacks closed-loop evidence, defects get logged and eventually fixed, but the process doesn't demonstrably verify the fix, confirm no regression, and formally close the record. And project planning exists on paper but doesn't reflect what actually happened, plans that were never updated as the project evolved undermine an assessor's confidence in the Managed-level attributes even when the underlying engineering was solid.
Building Toward ASPICE Compliance Without Slowing Delivery
Teams new to ASPICE compliance for automotive software suppliers often assume the process discipline it demands will slow delivery meaningfully, and while there's real upfront investment, well-integrated tooling, requirements management, traceability, and configuration management tools that fit into an existing development workflow rather than replacing it, makes most of the discipline close to free after the initial setup. Traceability captured automatically as requirements, code, and tests are linked in the normal course of development costs far less than reconstructing it retroactively before an assessment. The teams that struggle most with ASPICE are consistently the ones treating it as a documentation exercise to complete just before an audit rather than a way of working built into the project from day one.
Embien's Capabilities
Embien's automotive software development processes are structured around ASPICE guidelines and ISO 26262 functional safety practices together, with requirements traceability, configuration management, and structured problem resolution built into our standard automotive engineering workflow rather than assembled after the fact. Our internal Centers of Excellence for Automotive continuously benchmark our practices against ASPICE and MISRA expectations across ECU software programs spanning body, chassis, ADAS, and telematics domains.
To discuss ASPICE compliance for automotive software suppliers or process maturity requirements for an upcoming automotive software program, reach out to Embien's engineering team.