Method, device and equipment for optimizing starting KPI (Key Performance Indicator) of central control system of in-vehicle infotainment system

Abstract

The invention provides a KPI (Key Performance Indicator) optimization method, device and equipment for starting a central control system of an in-vehicle infotainment system, and relates to the technical field of KPI optimization for starting the central control system of the in-vehicle infotainment system, and the method comprises the steps: obtaining the time data of a preset key node and the hardware parameters of the in-vehicle infotainment system in the power-on starting process of a target in-vehicle infotainment system; through a preset AI analysis model, based on the time data of the preset key node and the vehicle machine hardware parameters, generating a starting optimization strategy corresponding to the chip of the target vehicle machine central control system; through a preset optimization generator, converting a starting optimization strategy corresponding to the chip of the target in-vehicle central control system into an executable scheme; pushing the executable scheme to a target object; the target object optimizes the starting process of the target central control system through the executable scheme; according to the method and the device, the aim of automatically and efficiently optimizing the start KPI of the vehicle machine central control system can be achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of KPI optimization of vehicle head unit control system startup, and in particular relates to a KPI optimization method, device and equipment for vehicle head unit control system startup. BACKGROUND

[0002] In the development and application of the vehicle head unit IVI Android system, the system startup time is a key indicator affecting user experience and product market competitiveness, and its optimization is crucial. A typical Android system startup needs to go through multiple stages, including loading the system startup program from the ROM, initializing the basic hardware driver and clock setting of the bootloader, loading the system driver and starting the Android init process of the kernel, starting the zygote, system server and other important system services (including AMS, WMS, PMS, etc.) in the user space from the init process, and then starting the system Launcher to display the desktop to complete the startup.

[0003] The current industry relies on tools such as systrace and bootchart to analyze and optimize the Android system startup time, and manually or semi-automatically analyzes the problem after adding logs in the startup key path or module. Although this method can identify startup bottlenecks to some extent, it has significant technical problems: first, the analysis period is long, the log collection needs to restart the device multiple times, and the massive data needs to be manually analyzed, which is easy to introduce human errors or omissions, resulting in an iteration period from problem discovery to optimization that may be extended to several weeks; second, in the process of continuous development of the project, the introduction of new functions such as audio drivers and specific system services may cause startup performance regression problems such as kernel driver loading conflicts and init service dependency changes, which may offset the previous optimization effect and require repeated verification and debugging by the team; third, the cross-device adaptability is poor, and in the multi-hardware variation scenario of the vehicle head unit Android system (such as using SoC chips from different suppliers such as Qualcomm, NXP, and TI), log analysis is difficult to form a standardized process, and the analysis results are often limited to a single device, which cannot be efficiently applied to multiple vehicle models; fourth, there is a lack of real-time reporting and centralized analysis mechanism, and the development is mainly dependent on local tools, which leads to low collaboration efficiency of the development team, ultimately lengthening the overall project cycle, increasing the delivery pressure, and even adversely affecting the product launch time and cost control; therefore, how to automatically and efficiently optimize the KPI of the vehicle head unit control system startup has become a technical problem to be solved. SUMMARY

[0004] To solve the above technical problems, the technical solution adopted by the present application is as follows: According to the first aspect of the present application, a KPI optimization method for vehicle head unit control system startup is provided, comprising: Obtain time data of preset key nodes in a power-on starting process of a target car machine central control system and car machine hardware parameters; the car machine hardware parameters at least include a chip model; Generate a starting optimization strategy corresponding to a chip of the target car machine central control system through a preset AI analysis model based on the time data of the preset key nodes and the car machine hardware parameters; the AI analysis model is obtained through gradient training of a local model corresponding to different car machine ends; Convert the starting optimization strategy corresponding to the chip of the target car machine central control system into an executable scheme through a preset optimization generator; Push the executable scheme to a target object; and enable the target object to optimize the starting process of the target central control system through the executable scheme.

[0005] Further, the preset key nodes include a bootloader stage, a kernel stage and an init stage; the time data and the car machine hardware parameters are obtained through a lightweight acquisition module embedded in the target car machine central control system.

[0006] Further, after obtaining the time data and the car machine hardware parameters, the method further includes preprocessing the time data; The preprocessing includes: eliminating abnormal values, arranging the time data into a time sequence format, and generating a starting reference curve corresponding to the target car machine central control system vehicle model based on the preprocessed time data.

[0007] Further, the training process of the AI analysis model includes: Obtain encrypted gradients corresponding to each car machine end; the encrypted gradients are generated by training the time data and the hardware parameters collected by the local Tiny ML model of the corresponding car machine end; Aggregate the encrypted gradients through a Fed Avg algorithm to generate the preset AI analysis model.

[0008] Further, the starting optimization strategy includes at least one of a driving loading optimization and a service starting optimization for the chip model of the target car machine central control system; The driving loading optimization includes: preferentially initializing a core device driver or asynchronously loading a non-core driver; The service starting optimization includes: merging an attribute file or adjusting an init stage service starting priority.

[0009] Further, the executable scheme includes at least one of an optimization report, a code patch template and a system configuration modification instruction.

[0010] Further, the target object includes the target car machine central control system or a development end. In the case that the executable scheme is a system configuration modification instruction, the system configuration modification instruction is pushed to the target vehicle machine control system, and the target vehicle machine control system automatically applies the system configuration modification instruction to make the optimization effective next time when starting; In the case that the executable scheme is an optimization report or a code patch template, the executable scheme is pushed to the development end for reference.

[0011] Further, in the case that the target vehicle machine control system is in a data sensitive scene, the method further includes the step of optimizing the starting KPI in combination with a snapshot starting recovery process: When the target vehicle machine control system is shut down or restarted, the core state data from the system starting to the completion of the kernel initialization and before the loading of the user space private data is captured and stored persistently in a non-volatile storage medium. Next time when starting, in the case that the core state data is detected, the core state data is directly recovered, and the complete initialization process of the bootloader and the kernel is skipped.

[0012] According to another aspect of the present application, a vehicle machine control system starting KPI optimization device is also provided, and the device includes: A data acquisition module is configured to acquire time data of preset key nodes and vehicle machine hardware parameters in a starting process of a target vehicle machine control system; the vehicle machine hardware parameters at least include a chip model; An AI analysis module is configured to generate a starting optimization strategy corresponding to a chip of the target vehicle machine control system based on the time data of the preset key nodes and the vehicle machine hardware parameters through a preset AI analysis model; the AI analysis model is obtained through gradient training of a local model corresponding to different vehicle machine ends; A strategy conversion module is configured to convert the starting optimization strategy corresponding to the chip of the target vehicle machine control system into an executable scheme through a preset optimization generator; A scheme pushing module is configured to push the executable scheme to a target object; so that the target object optimizes the starting process of the target control system through the executable scheme.

[0013] According to another aspect of the present application, an electronic device is also provided, which includes a processor and the above-mentioned vehicle machine control system starting KPI optimization device.

[0014] The present application has at least the following beneficial effects: The car machine central control system startup KPI optimization method of the present application, by automatically acquiring the time data of the startup key node and the hardware parameters such as the chip model, does not need to manually collect logs by restarting the device multiple times, greatly shortening the problem positioning time; with the help of the AI analysis model based on the gradient training of the local model of the multi-car machine end, personalized startup optimization strategies can be generated for different chip models, effectively adapting to the multi-hardware variation scene of the car machine, avoiding the limitation of the optimization scheme caused by hardware differences, and reducing the startup performance regression impact when introducing new functions; through the strategy optimization generator, the strategy is converted into an executable scheme and pushed to the target object, realizing efficient connection from data collection to optimization landing, reducing the cost of manual intervention, improving the development team collaboration efficiency, and finally efficiently optimizing the car machine startup KPI, shortening the startup time, so as to achieve the purpose of automatically and efficiently optimizing the car machine central control system startup KPI. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0016] Figure 1 The flowchart of the car machine central control system startup KPI optimization method provided by the embodiment of the present application is provided. Figure 2 The Android startup process schematic diagram provided by the embodiment of the present application is provided. Figure 3 The implementation architecture / topology schematic diagram of training and feedback by multiple models provided by the embodiment of the present application is provided. Figure 4 The function of each module and the specific interaction timing schematic diagram provided by the embodiment of the present application are provided. Figure 5 The snapshot startup / resume process schematic diagram provided by the embodiment of the present application is provided. DETAILED DESCRIPTION

[0017] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0018] It is noted that, based on the present disclosure, one skilled in the art will appreciate that one aspect described herein can be implemented independently of any other aspects and that two or more of these aspects can be combined in any suitable manner. For example, an apparatus can be implemented and / or a method can be practiced using any number of the aspects set forth herein. In addition, such an apparatus can be implemented and / or such a method can be practiced using other structure and / or functionality in addition to or other than one or more of the aspects set forth herein.

[0019] Reference will now be made to the drawings Figure 1 A flowchart of a vehicle head unit control system startup KPI optimization method is shown, and a vehicle head unit control system startup KPI optimization method is introduced.

[0020] In this embodiment, the relevant English terms are explained as follows: IVI: In-Vehicle Infotainment, vehicle entertainment system; KPI: the shortest time requirement required for system startup; FedAvg: Federated Averaging, the core algorithm of federated learning, used to train machine learning models on distributed devices; SHAP: SHapley Additive exPlanations, an explanatory AI technology used to explain the prediction results of machine learning models; TinyML: Tiny Machine Learning, a method for implementing AI inference on resource-constrained devices without relying on cloud computing.

[0021] Currently, the analysis of Android system startup time is mainly assisted by some tools such as systrace and bootchart, and logs are added in the key path or module of system startup for analysis and positioning. A typical Android system startup generally involves the following stages: a. Load the hardened system startup program from ROM; b. Start bootloader, initialize the most basic hardware driver, and set the clock; c. Kernel startup, load system driver, responsible for starting Android init process; d. Start Android userspace, starting from the init process, successively start zygote, systemserver and other important system services, including AMS, WMS, PMS, etc.; e. Start system Launcher, show desktop, system startup is completed.

[0022] The common Android boot process is as shown in FIG. 1, and each stage will focus on some specific optimization points, for example: Figure 2 Bootloader optimization: Trim unnecessary functions, such as unnecessary file systems, USB functions (not necessary on the car machine); hardware parallel initialization; clock frequency adjustment. Kernel optimization: Kernel configuration trimming; driver loading optimization, modularizing or delaying loading of modules that are not urgent at startup; turning off unnecessary kernel debugging options.

[0023] User space optimization: init script optimization, service reduction, phased startup, and zygote startup optimization, loading only the most core services.

[0024] The existing analysis scheme will analyze suspicious points step by step through log recording and tool assistance in the above-mentioned boot stages, and ultimately achieve the purpose of optimizing the startup time.

[0025] Based on the above description, the car machine control system startup KPI optimization method in the embodiment from the product side is as follows: In the field of automotive products, the startup time of the system is a key indicator that affects user satisfaction and market competitiveness. For automotive users, the ability to quickly operate the center control screen (IVI system) after the vehicle is started directly determines whether they can efficiently enter the driving mode, such as quickly setting navigation to the destination, viewing the reversing image, adjusting the air conditioning or entertainment system, and other basic needs. These functions often require the system to be ready before they can respond, and if the startup time is too long (such as more than 30 seconds), users may face safety hazards (such as distraction waiting) or inconvenience, leading to negative experiences and even loss of potential customers. According to industry data, for every second saved in startup time, user satisfaction can be improved by about 5-10%, and in the current electric vehicle market, a system cold startup speed of about 10 seconds has become an industry benchmark. Long waiting times not only damage brand image, but also may exacerbate problems in the highly competitive electric vehicle market. This technical solution directly addresses these pain points through automated monitoring and AI-driven optimization mechanisms.

[0026] From a technical perspective, the car machine control system startup KPI optimization method of the embodiment can include the following steps: S100, obtain the time data of the preset key nodes in the power-on startup process of the target car machine control system and the car machine hardware parameters; the car machine hardware parameters at least include the chip model.

[0027] S200, based on the time data and the car machine hardware parameters, determine the optimization strategy for the target car machine control system; and

[0028] Further, the preset key nodes include a bootloader stage, a kernel stage, and an init stage; and the time data and the vehicle machine hardware parameters are acquired by a lightweight acquisition module embedded in a target vehicle machine central control system.

[0029] The overall architecture of the scheme in the embodiment adopts an end-cloud collaborative mode to ensure an efficient monitoring, analysis, and optimization closed loop. The vehicle machine device end is responsible for data acquisition and preliminary processing, the cloud (server) handles aggregation analysis and AI training, and feedback optimization strategies are returned to the device.

[0030] The time data of the preset key nodes and the vehicle machine hardware parameters in the power-on starting process of the target vehicle machine central control system can be acquired by the vehicle machine device end component. A timestamp acquisition module can be embedded in an Android kernel and a user space, a kprobe hook or a custom log mechanism is used, and accurate time (microsecond level) is recorded at bootloader (LK / U-Boot initialization completion), kernel (initramfs loading), and init (Zygote fork) nodes. The module is lightweight designed, only increases <1% CPU overhead, and supports automatic enabling in the development mode.

[0031] For example, in the bootloader stage, a gettimeofday() function is inserted in the boot code to record a timestamp, and the “partition verification completion time” (220 ms) and the “kernel jump time” (180 ms) are captured; in the init stage, an init.rc script is modified to add log-t init-time$(date+%s%N) to record the Zygote process fork time (1500 ms).

[0032] Through this step, the performance overhead caused by “manual addition of logs” in the prior art is avoided, and the key nodes are fixed to ensure that the data acquisition standards of different vehicle machines are unified, and consistent data is provided for subsequent AI model training.

[0033] The preset key nodes correspond to three core stages of Android startup, and specifically include: Bootloader stage: collect partition verification completion time, kernel jump time (such as LK / U-Boot initialization completion node); Kernel stage: collect initramfs loading completion time, core driver (camera, audio) loading completion time; Init stage: collect Zygote process fork time, AMS / WMS system service startup time.

[0034] Data precision and hardware parameters: time data is in microseconds (to ensure bottleneck positioning accuracy); hardware parameters of the car machine include battery status (to avoid abnormal data interference caused by unstable power supply) in addition to the "chip model" (such as Qualcomm 8155, TI Jacinto7, NXP i.MX8); the collection trigger timing is "first start after new function integration" or "first start after new Dailybuild generation" to avoid uploading redundant data.

[0035] For example: take a car machine with Qualcomm 8155 chip as an example: after power-on, the lightweight module automatically records: Bootloader phase: partition verification takes 220ms, kernel jump takes 180ms; Kernel phase: initramfs loading takes 350ms, camera driver loading takes 900ms, and audio driver loading takes 600ms; Hardware parameters: chip model "Qualcomm 8155", battery status "95% (full power)".

[0036] Through this step, the problems in the prior art of "relying on manual log collection (such as systrace / bootchart), long analysis period (requiring multiple device restarts), and easy introduction of human error" are solved: automatic collection without human intervention, subsequent simulation tests show that "problem positioning time is greatly shortened, and microsecond-level precision avoids node omission, providing accurate data basis for subsequent AI analysis.

[0037] Further, after obtaining the time data and hardware parameters of the car machine, the time data is preprocessed; the preprocessing includes: removing outliers, arranging the time data into a time series format, and generating a startup reference curve for the corresponding target car machine central control system model based on the preprocessed time data.

[0038] In this embodiment, the cloud performs two-step processing on the collected time data: Remove outliers (such as data with "kernel phase time suddenly increased to 5s" due to hardware failure); Arrange into a time series format (sort by startup phase for easy comparison); Startup reference curve: based on preprocessed data of the same model and the same chip, generate "each node normal time interval curve" (such as bootloader phase normal time 150-250ms), store in cloud Prometheus database, and support visual dashboard viewing.

[0039] For example, based on the collected data of 100 high-pass 8155 chip vehicles, after excluding 3 abnormal data caused by battery failure, the benchmark curve of "kernel phase normal time consumption 800-1200ms" is sorted out; when the kernel phase time consumption of a high-pass 8155 vehicle is 1600ms, the model can quickly identify it as "timeout node".

[0040] Through this step, the problem of "chaotic data, difficult to judge whether the startup is abnormal" in the prior art can be solved: the benchmark curve provides "normal startup standard" for the AI model to avoid misjudgment, and the preprocessed time series data can improve the model training efficiency.

[0041] S200, based on the time data of the preset key node and the hardware parameters of the vehicle machine, a startup optimization strategy corresponding to the chip of the target vehicle machine central control system is generated through a preset AI analysis model; the AI analysis model is obtained through gradient training of the local model corresponding to different vehicle machine ends.

[0042] In this embodiment, the preset AI analysis model first compares the time data of the target vehicle machine with the "startup benchmark curve" (the normal time consumption interval curve of the same vehicle type stored in the cloud Prometheus database) of the same chip model, locates the timeout node (such as "high-pass 8155 vehicle camera driver loading time consumption exceeds the benchmark 500ms"), and then outputs a personalized strategy in combination with the chip hardware characteristics.

[0043] For example: for high-pass 8155 chip vehicles, the model finds that the "kernel phase camera driver loading time consumption is 900ms (benchmark 400ms)", and generates the strategy "preferentially initialize the camera driver, which can shorten the kernel phase by 1.5s" in combination with the high-pass chip driver compatibility characteristics; For TI Jacinto7 chip vehicles, the model finds that "the kernel phase non-core driver (such as vehicle-mounted WiFi driver) and the core driver are loaded in parallel, causing conflict, and the total time consumption increases by 300ms", and generates the strategy "asynchronous loading of non-core driver, which can shorten the kernel phase by 15% time".

[0044] Through this step, the problems of "difficult to adapt to multiple hardware variation scenarios (different chip solutions need to be repeatedly debugged), and new functions are easy to cause performance regression" in the prior art can be solved: the model generates differentiated strategies for high-pass, TI, NXP, etc. Chips, adapt to OEM multi-supplier cooperation scenarios; at the same time, through benchmark curve comparison, it can identify the driver conflict caused by new functions (such as ADAS integration) in real time, and output optimization strategies in advance to avoid the optimization effect being offset.

[0045] Further, the training process of the AI analysis model includes: S210, obtain the encrypted gradient corresponding to each vehicle terminal; the encrypted gradient is generated by training the time data and hardware parameters collected by the local TinyML model of the corresponding vehicle terminal.

[0046] In this embodiment, each vehicle terminal trains the collected time data and hardware parameters by the local TinyML model to generate an encrypted gradient (containing only model parameter update information, not containing original data); this can be achieved in the following way: Lightweight timestamp collection module: embedded in the kernel and user space of IVI Android system in advance, completes the collection of "bootloader / kernel / init phase microsecond-level time data" and "chip model (such as Qualcomm 8155), battery status", and the data has been stored in the special partition of the vehicle terminal local non-volatile storage (such as eMMC) (to avoid mixing with user data and reduce privacy risks).

[0047] Tiny ML model deployment: the vehicle terminal preloads a lightweight neural network model (such as a simplified MobileNet and a linear regression model) suitable for resource-limited scenarios, the model parameter size is controlled within 100 KB, the CPU single round training overhead is less than 1%, and it is only enabled in "development mode" to avoid occupying resources when used by users.

[0048] To ensure that the trained gradient is effective and focused on starting the bottleneck, the vehicle terminal first performs local preprocessing on the collected original data, including: Outlier elimination: invalid data (such as kernel phase time consumption suddenly increasing from 1.2s to 5s) caused by temporary hardware failure (such as unstable battery power supply during a startup) is eliminated by simple threshold rules (such as "time data of a certain phase exceeding 3 times the historical average of the same chip vehicle model is determined as an outlier"). Data standardization: convert "microsecond-level time data" into "relative time consumption ratio" (such as "kernel phase time consumption 1.2s, accounting for 30% of total startup time"), and convert "chip model" into One-Hot encoding (such as Qualcomm 8155 corresponding to [1, 0, 0], TI Jacinto 7 corresponding to [0, 1, 0]), to ensure that the data format meets the input requirements of the TinyML model; Data slicing: only extract "strongly related features" (such as bootloader phase partition verification time, kernel phase core driver loading time, and init phase Zygote startup time) and discard irrelevant data (such as APP operation logs during user use), to further compress the training data volume.

[0049] The vehicle machine end completes single-round local training through a Tiny ML model based on pre-processed data, the core of which is to learn the corresponding relationship between "time data - start-up bottleneck", and generate original gradient reflecting "model parameter adjustment direction": The model takes "locating start-up bottleneck node + predicting optimization space" as the target, and sets the loss function as "the square sum of the difference between the time consumption of the current vehicle machine at a certain stage and the normal time consumption of the vehicle model with the same chip (simplified start-up benchmark value pre-stored locally)", that is, through training, the model learns "when the time consumption at a certain stage exceeds the benchmark, which parameters need to be adjusted to locate the bottleneck".

[0050] Model training process: Input layer: receives pre-processed features (such as "bootloader time consumption 220ms, kernel core driver time consumption 800ms, chip model code [1, 0, 0]"); Hidden layer: through 1-2 layers of fully connected layers (to reduce computational load), linear transformation and activation (using ReLU activation function to reduce resource consumption) are performed on the input features; Output layer: outputs "bottleneck probability of each start-up stage" (such as "kernel stage bottleneck probability 90%, init stage bottleneck probability 10% "); Gradient calculation: using stochastic gradient descent (SGD) algorithm, taking "minimizing loss function" as the target, calculating the partial derivative of each parameter (such as fully connected layer weight, bias) of the model to the loss function, to get "original gradient" (reflecting "the magnitude and direction of each parameter adjustment to reduce loss"); Training termination condition: the number of single-round training iterations does not exceed 10 (to avoid long vehicle machine resource occupation), or the loss function value decreases to the preset threshold (such as "difference < 50ms") to stop, ensuring that the training is completed quickly.

[0051] In this embodiment, the vehicle machine end encrypts the original gradient, the core of which is "only encrypting gradient data, without involving any original time / hardware data", and the encryption process includes: Encryption algorithm selection: using lightweight symmetric encryption algorithm (such as AES-128), the key is determined by the vehicle machine end and the cloud through "preset key when the device is shipped + dynamic negotiation" (to avoid key transmission leakage); Encryption range: only "gradient value of model parameters" (such as "fully connected layer weight gradient -0.02, bias gradient 0.01") is encrypted, without any identifier that can be associated with original data (such as not containing vehicle machine SN number, specific timestamp); Encrypted data format: The encrypted gradient is stored in the form of "binary stream", the size is controlled within 1KB (to facilitate fast upload and reduce network transmission overhead), and the data header only contains "chip model code (such as [1, 0, 0])" (to classify and aggregate by chip model in the cloud for generating strategies suitable for different chips).

[0052] Through the above steps, only encrypted gradients are uploaded without any original time / hardware data, which meets the needs of military and privacy-priority vehicles; Tiny ML model + lightweight encryption, CPU overhead < 1%, avoiding affecting the normal startup and function use of the vehicle; Encrypted gradients are classified by chip model, supporting the cloud to generate a global model covering multiple chips through the Fed Avg algorithm, solving the problem of adaptation difficulty in multiple hardware variation scenarios.

[0053] S220, aggregating the encrypted gradient through the Fed Avg algorithm to generate the preset AI analysis model.

[0054] The cloud weights and averages the encrypted gradients of multiple vehicle machines through the Fed Avg algorithm to generate a global AI analysis model, and the aggregation process does not touch the original data.

[0055] For example: 100 different chip vehicle machines (30 high-potential, 40 TI, and 30 NXP) train local Tiny ML models respectively, generate encrypted gradients, and upload them to the cloud; the cloud aggregates the gradients through the Fed Avg algorithm to generate a global model that can adapt to three types of chips at the same time.

[0056] Through this step, the problems of "data privacy leakage risk (uploading original data) and repeated training of multiple vehicle models" in the prior art can be solved: encrypted gradients ensure privacy, global models cover multiple chips, and model development costs are reduced.

[0057] Further, the startup optimization strategy includes at least one of drive loading optimization and service startup optimization for the target vehicle machine central control system chip model. The drive loading optimization includes: preferentially initializing core device drivers or asynchronously loading non-core drivers.

[0058] The service startup optimization includes: merging attribute files or adjusting the service startup priority in the init phase.

[0059] Drive loading optimization: preferentially initializing core device drivers (such as camera and reverse image drivers to ensure user core needs); asynchronously loading non-core drivers (such as WiFi and Bluetooth drivers to avoid occupying core startup time).

[0060] Service startup optimization: merge property files (reduce the number of init phase property loading times, such as merging 3 independent property files into 1); adjust the service startup priority in the init phase (such as improving the priority of navigation service to respond to user demand in advance).

[0061] For example: for NXP i.MX 8 chip vehicle, model discovery "init phase loads 5 property files, total time 1.8s", generate strategy "merge property files, expected to reduce 1.5s startup time"; for Qualcomm 8155 vehicle, generate strategy "adjust the initialization order of the reversing image driver, from 5th to 2nd, shorten the startup time by 800ms".

[0062] Through this step, the optimization strategy is more specific and can be implemented, avoiding the execution difficulty caused by the vague strategy in the prior art (such as 'optimize driver loading'), and the developer can directly implement the optimization according to the type to improve the landing efficiency.

[0063] S300, through the preset optimization generator, the startup optimization strategy corresponding to the chip of the target vehicle control system is converted into an executable scheme.

[0064] Further, the executable scheme includes at least one of an optimization report, a code patch template, and a system configuration modification instruction.

[0065] In this embodiment, the preset optimization generator includes three types of core components: Strategy analysis engine: built-in "chip model-strategy type" mapping library (such as Qualcomm 8155 corresponding to "driver loading optimization", TI Jacinto 7 corresponding to "service startup optimization"), which can extract key information in the AI model output strategy (such as "optimization object=kernel phase camera driver, optimization action=priority initialization, expected benefit=shorten 1.5s").

[0066] SHAP explanatory module: through SHAP (SHapley Additive exPlanations) value calculation, "strategy logic explanation" is generated (such as "why does priority initialization of camera driver shorten the time: based on 1000 vehicles with the same chip, the driver loading time accounts for 40% of the kernel phase, and early initialization can avoid resource competition with other drivers").

[0067] Scheme template library: pre-set templates are stored according to "chip model+strategy type", including: Optimization report template (including "abnormal node analysis, optimization steps, expected effect" fixed format); Code patch templates (such as kernel driver loading script templates, init.rc service configuration templates, and syntax differences between Qualcomm / TI / NXP chips); System configuration instruction templates (such as the standardized format of the attribute modification instruction setprop and the service priority adjustment instruction chmod).

[0068] The optimization generator first structurally analyzes the "chip corresponding startup optimization strategy" output by the AI model, extracting key features (to ensure the accuracy of subsequent scheme generation): Core element extraction: parse 5 types of core information from the strategy text (take "Qualcomm 8155 chip: kernel phase camera driver priority initialization" as an example): Target stage: kernel phase; Optimization object: camera driver (camera_drv.ko); Operation type: driver loading order adjustment (priority initialization); Associated chip: Qualcomm 8155 (corresponding to the Qualcomm exclusive template in the template library); Expected yield: 1.5s reduction in startup time (based on SHAP module analysis of historical data); Abnormal scenario judgment: if the strategy contains "complex optimization requiring human intervention" (such as "modify kernel compilation parameters"), automatically mark it as "only generate optimization report + code patch template" to avoid generating system configuration instructions that cannot be automatically executed.

[0069] According to the parsed strategy features, call the corresponding template to generate three types of executable schemes ("optimization report, code patch, configuration instruction"), the core being to adapt the details according to the chip model: 1. Optimization report generation (general scenario) Content composition: automatically fill in the template by the SHAP explanatory module, including: Abnormal node positioning: "The camera driver loading time in the kernel phase is 900ms, which is 500ms more than the benchmark value (400ms) for the same chip model, and is the main bottleneck"; Optimization logic: "There is resource competition between the camera driver and the GPU driver on the Qualcomm 8155 chip, and priority initialization of the camera driver can reduce the waiting time"; Implementation steps: "1. Modify the kernel driver loading script; 2. Verify the change in startup time; 3. Merge into the development branch"; Expected effect: "1.5s reduction in startup time, optimized time ≤400ms"; Format: PDF or Markdown (for easy viewing and archiving by the development side).

[0070] 2. Code patch template generation (development end landing) Adaptation logic: Call the exclusive template according to the chip model, ensure code syntax compatibility (such as different driver loading script formats for Qualcomm and TI): Qualcomm 8155 chip example (for "camera driver priority initialization"), example patch code as follows: # Original driver loading sequence (kernel / drivers / init.sh) insmod gpu_drv.ko insmod camera_drv.ko # Optimized patch insmod camera_drv.ko # Load camera driver first insmod gpu_drv.ko.

[0071] 3. System configuration modification instruction generation (car machine end automatic execution) Applicable scenario: For "no code modification, only system parameter adjustment" strategy (such as service priority, attribute value): Example 1 (adjusting service priority in init phase): # Instruction: Increase the navigation service priority from 10 to 5 (Qualcomm 8155 chip) setprop sys.boot.priority.navigation 5.

[0072] Example 2 (merge attribute file): # Instruction: Merge 3 independent attribute files into 1 (NXP i.MX 8 chip) cat / system / etc / prop.d / *.prop> / system / etc / prop.d / merged.prop rm / system / etc / prop.d / *.prop.

[0073] Through the above steps, the abstract strategy is converted into "directly executable code / instructions", and the developer does not need to manually derive the implementation method, and the repair time is greatly shortened; through "chip exclusive template", ensure that the scheme is compatible with different hardware such as Qualcomm / TI / NXP, avoid single scheme invalidation on multiple vehicle types; with SHAP explanation logic and rollback mechanism, developers can clearly understand the optimization principle, while avoiding system failure caused by optimization failure.

[0074] S400, push the executable scheme to the target object; so that the target object optimizes the starting process of the target center control system through the executable scheme.

[0075] Further, the target object includes a target car machine center control system or a development end; in the case of the executable scheme being a system configuration modification instruction, the target car machine center control system is pushed to the target car machine center control system, and the target car machine center control system automatically applies the system configuration modification instruction, so that the optimization takes effect next time; in the case of the executable scheme being an optimization report or a code patch template, the development end is pushed to the development end for reference execution.

[0076] In the embodiment, the target object can be a target car machine center control system or a development end. In the case of the target object being a target car machine center control system, the system configuration modification instruction is received, and the target car machine center control system automatically applies (without manual intervention), and the optimization takes effect next time; in the case of the target object being a development end, the optimization report / code patch template is received, and the developer verifies and integrates the code (such as checking the compatibility of the patch and the existing code).

[0077] For example, the car machine end: after receiving the configuration instruction of "adjusting the service priority in the init phase", the start parameter of the "navigation service" in the init.rc script is automatically modified, and the start time of the navigation service is shortened from 2.5s to 1.7s next time the power is turned on and started.

[0078] The development end: after receiving the "kernel driver loading patch", the developer checks the patch through a code review tool, confirms that there is no compatibility problem, and integrates it into the development branch.

[0079] Through the step, the collaborative optimization of "automation + manual verification" can be realized: the car machine end automatically applies the simplified process, the development end manually verifies to ensure stability, and the problems of "low efficiency caused by full dependence on manual work" and "high risk caused by full automation" in the prior art are solved.

[0080] Based on three kinds of vehicle-mounted chips (Qualcomm, Ti, NXP), the implementation architecture / topology diagram of reporting data and then training and feeding back through multiple models is as shown in Figure 3 The distributed federated learning is used to realize the privacy data training of edge AI, and the process of cooperation of the central server and different car machine devices. The edge device uploads the start log, performs local calculation and inference, feeds back the result, and updates the central model at the same time. This scheme improves the efficient deployment and real-time performance of the model on resource-limited devices.

[0081] The functions of each module and the specific interaction timing diagram are as shown in Figure 4As shown, a specific timing diagram of the edge AI federated learning system is described. After different edge devices collect logs and CPU / GPU data, they are transmitted to edge AI for local TinyML inference. The central server aggregates model updates through FedAvg, simultaneously monitors feedback and optimizes for 24 hours, and pushes back to the edge device, forming a closed-loop iteration. Continuous monitoring and deployment optimization are achieved.

[0082] Further, in the case of the target vehicle head unit system in a data sensitive scene, the method further includes the step of optimizing the starting KPI in combination with the snapshot starting recovery process: When the target vehicle head unit system is shut down or restarted, the core state data from the system startup to the completion of kernel initialization before the loading of user space privacy data is captured and stored persistently in a non-volatile storage medium.

[0083] Next time the power is turned on and started, if the core state data is detected, the core state data is directly recovered, and the complete initialization process of the bootloader and the kernel is skipped.

[0084] In this embodiment, snapshot capture: when the target vehicle is shut down / restarted, the core state data (including bootloader snapshot, kernel snapshot, SystemServer key context) from the system startup to the completion of kernel initialization before the loading of user space privacy data is captured and stored persistently in a UFS / eMMC non-volatile storage medium after compression.

[0085] Snapshot recovery: next time the power is turned on and started, the bootloader first detects whether there is snapshot data in the storage medium: if there is, the core state data is directly recovered, the complete initialization process of the bootloader and the kernel is skipped, and only the init phase partial service startup is performed (realizing "hot start"); if there is not, the standard cold start process is performed.

[0086] For example: for military vehicles (data sensitive scene), when the vehicle is shut down, the state data from the completion of kernel initialization to the loading of user privacy data (such as positioning information) is captured and stored in UFS; next time the vehicle is started, the hardware initialization (time-consuming 1.2s) of the bootloader and the driver loading (time-consuming 1.8s) of the kernel are skipped, the snapshot is directly recovered, and the starting time is shortened from 8s of cold start to 3s of hot start.

[0087] Through the above method, the dual problems of "data upload risk" and "slow start" in a data sensitive scene (such as a military vehicle or a privacy priority EV vehicle) can be solved: without the need to upload data to the cloud, the lengthy initialization process is skipped, the starting time is further shortened, and special scene requirements are covered; the snapshot starting / recovery process is as follows Figure 5as shown.

[0088] The method in this embodiment is characterized in that, by embedding lightweight scripts and modules in the system source code, the boot time stamps of each key node in the bootloader, kernel and init stages after the device is powered on are automatically collected in the development environment. The collected time stamp data and device information are uploaded to a remote server at a specific time node, ensuring efficient transmission and centralized management of the data. The server side not only can deeply analyze these data, but also can combine AI data analysis models to train the data of multiple vehicle types and devices in a distributed manner without revealing the privacy of the devices (only encrypted model updates are uploaded instead of raw data). Based on the hardware characteristics of different vehicle types, the trained AI models can generate personalized optimization strategies. These optimization strategies are then generated into reports and pushed to developers, or returned to the device through an automated push mechanism and applied to the development process in real time, thereby realizing a closed-loop improvement from problem positioning to optimization. This scheme is particularly suitable for the multi-hardware variation scenario of vehicle machine development, significantly improves development efficiency and reduces manual intervention, and ultimately provides strong performance guarantee for project delivery.

[0089] In an exemplary embodiment, in order to verify the feasibility of the method in this embodiment, the optimization process after the simulation development stage iteration of new features based on the Qualcomm vehicle chip is simulated, and the simulation data is based on 10 runs. A normal distribution conforming to the typical vehicle machine development benchmark is used. The problem positioning time is 8 hours, the iteration period is 4 days, and the optimization accuracy is 75%, as shown in Table 1.

[0090] Table 1 The simulation data (10 runs) after the optimization scheme in this embodiment is executed, as shown in Table 2: Table 2 It can be seen that, in the case of reducing the iteration period by one time (from 4.28 days to 2 days, that is, more frequent changes), Problem positioning time: reduced from 7.7h to 1.9h, with a 3-fold improvement.

[0091] Optimization accuracy: from 76.4% to 81.6%, with no obvious improvement. However, in the case of more device models and start-up data, the accuracy will certainly have more room for improvement.

[0092] Repair time: from an average of 10 hours to 3 hours, with a 3-fold improvement.

[0093] Through the test results of 10 simulation data, the optimization scheme of the embodiment basically achieves the expected effect, and since the iteration period is reduced by half, the final optimization result is also about 1 times higher than the current result. It embodies the advantages of real-time analysis and rapid feedback. If there are more data model supports and self-learning, better performance will be achieved.

[0094] In addition, although the various steps of the methods in the present disclosure are described in a particular order in the accompanying drawings, this is not required or implied that the steps must be performed in this particular order, or that all of the steps shown must be performed to achieve the desired results. In addition or alternatively, certain steps can be omitted, multiple steps can be combined into one step, and / or one step can be divided into multiple steps, etc.

[0095] Embodiments of the present application also provide a device for starting KPI optimization of a car machine central control system, the device comprising: a data acquisition module configured to acquire time data of preset key nodes and car machine hardware parameters in a power-on starting process of a target car machine central control system; the car machine hardware parameters at least include a chip model.

[0096] an AI analysis module configured to generate a starting optimization strategy corresponding to a chip of the target car machine central control system based on the time data of the preset key nodes and the car machine hardware parameters through a preset AI analysis model; the AI analysis model is obtained through gradient training of a local model corresponding to different car machine ends.

[0097] a strategy conversion module configured to convert the starting optimization strategy corresponding to the chip of the target car machine central control system into an executable scheme through a preset optimization generator.

[0098] a scheme pushing module configured to push the executable scheme to a target object; so that the target object optimizes the starting process of the target central control system through the executable scheme.

[0099] Further, the data acquisition module comprises: a preprocessing unit configured to preprocess the time data; the preprocessing includes: eliminating abnormal values, arranging the time data into a time sequence format, and generating a starting reference curve corresponding to a target car machine central control system model based on the preprocessed time data.

[0100] Further, the AI analysis module comprises: an encrypted gradient acquisition unit configured to acquire encrypted gradients corresponding to each car machine end; the encrypted gradients are generated by training the time data and hardware parameters collected by the local Tiny ML model of the corresponding car machine end.

[0101] The AI analysis model generation unit is configured to generate the preset AI analysis model by aggregating the encrypted gradient through a Fed Avg algorithm.

[0102] Further, the scheme pushing module comprises: The first pushing unit is configured to, in the case that the executable scheme is a system configuration modification instruction, push the system configuration modification instruction to a target vehicle head unit system, and the target vehicle head unit system automatically applies the system configuration modification instruction to make the optimization effective next time when starting; The second pushing unit is configured to, in the case that the executable scheme is an optimization report or a code patch template, push the executable scheme to a development end for reference and execution by the development end.

[0103] Further, the device further comprises: The core state data capturing module is configured to, when the target vehicle head unit system is powered off or restarted, capture core state data after the system starts and before user space private data is loaded, and store the core state data to a non-volatile storage medium.

[0104] The state data recovery module is configured to, when the core state data is detected next time when starting, directly recover the core state data and skip the complete initialization process of the bootloader and the kernel.

[0105] The non-transitory computer readable storage medium can be arranged in an electronic device to save at least one instruction or at least one program related to a method in the method embodiment, and the at least one instruction or the at least one program is loaded and executed by the processor to realize the method provided in the above embodiment.

[0106] The program product can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, be but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include an electrical connection having one or more wires, a portable disc, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0107] A computer readable signal medium can include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal can take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium can be any computer readable medium that can be involved in

[0108] The program code embodied on the computer readable medium can be transmitted using any appropriate medium, including but not limited to wireless, wired, optical fiber cable, RF, and the like, or any suitable combination of the foregoing.

[0109] The program code can be executed by one or more programmable processors, which can be implemented in one or more computer devices including any combination of hardware, firmware, and / or software.

[0110] Embodiments of the present application further provide an electronic device including a processor and the aforementioned non-transitory computer readable storage medium.

[0111] The electronic device is merely an example, and should not bring any limitation to the function and usage range of embodiments of the present application.

[0112] The electronic device is in the form of a general computing device. The components of the electronic device can include, but are not limited to, the aforementioned at least one processor, the aforementioned at least one memory, a bus connecting different system components including the memory and the processor.

[0113] The memory stores program codes which can be executed by the processor, so that the processor performs steps in various embodiments described in the specification.

[0114] The memory can include a readable medium in the form of a volatile memory, such as a random access memory (RAM) and / or a cache memory, and can further include a read only memory (ROM).

[0115] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0116] A bus can represent one or more of several bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus structures.

[0117] Electronic devices can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable user interaction with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be achieved through input / output (I / O) interfaces. Furthermore, electronic devices can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0118] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0119] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0120] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A method for optimizing the startup KPI of a vehicle infotainment system, characterized in that, include: Acquire time data and vehicle hardware parameters of preset key nodes during the power-on and startup process of the target vehicle infotainment system; the vehicle hardware parameters include at least the chip model. Based on the time data of preset key nodes and the vehicle hardware parameters, the AI ​​analysis model generates the startup optimization strategy corresponding to the chip of the target vehicle central control system. The AI ​​analysis model is obtained through gradient training of the local model corresponding to different vehicle terminals; The startup optimization strategy corresponding to the chip of the target vehicle central control system is converted into an executable solution through a preset optimization generator. The executable solution is pushed to the target object, enabling the target object to optimize the startup process of the target central control system through the executable solution.

2. The method for optimizing the KPI of a vehicle infotainment system according to claim 1, characterized in that, The preset key nodes include the bootloader stage, kernel stage, and init stage; the time data and vehicle hardware parameters are obtained through a lightweight acquisition module embedded in the target vehicle central control system.

3. The method for optimizing the KPI of a vehicle infotainment system startup according to claim 1, characterized in that, After acquiring the time data and vehicle hardware parameters, the process also includes preprocessing the time data. The preprocessing includes: removing outliers, organizing the time data into a time series format, and generating a start-up baseline curve for the corresponding target vehicle infotainment system model based on the preprocessed time data.

4. The method for optimizing the KPI of a vehicle infotainment system according to claim 1, characterized in that, The training process of the AI ​​analysis model includes: Obtain the encryption gradient corresponding to each vehicle terminal; the encryption gradient is generated by training the local TinyML model of the corresponding vehicle terminal on the collected time data and hardware parameters. The encrypted gradients are aggregated using the Fed Avg algorithm to generate the preset AI analysis model.

5. The method for optimizing the KPI of a vehicle infotainment system startup according to claim 1, characterized in that, The startup optimization strategy includes at least one of the following: driver loading optimization and service startup optimization for the target vehicle infotainment system chip model. The driver loading optimization includes: prioritizing the initialization of core device drivers or asynchronously loading non-core drivers; The service startup optimizations include merging property files or adjusting the service startup priority during the init phase.

6. The method for optimizing the KPI of a vehicle infotainment system startup according to claim 1, characterized in that, The executable solution includes at least one of the following: optimization report, code patch template, and system configuration modification instructions.

7. The method for optimizing the KPI of a vehicle infotainment system startup according to claim 1, characterized in that, The target object includes the target vehicle infotainment system or the development terminal; If the executable scheme is a system configuration modification command, it is pushed to the target vehicle infotainment system, and the target vehicle infotainment system automatically applies the system configuration modification command so that the optimization takes effect on the next startup. If the executable solution is an optimization report or code patch template, it is pushed to the development team for reference and execution.

8. The method for optimizing the KPI of a vehicle infotainment system according to claim 1, characterized in that, In scenarios where the target vehicle infotainment system is in a data-sensitive environment, the process also includes steps to optimize startup KPIs by incorporating snapshot startup and recovery procedures. When the target vehicle infotainment system is powered off or restarted, capture the core state data from system startup to kernel initialization completion and before user space privacy data loading, and persistently store it to a non-volatile storage medium; Upon the next power-on startup, if the core state data is detected, the core state data will be directly restored, skipping the complete initialization process of the bootloader and kernel.

9. A vehicle infotainment system startup KPI optimization device, characterized in that, The device includes: The data acquisition module is used to acquire time data and vehicle hardware parameters of preset key nodes during the power-on and startup process of the target vehicle infotainment system; the vehicle hardware parameters include at least the chip model. The AI ​​analysis module is used to generate a startup optimization strategy for the target vehicle infotainment system chip based on the time data of preset key nodes and the vehicle hardware parameters through a preset AI analysis model; the AI ​​analysis model is obtained by gradient training of the local model corresponding to different vehicle terminals. The strategy conversion module is used to convert the startup optimization strategy corresponding to the chip of the target vehicle central control system into an executable scheme through a preset optimization generator; The solution push module is used to push the executable solution to the target object, so that the target object can optimize the startup process of the target central control system through the executable solution.

10. An electronic device, characterized in that, It includes a processor and the vehicle infotainment system start-up KPI optimization device as described in claim 9.

Images