Analysis of the evolution trend of intelligent driving domain controller hardware solutions

1. Evolution trend of intelligent driving domain control hardware solutions

2. The current mainstream intelligent driving domain control hardware solution is N*SoC+MCU, so can the MCU be removed?

3. As chip integration continues to increase, under ideal circumstances, will the smart driving domain control hardware solution eventually evolve into a single SoC chip solution?

Preface:

1. Early stage: Audi's zFAS (developed in April 2015) is the earliest architecture of the intelligent driving domain controller, using a 3-chip SoC+MCU solution, which almost combined the best chips in various application fields at that time. The zFAS module includes: SoC-1 (Mobileye-EyeQ3) + SoC-2 (NVIDIA-Tegra K1 VCM) + SoC-3 (Altera-Cyclone V) + MCU (Infineon-Aurix-TC297T)

Mobileye - EyeQ3: responsible for front camera image processing; 

NVIDIA - Tegra K1 VCM: Responsible for surround-view camera image processing and driver status monitoring;

Altera - Cyclone V: Responsible for ultrasonic signal processing; multi-source sensor data fusion such as cameras, millimeter-wave radars and lidars; as an internal gateway to achieve internal communications;

Infineon - Aurix TC297T: Used to monitor the system's operating status and communicate externally.

Limited by the computing power level of the computing platform that the entire industry can provide (EyeQ3's AI computing power is 0.256TOPS, Tegra K1 VCM's single floating-point computing performance is 350GFLOPS, and Cyclone V's CPU computing power is 5250DMIPS), the overall performance level of zFAS is greatly restricted.

Qualitative comparison of chip performance in two different time periods (Information source: compiled from public data)

 Schematic diagram of zFAS circuit board (Image source - Hardcore Automotive Electronics)

Note: The domain controller is provided by Mobieye with EyeQ3 chip and corresponding software solutions, TTTech provides middleware, Audi develops some upper-level application algorithms, and Aptiv performs system integration.

2.现状：随着芯片厂商开放度提升，SoC芯片集成的异构资源不断丰富，以及CPU算力和AI算力的大幅提高，行车和泊车传感器的数据处理、数据融合等软件算法开始逐渐地集成到一个功能更强大的异构SoC里面去完成。因此，智驾域控硬件方案中选用SoC芯片的种类在减少，但仍然需要ASIL D级别的MCU作为辅助支持，比如德赛西威的IPU03：英伟达-Xavier + 英飞凌Safety MCU；华为的MDC610：昇腾610芯片+英飞凌Safety MCU。虽然有一些域控方案里依然会使用2~4颗SoC，但大都是选择同一种型号的SoC，比如特斯拉的 Autopilot HW3.0平台采用2颗FSD芯片；蔚来的NIO Adam域控平台采用4颗Orin X芯片。

Information source: Public data compilation

3. Future: As the integration of SoC chips continues to increase, more and more SoC chips will integrate ASIL D-level MCU cores - functional safety islands. Then, the role of the external MCU tends to be replaced by the functional safety island inside the SoC, and more and more single SoC chip domain control solutions will gradually appear on the market. For example, Zhixing Technology's IDC MID version uses a single TDA4VM chip to achieve a travel-parking solution, which is expected to be mass-produced in the second half of this year.

Remark:

External MCU: Most SOCs used for intelligent driving domain control cannot meet the requirements of high functional safety levels. Therefore, an independent MCU chip that reaches the ASIL D level is needed on the main board circuit of the intelligent driving domain control, such as Infineon TC297/397, to meet application scenarios with high functional safety requirements such as safety monitoring and safe parking.

Built-in MCU core/functional safety island: By building a built-in MCU core inside the SoC and using the lock-step method to improve the functional safety level of the SoC chip itself, the peripheral interfaces will also be richer. Generally, a separate CAN interface will be provided as a data communication interface with the vehicle chassis and millimeter-wave radar to achieve safe parking of the vehicle under emergency conditions.

1. Thoughts on SOC+ MCU hardware solution

At present, the hardware solutions for intelligent driving domain control at L2+ and above are mainly in the form of: N*SoC+MCU. Among them, SoC is generally responsible for perception, global path planning, etc., while MCU is responsible for the whole vehicle control tasks with high real-time requirements. Why is there an independent MCU chip on the domain controller circuit board? What is its function? Can it be removed?

Mainstream intelligent driving domain control hardware solutions currently in mass production (Information source: compiled from public data)

1.1 What is the function of the external MCU?

In the entire intelligent driving solution, the external MCU must meet the functional safety ASIL D requirements, have multiple CAN bus interfaces and high-speed Ethernet interfaces, be able to connect to the body sensors, and receive and send body CAN bus and Ethernet information, so as to enable the domain control platform to interact with other nodes in the vehicle. The main functions supported by the MCU are as follows:

1) Vehicle chassis control function: As the last checkpoint, it verifies the vehicle's execution commands and connects to the chassis control function;

2) Status monitoring: monitoring of power supply module status, communication status, and interactive node status, etc.;

3) Execute the minimum safety risk strategy: When a fault is detected in the autonomous driving system, the external MCU will promptly enter the minimum safety risk condition and take on the role of functional degradation, driver takeover reminder, and safe parking.

1.2 Is it possible to remove the external MCU?

If the MCU is to be removed, who will take over the work that the MCU originally did? It can only be the SOC. So, does the SOC have the ability to do all the work of the MCU? In theory, it can, because many SOCs now begin to integrate the MCU core-functional safety island, and the performance is getting closer and closer to the external MCU. For example, the functional safety island inside the TDA4VM can already reach the ASIL D level, and in some cases it can completely replace the external MCU.

But why is the mainstream solution still using SOC + external MCU? After consulting with relevant experts in the industry, the following is a brief analysis and summary from the perspective of technology and commercialization:

1) The technology is not very mature

Although more and more chip manufacturers are beginning to consider building MCU cores inside SoC chips, compared with MCUs with traditional mature processes, built-in MCU cores still have some gaps in functional safety, real-time and reliability. After all, any new technology and new products require a certain amount of time to verify.

Insufficient security and limited memory

Yu Chenjie, Infineon's Greater China Intelligent Driving Market Manager, once mentioned in a public speech: Today's AI SoCs have rich computing power, including Cortex-A cores, NPUs, GPUs, etc. Some SoCs even integrate an MCU-level real-time lockstep core, called a safety island. It seems to instill a concept that adding a pair of lockstep cores to the SoC means functional safety ASIL-D. In fact, a pair of lockstep real-time cores and ECU systems, or even just the chip itself reaching ASIL-D level, are not the same concept. In addition, due to die size, cost and other reasons, some safety islands currently only integrate very limited RAM. Take a Lockstep R5F with 1M SRAM as an example. If you want all programs to run in RAM, the size of the program will be significantly restricted.

A similar view is expressed in the article "A 20,000-word article explaining the evolution of autonomous driving functional architecture": "In the future, the price of a single SoC will be cheaper than SoC+MCU. Even a single SoC can meet the requirements of functional safety ASIL D (currently, high-computing SoCs in the industry can only achieve ASIL B), and can also meet network security requirements. However, for fully autonomous driving safety, it is far from enough to achieve 'relative safety'. It is necessary to achieve 'intrinsic safety'. Therefore, the author believes that an external MCU is still very necessary."

Software migration is risky

The single SoC chip solution has not yet been fully verified by the market, and there are some risks in the innovative design of using a built-in MCU core to replace the external MCU.

Peng Nengling, former vice president of Yutong Bus Intelligent Network, believes that the reason why the mainstream solution is still SoC + MCU is that I think everyone is still cautious. After all, the hardware resources and hardware performance of MCUs from different manufacturers are not exactly the same. If the functions of the external MCU are transplanted to the built-in functional safety island, there will be some risks in the software transplantation process, such as software vulnerabilities and software defects. It is safer to continue to use the current SoC + MCU solution. After all, the current software is more complex than before, and the country's requirements for product safety and compliance are getting higher and higher. Therefore, no car company is willing to take the risk of removing the external MCU rashly.

2) It is not very commercially viable

Low return on investment at this stage

OEMs or Tier 1s are used to implementing functions such as vehicle control on external MCUs and running the traditional AUTOSAR CP operating system on them. Now, if Tier 1s intend to migrate the functions of external MCUs to internal devices, they will not only need to invest manpower and time, but also need to meet some objective conditions: the first is that the reliability and functional safety level of the MCU core built into the SoC chip meet the specified requirements; the second is that the entire software platform must also have a corresponding solution. In the long run, this is a trend, but the transition will definitely take time and require investment in R&D costs.

Liu Daofu, vice president of Cambrian Xingge products, mentioned that for the current vehicle platform, OEMs are generally reluctant to try and replace new architecture solutions considering the urgency of the R&D cycle. OEMs are already accustomed to using old architecture solutions, such as TC297/397 for vehicle control, and these solutions are already very mature. For the next generation of new platforms, OEMs have more time to do research and development, and will consider this from the perspective of higher integration and lower mass production costs, and may be willing to invest certain resources to do it. In Xingge's future products, it will consider integrating MCU functions into SoCs to improve the integration of domain controllers and reduce the overall BOM cost of domain controllers.