Source: GF Securities

With the development of intelligent connected vehicles, the number of onboard sensors is increasing, and the improving performance leads to a higher demand for computing power in onboard computing platforms. Compared to lower-level autonomous driving, advanced autonomous driving systems significantly increase the amount of data obtained from sensors, and the effective operation of autonomous driving systems requires the onboard computing platform to accurately and efficiently process this data. The chip computing power demand in the onboard computing platform for high-level autonomous driving will continue to rise.

Core components of the intelligent connected vehicle computing platform architecture: hardware platform + system software + functional software.

1. Core Software Overview

(1) Overview of Core Software Industry Landscape

The software involved in the driving domain computing platform includes system software, functional software, and application software from the bottom up.

Figure 3: Classification of Driving Domain Software Layers: System Software – Functional Software – Application Software

Core Software and Underlying Hardware of Driving Domain Computing Platform Architecture

At the system software level, it mainly includes BSP (Board Support Package), hypervisor (virtualization), narrow OS kernel, middleware components, etc.

At the functional software level, it mainly consists of core common functional modules for autonomous driving, including a general framework for autonomous driving, networking modules, operational control modules, etc. Functional software combines with system software to form a macro-level autonomous driving operating system.

At the application software level, application software mainly includes scene algorithms (covering data perception, multi-dimensional fusion, decision-making planning, control execution, etc.), data maps, etc.

For different software layers, we have categorized the main industry participants from four dimensions: traditional Tier 1, OEMs and their subsidiaries, tech giants, and third-party software suppliers.

Table 3: Companies with Business Layouts in Different Software Layers of the Driving Domain

(2) System Software 1: Hardware Abstraction Layer – Hypervisor and BSP

1. Hypervisor: Manages and virtualizes underlying hardware. Hypervisor virtualization technology can effectively achieve resource integration and isolation. The autonomous driving operating system is based on heterogeneous distributed hardware, where applications like AI computing and real-time safety functions may rely on different kernel environments and drivers, but share physical resources like CPU.

Figure 4: Typical Architecture of Hypervisor

Mainstream virtualization technology providers include BlackBerry QNX Hypervisor and ACRN (open source) led by Intel and the Linux Foundation. As of now, only QNX Hypervisor has been applied to mass-produced vehicles, making it the only virtualization operating system recognized with functional safety level reaching ASIL D.

Table 4: Major Suppliers of Onboard Hypervisors

Note: (1) RIM is BlackBerry’s parent company; (2) In mid-2017, Thunder Software Technology and Chengmai Technology were selected for BlackBerry’s VAI program. Once they become VAI project partners, they can develop integrated services and safety-critical solutions based on BlackBerry’s embedded technology, including BlackBerry QNX Neutrino real-time operating system, QNX Momentics tool suite, QNX management program, application and media QNX SDK, QNX wireless architecture, QNX certified operating system, QNX medical operating system, Certicom toolkit, Certicom-managed public key infrastructure, and Certicom asset management system, with applications in automotive electronics, medical devices, smart grids, power control, and industrial automation; (3) Runhe Software has developed an intelligent cockpit solution based on the Intel Apollo Lake platform using ACRN virtualization technology.

2. BSP: The underlying software that ensures hardware operation, with different OS corresponding to different defined forms of BSP.

BSP (Board Support Package) is essential for general embedded systems. Hardware needs to be designed by embedded hardware engineers, and newly manufactured circuit boards require BSP to ensure stable operation before moving on to the next step of software development.

BSP is one of the system software that sits between the motherboard hardware and the operating system, primarily aimed at supporting the operating system to run better on the hardware motherboard. BSP is relative to the operating system, and different operating systems correspond to different defined forms of BSP. For instance, while the functionality of VxWorks’ BSP and Linux’s BSP may be the same for a given CPU, the writing methods and interface definitions are completely different. Therefore, writing a BSP must adhere to the defined form of that system’s BSP to maintain the correct interface with the upper OS and provide good support.

BSP has both hardware and operating system relevance. Thus, the development of BSP requires certain hardware knowledge, such as CPU control, interrupt controller settings, memory controller settings, and related bus specifications, as well as mastery of the BSP interfaces defined by the operating system.

Figure 5: BSP Development Content Corresponding to Embedded Systems

Numerous companies are involved in the onboard chip BSP, including chip manufacturers, third-party software service providers, and vehicle manufacturers. However, different types of developers have distinct characteristics. For example, chip manufacturers are most knowledgeable about the underlying hardware but have limited development personnel, while vehicle manufacturers have relatively insufficient software capabilities. Third-party software service providers often have a competitive advantage, usually possessing rich experience in low-level development and a deep understanding of both underlying hardware and upper software, along with strong technology and good scalability in personnel size.

Table 5: Typical Participants in the Onboard Chip BSP Development Field

(3) System Software 2: Operating System Standards and OS Kernel

1. Classification of Onboard OS: Vehicle Control OS and Cabin OS can be roughly divided into vehicle control operating systems and intelligent cabin operating systems from the perspective of functional implementation:

(1) Vehicle Control Operating System: Mainly corresponds to the autonomous driving domain, power domain, and chassis domain, used to implement body chassis control, power systems, and autonomous driving; (2) Intelligent Cabin Operating System: Mainly corresponds to the cabin domain, used to implement in-vehicle entertainment information system functions and HMI corresponding functions.

Based on the above, we can further classify vehicle control operating systems: (1) Embedded Real-Time Operating Systems (RTOS): Used for traditional vehicle control, suitable for power systems and chassis control; (2) POSIX standard-based operating systems, suitable for the high-performance computing and high-bandwidth communication required for autonomous driving.

Table 6: Classification of Vehicle Control Operating Systems

Traditional vehicle control ECUs use RTOS that comply with OSEK/VDX and Classic AUTOSAR standards. In the traditional distributed EE architecture, specific ECUs handle specific functions. Common ECUs include EMS engine control system, ABS anti-lock braking system, TCU traction control, EPS electronic stability control, VCU for new energy vehicles, and BMS battery management system. Generally, vehicle ECUs consist mainly of MCU, memory, I/O, and peripheral circuits, with the MCU being the core.

Traditional ECUs have limited functions, operate relatively simply, and do not require high-performance OS for resource scheduling and allocation. However, since they are involved in vehicle control, related systems are complex measurement and control systems. If system task responses are not timely or have excessive delays, it may lead to serious safety hazards. Therefore, automotive electronic control ECUs must be high stability embedded real-time operating systems (RTOS), where real-time means the system guarantees completion of specific functions within certain time limits. Currently, mainstream electronic control operating systems generally comply with OSEK/VDX and Classic AUTOSAR automotive electronic software standards.

It is worth noting that AUTOSAR and OSEK are both automotive electronic software standards, with AUTOSAR developed based on OSEK/VDX. OSEK/VDX is an operating system standard developed for ECUs, originating in the 1990s, while AUTOSAR is a functional standard for overall automotive electronics development initiated in 2003.

Figure 6: Typical Vehicle Control OS Complying with OSEK/VDX Standards

Most autonomous driving OS kernels currently reference the Adaptive AUTOSAR platform, which defines an operating system based on POSIX standards, providing standardized platform interfaces and application services to support POSIX-compliant operating systems and diverse application needs. From a functional execution perspective, ECU software platforms can be divided into three categories: infotainment-based ECUs, traditional control-based ECUs, and ECUs executing autonomous driving functions.

The Classic AUTOSAR standard meets the needs of traditional vehicle control ECUs. However, advanced driver assistance and autonomous driving require the introduction of highly complex software with substantial computing resource demands. Moreover, these software systems must be fully compatible and absolutely safe within the vehicle. As automotive electronics and software functionalities significantly increase in the future, there may ultimately be a shift towards centralized electronic and electrical architecture based on central computing in vehicles. For controllers or computing platforms in the autonomous driving domain, the Classic AUTOSAR cannot meet their needs, requiring a new software architecture platform that is highly flexible, high-performance, and supports HPC, dynamic communication, and other features.

In 2018, to meet the future needs for automotive intelligence and connectivity, the AUTOSAR alliance launched a brand new platform by adding AP to the original AUTOSAR platform, forming the Adaptive AUTOSAR platform, which welcomed its first production-oriented release in October 2018. The original platform was also renamed the Classic AUTOSAR platform.

Figure 7: Software Platform Requirements for Different Types of ECUs

2. Driving Domain OS Kernel: QNX, Linux, and VxWorks Share the Market

Driving domain OS can be roughly divided into narrow and broad definitions: (1) Narrow OS: Specifically refers to the OS kernel that can be directly deployed on hardware; (2) Broad OS: Includes system software from BSP, OS kernel, middleware, and library components from the bottom up.

The OS kernel, also known as the underlying OS, aims to provide the most basic functions of an operating system, managing system processes, memory, device drivers, files, and network systems, determining system performance and stability.

Figure 8: Narrow OS Mainly Includes QNX, Linux, and VxWorks

The landscape of autonomous driving OS kernels is relatively stable, with the main products being QNX (Blackberry), Linux (open-source foundation), and VxWorks (Wind River System). Due to the immense human and material resources required to create a new OS, there are currently basically no companies developing completely new OS kernels. Currently, companies like Waymo, Baidu, Tesla, and Mobileye are developing middleware and application software based on existing OS kernels.

Additionally, the QNX system ecosystem is relatively closed, while both Linux and VxWorks are open source. The source code for all kernel components of Linux and VxWorks is available to customers for customization. If a QNX kernel is selected, vehicle manufacturers cannot customize it, but customers can write their middleware and application software. In 2017, BlackBerry established the VAI (Value Added Integrator) project, and Thunder Software Technology and Chengmai Technology joined BlackBerry’s embedded partner program as system integrators, providing integrated service solutions based on BlackBerry QNX embedded technology (including BlackBerry QNX Neutrino real-time operating system, QNX management program, QNX wireless architecture, QNX certified operating system, etc.), with applications in automotive electronics, medical devices, smart grids, power control, and industrial automation.

From a cost and development difficulty perspective, QNX requires payment, but has lower development difficulty and less code volume. Linux is free but has higher development difficulty and is prone to bugs.

Figure 9: Comparison of Mainstream OS Kernels

(4) Functional Software: Middleware and Core Common Functional Modules

1. Middleware

Middleware is a type of software that sits between application systems and system software, located above the operating system of client-server architectures, managing computing resources and network communication. According to IDC’s definition, middleware is an independent software service program that allows distributed application software to share resources across different technologies.

The main task of middleware is to facilitate communication between various application software modules and to schedule the underlying system resources. Its advantage is that it can significantly reduce the development difficulty of application-layer software, allowing development engineers to focus entirely on the development of functional algorithms.

The most well-known middleware in the industry is the RTE (Runtime Environment) in Classic AUTOSAR, which is responsible not only for communication between upper-layer SWCs (Software Components) but also for scheduling SWCs and invoking underlying operating systems and communication services.

Figure 10: Middleware Usage in Distributed Systems

Figure 11: Basic Middleware Category Division

The market for intelligent driving middleware is rapidly growing. For example, TTTech Auto (the automotive subsidiary of TTTech) has launched intelligent driving middleware (MotionWise safety software platform) with clients including Aptiv, Audi, BMW, Continental, and Daimler. Revenue grew from $19.2 million in 2018 to $88.72 million in 2019, with projected revenue of $190 million to $200 million in 2020.

However, due to the high functional safety levels involved, the market threshold is higher than for application layer software.

In the middleware field, traditional Tier 1 and tech giants have relatively few layouts. From the perspective of major Tier 1 products and scenario layouts for autonomous driving, Bosch, Continental, and ZF have the most comprehensive layouts among foreign Tier 1 companies, with Bosch and ZF both launching middleware products aimed at autonomous driving in 2020.

In July 2020, Bosch launched middleware for advanced autonomous driving applications—Iceoryx, compatible with ROS2 and Adaptive AutoSAR interfaces, addressing the needs of different development stages.

In December 2020, ZF released middleware ZF Middleware, providing a modular solution that can be integrated into vehicle manufacturers’ software platforms. This middleware is expected to be installed in mass-produced vehicles by 2024.

It is noteworthy that foreign Tier 1 companies are beginning to penetrate the underlying system development while implementing functionality, building bridges between systems and software applications. Bosch and ZF successively released middleware products with the aim of providing centralized autonomous driving solutions for OEMs through comprehensive sensor product layouts, reducing system integration complexity, lowering development costs, and accelerating product deployment.

Figure 12: Layout of Autonomous Driving Perception Layer Products and Scene Algorithms

2. Core Common Functional Modules

In addition to API middleware, the core common functional modules of autonomous driving constitute the main part of functional software. Core common functional modules include a general framework for autonomous driving, networking, cloud control, etc., which, combined with system software, form a complete autonomous driving operating system that supports autonomous driving technology implementation.

Table 7: Five Core Common Modules in Computing Platform Functional Software

(5) Application Software: Diverse Types, Including Scene Algorithms, Data Maps, etc.

Application layer software runs on top of the broad operating system, specifically responsible for implementing autonomous driving functions. A typical computing platform, after loading and running an operating system composed of system software and functional software, supports application software development upward, ultimately achieving overall functionality. Application layer software content is complex, including scene algorithms (covering data perception, decision-making planning, control execution, etc.), data maps, human-machine interaction (HMI), etc.

Here, we will elaborate on scene algorithms, which typically include data perception, decision-making planning, and control execution. Perception algorithms include SLAM algorithms (covering visual processing, lidar, multi-sensor fusion, etc.) and autonomous driving perception algorithms. Decision-making algorithms include autonomous driving planning algorithms and autonomous driving decision algorithms, while execution algorithms mainly consist of autonomous driving control algorithms.

Currently, numerous industry participants are involved in this field, ranging from vehicle manufacturers, traditional Tier 1s, to startup companies, tech giants, and independent software suppliers.

Figure 13: Main Algorithm Layout in the Application Layer

Figure 14: Main Purposes and Programming Languages of Application Layer Algorithms

Data maps (high-precision maps) are another typical software in the application layer. Traditional in-vehicle navigation maps are used by humans, and traditional electronic navigation maps depict roads, with some roads differentiating lanes. However, high-precision maps not only depict roads but also accurately reflect the actual styles of the roads. To enable autonomous driving systems to better recognize traffic conditions, high-precision maps detail and accurately display the nuances of road shapes.

High-precision maps are indispensable for intelligent driving. From the perspective of visibility, high-precision maps are not obstructed and do not have distance and visual defects, and they can still function under special weather conditions. From an error perspective, high-precision maps can effectively eliminate some sensor errors and can provide effective corrections to existing sensor systems under certain road conditions. Additionally, high-precision maps can also construct a driving experience database by mining multi-dimensional spatiotemporal data to analyze hazardous areas, providing drivers with new driving experience datasets.

Figure 15: High-Precision Maps are Indispensable for High-Level Autonomous Driving Systems

Currently, the competitive landscape in the high-precision map field shows a tripartite situation among Four-Dimensional Map (with Tencent Industry Fund as the second-largest shareholder, holding 5% as of the end of March 2021), Gaode (a wholly-owned subsidiary of Alibaba), and Baidu. Baidu was one of the first companies in China to conduct high-precision map research, starting its unmanned vehicle project in 2013. Gaode benefits from Alibaba’s full support and is progressing rapidly, while Four-Dimensional Map is an established map vendor in China.

Table 8: High-Precision Map Orders of the Three Major Map Vendors

Data Source: Four-Dimensional Map Company Announcements (See: February 13, 2019, “Four-Dimensional Map: Announcement on Signing Autonomous Driving Map License Agreement with BMW” and November 20, 2019, “Four-Dimensional Map: Announcement on Huawei’s Procurement of High-Precision Map Data Products and Services”), Autohome, Gaishi Automobile, GF Securities Development Research Center

2. Underlying Hardware Overview

(1) Underlying Hardware Adopts Heterogeneous Distributed Architecture (Taking Huawei MDC as an Example)

The intelligent driving domain controller is a core component that combines the vehicle’s drive-by-wire platform and a large number of various peripheral sensors, characterized by diverse interface types, sufficient interface numbers, and high performance. Multi-sensor data fusion, artificial intelligence algorithms, and other technologies impose higher requirements on the interfaces and computing power performance of domain controllers, thus requiring the use of heterogeneous multi-core chip hardware solutions integrating various architecture chips.

The heterogeneous multi-core chip hardware architecture mainly consists of three parts: AI unit, computing unit, and control unit.

AI Unit: The largest computing power segment in the heterogeneous chip hardware architecture, responsible for analyzing and processing data from multi-sensor fusion through the system kernel for resource allocation and scheduling. The AI unit mainly analyzes and processes multi-sensor fusion data, outputting environmental information for planning, decision-making, and control. Currently, mainstream AI chip architectures include GPU, FPGA, and ASIC.

Computing Unit: The computing unit based on multi-core CPU features high frequency and strong computing power, managed by the system kernel to execute task scheduling. The computing unit is mainly used to execute most core algorithms related to autonomous driving, integrating multi-sensor fusion data to complete path planning, decision-making, and control functions.

Control Unit: Mainly based on traditional vehicle controllers (MCU) to complete vehicle dynamic longitudinal and lateral control tasks, the control unit equipped with a basic software platform connects various vehicle control functional software to achieve vehicle control while reserving communication interfaces for integration with intelligent vehicle operating systems.

Table 9: Core Underlying Hardware Classification of Domain Controllers

Taking Huawei MDC as an example, in addition to the common MCU, the MDC computing platform includes two core chips: CPU chip: Kunpeng 920s, based on Huawei’s self-developed ARM processor, using 7nm process, with a maximum power consumption of 55W; AI chip: Ascend 310, based on Da Vinci AI architecture, with a 12nm process, a maximum power consumption of 8W, and computing power reaching 16 TOPS (8-bit integer precision).

Figure 16: Huawei MDC Architecture – Underlying Hardware Platform Composed of AI Chip/CPU, etc.

The internal MDC computing unit includes four major modules: CPU module, image processing, AI processing, and data exchange. The data exchange module is mainly responsible for data interaction among other modules, while the image processing module primarily converts raw data from cameras into YUV or RGB formats. Additionally, the AI processing module and CPU module have the following main functions:

AI Processing Module (with built-in AI chip): Mainly used for AI computing, primarily CNN calculations (Convolutional Neural Networks), capable of performing AI processing for cameras or pre-fusion AI calculations for cameras and lidar, with 64GB memory;

CPU Module (with built-in CPU chip): Mainly provides integer calculations and can be used to deploy post-fusion, positioning, and control algorithms, with 16GB memory.

Huawei MDC with Upper Application Architecture Diagram

Note: CAN, ETH, GMSL, etc., are all internal communication methods. Generally, ETH (Ethernet interface) can connect to 4G networks, vehicle networking systems, etc., while the CAN interface can connect to chassis ECUs, including steering and power ECUs.

(2) Three Main Schools of CPU + AI Chips

1. Main Classifications of AI Chips: GPU/FPGA/ASIC

GPU still belongs to general-purpose chips. It differs significantly from traditional CPUs, which require strong versatility to handle various data types and have high demands on logical judgments, resulting in a complex internal structure. In contrast, GPUs deal with large-scale data of highly consistent types that are independent of each other and do not require interruption in pure computational environments.

GPUs use numerous computing units and long pipelines but have very simple control logic and forgo cache, while CPUs are heavily occupied by cache and have complex control logic and numerous optimization circuits, making their computing power only a fraction of that of CPUs.

Figure 18: CPU VS GPU

ASIC refers to customized chips designed and manufactured to meet specific user requirements and the needs of specific electronic systems. ASICs are characterized by being tailored to specific user needs, and when produced in bulk, they have advantages over general integrated circuits in terms of smaller size, lower power consumption, improved reliability, enhanced performance, increased confidentiality, and reduced costs. ASICs have high-performance and low-power advantages, but most algorithms they contain—except those executed by internal processor cores—are “frozen”.

FPGA emerged as a semi-custom circuit in the ASIC domain, with its greatest feature being the ability to configure its programmable architecture to achieve the digital function combinations needed by developers.

Comparison of ASIC VS FPGA:

(1) Purpose: FPGA is mainly used for requirements of rapid iteration or small batch products; ASIC is used for designing large-scale, complex chips, or mature and high-yield products;

(2) Cost: For small batch needs, the unit cost of FPGA is lower than that of ASIC, while with increasing product volume, the unit cost of ASIC gradually decreases;

(3) Power Consumption: Under the same process conditions, FPGA power consumption is greater than that of ASIC;

(4) Speed: FPGA is based on a general structure, which leads to redundancy; ASIC optimizes logical resources based on design requirements and achieves optimal layout and routing to reduce routing delays;

(5) Area: Customized circuit designs and processes use less area in ASIC than in FPGA;

Figure 19: Comparison of Different Types of Chips

1. School One: CPU + GPU + ASIC (Represented by Nvidia, Tesla, Qualcomm, etc.)

Nvidia’s autonomous driving chips adopt a CPU + GPU + ASIC architecture. Nvidia currently holds a leading position in the global autonomous driving chip field, with main products including Xavier (launched in 2018, architecture disclosed), Orin (launched in 2019, internal architecture not disclosed), and Atlan (launched in 2021).

The Xavier chip, released in 2018, has been successfully mass-produced and mainly consists of four modules: CPU, GPU, and two accelerator ASICs. The two accelerator ASICs are Deep Learning Accelerator (DLA) and Programmable Vision Accelerator (PVA). In terms of size, the largest area is occupied by the GPU, followed by the CPU, and finally supplemented by the two dedicated ASICs, optimizing the energy consumption ratio.

The Atlan chip, launched in 2021, will be used in models of several automobile manufacturers for 2025, and it mainly includes four modules: a new Arm CPU core, GPU, and deep learning and computer vision accelerators.

Additionally, it will include a BlueField data processing unit that can provide a wide range of advanced networking, storage, and security services to support complex computing and AI workloads in autonomous driving vehicles, offering over 1,000 trillion operations per second (TOPS) of computing power.

Figure 20: Nvidia Xavier Architecture

Figure 21: Nvidia Atlan Architecture

Tesla’s self-designed FSD computing power reaches 144 Tops and also adopts a CPU + GPU + ASIC architecture. The FSD includes three different processing units: a GPU for graphics processing, a neural processing unit (NPU) for deep learning and prediction (ASIC), and a central processing unit (CPU) for general data processing. Tesla custom-designed the neural network accelerator (NPU) on the FSD chip, which is the largest component of the FSD chip and the most critical logical part.

Figure 22: Tesla FSD Architecture

Qualcomm’s Snapdragon ride high-end products are also expected to adopt a CPU + GPU + ASIC architecture. In 2020, Qualcomm launched the driving domain chip product Snapdragon ride, which is divided into three series:

(1) The underlying hardware for L1/L2 level ADAS (with functions like AEB, TSR, LKA) includes one ADAS application processor (safety system-on-chip SoC), providing 30-60 TOPS of computing power;

(2) The hardware support for L2+ level ADAS (with functions like HWA, automatic parking APA, and TJA) includes two or more ADAS application processors, requiring approximately 60-125 TOPS of computing power;

(3) The highest-end product aimed at L4/L5 level autonomous driving is configured with two ADAS application processors + two autonomous driving accelerators ML (ASIC), providing up to 700 TOPS of computing power, with a power consumption of about 150W.

Figure 23: Qualcomm Snapdragon Ride Product Line

2. School Two: CPU + ASIC (Represented by Mobileye, Huawei, Horizon, etc.)

Mobileye has a strong competitive advantage in the autonomous driving chip field, having successively launched the ASIC-based EyeQ series chips since 2004. Mobileye’s products cover L1-L3 level pre-installed ADAS, with its hardware products primarily based on the ASIC architecture’s EyeQ chips. The company’s intelligent driving system solutions consist of four parts: EyeQ chips, autonomous driving strategies, safe protection layers RSS, and mapping technology REM.

So far, five generations of EyeQ chips have been released. The first generation EyeQ1 has a computing power of approximately 0.0044 Tops, and the second generation EyeQ2 has a computing power of approximately 0.026 Tops, both with a power consumption of 2.5W, mainly used for L1 level autonomous driving. The third generation EyeQ3 is a self-developed ASIC architecture that uses four MIPS core processors and four VMP chips, supporting L2 advanced driver assistance computing requirements. The fourth generation EyeQ4, launched in 2018, uses a 28nm process, employs five core processors, six VMP chips, two MPC cores, and two PMA cores, achieving L4 level autonomous driving functionality at its peak.

The latest generation chip EyeQ5 mainly includes four modules: CPU, visual accelerator CVP (ASIC), and Deep Learning Accelerator (DLA) and Multithreaded Accelerator (MA). In terms of module size, the CPU and CVP occupy the majority, with the CVP being an ASIC chip designed for many traditional computer vision algorithms. Historically, Mobileye has been known for its CV algorithms and has achieved very low power consumption by using proprietary ASICs to run algorithms.

However, Mobileye’s ASIC chip + algorithm system is closed, which is a major criticism from many manufacturers, as OEMs and Tier 1s cannot use different algorithms to reflect differentiated competition and cannot grasp these core algorithms.

Figure 24: Mobileye EyeQ5 Block Diagram

Huawei is one of the leading companies in the domestic intelligent driving chip field, with comprehensive strength. In early 2021, Huawei officially launched four MDC products for different application scenarios: (1) MDC300F, targeting commercial vehicles or working vehicles in ports, mines, and logistics parks, with a computing power of approximately 64 TOPS; (2) MDC210, targeting passenger cars with L2+ functional scenarios, with a computing power of approximately 48 TOPS; (3) MDC610, targeting passenger cars with L4+ functional scenarios, with computing power exceeding 200 TOPS; (4) MDC810, targeting passenger cars or Robotaxis with L4-L5 functional scenarios, with computing power exceeding 400 TOPS.

Huawei’s MDC also adopts a CPU + ASIC combination architecture, with its self-developed NPU Ascend 310 providing strong AI computing power. According to Huawei’s 2018 MDC product introduction, the MDC integrates Huawei’s self-developed Host CPU chip, AI chip, ISP chip, and SSD controller chip.

MDC300 computing platform supports L3 level autonomous driving, consisting of the Ascend 310 chip (self-developed Da Vinci architecture NPU, belonging to ASIC), Kunpeng CPU, and Infineon TC397. The MDC600 computing platform supports L4 and above autonomous driving, including Kunpeng CPU, Ascend 310 chip, and ISP.

Figure 25: Core Parameters of Huawei MDC300/600

Figure 26: Huawei MDC Platform Based on Highly Integrated Ascend SoC

Horizon is the first company in China to achieve mass production of automotive-grade AI chips. In 2019, the company launched Journey 2, with several models equipped with the Horizon Journey 2 chip, including Changan UNI-T, Chery Ant, Zhiji Automobile, Changan UNI-K, GAC Aion Y, Dongfeng Lantu Free, JAC QX, GAC Trumpchi GS4 Plus, and SAIC Maxus MIFA concept car.

Currently, the Journey 5 launched in 2021 has already secured model points, with mass production expected in the second half of 2022. The planned Journey 6 is based on automotive-grade 7nm advanced process, with the engineering sample expected to be released in 2023 and mass production scheduled for 2024.

Figure 27: Horizon Automotive Intelligent Chip Roadmap

The Horizon Journey 2 adopts a CPU + ASIC combination architecture. In 2019, the company released the first mass-produced automotive-grade edge AI vision chip, Journey 2.0, manufactured using a 28nm process, integrating dual-core Arm Cortex A53 and the self-developed second-generation Horizon BPU architecture, reaching automotive-grade AEC-Q100 standards. In terms of performance, it has an equivalent computing power exceeding 4 TOPS and uses a 17mm*17mm BGA388 packaging process, with a typical power consumption of only 2W.

Figure 28: Horizon Journey 2 Chip Architecture

Figure 29: Horizon Journey 2 Block Diagram

3. School Three: CPU + FPGA (Represented by Baidu-Xilinx, Waymo, etc.)

Baidu’s mass-produced ACU adopts a CPU + FPGA architecture. The Baidu ACU is an autonomous driving onboard computing unit aimed at mass production, categorized into several series of products based on the computing power requirements of different scenarios. The ACU-Advanced is a dedicated onboard computing platform for autonomous parking products that has already been mass-produced.

The core architecture of ACU-Advanced is designed based on Xilinx ZU5 (FPGA), compatible with Baidu’s PaddlePaddle deep learning framework. According to Baidu’s R&D personnel, this chip from Xilinx offers good flexibility, beneficial for algorithm iteration; additionally, it can provide sufficient computing power to maintain driving speed; and it meets strict automotive-grade requirements for normal use at 85°C. Moreover, FPGA SoC has high reliability, contributing to the safety of autonomous driving.

Figure 30: Baidu’s Xilinx FPGA Chip Architecture

Figure 31: Baidu ACU-Advanced Underlying Hardware Architecture

Waymo adopts Xeon processors (CPU) and Arria FPGA as typical processing solutions. In 2017, Intel announced its collaboration with Google on the development of autonomous vehicles since 2009, also collaborating with Waymo to provide Xeon processors, Arria FPGAs (for machine vision), and Gigabit Ethernet solutions to help Waymo’s autonomous vehicles process information in real-time.

Figure 32: Intel Xeon Processor Architecture

Figure 33: Arria 10 FPGA Architecture

Business cooperation, add WeChat: 18008462630.There are dozens of groups in the automotive industry including complete vehicles, key components, new energy vehicles, intelligent connected vehicles, aftermarket, automotive investment, autonomous driving, and vehicle networking. To join the groups, please scan the administrator’s WeChat (please indicate your company name). There is also a startup financing group, welcome angel round and A round companies to join;

Core Software and Underlying Hardware of Driving Domain Computing Platform Architecture

Source: GF Securities

Related posts

Leave a Comment Cancel reply