07/07 2025
402
The autonomous driving domain controller, serving as the "brain" and "neural hub" of modern intelligent connected vehicles, stands as a vital cornerstone for achieving advanced autonomous driving capabilities. Leveraging its centralized computing architecture and domain-specific partitioning, it has revolutionized the traditional distributed multi-ECU automotive electronic and electrical (E/E) system. This innovation ensures efficient perception, real-time decision-making, and precise execution in autonomous driving scenarios.
Since the turn of the century, the rise of automotive electrification and intelligence has led to a surge in onboard ECUs, sometimes reaching into the dozens or even hundreds. This decentralized design posed challenges such as complex wiring, limited communication bandwidth, high system coupling, and steep software maintenance costs. In the era of autonomous driving, vehicles must process multimodal sensor data from cameras, millimeter-wave radars, LiDARs, ultrasonic sensors, etc., while meeting real-time demands for environmental modeling and behavioral decision-making. These requirements rendered the traditional architecture insufficient. Consequently, the industry has embraced the centralization and domain control of E/E architectures, logically segmenting and centrally managing ECUs based on "perception domain," "autonomous driving domain," "power domain," "chassis domain," "body domain," and "cockpit domain," interconnecting them via high-speed Ethernet. At the heart of this transformation lies the autonomous driving domain controller, responsible for perception, positioning, decision-making, and execution. By consolidating substantial heterogeneous computing power and uniformly orchestrating various algorithm modules, it significantly enhances the system's real-time performance and maintainability.
The autonomous driving domain controller supports intricate autonomous driving tasks through its highly integrated heterogeneous multi-core architecture. Leading domain control platforms employ high-performance SoC chips like NVIDIA DRIVE, Mobileye EyeQ, Horizon Journey, and Cambricon AutoAI, which internally integrate CPUs, GPUs, NPUs (Neural Processing Units), and programmable FPGAs for parallel processing of perception algorithms, deep learning inference, and decision planning. To accommodate the high data throughput demands of sensors—ranging from hundreds of MB to several GB per second—the domain controller is equipped with multiple high-speed interfaces such as 10Gbps Ethernet, PCIe, USB3.1, and CAN-FD. Furthermore, differential signal transmission, isolated power supplies, and common-mode filtering are implemented at the physical level to ensure signal integrity and electromagnetic compatibility. Adhering to the AEC-Q100 automotive-grade semiconductor standard, the domain controller supports ISO 26262 ASIL-D level functional safety and ISO 21434 cybersecurity requirements. To bolster stability and reliability under harsh conditions like extreme temperatures, vibrations, and voltage fluctuations, the hardware incorporates multi-level watchdogs, power redundancy, hardware isolation zones, and hardware security modules (HSM).
Addressing power consumption exceeding 50W, domain controllers typically adopt liquid cooling or efficient air cooling solutions, complemented by thermal silicone gel, heat dissipation copper pillars, and large heat sinks, to efficiently dissipate heat outside the vehicle body.
The autonomous driving domain controller must balance real-time tasks with complex application ecosystems. To meet millisecond-level execution of perception and control algorithms, alongside OTA (Over-the-Air) upgrades, cloud collaboration, and human-machine interaction, the domain controller typically runs an RTOS (Real-Time Operating System) alongside a securely isolated Linux/ROS2 or AUTOSAR Adaptive environment. Hypervisor or containerization technologies (Docker/Kubernetes) are widely used to achieve multi-tenant isolation of the operating system and ensure deterministic execution of critical tasks. The software architecture comprises three modules: perception, decision planning, and execution control. The perception module calibrates, spatially and temporally aligns, and initially fuses multi-source sensor data, utilizing Kalman filtering, graph optimization, and convolutional neural networks to construct high-precision environmental models. The decision planning layer generates safe and comfortable trajectory and speed planning in real-time, leveraging high-precision maps and centimeter-level positioning results, through behavior trees, finite state machines, or reinforcement learning algorithms. The execution control layer converts planning results into control instructions and sends them to the chassis execution units via MPC (Model Predictive Control) or PID algorithms, executing steering, braking, acceleration, and other operations. Additionally, the software platform implements comprehensive security measures such as Secure Boot, signature verification, firmware integrity checking, and network intrusion detection (IDS/IPS) to ensure the system can gracefully degrade or swiftly switch to safe mode in response to malicious attacks or software failures.
The autonomous driving domain controller is not a standalone computing node but realizes modular management and horizontal expansion of vehicle functions through the concept of "domains." The perception domain controller handles raw data preprocessing and initial fusion from multiple sensors; the autonomous driving domain controller undertakes environmental modeling, path planning, and decision execution; the body domain controller manages auxiliary functions like doors, lights, and wipers; the cockpit domain controller interfaces with human-machine interaction and infotainment systems; and the power domain controller and chassis domain controller control the power system and chassis subsystems like steering and braking, respectively. Each domain controller differs significantly in computing power, interface specifications, security levels, and software ecosystems, tailored to meet the diverse requirements of real-time performance, bandwidth, and security for their respective tasks.
Domain controllers can also be classified based on the evolution stage of the vehicle's E/E architecture: distributed domain architecture, domain-specific centralized architecture, and centralized architecture. In the distributed domain architecture, functions are domain-divided, but each domain comprises multiple distributed ECUs communicating via low-bandwidth buses (e.g., CAN, FlexRay). The domain-specific centralized architecture integrates multiple ECUs within a domain into a single domain controller, interconnecting with other domains via in-vehicle Ethernet. The centralized architecture further consolidates all domain functions into one or a few central compute units (Central Compute), forming a unified software-defined automotive platform. While the centralized architecture simplifies wiring and boosts efficiency, it demands higher central computing power and security isolation.
From a deployment perspective, domain controllers are divided into front-mounted, rear-mounted, and body central domain controllers. Front-mounted domain controllers are positioned near sensors like cameras and radars to minimize wire length and signal loss. Rear-mounted domain controllers are deployed in the rear cabin or trunk, often handling body or power domain tasks. The body central domain controller (or domain gateway) sits at the core of the vehicle network, facilitating data exchange, load scheduling, and security isolation between domains.
Another crucial aspect of autonomous driving domain controllers is the safety integrity level (ASIL). Autonomous driving domain controllers often require the highest ASIL-D level due to the potential threat their decision failures pose to vehicle safety. Conversely, body or cockpit domain controllers may only need to meet ASIL-B, ASIL-C, or even QM (Quality Management) levels, depending on the safety impact of their functions. This classification directly influences the design of hardware redundancy solutions, software development processes, and verification and testing protocols.
In terms of computing power platforms and chip ecosystems, domain controllers are categorized into general-purpose GPU/CPU/FPGA open platforms and dedicated ASIC/NPU customized platforms. The former, exemplified by NVIDIA DRIVE and Intel Mobileye EyeQ, offer mature ecosystems and high flexibility. The latter, such as Tesla's self-developed FSD computer, Horizon's "Journey" series, and Cambricon AutoAI chips, excel in power consumption optimization and performance customization. Both have trade-offs regarding mass production and R&D investment.
From an industrial chain perspective, domain controllers can be classified into OEM self-research models, Tier 1 solutions, and Tier 2/3 supplier supporting models. OEM self-research enables deep customization of software and hardware but demands significant R&D investment and organizational collaboration. Tier 1 solutions boast mature supply chains and mass production capabilities. Tier 2/3 suppliers often specialize in key components or software modules of domain controllers, providing technical services for overall solutions.
In summary, the autonomous driving domain controller addresses the multifaceted demands of the autonomous driving system for high-bandwidth data processing, real-time decision-making, and safety and reliability through its centralized computing architecture and domain partitioning concept. Its diverse classifications based on function, architecture level, deployment method, safety level, computing power platform, and industrial chain role offer flexible and customizable technical pathways for various automakers and application scenarios. As software-defined vehicles and vehicle-road coordination advance, domain controllers will emerge as the core hub of intelligent connected vehicles, steering the industry towards a new era of safer, more efficient, and intelligent travel.
-- END --