Automotive SPICE 3.1 vs 4.0

17.04.2025
Automotive SPICE®

The automotive industry is undergoing rapid technological advancement, driven primarily by the increasing complexity of modern vehicles. With the increasing integration of vehicles into software and sophisticated systems, the focus has shifted to improving software quality, system integration, and the overall reliability of electronic components. This shift is not only critical for autonomous vehicles, electric cars, and connected technologies, but also for the introduction of AI and machine learning in automotive systems, which are rapidly changing the way vehicles are designed, tested, and manufactured.

As these technologies evolve, development processes in the automotive sector must adapt to ensure the delivery of safer, more reliable, and higher-performing products. ASPICE (Automotive SPICE), a widely recognized standard for evaluating and improving development processes in the automotive industry, plays a central role in this transformation. Originally developed to assess the maturity of software development processes, ASPICE has continuously evolved to meet the increasing complexity of modern automotive systems.

To keep pace with these advances, ASPICE itself has undergone significant updates. These updates reflect the industry's growing reliance on system engineering, agile methods, functional safety, cybersecurity, and the integration of AI-driven processes. Two important versions of the ASPICE model that are widely discussed in the industry today are ASPICE 3.1 and ASPICE 4.0.
In this article, we provide a detailed overview of ASPICE 4.0 and highlight the most important updates and improvements it introduces. We will examine the new processes and improvements in ASPICE 4.0, outline the changes compared to the previous version, and offer a detailed comparison between ASPICE 3.1 and ASPICE 4.0, focusing on their most important differences and the implications for the assessment and improvement of processes in the automotive industry.

What is ASPICE?

What is ASPICE?

Automotive SPICE (ASPICE) is a process assessment model developed to improve software and system development processes in the automotive industry. It helps companies assess the maturity level of their development processes and ensures the development of high-quality, reliable, and safe automotive systems. ASPICE is frequently used by OEMs (original equipment manufacturers) and Tier 1 suppliers to assess their process capabilities.

ASPICE 3.1 Older version

ASPICE 3.1 was the industry standard for process assessment in the automotive industry prior to the release of ASPICE 4.0. Although it was a solid framework for assessing and improving processes in automotive development, its focus was primarily on:

Process capability levels
ASPICE 3.1 has outlined process capability levels from 0 to 5. These levels help companies assess the maturity and effectiveness of their processes.
Focus on software development
The focus was strongly on processes related to software development, such as requirements management, design, verification, and validation.
Strong emphasis on traceability
Traceability between different process stages, particularly in software development and system design, was a key priority.
**🚫Processes excluded in ASPICE 4.0

ASPICE 4.0

The release of ASPICE 4.0 marks a significant advancement of the standard. ASPICE 4.0 has introduced several important upgrades to better address the challenges of modern automotive development, with a focus on new technologies and the integration of complex systems.

New process groups are displayed below the VDA area and processes have been added.

New process groups: 3

  1. Machine Learning Engineering Process Group (MLE)
  2. Hardware Engineering Process Working Group (HWE)
  3. Validation Group (VAL)

Extended process group: 1 (A new process is added to the SUP group)

  1. Data management in the field of machine learning (SUP.11)
** ⭐ New

Recommended VDA range:

The table above lists the basic practices that are inherent within the scope. In addition, depending on the type of project—whether it involves systems, software, hardware, or machine learning—the appropriate plug-ins should be included in the scope, and then the project will be covered by the VDA.

E.g.:

Previously included in the VDA scope – Base + SYS + SWE

Now included in the VDA scope: Base + any plug-in based on the project

The following table shows optional basic practices that give us the flexibility to choose according to project needs, and they are not mandatory.

Machine learning process group

The automotive industry is currently moving toward the development of advanced autonomous vehicles, and therefore the software should also include machine learning functions. The traditional software engineering (SWE) process group alone will not be sufficient to meet this need. Machine learning has become indispensable as it plays a crucial role in important activities such as data management and algorithm training. Machine learning engineering (MLE) can be integrated into the SWE process as a plug-in, starting with the design of the software architecture and continuing through software integration and integration testing.

  • Identify software elements for machine learning development from the software architecture
  • MLE processes are applied to ML-based software elements, and others apply from SWE 3 to SWE testing
  • ML test results must be integrated into other software components, and SWE.5 processes must be applied to these.

Hardware Engineering Process Working Group

Hardware engineering was already available in SPICE as a separate module (PAM). Integration with ASPICE 4.0 enables us to handle process mechatronics disciplines consistently. (SYS; SW, HW)
HWE Scope only covers electrical or electronic hardware and does not represent mechatronics and control units.
This excludes system-level engineering, including mechatronics, processes at the control unit level, procurement, mechanical or hardware prototyping, or production processes that are addressed via interfaces to the relevant processes.

Important changes in terminology

  • System: The term “system” is used in different contexts at different levels (SYS.x).
  • If a project is limited exclusively to software, it is not referred to as a “system” because it is dependent on hardware.
  • The vehicle is considered the primary system, which encompasses several sub-levels such as hardware, mechatronics, and software.
  • The right side of the V-cycle in development, formerly referred to as “test,” has now been changed to “verification.”
  • Test specifications are now referred to as “verification measures.”
  • Validation is added as a new process group that takes place in Project after system verification is complete.

Training

Assessors who have already participated in a corresponding training course in 3.1 have the option of updating it to 4.0, but the new training structure applies to new members who wish to complete it.

A new training course will be introduced before you can begin training as a provisional assessor. This training focuses on ASPICE Base Practices, System, Software, and content guideline aspects. * Note: This training does not include the new process groups HWE and MLE.

This training deals with a certified process expert (ASPICE) who imparts knowledge about the processes and implementation, but not “How to assess.” The assessment topics are covered in the training program for provisional assessors.

Key points

ASPICE 4.0 brings several improvements over ASPICE 3.1, particularly by taking into account the growing importance of safety, cybersecurity, and the integration of newer technologies such as autonomous driving, AI, and electric vehicles.

ASPICE 4.0 is more flexible and enables a wider range of development approaches, including Agile and DevOps.

The processes in ASPICE 4.0 are more closely aligned with modern industry standards, including ISO 26262 and ISO 21434, making them more comprehensive for automotive companies facing complex development environments.