This article explores the roles of DCU, MCU, and MPU in the electronic and electrical architecture of autonomous driving, comparing the advantages of distributed and centralized architectures, as well as the development history of ADAS systems from L0 to L2+. It focuses on the differences between MCU and MPU, and their key roles in the trend of automotive intelligence and connectivity.
DCU, MCU, MPU in Autonomous Driving
1. Distributed Electronic and Electrical Architecture
2. Domain-Centralized Electronic and Electrical Architecture
2.1 General Hardware Definition
3. Vehicle-Centralized Electronic and Electrical Architecture
4. Evolution of ADAS/AD System Solutions
4.1 ADAS Solutions at L0-L2 Levels
4.2 ADAS Solutions Above L2 Level
5. Differences Between MCU and MPU
5.1 Differences Between MCU and MPU
5.2 Differences Between CPU and SoC
What is a Domain Controller (DCU), and what impact does it have on the future electronic architecture of vehicles?
Autonomous Driving Domain Controller
DCU: Domain Controller Unit
MCU: Micro Controller Unit
MPU: Micro Processor Unit
In recent years, the concept of SDV (Software Defined Vehicles) has gradually been recognized by automakers, stemming from the evolution of the question of how cars can reflect differentiation. With the innovation of automotive electronic architecture brought by electrification, the hardware systems of vehicles will gradually converge, making the construction of generalized hardware the prerequisite for realizing software-defined vehicles. Only by generalizing hardware and reducing differentiation can the cost of software adaptation be minimized, achieving true software-defined vehicles.
The following diagram is a strategic map shared by Bosch at an automotive conference in 2017 regarding the electronic and electrical architecture of vehicles. The development of vehicle electronic and electrical architecture is divided into six stages: modular stage -> functional integration stage -> central domain controller stage -> cross-domain integration stage -> on-board central computer and regional controller -> on-board cloud computing stage.
1. Distributed Electronic and Electrical Architecture
The development of automotive intelligence and informatization over the past decade has resulted in a significant increase in the use of ECU chips. From traditional engine control systems, airbags, anti-lock systems, electric power steering, and body electronic stability systems; to intelligent dashboards, entertainment systems, and driver assistance systems; as well as electric vehicle drive control, battery management systems, on-board charging systems, and the rapidly growing on-board gateways, T-BOX, and autonomous driving systems.
The traditional automotive electronic and electrical architecture is distributed, where various ECUs in the car are connected via CAN and LIN buses. The total number of ECUs in modern vehicles has rapidly increased to dozens or even hundreds, leading to increasing complexity in the entire system, nearing its limits. In today’s trends of software-defined vehicles and the intelligence and connectivity of cars, this ECU-based distributed EEA is increasingly exposing many problems and challenges.
2. Domain-Centralized Electronic and Electrical Architecture
To address these issues with distributed EEA, there has been a gradual integration of many functionally similar, separated ECU functionalities into a more powerful processor hardware platform than ECUs, which is the automotive domain controller. The emergence of domain controllers marks an important transition from ECU-based distributed EEA to domain-centralized EEA.
The domain controller is the core of each functional domain in the vehicle, primarily consisting of a domain master processor, an operating system, and application software and algorithms. Platformization, high integration, high performance, and good compatibility are the main core design concepts of the domain controller. Leveraging high-performance domain master processors, rich hardware interface resources, and powerful software functionalities, domain controllers can integrate core functionalities that originally required many ECUs, significantly improving system functionality integration, and with standardized interfaces for data interaction, can greatly reduce development and manufacturing costs.
Regarding the specific division of functional domains, each automaker will categorize them based on their design philosophies. For example, Bosch divides them into five domains: Power Train (safety), Chassis (vehicle dynamics), Body (body electronics), Cockpit/Infotainment (entertainment information), and Autonomous Driving (ADAS, driver assistance).
Systems within each domain are interconnected using commonly used CAN and FlexRay communication buses. Communication between different domains is handled by Ethernet, which has higher transmission performance, serving as the backbone network for information exchange. In each functional domain, the domain controller occupies a critical position, requiring powerful processing power, ultra-high real-time performance, and numerous communication peripherals to support the corresponding domain’s functionalities. The domain controller provides a solid foundation for building a new generation of universal, high-computing, high-bandwidth, high-security, and reconfigurable automotive electronic and electrical architecture, supporting the technological and industrial development of intelligent electric vehicles.
2.1 General Hardware Definition
General requirements for domain controllers:
Related functionalities are concentrated, integrating MPU/MCU to meet the computational and functional safety requirements within the domain;
Standardized software interfaces, such as AUTOSAR, are integrated;
Communication interfaces are provided to connect directly with the vehicle’s main network, while interacting with domain actuators or sensors via secondary communication buses, bus types: vehicle Ethernet (TSN), CAN, LIN, FlexRay…
Currently, mainstream automakers and component manufacturers are advancing research and commercialization of domain controllers based on power, chassis, body, cockpit, and autonomous driving.
For an introduction to the various domain controllers, see the article: What is a Domain Controller (DCU), and what impact does it have on the future electronic architecture of vehicles?
3. Vehicle-Centralized Electronic and Electrical Architecture
4. Evolution of ADAS/AD System Solutions
4.1 ADAS Solutions at L0-L2 Levels
Most early ADAS systems at L0-L2 levels were based on distributed controller architectures, composed of 4-5 ADAS subsystems, where each subsystem typically functions as an all-in-one solution (considered a smart sensor), with each subsystem independently configured with its own sensors.
For example, in the Intelligent Front Camera Module (FCM), the entire subsystem ECU board contains two chips: one is the safety core; the other is the performance core. The safety core is generally represented by MCUs such as Infineon’s TC297/397, which handle control tasks and thus require a high level of functional safety; the performance core is typically a multi-core heterogeneous MPU with higher performance computing power, handling a large number of computational tasks.
Below is a summary of L0-L2 level solutions:
L0 Level Solution: Implements various ADAS warning functions, such as FCW, LDW, BSW, LCA, etc. It is a distributed architecture, usually composed of major hardware modules like FCM, FCR, SRRs, AVS, APA, etc.
L1 Level Solution: Completes various ADAS longitudinal and lateral control functions, such as ACC, AEB, LKA, etc. It is also a distributed architecture, with hardware modules similar to those in the L0 level solution.
L2 Level Solution: Completes ADAS longitudinal + lateral combined control functions. For instance, based on the FCM+FCR fusion system, it integrates forward visual perception and forward radar target perception information to achieve functions like TJA/ICA; or based on the AVS+APA fusion system, it achieves automatic parking functions.
4.2 ADAS Solutions Above L2 Level
Distributed architecture ADAS systems have two fatal drawbacks:
Each subsystem operates independently, preventing deep fusion between multiple sensors.
Each subsystem monopolizes its configured sensors, thus failing to achieve complex functionalities across multiple subsystems.
As the vehicle’s EE architecture evolves into a domain-centralized EEA, the ADAS domain controller is equipped with a higher integration and performance computing processor platform, further supporting more complex sensor data fusion algorithms to realize higher-level ADAS functionalities, such as HWP, AVP, etc.
The centralized ADAS domain controller solution has transitioned from the earliest four-chip solution, to a three-chip solution, and now to the current mainstream two-chip solution, as shown in the diagram below:
5. Differences Between MCU and MPU
MPU stands for Micro Processor Unit, while MCU stands for Micro Controller Unit. The fact that both terms begin with ‘Micro’ indicates that these are technologies that emerged from the miniaturization of computing/control units. This is essentially a result of advancements in integrated circuits, leading to a higher level of integration in computer systems. It has transitioned from having multiple discrete components to a highly integrated development, where the functionalities of multiple chips/components concentrate into one chip. This is a significant technological evolution. The core difference is actually between Control and Process.
However, during the technological evolution, two different demands emerged. These two demands are the two modes of “soft control of hardware” and “hardware assisting software”.
Soft control of hardware refers to controlling hardware through running a piece of software/program, also known as program control. In this usage mode, the computer system does not bear the main workload but primarily plays an auxiliary/coordinating/control role.
Thus, in this case, the integrated computer system does not require powerful computing/processing capabilities. Therefore, the corresponding form should be one with low operating frequency, average computing ability, but high integration (convenient to use), and low cost (the auxiliary system should not significantly increase costs).
Since it mainly completes tasks related to “control”, it is referred to as a Controller. This means that based on external signals (stimuli), it generates some responses and performs simple human-machine interface tasks. For this kind of demand, there is no need for the chip’s main frequency to be too high. Early 8051 series chips operated at only a few MHz, executing one instruction every 12 cycles. After years of modifications, they finally reached 100MHz. Additionally, processing power does not need to be too strong; 8-bit MCUs have long been the mainstream of microcontrollers. Later, 16-bit MCUs gradually began to dominate the market. With the emergence of ARM-based 32-bit MCUs, the ARM M-series MCUs have also started to expand their market share, with ST and NXP’s products being major representatives. However, these ARM series MCUs generally operate at frequencies ranging from several tens to over 100MHz. Moreover, since the tasks executed are “control-related”, they usually do not require support for complex graphical interfaces and processing capabilities. Most tasks completed on MCUs are simple stimulus-response tasks, and the task types are usually singular, with a simple task execution process. In this case, there is generally no need for MCUs to execute complex, computationally intensive programs, nor do they typically need to run large operating systems to support complex multi-task management. This leads to MCUs generally having lower memory capacity requirements.
On the other hand, a Processor, as the name implies, is a device that can execute processing functions. In fact, many devices are equipped with the term Processor. For example, a CPU is referred to as a “central processing unit”; if there is a “central”, there should be “peripheral” devices. A GPU in a classic desktop computer is a typical “peripheral” processor, mainly responsible for graphics processing, due to the display of graphics and images. Of course, today, due to the rise of AI, GPUs have transformed into powerful training tools for artificial intelligence. Other processors with ‘P’ include DSP, digital signal processors, which are specifically designed for digital signal processing. Therefore, these processors with ‘P’ all need to possess processing capabilities. What do they process? Naturally, they process data/information. This means that processors themselves need to have strong data processing/computing capabilities. For example, a GPU’s powerful parallel floating-point computation capability allows for high-speed image processing, enabling audio and video playback and multimedia technologies. Similarly, this processing capability has allowed GPUs to play a significant role in the AI era.
The core message about processors is straightforward: processors must have strong processing/computing capabilities to execute relatively complex tasks. A microprocessor is essentially a miniaturized/integrated version of a processor. More accurately, it is a miniaturized/integrated central processing unit (CPU). This means that in addition to the traditional CPU, it integrates various interfaces and some “peripherals” that originally belonged to the “chipset”. The MPU has always been positioned with considerable processing and computing capabilities, designed to run relatively large operating systems to achieve complex task processing. Therefore, this determines that MPUs should have relatively high main frequencies and strong computing capabilities. MPUs have long evolved into 32-bit processors, and they are now increasingly adopting 64-bit architectures. The leading company in the MPU market, Arm, initially aimed to develop 32-bit processors. Additionally, MPUs have consistently pursued achieving high main frequencies. The early classic Arm9 series MPUs operated at frequencies between 200MHz and 400MHz. Now, high-end MPUs used in mobile phones have reached up to 3GHz, comparable to mainstream desktop processors. Like general desktop processors, MPUs are now also commonly “multi-core”.
To support the powerful computing capabilities of the MPU and make full use of its potential, it is necessary to run relatively complex and computationally intensive programs and tasks on the MPU, which typically requires large-capacity memory to support it. Since large-capacity memory is difficult to integrate into the logic-function-oriented MPU, it usually requires “external” large-capacity memory. This primarily includes large-capacity DDR memory and FLASH. In the mobile phone domain, the former is referred to as “operating memory”, while the latter is referred to as “internal memory”. To support the operation of complex operating systems and large programs, MPUs often require high-performance memory controllers, memory management units (MMUs), and a complete set of complex storage mechanisms and hardware.
Therefore, in terms of form, MPUs generally require external memory to run complex programs due to their need to execute tasks that demand high processing capabilities. In contrast, MCUs typically only perform simple stimulus-response process controls and auxiliary functions, which are relatively singular and only require small integrated memory on-chip to achieve system “monolithic integration”.
In summary, the differences between MPU and MCU fundamentally arise from their application positioning, optimized in different ways to meet different application scenarios. MPUs focus on executing complex and diverse large programs through relatively powerful computing/processing capabilities, usually requiring external large-capacity memory. In contrast, MCUs typically run relatively singular tasks, managing/control functions for hardware devices. They usually do not require strong computing/processing capabilities, and therefore do not need large-capacity memory to support running large programs. They typically achieve system “monolithic integration” by integrating small-capacity memory within a single chip.
However, it should be noted that as technology continues to evolve, the product forms mentioned above will also undergo a series of changes and derivatives. NXP has already begun to introduce MCUs with main frequencies of 1GHz, equipped with powerful computing capabilities. With the advancements in 3D packaging and Chiplet technology, the integration of large-capacity memory in advanced packaging is also being realized. Thus, these technical terms should ultimately be understood based on their reasons for emergence, rather than simply explained through some forms or architectures. It is even more inappropriate to mechanically impose meaningless “definitions” and have students answer them during exams.
5.1 Differences Between MCU and MPU
MCUs integrate an entire computer system on a single chip, allowing it to run code with just simple peripheral components (resistors, capacitors). It is essentially still a complete microcontroller, with a processor, various interfaces, and all development based on an already existing system architecture, where the user simply needs to develop software programs and add external devices.
MPUs, such as ARM’s Cortex-A series, cannot run code directly because they are essentially enhanced CPUs and must include corresponding RAM and ROM.
5.2 Differences Between CPU and SoC
SoC can be seen as a combination of the integration advantages of MCUs and the strong processing capabilities of MPUs, where MCUs integrate various peripherals while MPUs are enhanced CPUs. Currently, the development direction of chips is transitioning from CPU to SoC, and there are no longer purely CPUs; they are all SoCs.
The above image shows the autonomous driving domain controller based on J5, which includes one MCU and two SoCs: J5 and X9, where J5 contains an octa-core Arm Cortex-A55 MPU.
Source: Intelligent Vehicle Industry Database
Angel Round and A Round Enterprises in the Automotive Industry Chain (including the power battery industry chain) are invited to join (to be recommended to over 1,000 automotive investors including top institutions); there are communication groups for leading technology companies, and dozens of groups related to the automotive industry including complete vehicles, automotive semiconductors, key components, new energy vehicles, smart connected vehicles, aftermarket, automotive investment, autonomous driving, and vehicle networking, please scan the administrator’s WeChat to join (please indicate your company name).
