EN
RO
DE
Automotive SPICE® (ASPICE) is a process assessment and improvement model for engineering automotive software and systems. Maintained by the VDA QMC's Automotive Special Interest Group and aligned with the ISO/IEC 330xx measurement rules, ASPICE defines the outcomes that processes should achieve, as well as the evidence that should be produced upon successful completion of work. It is lifecycle-agnostic, meaning agile, V-model and hybrid teams can all comply, provided they consistently produce and demonstrate the expected results. While ISO 26262 remains responsible for functional safety, ASPICE supports safety by ensuring that processes creating safety-relevant work products are consistent, controlled and auditable.
This overview is intended for two audiences. Leaders and programme owners will find a clear line of sight from ASPICE to business outcomes such as predictability, audit readiness and supplier alignment. Delivery leads and engineers will find operational guidance on gates, baselines, traceability, reviews and approvals that fits existing lifecycles rather than replacing them.
ASPICE covers the activities you would expect in a modern, software-intensive programme and ties them together so that they behave coherently as a whole. The work begins with requirements management to ensure that what you plan to build is necessary, testable and understood by all. Mature requirements have stable identities, clear sources and rationales, and unambiguous acceptance criteria. When requirements change, these changes are controlled and leave a trace. System and software architecture translate intent into structure: interfaces are defined, responsibilities are allocated and major design choices are recorded alongside their reasoning. Architecture is not a static picture, but rather a living contract that enables independent teams to collaborate while keeping safety, cybersecurity and performance concerns in mind.
Implementation transforms the design into working code and configuration, with an emphasis on control rather than style. Coding standards are agreed upon, reviews are performed, builds are reproducible and toolchain outputs (e.g. static analysis, unit tests and coverage) are linked to the items they verify. Integration is planned incrementally against named baselines. The necessary environments, stubs and data are in place before they are needed. Results are recorded so that regressions can be explained rather than guessed. Verification and testing provide a factual basis for release decisions: each requirement is verified at the appropriate level, the results are linked to the exact build being tested, and any deviations enter a disciplined problem-resolution process instead of being silently accepted.
Configuration and change management provide stability. Work products are uniquely identified; meaningful baselines are frozen at the right time; changes are analysed for their impact and approved before being incorporated; and any delivery can be recreated exactly as approved. When defects appear, the problem-resolution process takes them from detection to closure via triage, root-cause analysis and corrective or preventive actions. This ensures that issues do not reappear in another form. Quality assurance provides an independent perspective on all of this, confirming that the agreed process has been followed and that the evidence is reliable. Project management plans and monitors the work, identifies risks, and makes go/no-go decisions based on criteria rather than opinion. In many programmes, the scope also includes supplier monitoring and product-release governance. Expectations and evidence are defined with partners from the outset. Progress is reviewed at agreed intervals and any deviations are addressed constructively yet firmly. The final stage is also managed rigorously to ensure that what is released aligns with what was approved and communicated to customers.
Because ASPICE specifies the expected outcomes and the evidence that proves them, improvement becomes a concrete plan rather than an aspiration. A requirement without a test link, a build that cannot be reproduced from a baseline, or an approval referring to 'latest' rather than a specific revision, for example, becomes an actionable gap with an obvious next step. Closing a handful of such gaps increases predictability, reduces firefighting and frees up capacity for deeper fixes. After a few cycles, planning becomes easier, risks surface earlier and customers will notice the difference: fewer late changes and integration issues and releases that are valued in their own right.
ASPICE maturity is assessed per process rather than as a single badge for the organisation. The scale runs from Capability Level 0 to Capability Level 5. At Level 0, a process is considered incomplete because it does not achieve its intended purpose. At Level 1, the process is performed, the intended outcomes are achieved, and there is evidence that the work was genuinely carried out. At Level 2, management discipline is introduced: work is planned, monitored, and controlled; and work products are managed under configuration control. At Level 3, a defined process is consistently deployed across the project to ensure that outcomes do not depend on local habits or individual efforts. At Level 4, the process becomes predictable by being placed under quantitative control within defined limits. Level 5 institutionalises innovation through data-driven improvement. Assessors determine the achievement of relevant attributes using the standard 'Not/Partly/Largely/Fully Achieved' scale. In order to claim a level, all of the attributes at that level and at all lower levels must be largely or fully achieved. Higher levels signify repeatability and control rather than perfection. Most organisations achieve the greatest return by reliably progressing from Level 1 to Level 2 and then to Level 3 before pursuing quantitative control and innovation on a large scale.
Two concepts are given particular emphasis in ASPICE: traceability and consistency. Traceability connects the lifecycle from start to finish. A requirement enters with a clear identity, source and rationale, and is realised in architecture and detailed design. This design is then implemented in code or configuration, and verification and validation demonstrate that the intended behaviour has been achieved. The history of issues, changes and decisions also remains attached to the same thread. This enables you to prove coverage and perform real impact analysis when something changes. You can see which design artefacts, code modules, test cases and documents must move together, and verify this before sign-off. Consistency ensures that the various work products tell the same story at the same time. Design elements truly realise their requirements, code implements the interfaces and constraints specified by the architecture rather than inferred ones, tests verify the behaviour demanded by the requirements and enabled by the design, and the release note accurately describes what is delivered. Maintaining consistency prevents contradictions from becoming integration problems, reducing rework, cycle time, and the risk to safety and reliability.
Supplier alignment improves when ASPICE is applied with operational clarity. Agreeing the necessary evidence, reporting rhythm and acceptance criteria in advance transforms integration into planned work rather than discovery. Routine reviews against these expectations, followed by corrective actions where necessary, make progress visible and risks explicit across the supply chain. The minimum requirements are straightforward: a coherent set of trace links to the tested build, results corresponding to the declared content, a controlled change history with approvals, and a delivery package whose documentation matches the shipped product.
Predictability improves when behaviour is measured, so a small, lightweight set of metrics is useful. Traceability coverage shows whether evidence keeps pace with change. The gate first-pass rate indicates whether the criteria are realistic and whether teams are preparing in good time. Change turnaround time reveals bottlenecks in analysis or approval processes. Defect leakage from earlier phases into later ones highlights weak gates or rushed integration. These measures are not ends in themselves; rather, they inform process adjustments and facilitate the attainment of higher capability levels when the organisation is ready.
A practical approach is to map current practices against the core ASPICE processes, select a few high-impact gaps to address, define clear entry and exit criteria, establish baseline points and configure stable identifiers in your lifecycle tool. Then, trial these controls on the next delivery. Review the results, address the top impediments and extend the approach to additional processes. ASPICE is then adopted as a set of disciplined habits that fit your context rather than replacing how you work entirely.
In summary, ASPICE is an evidence-driven approach to building automotive software more predictably, not just paperwork. By clarifying what must be achieved and how this will be demonstrated, it helps organisations refine their processes, demonstrate compliance and collaborate effectively with customers and suppliers. The practical payoff is fewer surprises, smoother integrations, and releases that stand up to scrutiny. The broader outcome is safer, more reliable vehicles and a genuine competitive advantage for teams that apply the model well. If you are looking for a structured starting point, consider undertaking a concise readiness scan and a lightweight self-assessment to identify your first few gaps and the evidence you will need to address them.
