Vehicle-mounted equipment optimization method and system based on firmware updating

Abstract

The invention relates to the field of vehicle-mounted equipment optimization, in particular to a vehicle-mounted equipment optimization method and system based on firmware updating. The method comprises the following steps: carrying out running state full monitoring on a vehicle-mounted firmware module, carrying out multi-behavior state sensing modeling, and constructing a firmware behavior state map; performing dynamic change trend analysis on the firmware behavior state graph, performing performance attenuation situation modeling, and constructing a performance attenuation situation curve; based on the performance attenuation situation curve, code-level program root cause analysis is carried out, firmware optimization target quantification is carried out, and firmware optimization demand data is generated; based on the firmware optimization demand data, multiple optimization direction decisions are made, multi-index optimization solution is carried out, and a firmware optimization task list is constructed; and performing firmware configuration update parameter simulation based on the firmware optimization task list to obtain a configuration update parameter scheme. According to the method, the optimal progressive equipment updating is realized, and the reliability and deployment safety of the vehicle-mounted equipment are improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle-mounted equipment optimization, and more particularly to a method and system for optimizing vehicle-mounted equipment based on firmware updates. Background Technology

[0002] In-vehicle equipment faces numerous challenges during actual operation. On the one hand, firmware modules are frequently updated, and inconsistencies in performance, resource scheduling conflicts, or compatibility issues between new and old logic may arise between updated versions. On the other hand, with the dynamic changes in the vehicle's operating environment, hardware status, and application requirements, the initial firmware configuration often struggles to maintain its optimal state throughout its lifecycle, easily leading to system performance degradation, increased response latency, and decreased resource utilization efficiency. Furthermore, the lack of effective state awareness and configuration control mechanisms during firmware updates can also trigger unexpected system anomalies, data conflicts, or even functional failures, posing potential risks to vehicle operation.

[0003] Current mainstream methods for optimizing in-vehicle equipment mostly focus on redundant design or static configuration adjustments at the hardware level, lacking dynamic perception and intelligent analysis capabilities for firmware behavior. While traditional OTA (Over-The-Air) firmware update mechanisms can achieve remote upgrades, they largely remain at the "update and deploy" level, lacking in-depth analysis and performance evaluation of the updated system state, making it difficult to meet the optimization needs of in-vehicle equipment in scenarios requiring high reliability, high real-time performance, and multi-tasking concurrent operation. Furthermore, existing methods generally rely on manual intervention and passive troubleshooting, which is not only inefficient but also unable to promptly address complex operational anomalies caused by firmware updates. Therefore, there is an urgent need for a firmware optimization method with intelligent analysis capabilities, dynamic perception capabilities, and automated decision-making capabilities. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes a method and system for optimizing in-vehicle equipment based on firmware updates, thereby resolving at least one of the aforementioned technical problems.

[0005] To achieve the above objectives, the present invention provides a method for optimizing in-vehicle equipment based on firmware updates, comprising the following steps: Step S1: Perform full monitoring of the operating status of the vehicle firmware module, and perform multi-behavioral state perception modeling to construct a firmware behavior state map; Step S2: Perform dynamic trend analysis on the firmware behavior state graph, model the performance degradation situation, and construct the performance degradation situation curve; Step S3: Based on the performance degradation trend curve, perform code-level program root cause analysis, quantify firmware optimization targets, and generate firmware optimization requirement data; Step S4: Based on firmware optimization requirement data, make decisions on multiple optimization directions, perform multi-index optimization solutions, and construct a firmware optimization task list; Step S5: Simulate firmware configuration update parameters based on the firmware optimization task list, select the optimal configuration parameters, and obtain the configuration update parameter scheme; Step S6: Based on the configuration update parameter scheme, perform incremental update deployment, and then perform fully automatic iterative closed-loop optimization to build a vehicle iterative closed-loop optimization engine.

[0006] This specification provides a firmware update-based in-vehicle device optimization system for performing the firmware update-based in-vehicle device optimization method described above, including: The firmware status unit is used to perform full monitoring of the operating status of the vehicle firmware module, and to perform multi-behavioral status perception modeling to construct a firmware behavior status map. The degradation status unit is used to perform dynamic trend analysis on the firmware behavior state graph, model the performance degradation status, and construct the performance degradation status curve. The optimization requirement unit is used to perform code-level program root cause analysis based on the performance degradation trend curve, quantify firmware optimization targets, and generate firmware optimization requirement data. The optimization and solution unit is used to make decisions on multiple optimization directions based on firmware optimization requirement data, perform multi-index optimization solutions, and build a firmware optimization task list; The configuration update unit is used to simulate firmware configuration update parameters based on the firmware optimization task list, select the optimal configuration parameters, and obtain a configuration update parameter scheme. The incremental update unit is used to deploy incremental updates based on configuration update parameter schemes, and then perform fully automatic iterative closed-loop optimization to build a vehicle iterative closed-loop optimization engine.

[0007] The beneficial effects of this invention are as follows: By deploying a multi-source sensing and log collection mechanism, the operating status of firmware modules in vehicle-mounted equipment is comprehensively perceived and monitored in real time. The graphical representation of firmware's operational behavior characteristics not only improves the observability of its operating status but also lays a solid data foundation for subsequent trend modeling, performance analysis, and optimization strategy formulation. Simultaneously, the state graph provides dynamic tracing capabilities based on historical and real-time behavior, helping to quickly identify and locate system bottlenecks or potential risk points, enhancing overall system stability. It effectively solves the problem of performance degradation during firmware operation being difficult to detect and quantify. By modeling performance evolution trends, early signals of performance decline can be detected in advance, enabling predictive maintenance and proactive update triggering. Furthermore, the degradation curve provides a clear quantitative reference for firmware optimization, supporting data-driven optimization evaluation and decision-making. It achieves automated mapping from macroscopic performance status to microscopic code implementation, making performance optimization visual, precise, and task-oriented. It transforms previous experience-based tuning work into a data-driven, goal-oriented scientific analysis process, greatly improving problem response speed and optimization efficiency, while providing a basis for subsequent automatic optimization and verification.

[0008] Through systematic modeling and algorithmic support, the risks of blind optimization or local optima are avoided, ensuring that every optimization decision has theoretical support and quantitative basis. The creation of a task list also facilitates orderly optimization implementation and version control by the development team, improving collaboration efficiency and the controllability of optimization execution. Finding optimal configuration parameters through simulation and intelligent search avoids the uncertainty and risks associated with "experience-based parameter tuning." Standardized output of configuration schemes facilitates flexible deployment in different vehicle or user scenarios, improving the relevance and stability of firmware updates. Simultaneously, the parameter schemes are traceable and iterative, supporting continuous optimization. This significantly improves the deployment security and reliability of optimized firmware, reducing the risk of impact on end users. Through an iterative closed-loop mechanism, continuous self-learning and self-adjustment enable continuous performance improvement and self-optimization capabilities of in-vehicle equipment, driving the evolution of vehicle software systems towards intelligence and automation. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the steps of an in-vehicle device optimization method based on firmware update according to the present invention. Figure 2 This is a detailed flowchart illustrating the implementation steps of step S1. Figure 3 This is a detailed flowchart illustrating the implementation steps of step S2; Figure 4 This is a flowchart illustrating the detailed implementation steps of step S3. Detailed Implementation

[0010] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0011] This application provides a method and system for optimizing in-vehicle equipment based on firmware updates. The executing entities of the method and system include, but are not limited to, mechanical equipment, data processing platforms, cloud server nodes, and network upload devices that can be considered general computing nodes in this application. The data processing platform includes, but is not limited to, at least one of an audio / image management system, an information management system, and a cloud data management system.

[0012] See also Figures 1 to 4 This invention provides a method for optimizing in-vehicle equipment based on firmware updates, comprising the following steps: Step S1: Perform full monitoring of the operating status of the vehicle firmware module, and perform multi-behavioral state perception modeling to construct a firmware behavior state map; Step S2: Perform dynamic trend analysis on the firmware behavior state graph, model the performance degradation situation, and construct the performance degradation situation curve; Step S3: Based on the performance degradation trend curve, perform code-level program root cause analysis, quantify firmware optimization targets, and generate firmware optimization requirement data; Step S4: Based on firmware optimization requirement data, make decisions on multiple optimization directions, perform multi-index optimization solutions, and construct a firmware optimization task list; Step S5: Simulate firmware configuration update parameters based on the firmware optimization task list, select the optimal configuration parameters, and obtain the configuration update parameter scheme; Step S6: Based on the configuration update parameter scheme, perform incremental update deployment, and then perform fully automatic iterative closed-loop optimization to build a vehicle iterative closed-loop optimization engine.

[0013] In the embodiments of the present invention, see Figure 1 The diagram below illustrates the steps of a firmware update-based in-vehicle device optimization method according to the present invention. In this example, the steps of the firmware update-based in-vehicle device optimization method include: Step S1: Perform full monitoring of the operating status of the vehicle firmware module, and perform multi-behavioral state perception modeling to construct a firmware behavior state map; In this embodiment, a combination of high-precision hardware probes and software tracking is used to collect multi-dimensional operational data of the firmware module. The monitoring content includes CPU instruction execution sequences, function call stacks, memory access patterns, and interrupt response timing. To ensure data integrity and timing synchronization, the system employs a microsecond-level timestamp synchronization mechanism, with a sampling frequency of thousands of times per second, ensuring accurate capture of high-speed instruction streams and real-time events. In the experimental environment, the monitoring system ran continuously for 48 hours on an in-vehicle control unit, collecting over 1 billion instruction execution records, covering the main functional modules of the firmware, ensuring the representativeness and sufficiency of the data. The collected multi-dimensional operational data underwent data preprocessing and trajectory fitting. Preprocessing included noise reduction, timing alignment, and outlier removal, using wavelet transform and Gaussian filtering techniques to optimize signal quality. Subsequently, the CPU instruction sequences, call stacks, and memory access patterns were fused to form a low-level multi-dimensional operational monitoring trajectory. This trajectory describes the state change characteristics of the firmware at different operational moments, reflecting the intrinsic relationship between instruction execution streams and resource access. Experimental parameters show that the fused multi-dimensional trajectory can effectively reduce monitoring noise by approximately 20%, improving the accuracy of subsequent analysis. A multi-time-window partitioning strategy was implemented, dividing the overall operation trajectory into multiple time-window segments at different time scales (e.g., 1 second, 5 seconds, 30 seconds), with each window extracting independent operation state features. This hierarchical time-series analysis can capture short-term transient behavior and long-term stable trends, helping to identify potential anomalies or performance bottlenecks in the firmware. In the experiment, a sliding window method was used, with the window length and overlap rate adjusted according to the module execution characteristics. The optimal balance between a 5-second window and a 50% overlap rate was finally determined. Firmware module execution time distribution was calculated for the operation trajectory within each time window, statistically analyzing the module-level instruction execution frequency and time consumed, generating an execution time distribution map. This map reveals the load distribution and execution hotspots among modules, providing a foundation for subsequent inter-module call dependency analysis. Taking a certain vehicle communication module as an example, the execution time distribution map shows that it accounts for 18% of the total system CPU time, clarifying the module's critical position in overall performance. Based on the execution time distribution, inter-module call dependencies were extracted, and a call dependency network was constructed using graph theory algorithms to identify the call frequency and hierarchical relationships between modules. Furthermore, a multi-behavioral state-aware modeling method (such as Hidden Markov Models and Graph Neural Networks) is employed to combine call dependencies and execution state data to construct a firmware behavioral state graph. This graph can dynamically display the firmware's runtime state transitions and behavioral patterns, supporting anomaly detection and performance analysis. Experimental results show that the behavioral state graph improves the accuracy of firmware runtime anomaly identification by approximately 15%, significantly enhancing the decision support capability for firmware performance optimization.

[0014] Step S2: Perform dynamic trend analysis on the firmware behavior state graph, model the performance degradation situation, and construct the performance degradation situation curve; In this embodiment, for each state node and its transition edges in the firmware behavior state graph, a state evolution sequence within a continuous running cycle is extracted. This sequence consists of the mapping relationship between key performance indicators (such as module execution time, resource consumption, and response latency) collected during runtime and the behavior nodes. In the experimental setup, we used the firmware of a vehicle gateway for a certain model as the object, continuously collecting state graph snapshots over 48 hours, obtaining a total of 2,880 5-second time slices. Each time slice contained more than 20 active state nodes and their transition relationships. Time series analysis methods (such as moving average and exponential smoothing) were used to model the changing trend of the state graph within the continuous time window, identifying abnormal patterns such as increased state transition frequency or prolonged dwell time of key nodes as potential signals of performance fluctuations. For example, experimental data showed that the average state dwell time of a certain communication protocol parsing module increased from the normal 320ms to 560ms after 24 hours of operation, indicating an increasing performance load trend. Multi-dimensional indicator aggregation technology was used to map the key performance parameters in the behavior graph to unified performance degradation indicators, including but not limited to average response time, system load index, and abnormal transition rate. Principal component analysis (PCA) and weighted averages (e.g., 40% response latency, 30% CPU utilization, 30% anomaly frequency) are used to normalize the above indicators, generating a firmware performance degradation index (F-Decay Index) to measure the overall performance decline trend of the system. Based on this, a performance degradation trend curve is constructed, with time on the horizontal axis and the performance degradation index on the vertical axis, showing the dynamic evolution of firmware performance over continuous operation. Experimental data shows that under conditions of temperature variation and increased network pressure, the performance degradation index of some firmware increases by more than 0.25 after 24 hours of operation, exhibiting a significant performance degradation trend. This curve can identify accelerated degradation intervals, potential performance critical points, and early stable operating intervals, providing accurate support for subsequent risk point prediction and optimization trigger mechanisms. The system also introduces a rate of change analysis mechanism to perform first derivative and curvature analysis on the performance degradation curve, thereby identifying the stage with the fastest performance degradation rate and anomalous points of drastic fluctuation, further enhancing the understanding of firmware performance trends. The entire modeling process is highly automated, supporting horizontal comparison and trend aggregation across different firmware versions and device models.

[0015] Step S3: Based on the performance degradation trend curve, perform code-level program root cause analysis, quantify firmware optimization targets, and generate firmware optimization requirement data; In this embodiment, based on the performance degradation trend curve, which identifies performance anomaly inflection points and accelerated degradation segments, the system locates specific time intervals and associates them with corresponding firmware behavior state graphs and monitoring logs. By tracing back the behavior state sequence and resource usage trajectory, firmware modules exhibiting abnormal frequency, execution time, or sudden increases in resource consumption during the degradation segment are selected. In the experiment, a vehicle multimedia control firmware is used as the research object, and the performance degradation inflection point segment (F-Decay Index ≥ 0.35) occurring at the 36th hour of operation is selected as the analysis window, focusing on the three modules with the largest abnormal fluctuations: the audio decoding processing module, the CAN frame parsing module, and the timed task scheduling module. The process then proceeds to the code-level root cause analysis stage. First, static analysis tools (such as Clang Static Analyzer and Cppcheck) are used to perform structured code scanning on the abnormal modules to identify potential risks such as memory leaks, circular dependencies, and uninitialized variables. Second, combined with dynamic analysis methods, function execution tracing and call stack backtracking mechanisms are used to quantify the average execution time, call frequency, and memory allocation behavior of key functions. In the experimental case, an unoptimized MP3 decoding function was found in the audio decoding module. Its average execution time was approximately 28% higher than the initial version, accompanied by a high heap memory usage, becoming the core root cause of the module's performance degradation. Data dependency path analysis and loop hotspot identification methods were also introduced, combined with LLVM instrumentation and binary analysis techniques, to identify code segments with high repetition and poor concurrency. For example, in the scheduled task module, the system identified multiple serial processing logics that lacked branch optimization, leading to a cumulative scheduling delay problem when the load increased. After completing the root cause identification, the system quantified and modeled optimization points based on the analysis results. Optimization targets included a percentage reduction in response time, a threshold for reducing memory usage, and a range for controlling function call frequency. For the example module mentioned above, the system provided clear quantitative targets: reducing the average execution time of the audio decoding function from the current 68ms to less than 50ms, and controlling the scheduled task response delay to less than 10ms. Each target is bound to a specific code file, function entry point, and performance baseline, ensuring executability and verifiability. Based on the root cause analysis results and optimization objectives, a firmware optimization requirement dataset is generated. This dataset records information such as optimization modules, corresponding problem categories, key function paths, resource impact scope, and suggested optimization strategies in a structured format. Experimental statistics show that an average of 15-30 code-level issues with practical optimization value can be extracted from each firmware version, supporting optimization task grading and task volume estimation.

[0016] Step S4: Based on firmware optimization requirement data, make decisions on multiple optimization directions, perform multi-index optimization solutions, and construct a firmware optimization task list; In this embodiment, based on the module names, code paths, performance bottleneck indicators, and optimization goals recorded in the firmware optimization requirement data, the system performs optimization direction classification analysis. This process uses a multi-label clustering algorithm (such as K-means with constraint-based clustering) to group optimization requirements and identify multiple improvement items belonging to the same optimization direction. In the experiment, after clustering analysis on a certain ADAS firmware version, the system automatically identified three main optimization directions: ① execution efficiency improvement (such as function runtime exceeding limits, thread blocking), ② memory resource optimization (such as stack overflow risk, decreased cache hit rate), ③ scheduling response improvement (such as task queuing delay, decreased real-time performance). These three directions cover more than 82% of the optimization requirement data points, exhibiting high concentration and operability. The system then enters the optimization direction decision modeling stage. In this stage, for each identified optimization direction, its corresponding performance benefit model and optimization cost model are constructed. Performance gains are predicted by a model that estimates the improvement in target performance metrics, such as a 20% reduction in response time and a 15% reduction in memory usage after optimization. Optimization costs are considered in terms of implementation complexity, development time costs, and testing and verification cycles, and are modeled using a combination of expert scoring and historical project regression analysis. In real-world scenarios, the implementation benefit-cost ratios of 10 different optimization directions are simulated, ultimately selecting 5 directions with high cost-effectiveness for the next stage of priority processing. The system introduces a multi-index optimization algorithm for comprehensive decision-making. A weighted multi-objective decision-making method (such as a combination of TOPSIS, AHP, and Pareto frontier analysis) is used to incorporate multiple indicators such as performance improvement, resource saving, implementation cost, and risk control into a unified evaluation system, with weights configured according to vehicle business priorities. For example, for in-vehicle central control systems, performance response time may be given a higher weight (0.4), while in battery management systems, resource saving indicators may have a higher weight (0.35). After optimization calculations, the system provides an optimization priority ranking for each direction and corresponding strategy recommendations. Based on the priority decision results, the system automatically constructs a firmware optimization task list. The list outlines specific optimization tasks by module, including optimization item number, target module, root cause description, recommended optimization method, expected improvement indicators, risk level, and estimated implementation cycle. Each task has clear evaluation criteria and responsible modules, facilitating subsequent coordination and implementation by the development and testing teams. In the experimental project, a total of 28 optimization tasks were generated for a specific vehicle model's ECU firmware version, with 16 listed as high-priority tasks. The overall performance improvement is expected to reach 22%, the average response time will decrease by approximately 170ms, and resource load will decrease by approximately 13%.

[0017] Step S5: Simulate firmware configuration update parameters based on the firmware optimization task list, select the optimal configuration parameters, and obtain the configuration update parameter scheme;In this embodiment, configuration parameter items associated with the tasks are extracted from the firmware optimization task list formed in step S4. These parameters may include thread priority, cache size, I / O interrupt threshold, scheduling cycle, memory allocation strategy, etc., and usually have adjustable ranges and default settings. For example, for the optimization task "reduce interrupt latency", the corresponding parameters may be the interrupt priority table and CPU core allocation strategy. In the experiment, taking a certain vehicle intelligent central control firmware as an example, 27 key adjustable parameters were extracted, covering dimensions such as scheduler configuration, memory pool partitioning, and DMA channel configuration. A configuration update parameter simulation environment is constructed. At this stage, the system will load the configuration parameter scheme to be tested and execute firmware operation simulation based on the actual vehicle control unit's operating model, combined with a virtual machine or containerized simulation platform (such as QEMU, Docker with customized firmware runtime). Each set of parameter combinations runs the set task process in the virtual environment, and core performance indicators are collected: average response time, inter-module latency, CPU utilization, memory usage efficiency, task completion rate, etc. To ensure the stability of the results, each set of parameter schemes needs to be run repeatedly for no less than 10 times, and the average value is taken to remove occasional noise. Through the above methods, a large number of configuration parameter-performance response comparison datasets are generated, with each data point corresponding to a complete configuration and its operational effect. In a typical experiment, the system performed parallel simulations on 50 sets of configuration parameter combinations, with an average time of about 3 minutes per set, collecting over 10,000 data points covering 5 categories of optimization metrics. Subsequently, regression analysis (such as random forest regression and XGBoost) and heuristic search algorithms (such as genetic algorithms and Bayesian optimization) were used to mine the dataset, identifying which parameter items are highly sensitive to which performance metrics, and eliminating redundant or interfering parameters. After identifying key parameters, the system enters the optimal configuration parameter selection stage. By constructing an objective function, multiple performance metrics are weighted and fused (e.g., response latency weight 0.4, resource consumption weight 0.3, stability weight 0.3), and multi-objective function maximization or minimization is performed. Optimization algorithms (such as the NSGA-II multi-objective evolutionary algorithm) are used for global parameter search, and under the premise of satisfying firmware stability and compatibility, 1-3 sets of parameter combinations with optimal performance and minimum resource consumption are selected to form candidate configuration schemes. For some key parameters, the system also estimates confidence intervals based on configuration stability to ensure that the selected parameters are fault-tolerant and generalizable in real-world environments. A configuration update parameter plan is generated, detailing the name, recommended value, original value, tuning target, expected performance improvement, and applicable module range for each parameter. For example, in a configuration update plan for a control unit, adjusting the thread priority from "medium" to "high" and expanding the cache size from 64KB to 96KB is expected to improve average performance response by 18% and system idle rate by 12%.The solution also includes version identification and compatibility information, and supports integration with OTA update modules.

[0018] Step S6: Based on the configuration update parameter scheme, perform incremental update deployment, and then perform fully automatic iterative closed-loop optimization to build a vehicle iterative closed-loop optimization engine.

[0019] In this embodiment, the deployment follows a gradual update strategy, meaning it's not a one-time full rollout, but rather a phased update based on vehicle grouping, functional module classification, and operational scenario division. For example, 10% of test vehicles of the same model are selected as the initial deployment target, and non-critical control modules (such as the central infotainment system and vehicle status information synchronization module) are designated as the first batch of update targets. This deployment strategy significantly reduces the risk of systemic updates while facilitating the verification of the stability and performance of new configuration parameters on a small scale. In the experimental scenario, a fleet of 300 vehicles of a certain model is divided into three phases for updates, with no more than 100 vehicles in each phase, and a deployment cycle of 5 days, ensuring that each phase undergoes complete operational verification. During deployment, the system enables a real-time configuration update detection mechanism to dynamically monitor key performance data and operational status during the configuration activation process, including changes in CPU utilization, module response latency, memory usage fluctuations, and thread scheduling status. A log collection and remote diagnostic framework (such as an OTA monitoring module + remote CAN log collection system) is used to extract update detection parameters throughout the process and automatically identify abnormal update status points. If the system enters an unstable state after a configuration takes effect (e.g., a surge in response time or a spike in resource usage), an anomaly detection flag is immediately triggered, and the timestamp of the state point, the anomalous module, and related configuration items are recorded. The system builds a stable configuration state parameter library based on historical state data. By comparing the mapping relationship between configuration parameters and operating states, it identifies the parameter configuration pattern under stable operating conditions. When an abnormal configuration state is detected, the system automatically backtracks to the nearest stable configuration point, triggering an adaptive state rollback mechanism. This mechanism does not rely on manual intervention; instead, the built-in strategy engine determines the rollback priority and scope, ensuring that the system can quickly recover to a safe and stable state in the event of performance anomalies. In the aforementioned experiments, the average response time of adaptive rollback was less than 300 milliseconds, effectively avoiding fault propagation and ensuring that the core functions of the vehicle are not affected. After implementing configuration parameter deployment, operational monitoring, and automatic rollback, the system initiates a fully automated iterative closed-loop optimization process. This process uses a five-step integrated mechanism of "deployment—monitoring—evaluation—adjustment—redeployment," combined with reinforcement learning strategies and policy transfer methods, to fine-tune and iterate existing configuration schemes. For example, when the system detects that an optimization scheme performs worse than expected under high-temperature conditions, it will automatically adjust parameters such as cooling fan scheduling logic and memory load allocation strategy based on environmental parameters, regenerate a new parameter combination, and redeploy to verify its effect. This optimization engine uses improving performance metrics (such as throughput and latency) as its objective function, continuously iterating until performance convergence. Through continuous data collection, optimization feedback, and automatic deployment updates, this step completes the upgrade from single-step optimization to an adaptive closed-loop optimization engine. This engine possesses continuous evolution, autonomous learning, risk control, and efficient recovery capabilities, and can adapt to different vehicle models, firmware versions, and operating environments, achieving true "intelligent firmware update" capabilities.Experiments have shown that, compared with the traditional static configuration deployment method, this optimization mechanism improves overall firmware performance by an average of 17% and resource utilization by 12% within three months, with a configuration anomaly rollback success rate as high as 98.6%.

[0020] In this embodiment, see Figure 2 The diagram below illustrates the detailed implementation steps of step S1. In this embodiment, the detailed implementation steps of step S1 include: Full monitoring of the operational status of the vehicle firmware module is performed, and the CPU instruction execution sequence, function call stack, memory access mode, and interrupt response timing of the vehicle firmware are collected to fit and construct a multi-dimensional underlying operation monitoring trajectory. The underlying multi-dimensional operation monitoring trajectory is divided into multiple time windows, and the operation monitoring trajectory of multiple time windows is extracted; The execution time distribution of each firmware module is calculated for the operation monitoring trajectory of multiple time windows, and the execution time distribution map of each firmware module is generated. Based on the execution time distribution map, perform inter-module call dependency analysis to extract the call dependency relationships between modules; Based on the aforementioned call dependencies, multi-behavioral state-aware modeling is performed to construct a firmware behavior state graph.

[0021] In this embodiment, a high-precision, low-overhead operation monitoring system is built around the firmware execution process in the vehicle-mounted device. By integrating on-chip debug interfaces (such as JTAG), a performance monitoring unit (PMU), and system-level tracing tools (such as ARM ETM+PTM and Intel Processor Trace), the system performs full-process monitoring and sampling of the target firmware module. The collected metrics include: CPU instruction execution sequences exceeding 1000 per second, function call stack chains (call depth controlled at 8 levels or more), typical memory access frequencies (100,000 accesses per second), and interrupt service routine response timing and latency variations (accurate to the microsecond level). These data are mapped to four low-level operational characteristics. The system fits and denoises the timing data according to the sampling frequency and clock source synchronization mechanism, constructing a multi-dimensional operation monitoring trajectory including instruction flow, function graph, access trajectory, and interrupt response. The trajectory data, aligned using a unified timestamp format, is stored in a structured manner in the monitoring data cache, providing basic data support for subsequent timing analysis and state modeling. The raw time-series data is divided into multiple analysis windows to enable local modeling and feature comparison of firmware states at different time periods. To this end, a sliding window mechanism is introduced for time-domain partitioning. Each window size is set to 500ms (based on the task cycle distribution characteristics of the medium-sized vehicle system in the experiment), and the window step size is set to 200ms to ensure a 20%–50% overlap between adjacent windows, thus preserving state transition boundary information. Within each time window, the system performs normalization processing on various trajectory data, including instruction stream deduplication and compression, call stack depth normalization, memory access density adjustment, and interrupt response time normalization. Simultaneously, the system employs an asynchronous alignment mechanism to correct time drift in sensor sampling across different dimensions. Ultimately, each window forms a set of structurally complete and time-consistent operational monitoring segments. This multi-window trajectory sequence can be viewed as a "state snapshot set" of firmware behavior during time evolution, possessing strong expressiveness and comparative analysis capabilities, facilitating subsequent behavior modeling and dependency identification.

[0022] Within each monitoring window, the system further analyzes the time occupancy characteristics of each firmware module. Using instruction tags and module information in the call stack, the collected instructions and functions are mapped to their corresponding firmware logic modules (such as CAN communication modules, sensor reading modules, image processing modules, etc.), and their execution times within that time window are accumulated and statistically analyzed. Execution time includes: the duration of the calling function, the propagation delay of the sub-call chain, buffer wait time, and the blocking time introduced by nested interrupt handling. In actual experiments, the execution time of typical firmware modules ranges from 30ms to 250ms, with peak times reaching 400ms for image processing-related modules. Finally, based on the execution time percentage of all modules in each time window, the system generates multiple "execution time distribution charts," where the horizontal axis represents the module identifier, and the vertical axis represents the relative time occupancy rate or absolute time consumption. The graphical formats include bar charts, heatmaps, and stacked area charts. These distribution charts clearly reflect the load changes of each module in different operating windows, providing intuitive data for analyzing system bottlenecks, call contention, and abnormal module behavior. After obtaining the module-level execution time distribution, the system further performs cross-module call dependency modeling to characterize the collaboration and linkage relationships between modules. Call dependency analysis is conducted using a combination of stack trace clustering, call chain slicing, and time synchronization analysis. Specifically, the method involves: first, hierarchical clustering of function call stacks to group similar call paths into the same category; then, using static function relationship graphs and dynamic call path comparison techniques to identify potential module call start and end points; finally, combining the timestamp information from the execution time distribution graph, aligning the call chain in the time dimension to identify the latency, frequency, and order of module A calling module B. In the experimental setup, the call chain depth was controlled within 10 levels, and the number of valid call pairs extracted in each window was approximately between 200 and 600. The dependency relationship is ultimately represented as a directed graph, where nodes represent firmware modules, edges represent call dependencies, and edge weights represent call frequency or average latency. This module dependency graph intuitively reveals the communication, data flow, and synchronization relationships between firmware modules, serving as a crucial bridge between state modeling and graph construction. Based on the module call dependency graph and combined with the module execution characteristics under different time windows, multi-behavioral state perception modeling is carried out. First, temporal clustering methods (such as DBSCAN, HMM, K-means, etc.) are used to cluster the monitoring trajectories of all time windows to identify various "system operation state types," such as: startup initialization state, stable operation state, sensor rereading state, and anomaly recovery state. Each state consists of a set of typical module execution characteristics and call patterns. Then, a graph structure is constructed, where nodes represent specific module behavior states (including execution time, call relationships, memory access characteristics, etc.), and edges represent the transition paths and conditions between states (such as external event triggering, interrupt response, or resource contention).In the experimental environment, a typical automotive firmware system can be divided into 5 to 8 main states, with the graph ranging from hundreds of nodes to thousands of edges. The final output "firmware behavior state graph" is a visualized, analyzable, and reasonable knowledge graph that can track and analyze the evolution of the system's operating state and serve as input for subsequent core tasks such as performance degradation modeling, root cause localization, and optimization decisions.

[0023] In this embodiment, the specific steps for constructing a firmware behavior state graph by performing multi-behavior state-aware modeling based on the call dependency relationship are as follows: Based on the call dependencies, the underlying multi-dimensional operation monitoring trajectory is dynamically parsed to generate a call sequence of instruction execution order; The frequency of module calls is calculated based on the order of instruction execution, and resource contention analysis of multiple firmware modules is performed to generate resource contention patterns. State transition analysis is performed on the instruction execution sequence to identify high-frequency execution paths and key execution nodes; Based on high-frequency execution paths and key execution nodes, a global state transition graph is constructed to represent the execution behavior state transition. Graph embedding encoding is performed on the execution behavior state transition graph to obtain multiple low-dimensional feature vectors of the execution state; Vector pattern classification is performed on low-dimensional feature vectors of multiple execution states, and multi-behavioral state perception modeling is carried out to construct a firmware behavior state map.

[0024] In this embodiment, after obtaining the inter-module call dependency graph, to further analyze the micro-execution characteristics during firmware operation, the system dynamically parses the CPU instruction data in the underlying collected runtime monitoring trajectory. This step relies on the raw instruction stream provided by trace acquisition tools (such as ARM CoreSight, Intel PT, etc.), and uses disassembly toolchains (such as objdump, Dyninst) to restore the machine code into a recognizable assembly instruction sequence, and maps it to the firmware symbol table to restore the function name and module to which the instruction belongs. During the parsing process, call boundary markers (such as function entry instruction markers, stack frame construction operations, etc.) are introduced to help segment continuous instruction segments into call sequence blocks. The system concatenates all continuously executed instruction segments according to timestamps and call relationships to generate a complete "instruction execution order call sequence". Each sequence includes the call start instruction, call chain order, return position, and nested call depth. Further statistics are collected on the call frequency, concurrent access time segments, and shared resource usage of each firmware module to identify and analyze potential resource contention behaviors. First, each instruction is mapped to its corresponding firmware module, and a "call window" is divided based on a timestamp. The call frequency of each module in different time periods is then statistically analyzed. The system employs a shared resource access point marking mechanism to label instructions accessing critical resources such as shared memory, I / O bus, and communication buffers. In the experimental setup, the call cycle is divided into 1-second units, recording the number of times each module accesses shared resources, the average access interval, and the concurrency overlap rate. By calculating the resource access cross-degree between modules (resource conflict windows overlapping by more than 30% are considered contention), a "resource contention matrix" is output. Further, based on the contention matrix, typical resource contention patterns (such as CPU-bound conflicts, I / O preemptive contention, and cache line conflicts) are clustered and extracted. The system ultimately forms a "resource contention pattern graph," providing a precise basis for analyzing inter-module coupling and optimizing resource scheduling strategies.

[0025] To characterize the state evolution of firmware during operation, the system transforms the instruction execution sequence into state transition paths and identifies high-frequency paths and key state nodes. This analysis employs a directed path construction approach, treating function calls, instruction segments, or interrupt response events within each call sequence as state nodes, with state transition edges established between nodes according to their execution order. The system accumulates the frequency of path occurrences in windows, setting a frequency threshold (e.g., 10 times / minute or more) to filter out "high-frequency execution paths." Simultaneously, graph algorithms such as PageRank and Betweenness Centrality are used to evaluate the importance of nodes within the overall path, identifying "critical execution nodes," such as common service functions frequently called by multiple paths or path switching points. Experimental tests show that in a typical image processing module, path overlap is as high as 70%, with key nodes concentrated in image filtering and data synchronization operations. This analysis not only reveals the core path structure of firmware operation but also provides important characteristic signals for performance bottleneck localization and behavioral modeling.

[0026] After aggregating high-frequency execution paths and key nodes extracted from all time windows, the system constructs an "execution behavior state transition graph" covering the entire lifecycle of behavior evolution. This graph is a directed weighted graph, where each node represents a functional behavior unit or system operating state (such as module initialization, sensor data reading, communication feedback, etc.), edges represent the transition relationships between behaviors, and edge weights represent path frequency or average latency. To enhance the graph's expressiveness, the system introduces a multi-dimensional attribute annotation mechanism, attaching attributes such as execution time, resource utilization, and call depth to nodes and edges. The state transition graph is constructed using an incremental graph building method, and duplicate subgraph structures are merged using a graph compression algorithm. In experiments, the constructed state graph has approximately 300-500 nodes and over 2000 edges. This graph structure not only demonstrates the firmware's operating behavior patterns but also possesses structural reasoning capabilities, which can be used for subsequent applications such as state anomaly detection and path prediction, serving as an important foundation for subsequent graph embedding and behavior modeling.

[0027] Graph embedding was employed to encode the state transition graph, extracting low-dimensional feature vectors for each execution state. The algorithms used primarily included Node2Vec and GraphSAGE, two structure-aware embedding methods that preserve the local structure of nodes (e.g., neighbor relationships), global path characteristics, and state label features. The state transition graph constructed in the previous step was used as input, with each node containing multiple attributes such as function call structure, resource consumption labels, and time series markers. A random walk strategy was used to generate a walk path of length 10 for each node, with each node participating in approximately 30 walks to form training samples. Subsequently, a Skip-Gram model was used to learn the vectors of the paths, with the output dimension set to 128. In the experimental dataset, a feature matrix covering 56 state nodes was finally formed, with a matrix dimension of 56×128. After embedding, T-SNE visualization analysis revealed a clear clustering trend among different functional regions (e.g., navigation, image recognition, and vehicle control) in the vector space, indicating that the embedding results have good discriminative and semantic expressive capabilities. Furthermore, the embedding vector possesses temporal continuity, which can be used to describe the potential paths of state evolution over time. This feature provides a fundamental input for subsequent behavior classification and intelligent modeling, and can also serve as an important quantitative indicator for comparing state changes after firmware updates.

[0028] By clustering and classifying multiple low-dimensional feature vectors, a multi-behavioral state-aware model of the firmware system is established, ultimately generating a "firmware behavior state map" with temporal evolution capabilities. First, clustering algorithms (such as K-Means and DBSCAN) are used to classify all state vectors. In the experiment, the number of clusters was set to 5-8, and the clustering quality was evaluated based on the silhouette coefficient, resulting in six main behavior clusters: startup initialization, navigation operation, media decoding, camera acquisition, anomaly handling, and idle standby. Each cluster represents a typical system behavior state and corresponds to a specific module combination and call path. Furthermore, Hidden Markov Models (HMMs) are used to model the state transition process, defining the transition probability and average dwell time between each behavior cluster to construct a complete state evolution map. In the experiment, significant differences in the maps were observed between different firmware versions. For example, the probability of transitioning from the image acquisition state to the abnormal state in the older version was as high as 0.36, while the probability in the new version was controlled below 0.08, showing an improvement in stability after the update. The final firmware behavior state map is not only a high-level abstraction of firmware operation behavior but can also be used in multiple scenarios such as firmware scheduling optimization, system anomaly warning, and OTA update verification. Based on the graph, it can also support behavioral simulation, fault injection testing and inter-module coupling and decoupling analysis, providing a cognitive underlying operational perspective for future intelligent vehicle systems.

[0029] In this embodiment, see Figure 3The diagram below illustrates the detailed implementation steps of step S2. In this embodiment, the detailed implementation steps of step S2 include: A time-series correlation analysis is performed on the firmware behavior state graph, and long-term firmware operation prediction is made to obtain long-term operating performance indicators, including firmware response latency, throughput, and resource utilization. Dynamic trend analysis of long-term operating performance indicators is performed to extract the firmware performance change patterns; Based on the firmware performance change pattern, predict the firmware performance degradation risk and mark multiple performance degradation risk points; The performance degradation rate is calculated for multiple performance degradation risk points to obtain the time-series performance degradation rate. Calculate the decay time interval of the multiple performance degradation risk points; Based on the decay time interval and time-series performance decay rate, a performance decay trend model is constructed, and a performance decay trend curve is generated.

[0030] In this embodiment, long-term data is segmented using sliding time windows (e.g., 100ms or 500ms), and the temporal correlation coefficient of the state sequence is calculated by combining the occurrence frequency and transition probability of each node in the state graph. Two time-series prediction methods, Autoregressive Moving Average (ARMA) and Long Short-Term Memory (LSTM), are used in the experiment to train the vehicle navigation firmware on sampled data from one hour of continuous operation. Input features include state node frequency, transition edge weights, CPU utilization, and memory access rate. The prediction output mainly includes three key performance indicators: response latency (i.e., the time from instruction initiation to response completion, with an average of 12ms in the experiment), throughput (the number of instructions processed per unit time, approximately 12,000 per second), and resource utilization (average CPU utilization between 65% and 85%). Through time-series model prediction, performance fluctuation trends within multiple future time windows can be anticipated, and potential bottlenecks or periods of resource stress can be identified. The results show that the state diagram-based time series analysis model controls the prediction error of response latency within ±1.5ms, and the root mean square error of throughput and resource utilization predictions is less than 5% and 7%, respectively, demonstrating good prediction accuracy and stability, laying a solid foundation for subsequent performance trend analysis. For historical performance index time series, sliding window statistics and trend decomposition methods (such as STL decomposition) are used to split the time series into trend, seasonality, and residual components. In the experiment, for 24 hours of firmware operation data, with a 10-minute time window, the change curves of response latency, throughput, and CPU utilization were extracted. Trend decomposition revealed that response latency shows a slow upward trend, with an average daily increase of approximately 0.15ms, indicating a gradual performance degradation of the system; throughput shows slight periodic fluctuations, with peaks corresponding to vehicle startup and high-speed driving periods, and troughs occurring during sleep states; resource utilization is generally stable around 70%, but occasionally experiences sudden spikes, suggesting instantaneous pressure on resource scheduling. Furthermore, the Dynamic Time Warping (DTW) algorithm was used to perform similarity matching on performance curves, extracting similar performance evolution patterns across different time periods and revealing the performance fluctuation characteristics of the firmware under various usage environments. Cluster analysis revealed that performance degradation often occurs during periods of frequent module switching and intensified resource contention. This step provides a data foundation for modeling firmware performance change patterns and offers theoretical support for subsequent risk prediction.

[0031] Time-series anomaly detection techniques, such as threshold-based early warning mechanisms and machine learning methods (e.g., Isolation Forest, LSTM autoencoders), were used to detect anomalies in the predicted data of response latency and resource utilization. In actual experiments, a response latency exceeding 15ms was set as the risk threshold, and a sudden increase in resource utilization exceeding 85% triggered a resource bottleneck warning. After analyzing vehicle firmware test data for one week, approximately 15 performance degradation risk points were successfully identified, all corresponding to abnormal paths or resource contention anomalies that occurred after firmware version iterations. Each risk point was accompanied by its occurrence time, associated modules, and specific performance metric values. For example, one risk point occurred during a surge in navigation module call frequency under low-temperature conditions at night, with the response latency instantly increasing to 18ms and resource utilization reaching 90%. By constructing a time-series distribution map of the risk points, it was revealed that performance degradation often coincides with close inter-module dependencies and peak hardware resource loads. This step not only enabled the prediction of performance degradation but also provided quantitative evidence for subsequent degradation rate analysis and optimization decisions.

[0032] For multiple marked performance risk points, the change curves of key performance indicators (KPIs) are extracted within a specified time window before and after each risk point (e.g., 30 minutes before and after the risk point), and the rate of change of the indicators is calculated. The experiment uses response latency as the main indicator, and the calculation formula is the increase in latency per unit time; for example, a latency increase of 0.05 ms per minute is considered a decay rate of 0.05 ms / min. In the vehicle parking assist firmware experiment, the average response latency decay rate of typical risk points ranged from 0.03 to 0.07 ms / min, showing significant differences in the performance degradation rate of different modules. Simultaneously, the decay rates of throughput and resource utilization were also evaluated. Some risk points were accompanied by a rapid decrease in throughput (average decrease of 5% / min) and drastic fluctuations in resource utilization. By comparing the decay rates of different risk points, nodes with higher decay rates can be prioritized to quickly locate bottleneck areas requiring optimization. The time-series analysis of decay rates helps to dynamically adjust the firmware update frequency and version iteration plan, achieving refined performance management.

[0033] The decay time interval refers to the time distance between consecutive performance risk points. This indicator reflects the frequency of firmware performance anomalies and system stability. Specifically, it calculates the difference in timestamps between adjacent risk points based on the time series of risk points marked in the previous step. In the experimental setup, continuous operation data of the vehicle firmware was used as the sample, covering a one-month operating cycle. The average risk point interval was found to be 4.8 hours, with fluctuations ranging from several minutes to tens of hours. Statistical analysis shows that a shortened risk point interval often indicates that firmware performance is becoming unstable or hardware aging is accelerating, especially under harsh driving environments (such as complex urban road conditions, high temperature and humidity), where the dense distribution of risk points is more pronounced. Distribution fitting of the time interval revealed an approximately exponential distribution, suggesting that performance mutations have a certain degree of randomness, but predictable time windows still exist. This indicator is significant in firmware update strategies, helping to determine maintenance cycles and early intervention opportunities, enabling preventative optimization, and reducing the impact of performance anomalies on vehicle safety.

[0034] By combining the aforementioned performance degradation rate with the risk point interval, a performance degradation trend model for the entire system is constructed. Specifically, multivariate time series modeling techniques (such as multivariate ARIMA or Bayesian dynamic linear models) are used to fuse the degradation rate and time interval as two types of indicators to establish a performance degradation trend function. In the experiment, response latency was selected as the core indicator, and its degradation rate and risk point time interval were used as input features to fit and predict performance changes during firmware operation. The fitting result is a smooth performance degradation trend curve, reflecting the full-cycle evolution of firmware performance from stability to degradation. This trend curve not only reveals the speed of performance decline but also dynamically reflects the impact of the density of risk events on overall performance. Through the trend curve, the critical point of firmware performance can be quantitatively identified, and the potential performance collapse window in the future can be predicted, assisting in the formulation of reasonable firmware upgrade or resource allocation plans. Actual vehicle-mounted testing shows that the model achieves an 85% accuracy rate in predicting the peak response latency within the next 12 hours, providing a scientific basis and practical tool for the long-term stability assurance and intelligent optimization of vehicle-mounted firmware.

[0035] In this embodiment, reference Figure 4 The above is a detailed implementation flowchart of step S3. In this embodiment, the detailed implementation steps of step S3 include: The decay amplitude at multiple points is calculated based on the performance decay trend curve, and a decay abrupt change analysis is performed, which is marked as the decay abrupt change starting point. Based on the starting point of decay mutation, the source of decay mutation precursors is traced and the performance bottleneck is located to obtain the firmware performance bottleneck node. Perform code-level root cause analysis on firmware performance bottleneck nodes to extract code-level attenuation information; Firmware optimization targets are quantified based on code-level attenuation information to generate firmware optimization requirement data.

[0036] In this embodiment, the attenuation magnitude of multiple key nodes in the curve is precisely calculated to quantify the severity of firmware performance degradation. Specifically, several time points on the curve are selected, and the rate of change of performance indicators (such as response latency or throughput) at adjacent time points is calculated. The focus is on time periods where the rate of change exceeds a preset threshold, identifying these as potential degradation abrupt change intervals. The threshold is generally set based on historical data statistics; for example, a response latency change rate exceeding 0.05 ms / min or a throughput decrease exceeding 3% / min is considered a significant abrupt change. In the experiment, 48 hours of sampling data from a certain vehicle navigation firmware revealed six significant attenuation abrupt changes, with an average abrupt change magnitude of 15%-25%. Based on these abrupt change magnitudes, and combined with the CUSUM (cumulative sum control chart) method in statistics, the starting points of the attenuation abrupt changes were further confirmed and precisely marked as "attenuation abrupt change start points." This process effectively distinguishes between normal performance fluctuations and abnormally rapid attenuation, providing clear time anchors for subsequent source tracing analysis. Furthermore, through statistical and distribution analysis of the attenuation magnitudes at multiple points, the frequency and trend characteristics of firmware performance degradation can be revealed, providing key parameter support for the design of dynamic monitoring and early warning systems. After identifying the initiation point of performance degradation, it is necessary to delve into the system behavior and operational state prior to its occurrence to uncover the precursory events and core bottlenecks leading to the performance mutation. This process relies on time-series tracking of firmware behavior state graphs and operational logs, combined with causal inference and event correlation analysis techniques from machine learning. In specific implementation, monitoring data from the 30 minutes preceding each performance degradation initiation point is selected, including instruction call sequences, module resource utilization, interrupt response times, and memory access patterns. By constructing a time backward propagation model (such as inverse LSTM or a Bayesian network based on a causal graph), common abnormal call paths and resource bottleneck nodes before performance mutations are identified. Taking a vehicle control firmware as an example, the experiment located a significant increase in resource contention between the navigation module and the image processing module, and an abnormal surge in the frequency of a certain function call, which became the key bottleneck node causing a sudden increase in response latency. Further dependency analysis was used to clarify the position of this bottleneck node in the module call chain and its impact on overall performance. This step not only achieves accurate precursor tracing of the performance degradation initiation point but also identifies specific modules and functions for performance optimization, improving the targeting and effectiveness of firmware updates.

[0037] By combining static code analysis and dynamic performance profiling techniques, the code execution path, loop complexity, and resource access patterns of bottleneck functions are meticulously traced. Specifically, static analysis tools (such as Coverity and Cppcheck) are used to detect potential code defects and complexity hotspots, while dynamic analysis tools (such as Profiler and Tracealyzer) are used to collect call times, cache hit rates, memory access latency, and thread contention for bottleneck functions. Taking a key bottleneck function identified in a navigation firmware as an example, static analysis revealed multiple nested loops and complex conditional branches, while dynamic performance profiling showed that this function consumed up to 28% of CPU time and had a cache miss rate of 12%. Further analysis revealed frequent global variable accesses and lock contention in the code, leading to a significant performance degradation in a multi-threaded environment. By combining the results of these two types of analysis, a code-level description of performance degradation characteristics is formed, clarifying that the root cause of the performance bottleneck lies in algorithm complexity and improper resource scheduling. This analysis provides specific directions for code improvement and key optimization areas for subsequent firmware optimization.

[0038] Based on code-level attenuation information and performance bottleneck location results, firmware optimization goals were quantified and specific requirements were defined. The quantification process focused on the magnitude of performance metric improvement, such as reducing CPU utilization of bottleneck functions by at least 15%, cache miss rate by 50%, and thread lock wait time by 20%. Simultaneously, optimization goals were refined into specific tasks, such as algorithm complexity simplification, data structure reconstruction, memory access pattern optimization, and concurrency scheduling improvement. For the navigation firmware bottlenecks identified in the experiment, a detailed optimization requirement document was generated, including the corresponding code modules for each goal, priority order, and estimated optimization costs. The requirement data also included the expected performance improvement and risk assessment, facilitating effect verification and risk management in subsequent firmware version iterations. This step ensured that optimization goals were clear and measurable, guiding the development team to focus their efforts on overcoming performance bottlenecks, achieving continuous improvement in overall firmware performance, and ultimately enhancing the stability and response speed of in-vehicle equipment to meet the real-time and reliability requirements of intelligent driving.

[0039] In this embodiment, step S4 includes the following steps: Based on firmware optimization requirements data, multiple optimization direction decisions are made to obtain multiple vehicle equipment optimization directions; Based on the performance degradation trend curve, the expected benefits and optimization difficulty of multiple vehicle equipment optimization directions are calculated to obtain the expected benefits and optimization difficulty of different directions. Define optimization metrics for performance improvement, resource saving, and stability enhancement, and construct a firmware optimization decision tree; The expected returns and optimization difficulty are input into the firmware optimization decision tree to perform multi-index optimization and generate the optimal optimization index strategy. A firmware optimization task list is constructed based on the optimal optimization index strategy.

[0040] In this embodiment, key performance bottlenecks and improvement targets are extracted from optimization requirements. Combined with firmware architecture and hardware resource constraints, directions covering algorithm optimization, resource management, code refactoring, and hardware acceleration adaptation are generated. The Analytic Hierarchy Process (AHP) is used to weight optimization requirements during the decision-making process, evaluating the potential contribution of different directions to performance improvement, stability enhancement, and resource conservation. In the experiment, for a specific vehicle model's in-vehicle firmware, five optimization directions were initially selected, including multi-threaded scheduling optimization, caching mechanism improvement, memory access optimization, algorithm parallelization, and module interface refactoring. Each direction was assigned priority and expected impact range based on historical data and test feedback. For example, multi-threaded scheduling optimization is expected to reduce CPU usage by 10%-15%, and caching mechanism improvement is expected to increase cache hit rate by 10%. Furthermore, the feasibility of each optimization direction is evaluated based on the actual hardware resources of the in-vehicle equipment, such as the number of CPU cores, memory capacity, and bandwidth. Through comprehensive analysis of multiple indicators, multiple optimization paths covering performance, resources, and stability are ultimately formed, laying the foundation for subsequent detailed analysis and optimization strategy formulation. The expected benefits and optimization difficulty of each vehicle equipment optimization direction are quantified using the performance degradation trend curve as the core data. Expected benefits refer to the improvement in performance metrics (such as response latency and throughput) after optimization, while optimization difficulty encompasses development cycle, risk, and resource consumption. In practice, a regression analysis model is used to correlate the expected code-level improvements corresponding to the optimization direction with historical performance degradation data, estimating the potential latency reduction and resource savings. Taking a navigation firmware as an example, the caching mechanism improvement is expected to reduce latency by 12%, with an optimization difficulty index of 0.6 (0-1 scale); algorithm parallelization is expected to reduce latency by 18%, but the difficulty index is as high as 0.85. Furthermore, considering the complexity of hardware and software coupling, code compatibility, and testing workload, an optimization difficulty evaluation system is constructed. This system combines expert scoring with historical project data to ensure the objectivity and accuracy of the evaluation. Through comparative analysis, the benefits and costs of optimization directions are clarified, effectively identifying high-return, low-difficulty and high-difficulty, low-return optimization paths, providing a basis for the scientific allocation of development resources.

[0041] To systematically guide the firmware optimization process, three main categories of optimization metrics were clearly defined: performance improvement, resource conservation, and stability enhancement. Performance improvement metrics primarily cover the reduction in response latency (target 10%-20%) and throughput improvement (target 15%-25%). Resource conservation metrics focus on reducing CPU utilization (target 5%-10%) and memory usage (target 8%-15%). Stability metrics emphasize reducing error rate (target below 30%) and system crash frequency. The metric definition process considered both the actual application scenarios and security requirements of automotive firmware, taking into account both real-time performance and reliability. Based on these metrics, a firmware optimization decision tree model was constructed. The decision tree uses the optimization direction as the root node, with branches representing the achievement status of each metric and the corresponding implementation plan. The decision tree utilizes a hierarchical filtering method to decompose the complex multi-objective optimization problem into quantifiable sub-tasks, facilitating gradual optimization and dynamic adjustment. In experimental verification, the decision tree structure in an automotive environment can achieve comprehensive evaluation of multiple solutions, quickly selecting the optimal path that meets the metric thresholds, greatly improving the efficiency and accuracy of optimization decisions. The expected benefits and optimization difficulty of each optimization direction are used as input variables and imported into a firmware optimization decision tree. Multi-index optimization algorithms (such as weighted scoring and Pareto optimization) are then used to solve the problem. Specifically, the hierarchical structure of the decision tree is used to evaluate the comprehensive performance of each direction in terms of performance improvement, resource saving, and stability enhancement, while simultaneously weighing its implementation difficulty and risk to arrive at the optimal trade-off. The experiment uses a weighted allocation: 40% performance improvement, 30% resource saving, and 30% stability enhancement. Cross-validation is used to verify the model's robustness. The calculation results generate an optimization strategy ranking, identifying high-benefit and moderately difficult solutions as the first choice. For example, algorithm parallelization has the highest priority, followed by improvements to caching mechanisms and multi-threaded scheduling optimization. This process effectively avoids wasting resources on directions with excessive difficulty and limited benefits, ensuring the efficiency and controllability of the optimization process. The final output of the optimal optimization index strategy provides a clear implementation roadmap for firmware upgrades, guiding the development team to focus on key improvement points. Based on the optimal optimization index strategy, a detailed firmware optimization task list is refined and constructed. The task list includes detailed implementation steps, target indicators, priority ranking, and expected completion time for each optimization direction. The task list clearly assigns responsibility modules and key nodes, covering code refactoring, algorithm optimization, resource scheduling adjustments, and verification testing. In the experimental project, the task list sets multi-stage milestones: the first stage focuses on improving the caching mechanism and optimizing multi-threaded scheduling; the second stage promotes algorithm parallelization. Each task includes performance targets, such as a 12% reduction in response latency and an 8% reduction in CPU utilization, along with corresponding verification standards and performance evaluation methods. By dynamically updating the task list, iterative optimization and continuous improvement are achieved, ensuring the firmware optimization work progresses systematically. This step guarantees a seamless connection between theoretical analysis and practical development, improving the performance and stability of the vehicle equipment firmware and meeting the stringent requirements of complex driving environments.

[0042] In this embodiment, step S5 includes the following steps: Based on the firmware optimization task list, simulate firmware configuration update parameters and generate multiple configuration update parameter schemes; Simulate and execute each of the multiple configuration update parameter schemes one by one to generate the execution effects of different schemes; The firmware optimization effect is evaluated for the execution effect of different schemes, and the evaluation value of each firmware optimization effect is obtained; Based on the optimal optimization index strategy, the expected performance improvement deviation of each firmware optimization effect evaluation value is analyzed, and the optimal configuration parameters are selected to obtain the configuration update parameter scheme.

[0043] In this embodiment, key optimization points in the task list are transformed into adjustable configuration parameters, such as the number of threads, cache size, scheduling priority, and memory allocation strategy. For each parameter, a reasonable value range and step size are set, and the initial parameter boundaries are determined based on historical data and hardware resource constraints. The Design of Experiments (DOE) method is used to combine different parameter values ​​to form multiple configuration schemes. Taking a certain automotive firmware system as an example, the number of threads is set to 2 to 8 threads, the cache size is between 128KB and 512KB, and the scheduling priority is divided into 3 levels, generating approximately 50 different configuration schemes. Subsequently, these schemes are initialized and simulated using a simulation environment to observe their performance in terms of system resource consumption, task response time, and exception handling capabilities. Based on multiple configuration parameter update schemes, each scheme is executed and tested on the simulation platform, and the running performance data of each scheme is collected and recorded. The simulation execution environment is usually based on a real automotive hardware simulator or a high-precision virtual machine, capable of reproducing the firmware's running state under different hardware resource and load conditions. During simulation, key performance indicators such as CPU utilization, response latency, memory utilization, and system throughput are monitored. Simulations for each configuration typically last from several hours to over ten hours to ensure coverage of various typical operating scenarios and edge cases. Taking a navigation firmware as an example, after simulating 50 configurations, it was found that the configuration with 4 threads and a 256KB cache showed a better balance between response latency and resource consumption, with an average reduction in response latency of approximately 12% and a reduction in CPU utilization of approximately 8%. Furthermore, anomaly rates and system stability indicators were monitored during execution to ensure that optimization not only focused on performance but also on system reliability. The evaluation system is based on the aforementioned three core indicators: performance improvement, resource conservation, and enhanced stability. Scores are calculated for each configuration regarding the percentage reduction in response time, changes in CPU and memory utilization, and reduction in error rate. The evaluation process incorporates a multi-indicator weighting method to ensure that overall performance is objectively reflected. For example, a weight of 40% is set for response latency, 30% for resource utilization, and 30% for stability, and scores are assigned to each configuration based on experimental data. Taking a firmware optimization simulation as an example, scheme A scored 0.82, scheme B scored 0.75, and scheme C scored 0.88. Through normalization, the scores were mapped to the 0-1 interval for easy horizontal comparison. The evaluation also included confidence interval analysis to measure the stability of the effect under different operating scenarios and prevent bias caused by optimization in a single scenario. After the firmware optimization effect evaluation was completed, a deviation analysis of the expected performance improvement was conducted in conjunction with the previously established optimal optimization index strategy. This step identified potential performance deviations and optimization bottlenecks by comparing the actual optimization effect of each scheme with the theoretical expectation. The analysis methods typically employed error analysis and statistical tests to assess the significance of the deviation and its source, ensuring that the selected optimization schemes met the overall optimization objectives.For example, regarding the response latency reduction metric, the difference between the actual reduction and the policy target for each solution is calculated, and the mean squared error (MSE) of each solution is statistically analyzed, eliminating solutions with large deviations and instability. Based on this analysis, and combined with a multi-objective trade-off method, the configuration solution that best performs in terms of performance improvement, resource saving, and stability, and is closest to the expected result, is selected. Experimental results show that the solution with 4 threads and 256KB of cache not only has the highest score but also the smallest deviation, becoming the final configuration update parameter solution.

[0044] In this embodiment, step S6 includes the following steps: Generate firmware configuration optimization strategy packages based on configuration update parameter schemes; Progressive updates are deployed based on firmware configuration optimization strategy packages, and real-time configuration update process detection is performed to extract update detection parameters throughout the entire process. Identify abnormal update processes in the entire process of update detection parameters and mark abnormal update status points; Calculate the timestamp of the abnormal update state point, and perform pre-stable state identification to extract stable configuration state parameters; An adaptive state rollback mechanism is constructed based on stable configuration state parameters. A fully automated iterative closed-loop optimization engine for vehicles is constructed based on an adaptive state rollback mechanism and a configuration update parameter scheme.

[0045] In this embodiment, after determining the final configuration update parameter scheme, it is packaged into a firmware configuration optimization strategy package. The strategy package includes key components such as specific parameter configuration files, upgrade scripts, verification rules, and rollback mechanisms. The generation process ensures the reusability and traceability of the configuration scheme through parameter templates and version control management. In specific implementation, configuration management tools (such as customized lightweight versions of Ansible and Puppet) are used to uniformly package the parameters and associate them with firmware version, device type, and application scenario tags. Taking a certain vehicle control unit as an example, the strategy package defines parameters for thread number adjustment, cache size optimization, and priority scheduling, and also includes monitoring thresholds and anomaly alarm rules for key performance indicators. In the experiment, the strategy package generation cycle was approximately several hours, covering more than 20 configuration parameters, supporting flexible combinations. This strategy package is the foundation for subsequent automated deployment and dynamic adjustment, ensuring the standardization and automation of the optimization process. Based on the strategy package, a gradual update deployment of firmware configuration is implemented, i.e., pushing optimized configurations in stages and batches to avoid the risks of a large-scale update at once. The deployment strategy leverages OTA (Over-The-Air) technology, initially piloting it on a small sample of vehicles before gradually expanding to the entire fleet. A real-time configuration update monitoring system is simultaneously activated, employing an online monitoring framework to collect parameters in real time, such as update progress, success rate, response latency, and resource usage. Monitoring parameters include update timestamps, configuration effective times, system load change curves, and anomaly logs, with a sampling frequency of once per second to ensure fine-grained tracking. Experimental results show that incremental updates control the update failure rate to below 0.5% in a real-world environment, and real-time monitoring allows for rapid identification and isolation of abnormal vehicles. This phase achieves controllability and transparency in the update process, laying a solid data foundation for subsequent anomaly identification and performance evaluation.

[0046] Based on real-time collected end-to-end update detection parameters, automatic identification of abnormal update processes is implemented. Specifically, a multi-index anomaly detection algorithm is employed, combined with statistical threshold analysis and machine learning anomaly detection models (such as Isolation Forest and LOF), to score anomalies in indicators such as update time, system response latency, and sudden changes in resource utilization. Upon identification of an anomaly, the corresponding time point is immediately marked as an abnormal update status point. Monitoring of 200 update processes for a certain firmware version revealed that abnormal update status points mainly concentrated on transmission failures caused by network fluctuations and system instability caused by configuration parameter conflicts. Abnormal status points accounted for 3% of the overall update time, with a location accuracy of 95%. This step achieves automated and accurate anomaly identification, significantly improving update security and providing crucial triggering evidence for anomaly handling and subsequent rollback.

[0047] For marked abnormal update state points, the timestamp of each occurrence is first accurately calculated, and time series analysis is used to reverse-engineer the system's stable state before the anomaly. A sliding window method is employed to analyze the volatility of key performance indicators (such as CPU utilization, memory usage, and response latency) during the update process, determining the preceding stable state interval. Configuration state parameters within this interval are extracted as stable configuration state parameters based on statistical thresholds and trends. Taking a vehicle firmware update as an example, the average length of the stable state interval is 30 seconds, and the stable configuration state parameters include a thread count maintained at 4, a cache hit rate exceeding 85%, and a response latency maintained within 100ms. Accurate identification of the stable state provides crucial reference for subsequent adaptive state rollback, enabling the rollback operation to quickly restore the system to an efficient and reliable state, minimizing the impact of the anomaly. The adaptive state rollback mechanism, based on the stable configuration state parameters extracted in the previous step, achieves rapid response and automatic recovery from abnormal updates. This mechanism combines state machine design and threshold triggering strategy. When an abnormal update state point is detected, the system automatically determines whether to trigger a rollback. If triggered, it dynamically restores the system to the previous healthy and stable configuration state based on stable configuration state parameters. The rollback process includes parameter replacement, module restart, and resource reallocation, ensuring minimal impact on the system. In the experimental environment, the average rollback time was controlled within 10 seconds, with a success rate of 98%. Furthermore, by dynamically adjusting the rollback threshold and strategy, the mechanism possesses adaptive adjustment capabilities, flexibly adjusting the rollback trigger conditions according to different vehicle models and operating environments, improving the robustness of firmware updates and system stability. Finally, combining the adaptive state rollback mechanism with the configuration update parameter scheme, a fully automated vehicle iterative closed-loop optimization engine is constructed. This engine achieves closed-loop management of automatic firmware configuration deployment, real-time monitoring, anomaly identification, rollback recovery, and optimization strategy updates. Based on machine learning and reinforcement learning algorithms, the engine automatically analyzes historical update data and performance feedback, continuously optimizing configuration schemes and rollback strategies. In experimental deployments, the engine supports multiple daily iterative updates, automatically identifying optimal parameter combinations and gradually improving vehicle performance, significantly shortening the manual intervention cycle. Taking a certain vehicle control system as an example, iterative closed-loop optimization reduced the average response latency by 15%, improved system stability by 20%, and optimized resource utilization by 10%. This mechanism promotes the transformation of vehicle firmware from traditional static updates to intelligent, adaptive, and continuous optimization, achieving an efficient and secure firmware upgrade ecosystem.

[0048] In this embodiment, a vehicle-mounted device optimization system based on firmware updates is provided, for executing the vehicle-mounted device optimization method based on firmware updates as described above, including: The firmware status unit is used to perform full monitoring of the operating status of the vehicle firmware module, and to perform multi-behavioral status perception modeling to construct a firmware behavior status map. The degradation status unit is used to perform dynamic trend analysis on the firmware behavior state graph, model the performance degradation status, and construct the performance degradation status curve. The optimization requirement unit is used to perform code-level program root cause analysis based on the performance degradation trend curve, quantify firmware optimization targets, and generate firmware optimization requirement data. The optimization and solution unit is used to make decisions on multiple optimization directions based on firmware optimization requirement data, perform multi-index optimization solutions, and build a firmware optimization task list; The configuration update unit is used to simulate firmware configuration update parameters based on the firmware optimization task list, select the optimal configuration parameters, and obtain a configuration update parameter scheme. The incremental update unit is used to deploy incremental updates based on configuration update parameter schemes, and then perform fully automatic iterative closed-loop optimization to build a vehicle iterative closed-loop optimization engine.

[0049] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0050] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein are implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A method for optimizing in-vehicle equipment based on firmware updates, characterized in that, Includes the following steps: Step S1: Perform full monitoring of the operating status of the vehicle firmware module, and perform multi-behavioral state perception modeling to construct a firmware behavior state map; Step S2: Perform dynamic trend analysis on the firmware behavior state graph, model the performance degradation situation, and construct the performance degradation situation curve; Step S3: Based on the performance degradation trend curve, perform code-level program root cause analysis, quantify firmware optimization targets, and generate firmware optimization requirement data; Step S4: Based on firmware optimization requirement data, make decisions on multiple optimization directions, perform multi-index optimization solutions, and construct a firmware optimization task list; Step S5: Simulate firmware configuration update parameters based on the firmware optimization task list, select the optimal configuration parameters, and obtain the configuration update parameter scheme; Step S6: Based on the configuration update parameter scheme, perform incremental update deployment, and then perform fully automatic iterative closed-loop optimization to build a vehicle iterative closed-loop optimization engine.

2. The method for optimizing in-vehicle equipment based on firmware updates according to claim 1, characterized in that, The specific steps of step S1 are as follows: Full monitoring of the operational status of the vehicle firmware module is performed, and the CPU instruction execution sequence, function call stack, memory access mode, and interrupt response timing of the vehicle firmware are collected to fit and construct a multi-dimensional underlying operation monitoring trajectory. The underlying multi-dimensional operation monitoring trajectory is divided into multiple time windows, and the operation monitoring trajectory of multiple time windows is extracted; The execution time distribution of each firmware module is calculated for the operation monitoring trajectory of multiple time windows, and the execution time distribution map of each firmware module is generated. Based on the execution time distribution map, perform inter-module call dependency analysis to extract the call dependency relationships between modules; Based on the aforementioned call dependencies, multi-behavioral state-aware modeling is performed to construct a firmware behavior state graph.

3. The method for optimizing in-vehicle equipment based on firmware updates according to claim 2, characterized in that, The specific steps for constructing a firmware behavior state graph by performing multi-behavior state-aware modeling based on the call dependency relationship are as follows: Based on the call dependencies, the underlying multi-dimensional operation monitoring trajectory is dynamically parsed to generate a call sequence of instruction execution order; The frequency of module calls is calculated based on the order of instruction execution, and resource contention analysis of multiple firmware modules is performed to generate resource contention patterns. State transition analysis is performed on the instruction execution sequence to identify high-frequency execution paths and key execution nodes; Based on high-frequency execution paths and key execution nodes, a global state transition graph is constructed to represent the execution behavior state transition. Graph embedding encoding is performed on the execution behavior state transition graph to obtain multiple low-dimensional feature vectors of the execution state; Vector pattern classification is performed on low-dimensional feature vectors of multiple execution states, and multi-behavioral state perception modeling is carried out to construct a firmware behavior state map.

4. The method for optimizing in-vehicle equipment based on firmware updates according to claim 1, characterized in that, The specific steps of step S2 are as follows: A time-series correlation analysis is performed on the firmware behavior state graph, and long-term firmware operation prediction is made to obtain long-term operating performance indicators, including firmware response latency, throughput, and resource utilization. Dynamic trend analysis of long-term operating performance indicators is performed to extract the firmware performance change patterns; Based on the firmware performance change pattern, predict the firmware performance degradation risk and mark multiple performance degradation risk points; The performance degradation rate is calculated for multiple performance degradation risk points to obtain the time-series performance degradation rate. Calculate the decay time interval of the multiple performance degradation risk points; Based on the decay time interval and time-series performance decay rate, a performance decay trend model is constructed, and a performance decay trend curve is generated.

5. The method for optimizing in-vehicle equipment based on firmware updates according to claim 1, characterized in that, Step S3 is as follows: The decay amplitude at multiple points is calculated based on the performance decay trend curve, and a decay abrupt change analysis is performed, which is marked as the decay abrupt change starting point. Based on the starting point of decay mutation, the source of decay mutation precursors is traced and the performance bottleneck is located to obtain the firmware performance bottleneck node. Perform code-level root cause analysis on firmware performance bottleneck nodes to extract code-level attenuation information; Firmware optimization targets are quantified based on code-level attenuation information to generate firmware optimization requirement data.

6. The method for optimizing in-vehicle equipment based on firmware updates according to claim 1, characterized in that, The specific steps of step S4 are as follows: Based on firmware optimization requirements data, multiple optimization direction decisions are made to obtain multiple vehicle equipment optimization directions; Based on the performance degradation trend curve, the expected benefits and optimization difficulty of multiple vehicle equipment optimization directions are calculated to obtain the expected benefits and optimization difficulty of different directions. Define optimization metrics for performance improvement, resource saving, and stability enhancement, and construct a firmware optimization decision tree; The expected returns and optimization difficulty are input into the firmware optimization decision tree to perform multi-index optimization and generate the optimal optimization index strategy. A firmware optimization task list is constructed based on the optimal optimization index strategy.

7. The method for optimizing in-vehicle equipment based on firmware updates according to claim 1, characterized in that, The specific steps of step S5 are as follows: Based on the firmware optimization task list, simulate firmware configuration update parameters and generate multiple configuration update parameter schemes; Simulate and execute each of the multiple configuration update parameter schemes one by one to generate the execution effects of different schemes; The firmware optimization effect is evaluated for the execution effect of different schemes, and the evaluation value of each firmware optimization effect is obtained; Based on the optimal optimization index strategy, the expected performance improvement deviation of each firmware optimization effect evaluation value is analyzed, and the optimal configuration parameters are selected to obtain the configuration update parameter scheme.

8. The method for optimizing in-vehicle equipment based on firmware updates according to claim 1, characterized in that, The specific steps of step S6 are as follows: Generate firmware configuration optimization strategy packages based on configuration update parameter schemes; root The firmware configuration optimization strategy package is used to perform incremental updates and deployments, and the configuration update process is monitored in real time to extract update detection parameters throughout the entire process. Identify abnormal update processes in the entire process of update detection parameters and mark abnormal update status points; Calculate the timestamp of the abnormal update state point, and perform pre-stable state identification to extract stable configuration state parameters; An adaptive state rollback mechanism is constructed based on stable configuration state parameters. A fully automated iterative closed-loop optimization engine for vehicles is constructed based on an adaptive state rollback mechanism and a configuration update parameter scheme.

9. A vehicle-mounted equipment optimization system based on firmware updates, characterized in that, The method for performing the on-board equipment optimization method based on firmware update as described in claim 1 includes: The firmware status unit is used to perform full monitoring of the operating status of the vehicle firmware module, and to perform multi-behavioral status perception modeling to construct a firmware behavior status map. The degradation status unit is used to perform dynamic trend analysis on the firmware behavior state graph, model the performance degradation status, and construct the performance degradation status curve. The optimization requirement unit is used to perform code-level program root cause analysis based on the performance degradation trend curve, quantify firmware optimization targets, and generate firmware optimization requirement data. The optimization and solution unit is used to make decisions on multiple optimization directions based on firmware optimization requirement data, perform multi-index optimization solutions, and build a firmware optimization task list; The configuration update unit is used to simulate firmware configuration update parameters based on the firmware optimization task list, select the optimal configuration parameters, and obtain a configuration update parameter scheme. The incremental update unit is used to deploy incremental updates based on configuration update parameter schemes, and then perform fully automatic iterative closed-loop optimization to build a vehicle iterative closed-loop optimization engine.

Images