In-depth analysis of the five-domain model of automotive electronic vehicle control functions

Introduction: In recent years, the domain control of automotive electronic control has evolved from a few forward-looking projects to a direction that all OEMs are working hard to implement. Why can we now bring up the concept of domain control and even central computing platform? What kind of functions can be domain controlled? What are the possible paths to take in the future? This article will combine my many years of development experience in the automotive industry to try to deeply sort out the evolution of electronic and electrical domain control.

1. Why can domain control be used?

Regardless of the type, automotive electronic control can essentially be expressed as a simple control system model: "sensing input => processing calculation => driving actuator output".

In the MCU embedded environment of previous automotive electronics, input, processing calculation and output were integrated. The same ECU board performed both signal acquisition and logical operations, and finally drove execution, thus forming a closed loop.

In most cases, the ECU and the driven parts are physically enclosed in the same housing. The parts status at the time of delivery includes both electromechanical structural parts such as gear structures, as well as chips and PCBs that carry software algorithms. The hardware and software are of the same type and inseparable.

After installing it on the vehicle, the vehicle manufacturer is responsible for the integration of the entire system interface and the opening of functions. The interface coordination relationship between each other has been relatively solidified during the development process (such as the CAN signal matrix). In this state, each ECU takes the management of its own parts as its main task, and whether they can flexibly cooperate with each other at the vehicle level to play tricks in terms of functions is secondary. In other words, even if there is such a desire, it is very difficult to change in practice. The electronic and electrical framework of the whole vehicle is basically in a welded state in the middle of the project development, and any change may require a lot of manpower.

The above is the traditional status. As a complex large industrial product, the first thing a car needs is precise coordination and long-term stable operation. In terms of concept, flexible change is not given top consideration, including the electronic control part.

The concept of domain control, or further the concept of central computing platform, is essentially doing one thing, which is to separate the three processes mentioned above and separate and centralize the logical processing and computing parts.

To be able to separate and centralize logic, the following prerequisites are required:

1. The core processing chip is upgraded from MCU/MPU/SoC, and the computing power is greatly improved;

2. Automotive Ethernet applications support high-speed, real-time, and large-volume information transmission capabilities;

3. The ability to transmit large amounts of data further supports the service-oriented middleware software architecture.

Processor power increases

Taking the power domain as an example, the logic complexity of the control system in the power domain is relatively high in traditional automotive electronics, and currently all of them are 32-bit floating-point processors. In addition, there are many 8-bit and 16-bit microcontroller chips in other applications on the car.

About seven or eight years ago, the commonly used MCU models for power systems, such as Infineon's TC178x and NXP's MPC574x, were all below 200MHz, with performance at about 1.x~2.xDMIPS/MHz, so the computing power can be estimated to be ~400DMIPS. A large number of power domain and chassis domain controllers can already be implemented based on this level of computing power, such as EMS, VCU, BMS, EPS, ESP, etc., all of which have examples of applying the above MCU models.

Take Infineon as an example. Later, it was gradually upgraded to TC2xx. According to 1.7~2.4DMIPS/MHz, 200MHz, and three-core computing, the computing power reached the order of ~1200DMIPS, which is several times higher than the previous state.

In recent years, it has been upgraded to TC3xx. For example, TC39x has reached the 4kDMIPS level, which has increased several times.

Infineon's latest MPU TC4Dx has reached the 8kDMIPS level.

In addition, the MPU S32G, which is widely used in the industry, has a processor part of 4xA53+3xM7, which is calculated at 2.3DMIPS/MHz @ 1GHz and 2.14DMIPS/MHz @ 400MHz respectively, and its total processing power reaches 11k+DMIPS.

The TDA4VM is currently widely used in the industry. Its processors include 2xA72 and 6xR5F, which are calculated at 7.3DMIPS/MHz @ 2GHz and 2.45DMIPS/MHz @ 1GHz respectively. Its total processing power reaches 40k+DMIPS.

Going further to SoC, taking Qualcomm as an example, the computing power of its subsequent SA85xx series went straight to 100~200kDMIPS.

From MCU to SoC, the CPU computing power has increased by 200 times.

Of course, the content processed by MPU and SoC is not just the pure logic system in the embedded system, but also includes running complex operating systems such as Linux, and cooperating with other co-processing systems such as DSP, GPU, NPU, etc. to complete the processing of complex image perception and data-intensive algorithms. It is a bit unfair to MCU to simply compare computing power. But in general, I just want to express a point of view, that is, with the enhancement of processor capabilities, multiple control units in the past have the opportunity to be put into the same chip in terms of computing power; from another perspective, using a new generation of MCU to handle traditional automotive electronic control system scenarios may still waste a lot of computing resources even if the factors of increased complexity of the control strategy itself are excluded.

Applications of Automotive Ethernet

In-vehicle Ethernet is another important factor in achieving domain control separation. In in-vehicle applications, the ability to exchange data in real time is a basic requirement for almost all control functions. When it comes to real-time performance, the AVB/TSN protocol family comes to mind first. But let's not talk about AVB/TSN here, let's do a basic calculation first.

Taking a 500kbps CAN network as an example, it takes about 216us (theoretical value, the actual value will be slightly higher by 250~300us) to transmit a frame of 8 bytes of message, and the theoretical transmission efficiency is 27us/Byte. Similarly, according to the 100Mbps bandwidth of 100M Ethernet, a frame of message ~1500Bytes takes about 120us to transmit (theoretical value, the actual value depends on the network status and inter-frame delay, etc.), and the theoretical transmission efficiency is 0.08us/Byte. Compared with the two, the difference is 200 times.

It is this 200-fold margin that further provides sufficient room for protocol families such as AVB/TSN to develop.

Service-oriented communication middleware design

It is the magnitude improvement of physical communication methods from CAN to Ethernet that makes the transmission of information more flexible. Service-oriented is just an engineering way of thinking, and strictly speaking, it is not a new species in the car. The traditional diagnostic service protocol UDS is a service-oriented thinking, but even if multiple frames are used, the amount of data transmitted in real time is limited to dozens of bytes (not considering large packets and multiple frames of flashing). However, the magnitude improvement of communication efficiency brought by Ethernet has brought new possibilities to communication middleware.

Flexibility and efficiency are a pair of mutually balancing attributes. A service-oriented architecture has the ability to be flexible and pluggable, but it also generates additional protocol overhead, such as service discovery, handshakes, and the additional transmission of QoS information, which essentially reduces the coding efficiency of information entropy.

After becoming service-oriented, the same signal may be packaged in different service messages and sent multiple times, or the same message may be consumed multiple times by different consumers, which is redundant compared to transmission based on CAN signals. Fortunately, the improvement of physical communication efficiency provides enough space for information redundancy. When further upgraded to Gigabit Ethernet, the bandwidth required for the effective load information in the traditional automotive communication network is almost negligible, and redundancy and protocol overhead occupy the majority.

Because information service provides flexible service configuration, as well as capabilities such as node hot-swap and dynamic function configuration, it makes it possible to coordinate and combine functions between different control nodes in the vehicle, thereby developing a variety of vehicle functions that are easy to adjust and upgrade over time.

2. What kind of functions can be domain controlled?

Five-domain model of vehicle control functions

By dividing the domains according to the functions of the vehicle, it is possible to concentrate the functions within the domains together. For example, the chassis domain, power domain, body domain, and the cockpit domain and intelligent driving domain that have gradually taken shape with the intelligentization of automobiles in recent years. The above five-domain model is a relatively common domain control architecture concept at present.

Then, in the process of moving towards domain control and further towards the central computing platform, can all functions be moved up to high-performance chips? The answer seems to be not necessarily. In other words, which functions can be moved in and which cannot need to be considered.