ASPICE – Automotive SPICE – is a standard framework for software process improvement and capability assessment in the automotive industry. When OEMs select software suppliers, ASPICE capability level is a core criterion. With the rapid deployment of autonomous driving and connected vehicles, ASPICE has expanded from traditional ECU software development to autonomous driving and vehicle‑cloud collaboration projects – increasingly becoming a mainstream OEM supplier threshold. This article covers ASPICE's basic definition, assessment process, and key changes in ASPICE 4.0.
1. Standard origins
ASPICE is built on the ISO/IEC 15504 SPICE framework – developed by Germany's VDA (German Association of the Automotive Industry) as a process‑assessment manual specifically for automotive electronics software. The assessment focuses on process capability – whether a process can consistently deliver quality outputs – software performance is a result of process implementation. In short: ASPICE checks whether the development process is standardised – it does not directly judge whether the software has defects.
2. Distinction from related standards
ASPICE and ISO 26262 functional safety overlap. Teams following ASPICE processes generally align with many of ISO 26262 Part 8's process requirements – but the two standards do not substitute for each other. ASPICE focuses on process capability – ISO 26262 focuses on functional safety risk management. For cybersecurity, ISO/SAE 21434 has its own CS‑PAM assessment model – regular ASPICE assessments do not cover cybersecurity – separate cybersecurity process assessments are required.
二、Capability Level Determination
1. Six capability levels
ASPICE defines six capability levels:
·L0 – Not performed: process fails to achieve its purpose.
·L1 – Performed: work products are produced – but without systematic control.
·L2 – Managed: work plans, progress monitoring, and standardised work products are in place.
·L3 – Established: enterprise‑wide standard processes are defined – with project‑specific tailoring.
·L4 – Predictable: process performance is controlled using quantitative data.
·L5 – Innovating: continuous improvement is institutionalised.
OEMs generally require suppliers to achieve at least L2. L2 requires strategy definition, resource allocation, responsibility assignment, training, and work‑product control – all in place. The VDA manual fully defines all six levels – most commercial assessments focus on L2–L3.
2. Assessment scoring
Certified assessors use the NPLF scale to record Base Practice (BP) implementation:
·N – Not achieved.
·P – Partially achieved.
·L – Largely achieved.
·F – Fully achieved.
Individual BP scores cannot be directly converted to a level – all indicators are aggregated to form Process Attribute (PA) conclusions – combined with official rules – the final Process Capability Level (CL) is determined.
三、VDA Assessment Scope and Process Groups
1. Engineering processes
The assessment framework is built on the V‑model:
·Left side: SYS.1 (requirements analysis), SWE.1 (software requirements), SWE.2 (software architecture), SWE.3 (software detailed design), SWE.4 (software unit construction).
·Right side: SWE.5 (software component verification), SWE.6 (software verification), SYS.4 (system integration verification), SYS.5 (system verification).
ASPICE 4.0 unified terminology – changing "testing" to "verification". This is not just wording – it clarifies that verification covers reviews, static analysis, and other non‑execution methods – broader than just testing.
2. Management and support processes
Management: MAN.3 (project management), MAN.5 (risk management), MAN.6 (measurement).
Support: SUP.1 (quality assurance), SUP.8 (configuration management), SUP.9 (problem management), SUP.10 (change request management).
4.0 added machine‑learning requirements – integrated into the new MLE (Machine Learning Engineering) process group – there is no standalone SUP.11.
四、ASPICE 4.0 – Key Updates
1. Expanded scope – hardware and AI engineering
4.0 adds the HWE (Hardware Engineering) process group – covering hardware requirements, design, and verification – extending the standard beyond software to full‑system assessment. It also introduces the MLE (Machine Learning Engineering) group – adapting to AI algorithm development – addressing gaps like dataset management and model generalisation validation.
2. Basic Scope replaces the fixed VDA Scope
3.1 used a fixed VDA scope – including system and software processes – pure‑hardware or pure‑algorithm teams had redundant process requirements. 4.0 introduces Basic Scope with optional extension packages. The base scope only includes general management processes – engineering processes are optional modules – assessment boundaries align with actual product architecture – reducing unnecessary documentation.
3. Traceability and consistency practices merged
The old standard split traceability and consistency verification into two separate practices. 4.0 integrates them – clarifying that the ultimate goal is upstream‑downstream consistency – they are the same management objective – avoiding formal traceability built just to meet clauses.
五、Assessment Process and Preparation Points
1. Full assessment steps
Assessment has four stages:
·Initiation: define assessment scope, boundaries, organisational units, and target levels.
·Data collection: review requirements documents, design files, code, test cases, and review records.
·On‑site interviews: discuss with engineers – verifying process implementation.
·Reporting: consolidate BP scores – output strengths, gaps, and improvement plans.
Bidirectional traceability is a core verification method for engineering processes – assessors randomly sample – checking traceability from requirements to design to test cases – confirming change propagation. Management and support processes do not require bidirectional traceability.
2. Preparation focus
For companies preparing for assessment – focus on continuous evidence retention. Technical documents and tracking records must be archived as the project progresses – no last‑minute document assembly. Run an internal pre‑assessment – identifying common gaps: change‑process gaps, incomplete review closure, broken traceability. Formal third‑party assessments require intacs‑registered assessors – internal self‑checks do not require certification.
六、Common Misconceptions
Misconception 1: ASPICE = software testing standard.
Reality: ASPICE covers the full development process – testing is just one part – assessment covers the entire chain from requirements to delivery – not just testing.
Misconception 2: Sufficient documentation = pass.
Reality: Auditors check evidence consistency – documents alone – if on‑site interviews reveal processes aren't actually implemented – the assessment fails.
Misconception 3: You can compile records just before the assessment.
Reality: Assessors check version histories and timelines – last‑minute records are likely to have logical inconsistencies – resulting in a finding of ineffective process execution.
For ASPICE certification, contact BlueAsia at 13534225140 (King) or email king.guo@cblueasia.com.
Related News
