What is ASPICE? 

ASPICE, developed as a process reference model within the ISO/IEC 15504 standard, is also known as SPICE – Software Process Improvement and Capability Determination. It was created to assess the performance and help with evaluating software development processes of OEM suppliers in the Automotive industry. It defines best practices and processes to ensure the highest quality of Embedded Automotive Software development. The certification process is based on the audit conducted by external, independent ASPICE-certified assessors.   

ASPICE was developed within the ISO/IEC 15504 standard – Software Process Improvement and Capability Determination, also known as SPICE. Where SPICE gives the framework for software process assessment, ASPICE applies this framework to the Automotive industry.

Find out more about the evolution of SPICE to ASPICE in this article: SPICE to ASPICE – standards evolution and implementation. 

ASPICE CAPABILITY LEVELS 

Suppliers who undergo the ASPICE certification can be scored at one of five capability levels: 

Levels 2 and 3 are usually perceived by clients as the universal standards for excellence, while levels 4 and 5 are treated as aspirations.   

ASPICE guide: Verification and Validation model 

The Verification and Validation model, also known as a V-model, is what Automotive SPICE builds on. The V-model is strict in its requirement for constant evaluation and development, so that potential issues can be eliminated at the first stage. The V-model consists of two stages. Each one of them includes different phases, as illustrated in the graphic below: 

In a V-model, there’s a testing phase alongside each stage of the development. After the development, the software is tested in a sequential order against the requirements specified at the beginning of the project.  
For more information, read: What is ASPICE?

Can ASPICE and agile be combined?

The linear approach implied by the V-model suggests that ASPICE should be associated with a waterfall software development model. However, it’s not the only way to maintain the sequential development cycle.  

ASPICE doesn’t specify how the development process should be conducted. It determines what should be done and what results should be achieved. Therefore, it’s possible to implement certain strengths of agile methodology, so the target results could be achieved in shorter cycles with the flexibility to apply changes during the process, which would be very difficult in a traditional waterfall approach. In other words, by combining ASPICE with agile, the working products can be produced faster and without concerns about software quality.  

It’s important to highlight that the agile approach to software development processes don’t interfere with ASPICE compliance. However, agile methodology can and should be adjusted to the needs and requirements of the Automotive industry. Probably the most well-known approach to combining agile and ASPICE is Agile SPICE ™. It was prepared by the Intacs Working Group as an add-on for Automotive SPICE. Its aim is to help implement agile best practices and achieve ASPICE expectations at the same time.  
Agile SPICE ™ doesn’t favour one specific agile practice, like scrum or kanban. Its objective is to bridge existing PAM processes and outcomes and retain existing process attributes or generic practices on CL1-3.  

Read about Agile SPICE ™ in more detail in this article: How agile and ASPICE combined are a recipe for reducing software development costs.  

What benefits does ASPICE bring? 

ASPICE gives organisations a significant competitive advantage in the Automotive industry. It helps maintain systematic and well-documented Automotive software development and deliver repeatable and predictive results with minimal risk of errors. As a result, companies can produce better quality and more innovative products.  

What is more, ASPICE opens the door to new contracts with the world’s biggest OEMs as it is a widespread and recognisable framework in the Automotive industry. The leading OEMs, like BMW and Audi, select their suppliers based on their ASPICE assessment rating.  

ASPICE vs ISO 26262 

ISO 26262 is the international standard for the functional safety of electrical and electronic systems in road vehicles. The aim of ISO 26262 is to cover all functional safety aspects of the development process. Safety is the main focus of ISO 26262.  

Read our guide to ISO 26262 to find out more about this standard. 

ASPICE differs from ISO 26262 in its purpose, application, and focus. Most importantly, ASPICE defines best practices and processes for automotive software development that are not necessarily related to safety. It is used to evaluate if an organisation meets a specific level of quality and certain safety and performance standards.  

ASPICE focuses on continuous process improvement to raise the supplier’s capability level. In ISO 26262, the focus is on filling all the gaps in compliance identified by the audit. Also, ASPICE takes into consideration the cost and schedule of the development schedule. On the contrary, ISO 26262 primarily targets functional safety.   

Find out more about the differences between ASPICE and ISO 26262

To sum up, the best and most recommended approach is adhering to both ASPICE and ISO 26262 standards for full ASPICE compliance. This is the optimal way to keep the risks of potential failures at a minimum, especially for critical Automotive systems. 

ASPICE vs CMMI 2.0 – software development processes

CMMI 2.0 (Capability Maturity Model Integration) is a model for improving business performance and delivering better products or services. It is also used as a process assessment model of maturity level. It determines different practice areas associated with each level from 0 to 5: the higher the level, the deeper the understanding of the processes within the organisation. Organisations that achieve level 4 or 5 are considered high maturity. 

Both ASPICE and CMMI encompass the software engineering process group, covering the four categories of Process Areas within Automotive software development (process management, project management, engineering and support), but at different depths. Also, CMMI has a broader scope of application than ASPICE. CMMI covers certain process areas that ASPICE doesn’t.  

ASPICE is focused on the engineering practices according to the V-model at a project level- not only software engineering, but also systems engineering (software + hardware, electronics, mechanical, etc.). CMMI is oriented towards project management and other organisational practices at a company level.  

To find out more about the differences between ASPICE and CMMI and whether it’s worth implementing both, read: ASPICE vs CMMI 2.0: Automotive standards deciphered.  

ASPICE: Cybersecurity in automotive industry

In February 2021, the German Association of the Automotive Industry (VDA) has issued Automotive SPICE for Cybersecurity guidelines. This document ended a long period where the Automotive sector was lagging behind almost any industry and not properly addressing cybersecurity threats. It adds an important layer to the existing ASPICE standard and the V-model itself. This new group is named Cybersecurity Engineering Process Group (SEC), with four elements included:

  • SEC.1: Cybersecurity Requirements Elicitation,
  • SEC.2: Cybersecurity Implementation,
  • SEC.3: Risk Treatment Verification,
  • SEC.4: Risk Treatment Validation.

Read more about how to merge cybersecurity guidelines with Automotive SPICE and the V-model in this article on our blog >>> Cybersecurity as a plugin into ASPICE and V-model

We’ll help you prepare for the ASPICE certification process  

If you plan to go through the ASPICE certification process, our experts can provide your team with ASPICE training for any role and at any level. We can also conduct an audit and a gap analysis to identify areas for improvement and help you implement the necessary changes. 

See our ASPICE and FuSa offering or contact us using the form below. 

About the author

Małgorzata Kruszyńska

Małgorzata Kruszynska

Business Researcher