Automotive SPICE (ASPICE): Automotive SPICE – Tutorial (about 60 minutes)

Automotive SPICE (usually shortened to ASPICE) is the process assessment model that carmakers and their suppliers use to judge how well a development organisation builds software-based vehicle systems. It does not tell you how to write code or design an electronic control unit; it describes what a capable development process must achieve and gives assessors a common yardstick for rating it. After this tutorial you will be able to read an ASPICE capability profile, explain what each process and capability level demands, and plan a realistic path from "we have never been assessed" to a successful Level 2 assessment.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is the Automotive SPICE Process Reference Model and Process Assessment Model version 4.1, published by the Quality Management Center of the German Association of the Automotive Industry (VDA QMC), Working Group 13, with a release date of 24 August 2026 and status "Released". Version 4.1 is a light revision of version 4.0 (a complete revision released in late 2023): its document history lists the removal of one machine-learning base practice (in MLE.2, on resource-consumption objectives) and editorial changes based on community feedback, which also clarify some outcomes. The 32 processes, the six capability levels, the nine process attributes and the rating scale stay the same. Version 4.0 is now listed by VDA QMC as a legacy publication, and the assessment registration scheme accepts assessments based on version 4.0 or higher. A companion book, the VDA Automotive SPICE Guidelines (3rd revised edition, July 2026, based on PAM 4.1, sold in print), adds interpretation and rating rules and a documented assessment process. Verified 2026-10-28 against the VDA QMC Automotive SPICE publications page and the version 4.1 model document.

Who it is for: software, systems and hardware engineers, test and validation engineers, project managers, quality and process people, and supplier-quality staff at carmakers who are new to ASPICE and expect to take part in, prepare for, or commission an assessment.

Prerequisites: none. A rough idea of how embedded products are developed (requirements, design, coding, testing) helps, but every term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why the automotive industry created ASPICE and what problem it solves between carmakers and suppliers.
You will be able to describe the two dimensions of the model: the processes and the capability levels with their process attributes.
You will be able to name the process groups of version 4.x and say which ones form the recommended assessment scope.
You will be able to apply the N-P-L-F rating scale and the rules that turn attribute ratings into a capability level.
You will be able to outline how an assessment is prepared, performed and reported, and who is allowed to lead one.
You will be able to plan practical improvement steps for a project that must reach capability Level 2.
You will be able to position ASPICE against ISO 26262, ISO/SAE 21434, IATF 16949, CMMI and the ISO/IEC 33000 family.

Lesson 1 – Origins, purpose and scope

Why carmakers needed a common yardstick

A modern vehicle contains dozens of electronic control units (ECUs), and a large share of the features a driver notices, from adaptive cruise control to battery management, are realised in software. Almost none of that software is written by the carmaker alone. A typical vehicle program buys ECUs and software from many tier-1 suppliers, who in turn buy components and code from tier-2 suppliers. When a defect reaches the road it can lead to recalls, warranty costs and safety risks, so a carmaker (in industry jargon an OEM, original equipment manufacturer) wants confidence, before it awards a contract and throughout development, that each supplier can deliver working software on time.

Testing the final product alone cannot give that confidence early enough. What a buyer really needs to know is whether the supplier's way of working, its process, is reliable: whether requirements are analysed and traced, whether designs are verified, whether changes and problems are controlled, and whether the project is planned and monitored. If every carmaker invented its own checklist for this, suppliers would face a different audit for each customer, and results would never be comparable. ASPICE exists to give the whole supply chain one shared model and one shared rating method for development process capability.

From ISO/IEC 15504 to Automotive SPICE 4.1

SPICE stands for Software Process Improvement and Capability dEtermination (the current model expands it as "Systems/Software"). It began in the 1990s as an international project that became the ISO/IEC 15504 series on process assessment. In the early 2000s the Automotive Special Interest Group (AutoSIG), a group of carmakers working together with the SPICE User Group, tailored the generic model to automotive embedded development. The first formal release of Automotive SPICE (version 2.2) followed in 2005, and updates continued until version 2.5 in 2010.

Around the same time, the German carmakers agreed in their Herstellerinitiative Software (HIS, "manufacturers' software initiative") on a minimum set of processes that every assessment should cover. That list became known as the HIS Scope and later as the VDA Scope. Responsibility for the model then moved to VDA QMC, whose Working Group 13 released version 3.0 in 2015, version 3.1 in 2017, the completely revised version 4.0 in 2023 and version 4.1 in 2026. In parallel, ISO/IEC 15504 was replaced by the ISO/IEC 33000 family, and ASPICE now states conformance with those newer standards.

What ASPICE covers, and what it does not

ASPICE is intended for assessing the development of embedded automotive systems: the systems, software, hardware and machine-learning engineering that turn stakeholder needs into a released product, plus the management and support work around it. Its process reference model was derived from ISO/IEC 12207 (software life cycle processes) and adapted to vehicle development. If an organisation needs processes outside this scope, it can add processes from other reference models.

Three boundaries are worth fixing in your mind from the start:

ASPICE is a process model, not a product standard. It does not judge whether a brake controller is safe or a gateway is secure; other standards do that.
ASPICE describes what a process must achieve, not how to do it. It does not prescribe a lifecycle, a tool, a template or a document structure. An agile team and a strict waterfall team can both reach the same capability level.
ASPICE is about development. It does not assess series production or manufacturing processes; plant quality is the subject of other standards such as IATF 16949.

Because the model is free to download from VDA QMC and widely demanded by carmakers worldwide, it has become the default language for talking about software development capability in the automotive supply chain, far beyond Germany.

Lesson 2 – Key concepts and vocabulary

ASPICE borrows its assessment vocabulary from the ISO/IEC 33000 family and adds automotive terms. You will hear these words in every assessment, so learn them carefully.

Process reference model (PRM) – the catalogue of processes, each with an identifier, a name, a purpose statement and a list of expected outcomes. It defines the "process dimension".
Process assessment model (PAM) – the PRM plus the indicators an assessor uses to judge evidence, combined with a measurement framework for capability. ASPICE publishes both in one document.
Process purpose and process outcomes – the purpose is the high-level goal of a process; outcomes are the observable results that show the purpose is being met, for example "software requirements are specified".
Base practice (BP) – an activity-oriented indicator specific to one process that shows the outcomes are being achieved, such as analysing software requirements for correctness and feasibility. Base practices are numbered, for example SWE.1.BP3.
Generic practice (GP) – an indicator that applies to every process and shows whether a capability attribute is achieved, such as planning the performance of the process. Generic practices are numbered by attribute, for example GP 2.1.2.
Information item – a result-oriented indicator: a body of information, with listed characteristics, that an assessor expects to find somewhere in the organisation's outputs. Version 4.0 introduced this term in place of the earlier "work product" indicators.
Work product – the real artefact the assessed organisation produces: a requirements database, a design model, a test report, a binary. There is no one-to-one mapping between information items and work products.
Process attribute (PA) – a measurable property of process capability, such as process performance or work product management. There are nine attributes, numbered PA 1.1 to PA 5.2.
Capability level – one of six steps from 0 (incomplete) to 5 (innovating), each defined by one or two process attributes.
Capability profile – the table of ratings and resulting levels for every process in the assessment scope. ASPICE gives no single overall score for a company or project.
Process instance – a specific occurrence of a process, for example SWE.3 performed for hand-written code and for model-generated code; instances can be rated separately and then aggregated.
Assessment scope – the agreed boundaries of an assessment: the organisational unit, the processes, the target capability level for each, and the process context (which product release, which requirements and changes).
Bidirectional traceability – links that let you follow each requirement forward to the design elements and tests that address it, and from each test or design element back to its source.
Consistency – the content of linked items actually matches; a trace link to a test that no longer checks the requirement is traceable but not consistent.
Verification and validation – verification checks a work product against its specification ("did we build it right?"); validation, covered by VAL.1, provides evidence that the product fits its intended use ("did we build the right thing?").
Lead assessor – the certified assessor who is accountable for planning and conducting the assessment and for the conformity of its results.

The two-dimensional model

The single most important idea in ASPICE is that capability is measured in two directions at once. The process dimension asks: which processes are we looking at, and does each one achieve its purpose? The capability dimension asks: how well is each process managed, standardised and controlled? Indicators connect the two. Base practices and output information items support judging the process outcomes; generic practices and their information items support judging the higher process attributes. The assessor collects evidence, maps it to indicators, rates the attributes and derives a level for each process.

Figure 1 – How the process dimension and the capability dimension meet through indicators and evidence to produce a capability profile.

A useful way to remember the split: Level 1 is about doing the right technical things (the outcomes of each process are achieved), while Levels 2 to 5 are about how the doing is managed (planned, controlled, standardised, measured and continuously improved).

Lesson 3 – Structure of the model

The process dimension: three categories, eleven groups, 32 processes

Version 4.x organises its 32 processes into eleven process groups, which sit in three categories. Each process has a three-letter group prefix and a number. The numbers are not consecutive (there is a SUP.8 but no SUP.2 in version 4.x) because the numbering was kept stable from earlier versions when processes were removed.

Figure 2 – The three process categories of Automotive SPICE 4.x and the process groups inside each.

The primary processes are the ones a supplier or acquirer performs to buy, build and deliver a product:

Acquisition (ACQ) – one process, supplier monitoring, used when an organisation buys from its own suppliers and must track and steer them.
Supply (SPL) – one process, product release, covering how release content is defined, built and delivered with the right documentation.
System engineering (SYS) – requirements elicitation, system requirements analysis, system architectural design, system integration and integration verification, and system verification.
Validation (VAL) – one process that provides evidence the delivered product meets the expectations of its intended use, for example through real-world use-case tests or end-user trials.
Software engineering (SWE) – software requirements analysis, architectural design, detailed design and unit construction, unit verification, component verification and integration verification, and software verification.
Machine learning engineering (MLE) – ML requirements analysis, ML architecture, ML training and ML model testing, for software elements whose behaviour is learned from data.
Hardware engineering (HWE) – hardware requirements analysis, hardware design, verification against the hardware design and verification against the hardware requirements, for electronic hardware.

The supporting processes can be used by any other process: quality assurance (SUP.1), configuration management (SUP.8), problem resolution management (SUP.9), change request management (SUP.10) and machine learning data management (SUP.11).

The organizational processes build assets that help projects: project management (MAN.3), risk management (MAN.5), measurement (MAN.6), process improvement (PIM.3) and management of products for reuse (REU.2).

Version 4.0 was a deliberate reshaping. Compared with version 3.1 it removed ten processes: six acquisition processes (only ACQ.4 Supplier Monitoring remains), SPL.1 Supplier Tendering, and the support processes SUP.2 Verification, SUP.4 Joint Review and SUP.7 Documentation. Verification now lives inside the engineering processes themselves rather than in a separate support process. In their place it added ten: VAL.1 Validation, the four hardware engineering processes, the four machine learning engineering processes and SUP.11. The total therefore stayed at 32 while the content moved closer to how vehicle electronics are built today.

How a single process is described

Every process in the model follows the same template, which makes the document easy to navigate once you know it:

Process ID and name, for example SWE.4 Software Unit Verification.
A purpose statement: one sentence on why the process exists.
Process outcomes: the numbered results that show the purpose is achieved.
Base practices: the activities that typically produce those outcomes, each mapped to one or more outcomes.
Output information items: the kinds of information the process normally produces, mapped to outcomes, with their characteristics listed in an annex.

Engineering processes share a recognisable rhythm of base practices: specify, structure or analyse, then ensure consistency and establish bidirectional traceability, and finally communicate the agreed result to the affected parties. Verification processes follow their own pattern: specify verification measures, select them for a given release, perform them, ensure traceability, and summarise and communicate the results.

The capability dimension: six levels, nine attributes

The measurement framework is an adaptation of ISO/IEC 33020:2019. It defines six capability levels; every level above 0 is achieved through one or two process attributes.

Level	Name	Process attributes	In plain words
0	Incomplete	none	The process is missing or does not achieve its purpose.
1	Performed	PA 1.1 Process performance	The outcomes are achieved, even if in an ad hoc way.
2	Managed	PA 2.1 Performance management; PA 2.2 Work product management	The work is planned, monitored and adjusted, and its outputs are defined, reviewed and controlled.
3	Established	PA 3.1 Process definition; PA 3.2 Process deployment	A standard organisational process exists and projects use tailored versions of it.
4	Predictable	PA 4.1 Quantitative analysis; PA 4.2 Quantitative control	Measurement data are used to keep the process within defined limits and to act on causes of variation.
5	Innovating	PA 5.1 Process innovation; PA 5.2 Process innovation implementation	The process is continually improved in response to changing business goals.

Figure 3 – The six capability levels and the process attributes that must be achieved to climb each step.

The rating scale

Each process attribute is rated on a four-point ordinal scale, which ASPICE takes over unchanged from ISO/IEC 33020:

N, not achieved – little or no evidence; 0 to 15 % achievement.
P, partially achieved – some evidence of an approach and some achievement, with parts unpredictable; above 15 % up to 50 %.
L, largely achieved – a systematic approach with significant achievement, though some weaknesses exist; above 50 % up to 85 %.
F, fully achieved – a complete and systematic approach with full achievement and no significant weaknesses; above 85 % up to 100 %.

Assessors may refine P and L into P-, P+, L- and L+ to give more nuance, splitting each band at its midpoint (32.5 % and 67.5 %). The percentages are not computed with a calculator; they describe the degree of achievement the assessor judges from evidence.

From attribute ratings to a capability level

The rule that turns ratings into a level is short but strict: a process reaches level n when the attributes of level n are rated at least L (largely or fully), and every attribute of all lower levels is rated F. So a process with PA 1.1 = F, PA 2.1 = L and PA 2.2 = F is at Level 2. A process with PA 1.1 = L, however good its planning, stops at Level 1, because Level 2 requires the Level 1 attribute to be fully achieved. Remember this rule; it explains most of the "surprising" results that teams see in their first assessment report.

Two further points round out the structure. First, ratings may be made with one of three rating methods defined in ISO/IEC 33020 (named R1, R2 and R3), which differ in how detailed the characterisation is and whether ratings for several process instances are aggregated; the lead assessor chooses and documents the method. Second, the VDA guidelines provide detailed interpretation and rating rules for Levels 1 to 3 only, because that range covers most automotive assessments.

Lesson 4 – How it works in practice

The V-model and the plug-in concept

Although ASPICE does not prescribe a lifecycle, its engineering processes are easiest to understand when drawn as the familiar V. On the left side, needs are refined into requirements and architecture at system level, then into software (or hardware, or ML) requirements and designs. On the right side, the pieces are verified and integrated back up. Each process on the right verifies the results of its partner on the left.

Figure 4 – The system and software processes as a V: specification runs down the left side, and integration and verification climb the right side back up to validation.

The plug-in concept describes how this V scales to different products. The system-level processes (SYS) form the top of the V. Underneath, one or more domain-specific "plug-ins" are added depending on what the project develops: SWE for software, HWE for electronic hardware, MLE (together with SUP.11) for machine-learning elements. Management and support processes are domain-independent and apply at system level and at every domain level. Other domains, such as mechanical engineering, can be attached using the same idea through separate models that are not part of ASPICE itself.

Traceability, consistency and communication

Three themes run through nearly every engineering process, and they are where many projects struggle:

Bidirectional traceability between stakeholder requirements, system requirements, architecture, software requirements, design, units, verification measures and results. Assessors will pick a requirement and ask you to follow it down and back up.
Consistency of the linked content. Links are necessary but not sufficient; the assessor checks samples to see that the linked items actually agree.
Communication of agreed results to affected parties, for example that the software architecture has been shared with the teams who must implement it, or that verification results reached the project lead.

Version 4.x merged traceability and consistency into single base practices per process and supplies a reference picture of the expected trace chains in its annex. In practice, teams use requirements management and application lifecycle management tools to hold these links, but a tool alone proves nothing; the assessor looks at whether the links are complete, current and used.

What Level 2 means day to day

Many carmakers ask suppliers for capability Level 2 on the recommended scope, and some ask for Level 3. It helps to translate the Level 2 attributes into concrete habits.

PA 2.1 Performance management asks whether each process is run as managed work. Its generic practices cover identifying objectives and a strategy for the process, planning it, determining and providing resources, monitoring and adjusting performance, and managing the interfaces between involved parties. For software unit verification, for instance, this means someone decided what level of unit verification is needed, planned when and by whom it happens, made sure tools and people were available, tracked progress against the plan and coordinated with the developers and the integration team.

PA 2.2 Work product management asks whether the outputs are under control. Its generic practices cover defining requirements for the work products (content, structure, quality criteria), defining how they are stored and controlled, actually identifying, storing and controlling them, and reviewing and adjusting them. For the same unit verification process, that could mean a defined format and review criteria for unit verification reports, storage in configuration management with versions tied to baselines, and documented reviews.

Level 3 then asks the organisation, not just the project, to define a standard process (with roles, competencies, resources, methods for monitoring) and to show that projects deploy a tailored version of it and feed back experience. That is why Level 3 is usually an organisational investment, while Level 2 can be reached project by project.

The "what, how, doing" distinction

The model explains the term "process" at three levels of abstraction. The PAM sits at the "what" level: goals, outcomes, technical dependencies. Your company's process descriptions, methods, templates and tools sit at the "how" level. Actual project work is the "doing". An assessor looks at the doing and at your how, then maps what they find to the what. This is why the model can be applied to agile, model-based or traditional development alike: the indicators do not dictate the order of work or the number of documents. For example, SYS.2 does not mean you must have exactly one system requirements specification; a well-managed requirements database split across several modules can satisfy it.

Implementation steps for an organisation

Organisations that adopt ASPICE for the first time typically move through these steps:

Clarify the driver: which customer asked for which processes and which capability level, and by when.
Agree the scope: which projects, which processes (usually starting from the recommended VDA scope), which plug-ins apply.
Run a gap analysis, ideally with an experienced assessor, against the base practices and generic practices of the target level.
Define or update the "how": a lightweight process description per process, templates, tool configuration, review checklists and role definitions.
Train the people who will do the work, not only the quality department.
Pilot on a live project and fix what does not work; let quality assurance (SUP.1) check adherence objectively.
Hold an internal or informal assessment to test readiness, then a formal assessment when evidence has been produced over a meaningful period.
Use the findings for continuous improvement (PIM.3) rather than treating the assessment as the finish line.

Lesson 5 – Assessment, certification and compliance

What is assessed, and what is not certified

An ASPICE assessment evaluates the capability of selected processes in a defined organisational unit, almost always a single project, against the PAM. The result is a capability profile: one capability level per process, with strengths, weaknesses and improvement suggestions. There is no overall company level, and no scheme certifies a company as "ASPICE Level 2". Results describe the assessed project in its context. The VDA guidelines advise that results are not generally transferable to other sites, product domains or distributed teams that were not assessed. They add that experience supports relying on them for about twelve months for the assessed project: less if the work moves site, the organisation is restructured or the processes change, and possibly longer if the project is very stable.

Who may assess

Assessors are people, not companies. The assessor qualification scheme is defined by intacs (the International Assessor Certification Scheme association), and VDA QMC acts as the personnel certification body for Automotive SPICE. Candidates complete training with an intacs-registered training provider, pass an exam and receive a licence. The scheme has grades: everyone starts as a provisional assessor; the higher grades, competent assessor, principal assessor and instructor, are the ones allowed to act as lead assessors. A licence is valid for three years and must then be renewed. To enter the scheme, a candidate needs at least 24 months of professional experience in developing software-based systems in the automotive sector.

Roles in an assessment

Sponsor – the party that requires the assessment and pays for it, often a carmaker's supplier-quality department, or the supplier's own management for an internal assessment.
Lead assessor – accountable for the assessment plan, the team, the conduct of the assessment and the conformity of the result.
Co-assessor – takes part in interviews and evidence review and in the joint rating.
Local assessment coordinator – organises the assessment inside the assessed organisation: rooms, schedules, access to tools and people.
Participants – the engineers, managers and quality staff who are interviewed and show evidence.

The assessment process

The VDA guidelines provide a documented assessment process that conforms to ISO/IEC 33002 and is set up to serve most automotive assessments. It assumes a "Class 3" assessment in the ISO/IEC 33002 sense that is not meant to rate organisational maturity, and it has three main stages.

Figure 5 – The main stages of a formal Automotive SPICE assessment, from initiation to report, registration and improvement.

Prepare. The sponsor states the purpose (for example, reducing delivery risk for a product, or finding improvement potential). The lead assessor and sponsor define the scope: organisational boundaries, processes, the target capability level per process, and the process context, such as "all requirements and changes for release B2". The team is appointed, a plan is agreed, and confidentiality is settled. If the processes deviate from the recommended VDA scope, the reason is documented. Dropping a process later is a documented change of the assessment input that the sponsor must approve; calling a process "not applicable" without that approval is not allowed, and a simple lack of evidence usually leads to an N rating rather than an exclusion.
Perform. Over several days, the team interviews the people doing the work and examines real work products in their real tools. Every piece of evidence is mapped to indicators. The team consolidates its observations and rates each process attribute, process by process, then gives the assessed team verbal feedback.
Report. The lead assessor issues a report with the capability profile, ratings, strengths, weaknesses and the scope and context, plus an assessment log for the record.

Registration and the "Certificate of Achievement"

Since January 2026, VDA QMC runs an assessment registration scheme. An independent assessing organisation (a legal company, not an individual, and never the assessed organisation itself) may register an assessment that used PAM 4.0 or later, was led by an assessor of at least competent grade with a co-assessor of at least provisional grade, and took place after 1 January 2025. After checking the formal criteria and receiving the registration fee, VDA QMC sends a registration number and QR code. Only then may the assessing organisation issue a "Certificate of Achievement" carrying the Automotive SPICE logo, showing the assessed organisation and project, scope, date and achieved capability level (the lowest level across the processes in scope), signed by the assessing organisation and the lead assessor. The assessing organisation and its lead assessor remain fully responsible for the result; VDA QMC neither issues the certificate nor vouches for the result. It is still a statement about one assessed project, not a certification of the company.

Lighter forms of evaluation

Not every evaluation is a formal assessment. Organisations run self-assessments and gap analyses to prepare. VDA QMC also publishes an Automotive SPICE Potential Analysis (PoA), a lighter evaluation built on a subset of version 4.0 and intended to judge the capability of a potential partner before a contract is awarded. These are useful tools, but their results should not be presented as formal assessment ratings.

Why customers care about the profile

For a carmaker, an assessment profile feeds supplier selection, development risk management and escalation decisions. For a supplier, it is a structured list of where its processes are weak. The most valuable use is the second one: assessment findings tied to concrete evidence are a strong basis for improvement, while chasing a number for its own sake tends to produce paperwork that impresses nobody.

Lesson 6 – Worked example: a Tier-1 supplier prepares for Level 2

The situation

Voltera Drive Systems (a fictional company) is a tier-1 supplier of battery management systems for electric vehicles. Its new project, BMS Gen3, includes a custom electronic board, embedded software in C, and a small ML-based model that estimates battery state of health. A European carmaker awards the contract with a condition in the supplier agreement: the project must demonstrate capability Level 2 for the recommended VDA scope before the start of production, with an intermediate assessment at the B-sample milestone.

Step 1 – Work out the scope

The quality manager, Ana, starts by translating the condition into a concrete scope. The recommended VDA scope consists of a base set (MAN.3 Project Management, SUP.1 Quality Assurance, SUP.8 Configuration Management, SUP.9 Problem Resolution Management and SUP.10 Change Request Management) plus at least one engineering plug-in. Because BMS Gen3 builds a system with software and hardware, the plug-ins are system engineering (SYS.2 to SYS.5), software engineering (SWE.1 to SWE.6) and hardware engineering (HWE.1 to HWE.4). The ML estimator raises the question whether MLE.1 to MLE.4 and SUP.11 should be included; after discussion with the customer, they agree to add them because the model affects a customer-visible function. Optional processes such as ACQ.4 (Voltera buys its cell-monitoring chip and an RTOS from suppliers) are noted for a later assessment.

Step 2 – Gap analysis

Ana engages an external competent assessor for a two-day gap analysis on the B-sample work so far. The findings are typical for a first contact with ASPICE:

System requirements exist in a requirements tool, but many software requirements are written directly from customer documents without a link to system requirements. Traceability is broken in the middle of the V.
Unit tests are run by the developers, but nobody defined which units need which verification measures (for example, static analysis versus unit tests versus reviews), and results are stored on personal drives.
The project plan exists, but it is a milestone chart only; the software and hardware teams plan their work informally and nobody tracks effort.
Problem reports and change requests share a single ticket type with no defined states, so it is hard to see what was analysed, approved or verified.
The ML team trains models in notebooks; the training data set and its version are not recorded with the trained model.

Step 3 – Improvement plan

Instead of writing a large process handbook, the team picks targeted improvements, each owned by the people who will use it:

The system architect and software lead restructure requirements: software requirements are derived from allocated system requirements, with trace links in the tool and a weekly report of untraced items.
The software lead writes a one-page unit verification strategy: which units get static analysis and coding-rule checks, which get unit tests with which coverage target, which get reviews. The CI pipeline stores results, linked to the commit and the baseline.
The project manager splits the plan into work packages per discipline with estimates, and introduces a weekly tracking meeting with a simple status and risk list; deviations lead to recorded corrective actions.
Configuration management is defined: what is a configuration item, how baselines are named, when they are created (every sample delivery), and how they are audited.
Separate workflows are created for problem reports and change requests, each with states, an approval step and a link to the verification that closes them.
The ML team adopts ML data management (SUP.11): a data management system with a lifecycle and status for each data item, data quality criteria, and versioned data sets with recorded provenance. Training records (MLE.3) then link each trained model to the data set and hyperparameters that produced it.
Quality assurance (SUP.1) is reorganised so that an engineer outside the project checks process and product samples monthly and escalates unresolved issues to the head of engineering.

Step 4 – Live with it, then assess

The team runs with the new practices for four months, through one full sample delivery, before the formal B-sample assessment. This matters: assessors look for evidence of the practices in use, not a pile of templates created last week. The carmaker sponsors the assessment, appoints a lead assessor and a co-assessor, and agrees a scope covering the B2 software and hardware release and all requirement changes since the A-sample.

Step 5 – Reading the result

The report contains a capability profile. An extract looks like this:

Process	PA 1.1	PA 2.1	PA 2.2	Level
MAN.3 Project Management	F	L	L	2
SYS.2 System Requirements Analysis	F	F	L	2
SWE.1 Software Requirements Analysis	F	L	F	2
SWE.4 Software Unit Verification	L	F	L	1
HWE.3 Verification against Hardware Design	F	P	L	1
SUP.8 Configuration Management	F	L	F	2

Two results catch management's attention. SWE.4 has strong management attributes but sits at Level 1, because PA 1.1 is only largely achieved: older units carried over from Gen2 were never covered by the new unit verification strategy, so some outcomes are only partly met. HWE.3 is held back for a different reason: the hardware verification was performed, but without a plan or monitoring, so PA 2.1 is only partially achieved. Ana explains to management that the rule demands full achievement of lower attributes, so the fixes are different: SWE.4 needs technical completion for the legacy units, HWE.3 needs planning and tracking discipline.

Step 6 – Close the loop

The team adds both topics to its improvement backlog, re-plans the legacy unit verification, and gives the hardware lab a verification plan with tracked progress. Six months later, the pre-SOP assessment shows Level 2 across the agreed scope. Voltera then decides to define organisation-wide standard processes from the practices that worked on BMS Gen3, which is the first step towards Level 3. Because the pre-SOP assessment was performed by an independent assessing organisation with a competent lead assessor, Voltera asks that organisation to register it with VDA QMC, so that a Certificate of Achievement can be shown to other customers, always described as a result for that project.

Notice what the example shows: the work was not about writing documents for assessors. Each change addressed a real engineering weakness (lost traceability, untracked verification, uncontrolled data) that would otherwise have caused defects or late surprises.

Lesson 7 – Relationship to other standards and frameworks

ASPICE rarely stands alone. A supplier developing a battery management system will usually also face functional safety, cybersecurity and quality management requirements. Knowing how these fit together avoids duplicated effort.

Standard or framework	What it addresses	Relationship to ASPICE
ISO/IEC 33000 family (33001, 33002, 33004, 33020 and others)	Generic requirements for process assessment, process models and measurement frameworks	ASPICE is a domain-specific PRM and PAM that conforms to these standards; its rating scale and capability levels are adapted from ISO/IEC 33020.
ISO/IEC 15504	The original SPICE process assessment series	The historical basis of ASPICE; superseded by the ISO/IEC 33000 family.
ISO/IEC/IEEE 12207 and 15288	Software and system life cycle processes	The ASPICE PRM was derived from 12207; processes from 12207 or 15288 can be added where ASPICE has none.
ISO 26262	Functional safety of road vehicle E/E systems, organised around a safety lifecycle	Complementary: ASPICE capability supports the rigour ISO 26262 expects, but ASPICE says nothing about safety goals, ASILs or safety analyses. ISO 26262 is a lifecycle, not a process reference model.
ISO/SAE 21434 and Automotive SPICE for Cybersecurity	Cybersecurity engineering for road vehicles	ISO/SAE 21434 defines cybersecurity requirements; VDA QMC publishes a separate ASPICE for Cybersecurity model that adds cybersecurity processes for assessing capability in that area.
IATF 16949	Automotive quality management system requirements, certified by third parties	IATF 16949 expects organisations that develop products with embedded software to assess their software development capability; ASPICE is a widely used way to do that. IATF 16949 certifies organisations; ASPICE does not.
CMMI	A cross-industry capability and maturity model with organisational maturity levels	Similar aims, but CMMI is not automotive-specific and can rate organisational maturity, while ASPICE rates the capability of individual processes in a project.

Integrating ASPICE with functional safety and cybersecurity

The model itself points out that ISO 26262 and ISO/SAE 21434 are built around lifecycles, which belong at the "how" level, while ASPICE stays at the "what" level. In practice, organisations build one integrated development process in which, for example, safety requirements are handled as a category of requirements inside SYS.2 and SWE.1, safety analyses feed the architecture processes, and the same configuration and change management serves all three standards. The work products then provide evidence to ASPICE assessors, functional safety assessors and cybersecurity auditors at once. Keep the questions separate, though: an ASPICE Level 2 rating does not demonstrate that a product is safe or secure.

ASPICE and agile development

ASPICE is sometimes seen as incompatible with agile methods. It is not. Because the model is at the "what" level, sprint planning and backlogs can provide evidence of project planning and monitoring, user stories can serve as requirements if they are analysed, traced and verified, and a continuous integration pipeline can produce much of the verification evidence. The VDA guidelines include a section on rating in agile environments. The real risk with agile teams is not the method but weak traceability, missing architecture work or undocumented decisions, which an assessor will notice in any lifecycle.

Common pitfalls and best practices

Common pitfalls

Treating ASPICE as a documentation exercise: creating templates and documents shortly before the assessment, which assessors quickly recognise as unused.
Expecting a company-wide certificate or a single overall score, and then presenting one project's result as if it applied to every site and product.
Investing in management attributes (plans, reviews, tools) while leaving Level 1 outcomes incomplete, which blocks Level 2 regardless of how polished the planning is.
Relying on a tool's trace links without checking that the linked content is consistent and current.
Copying another company's process handbook instead of describing how your own teams actually work, so that the "how" and the "doing" never match.
Assuming ASPICE compliance proves functional safety or cybersecurity, or vice versa.
Excluding difficult processes from the scope by declaring them "not applicable" rather than agreeing a documented and justified scope change with the sponsor.

Best practices

Start from the customer's requirement and the recommended VDA scope, and write down the scope, plug-ins and target levels before doing anything else.
Run an early gap analysis with an experienced assessor, and prioritise fixes that remove real engineering risk.
Build traceability into daily work and tooling from the first requirement, rather than reconstructing it late.
Keep process descriptions short and owned by practitioners; let them evolve with feedback.
Make quality assurance objective and independent of the people whose work it checks, with a clear escalation path.
Integrate ASPICE, functional safety and cybersecurity into one development process so that one set of evidence serves all of them.
Use assessment findings as input to continuous improvement and re-check after significant organisational or project changes.

Summary and key takeaways

Automotive SPICE is the automotive industry's shared model for assessing development process capability; the current edition is version 4.1 (2026) from VDA QMC, a light revision of the completely rewritten version 4.0.
The model has two dimensions: 32 processes in eleven groups and three categories, and six capability levels defined by nine process attributes.
Base practices and output information items indicate process outcomes; generic practices indicate the higher process attributes. They guide assessors and are not a mandatory checklist.
Attributes are rated N, P, L or F; a level is achieved when its own attributes are at least L and all lower attributes are F.
The recommended VDA scope combines project management and core supporting processes with at least one engineering plug-in (system, software, hardware or machine learning).
Assessments are led by intacs-certified assessors, cover a defined project and context, and produce a capability profile per process; there is no company certification, though registered results may carry a Certificate of Achievement since 2026.
ASPICE complements ISO 26262, ISO/SAE 21434 and IATF 16949; it rates process capability, not product safety or security.
The best preparation is real engineering discipline in daily work: traceable requirements, planned verification, controlled configurations and honest improvement.

Reflection questions

Think of a project you know. Which engineering plug-ins would its ASPICE assessment scope need, and which optional processes would you argue to add or leave out, and why?
Pick one requirement from that project. Could you follow it down to its implementation and verification and back again today? Where would the trail break?
Your team has excellent plans and reviews, but some outcomes of a verification process are only partly achieved. How would you explain to management why the process cannot reach Level 2 yet, and what would you fix first?
How would you describe your current way of working at the "how" level so that an assessor can map it to the model, without writing documents nobody uses?
Where could one integrated process give evidence for ASPICE, ISO 26262 and ISO/SAE 21434 at the same time in your organisation, and where must the questions remain separate?