Source: Liu Bibo, Cheng Changchun / Dongfeng Motor Technology Center & Qoros Auto Research Institute
As domestic and foreign OEMs gradually reach a consensus on smart vehicles, endowing cars with new missions, the application scenarios for vehicles have become increasingly rich, leading to more direct interactions between users and vehicles. The increase in usage scenarios poses more challenges to the normal operation of in-vehicle infotainment systems. By analyzing the load of key components in the system, engineers can guide the selection of core components and optimize software strategies to enhance system smoothness, aligning with market user demands.
1. System Architecture Composition
1.1 Hardware Block Diagram
Refer to a simplified hardware architecture diagram of a central vehicle control unit from an OEM (Figure 1).
Figure 1 Hardware Block Diagram
The architecture of the central multimedia entertainment system mainly includes the main CPU, touchscreen, MCU, DSP, amplifier, WIFI module, BT Bluetooth module, GPS antenna module, radio AM/FM module, CAN transceiver, USB interface, etc. Each independent functional chip mainly participates in signal transmission, analysis, and optimization, having a minor impact on system smoothness, which is primarily influenced by the core processor that comprehensively processes user and external input signals. The performance of the main processor has a significant impact on system operation speed. By testing the load of the main processor and the memory usage status of each application, suitable components can be selected to reduce design flaws, avoid resource waste, and effectively control costs.
1.2 Application Working Principle
Figure 2 Application Working Principle
Figure 2 illustrates the application working principle. When the Linux system starts, it loads basic system information from ROM and launches the main program through a bootloader. When an application is awakened, it searches for application data in L1/L2 cache data, and if the required data is found, it quickly starts the application; otherwise, it calls and runs application data from storage memory via running memory.
Since the cache module is encapsulated within the main processor, during the entire process from waking an application to running it, the main hardware modules involved are: functional module chips, CPU, running memory, and storage memory. The functional module chip receives raw signals and converts them into A/D signals for input to the CPU, which drives the display through bottom software to show and amplify sound. Due to the numerous functional modules, this article will not delve deeply into them, focusing instead on the optimization solutions of the system from three dimensions: CPU, running memory, and storage memory.
2.1 CPU Load Distribution
The CPU load varies across different scenarios for the same application. Inputting the command on a fully functional prototype: adb shell top -m 10 -s cpu, the maximum CPU load data for each application and corresponding scenarios are shown in Figure 3.
According to the above data statistics, considering user usage habits, the following two common usage scenarios exhibit high CPU loads.
1) Radio + Navigation + Voice Assistant + Dual-Screen Interaction, load 79%.
2) Navigation + Calendar + Voice Assistant + Dual-Screen Interaction, load 86%.
Typically, the underlying software running monitoring will also occupy a small amount of resources (<2%). When the load is too high, invoking other applications, such as clicking multimedia keypads, playing HD media sources, Bluetooth calls, etc., will lead to insufficient CPU resources, resulting in system sluggishness.
During the project planning stage, it is necessary to statistically analyze in-vehicle applications based on the maximum CPU load measured in experiments, cost, and future OTA upgrade requirements to select the CPU. CPU optimization typically considers the following two points.
1) When the CPU is under a high load condition (CPU usage at 90%), if an application occupying 20% CPU is activated, under normal circumstances, the application would take 1 second to wake up and start. However, due to insufficient CPU resources, the application invocation time doubles to 2 seconds, resulting in perceived delays. Although subsequent code architecture optimization can alleviate this, it cannot fundamentally resolve the issue of system sluggishness. Therefore, when selecting hardware, it is necessary to estimate the maximum load of the CPU and choose the processor accordingly.
2) Currently, the industry generally designs CPU loads not to exceed 70%. After determining the CPU model, it is essential to ensure stable CPU operation. Production processes, hardware circuits, and structural heat dissipation can all affect CPU operation; prolonged operation may lead to increased local temperatures within the main unit, causing CPU throttling and reduced computing power. Optimizing CPU heat dissipation through reasonable mechanical structure and hardware circuit layout is crucial to ensure good CPU operation.
3.1 Running Memory Load Distribution
Similar to CPU load, invoking adb commands on a fully functional prototype directly shows the memory usage of each module. Inputting the command: adb shell dumpsys meminfo, the simulated memory usage of each application is shown in Figure 4.
Figure 4 Running Memory Load
For a system designed with 2G (2048M) running memory, the actual memory occupied by simulated application startup using adb commands is 931M. Selecting 1G (1024M) memory can meet system requirements, but insufficient memory reservation may lead to insufficient capacity during subsequent program upgrades, causing system lag. Thus, it is necessary to consider costs and current memory usage status to select an appropriate memory size.
3.2 Running Memory Optimization
Currently, the market reference for vehicle-mounted DDR3 memory size and pricing is as follows: 1G memory costs 96 yuan, while 2G memory costs 130 yuan.
In summary, considering future OTA upgrades and application updates, along with current memory market prices, selecting 2G running memory meets the current design scheme and supports future iterative upgrades, providing the best cost-performance solution.
4.1 Storage Memory Load Distribution
Application data is usually stored in eMMC (Embedded Multi MediaCard) storage, which typically holds system application data, offline map data from Gaode, voice package data from iFlytek and Baidu, regular system application data, and test LOG files, as referenced in Figure 5.
Figure 5 Storage Memory Load
In hardware architecture design, the storage is generally divided into system and user areas. The system area typically reserves some space for system updates and temporary caching of system data. The actual data size of the system application for a certain project is 3.18G, with 4G reserved; the user area has Gaode offline maps occupying 7.19G, and iFlytek offline voice packages occupying 0.48G, while regular system applications generally occupy less space, mainly taken up by third-party apps like Kuwo Music and debugging LOG data.
Before determining the system hardware scheme, while map data and voice data occupy a significant amount, they generally fluctuate less. In contrast, regular system application data occupies very little. Therefore, during design optimization, attention must be paid to LOG interface data and third-party download data to avoid insufficient system storage space, which could impact system operation.
4.2 Storage Memory Optimization
For functional module LOG interface data, printing permissions can be restricted from a software architecture perspective. When a specific functional module needs to be developed or debugged, permission must be requested, while the main program monitors memory status, displaying real-time memory status through a floating window. An alarm will trigger through a pop-up window when memory usage exceeds the threshold.
Currently, third-party applications are increasingly used in in-vehicle multimedia, most of which do not impose restrictions on user downloads. The optimization methods include: 1) Similar to mobile phones, when the download data exceeds the memory threshold, the system prompts to clean up memory and displays the download usage status for each application; 2) Third-party software self-optimization, taking the Kuwo app as an example, when the number of downloaded tracks reaches a set limit (100 tracks) or memory usage exceeds the threshold, further downloads will default to overwrite the earliest downloaded tracks.
