Author: Chen Kangcheng

Following the development path of the vehicle’s EE architecture, the development process of intelligent driving-related functions can be divided into the following stages:

Stage 1: Each parking or driving function has a corresponding ECU unit.

Stage 2: Parking-related functions begin to be continuously integrated into a parking control unit, while driving-related functions are integrated into a driving control unit.

Stage 3: Parking functions and driving functions are integrated, and an integrated technology solution for intelligent driving domain control, i.e. cabin driving, appears. At the same time, another technical path-merging parking functions into the cabin domain, i.e. cabin parking, also appears.

Stage 4: The functions of the intelligent driving domain and the cabin domain are cross-domain integration to form a higher performance cabin driving integration HPC.

The cabin parking integration and the driving-cabin integration solutions are the products of the 3rd stage in the following figure. This year, there will be several domestically produced driving-cabin integration technology solutions put into mass production. This article focuses on some issues that occurred during the 3rd stage.

Cabin Parking Integration Solution

Both parking and driving belong to the category of driving functions. It is reasonable to integrate parking and driving together. Why did the industry come up with a solution to integrate low-speed parking functions into the cabin domain?

Reason for the “birth” of the Cabin Parking Integration Solution

After conducting research among industry experts, Nine Chapters IntelliDrive found that their opinions were basically consistent:

• The computing power on the cabin domain controller is sufficient, and the remaining computing power can meet the application needs of some basic parking functions, such as 360 surround view and automatic parking assist (APA).

• Parking functions will involve some human-machine interaction designs. By integrating parking functions into the cabin, the cabin domain controller will receive more parking signals, thereby enabling better human-machine interaction design in parking scenarios.

• By merging low-speed parking functions into the cabin, the original parking controller can be eliminated, which can save some costs.The chief designer of the intelligent driving system at a certain automaker believes that the integration of low-speed parking into the cockpit stems from a trend towards functional integration. In the early days of 360-degree surround view, there was a separate controller that needed to connect to four fisheye cameras. Later, 360-degree surround view and Automatic Parking Assistance (APA) were merged, upgraded to a fusion parking function, and the performance of the controller needed to be upgraded again, requiring the connection of four fisheye cameras and twelve ultrasonic radar. As the cockpit becomes more intelligent, the cockpit system-on-chip (SOC) now has stronger CPU and AI computing power, and can also support more sensor interfaces. For example, Samsung’s production-ready cockpit chip, Exynos Auto V910, embeds AI acceleration computation and can support up to 12 cameras with a computing power of 1.9 TOPS. With the integration of parking features in the cockpit, the technology requirement of fusing the parking function into the cockpit arises.

The disadvantages and limitations of the cockpit-parking integration solution

Why is the cockpit-parking integration solution generally considered a non-mainstream technology solution in the industry? This is because compared with the parking-drive integration solution, it has its own disadvantages and limitations.

Disadvantages:

1) High cost of development coordination and communication

Whether it is within the automaker or within Tier1, the parking function and cockpit function are mostly handled by two independent teams, and for both functions, the automaker usually relies on different suppliers. If the low-speed parking function is integrated into the cockpit domain, project development or requirement changes require coordination and communication between the different departments of the automaker and multiple suppliers, resulting in high communication costs.

The chief designer of the intelligent driving system at a certain automaker told Jiu Zhang Zhi Jia: “Integrating low-speed parking functions into the cockpit domain requires cross-departmental development in many automakers, and the current organizational structure of automakers is difficult to promote. Especially for traditional automakers, this solution is mostly rejected because it involves too many parties. If problems arise during mass production and implementation, who will be responsible for solving them? If they cannot be solved, who will be willing to shoulder the blame?”

2) The cockpit function and parking function have different development modes. Integrating both may result in mismatched development cycles and iteration speeds.The deputy general manager of Neusoft Reach, Liu Wei, mentioned that from a development perspective, the development of intelligent driving functions is related to sensors, actuators, data collection, and data upload. There are more interactions with the outside world, and synchronous development is required. The cabin is relatively enclosed, and its relationship with the surrounding systems is not so strong, with offline development as the main focus. If the cabin, which focuses on offline development, and the parking function, which focuses on synchronous development and interaction with the outside world, are developed together, their development cycles and iteration speeds cannot be completely matched.

Limitations:

From the perspectives of shared perception sensor data and functional safety, the limitation of integrating parking functions into the cabin domain solution is that it will limit the parking function in future iterations and upgrades. This solution is currently mainly suitable for some cost-effective mid-to-low-end models.

1) For basic parking functions, the higher configuration rate on current models is 360 surround view and automatic parking assist (APA). If future higher-level parking functions, such as valet parking (AVP) or home memory parking (HPA), are involved, the driving perception system needs to participate, whether it is a front-facing camera, a side-facing camera, or even a lidar sensor. Therefore, from this perspective, higher-level parking functions are currently not suitable for integration into the cabin domain.

2) Currently, the functional safety requirements for the cabin domain control chip and the intelligent driving domain control chip are different. The cabin domain control chip has low requirements for functional safety levels and can only support some low-level parking functions, such as APA and AVM.

The cabin domain generally runs two types of operating systems through a virtual machine manager: QNX operating system with high real-time and security requirements for instrument modules, and Android and Linux operating systems with low real-time and security requirements but rich ecological resources for entertainment modules. The parking function needs to be displayed on the central control screen, and it will involve human-computer interaction designs such as 3D interfaces, panorama interfaces, and operation interfaces. Therefore, it should be implemented in the entertainment module. The functional safety requirements for the entertainment module are currently relatively low, and it is actually impossible to achieve higher-level parking functions, only basic parking functions can be implemented.

Will the cabin parking integration solution survive?From the development path of parking, first came the reversing camera, followed by the 360-degree surround view, and then the development of memory parking (HPA) and valet parking (AVP). 360-degree surround view is currently a popular ADAS function with a high rate of adoption, and there is still a lot of room for growth in the future. At the same time, integrating parking functions into the cabin can save the hardware cost of parking controllers. Therefore, from the perspective of user experience and cost optimization, entry-level models may integrate practical basic parking functions into the cabin; mid-to-high-end models need to carry higher-level parking functions such as HPA and AVP, which require higher functional safety levels and cannot be integrated into the cabin. As a result, mid-to-high-end models will choose to adopt a road and parking integrated solution.

Lele Li, vice president of Desay SV Automotive, believes that the two technology solutions of road and parking integration and cabin and parking integration will coexist. If we extend the timeline for three to five years, by that time, AVM and APA will almost become standard configurations for entry-level models. Due to cost constraints, entry-level models may not have the capability to integrate high-performance domain controller platforms into the vehicle, and therefore the functions of parking and driving cannot be integrated. Therefore, entry-level models will choose a technology solution that integrates basic parking functions into the cabin. Mid-to-high-end models with high-performance domain controller platforms will definitely adopt the solution of road and parking integration.

Road and Parking Integrated Solution

Advantages of the Road and Parking Integrated Solution

Currently, most intelligent driving modules of vehicles are still composed of two systems for parking and driving. The upgrade of the whole vehicle’s electronic and electrical architecture from a distributed architecture to a domain-centralized architecture, as well as the mature technology of sharing sensors and domain controllers for driving and parking, will further accelerate the mass production and implementation of the road and parking integrated solution.

1) Sensor sharing for improved performance

Once the parking function is upgraded to AVP or HPA, sensors from the driving system are also required to supplement perception, to enhance the system’s safety. For example, in AVP, the emergency evasive maneuver capability relies not only on the perception of the 360-degree camera and ultrasonic radar but also on the camera, millimeter-wave radar, and even lidar in the driving system, to identify distant or small objects in advance.

Similarly, some driving scenarios also require low-speed parking sensor data to serve as auxiliary support. For instance, in a Cut-in scenario, without side-view cameras, the surround-view camera needs to be used to improve the accuracy of predicting the cut-in of the car behind.

2) Function iterationThe previous solution of separating driving and parking mostly still adopts the traditional distributed architecture, which is basically not capable of supporting OTA function due to storage, hardware interface, and computing power limitations. In contrast, the integrated domain controller for driving and parking is equipped with 100M or even 1G Ethernet interface and more computing power to support advanced algorithm models, thus better supporting OTA upgrades.

3) Improving development efficiency

The integrated domain controller for driving and parking achieves software and hardware decoupling by deploying layered software architecture. The underlying basic software and standard middleware are pre-installed and made universal to be ported between different platforms. Meanwhile, based on the standardized middleware, the upper-layer interface is relatively stable, making it convenient and fast for automakers to carry out personalized and differentiated upper-layer application software development and iterative upgrades, thereby shortening the development cycle and improving development efficiency.

According to Si Zhengmin, product director of Zhixing Technology, the previous separation of driving and parking was equivalent to developing two systems, while the integrated domain controller solution integrated them into one. Talking about software architecture, the development of underlying basic software and middleware is actually very complex and time-consuming. Previously, it required two sets, but now one set suffices, and the upper layer can directly develop some differentiated application module software. Thus, the development efficiency will be improved to a certain extent.

4) Reducing costs and improving efficiency

First of all, the low-speed parking function is integrated into the driving controller, which not only reuses the computing power on the driving controller but also saves the hardware cost of the original parking controller. Secondly, it can simplify the I/O interface of the domain controller, reduce the length of wiring, and effectively reduce the complexity of the entire vehicle. In summary, it can help automakers reduce the entire production cost.

Domestic mainstream driving and parking integrated solutions

Desay SV – IPU02/IPU03/IPU04

1) IPU02

• A. Master chip: TDA4
• B. Operating system: Supports QNX, Linux, and AUTOSAR CP
• C. Interface:
• 6 GMSL
• 8 CAN
• 6 100M +1 1G vehicular Ethernet
• D. Function support:- Driving Functions: Adaptive Cruise Control (ACC), Automatic Emergency Braking (AEB), Lane Keeping Assist (LKA), Highway Assist (HWA), Navigation Guided Driving (NOA) on highways, etc.
• Parking Functions: 360 Surround View, Automatic Parking Assist (APA), Remote Parking Assist (RPA), Memory Parking (HPA), Valet Parking (AVP), etc.

2) IPU03

A. Main Control Chip: Xavier (NVIDIA) + Safety MCU (Infineon Aurix)

B. Operating System: Xavier uses QNX, MCU uses AUTOSAR CP

C. Interface:

• 12 channels of GMSL
• 12 channels of CAN
• 2 channels of LVDS
• 8 channels of 1G + 1 channel of 10G vehicular Ethernet

D. Function Support: Compared to IPU02, IPU03 supports enhanced AVP and high-speed NOA, as well as city area NOA and HWP functions.

3) IPU04

A. Main Control Chip: Orin (NVIDIA) + Safety MCU (Infineon Aurix)

B. Operating System: Orin chip uses QNX or Linux, MCU uses AUTOSAR CP

C. Interface:

• 16 channels of GMSL (up to 28 channels)
• 24 channels of CAN
• 4 channels of LVDS
• 12 channels of 100M + 12 channels of 1G + 1 channel of 10G vehicular Ethernet
• 2 channels of Flexray
• 2 channels of PCIe

D. Function Support: Compared to IPU03, IPU04 supports enhanced city area NOA and HWP functions.

Foryoungtech – ADC20/ADC25/ADC30

1) ADC20

A. Main Control Chip: TDA4 + Horizon J3

B. Operating System: Supports QNX, Linux and AUTOSAR CP

C. Interface: CAN/CAN-FD/ Ethernet / LVDS

D. Sensor Configuration: 6V5R12UE. Function Support: Navigation Assisted Driving NOA (Highway), Adaptive Cruise Control ACC, Lane Keeping Assist LKA, Automated Emergency Braking AEB, Automated Parking Assist APA, Remote Parking Assist RPA, and other features.

Zhixing Technology – IDC MID

1) IDC MID

A. Main Control Chip: Flexible adaptation to mainstream chips such as TDA4/EyeQ5H, and domestic chips such as Horizon J3.

B. Operating System: Supports Linux, AUTOSAR CP, etc.

C. Interfaces:

• 12 Camera Interfaces
• 8 CAN-FD
• 2 Gbps Ethernet

D. Sensor Configuration: 4R5V12U

E. Function Support: Navigation Assisted Driving NOA (Highway), Adaptive Cruise Control ACC, Automated Emergency Braking AEB, Memory Parking HPA, 360 Surround View, etc.

Neusoft Reach – Upgrade Version of Integrated Control for Driving and Parking

1) Upgrade Version of Integrated Control for Driving and Parking

A. Main Control Chip: TDA4 chip

B. Operating System: Supports Linux and QNX

C. Interfaces: Supports CAN-FD, LVDS, Ethernet 1000BASE-T, etc.

D. Sensor Configuration: 10V5R12U

E. Function Support: Navigation Assisted Driving NOA, Memory Parking HPA, Valet Parking AVP, etc.

Lightweight and High Computing Power Integrated Control for Driving and Parking

In the previous article Observations on Intelligent Driving Domain Controllers, it was mentioned that there are differences between the low-to-medium computing power (lightweight) integrated control for driving and parking and the high computing power integrated control for driving and parking, mainly from the perspective of market positioning and the demands of automakers. In this article, the author will talk about the differences between the two from a technical perspective.

1) Hardware Configuration

The lightweight integrated control for driving and parking is a cost-effective solution that mainly supports level L1～L2 driving assistance functions. Due to cost limitations, the lightweight domain controller generally uses a cost-effective AI chip with low-to-medium computing power, such as TDA4 and Horizon J3. The AI computing power of the entire domain controller is generally around tens of TOPS, and the number, type and performance of sensors that can be connected are limited. At present, the supported sensor configurations are mainly 4R5V12U or 5R5V12U.The large computing power domain controller is mainly installed in high-end car models as a technical highlight and brand promotion. Additionally, it also needs to have expandable functionality and requires embedded computing power. It may choose high computing power AI chips such as NVIDIA’s Orin X and Huawei’s Ascend 610. The overall computing power of the domain controller is generally above 200 TOPS, and some even cascade four high computing power chips together to achieve over a thousand TOPS. At the same time, it supports a larger number and more diverse types of sensors, and the sensors’ accuracy can also be higher. For example, the sensor configuration of NIO ET7 is 1L11V5R12U and adopts seven 8 million-pixel high-definition cameras and one hybrid solid-state lidar with a wavelength of 1550nm.

In summary, different system requirements lead to different choices in the sensor and system architecture solutions, which require different hardware platform interfaces and computing resources.

On the functional experience level, the lightweight domain controller and the high computing power domain controller can support similar functions, but with differences in some functional experience aspects. This not only depends on the type and number of sensors configured for the vehicle but also has a large relation to the algorithm models that can be deployed within the domain controller.

The high computing power domain controller can deploy larger and more complex algorithm models, and can cover more scenarios, so the resulting implemented functionalities in terms of safety and comfort will be better. For example, on the highway, the automatic lane changing function supported by the high computing power domain controller can run more in-depth neural network models for better perception performance, resulting in higher precision when changing lanes. On the other hand, the lightweight domain controller has limited computing power and can only deploy simplified algorithm models, which may result in a poor control of the timing of lane changing, and may even require the driver to intervene and confirm before changing lanes.

Li Maoqing, the design leader of the Junsheng Electronics intelligent driving system, believes that the reason for the functional experience differences between the lightweight and high computing power domain controllers is due to their different product positioning. Customers have different demands for the scenarios, function performance, product expansion, and safety requirements of these two types of products. For example, both require the implementation of high-speed navigation functions, but the details of the usage scenario and safety requirements may differ greatly, such as the requirement to avoid stationary obstacles at different speeds, which directly affects the perception scheme design and thus affects the domain controller’s scheme design. Another example is whether the dynamic driving task can be directly handed over to the driver during a system failure scenario, or if the system needs to realize parking by the roadside, which directly affects the hardware security architecture design of the intelligent driving system.

In terms of OTA updates, both types of domain controllers can have OTA updates for their software and algorithms to improve and optimize their performance.The lightweight domain controller has a higher coupling of software and hardware in order to maximize the use of limited computing power, and it needs to continuously refine its functions according to specific scenarios. While it can also be upgraded via OTA, it is mainly for optimizing performance and solving bugs, and adding new functions in later stages can be difficult due to insufficient computing power.

On the other hand, the high computing power domain controller has sufficient computing power to support extensive model optimization and multiple rounds of OTA upgrades, with strong scalability. With its powerful computing power, the optimized model can be deployed even without special compression and simplification. In contrast, the lightweight domain controller needs to carefully calculate the computing power required for the new model before OTA upgrades; otherwise, there may be embarrassing situations where the optimized model cannot be deployed.

From another perspective, the main purpose of the lightweight domain controller with medium-low computing power is to address current demands, while the high computing power domain controller is designed to address future unknown demands.

Development Trend of Integrated Domain Controllers for Automated Parking

Regardless of whether it is a lightweight integrated domain controller or a high computing power integrated domain controller, considering the overall development of domain controllers, the peripheral I/O interfaces, sensor configurations, and associated devices will gradually converge and eventually be standardized. But it is unlikely that the chips used internally by the controllers will be uniform, and some differentiation needs to be designed and developed for software and functionality implementation.

The main reasons are as follows:

1) Different OEMs need differentiated competition, and even for the same OEM, different vehicle models will still choose different hardware solutions;

2) To respond to the OEMs’ various needs, the chipset manufacturers’ Roadmaps will also develop differentiated selling points.

“First of all, the chips used by domain controllers from different OEMs are unlikely to be unified in one or a few chips. Secondly, even for the same OEM, the domain controllers used in different brand-positioned vehicle models cannot be exactly the same. From the past period, chip manufacturers have their own Roadmaps, and among different chip manufacturers, there will be some differentiated planning on the Roadmap to respond to the different needs of OEMs,” explained Dr. Liu Weibo.

Li Maoqing believes that “the integrated domain controller solution is moving towards standardization and platformization. Developing a standardized and platform-based domain controller can not only fully reuse R&D resources and reduce R&D costs for Tier1, but this process can also increase technical accumulation and understanding of these types of domain controllers, and establish technological brand influence. For automotive customers, a standardized hardware platform can not only greatly shorten the R&D cycle of the whole vehicle, but also improve scalability and solve cost and other issues.”

The Impact of Integrated Solutions on the Autonomous Driving Supply Chain.The separation of driving and parking systems is a product of the distributed architecture phase. During this phase, Tier1 occupies a dominant position, and hardware and software are directly supplied to OEMs in a bundled manner. The supply chain is relatively simple, belonging to a “linear” supply relationship: software suppliers/chip suppliers Tier2 → component integrators Tier1 → OEMs.

The integrated driving and parking system is a product of the centralized domain architecture phase. In this phase, the traditional “linear” supply relationship is broken, and the supply system develops from “line” to “plane”, forming a network centered on the OEM and making cooperation among various parties on the industrial chain more open and diverse.

OEM

The system solutions for separated driving and parking schemes are basically “black box” mode, and it is difficult for automakers to decompose and bid. In contrast, integrated driving and parking systems break this pattern and make cooperation between OEMs and suppliers more flexible and diverse. At the same time, more and more automakers are no longer satisfied with just being a “system integrator” role and hope to have customization capabilities for the entire system and supply chain. For example, OEMs will directly establish strategic partnerships with chip companies to customize development of chips in the domain controller.

According to Xia Tian, an expert in intelligent driving systems at Geek+, in the past, driving and parking systems were two different systems, where a package supplier was usually selected for parking and a different package supplier was selected for driving. Now, with integrated driving and parking, the participation of OEMs will be higher, and the selectivity will be greater. A large system can be divided into multiple packages: sensors, controllers, system integration, application software development, etc. OEMs will do the necessary and feasible parts, and hand over parts that are unnecessary or cannot be done to different suppliers. Overall, the way OEMs and suppliers cooperate has become more flexible and diverse.

“In the past mode of cooperation, Tier1 provided a complete hardware and software solution to OEMs, and OEMs did not have a strong tendency in choosing controller chips. But now, because automaker customers have put forward more and higher requirements for the development and extensibility of the system, they will have a stronger tendency to choose domain controller chips. So, the phenomenon of automaker customers choosing corresponding Tier1 companies for cooperation based on the chips they have chosen has emerged,” said Li Maoqing. “Now, the understanding of automakers for domain controller chips is actually deeper than we imagine. On the one hand, chip manufacturers and automakers provide technical support through strategic cooperation to help automaker customers understand related product technology. On the other hand, the talent flow in the entire smart driving industry is very large, and automakers have gradually accumulated expertise in technology fields such as chips and basic software through talent team building.”

Tier1## The Impact of Integrated Parking and Driving Systems on the Automotive Industry

The mass production of integrated parking and driving systems, also known as domain controller architecture, has brought a significant impact on traditional Tier1 companies. In the past, these companies relied on the core technologies and driving forces of component manufacturers in the supply chain. These companies would supply the components, and the automakers would incorporate them into their vehicles to sell. With the upgrade and transformation of electronic and electrical architecture and the gradual standardization of hardware, the software has been extracted from the hardware, and the decoupling of software from hardware has made it possible for software to define the car. Therefore, automakers are becoming more strongly motivated to acquire the ability to define software-defined cars, hoping to gradually regain the long-awaited “leadership” from Tier1 companies. At the same time, Tier1s are also vertically integrating and developing full-stack software and hardware capabilities, transitioning from system integrators to system solution providers in order to maintain their dominant position.

According to Zhengmin Si, the application of integrated parking and driving systems is indeed forcing some Tier1 companies to pursue transformation. For example, Tier1s that used to only focus on parking solutions are now actively trying out driving solutions. Traditional Tier1s excelled in hardware development and now need to continue to break through and strengthen hardware development innovation capabilities. Highly integrated domain controllers also promote the reconstruction of the development ecosystem. The traditional vertically integrated linear industrial chain structure will gradually evolve into a layered, decoupled, shared, and cross-domain 3D network-like ecosystem, promoting the integration of the new ecosystem and driving its continued evolution.

Chip Industry

The chip industry has become more active in the autonomous driving supply chain. Chip companies now directly face automakers to help Tier1s obtain projects, or directly cooperate with automakers. Through this form of direct interaction, chip companies not only can demonstrate their chip capabilities to automakers but also can directly obtain the needs of automakers, such as domain controller scalability requirements, chip interfaces, computing resources, and other requirements. This approach allows chip companies to adjust their product strategy more promptly.

In addition, to fully exploit the “capabilities” of chips, chip companies have also started to lay out on the software level, committed to providing their customers with full software and hardware solutions. Examples include NVIDIA’s open-source software stack NVIDIA DRIVE, Snapdragon Ride from Qualcomm, which includes security middleware, operating systems, and drivers, Horizon Robotics’ AI open platform-Tiangong Kaiwu, which mainly includes three functional modules: model repository, AI chip toolchain, and AI application development middleware, and Hanzhima’s Hanhai ADSP autonomous driving middleware platform.

This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.