Previous Issues
In-Vehicle Operating Systems (Part 1): Software-Defined Vehicles
In-Vehicle Operating Systems (Part 2): Vehicle Control Operating Systems
In-Vehicle Operating Systems (Part 3): Intelligent Cockpit Operating Systems
In-Vehicle Operating Systems (Part 4): Domestic and International In-Vehicle OS Layouts
In-Vehicle Operating Systems (Part 5): AUTOSAR Standards
Introduction
The intelligent connectivity of vehicles has led to a significant increase in information flow, prompting an upgrade in the electronic and electrical (E/E) architecture of automobiles. This evolution mirrors the changes in the organizational structure of ancient Chinese society, transitioning from feudal states to the hegemony of the Spring and Autumn period, and finally to a unified empire. Similarly, the automotive architecture is evolving from distributed to domain centralized to central computing. Currently, it is in the transitional phase from distributed to domain centralized, reducing the number of ECUs from over 100 to 5 DCUs, with control functions rapidly centralizing. The domain controller, acting as the “decision-making center of local factions,” is stepping onto the historical stage.
01Why Introduce Domain Controllers?
In the 1980s, with the rise of IT technology, the automotive industry, which was predominantly mechanical at the time, experienced an electronic and electrical revolution. The young automotive electronic systems developed rapidly, with Electronic Control Units (ECUs) taking over the entire vehicle, from Anti-lock Braking Systems, Four-Wheel Drive Systems, Electronic Automatic Transmissions, Active Suspension Systems, to Airbag Systems, gradually extending to body safety, networking, entertainment, and sensor control systems, becoming an essential part of automobiles.
At that time, the automotive electronic and electrical architecture was distributed, with each ECU connected via CAN (Controller Area Network) or LIN (Local Interconnect Network) buses, exchanging information through pre-defined communication protocols set by engineers.
According to Strategy Analytics, the number of ECUs at all levels is increasing year by year, with an average of 25 ECUs per vehicle, and in some high-end models, this number often exceeds 100. The more ECUs there are, the longer the bus length must be. In 2000, the Mercedes-Benz S-Class had 80 ECUs and 1,900 communication lines totaling 4 km. By 2007, the bus length of the Audi Q7 and Porsche Cayenne exceeded 6 km, weighing over 70 kg, making it the second heaviest component in the vehicle after the engine.
To control bus length, reduce the number of ECUs (or maintain the same number), thereby reducing the weight of electronic components and lowering overall manufacturing costs, small distributed sensors are gradually being integrated into more powerful single sensors. The idea of categorizing and integrating distributed controllers into domain controllers (Domain Control Units, DCUs) based on functional domains has emerged.
In addition, in recent years, with the rapid development of ADAS (Advanced Driver Assistance Systems), including parking assistance, lane departure warning, night vision assistance, adaptive cruise control, collision avoidance, blind spot detection, and driver fatigue detection, many functions cannot be accommodated by a distributed architecture. This is because ADAS systems involve various sensors (such as cameras, millimeter-wave radars, and LiDAR), generating a large amount of data. Each sensor module can preprocess data and transmit it via in-vehicle Ethernet. To ensure optimal data processing results, it is best to concentrate all functional controls in a core processor, which creates a demand for domain controllers.
02What is a Domain Controller?
The concept of domain controllers was first proposed by Tier 1 suppliers such as Bosch and Continental to address information security and ECU bottleneck issues. Domain controllers, with their powerful hardware computing capabilities and rich software interface support, allow more core functional modules to be centralized within the domain controller, significantly improving system function integration. This reduces the hardware requirements for function perception and execution. Additionally, the standardization of data exchange interfaces transforms these components into standard parts, thereby lowering the development/manufacturing costs of these components. In other words, peripheral components focus only on their basic functions, while the central domain controller focuses on system-level function implementation.
The term “domain” refers to dividing the automotive electronic system into several functional blocks based on functionality, with each block’s internal system architecture led by the domain controller. It utilizes more powerful multi-core CPU/GPU chips to relatively centralize control of each domain, replacing the current distributed electronic and electrical architecture. The internal systems of each domain can still use the commonly used CAN and FlexRay communication buses, while communication between different domains requires a higher-performance Ethernet as the backbone network for information exchange.
For the specific division of functional domains, different automakers have their design philosophies. For example, Bosch divides into 5 domains: power domain, chassis domain, cockpit domain, autonomous driving domain, and body domain, while Volkswagen’s MEB platform models have 3 domains: autonomous driving domain, intelligent cockpit domain, and body control domain, and Huawei also has 3 domains: autonomous driving domain, intelligent cockpit domain, and vehicle control domain.
The following diagram illustrates a possible division method. In each functional domain, the domain controller is at the absolute center, requiring powerful computing capabilities, ultra-high real-time performance, and numerous communication peripherals.
03Internal Architecture of Domain Controllers
Most mass-produced automotive electronic controllers today use static driving systems developed based on AUTOSAR or OSEK. During the operation of the software system, different functional functions are called and executed sequentially according to pre-defined scheduling files. The advantage of static driving systems is that resource allocation issues are resolved in advance, and the specific operating intervals of each function are locked in advance. This design meets the stringent operational requirements for certain safety-critical functions, such as the function that determines whether the airbag should deploy, which is fixed to run every few milliseconds to ensure timely deployment in emergencies.
However, in conjunction with multi-core processors, for those functional functions that do not have high timing requirements, dynamic driving systems have many advantages. For example, they are more suitable for service-oriented functional functions, allowing for easy software upgrades and providing possibilities for online optimization of function execution order. To address this need, AUTOSAR has proposed a solution called Adaptive AUTOSAR, which encompasses the advantages of dynamic driving systems while providing interfaces for traditional AUTOSAR (Classic AUTOSAR).
As shown in the diagram, the entire architecture is based on a POSIX-OS with a Linux kernel, which can run directly in multi-core systems or independently in an additional Hypervisor virtualization environment. Numerous software packages from automakers and different suppliers constitute functional blocks such as diagnostic services, safety measures, and communication services, integrated within the Adaptive-AUTOSAR working group. All software communicates through a Service Broker and provides interfaces for traditional AUTOSAR software.
04Advantages of Domain Controller Architecture
The domain controller is based on Ethernet as the backbone network, with a service-oriented architecture that accelerates the separation of hardware and software by functional division, saving overall costs. Specific advantages include:
-
Enhanced Service Value. With the implementation of OTA (Over-The-Air) functionality, automakers can continuously improve vehicle functions through system upgrades, allowing software to partially fulfill the role of traditional 4S dealerships, providing ongoing operation and service after vehicle delivery. Traditional automotive products begin to depreciate upon delivery, but software OTA gives vehicles more longevity and enhances user experience. For example, since the launch of the Model S in 2012, Tesla’s software system has undergone multiple major updates, averaging small updates every few months, adding and improving over 50 functions, including automated driving assistance, battery preconditioning, and automatic parking.
-
Centralized Computing Power. This can truly achieve hardware standardization and software development reuse, enabling supplier interchangeability and significantly shortening software iteration cycles, while clearing obstacles for future third-party software development. Vehicles will become mobile intelligent terminals, with a large amount of computing work centralized in the vehicle’s central processor or even in the cloud, reducing internal redundancy and enabling vehicle networking collaboration.
-
Simplified Internal Structure. In-vehicle Ethernet is beginning to replace the CAN bus structure, and semiconductor integration allows automakers to streamline internal wiring structures. For example, the internal wiring length of the Model S is 3 km, while the Model 3 is only 1.5 km, and the Model Y plans to control the wiring length to 100 m.
05Transformation of Future Business Models
As the automotive E/E architecture evolves from distributed to domain centralized, the supply relationships between automakers and automotive electronic suppliers are undergoing profound changes, with the number of automotive electronic suppliers gradually decreasing and the status of DCU suppliers becoming increasingly important.
Taking the intelligent cockpit domain controller as an example, it typically integrates the instrument panel and vehicle machine, and in the future, it will gradually integrate air conditioning control, HUD (Head-Up Display), rearview mirrors, gesture recognition, DMS (Driver Monitoring System), and even T-BOX (Telematics BOX) and OBU (On-Board Unit).
Therefore, the development cooperation between domain controller manufacturers and automakers will become closer. In the future, in the field of autonomous driving domain controllers, it is expected that Tier 1 suppliers will adopt two cooperation methods with automakers.
-
Tier 1 is responsible for the intermediate layer and hardware production, while the automaker 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 automakers and Tier 1 for production inevitable, with the former responsible for the autonomous driving software part and the latter for hardware production, intermediate layers, and chip solution integration.
-
Tier 1 collaborates with chip manufacturers to achieve solution integration, then develops central domain controllers and sells them to automakers, such as Continental’s ADCU (ADAS Domain Controller Unit), ZF’s ProAI, and Magna’s MAX4.
06Market Potential for Domain Controllers
According to predictions from automotive and new energy industry consulting firm Zosi Research, global shipments of automotive domain controllers (cockpit + autonomous driving) will exceed 14 million units by 2025, with an average growth rate of 50.7% from 2019 to 2025.
07Future Electronic Architecture of Automobiles
With the introduction of domain controllers, software will be reclassified and integrated according to corresponding functional domains. The future automotive electronic system will increasingly focus on the driver and be service-oriented. In-vehicle entertainment systems, human-vehicle interaction systems, and vehicle networking systems will play increasingly important roles, and their code volume will inevitably increase. To cope with this system transformation, it is necessary to strip the corresponding software systems from the distributed ECUs and re-integrate them into the corresponding DCUs.
The following diagram illustrates a possible future automotive electronic system architecture. The upper left corner features a driver-oriented domain controller, primarily responsible for human-machine interaction functions with the driver. It is separated from traditional controllers such as the power system and communicates with other domain controllers through a central gateway and Ethernet.
Through smart antennas and mobile networks, real-time connectivity between the in-vehicle electronic system and the automaker’s backend becomes possible. For users, real-time connectivity with the cloud backend will significantly increase the amount of data the vehicle can receive, providing more in-vehicle services for the driver. For example, environmental perception while driving or information collection about available parking spaces can be accomplished not only through in-vehicle sensors but also through real-time access to cloud backend databases.
Additionally, information about the usage of mechanical wear parts, electronic system hardware and software error reports can also be transmitted to the cloud in real-time. This means that services such as error diagnosis reading will not require customers to take their vehicles to 4S dealerships but can be read directly through the cloud. This provides a big data foundation for automotive engineers to improve and develop the next generation of vehicles. The well-known OTA will also benefit from this architecture becoming more widespread. At the same time, the open automotive software architecture will provide users with the possibility of installing personalized software applications. Customer-facing automotive software systems will offer increasingly flexible and diverse user experiences, similar to smartphones.