The Background and Purpose Behind ASPICE

"Software-defined vehicles" has gradually become an industry consensus. Everyone recognizes that software is growing in importance relative to hardware in the automotive industry. Traditional OEMs are transforming, new EV makers are flooding in, and more automotive software suppliers are appearing.

Whether you have prior car-making experience or not, once you start building cars, the first question is: what is automotive software development actually like? For example, if Xiaomi makes cars, can it directly use the same process and steps it used for phone software?

Looking for the answer, we find two important software development standards in the automotive industry: ASPICE and functional safety ISO 26262. Both are based on the V-model development approach.

So what was the background behind ASPICE? In 2005—note this is 17 years ago—several dozen German OEMs and major suppliers created an evaluation framework for automotive software processes, later published under the VDA (German Association of the Automotive Industry).

Why did they create this framework? Because their software suppliers couldn't deliver software as white-box to them. So they came up with a solution: although I can't see your code, I require that your entire software or system R&D process follows a specific workflow—the famous V-model in the automotive industry. Its main body covers systems engineering and software engineering. Specifically, developing a system includes: system requirements analysis, system architecture design, software requirements analysis, software architecture design, software detailed design—that's the left side of the V—plus the corresponding right side of verification and testing.

The logic of these OEMs and suppliers was: although I can't see your detailed code, if your entire development process is based on the workflow I defined, then I'll consider your quality basically up to standard. But this is just a door-opener for entering the supply chain of OEMs and major suppliers. It only means you followed a process; it doesn't say anything about your product quality. Whether you ultimately enter the supply chain depends much more on product quality, price, delivery speed, and after-sales.

So if we understand this logic deeply, it's clear: it's a requirement by powerful buyers (OEMs) on suppliers. The requirements and details of this framework are very complex.

Specifically, ASPICE has particularly high requirements in two areas: traceability and document compliance. Traceability simply means: from any detail—say, a bug—you can trace back to its test case, test plan, software requirement, software architecture, system architecture, system requirement, and so on.

The other is document compliance. For example, when doing testing, you first need a test plan: what's the test strategy? What are the test objectives? What are we testing this time? Who's involved? How are test results recorded? How are bugs tracked, resolved, root-caused, and impact-analyzed?

How exactly do you implement traceability and compliance? The evaluation framework doesn't say. The OEM doesn't really care—even if they wanted to, their suppliers couldn't fully comply. So how do they verify that suppliers actually meet this evaluation framework? That's where ASPICE audits come in—conducted by assessors familiar with the ASPICE standard, who evaluate a company's processes. Pass it, and you get a certificate.

Some assessors are very experienced—they not only know how to evaluate, but also know which tools and methods help you pass quickly. Others only know what the standard requires, but can't help with "how to do it efficiently."

This creates a problem: the standard is the same, but implementation varies. Some companies implement traceability very efficiently; others are very inefficient. For example, some companies manage all their documents entirely in Word. A requirements document might be 20 pages, a software architecture document 50 pages. You look at requirement #1 and see it references architecture 3.2, so you flip to architecture 3.2 in the Word document. Then you ask, does this architecture have test cases? You see test case 5.3, so you flip to the test case Word document and find 5.3.

Did this company establish traceability? Yes, it did. But our example is very simple—only three steps. We can actually trace by flipping through documents.

But imagine: in a company, requirements, software architecture, and test cases are done by different engineers. They might store documents in different places and update them in real-time. If we just linked software requirements to software architecture, and then the architecture Word doc updates something—can it notify the requirements side about this update? And does the architect even know who to notify?

If our system has 30 requirements documents, 50 architecture documents, and 100 test case documents, the complexity of finding things grows exponentially. So yes, traceability exists—but its practical usability is poor. This is why many teams complain bitterly during ASPICE audits and immediately abandon this "traceability" and "compliance" process once the audit is over.

To summarize: ASPICE was born as a requirement by powerful OEMs and suppliers on their downstream suppliers. The reason for its creation is that buyers can't get white-box delivery from suppliers, so at minimum they require the process to follow the standard they define. Suppliers use this as a door-opener to enter the supply chain. But passing the standard doesn't mean you can build good products—there's no fundamental connection between the two.

Which Companies Is ASPICE Suitable (and Not Suitable) For?

Given this background, let's think about which companies ASPICE—or V-model development—is and isn't suitable for.

First, who it's suitable for.

If a company is a traditional OEM that has never done software development before, learning the ASPICE development model is appropriate. It can use a standard process to quickly understand how automotive software development works: its systems, its requirements, what steps need to be completed. It helps the team quickly establish processes and find the right people—systems engineers, software architects, software test engineers, and so on.

It's also useful for companies transitioning from other industries—like Xiaomi making cars. They can quickly familiarize themselves with the automotive industry.

Who isn't it suitable for?

If an automotive software company already builds excellent software, with its own system guaranteeing quality, and doesn't need to supply to external customers—say it's itself an OEM, and doesn't need to explain its software development process in detail to suppliers. For example, when writing a test plan, what's the detailed test strategy? How is the test plan scheduled? Under what conditions do regression tests happen? These things are already implicitly understood within the team. Take NIO: its smart cockpit is basically fully self-developed. The whole team knows the test strategy—after six months or a year of establishing it, everyone knows how it works. At that point, you don't need to spend effort writing detailed test strategies, test processes, and regression strategies in every test plan.

Companies like this aren't suitable for retrofitting ASPICE—it would actually slow down their software development. But that doesn't mean ASPICE is completely useless for companies like NIO; it can still serve as a reference. Because once teams go Agile, many documents disappear. For example: there are 100 software requirements and 1,000 corresponding test cases. No traceability is established between them, but everyone knows those 1,000 test cases test those 100 requirements. That's fine. But you can't test all 1,000 test cases every time. Depending on the development phase, sometimes only 500 are selected. Then if someone asks: what's the test case coverage for these ten requirements in this test plan? Without traceability, that question is very hard to answer.

So teams like NIO also need to learn from ASPICE's experience and methods to balance Agile efficiency with compliance and efficiency. Also, NIO is a new EV maker—it hires people from traditional software backgrounds, phone industries, and internet industries. How do you get them to speak a common language and follow a common process? In the early stages, borrowing from ASPICE's ideas and methods is necessary.

To summarize:

If your team has never done automotive software development before, the ASPICE process is useful for quickly building an R&D system;

If your team is a mixed team hiring from various industries, ASPICE is useful for quickly establishing consistent development habits and processes;

But if your team has no external software delivery needs, internal processes are very clear, traceability is established, and software quality is high—then ASPICE's importance drops significantly. At that point, what you need is upgrading your toolchain and management methods to make R&D more efficient.

For example: from my home to the automotive company, I already know three fast walking routes. What I need to do next is no longer find a new walking route—the shortest path is already found and I'm familiar with it. What I need is to consider whether some form of transportation can further shorten the commute.

Fusing ASPICE with Agile Development

Now let's talk about ASPICE and Agile integration. We've talked a lot about ASPICE: it's a software process evaluation framework, a buyer's requirement on suppliers. What is Agile? Agile is a set of software development philosophies, values, and tooling. Its starting point is completely different from ASPICE.

ASPICE starts from the buyer's requirement; Agile starts from the supplier's perspective—discussing how to quickly implement software development. So Agile actually tells people how to actually implement this process.

ASPICE is a requirement: what the buyer tells the supplier to do. Agile says: how the supplier can do it quickly. This is actually the current automotive industry transformation dilemma: everyone knows they need to transform, but no one knows how, no one knows how to fuse, and no standard has emerged yet.

Agile talks about many ideas, like "working software over comprehensive documentation." It also provides many theoretical tools: Scrum, Kanban, burndown charts, Agile retrospectives, and so on. Many software companies design their tools based on this approach—like Australia's Atlassian.

Having discussed both ASPICE and Agile, we know ASPICE is a standard for automotive industry software development processes. Although it was born in 2005, 17 years ago, revolutionary changes in (Chinese) automotive software development happened around 2014. Until a new software development standard emerges, it still has its place.

I believe a new software development standard will emerge in the next few years, because the automotive industry is changing extremely rapidly—it's revolutionary, and the whole industry has become dynamic. This is a good time for new development processes to emerge. The new standard is likely to be born in China, because China produces over 40% of the world's EVs and smart cars. We have the advantage.

I've worked at both new EV makers and traditional OEM software centers in software quality and toolchain roles. After deeply engaging with and applying ASPICE, I think ASPICE isn't a silver bullet. Don't assume it solves all problems—it's just a teacher's requirement on students, or a buyer's requirement on suppliers. If you dig deep into the requirement and come up with your own approach, you can do it, but your efficiency will be very slow because automotive software R&D is complex.

Based on the problems mentioned above, last year I and a few colleagues started our own company. Our product design philosophy is: based on ASPICE's development ideas, design tools that implement efficient traceability and compliance. If meeting the standard itself isn't tedious, engineers will be more willing to comply—while also achieving agility.

For example, ASPICE has very strong traceability requirements. We use mind maps to build traceability because mind maps naturally have contextual traceability. Different mind maps can also establish traceability through cross-referencing views.

Another example: in ASPICE, we often talk about review. Whether it's software requirements or software architecture, after one person finishes it, it needs to be reviewed with other team members. In Agile, this review might happen on the spot—relatively open-ended discussion without good records. We've integrated this review into our tool: based on a mind map, I can send review requests to multiple people or a designated review committee. They see the mind map and review it directly—approve or reject, with comments if rejected. We automatically aggregate everyone's review results to determine the final outcome. The entire process is recorded in the system.

To summarize: ASPICE isn't a silver bullet. Passing ASPICE doesn't mean you can build good products. If meeting the standard isn't tedious, engineers will be happy to do it. The direction of toolchain building is: meet standards efficiently, while staying fast and agile.