Automotive software development: classification and differences between in-vehicle and non-in-vehicle software

Automotive software development is a very complex system engineering.

This complexity often makes us, who come from different knowledge backgrounds, talk at cross purposes when we exchange opinions.

One way to address complexity and align discussion benchmarks is to use crude visualization, such as a cartoon portrait, which only outlines the most critical features with a few strokes. It is not comprehensive, but typical enough.

This article hopes to outline the particularity and changes of the automotive software development model by extracting 7 typical characteristics.

1

Classification and differences between in-vehicle and non-in-vehicle software

Since automotive software is very complex and diverse, it is expected that there will be many types of software. Let’s solve this most basic problem first.

1.1 In-car software with a physical box

The most authentic automotive software is the software in the ECU, which is also the in-vehicle software. Intuitively, it is a physical box fixed to the car and connected to the electrical system or other ECUs through wiring harnesses.

ECUs have been in the automotive industry for nearly 60 years, but until now, they are still the main subject when talking about automotive software.

However, with the evolution of automotive electronic and electrical architecture, the functions of ECUs are becoming more and more centralized, which is now the popular domain control or central computing.

In any case, in form, ECU or DCU is an in-vehicle software product embedded in a physical box.

For automotive software, this feature is as prominent as Einstein's nose.

1.2 The connotation of in-vehicle software

In addition to the form, look at the functional connotation.

First of all, based on the Bosch five-domain division that has been widely circulated in the past two years, the electronic software functions on the vehicle can be divided into power domain (vehicle motion), chassis domain (safety), body domain (body electronics), cockpit domain (entertainment information) and autonomous driving domain (driving assistance).

These five domain divisions can give us a reference for a large framework, but they are not friendly enough for us to distinguish development models.

Furthermore, in-vehicle software can be divided into four categories:

Category 1: Modules that are highly coupled with the entire vehicle or have a higher safety level, such as engine control, motor control, brake control, electronic power steering control, body stability control system ESP, hybrid system control, airbag control, battery thermal management, etc.

The second category: body control modules with independent functions and lower safety levels, such as gateways, lighting control, wiper control, door and window control, keyless start, sunroof control, seat memory control, rearview mirror control, amplifier control, etc.

The third category: intelligent driving, ADAS, AD and associated radar or camera sensors, etc.

The fourth category: smart cockpit or car computer, which is mainly software carried by various large screens.

1.3 Non-vehicle software

In addition to in-vehicle software, there is also some non-in-vehicle software, which are also widely present in various fields of the automotive industry.

It includes cloud platform (such as data collection background, battery status remote monitoring, OTA operation platform), tool chain software, end-of-line electrical inspection software (EOL, End Of Line) for production, as well as mobile car-connected apps and third-party apps on the car computer.

Among them, cloud platforms are closer to apps and Internet software, while in-vehicle software and Internet software are completely different categories. The inconsistency in the subject of discussion is often one of the reasons why people from two industry backgrounds talk at cross purposes.

Of course, these non-in-vehicle software have not yet formed a stable and scalable ecosystem, so the latter part of this article is still mainly based on in-vehicle software.

However, V2X is always a trend and deserves our continued attention.

The above classification of software categories will directly affect the distribution and emphasis of the following 6 features, so you can pay attention to them when reading.

2

5 layers of integration from code to vehicle

Automotive software is of many types and modules, and needs to be installed on the entire vehicle to demonstrate its functions across modules and domains.

Therefore, as long as the centralization of electronic and electrical architecture does not move towards central computing and cloud computing, and as long as the software and hardware autonomy of all parties in the supply chain is not unified, multi-layer integration is inevitable.

According to the current stage of architecture development, we can divide the integration of automotive software into five levels:

Integrate software units together

Integrate software into hardware

Integrate hardware into the mechanical housing

Integrate ECUs into subsystems

Integrate subsystems into the vehicle

For details on this part, please see "Five Levels of Automotive Software Integration".

3

Joint debugging and vehicle-level evaluation

Automotive software development is a collaborative process among various modules or functional domains.

For a long time, people have been accustomed to completing development and verification on their own computers and test benches, and then confirming them at the integration point.

The collaborative practice of "everyone takes care of their own business" can make the division of labor clear and delay the exposure of almost inevitable problems.

Therefore, some modules (the first category) that are closely dependent on the vehicle environment will be debugged in advance.

A typical example is the airbag controller.

The whole vehicle collision test will cost a lot. Once the test fails, it will be a huge waste of time and money. The early joint debugging is very necessary.

For example, the joint debugging and confirmation of installation direction, sensor position, wiring harness connection, resistance range, DTC status, software version and response to the handpiece.

Of course, airbags are too mature, too traditional, and the degree of soft-hard coupling is too deep.

For modules that are not so tightly coupled with other modules or the entire vehicle (the second category), the necessity of joint debugging is reduced. For example, for a simple sunroof control module and steering wheel heating module, it may be more than enough to connect a motor and a heating pad on the test bench.

Intelligent driving and cockpit are gradually moving away from the traditional automotive software development model, and there are some differences between the two.

The development and verification of intelligent driving can rely on some simulation, but ultimately it requires debugging and calibration of the entire vehicle, especially the improvement of the functions of the motion control part.

The smart cabin integrates a large amount of human-computer interaction content. Whether it is the issuance of control commands or the projection of feedback information, the large screen is becoming the I/O port between people and cars. This makes the development of the cockpit quite difficult, and the significance and necessity of the so-called joint debugging or collaborative verification are also very significant.

In short, we have seen such a trend that joint debugging is gradually evolving into an overall evaluation of the vehicle along with the integration of architecture.

4

Development and verification are subject to the actual vehicle environment

Simulation is also a very old thing, but its development always seems to be a bit slow. Development and verification at all levels of automobile development are difficult to leave the real physical environment, that is, the car.

Cars are expensive, especially engineering cars. As a second choice, people use simulated signals and loads, simple test benches with ECUs, white bodies, and assembled real cars...

The next best thing will naturally lead to various problems such as misaligned software versions, insufficient verification load, and delayed problem exposure.

Being constrained by the environment of samples and real vehicles is a characteristic of automobile development. In particular, in the transition stage of architecture integration, more coupled functions and more interactions will make the current single simulation environment highlight greater problems.

5

Consider production

All software needs to be integrated into the vehicle to solve customer needs at the vehicle level. The first and main step is through production assembly, especially for the first type of software.

Therefore, when we develop automotive software, we must focus on manufacturing and production.

There are two reasons:

OTA technology, processes and supervision are not mature enough, so we cannot carry out OTA freely.

The existing standardized production methods are still safe and reliable enough.

6

ASPICE

ASPICE was once worshipped as a god, but in the last one or two years, probably because the entire industry is in a shabby state, the exquisite and expensive ASPICE has gradually been greeted with a smile.

After repeated thinking and research, I believe that ASPICE will return to a certain extent, and will gradually reflect its necessary normative significance as the industry ecology recovers and product solutions mature.

However, there is another point to note. The significance of ASPICE's layering may weaken with the further development of architectural centralization. For example, after the decoupling of software and hardware, the system (software + hardware +...) that has always been the focus of software development is not necessary.