Some observations on intelligent driving domain controllers

Foreword:

The electronic and electrical architecture of Chinese car companies is gradually transitioning from a distributed architecture to a domain-centralized architecture. Some mainstream domestic car companies have achieved mass production of domain-centralized architecture platforms in 2021. As the "central brain" of intelligent connected cars, intelligent driving domain controllers have become a key area of ​​focus for various OEMs.

The key contents are as follows:

1. Currently, OEMs have diversified demands for intelligent driving domain controllers. In order to better serve customers, Tier1 is constantly improving its software and hardware capabilities so that it can provide flexible and diverse cooperation models.

2. The main control chip is the core component of the intelligent driving domain controller. For OEMs and Tier1, selecting the appropriate main control chip is a key step for the domain controller to achieve rapid mass production.

3. Intelligent driving domain controllers not only have some technical problems at the hardware and software levels during the design and development process, but also face various challenges such as high technical engineering requirements, short development cycles, and difficult supply chain guarantees during mass production. challenge.

1. Classification of smart driving domain controllers and flexible cooperation models

Generally speaking, the intelligent driving domain controller that everyone understands may mainly refer to domain controller hardware + underlying basic software (virtual machine, operating system kernel, board-level support package, etc.). But in a broad sense, the intelligent driving domain controller not only includes hardware + underlying basic software, but also covers middleware and upper-layer application algorithms, and even involves peripheral sensors and actuators, which together form a large system.

Yu Qingzhou, Director of Freetech Domain Control Product Line, said: "From the perspective of high-end autonomous driving system solution architecture design, the current intelligent driving domain controller system solution includes not only domain controller solution design, architecture design, algorithm design and Software design also includes the products of the software and hardware ecological partners involved. It is necessary to connect the chip, basic software, middle layer, algorithm and application layer within the hardware carrier of the domain controller to achieve in-car interconnection and continuously enhance it through rapid iteration. User senses and driving experience welcome the arrival of the digital driving world.”

1. Classification of smart driving domain controller types

From the perspective of product positioning and usage, the current smart driving domain controllers in the passenger car market can be roughly divided into two types: medium and low computing power domain controllers (lightweight domain control) and large computing power domain controllers device.

Medium and low computing power domain controller : used to implement L1~L2+ level driving assistance functions, mainly installed in mid-to-low-end models, such as Desay SV’s IPU01/IPU02, Freetech’s ADC10, etc. This type of domain controller is relatively cost-sensitive and is positioned as a cost-effective product suitable for large-scale mass production.

Large computing power domain controller : used to implement high-end autonomous driving functions of L2+ and above, mainly installed in mid-to-high-end models, such as the NVIDIA Orin platform installed in NIO ET7 and SAIC Feifan R7, and the Qualcomm Snapdragon platform installed in the Great Wall Mocha Dragon Ride platform. This type of domain control requires relatively high AI computing power and requires pre-embedded hardware. However, because it is positioned to reflect high-end and technological aspects, it is more affordable in terms of cost.

2. Different demands of OEMs

Since different types of domain controllers have different market positionings, OEMs have different demands when cooperating with Tier1 for different types of smart driving domain controllers .

Low-to-medium computing power domain controller : If the OEM did not prepare for self-research in the early stage, most of them will not engage in self-research or joint development now. For OEMs, they should define their own needs, such as what main control chip to choose in the controller and what functions it needs to have, and then directly hand it over to the supplier, which will be more efficient. For them, what is most needed now is to be able to deliver quickly and bring new features to the market as quickly as possible to ensure the competitiveness of the product in the market. Therefore, for domain controllers with medium and low computing power, most OEMs will choose to have suppliers provide “turnkey” solutions.

For lightweight domain controllers with medium and low computing power, there are solutions based on the TDA4 platform in the industry, as well as solutions based on TDA4 + Horizon J3. Regardless of the solution, the product positioning is basically the same - mainly used to achieve L1~L2+ level assisted driving functions. The application scenario of this function is relatively simple and has relatively low functional safety requirements. For this type of domain controller, the OEM pays more attention to the supplier's cost control and implementation efficiency. Its competitiveness lies in whether it can provide a cost-effective product.

Li Lele, vice president of Desay SV, gave an example: "For parking-in-one domain controllers with medium and low computing power, for example, low-speed scenarios only implement APA and HPA functions without requiring people to be outside the vehicle, and the functional safety level requirements are lower. High-speed scenarios From L1 to L2+, people can intervene at any time without leaving the steering wheel. The main challenge in developing this type of domain controller is to focus on improving it with limited computing power and cost. In this case, the performance must be maximized because the upper-layer application algorithm, middleware and underlying software must be jointly optimized, and the coupling degree is high, making it difficult to decouple software and hardware.”

Large computing power domain controller: There is still a buffer period in terms of mass production time, and the OEM still has time and energy to engage in joint development with Tier1. What's more, most of the leading OEMs hope to be able to develop the full stack themselves. Even if they can't handle the full stack now, they hope to get more involved in the cooperation with Tier1, so as to continuously make up for it during the cooperation between the two parties. own shortcomings.

Domain controllers with large computing power are used in mid- to high-end models and are used as technical highlights and brand promotion highlights. Therefore, in terms of attention, it is incomparable to lightweight domain controllers with medium and low computing power. This is an important factor that can reflect brand power and influence.

Li Lele of Desay SV explained: “Domain control with medium and low computing power requires continuous polishing and optimization strategies to make up for the lack of computing power and achieve the best performance at a limited cost, which is to pursue a balance between performance and cost. But large Computing power domain control currently does not need to worry about insufficient computing power. Since the computing power itself is very powerful, even without special compression and model simplification of the algorithm, large networks can run very smoothly and demonstrate extremely strong performance.

"From this perspective, it can be understood that the coupling between the hardware and algorithm functions of large computing power domain control will be relatively low, and the collaboration requirements between OEMs and Tier1 are much lower than the development of lightweight domain control. Therefore. , the large computing power domain controller is suitable for collaborative development between Tier 1 and the OEM. The OEM can concentrate on the upper-layer software to create differentiation, and does not have to invest a lot of resources and energy on tailoring and optimization because of worries about insufficient computing power. "

3. Flexible and diverse cooperation models

Since the strength levels of various mainframe manufacturers are uneven and their respective strategic plans are also different, the demand for domain controllers is also diverse. Tier1 needs to ensure that its products can be put into mass production as soon as possible, quickly realize its own data closed loop, and be able to continuously iterate its products, so it needs to try its best to meet the differentiated needs of customers.

• 硬件 +底层软件

• 硬件 +底层软件+中间件

• 硬件 +底层软件+中间件+部分应用算法

• 硬件 +底层软件+中间件+全部应用算法 （全栈交付）

当然，提供多样化的合作模式也给供应商带了一定的压力和考验。毕竟开发需求越多 ，资源投入就会越大。反过来讲，能够经受住这些挑战，并充分利用自身有限的资源去满足主机厂的需求，也有利于 Tier1提升其自身竞争力。

德赛西威李乐乐告诉九章智驾： “ 对于智能驾驶域控制器，客户在软硬件层面均会存在一些差异化的需求。

“在软件层面，有的客户希望短平快，选择Linux操作系统，因为Linux的生态系统比较完善，可以满足功能快速实现。但是选择Linux，功能安全就没办法实现，这种情况我们会尽量增加一些冗余设计，包括芯片内部的出错诊断，做一些能做的安全相关的设计。当然，也有些客户基于功能安全层面的考虑会选择QNX实时操作系统。

“同样，除了需要提供底层软件外，有的客户希望我们提供中间件，也有客户需要我们提供全栈工程的交付。这就需要我们基于客户的不同需求去做好边界的划分和接口的定义。

“在硬件层面，基于算力需求的不同，客户会选择不同类型的芯片或不同的组合形式。有的客户选择单Orin 110TOPS，也有选择单Orin X的254 TOPS，更有选择双Orin X的508 TOPS，甚至有客户要求两个双Orin X的板子背靠背集成到一起达到1016TOPS算力。

“另外，从整车架构集成角度来看，不同的OEM也有不同的规划，有一些客户希望在大算力自动驾驶域控平台上集成网关、VCU，也有一些客户希望能集成IMU、GPS定位模块，甚至也有一些希望能集成V2X模块。这些都可以配合客户去提供差异化定制开发的支持。”

总之，主机厂需求不同，域控制器供应商 Tier1在服务客户的方式上也会存在差异。无论双方选择哪种合作模式，最终都是以硬件为载体，并以产品的形态给到主机厂，只是在分工上会有差别。对Tier1的挑战在于前期做系统需求设计的时候，需要能够结合客户的差异化需求，提供一个完整的平台化设计，并且能够在平台基础上可进行差异化定制的更改，确保能提供一个最适合客户需求的设计方案。

二、智能驾驶域控制器主控芯片的选择

主控芯片是智能驾驶域控制器的核心，它的算力和集成度直接影响了整车 EE架构的形态，进而决定了智能汽车的性能表现。对于Tier1来讲，在开发域控制器的时候，比较关键的一点就是如何去选择合适的主控芯片。笔者在与相关专家的交流过程中发现，大家考虑的维度基本是一致的，都是先基于市场定位的去框定芯片的大致选择范围，然后再从芯片的Roadmap、生态、可落地性等维度去考虑。

1）基于市场定位

选择什么样的主控芯片，首先要看该域控制器的市场定位：打算实现什么样的功能，用于配置在什么价位区间的车型上。

宏景智驾联合创始人蔡文利提到： “如果目标定位是做辅助驾驶，做一个L1~L2级的产品，而且是走量的，在选择芯片的时候对成本就很敏感。这样的域控产品，它走的路线一般是平台化和高性价比。

“如果说目标定位是打造一款L4级限定场景下的无人驾驶，那么客户可能更倾向于去打造一款定制化的产品。比如，定位做Robotaxi，打算走运营的一个模式，目的是想要先把算法打磨出来。它的量就不会特别大，那么选择芯片时，对成本相对就没那么敏感，但要求性能足够好，足够稳定。”

2）芯片的Roadmap

东软睿驰副总经理刘威提到： “从与芯片公司合作的角度来看，会看它是不是一个主流的芯片厂商，有没有连续的产品Roadmap。比如，有一些芯片厂商可能开发出了一款不错的芯片，但是后续没有更新换代。那么围绕该芯片来做域控制器，后续产品的迭代和升级会存在很大的问题。”

同样，均胜电子智能驾驶系统设计负责人李茂青也提到了相同的观点： “在域控制器系统设计中对于硬件方案的选型上除了关注芯片本身的功能性能外，还需要充分了解芯片公司的产品Roadmap，是否有灵活的家族化芯片系列，后续的芯片能不能PIN to PIN地在硬件平台上升级，继而可以在提升硬件性能的同时降低开发成本？”

3）芯片的生态

芯片整个软件的工具链或者对一些算法的开发是不是能满足客户的需求。也就是说芯片的生态怎么样，是否具备一个良好的生态系统能够支撑客户做可落地化的开发 ,也是主机厂或Tier1在选择芯片时候的重要考量因素之一。

• 可为汽车领域提供丰富的软件算法人才；

• 在通用AI领域已训练出大量的算法模型及相关应用软件；

• 统一的硬件和底层软件接口架构（CUDA-X），可便捷的移植到汽车领域；

• 由于大量的用户使用，合作伙伴为CUDA平台贡献了大量的库和工具。

知行科技硬件研发总监解释道： “现在很多主机厂都在用英伟达的Orin芯片，除了它是一个大算力平台，另外一个重要的原因是它能提供整个软件的工具链，甚至一些底层的代码以及一些算法的代码都可以提供；开发者可以在上面做更多的适配，能够更好地开发出一款可以落地的高级自动驾驶计算平台。选择芯片，除了芯片本身，更多的是在选择一种生态。”

4）芯片的可落地性

知行科技硬件研发总监讲到： ”从产品的角度来讲，选择芯片的话，首要关心的是芯片的可落地性，这是我们最高的优先级。有一个相对简单的判断原则：这款芯片它的量产可靠性怎么样？能不能够满足客户需求，是否能够按照我们的产品路线去做交付。

"On this basis, we will consider other factors, such as whether its computing power meets our needs; how simple the product is, and whether it can use natural cooling instead of air cooling. , liquid cooling; of course, its manufacturing process is also a relatively important parameter, which will affect the audience of the product in the next few years. If the manufacturing process is too backward, its demand for use will gradually decrease. "

5) Other factors

From the performance of the chip itself, we also need to consider its AI computing power and comprehensive energy efficiency ratio, that is, the utilization rate of its computing power. At the same time, the functional safety level of the chip itself is also a key element. The last and more critical point is to look at the engineering service capabilities of the chip manufacturer. If the engineering service capabilities are not good, no matter how good the technology is, there will still be big problems for Tier 1 when it comes to mass production.

3. Challenges faced by the design, development and mass production of intelligent driving domain controllers

Li Maoqing of Joyson Electronics mentioned : "The products we make need to fully consider the needs of customers. For example, if the customer wants to provide high-speed navigation + parking functions at the current stage, but later expands to urban navigation, then it is necessary to do so during the conceptual design stage. Analyze whether it can match the customer's project needs from multiple dimensions such as system architecture, hardware resources, functional safety, and product life cycle. This stage is the most challenging stage of intelligent driving domain control design. Only at this stage does the technology become more important. Only after the plan is fully evaluated will the subsequent work be more directional and rational.”

1. Challenges faced in the design and development of intelligent driving domain controllers

1) Hardware level

Traditional distributed ECUs have relatively low requirements on interfaces, power consumption or computing power. However, today's domain controllers integrate more functions, need to process more and more data, and require more and more computing power. big. As a result, domain controllers have become more complex and require many electronic components. It is a relatively challenging task to do a good job of fail-safe design for the functional safety of all internal hardware. At the same time, it also faces great difficulties in terms of electromagnetic anti-interference capability and signal integrity.

In addition, chips with large computing power will generate new power consumption and generate large amounts of heat, which requires a balance between size and heat dissipation.

Li Lele, vice president of Desay SV, told Jiuzhang Zhijia: "The number of components and materials used by the large computing power domain controller far exceeds the number of components in the ECU of any vehicle in the past. In terms of functional safety, WCCA needs to be done well. (Worst-case circuit) analysis, failure probability analysis and corresponding backup design. It is very challenging to do a good job in functional safety design when there are many components and the system is complex.

“Secondly, due to the limited layout space of the vehicle itself, it is also challenging to control the domain controller’s appearance design within a smaller size range while fully meeting reliability, electromagnetic compatibility and environmental test requirements.

"Domain controllers with large computing power tend to generate relatively high heat. The current mainstream solutions are to solve the heat dissipation problem through water-cooling design. This requires strong thermal simulation capabilities to make a very sophisticated water-cooling heat dissipation pipeline solution. , and at the same time can monitor the main chip temperature through software, and control the inlet water temperature and flow rate of the water cooling system based on these chip temperatures. To build such a closed-loop system for temperature monitoring, inlet water temperature and flow rate control, a set of models needs to be established. And conduct simulations and tests to avoid problems such as water condensation inside the controller due to overcooling or overheating or failure to dissipate heat in time.”

2) Software level

How to implement SOA as a service? How to achieve coordinated communication, high-speed computing, computing power deployment, real-time scheduling, etc. between multiple cores or multiple SoCs? How to ensure the flexibility of software architecture and the functional safety and expected functional safety of software? These are all challenges faced by domain controller design and development at the software level.

Dr. Liu Wei from Neusoft Reach mentioned: "From the perspective of the entire software function, everyone is now doing SOA. In fact, SOA service-oriented has an impact on computing power. Although everyone says they are doing SOA, there are still differences. It's quite big. For example, there is no unified conclusion so far about which signals can be servitized and which signals cannot be servitized, because, first, it depends on the entire application requirements; second, it depends on the entire vehicle architecture. ;Thirdly, it also depends on the computing performance of the entire hardware.”

In the context of software-defined cars, the development cycle of future models continues to shorten. Everyone wants to create a flexible software architecture that can span different operating systems and different hardware platforms. In addition to the functions related to autonomous driving itself, the software architecture also needs to consider data upload and information security issues. At the same time, it will also involve issues such as how to process data locally and in the cloud together, including how to upload data collaboratively. This puts forward high requirements for software architecture.

From the perspective of the entire software implementation, in addition to considering the functional safety of the hardware, the functional safety of the software must also be considered, and the workload is very heavy. From the underlying driver to the basic software, to some upper-layer middleware, all the way to the top-layer application, all these software must consider functional safety. Moreover, for high-end autonomous driving functions, the expected functional safety of software and hardware must also be considered.

2. Challenges faced by mass production of intelligent driving domain control

Judging from the current situation, low-to-medium computing power integrated domain controllers have been mass-produced since last year, and will usher in an explosive period of mass production and delivery in the past year or two. At the same time, some models of smart driving domain controllers with large computing power will be delivered starting this year. New technologies or new products will certainly continue to expose some problems in the early stages of mass production. So what problems will the intelligent driving domain controller face during the mass production process?

1) Technical engineering understanding

The intelligent driving domain controller system is relatively new and has high requirements for systematic design capabilities. If a problem occurs during the development of the system, you need to have the ability to see through the appearance of the problem and see the essence of the problem, and be able to decompose the problem layer by layer and finally solve it. This still places high demands on the technical engineering understanding of the entire team.

Yu Qingzhou of Freetech believes that when functional and experience problems arise, whether the team can dig from the application algorithm side to the lowest level sensor. The root cause of the problem may be caused by the chip driver or perception. Whether we can open up all the links from front to back in this chain is the most direct challenge to the team's ability. "

2) The development cycle is continuously compressed

In the era of software-defined cars, it is obvious that the speed of product iteration is accelerating. In order to bring it to the market quickly, OEMs are desperately trying to find ways to shorten the development cycle of new cars. Therefore, Tier1 has to change its traditional development model and draw on the development concepts of Internet technology companies to form its own new development model. Respond quickly.

As a relatively new product integrating software and hardware, the intelligent driving domain controller involves many partners. When a problem occurs, someone needs to be able to locate the problem, and then dismantle it and assign it to different responsible parties to solve it. Especially for some deep-seated problems, locating the problem itself is time-consuming. At the same time, for new systems, there will be many problems that will arise later. This also consumes a lot of time in the development cycle to a certain extent.

Cai Wenli, CEO of Hongjingzhi, said: "Since OEMs have strict mass production timelines, many ADAS projects have extremely tight deadline requirements. This is a double-edged sword for ADAS service providers. We need to have the ability to customize for customers. The service awareness and technical capabilities of specialized development must also be flexible in resource allocation, and the company must be willing to cooperate with its customers to jointly develop a product that can be mass-produced and satisfy customers. The main challenge here lies in how to coordinate the enterprise. Internal resources are required to deliver products in an orderly and timely manner with high quality and quantity. This is a comprehensive challenge to the entire enterprise’s system design experience, project management, and capital investment.”

Zhixing Technology Hardware R&D Director believes: "Under the pressure of a short development cycle, Tier1's engineering basic capabilities are sufficient to cope with problems that arise during the development process and solve them quickly. It also tests the Tier1 ecosystem. Can your partners to support you quickly and whether there are resources to support you in solving these problems.”

3) Supply chain guarantee

Greater market demand has led to shortages in the semiconductor supply chain and production capacity. Various "natural and man-made disasters" including the epidemic have continued to disrupt the normal production rhythm of semiconductors. The contradiction between demand and production capacity is difficult to resolve in the short term. For chips that are in short supply in the market, downstream factories still need to pay deposits, place reservation orders in advance, sign purchase contracts, etc. to ensure that they can receive the goods. Even the so-called "big customers" who are given priority for supply may not be able to get the chips. Get enough chips.

In the context of such a tight global chip supply chain, supply chain security is also very challenging for domain controller suppliers. When OEMs select domain controller suppliers, the supply capabilities of their partner chip manufacturers are also important considerations.

In 2022, chip shortages will still affect the automotive industry. Some OEMs have begun to think about new ideas for semiconductor supply, and some have even bypassed Tier 1 and directly found chip design manufacturers. More in-depth OEMs have begun to participate in the research and development process of chip design. For example, many car companies have established strategic partnerships with autonomous driving AI chip manufacturers such as Black Sesame and Horizon. What's more, they directly penetrate into the semiconductor supply chain and introduce chip design into the main engine factory. This model is called the "OEM-Foundry-Direct" model, and representative companies include Tesla, BYD, etc.

Conclusion:

• Continuously expand the boundaries of software capabilities: As hardware gradually converges, software capabilities need to be improved to empower the hardware and allow the hardware to perform at its best;

• Ability to provide diversified cooperation models: Ability to provide differentiated services in response to the differentiated needs of OEMs;

• Engineering implementation capabilities: During product mass production, we can provide corresponding supply capabilities and engineering service capabilities to ensure smooth delivery of products.