Countdown to the demise of ASPICE?

01

ASPICE crazy

Recently, I communicated with my colleagues and found that the ASPICE projects launched last year have all stalled without exception. There's no reason, it's just that the OEM doesn't want to do it.

This reminds me of when I took the ASPICE certification for the first time almost four years ago ( Thinking about ASPICE at Work ). At that time, I was quite curious about this process. After all, it was my first contact with it. I only knew that it was an advanced version of the V process. Although I only covered a small part of it, the tedious process gave me a headache. This feeling can only be understood by those who have actually done it.

I remember that about three years ago, there seemed to be an ASPICE craze in China. Various ASPICE projects are flocking to it, and its certification agencies are making a lot of money. If any supplier does not have A SPICE qualifications, you will be embarrassed to say hello to others.

02

ASPICE and V model

ASPICE stands for Automotive Software process improvement and capability determination, automotive software process improvement and capability determination. It is a process standard for in-vehicle software development and is used by European OEMs to evaluate suppliers' software processes. Friends who don't know ASPICE can first read these two articles ( Introduction to Automotive SPICE ) and ( Things about Automotive SPICE and Automotive SPICE evaluation ). It can be seen that ASPICE evolved from the traditional automobile V model development process .

ASPICE overview

Why V model?

There is no so-called standard answer to this question. I try to express my own understanding. For automotive controller software development, the main reason is that there are fewer requirements

Since the controlled objects and working characteristics of traditional automobile controllers are very certain, their requirements are also very clear. For example, the ABS controller software is designed for anti-lock braking, and the TCU controller software controls transmission shifting. This means that before development, the OEM will have clear requirements for the software functions that the controller needs to implement, and at the same time provide clear requirements input documents, which is also the first step in V model development.

In addition, customer demand documents generally have continuity. Unless the demands are unreasonable , rash changes will cause inconsistent usage problems for end consumers .

Can ASPICE really improve software quality?

In theory, maybe. How much it can be improved, I don’t know. Because unless the OEM specifically requests it (pays money), suppliers will not actively use the ASPICE process for development.

ASPICE is just a process certificate for a certain project. Using this project can indirectly prove that the R&D department has the ability to meet the standards required by AS PICE . You can show it off every time you get a new project, but it doesn't mean you have to follow this process for development every time.

Personally, I have always been skeptical about the guiding significance of ASPICE. Because its positioning is the software development model that OEMs expect suppliers to adopt . Has anyone ever questioned whether this approach can really improve the supplier's software quality? Is it specifically tailored to the supplier? There is currently no data to support this view.

How much difference is there in the bug defect rate between the same engineer developing using the company's internal process and the A SPICE process? I wonder if anyone has done statistics? If not, I'd be skeptical of its effectiveness.

How do others play?

As a new force in electric vehicles, do you think they are also playing ASPICE? It seems not now. If you want to say that his software is not good, isn’t it running everywhere? New players do not have the historical baggage of traditional Autobots. By using the experience of the Internet and through continuous iteration and testing, they can still ensure software quality, or even higher !

80/20 Software Development Process

I personally have always been opposed to the statement that increasing the development process can improve software quality ! What really applies is the 80/20 rule, that is, only 20% of the key processes guarantee 80% of the software quality, and these key processes are what we need to focus on!

Then the remaining 20% ​​of quality is not important? No, but we must not focus our main energy on these 20%. Instead, it should be ensured through automated tools, automated testing and other methods, and this process does not require R&D engineers to do it themselves.

03

embrace change

Currently, automotive software is shifting from fixed function development to computing power-based supercomputers. In short, the controller will be a computing tool in the future, and the type of internal software determines its working characteristics.

The diversity of work scenarios means the diversity of needs. In the future, software development and changes will be more frequent, which is the main reason for the sudden rise of OTA in the automotive industry.

Let us use our imagination, make bold assumptions, and carefully verify: through OTA, the mobile Internet APP development and update model will be possible to implement in cars . For example, if there is a software function package, its functions may only be 80% completed. The OEM can first push it to some trial users for early adopter experience, and carry out continuous iterative updates through the continuous collection of background data. After the final verification is complete, it will be pushed to all car owners, and you will even need to pay before you can experience it!

Looking back now, it seems that ASPICE’s downfall and the rise of “software-defined cars” happened at the same time. When the fire breaks out, everyone rushes forward together. In the end... The reason why I think ASPICE will slowly decline is because it is cumbersome and resists change. In the future, change will become the mainstream trend. Maybe in the future ASPICE will integrate agile or other development models to gain new life, but at least not now.

04

No destruction, no establishment

The existence of everything depends on a foundation, just like every skyscraper relies on its solid foundation without exception. Cornerstones are like axioms in mathematics, which cannot be proven without use. This cornerstone ensures the building's construction, but ultimately limits its height.

For those of us in the industry, it is generally difficult to realize the existence of the cornerstone. As the saying goes, "It is not the true face of Mount Lu, it is just because we are in this mountain." Only when we truly step out of this industry can we truly discover the existence of the cornerstone. Obviously, the entry of Tesla and a new force in Internet car manufacturing has brought us new ideas. By following their thoughts and looking at their behaviors, we have the opportunity to glimpse our own foundation.

So what is the cornerstone of automotive controller software development? Maybe you also discovered it, that is the V model. From our development model, process documents, organizational structure, job establishment, etc., all are established in accordance with the guiding ideology of the V model.

Have you ever had many innovative ideas, but were unable to implement them due to the constraints of the V process? The V model has been with us for more than 20 years. Can it continue to carry our software building?

There is no doubt that only by breaking this cornerstone can we build a new building. The new forces of Internet car manufacturing have brought agile development to us traditional car people, but is this the final answer? All this is yet to be determined.

[1] Thinking about work——Agile development (1)

[2] Work Thoughts: The Impossible Triangle

[3] principle knowledge