What is a Domain Controller

Over the past decade, the development of automotive intelligence and information technology has led to a significant increase in the usage of ECU chips. From traditional engine control systems, airbags, anti-lock braking systems, electric power steering, and electronic stability control systems; to intelligent dashboards, entertainment systems, and driver assistance systems; as well as electric vehicle power control, battery management systems, onboard charging systems, and the rapidly growing onboard gateways, T-BOX, and autonomous driving systems, etc.

Traditional automotive electronic and electrical architectures are distributed (as shown in Figure 2-1), with various ECUs in the vehicle connected via CAN and LIN buses. The total number of ECUs in modern vehicles has rapidly increased to dozens or even hundreds, resulting in greater system complexity, nearing its limits. In today’s trend of software-defined vehicles and the development of automotive intelligence and connectivity, this ECU-based distributed EEA has increasingly exposed many problems and challenges.

Figure 2-1 Distributed EEA in Automobiles

To address these issues of distributed EEA, people have started to gradually integrate many similar, separated ECU functions into a more powerful processing hardware platform, which is the automotive “Domain Control Unit (DCU).” The emergence of domain controllers marks an important evolution of automotive EE architecture from distributed ECU architecture to domain centralized EE architecture (as shown in Figure 2-2).

The domain controller is the core of every functional domain in a vehicle, primarily composed of a domain master processor, operating system, and application software and algorithms. Platform-based, high integration, high performance, and good compatibility are the main core design philosophies of the domain controller. Relying on high-performance domain master processors, rich hardware interface resources, and powerful software features, domain controllers can integrate core functions that originally required many ECUs, greatly improving system functional integration. Additionally, with standardized interfaces for data interaction, this can significantly reduce development and manufacturing costs for this part.

As for the specific division of functional domains, each automotive manufacturer will divide them into several different domains based on their design philosophies. For example, BOSCH divides them into five domains: Power Train, Chassis, Body/Comfort, Cockpit/Infotainment, and ADAS. This represents the classic five-domain centralized EEA, as shown in Figure 2-2. Some manufacturers further integrate on the basis of the five-domain centralized architecture, merging the original power, chassis, and body domains into a complete vehicle control domain, resulting in a three-domain centralized EEA, namely: Vehicle Domain Controller (VDC), Intelligent Driving Domain Controller (ADC), and Cockpit Domain Controller (CDC). Volkswagen’s MEB platform and Huawei’s CC architecture belong to this three-domain centralized EEA.

Figure 2-2 Domain Centralized EE Architecture

02

Overview of the Domain Controller Market

In 2018, based on Delphi’s domain controller technology, Austria’s TTTech company developed the zFAS controller, which was first applied in the Audi A8. Visteon then launched the SmartCore domain controller, integrating infotainment, dashboard, information display, HUD, ADAS, and other functions. These products pioneered commercial functional domain controller products, and major Tier 1 suppliers worldwide have followed suit, gradually developing the entire domain controller market.

In the domestic market, companies such as Huawei, Desay SV, Haosmart, and Neusoft have also launched DCU solutions, which have been adopted by domestic automotive manufacturers. For instance, the intelligent coupe P7 launched by XPeng Motors in 2020 adopted Desay SV’s autonomous driving domain controller product – IPU03, based on NVIDIA Xavier.

Currently, the entire industry has very optimistic expectations for the DCU market. According to Zosi Research, global automotive DCU (cockpit + autonomous driving) shipments are expected to exceed 14 million units by 2025, with an average annual growth rate as high as 50.7% from 2019 to 2025.

Figure 2-3 Global Domain Controller Market Forecast

The entire automotive industry generally believes that domain controllers represent the highest competitive threshold in the automotive electronics industry in the future, thus holding the highest profit potential; chip manufacturers and core algorithm suppliers will benefit.

(1) Driving Factors Behind the Rapid Growth of the Domain Controller Market

More and better ADAS functions, along with intelligent cockpit and infotainment features, have always been the main factors driving the rapid growth of the domain controller market. These new features significantly enhance the technological feel and user experience of the vehicle, making them a key investment focus for manufacturers when developing new models. ADAS applications from Level 1 to Level 2+ have developed rapidly in recent years, with many functions quickly becoming widespread, such as parking assistance, lane departure warnings, adaptive cruise control, collision avoidance, blind spot detection, and driver fatigue detection.

Domain controllers require a more powerful, highly integrated master processor as their brain, enabling more functions that were previously achieved by separate ECUs to now be implemented on the domain master processor, thus saving the required number of ECUs and other hardware resources in the functional domain. Higher integration allows manufacturers to meet the requirements of platformization and standardization for ADAS domain control and related components in supply chain management.

(2) Impact on the Domain Controller Supply Chain

The evolution and development of automotive E/E architecture have profoundly influenced the supply relationships between manufacturers and automotive electronics suppliers. The core competitiveness of manufacturers has shifted from primarily mechanical manufacturing to a focus on software and algorithms. It is expected that in the future, there will be two possible cooperation models between vehicle manufacturers and Tier 1 suppliers:

• Firstly, Tier 1 is responsible for the hardware design and production of the domain controller, as well as the middleware software part. The vehicle manufacturer is responsible for the autonomous driving software part. The advantage of Tier 1 lies in producing products at reasonable costs and accelerating product deployment, making collaboration between vehicle manufacturers and Tier 1 for production inevitable. In this model, the vehicle manufacturer may bypass Tier 1 and directly confirm the chip selection with chip manufacturers during project initiation.
• Secondly, Tier 1 collaborates with chip manufacturers to integrate solutions and develop central domain controllers for sale to vehicle manufacturers, such as Continental’s ADCU, ZF’s ProAI, Magna’s MAX4, etc.

2.1 Intelligent Cockpit Domain Controller

The essence of cockpit intelligence is based on the human-machine interaction scenarios in the vehicle cockpit, integrating driving information and entertainment information into two modules to provide users with an efficient, intuitive, and futuristic driving experience. The design requirements for intelligent cockpits primarily aim to enhance the user’s driving experience while ensuring safety and comfort, ultimately achieving the goal of the vehicle as a third living space outside of work and home.

The intelligent cockpit domain consists of three main components: HUD, dashboard (Cockpit), and In-Vehicle Infotainment (IVI) system.

HUD is a very practical feature that projects ADAS and some navigation functions onto the windshield, such as ACC, pedestrian recognition, LDW, route prompts, intersection turning prompts, lane change prompts, remaining battery, and drivable range. HUD will soon evolve into AR HUD, becoming a standard feature in the L3 and L4 era.

As we enter the L3 era, Driver Status Monitoring (DMS) will become an essential feature, including facial recognition, eye tracking, and blink count tracking, which will incorporate machine vision and deep learning algorithms. The L4 era will necessitate V2X (Vehicle to Everything).

Moreover, the rapid development of multimodal interaction technology will greatly change the interaction mode between users and vehicles. Voice interaction technology based on voice recognition is becoming increasingly popular, commonly used for interactions with the IVI system. Furthermore, it can analyze the emotional state of the driver through voice. When the DMS system detects that the driver is drowsy, the system can awaken the driver by playing music or releasing fragrances; the multimodal interaction technology in various scenarios will undoubtedly redefine the development of human-machine interaction technology.

All these new technologies in intelligent cockpits will drive a surge in demand for cockpit domain computing resources.

In the field of intelligent cockpit domain controllers, major global Tier 1 manufacturers include Bosch, Continental, Harman, Visteon, and Aptiv. Domestic companies include Desay SV, Haosmart, and Neusoft.

Table 2-1 Information on Major Global Cockpit Domain Controller Manufacturers

▼

Manufacturer	Chip Platform	Cockpit Domain Controller Name	Operating System/Hypervisor	Clients
Visteon	Qualcomm	SmartCore	Android, Linux	Geely, Daimler, Dongfeng, GAC
Continental	Qualcomm/Renesas	Integrated Body Electronics Platform IIP	QNX/PikeOS
Bosch	Qualcomm	AI Car Computer	AGL	General Motors
Aptiv	Intel	ICC	Linux/ARCN	Great Wall, Audi, Volvo
Desay SV	Qualcomm 820ATI Jacinto6	Intelligent Cockpit Domain Controller	Li Auto
Neusoft Ruichi	Intel	C4-A1fus	Linux/ARCN

2.2 ADAS Domain Controller

ADAS domain controllers typically need to connect multiple cameras, millimeter-wave radars, lidar, and other sensor devices, requiring capabilities for multi-sensor fusion, positioning, path planning, decision control, wireless communication, and high-speed communication, completing numerous functions including image recognition and sensor data processing. Therefore, they require substantial computing power, and domain controllers generally need to match a core processor with strong computational power that can support various levels of autonomous driving. Currently, there are multiple solutions from NVIDIA, Huawei, Renesas, NXP, TI, Mobileye, Xilinx, Horizon, and others in the industry.

Autonomous driving technology is currently at the forefront of the global technology industry. The assisted driving technologies and functions at Levels 1 to 2+ have matured, and many models equipped with ADAS functions and applications are beginning large-scale production. It can be seen that the market penetration rate of L1/L2 level ADAS functions will rapidly increase, while L3/L4 level autonomous driving systems are still in small-scale prototype testing stages.

Today, the Chinese market is undoubtedly a major player in the autonomous driving industry. This year, the expected installation of L2 in China is expected to exceed 800,000, with Chinese brands accounting for the majority of the market share. In the future, the penetration rate of ADAS functions in the Chinese market will continue to rise rapidly, with more mid-range and low-end vehicles gradually equipped with ADAS functions. According to a research report by iResearch Consulting, it is estimated that by 2025, the penetration rate of ADAS functions in the passenger vehicle market could reach around 65%. The penetration rates of L3 level high-speed autonomous navigation (HWP) functions and L4 level AVP autonomous parking functions are currently low, but there is significant room for growth in the future.

Figure 2-4 Forecast of ADAS Function Market Penetration in China

ADAS domain controllers are evolving from the past distributed system architecture to domain centralized architecture. Previously, a complete ADAS system required several independent ECUs to function, such as lane departure and traffic recognition ECUs, forward collision warning ECUs, parking assistance ECUs, etc. Now, with powerful centralized ADAS domain controllers, a single domain controller can achieve all functions. The complexity of the system’s hardware and software has been greatly reduced, and reliability has improved.

Currently, major providers of ADAS domain control chip platforms include NVIDIA, Huawei, Renesas, NXP, TI, Mobileye, as well as domestic companies like Horizon and Black Sesame, among others. The following Table 2-2 summarizes the key global ADAS domain controller manufacturers and their clients and partners.

Table 2-2 Information on Major Global ADAS Domain Controller Manufacturers

▼

Manufacturer	ADAS Domain Controller Name	Computing Chip Platform	Autonomous Driving Level	Functional Safety	Operating System	Clients and Production Plans
Visteon	DriveCore	Supports NVIDIA, Qualcomm, and NXP processor architectures	L2-L4	ASIL-D	AutoSAR CP, Auto AP, Linux, etc.	GAC and two European manufacturers, with SOP planned for 2022
Continental	ADCU	NVIDIA DRIVE Xavier	L3/L4	ASIL-D	AutoSAR Adaptive platform	Collaborating with NVIDIA on the L3 level autonomous driving domain controller platform
In-Vehicle Server (ICAS1)	NVIDIA	L2	ASIL-C/D	Volkswagen MEB platform ID.3 series electric vehicles
Bosch	DASy 1.0	NVIDIA	L2/L2+	ASIL-C/D	AutoSAR CP, AutoSAR AP	Launched in 2019, supports HWP/TJA and other L2+ level functions
DASy 2.0	NVIDIA DRIVE Xavier	L3/L4	ASIL-D	AutoSAR AP, Linux	SOP in 2022
TTTech	zFAS/iECU	NVIDIA TX2/Xavier	/	/	/	Audi, SAIC
Aptiv	Central Sensor Localization and Planning (CSLP) Platform	Intel Mobileye	/	/	/	/
Veoneer	Zeus Super Computer	NVIDIA Xavier	/	/	/	/
ZF	Central Controller ProAI	NVIDIA Xavier	/	/	/	Collaborating with Baidu Apollo, clients include Chery
Magna	MAX4	/	/	/	/	BMW
Horizon Robotics	TITAN	NVIDIA Xavier	/	/	/	/
Black Sesame	Auto Wheel	NXP	/	/	/	Partners include NXP, Renesas, Sony, etc.
Zhixing Technology	iMo DCU Central Controller	TI Jacinto/NXP	/	/	/	Zotye
Jingwei Hengrun	ADAS Domain Controller	NXP	/	/	/	/
Neusoft Ruichi	ADAS DCU	Xilinx	/	/	/	Passenger and commercial vehicle manufacturers
Desay SV	Autonomous Driving Platform	NVIDIA Xavier	/	/	/	XPeng Motors

3.1 High Performance

Overall, the demand for computing power has always been a major driving force behind the development of core chips for domain controllers. On one hand, functions that were originally completed by multiple ECUs now need to be accomplished by a single domain master processor, which also needs to manage and control various connected sensors and actuators. For instance, the domain master processor for chassis, powertrain, and body comfort electronic systems has a computing power requirement of approximately 10,000 DMIPS to 15,000 DMIPS.

Figure 2-5 Forecast of CPU DMIPS Demand for Automotive Domain Controllers

The new intelligent vehicles not only need to interact more with people but also require extensive perception of the environment, necessitating the computation and processing of massive unstructured data. Therefore, both the cockpit domain and autonomous driving domain require high-performance CPUs. For example, the CPU computing power for cockpit dashboards is comparable to that of a high-end smartphone, approximately 50,000 DMIPS. In addition, to support L2 assisted driving functions or higher-level autonomous driving functions, numerous visual DNN model algorithms need to be executed, which requires hundreds of TOPS of AI computing power.

Therefore, chip manufacturers will always strive to use more advanced manufacturing processes and more advanced CPU and NPU cores to enhance the CPU core performance and NPU performance of domain master chips.

3.2 High Heterogeneity

With the application of AI technology in the visual domain, vision-based autonomous driving solutions have gradually emerged, requiring the addition of GPU chips adept at visual algorithms on top of CPUs, forming a “CPU + GPU” solution. However, the “CPU + GPU” combination is not necessarily the optimal solution because, while GPUs possess strong computing capabilities, they are costly and consume significant power, leading to the gradual introduction of FPGA and ASIC chips.

Overall, a single type of microprocessor, whether CPU, GPU, FPGA, or ASIC, cannot meet the higher-level autonomous driving requirements. The main control chip in domain controllers will trend toward integrating “CPU + xPU” heterogeneous SoC (where xPU includes GPU/FPGA/ASIC, etc.), thereby better supporting various scene hardware acceleration needs.

3.3 High Integration

From a functional perspective, domain controllers will integrate and consolidate an increasing number of functions. For example, the power system domain may combine engine control, motor control, BMS, and onboard charger control. Some manufacturers even directly integrate the three major functional domains of chassis, power transmission, and body into a “Vehicle Domain Controller (VDC).”

To support the integration of these functions, the domain master processor SoC, as the brain of the domain controller, needs to integrate as many types of interfaces as possible, such as USB, Ethernet, I2C, SPI, CAN, LIN, and FlexRay, to connect and manage various ECUs, sensors, and actuators.

3.4 Hardware Virtualization

The need for hardware virtualization technology mainly stems from two aspects: (1) partitioning and isolation of hardware resources; (2) supporting mixed safety levels.

As multiple functions that originally required several ECUs are consolidated into the domain controller, the software of the domain controller inevitably becomes more complex, which will increase the probability of errors in the entire software system, thus reducing reliability. Furthermore, when multiple applications run together on the same operating system, failures can propagate (Failure Propagation), meaning that if one application encounters an issue, it can disrupt the entire system’s underlying software and hardware, causing other originally normal applications to also start failing. Therefore, hardware virtualization technology is used to partition hardware resources, isolating the software and hardware corresponding to each function to ensure the overall system’s reliability.

On the other hand, in automotive electronic systems, different applications often have different requirements for real-time performance and functional safety levels. For instance, according to the ISO 26262 standard, automotive instrument systems and infotainment systems belong to different safety levels and have different processing priorities. The automotive instrument system is closely related to the power system, requiring high real-time performance, reliability, and safety, and must run on a low-level real-time operating system (e.g., QNX). In contrast, the infotainment system primarily provides a control platform for human-machine interaction within the vehicle, pursuing diverse applications and services, mainly using Linux and Android. To achieve mixed safety level applications, it is necessary to run different operating systems on the same system, which requires support from virtualization technology.

The core of in-vehicle hardware virtualization technology is the Hypervisor, which is middleware that runs between physical servers and operating systems, allowing multiple different operating systems and applications on different virtual machines to share a set of underlying physical hardware. When the system starts, the Hypervisor runs first, responsible for allocating appropriate memory, CPU, network, storage, and other hardware resources to each virtual machine (i.e., partitioning the hardware resources), and finally loads and starts all the virtual machines’ client operating systems.

To summarize the advantages of Hypervisor-based technology in one sentence: it provides the flexibility to host heterogeneous operating systems on the same hardware platform while ensuring high reliability and fault control mechanisms to guarantee security isolation between critical tasks, real-time applications, and general-purpose, untrusted applications, enabling the integration of vehicle computing units and resource sharing.

3.5 ISO 26262 Functional Safety

Functional safety is one of the critical elements in the automotive development process. With increasing system complexity, the risks from system failures and random hardware failures are also rising. The purpose of the ISO 26262 standard is to better regulate and standardize the management and requirements of functional safety throughout the automotive lifecycle, including: concept phase, system development, hardware development, software development, production and operational processes, and after-sales, with a particular focus on how to define and achieve functional safety objectives during the product design phase.

The automotive functional safety standard ISO 26262-5 2018 “Product Development: Hardware Level Appendix D” recommends safety technical measures for the diagnostic coverage of processor units, including dual-core lockstep, asymmetric redundancy, and coding calculations as three typical hardware redundancy techniques. In addition, hardware BIST, software-hardware self-test technologies, ECC, etc., are also common design measures to enhance processor safety characteristics.

Figure 2-6 Functional Safety Chip Design Technologies in ISO26262 Standard

Dual-core lockstep CPUs are a type of CPU redundancy technique that includes two identical processors in one chip, with one acting as the master core and the other as the slave core. They execute the same code and are strictly synchronized; the master can access system memory and output instructions, while the slave continuously executes instructions on the bus (i.e., instructions obtained by the master processor). The output generated by the slave, including address bits and data bits, is sent to a comparison logic module, which consists of a comparator circuit between the master and slave bus interfaces, checking the consistency of data, address, and control lines between them. If any bus values are inconsistent, a fault is detected in one of the CPUs, but it cannot be determined which CPU has failed.

This CPU architecture allows for CPU self-testing independent of application software, without needing to execute specialized instruction set tests. The actual running software instructions are compared at each clock cycle, only requiring testing of CPU resources used by the software. However, this architecture does not check memory and buses, necessitating additional detection methods to avoid common-mode failures between the two CPUs.

3.6 Network Offload Engine

Automotive networks will have multiple communication buses. The backbone network will inevitably be built on TSN Ethernet in the future, but communication between domain master processors and ECUs or sensors will still rely on traditional low-speed in-vehicle buses, such as CAN and FlexRay. The domain master processor, as the core of the domain controller, is the hub for communication between all ECUs and sensors. Therefore, relying on the CPU’s computing power to complete protocol conversion between different buses and handle network packet processing for cross-domain communication will occupy valuable CPU resources.

Thus, a network offload engine based on hardware for network protocol conversion processing is a crucial technology for the domain master processors in each domain (including the central gateway).

3.7 Security Engine

Connectivity is a significant trend in the development of automotive intelligence; future vehicles will certainly remain connected to the internet like today’s smartphones. Therefore, preventing unauthorized network access to protect vehicles from hacker attacks will become extremely important for future smart vehicles. Next-generation hardware security modules (HSM) are becoming one of the essential infrastructures for next-generation in-vehicle network communication.

HSM is essential for secure onboard communication (SecOC). It ensures the authenticity of received data and prevents attackers from bypassing relevant security interfaces to invade the in-vehicle network.

The hardware-based security module primarily addresses two issues:

1. Key leakage issue: If keys are stored in application code or data, they can easily be leaked. Therefore, it is necessary to add a hardware module specifically for key storage.

2. Crypto algorithm acceleration: Directly performing encryption or decryption operations through the core consumes significant CPU resources. Therefore, it is necessary to use hardware modules to accelerate encryption and decryption algorithms.

The SHE (Secure Hardware Extension) standard is a specification developed collaboratively by Audi and BMW for hardware security modules (HSM), mainly including the hardware of the cryptographic module and the hardware-software interface. This specification has been widely accepted, and many microprocessors for the automotive industry support it.

3.8 Service-Oriented Software Architecture (SOA)

The software running on ECUs was mostly developed according to the Classic AutoSAR specification, where application software generally follows a static scheduling model, meaning that different functional functions in the program are called and executed in a predefined order during system operation. The advantage of static scheduling is that resource allocation issues are predetermined and will not change after vehicle mass production; the execution time of function codes corresponding to each function is also locked in advance, making it deterministic. Therefore, this design is very suitable for many scenarios with stringent functional safety requirements in vehicles. For instance, the function that determines whether to deploy airbags runs at fixed intervals of a few milliseconds to ensure timely deployment in emergencies.

As the underlying hardware for computation and control shifts from dispersed multiple ECUs to multi-core, heterogeneous high-performance domain master processors, the corresponding software will also evolve from being dispersed to centralized, from simple to complex, and from static to dynamic. The following Figure 2-7 illustrates a typical software architecture based on spatial virtualization technology on future automotive domain controllers:

Figure 2-7 Typical Software Architecture Based on Spatial Virtualization Technology on Domain Controllers

• Operating System Layer: The lowest layer uses Hypervisor virtualization technology to partition hardware resources, allowing different operating systems to run on each virtual machine. For example, in the above figure, virtual machine VM1 runs a real-time operating system (RTOS) compatible with the POSIX real-time operating system standard (such as PSE 52), typically hosting applications and services related to functional safety; virtual machine VM2 runs Linux, a time-sharing operating system fully compliant with POSIX 1003.1 standard, usually operating management-related functions and services; virtual machine VM3 may run legacy applications that were previously on ECUs.

• Middleware Layer: The operating system does not perform any vehicle-specific tasks. To enable the domain master processor to be used in automotive scenarios, many software or middleware are needed to ensure that the domain controller meets automotive power management standards, network management standards, and diagnostic standards; in-vehicle domain controllers require higher reliability than general industrial embedded systems, necessitating additional security and fault tolerance mechanisms for storage and communication; furthermore, to enable the in-vehicle domain controller to operate within the overall vehicle EE architecture, features such as clock synchronization, log tracking, and service management and discovery must also be provided. The Adaptive AutoSAR specification defines middleware standards relevant to vehicles running on Linux or fully POSIX-compliant RTOS; while the traditional middleware standards for RTOS or BareMetal mode are defined by Classic AutoSAR standards.

• Application Layer: Upper-level applications are developed based on AutoSAR standard middleware. As automotive intelligence and connectivity features continue to increase, upper-level application software is becoming more complex. To reduce the overall complexity of individual applications, we can draw on the service-oriented architecture (SOA) software design philosophy from the internet, breaking down a complex application into multiple services. Each service should be as small as possible and ideally implement a stateless service to facilitate the overall system’s development, testing, and software reuse. Services communicate with each other through events or message buses (publish/subscribe model) to reduce coupling between them. Service configuration manages dependencies between services, service deployment and startup, as well as service health status detection, etc.

The automotive Ethernet brings revolutionary changes to in-vehicle system communication. Under the centralized computing automotive EE architecture, the entire in-vehicle system can be viewed as a distributed network system: the central computing platform is a small server cluster, while the regional computing platform serves as edge computing nodes. In the internet or large distributed systems, SOA architecture design concepts have been widely used. Therefore, when IP network technology is widely applied in automotive contexts, many mature software technologies from the internet or distributed computing will naturally be referenced in the new automotive software architecture design, such as RPC technology, event/message buses, RESTful API design, etc.

Server clusters in large internet data centers often consist of hundreds or thousands of servers, with concurrent requests reaching millions or tens of millions per second. Although the in-vehicle system can be viewed as a distributed network system, it does not exhibit the high concurrency characteristics of large internet server systems; instead, it emphasizes real-time communication and reliability.

Physically, the in-vehicle system is moving toward centralization, meaning that functions previously implemented through multiple dispersed ECUs are gradually centralized into several main high-performance domain controllers. Therefore, although we will strive to break down the software design into small services following the SOA approach, these services are actually centralized in deployment. Given this characteristic of “centralization” in physical deployment and “distribution” at runtime, we can utilize a series of technical means to optimize communication delays between services (e.g., through shared memory technology). This is another significant difference between in-vehicle distributed systems and internet systems that emphasize high concurrency.

04

Summary

The domain centralized EE architecture will dominate the automotive EE architecture for a considerable time in the future, with domain controllers as the core of this architecture playing an increasingly important role in the entire automotive industry chain. Corresponding chip and hardware solutions, operating systems, and algorithms will become focal points of competition among upstream and downstream manufacturers in the entire industry chain.

1.Accelerating Automotive Artificial Intelligence Incubation: We welcome partners in artificial intelligence entrepreneurship to participate. We will leverage manufacturer resources to provide support in consultation, brand promotion, funding, and product deployment.

2.We welcome angel round and A round companies from the entire automotive industry chain (including the power battery industry chain) to join the group (We will recommend to top 800 automotive investment institutions);We have communication groups for scientific and technological innovation company leaders, as well as dozens of groups for the automotive industry, including complete vehicles, automotive semiconductors, key components, new energy vehicles, intelligent connected vehicles, aftermarket, automotive investment, autonomous driving, and vehicle networking. Please scan the administrator’s WeChat to join the group (Please indicate your company name)