What is a domain controller
A significant result of the development of automotive intelligence and informatization in the past decade or so is the increasing use of ECU chips. From the traditional engine control system, airbag, anti-lock braking system, electric power steering, body electronic stability system; to intelligent instruments, entertainment audio-visual systems, assisted driving systems; as well as electric drive control on electric vehicles, battery management systems, in-vehicle charging systems, as well as the booming in-vehicle gateways, T-BOX and automatic driving systems.
The traditional automotive electrical and electronic architecture is distributed (Figure 2-1 below), the various ECUs in the car are connected together through CAN and LIN buses, the total number of ECUs in modern cars has rapidly increased to dozens or even hundreds of them, and the complexity of the entire system is getting larger and larger, almost the upper limit. Under today's software-defined car and the development trend of intelligent and networked vehicles, this ECU-based distributed EEA is also increasingly exposing many problems and challenges.
Automotive Distributed EEA
In order to solve these problems in distributed EEA, people began to integrate many similar and separate ECU functions into a processor hardware platform with stronger performance than ECU, which is the automotive "Domain Control Unit (DCU)". The advent of domain controllers is an important sign of the evolution of automotive EE architectures from ECU distributed EE architectures to domain-centralized EE architectures (as shown in Figure 2-2).
The domain controller is the core of each functional domain of the car, which is mainly composed of three parts: the domain master processor, the operating system and the application software and algorithms. Platforming, high integration, high performance, and good compatibility are the main core design ideas of domain controllers. Relying on the high-performance domain master processor, rich hardware interface resources and powerful software features, the domain controller can integrate the core functions that originally need to be implemented by many ECUs, greatly improving the integration of system functions, coupled with the standardized interface of data interaction, so it can greatly reduce the development and manufacturing costs of this part.
For the specific division of the functional domain, each automobile OEM manufacturer will be divided into several different domains according to its own design concept differences. For example, BOSCH is divided into 5 domains: Power Train, Chassis, Body/Comfort, Cockpit/Infotainment, and Autonomous Driving (ADAS). This is the most classic five-domain centralized EEA, as shown in Figure 2-2 below. Some manufacturers further integrate on the basis of the five-domain centralized architecture, and integrate the original power domain, chassis domain and body domain into the vehicle control domain, thus forming a three-domain centralized EEA, that is, the vehicle control domain controller (VDC, Vehicle Domain Controller), intelligent driving domain controller (ADC, ADAS\AD Domain Controller), and intelligent cockpit domain controller (CDC, Cockpit Domain). Controller）。 Volkswagen's MEB platform and Huawei's CC architecture belong to this three-domain centralized EEA.
Domain centralized EE architecture
Domain Controllers Market Overview
In 2018, based on the domain controller technology provided by Delphi, the zFAS controller developed by the Austrian company TTTech was the first to be used in the Audi A8. Visteon introduced smartCore domain controllers that integrate infotainment, dashboards, display, HUDs, ADAS, and more. These products have pioneered commercially available domain controller products, followed by major Tier 1 vendors around the world, and the entire domain controller market has gradually developed.
In the domestic market, Huawei, Desay SV, Hangsheng Electronics, Neusoft and other enterprises have also launched DCU solutions, which have been adopted by domestic car companies. For example, the smart coupe P7 launched by Xiaopeng Motors in 2020 adopts IPU03, an autonomous driving domain controller product built by Desay SV based on NVIDIA Xavier.
At present, the entire industry has very optimistic expectations for the DCU market. According to the forecast of Zoss Production research institute, the global shipment of automobile DCU (cockpit + autonomous driving) will exceed 14 million units in 2025, with an average annual growth rate of 50.7% in 2019-2025.
Global Domain Controllers Market Forecast
The entire automotive industry generally believes that domain controllers are the part with the highest competitive threshold in the future of the automotive electronics industry, so the profits are also the highest, and chip manufacturers and core algorithm suppliers will benefit.
(1) The driving factors behind the rapid growth of the domain controller market
More and better ADAS functions and smart cockpit and infotainment functions have been the main factors driving the rapid growth of the domain controller market, and these new features can significantly improve the sense of technology and user experience of the whole vehicle, so they are also the focus of OEMs when developing new models. ADAS applications between L1 and L2+ levels have developed very rapidly in recent years, and many functions are rapidly becoming popular, such as: parking assistance, lane departure warning, adaptive cruise, collision avoidance, blind spot detection, driver fatigue detection, etc.
Domain controllers need a more powerful and integrated master processor as their brain, and more functions originally achieved by separating ECUs can now be implemented on domain master processors, which can save more ECU usage and other hardware resources required in the functional domain. A higher degree of integration can achieve more OEM supply chain management to achieve ADAS domain control and related parts platformization and standardization requirements.
(b) The impact on the supply chain of domain controllers
The evolution and development of automotive E/E architectures has also profoundly affected the supply relationship between OEMs and automotive electronics suppliers. The core competitiveness of OEMs has shifted from the previous machinery manufacturing to a focus on software and algorithms. It is expected that there will be two modes of cooperation between OEMs and Tier 1 suppliers in the future:
First, Tier 1 is responsible for domain controller hardware design and production, as well as the middle-tier Middleware software part. OEMs are responsible for the autonomous driving software component. Tier 1's advantage is to produce products at a reasonable cost and accelerate product landing, so it is inevitable for OEMs to cooperate with Tier 1, the former responsible for the autonomous driving software part, and the latter responsible for hardware production, intermediate layer and chip solution integration. In this mode, when the project is established, the oem may directly determine the chip selection of the solution with the chip manufacturer across the Tier 1.
Second, Tier 1 cooperates with chip manufacturers to develop a central domain controller and sell it to OEMs, such as Continental ADCU, ZF ProAI, Magna MAX4, etc.
Smart cockpit domain controller
The essence of cockpit intelligence is based on the human-computer interaction scenario in the cockpit of the car, integrating the two modules of driving information and entertainment information to provide users with an efficient, intuitive and futuristic driving experience. The design appeal of the smart cockpit is mainly used to improve the user's driving experience, while also ensuring the safety and comfort of the user's driving, and ultimately achieving the ultimate goal of the car as a third living space outside of people's work and family scenes.
The smart cockpit domain includes the hud, cockpit and in-vehicle infotainment (IVI) three of its most important components.
HuDs are very practical features, projecting ADAS and some navigation functions onto the windshield, such as ACC, pedestrian identification, LDW, route indication, intersection turn indication, lane change indication, remaining battery, mileage, etc. HUDs will soon evolve into AR HUDs, becoming standard in the L3 and L4 eras.
In the L3 era, Driver Status Monitor (DMS) will become a must-have function, including: facial recognition, eye tracking, blink tracking, etc. will introduce machine vision and deep learning algorithms. The L4 era is a must-have V2X (Vehicle to everything).
In addition, the vigorous development of multimodal interaction technology will greatly change the interaction mode between users and cars. Voice interaction technology based on speech recognition function is becoming more and more popular, and is often used for interactive operation with IVI systems. It is also possible to analyze the driver's emotional state through voice. When the DMS system detects that the driver is drowsy, the system can wake up the driver by playing music or releasing scent; the multimodal interaction technology of the car cockpit based on multiple scenarios will definitely redefine the development of human-computer interaction technology in the future.
All these new technologies for smart cockpits will drive a surge in demand for computing resources in the cockpit domain.
In the field of smart cockpit domain controllers, the global Tier 1 manufacturers mainly include: Bosch, Continental Automotive, HARMAN, Visteon and Aptiv. Chinese local enterprises mainly include Desay SV, Hangsheng and Neusoft Ruichi.
Worldwide major cockpit domain controller vendor information
ADAS domain controller
ADAS domain controllers usually need to connect multiple cameras, millimeter wave radar, lidar and other sensor devices, to have multi-sensor fusion, positioning, path planning, decision control, wireless communication, high-speed communication capabilities, to complete the image recognition, sensor data processing and many other functions, so to complete a large number of operations, domain controllers generally have to match a core computing power of a strong processor, can provide automatic driving of different levels of computing power support, the industry currently has NVIDIA, Huawei, Renesas, NXP, TI, Mobileye, Xilinx, Horizon and many other solutions.
Autonomous driving technology is currently at the forefront of the global technology industry. L1 to L2+ driver assistance technologies and features have matured, and many models equipped with ADAS functions and applications have begun to enter mass production. It can be seen that the market penetration of L1/L2 level ADAS functions will increase rapidly, while the L3/L4 level autonomous driving system is still in the small-scale prototype testing stage.
In today's autonomous driving industry, the Chinese market is definitely the main force. This year, the number of L2 carriers in China is expected to exceed 800,000, and Chinese brands account for the vast majority of the share. In the future, the penetration rate of ADAS functions in the Chinese market will continue to increase rapidly, and the ADAS functions configured in low-end and medium-end vehicles will gradually increase. According to iResearch research reports, it is expected that ADAS functions can reach a penetration rate of about 65% in the passenger car market in 2025. L3 level high-speed automatic pilot HWP function and L4 level AVP automatic parking function, the current model penetration rate is low, the future improvement space is larger.
China ADAS function market penetration rate forecast
ADAS domain controllers are evolving from the distributed system architecture of the past to a domain-centralized architecture. In the past, a set of ADAS systems had to have several independent ECUs to achieve, such as lane shift and traffic recognition ECUs, forward collision warning ECUs, parking assistance ECUs, etc. Now with a powerful centralized ADAS domain controller, one domain controller implements all the features. The complexity of the system's hardware and software has been greatly reduced, and the reliability has also been improved.
At present, the industry provides ADAS domain control chip platforms such as NVIDIA, Huawei, Renesas, NXP, TI, Mobileye, as well as domestic horizon and black sesame. Table 2-2 below summarizes the world's major ADAS domain controller vendors and their customers and partners.
World's leading ADAS domain controller vendor information
Domain controller trends
The rise of domain controllers poses a great challenge to traditional automotive MCU manufacturers, "because the use of MCUs will be greatly reduced, and the evolution route of traditional MCU products will no longer exist."
In the era of distributed ECUs, the core of computing and control is the MCU chip, and the basic core of transmission is based on traditional low-speed buses such as CAN, LIN and FlexRay. However, in the era of domain controllers, heterogeneous SoC chips with high performance and high integration will become the core chips of domain controllers' computing and control as the main control processor of the domain. Automotive TSN (Time-Sensitive Network) Ethernet, because of its high bandwidth, real-time and reliable data communication capabilities, will become the core infrastructure of vehicle communication, especially the communication backbone between domain master processors.
Let's briefly analyze some of the key technologies and trends in domain controllers and core master processors.
Performance
Overall, the increased demand for computing power has been the main driving force for the development of domain controller core chips. On the one hand, functions that were originally completed by multiple ECUs now need to rely on a single domain master processor to complete, and it is also necessary to manage and control the various sensors and actuators connected. For example, the domain master processor of the chassis, the powertrain and the body comfort electronic system has an computing power requirement of about 10,000 DMIPS-15,000DMIPS.
Forecast of the demand for CPU DMIPS computing power for automotive domain controllers
The new smart car, in addition to more interaction with people, but also need a lot of environmental perception, which requires the calculation and processing of massive amounts of unstructured data, so the cockpit domain and the automatic driving domain require high-performance CPU, such as the CABIN instrument CPU computing power, it is actually similar to a high-end smart phone CPU computing power, about 50,000 DMIPS or so. In addition, in order to support L2 assisted driving functions or higher level of automatic driving functions, many visual DNN model algorithms need to be run, which requires hundreds of ADDITIONAL TOPS AI computing power.
Therefore, chip manufacturers will always try to use more advanced process technology, more advanced CPU core and NPU core to maximize the CPU core performance and NPU performance of the domain master chip.
High heterogeneity
With the application of AI technology in the field of vision, vision-based autonomous driving solutions are gradually emerging, which requires the addition of GPU chips that are good at visual algorithms on the basis of the CPU, thus forming a "CPU + GPU" solution.
However, the "CPU + GPU" combination is not the optimal solution, because the GPU has strong computing power, but the cost is high, the power consumption is large, and the FPGA and ASIC chips are gradually introduced.
In general, a single type of microprocessor, whether it is CPU, GPU, FPGA or ASIC, can not meet the needs of higher-order automatic driving, the main control chip in the domain controller will move towards the integration of "CPU + xPU" heterogeneous SoC (xPU including GPU/FPGA/ASIC, etc.), so as to better support the hardware acceleration needs of various scenarios.
High level of integration
At a functional level, domain controllers consolidate and integrate more and more functionality. For example, the power system domain may combine the control of the engine, the motor control, the BMS, and the control of the on-board charger. Some OEMs even directly integrate the three functional domains of chassis, power transmission and body into a "Vehicle Domain Controller" (VDC) in one step.
To support the integration of these functions, as the brain of the domain controller, the domain master processor SoC needs to integrate as many interface types as possible, such as USB, Ethernet, I2C, SPI, CAN, LIN, FlexRay, etc., to be able to connect and manage a wide variety of ECUs, sensors and actuators.
Hardware virtualization
The need for hardware virtualization technology comes from two main aspects: (1) partitioning and isolation of hardware resources; and (2) support for mixed security levels.
After the multiple functions that originally required multiple ECUs were integrated into the domain controller, it was bound to lead to more complex software of the domain controller, which was bound to lead to an increase in the probability of error and a decrease in reliability of the entire software system. Moreover, multiple applications running on the same operating system often occur failure propagation, that is, after an application has a problem, the underlying software and hardware of the entire system are in a disordered state, resulting in other normal applications will also begin to fail. Therefore, the hardware resources are partitioned (partitioned) through hardware virtualization technology, so that the software and hardware corresponding to each function are isolated from each other (Isolation), so as to ensure the reliability of the entire system.
On the other hand, in automotive electronic systems, the requirements for real-time and functional safety levels are often different for different applications. For example, according to the ISO 26262 standard, automotive instrumentation systems and infotainment systems belong to different safety levels and have different processing priorities. Automotive instrumentation systems are closely related to powertrains, requiring high real-time, high reliability and strong safety, and running on the underlying real-time operating system (such as QNX). The infotainment system mainly provides a control platform for human-computer interaction in the car, and pursues diversified applications and services, mainly Linux and Android. In order to achieve the application of mixed security levels, so that different operating systems run on the same system, this requires the support of virtualization technology.
At the heart of in-vehicle hardware virtualization technology is Hypervisor, a middle-tier software that runs between a physical server and an operating system that allows operating systems and applications on multiple different VMs to share a set of underlying physical hardware. When the system boots, it first runs Hypervisor, which is responsible for allocating the appropriate amount of memory, CPU, network, storage, and other hardware resources to each virtual machine (that is, partitioning the hardware resources), and finally loading and starting the guest operating system of all virtual machines.
To sum up the advantages of Hypervisor in one sentence: it provides the flexibility to carry heterogeneous operating systems on the same hardware platform, while achieving good high reliability and fault control mechanisms to ensure security isolation between mission-critical, hard real-time applications and general-purpose, untrusted applications, enabling on-board computing unit integration and computing power sharing.
ISO 26262 Functional Safety
Functional safety is one of the most critical elements in the automotive development process. As system complexity increases, there is a growing risk of system failure and random hardware failure. The purpose of iso 26262 standard is to better standardize and standardize the functional safety management and requirements in the whole life cycle of automobiles, including: concept stage, system research and development, hardware research and development, software research and development, production and operation processes, after-sales service and other links, especially in the product design stage how to define and achieve the goal of functional safety.
Among the safety technical measures recommended for the diagnostic coverage of processor units in the functional safety standard ISO26262-5 2018 "Product Development: Hardware Level Appendix D", dual-core lockstep, asymmetric redundancy and coded computation are three typical hardware redundancy technical measures. In addition, hardware BIST, hardware and software Self-Test technology, ECC, etc. are also common design measures to improve the security characteristics of processors.
Functional safety chip design techniques in the ISO26262 standard
A dual-core lock-step CPU is a CPU redundancy technique that contains two identical processors in one chip, one as a master core and one as a slave core, which execute the same code and are strictly synchronized, the master can access system memory and output instructions, while slave constantly executes instructions on the bus (i.e. instructions acquired by the main processor). The output generated by slave, including address bits and data bits, is sent to the comparison logic module, consisting of a comparator circuit of the master and slave bus interfaces, checking the consistency of data, addresses, and control lines between them. When any bus values are detected, a fault is found on one of the CPUs, but it is not determined which CPU is faulty.
This CPU architecture makes the CPU self-test independent of the application software, does not need to perform a special instruction set self-test, the actual running software instructions are compared at each clock, only need to test the CPU resources used by the software, but this architecture will not detect the memory and bus, and a separate detection method needs to be added to avoid the common-mode failure of the two CPUs.
Network uninstall engine
There are multiple communication buses in automotive networks. The backbone network is bound to be built on TSN Ethernet in the future, but the communication from the domain master processor to the ECU or sensor is still based on the traditional on-board low-speed bus, such as: CAN, FlexRay, etc. The domain master processor, as the core of the domain controller, is the aggregation center for all ECU and sensor communications. Therefore, if you want to rely on the computing power of the CPU to complete the protocol conversion between different buses, as well as the processing of network packets for cross-domain communication, it is bound to occupy valuable CPU computing power resources.
Therefore, a network offload engine that implements network protocol translation processing based on hardware is a very important technology for domain master processors in various domains (including central gateways).
Security Engine
Connectivity is a very important trend in the development of automotive intelligence, and the cars of the future will surely remain connected to the Internet at all times like today's mobile phones. Therefore, how to prevent unauthorized network access to protect cars from hackers will become extremely important for the smart cars of the future. The Next Generation Hardware Security Module (HSM) is becoming one of the key infrastructures for next-generation in-vehicle network communications.
HSMs are essential for fully secure onboard communications (SecOC). The HSM ensures the authenticity of the received data and prevents attackers from bypassing the relevant security interfaces and invading the in-vehicle network.
Hardware-based security modules mainly solve two problems:
Key leak issues: If the key is stored in the application's code or data, it can be easily leaked. Therefore, it is necessary to add a hardware module that specifically stores the key.
Crypto algorithm acceleration: Direct encryption or decryption operations through the kernel will consume a lot of CPU computing power resources. Therefore, it is necessary to speed up the encryption and decryption algorithm through hardware modules.
The SHE (Secure Hardware Extension) standard is a specification for the hardware security module HSM developed by Audi and BMW in cooperation, which mainly includes the hardware and hardware software interface of the cryptographic module. This specification has been widely accepted, and many microprocessors for the automotive industry support it.
Service-oriented software architecture SOA
Most of the software originally run by the ECU is a software system developed in accordance with the Classic AutoSAR specification, and the application software is generally in the Static Scheduling mode, that is, when the system is running, the functions of different functions in the program are called sequentially and run one by one according to the pre-defined order file. The advantage of static scheduling is that the resource allocation problem is arranged in advance, and the vehicle will not change after mass production, and the specific running time of the function code corresponding to each function is also locked in advance, which is deterministic. Therefore, this design is very suitable for many scenarios where functional safety is critical in automobiles. For example, the function of deciding whether the airbag is turned on is to run it regularly every few milliseconds so that it can be opened in time in an emergency.
After the underlying hardware carrying computing and control is concentrated from a decentralized multiple ECUs to a multi-core, heterogeneous high-performance domain master processor, the corresponding software will evolve from decentralized to centralized, from simple to complex, from static to dynamic. Figure 2-7 below shows a typical software architecture on a later automotive domain controller:
A typical software architecture based on null-resolution virtualization technology on domain controllers
Operating system layer: The lowest level uses Hypervisor virtualization technology to partition hardware resources, so that different operating systems can be run on each virtual machine. For example, in the above figure, the VM VM1 runs rTOS that is compatible with the POSIX real-time operating system standard (such as PSE 52), and the RTOS usually carries functional safety-related applications and services; the time-sharing operating system of Linux, which is a complete POSIX standard, is run in vm VM2, which usually runs management-related functions and services; and the LEGcy application running in VM3 may be the legacy application that originally ran on the ECU.
Middleware layer: The operating system does not do any work related to the "car" specific. In order to allow the domain master processor to be used in the automotive scenario, there is a lot of software or middleware that is required to make the domain controller meet the automotive power management standards, network management standards and diagnostic standards; the on-board domain controller needs to have higher reliability requirements than the general industrial embedded system, so it is necessary to attach the security protection and fault tolerance mechanism for storage and communication on the basis of the computer OS; at the same time, the bit allows the on-board domain controller to run under the vehicle EE architecture, and also needs to provide clock synchronization, Features such as log tracking and service management and discovery. The Adaptive AutoSAR specification defines this layer of "car"-related middleware standards that run on Linux or fully compatible with POSIX 1003.1 standard RTOS, while the traditional RTOS or BareMetal mode specifications that run on a subset of POSIX are defined by the Classic AutoSAR standard.
Application layer: The upper layer application is developed based on the middleware of the AutoSAR standard. With the increasing number of functions related to automotive intelligence and networking, the upper-layer application software is becoming more and more complex. By reducing the overall complexity of a single application, we can learn from the software design ideas of the Internet's service-oriented architecture (SOA) to split a complex application into multiple services. Each service is implemented as small as possible, as far as possible as stateless as possible, to facilitate the development, testing, and software reuse of the entire system. Services communicate with each other through events or message buses (publish/subscribe operating modes) and reduce coupling between them. Service configuration to manage dependencies between services, deployment and startup of services, health detection of services, and more.
Automotive Ethernet brings a revolutionary change to in-vehicle system communication, under the central computing car EE architecture, the entire in-vehicle system can be seen as a distributed network system: the central computing platform is a small server cluster, and the regional computing platform is the edge computing node. In the Internet or large distributed systems, soA architecture design concepts have been widely used. Therefore, when IP network technology is widely used in automobiles, many software technologies that are already mature in the Internet or distributed computing will naturally be borrowed into the design of new automotive software architectures, such as RPC technology, event/message bus, RESTful API design, etc.
Server clusters in large Internet data centers often have hundreds or thousands of servers, and millions and tens of millions of concurrent servers per second. Although the in-vehicle system can be regarded as a distributed network system, it does not have the high concurrency characteristics of the Internet large server system, on the contrary, it pays more attention to the real-time and reliability of communication.
The in-vehicle system is physically centralized, that is, the functions that were originally implemented through multiple decentralized ECUs are gradually concentrated on several major high-performance domain controllers. Therefore, although in software design, we will try to split into small services according to the SOA idea, these services are actually centralized in deployment. Given the coexistence of "centralized" and "distributed" runtimes on physical deployments, we can optimize the latency of communication between services through a range of technical means (e.g., through shared memory technology). This is another significant difference between the on-board distributed system and the distributed system of the Internet that emphasizes high concurrency.
Domain centralized EE architecture will be the dominant automotive EE architecture for a long time to come, and domain controllers, as the core of domain centralized EE architecture, will occupy an increasingly important position in the entire automotive industry chain. Its corresponding chip and hardware solutions, operating systems and algorithms will become the focus of competition for upstream and downstream manufacturers in the entire industry chain.
Reprinted from the forefront of intelligent driving, the views in the text are only for sharing and exchange, do not represent the position of this number, such as copyright and other issues, please inform, we will deal with it in a timely manner.