ASPICE (Automotive Software Process Improvement Capability dEtermination) is an industry-standard guideline for evaluating software development processes. Introduced in 2005, ASPICE helps automotive suppliers incorporate best practices to identify defects earlier in development and ensure that OEM requirements are met.

ASPICE is a domain-specific adaptation of SPICE, the ISO 33061 standard, which has been used by a variety of industries for decades to sharpen their software development practices. ASPICE addresses specific needs of the automotive industry that its predecessor was not designed to meet, including a greater emphasis on cybersecurity.

The amount of software included in vehicles has expanded rapidly — from zero lines of code just a few decades ago to more than 200 million in some cases today. This complexity means projects typically have hundreds of engineers working together to meet tens of thousands of requirements. Making sure everyone is on the same page is critical to meet OEM requirements. But how does an organization do that efficiently?

When someone hires a construction company to build a house, it is a standard practice to conduct periodic walkthroughs to verify that the approved construction plans are being followed. It is easier and less expensive to fix a critical mistake, such as improper plumbing, when it is discovered earlier in the project. The same is true for software development — except that it is more difficult to clearly see a software project as it is being constructed. ASPICE gives OEMs confidence that the needs of their projects are accounted for every step of the way.

When a premium OEM compared suppliers that use ASPICE against those that did not, it discovered that the average ASPICE supplier found 90 percent of defects 11 months before the start of production, whereas the average non-ASPICE supplier found 90 percent of defects just two months before the start of production, putting an on-time launch at risk.

Customer needs come first

ASPICE leverages the V-model of software development, which splits the process into two parts. The left side of the letter V represents the design and development steps, and the right side represents the testing steps. In this way, every development step is mirrored by a testing step. The letter V also stands for verification and validation.

When hundreds of cooks are in the kitchen, it is important to make sure that they all use the right recipe and that the meal they are cooking is what the customer ordered. Verification ensures that a piece of software meets the required specifications, while validation ensures that the specifications meet the OEM’s needs.

ASPICE assessments look at how well engineers conduct a requirement analysis to distill customer requests into requirements and then trace their work back to those requirements.

At Aptiv, we call the requirement analysis the Product Development Process (PDP), and it helps us extrapolate customer requests into diverse scenarios for a more complete picture. For example, if an OEM specifies a minimum distance for its automatic braking system to function successfully, we take into account how different driving conditions, such as rain or poor lighting, will affect performance. After determining the functional requirements for each scenario, we map a work process for the project development, identify the resources needed and define the logical operations between the hardware and the software.

The thorough requirement analysis guides software development and helps provide engineers with the guideposts they need for their code.

Focused on intended outcomes, not on the process

ASPICE does not dictate specific tools or techniques that engineers must use. Companies are free to establish their own development processes, so long as the intended outcomes are achieved. For example, an ASPICE assessor will determine whether engineers have traced their system’s specifications back to the requirement analysis.

ASPICE assessors use an NPLF scale to rate the degree to which the desired outcome was achieved. According to the scale, the results are either “not achieved,” “partially achieved,” “largely achieved” or “fully achieved.” The assessor assigns an NPLF rating for multiple expected outcomes and uses the aggregate rating to determine the overall capability level of the entire project. OEMs determine what will be considered an acceptable capability level for each project.

Suppliers select members of their teams who have at least three years of relevant work experience to complete provisional ASPICE assessor training and certification through the International Accessors Certification Scheme (Intacs), an independent, nonprofit company established by the ISO board. To earn a Competent Assessor certificate, the employee must have completed at least 250 hours as a provisional assessor.

ASPICE complements existing standards

ASPICE goes hand in hand with many existing safety and quality management best practices. In fact, achieving ASPICE Capability Level 2 is typical for completing an ISO 26262 functional safety audit. ASPICE also exemplifies Lean manufacturing principles by fostering an iterative design environment, shortening development cycles and ensuring quality throughout the development process — not just at the end.

ASPICE principles are central to Aptiv’s proprietary PDP. They guide our teams in identifying how and when to do the right things at the right time. Our PDP evolves and improves with every project, and our years of experience with ASPICE have enabled us to apply lessons that streamline some of our most frequent system assessments, avoid unnecessary redundancy and reduce development costs.