The most well-known software development standard in the automotive industry is the V-model. Representing the V-model are ASPICE, ISO 26262, and ISO/SAE 21434. Today we'll primarily use ASPICE as a basis to explore the characteristics of the V-model in the current era of automotive software transformation.

The traditional V-model standard is somewhat ineffective at this stage.

What does this mean? First, let's clarify a characteristic of ASPICE: it's written as a "proposition outline." It's been in use for over a decade, and we've never heard of any major errors with it—because it's written broadly enough.

Let's take examples. In ASPICE's supplier monitoring section, there are 5 base practices (BPs):

The first BP: establish and maintain joint development measures or interfaces with suppliers so information can be exchanged (what the joint process or interface should look like isn't described in ASPICE).

The second BP: exchange all mutually agreed information.

The third BP: review technical development processes with suppliers.

The fourth BP: review supplier progress.

The fifth BP: take action on deviations.

You can see these BPs are very broad behavioral descriptions. How exactly should these behaviors be implemented? The standard doesn't say.

So ASPICE's standard has very wide latitude for interpretation. That's why it hasn't had major errors over a decade—it describes generic product development and project management processes. But in the current stage of automotive software transformation, we need the standard to tell us how, not just give us a proposition.

In the era of transformation from traditional cars to smart connected vehicles, everyone is exploring this new model—both software suppliers and OEMs. If ASPICE were a magic bullet, German OEM VW wouldn't have had its new cars sitting in parking lots for months.

So my conclusion is: traditional V-model development standards are ineffective at this stage. Proposition-only standards don't work here; we need actual solution methods.

At this stage, more and more OEMs and new EV makers are adopting another development model: Agile.

Agile hasn't formed a standard yet—it's just a set of philosophies, tools, and practices. Agile is more like an excellent "test-taker" who wrote a study guide with many methods. The test-taker starts by saying: don't try to get everything right and complete in one go (things are too complex)—just start doing it, build a prototype, and through rapid validation you'll quickly find problems, then fix them, ensuring every iteration is better than the last, and every iteration is what you want most at that stage. Then he tells you how many weapons are in your arsenal: Agile kanban, requirement prioritization, Agile reports, sprint reviews, daily standups, and so on. This starting point of the "test-taker" causes much controversy. Because we know: the same exam, the same applied problem, different people can solve it using different methods, and everyone gets it right. It's like: there are study techniques from Huanggang teachers and from Renmin University High School, but there's only one exam syllabus.

The people who promoted Agile originally didn't have big ambitions. They just wanted to tell programmers and project managers how to manage projects and how to collaborate across roles. It doesn't impose requirements on industries, and it wasn't designed for the automotive industry. So when such a method is applied to the automotive industry, it inevitably creates much debate.

I wrote an article earlier, and you can see from the comments that Agile in the automotive industry is full of debate. Some people are cynical about Agile. But in reality, including Tesla and domestic new EV makers, they basically all use a "small steps, fast iteration" approach to software development. Tesla's FSD feature evolves and upgrades at visible speed on already delivered vehicles. While many leading automotive companies are already more or less trying Agile ideas, some people still stay in their own views.

Of course, we have to admit a fact: Agile hasn't been widely recognized in the automotive industry yet. I think that's normal—the automotive industry is undergoing transformation, and during transformation there's naturally a hundred schools of thought. No unified post-transformation standard has formed yet, so more debate at this time is beneficial for industry progress.

The topic of this article is predicting what direction automotive software development standards will evolve toward.

My first prediction: the V-model will absorb Agile characteristics and form a new standard.

Although Agile hasn't formed an automotive industry standard, many teams practice it this way. Many companies consult us about automotive industry Agile toolchains, and we find they've more or less started using Agile project management tools. The industry should feel this trend even more clearly.

In the new automotive industry software standard, I predict it will definitely embrace and recognize the "small steps, continuous iteration" philosophy. The V-model shouldn't simply be seen as waterfall. The V-model's writing doesn't mention waterfall, but from its context, it's easy to understand as waterfall. For example, when we do software architecture design, it assumes software requirements analysis has already been extensively discussed and approved—but it doesn't mention: what if requirements are incomplete? If requirements aren't sorted out and fully discussed, can we still do architecture design? Can they be parallel? Requirements gradually mature, architecture gradually matures, and during maturation, traceability is gradually established—is that feasible?

Changes are inevitable during development, but in ASPICE, change management is a supporting process, as if changes don't happen in every process but are occasional deviations after the project reaches a certain stage. But in reality, change management should be elevated to a more important, more frequent position—because during automotive transformation, the uncertainty of technologies and products is very high, and we'll face more frequent changes.

In the early product stage, we might not consider everything. We have a product roadmap. But for each feature point in the roadmap, we might not write all requirement details in the very beginning—instead, they're refined during development. Through continuous delivery of working products, requirements are constantly adjusted.

Second, I predict the new standard will further detail BPs and recommend some Agile development methods.

As we saw earlier, BPs in ASPICE are generally written coarsely. There aren't many recommendations on how to do things. I estimate the new standard will more frequently recommend Agile development methods. If a problem-solving method is good, we need to reflect it in the standard. While it's not mandatory, it at least provides reference. That's how standards gradually fuse with Agile.

Third, how to collaborate with third parties will be an important part of the standard.

In the original ASPICE standard, there's very little about collaborating with third parties—there's a section called supplier management.

But in the new standard, how to collaborate with third parties should have extensive coverage. In current automotive software development, we find joint development has become the norm, leading to collaboration models like Tier 0.5.

In traditional standards, we generally only emphasize: need to communicate with suppliers, need channels for information exchange, need alignment with suppliers, and so on. But in new development processes, we need to realize: we not only jointly develop with suppliers, but also need joint development with OEM customers. And the joint development process is more frequent and tighter than before—it's no longer a turnkey project. For a software or system development, different software components may be executed by different stakeholders. This requires real-time communication channels in requirement management and issue management: each can raise requirements and bugs to the other, and everyone seems to be working on one management system. This is very necessary for improving software development efficiency.

Fourth, CICD will become one of the BPs. Lacking CICD infrastructure means the product lacks continuous iteration capability.

In the original ASPICE standard, continuous integration, delivery, and deployment weren't specifically emphasized. It only described that software verification processes need software unit testing, software integration testing, software functional testing, and so on. It emphasized traceability and complete coverage of requirements, architecture, and detailed design. It didn't require how verification processes should be done. Predictably, future OEM requirements will be more numerous and more frequent, and CICD infrastructure will be key to responding to this change. We have a client making gas sensors; their German customer explicitly requires that the R&D process must be on a system, with a unified code repository and continuous integration capability. The German customer is considering that future market or regulatory requirements for in-car air quality may require updated products in shorter timeframes.