A new energy vehicle communication controller software upgrading method and system

Abstract

This invention relates to the field of software upgrade control technology, and in particular to a method and system for upgrading the software of a new energy vehicle communication controller. The method includes the following steps: acquiring vehicle load current data; performing temperature compensation based on the vehicle load current data to obtain a compensated battery power consumption feature vector; performing sleep cycle prediction and power consumption scheduling on the vehicle based on the compensated battery power consumption feature vector to obtain a sleep cycle transmission scheduling benchmark; acquiring the original software upgrade package; constructing a functional unit dependency graph based on the original software upgrade package; and fragmenting the original software upgrade package according to the sleep cycle transmission scheduling benchmark and the functional unit dependency graph to obtain a fragmented upgrade package. This invention solves the problems of power consumption, transmission interruption, and fault risks faced by new energy vehicle communication controllers during software upgrades in deep sleep mode, significantly improving the reliability and stability of software upgrades.

Description

Technical Field

[0001] This invention relates to the field of software upgrade control technology, and in particular to a method and system for upgrading the software of a communication controller for new energy vehicles. Background Technology

[0002] The core control of new energy vehicles relies on numerous electronic control units (ECUs) distributed throughout the vehicle body, among which communication controllers (such as vehicle gateways and T-Boxes) play a crucial role in the interaction of information between the vehicle and the outside world. To ensure functional iteration, security patch updates, and performance optimization, remote over-the-air (OTA) software upgrades for communication controllers have become an industry standard practice. Currently, the mainstream solution typically relies on the vehicle being parked under specific operating conditions (such as when the engine is off and the vehicle is connected to a charging station). The cloud server initiates the upgrade command, transmits the upgrade package to the target controller via a cellular network, and the controller performs local flashing verification after receiving the complete package.

[0003] However, in typical application scenarios where vehicles are parked for extended periods and rely solely on small-capacity batteries to maintain minimal power consumption, existing upgrade methods face a technical challenge: the conflict between maintaining a reliable network connection while the communication controller is in deep sleep mode and ensuring the complete reception of large upgrade packages. To conserve battery power to maintain core functions such as basic vehicle status monitoring and unlocking, the communication controller frequently and deeply enters low-power sleep mode during parking periods, periodically forcibly shutting down its network connections (such as 4G / 5G modules) or placing them in a standby state with extremely low bandwidth. In this situation, if the cloud initiates the transmission of a large software upgrade package, the transmission process is highly likely to be forcibly interrupted by the controller's periodic sleep mode.

[0004] The consequences of such unpredictable transmission interruptions caused by sleep strategies go far beyond simple transmission delays or retries. In complex controller software upgrades, especially those involving multi-component collaboration or underlying firmware updates, upgrade packages typically contain strictly sequential instruction sequences and verification information. When transmission is hard-terminated at any non-designed breakpoint within the package, the receiving controller receives only a fragmented data segment with broken internal logic. When the controller's local firmware attempts to process this "half-finished" upgrade package, it may, at best, discard it due to verification failure, resulting in invalid transmission and wasted power; at worst, unpredictable logical errors may occur during parsing or pre-flashing, causing the controller's core functions to malfunction or even become unusable, completely losing communication capabilities and leaving the vehicle unable to be remotely diagnosed or repaired, ultimately requiring expensive on-site roadside assistance and manual intervention. Summary of the Invention

[0005] Therefore, the present invention needs to provide a method and system for upgrading the communication controller software of a new energy vehicle to solve at least one of the above-mentioned technical problems.

[0006] To achieve the above objectives, a method for upgrading the communication controller software of a new energy vehicle includes the following steps: Step S1: Obtain vehicle load current data through the vehicle's built-in current sensor, and perform temperature compensation based on the vehicle load current data to obtain the compensated battery power consumption feature vector; perform sleep cycle prediction and power consumption scheduling on the vehicle based on the compensated battery power consumption feature vector to obtain the sleep cycle transmission scheduling benchmark. Step S2: Obtain the original software upgrade package; construct a functional unit dependency graph based on the original software upgrade package; fragment the original software upgrade package according to the sleep cycle transmission scheduling benchmark and the functional unit dependency graph to obtain fragmented upgrade packages; Step S3: Verify the integrity of the fragmented upgrade package to obtain the verified molecular cache set; perform transmission recovery scheduling on the verified molecular cache set through the breakpoint resume scheduler to obtain fragmented transmission recovery status data; Step S4: Obtain the hardware configuration of the vehicle communication unit through the vehicle OBD-II diagnostic interface and identify redundant paths to obtain a redundant communication path table; ensure continuous transmission based on the redundant communication path table and the fragmented transmission recovery status data to obtain the upgrade package continuous transmission guarantee data. Step S5: Based on the continuous transmission of the upgrade package and the guarantee data, perform fault level location to obtain fault level location data; perform minimum function firmware maintenance based on the fault level location data to obtain the controller software upgrade result.

[0007] This invention accurately predicts a vehicle's sleep cycle by acquiring onboard load current data and combining it with temperature compensation. This allows the system to rationally schedule software upgrade transmission before the vehicle enters a low-power sleep mode, avoiding network connection interruptions caused by sleep. Through a power scheduling strategy based on compensated battery power consumption feature vectors, it ensures that the vehicle's power consumption remains within a controllable range during the upgrade process, meeting both the vehicle's low-power operation requirements and providing stable power support for software upgrades. By constructing a functional unit dependency graph, the original software upgrade package is intelligently fragmented. This considers not only the size and transmission efficiency of the upgrade package but also the dependencies between functional units. This means that even if transmission is interrupted due to sleep, the system can quickly resume transmission and ensure the integrity of the upgrade package based on the received fragmented data and dependency graph. Compared to traditional whole-transmission methods, this method significantly improves the flexibility and reliability of upgrades and reduces the risk of upgrade failure due to transmission interruptions. This invention introduces a redundant path identification mechanism, ensuring the continuity of the upgrade package during transmission by monitoring communication quality in real time and dynamically adjusting redundant communication paths. Even if the primary communication path is interrupted due to vehicle sleep mode, the system can seamlessly switch to the backup path to continue transmitting the upgrade package. This effectively solves the transmission interruption problem caused by the communication controller's sleep mode in existing technologies, significantly improving the stability and reliability of the upgrade process. During the upgrade process, this invention can accurately locate faults and perform minimum functional firmware maintenance according to the fault level. This not only enables rapid diagnosis and repair of problems that occur during the upgrade process but also ensures that the controller retains basic functions even if the upgrade fails, avoiding the risk of the controller becoming unusable due to upgrade failure. Through the above operations, this invention significantly improves the fault tolerance and self-healing capabilities of the vehicle communication controller, ensuring the normal operation of the vehicle during the upgrade process, enhancing user experience and vehicle reliability. In summary, this invention comprehensively solves the problems of power consumption, transmission interruption, and fault risks faced by new energy vehicle communication controllers during software upgrades in deep sleep mode, significantly improving the reliability and stability of software upgrades.

[0008] Preferably, the present invention also provides a new energy vehicle communication controller software upgrade system for executing the new energy vehicle communication controller software upgrade method described above, the new energy vehicle communication controller software upgrade system comprising: The power consumption prediction module is used to acquire on-board load current data through the vehicle's built-in current sensor, and perform temperature compensation based on the on-board load current data to obtain a compensated battery power consumption feature vector; based on the compensated battery power consumption feature vector, the module performs sleep cycle prediction and power consumption scheduling for the vehicle to obtain a sleep cycle transmission scheduling benchmark. The fragmentation management module is used to obtain the original software upgrade package; construct a functional unit dependency graph based on the original software upgrade package; and fragment the original software upgrade package according to the sleep cycle transmission scheduling benchmark and the functional unit dependency graph to obtain fragmented upgrade packages. The verification and recovery module is used to verify the integrity of the fragmented upgrade package and obtain a set of verified molecular caches; the transmission recovery scheduling of the set of verified molecular caches is performed through the breakpoint resume scheduler to obtain fragmented transmission recovery status data. The transmission assurance module is used to obtain the hardware configuration of the vehicle communication unit through the vehicle OBD-II diagnostic interface and perform redundant path identification to obtain a redundant communication path table; based on the redundant communication path table and the fragmented transmission recovery status data, it performs continuous transmission assurance to obtain upgrade package continuous transmission assurance data. The fault handling module is used to locate fault levels based on the continuous transmission of protection data from the upgrade package, and obtain fault level location data; based on the fault level location data, it performs minimum functional firmware maintenance to obtain the controller software upgrade result.

[0009] This invention, by accurately acquiring vehicle load current data and performing temperature compensation, can effectively predict vehicle sleep cycles and rationally schedule power consumption. This enables more refined power management, achieving a balance between the vehicle's low-power requirements and software upgrade needs, avoiding vehicle startup failure due to excessive power consumption or upgrade failure due to insufficient power. By intelligently fragmenting the original software upgrade package and constructing a functional unit dependency graph, this not only improves the flexibility of upgrade package transmission but also ensures the integrity and order of fragmented data during transmission. Even in the event of transmission interruption, it can quickly recover and continue transmission, greatly improving the upgrade success rate. By verifying the integrity of the fragmented upgrade package and fusing and scheduling the transmission recovery of verified data, this module ensures the accuracy and integrity of each fragmented data, avoiding upgrade failure due to data loss or corruption. Furthermore, the recovery scheduling mechanism further improves the reliability and stability of transmission. Through redundant path identification, continuous transmission of fragmented transmission recovery status data is guaranteed. This module can monitor communication quality in real time and seamlessly switch to a backup path when the main path is interrupted, ensuring complete reception of the upgrade package and effectively solving the transmission interruption problem caused by the communication controller's sleep state. By continuously transmitting backup data based on upgrade packages to pinpoint fault levels and performing minimum functionality firmware maintenance, this module can quickly diagnose and repair faults during the upgrade process. This ensures that the controller retains basic functionality even if the upgrade fails, avoiding the risk of the controller becoming unusable due to upgrade failure and significantly improving the system's fault tolerance and self-healing capabilities. Attached Figure Description

[0010] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description taken in conjunction with the accompanying drawings: Figure 1 A flowchart illustrating the steps of a new energy vehicle communication controller software upgrade method according to an embodiment is shown. Figure 2 A detailed flowchart of step S18 of one embodiment is shown; Figure 3 A detailed flowchart of step S47 of one embodiment is shown. Detailed Implementation

[0011] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0012] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0013] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0014] To achieve the above objectives, please refer to Figures 1 to 3 This invention provides a method for upgrading the communication controller software of a new energy vehicle, comprising the following steps: Step S1: Obtain vehicle load current data; perform temperature compensation based on vehicle load current data to obtain the compensated battery power consumption feature vector; perform sleep cycle prediction and power consumption scheduling on the vehicle based on the compensated battery power consumption feature vector to obtain the sleep cycle transmission scheduling benchmark. Step S2: Obtain the original software upgrade package; construct a functional unit dependency graph based on the original software upgrade package; fragment the original software upgrade package according to the sleep cycle transmission scheduling benchmark and the functional unit dependency graph to obtain fragmented upgrade packages; Step S3: Verify the integrity of the fragmented upgrade package to obtain the verified molecular cache set; perform transmission recovery scheduling on the verified molecular cache set through the breakpoint resume scheduler to obtain fragmented transmission recovery status data; Step S4: Obtain the hardware configuration of the vehicle communication unit through the vehicle OBD-II diagnostic interface and identify redundant paths to obtain a redundant communication path table; ensure continuous transmission based on the redundant communication path table and the fragmented transmission recovery status data to obtain the upgrade package continuous transmission guarantee data. Step S5: Based on the continuous transmission of the upgrade package and the guarantee data, perform fault level location to obtain fault level location data; perform minimum function firmware maintenance based on the fault level location data to obtain the controller software upgrade result.

[0015] Preferably, step S1 includes the following steps: Step S11: Obtain vehicle ambient temperature data and acquire vehicle load current distribution monitoring data through the vehicle's built-in current sensor; Step S12: Simultaneously acquire vehicle load current distribution monitoring data through multiple channels to obtain vehicle load current data; Step S13: Perform Kalman time-domain filtering on the vehicle load current data to obtain steady-state load current signal data; Step S14: Evaluate battery capacity degradation based on steady-state load current signal data to obtain the vehicle battery capacity degradation coefficient; Step S15: Calculate the temperature influence factor based on the vehicle ambient temperature data and the vehicle battery capacity decay coefficient to obtain the temperature power consumption correction factor; Step S16: Perform power consumption distribution spectrum analysis based on the vehicle load current data to obtain the frequency domain characteristic data of load power consumption; Step S17: Perform spectral entropy weighted integration on the load power consumption frequency domain feature data and the temperature power consumption correction factor to obtain the compensated battery power consumption feature vector.

[0016] In this embodiment, in a new energy vehicle, an ambient temperature sensor and a current sensor built into the vehicle are used to acquire relevant data. The ambient temperature sensor is installed in the vehicle's battery compartment and can measure the ambient temperature around the battery in real time, with a measurement range of -40℃ to 80℃ and an accuracy of ±0.5℃. Current sensors are distributed at key electrical nodes in the vehicle, such as the battery management system, on-board charger, and high-voltage motor controller, to monitor the current distribution under different loads. These sensors transmit data to the on-board computing platform via the vehicle's CAN bus. For example, after the vehicle starts, the ambient temperature sensor records a battery compartment temperature of 25℃, and the current sensors detect a battery management system load current of 5A, an on-board charger load current of 3A, and a high-voltage motor controller load current of 100A during vehicle operation. This data is collected in real time and stored in the database of the on-board computing platform. A multi-channel synchronous acquisition device is used, which has multiple data acquisition channels and can simultaneously receive signals from different current sensors. Taking the vehicle's battery management system, on-board charger, and high-voltage motor controller as examples, the three channels of the multi-channel synchronous acquisition device are connected to the corresponding current sensor output terminals. The acquisition device uses an internal synchronization clock module to ensure that all channels collect data simultaneously at the same sampling frequency (e.g., 100Hz), avoiding data correlation errors caused by sampling time differences. During vehicle operation, the acquisition device simultaneously records the current value of each load node according to the set sampling frequency. For example, at a certain moment, the battery management system load current is 5.2A, the on-board charger load current is 3.1A, and the high-voltage motor controller load current is 102A. These data are accurately recorded and timestamped to form a complete sequence of on-board load current data. The Kalman filter algorithm is used to filter the acquired on-board load current data to remove noise and extract the steady-state load current signal. Taking the load current data of the vehicle's high-voltage motor controller as an example, the acquired current data contains noise caused by factors such as motor speed fluctuations and electromagnetic interference. Based on the characteristics of the load current data, a state-space model of the Kalman filter is established, where the state variable is the actual load current value, and the observed variable is the acquired noisy current data. By setting appropriate filter parameters, such as the process noise covariance matrix and the observation noise covariance matrix, the Kalman filter can recursively calculate the estimated load current value at the current moment based on the current observation value and the state estimate value at the previous moment. For example, the collected load current data of the high-voltage motor controller fluctuates within a certain time period. After Kalman filtering, steady-state load current signal data is obtained. Based on the battery's rated capacity and the vehicle's driving conditions, the theoretical discharge curve of the battery under different loads is determined. The steady-state load current signal data after Kalman filtering is then compared and analyzed with the theoretical discharge curve.For example, for a lithium-ion battery with a rated capacity of 50Ah, the actual discharge amount of the battery is calculated based on the collected steady-state load current signal during vehicle operation. By comparing it with the theoretical discharge amount of the battery, it is found that the actual discharge amount is 5% less than the theoretical discharge amount, indicating that the battery capacity has decayed by 5%. Based on this result, the vehicle battery capacity decay coefficient is calculated to be 0.05. For detailed implementation of step S15, please refer to the sub-steps of step S15. The Fast Fourier Transform (FFT) algorithm is used to perform power distribution spectrum analysis on the vehicle load current data. Taking the load current data of the vehicle's high-voltage motor controller as an example, the collected steady-state load current signal data is input into the FFT analysis tool. The FFT algorithm converts the load current signal in the time domain into a frequency domain signal, obtaining the load current spectrum. By analyzing the spectrum, the power consumption characteristics corresponding to different frequency components can be identified. For example, a significant frequency component is found in the spectrum at 50Hz, with a large corresponding power consumption amplitude, indicating that the load current of the motor controller contributes significantly to the power consumption at this frequency. Based on the frequency components and their corresponding power consumption amplitudes in the spectrum, the load power consumption frequency domain feature data is extracted. The spectral entropy of the load power consumption frequency domain feature data is calculated; spectral entropy reflects the complexity of the frequency domain signal. Taking the load power consumption frequency domain feature data of a vehicle high-voltage motor controller as an example, the spectral entropy value is calculated using the spectral entropy calculation formula based on the frequency components and their corresponding power consumption amplitudes in the spectrum. The load power consumption frequency domain feature data is then weighted according to the spectral entropy value, and combined with the previously calculated temperature power consumption correction factor. For example, assuming the spectral entropy value is 0.8 and the temperature power consumption correction factor is 0.9025, these parameters are integrated using a preset weighted integration formula, such as Compensated Battery Power Consumption Feature Vector = Load Power Consumption Frequency Domain Feature Data × Spectral Entropy Value × Temperature Power Consumption Correction Factor. After calculation, the compensated battery power consumption feature vector is obtained, which can more accurately reflect the battery's power consumption characteristics under the current operating conditions.

[0017] Preferably, step S15 includes the following steps: Step S151: Perform time-domain waveform decomposition on the steady-state load current signal data to obtain the vehicle battery current waveform characteristic data; Step S152: Obtain the positive electrode material type parameters, negative electrode material type parameters, and electrolyte ionic conductivity attenuation coefficient of the vehicle battery; Step S153: Obtain vehicle battery calendar life data and vehicle deep discharge cycle count, and quantify historical degradation based on vehicle battery calendar life data and vehicle deep discharge cycle count using a preset aging accumulation model to obtain historical capacity degradation factor. Step S154: Based on the vehicle battery current waveform characteristic data, the positive electrode material type parameters of the vehicle battery, the negative electrode material type parameters of the vehicle battery, and the electrolyte ion conductivity decay coefficient, the active lithium ion loss is evaluated using a preset electrochemical degradation equation to obtain the electrochemical capacity decay characteristic value. Step S155: Obtain the temperature gradient distribution data of individual battery cells; perform temperature compensation on the electrochemical capacity decay characteristic value based on the temperature gradient distribution data of individual battery cells to obtain the temperature-calibrated electrochemical decay amount. Step S156: Perform a weighted fusion calculation based on the temperature-calibrated electrochemical decay amount and the historical capacity decay factor to obtain the battery capacity fusion decay coefficient; unify the dimensions of the battery capacity fusion decay coefficient to obtain the vehicle battery capacity decay coefficient.

[0018] In this embodiment, the wavelet transform toolbox in MATLAB software is used to perform time-domain waveform decomposition on the steady-state load current signal. For example, during vehicle operation, the steady-state load current signal collected by the battery management system is 100A. This signal is imported into MATLAB, and the Daubechies wavelet (db4) is selected as the mother wavelet for multi-scale decomposition. By setting the decomposition level to 3, the low-frequency components (DC components) and high-frequency components (AC components) in the signal can be separated. The low-frequency components reflect the baseline level of the battery current, while the high-frequency components reveal the transient fluctuation characteristics of the current. After decomposition, the low-frequency component is extracted to be 98A, and the maximum value of the high-frequency component is 2A. These characteristic data are recorded as vehicle battery current waveform characteristic data. The relevant material parameters of the vehicle battery are obtained through the vehicle's battery management system (BMS). Taking new energy vehicles as an example, their batteries use lithium iron phosphate (LFP) as the positive electrode material and graphite as the negative electrode material. The positive electrode material type parameter is read as "LFP" and the negative electrode material type parameter is "Graphite" from the BMS. The electrolyte ionic conductivity decay coefficient is measured using battery aging test equipment. Electrochemical impedance spectroscopy (EIS) tests were performed on the battery at different aging stages, revealing that the electrolyte ionic conductivity decreased from an initial 10 S / cm to 8 S / cm, with a calculated electrolyte ionic conductivity decay coefficient of 0.2 S / cm. These parameters were recorded in the vehicle's BMS database. Battery calendar life data and deep discharge cycle count were obtained from the vehicle's BMS. For example, a vehicle's battery had been used for 3 years, accumulating 200 deep discharge cycles. A pre-defined aging accumulation model based on the Arrhenius equation and the deep discharge cycle decay formula was used. By substituting the calendar life data (3 years) and deep discharge cycle count (200 cycles) into the model, the historical capacity decay factor was calculated. Assuming the model calculation showed a 5% capacity decay due to calendar life and a 3% decay due to deep discharge cycles, the overall historical capacity decay factor was 0.08 (i.e., 8%). This factor reflects the cumulative capacity loss of the battery over its historical usage. Taking lithium iron phosphate (LFP) batteries as an example, based on battery current waveform characteristics (98A low-frequency component, 2A high-frequency component), cathode material type (LFP), anode material type (Graphite), and electrolyte ionic conductivity decay coefficient (0.2S / cm), a preset electrochemical degradation equation was substituted. This equation considers the influence of material properties on lithium-ion diffusion and intercalation / deintercalation processes. Calculations showed that the loss of active lithium ions is 5% of the battery's initial capacity. Therefore, the electrochemical capacity decay characteristic value was determined to be 0.05, representing the proportion of capacity loss due to electrochemical degradation. Infrared thermal imaging was used to measure the temperature of individual battery cells, obtaining temperature gradient distribution data.For example, during vehicle operation, the temperature at the center of a battery cell is 30°C, and the temperature at the edge is 25°C, forming a temperature gradient. Based on the battery's temperature gradient distribution data and combined with the battery's temperature characteristic curve, temperature compensation is applied to the electrochemical capacity decay characteristic value. Assuming the battery's temperature characteristic curve indicates that for every 1°C decrease, the battery capacity decay characteristic value increases by 0.001, the temperature compensation value is calculated to be 0.005 based on the temperature difference between the center and edge (5°C). This compensation value is added to the electrochemical capacity decay characteristic value (0.05), resulting in a temperature-calibrated electrochemical decay amount of 0.055. The temperature-calibrated electrochemical decay amount (0.055) is then weighted and fused with the historical capacity decay factor (0.08). Based on a preset weight allocation, assuming the weight of the electrochemical decay amount is 0.6 and the weight of the historical decay factor is 0.4, the weighted calculation yields a battery capacity fusion decay coefficient of 0.067. This coefficient is then normalized to the battery's initial capacity (assumed to be 100Ah). Ultimately, the vehicle battery capacity degradation factor was determined to be 0.067, indicating that the battery's current total capacity degradation rate is 6.7%.

[0019] Preferably, step S1, which involves predicting the vehicle's sleep cycle and scheduling power consumption based on the compensated battery power consumption feature vector, includes the following steps: Step S181: Perform time-series alignment of the feature vectors based on the compensated battery power consumption feature vectors to obtain the time-series temperature compensated power consumption feature tensor; Step S182: Based on the preset LSTM network architecture, perform sequence modeling on the time-series temperature compensation power consumption feature tensor to obtain the vehicle power consumption time-series state prediction model. Step S183: Predict the future sleep cycle of the vehicle using the vehicle power consumption timing state prediction model to obtain sleep cycle prediction sequence data; Step S184: Perform sleep mode statistics on the sleep cycle prediction sequence data to obtain sleep mode statistical feature data; calculate the available transmission time window based on the sleep mode statistical feature data to obtain available transmission window time series data; Step S185: Obtain vehicle static configuration parameters and construct a set of vehicle power consumption constraints based on the vehicle static configuration parameters; Step S186: Optimize window scheduling based on available transmission window timing data and vehicle power consumption constraint set to obtain vehicle communication window scheduling table; Step S187: Construct the power consumption communication window mapping relationship based on the vehicle communication window scheduling table to obtain the sleep cycle transmission scheduling benchmark.

[0020] In this embodiment, the NumPy library in the Python programming language is used to process the compensated battery power consumption feature vector. Assume the compensated battery power consumption feature vector is a power consumption data sequence containing multiple time points, such as [1.2, 1.5, 1.8, 2.0, 1.9] (in watts). First, a time reference is determined, for example, the vehicle startup time is taken as zero. Using NumPy's array manipulation capabilities, each data point in the feature vector is aligned according to its timestamp, ensuring that the time order of each power consumption data point is consistent with the actual vehicle running time. For example, if the timestamps are [0, 1, 2, 3, 4] (in seconds), then the time-series temperature compensated power consumption feature tensor [[0, 1.2], [1, 1.5], [2, 1.8], [3, 2.0], [4, 1.9]] is obtained through NumPy's array concatenation function. The time-series temperature compensated power consumption feature tensor is then used to construct a vehicle power consumption time-series state prediction model. The time-series temperature compensated power consumption feature tensor is input into the LSTM network. The LSTM network architecture consists of an input layer, an LSTM layer (containing 10 neurons), and an output layer. The network structure is defined using the TensorFlow API, and hyperparameters are set, such as a learning rate of 0.001 and 100 training epochs. Historical power consumption data of the vehicle is used as the training set to train the LSTM network. After training, the resulting LSTM model can predict the vehicle's power consumption state at future points in time based on the input power consumption feature tensor. For example, given the current power consumption features, the model can predict the power consumption trend over the next 10 seconds. The trained LSTM model is then used to predict the vehicle's future sleep cycles. Assuming the vehicle's current power consumption is 1.8 watts, this state is input into the LSTM model. The model calculates the predicted power consumption values ​​for several future time points based on the trained weights and bias parameters. For example, the model predicts power consumption of [1.7, 1.6, 1.5, 1.4, 1.3] watts over the next 5 seconds. Based on the decreasing power consumption trend, it is determined that the vehicle will enter a sleep state within the next 5 seconds. Therefore, the obtained sleep cycle prediction sequence data is [1.7, 1.6, 1.5, 1.4, 1.3], which will be used for subsequent sleep mode statistics and transmission time window calculation. Statistical analysis of the sleep cycle prediction sequence data is performed using the Pandas library in Python. For example, the sleep cycle prediction sequence is [1.7, 1.6, 1.5, 1.4, 1.3]. First, the mean, variance, and other statistical characteristics of the sequence are calculated to obtain the sleep mode statistical characteristics data, for example, a mean of 1.5 watts and a variance of 0.02. Based on these statistical characteristics and combined with the vehicle's historical sleep modes, the available transmission time window is determined. It is assumed that data transmission can proceed when the vehicle's power consumption is below 1.6 watts before sleep mode begins.Using Pandas' filtering function, time points with power consumption below 1.6 watts are selected from the sleep cycle prediction sequence, resulting in available transmission window time series data [1,2,3,4] (in seconds), indicating that data transmission is possible between the 1st and 4th second. Static configuration parameters are obtained from the vehicle's configuration file, such as the maximum allowable power consumption of 2 watts and the minimum sleep power consumption of 1 watt. These parameters reflect the power consumption limitations of the vehicle under different operating modes. A set of vehicle power consumption constraints is constructed using these parameters. For example, the power consumption constraint set can be expressed as: power consumption must be between 1 watt and 2 watts. A linear programming method is used to optimize the scheduling of the available transmission window time series data. Taking the available transmission window time series data [1,2,3,4] and the power consumption constraint set (power consumption between 1 watt and 2 watts) as an example, an optimization objective is defined using a linear programming tool (such as Python's PuLP library). The objective is to maximize data transmission time while satisfying power consumption constraints. Using the available transmission window time series data as decision variables and the power consumption constraint set as constraints, the optimal transmission time window is calculated using a linear programming solver. For example, optimization results show that transmitting data between the 1st and 3rd second maximizes transmission time while satisfying power consumption constraints. The final vehicle communication window schedule table shows that data transmission can occur between the 1st and 3rd second. Based on the vehicle communication window schedule table, a power consumption communication window mapping relationship is constructed using a dictionary data structure in Python. For example, since the communication window schedule table shows that data transmission can occur between the 1st and 3rd second, the power consumption values ​​during this period (e.g., [1.5, 1.4, 1.3] watts) are mapped to the corresponding transmission time points to obtain the power consumption communication window mapping relationship. For example, the mapping relationship can be represented as {1:1.5, 2:1.4, 3:1.3}, indicating that the power consumption is 1.5 watts in the 1st second, 1.4 watts in the 2nd second, and 1.3 watts in the 3rd second.

[0021] Preferably, step S2 includes the following steps: Step S21: Obtain the original software upgrade package; perform integrity verification on the original software upgrade package to obtain the verified upgrade package data; Step S22: Parse the file format of the verified upgrade package data to obtain the upgrade package structure description data; identify code segment dependencies based on the upgrade package structure description data to obtain the upgrade package code dependency graph; Step S23: Deconstruct the control flow graph structure based on the upgrade package code dependency graph to obtain the upgrade package control flow graph; Step S24: Based on the upgrade package control flow graph and upgrade package structure description data, perform data flow dependency tracking to obtain the upgrade package data flow dependency graph; Step S25: Identify functional module boundaries based on the upgrade package data flow dependency graph to obtain upgrade package functional module partitioning data; Step S26: Extract the interface contract relationship between modules from the functional module partitioning data of the upgrade package to obtain the interface dependency data of the upgrade package modules; Step S27: Construct a directed acyclic graph based on the interface dependency data of the upgrade package module to obtain the functional unit dependency graph; Step S28: Fragment the original software upgrade package according to the hibernation cycle transmission scheduling benchmark and functional unit dependency graph to obtain fragmented upgrade packages.

[0022] In this embodiment, the original software upgrade package is downloaded from the vehicle's remote server. This upgrade package is stored as a compressed file, for example, a file named "controller_upgrade_v1.2.zip". The integrity of the upgrade package is verified using the SHA-256 hash algorithm. Specifically, the Python hashlib library is used to read the contents of the downloaded upgrade package file and calculate its SHA-256 hash value. The server also provides the expected hash value for the upgrade package. The calculated hash value is compared with the hash value provided by the server. If they match, the upgrade package is complete and error-free, and the verified upgrade package data is obtained; if the hash values ​​do not match, the upgrade package needs to be downloaded again. The open-source file parsing tool pyunpack is used to parse the format of the verified software upgrade package. For example, after decompression, the upgrade package contains three folders: bin, lib, and config, which respectively contain executable files, library files, and configuration files. The pyan tool is used to perform dependency analysis on the decompressed code files. pyan can analyze the module dependencies of Python code and generate a dependency graph. Inputting the path to the decompressed code file into `pyan` will allow the tool to scan the code for import statements and other dependencies, identifying the relationships between code segments and displaying them graphically as a dependency graph of the upgrade package. For example, `main.py` depends on `lib / utils.py` and `lib / config.py`, which are clearly shown in the graph. The `pycallgraph` tool is then used to perform control flow analysis on the upgrade package code. This tool can trace the execution path of the code and generate a control flow graph. Specifically, the main program entry file in the upgrade package (such as `main.py`) is used as the starting point, and `pycallgraph` is run. The tool will trace function calls and execution order during program execution, generating a control flow graph. For example, during program execution, the `main()` function calls functions such as `init()`, `process_data()`, and `shutdown()`. These function call relationships are represented in the control flow graph as nodes and directed edges. Each node represents a function, and the directed edge indicates the direction of the function call. Through the above operations, the control flow graph of the upgrade package is obtained, clearly showing the code execution flow and the call relationships between various functions. The pyan tool is used to trace data flow dependencies by combining control flow graphs and upgrade package structure descriptions. pyan can not only analyze code dependencies but also trace the flow of data. For example, in the control flow graph, the `process_data()` function calls the `calculate()` function in `lib / utils.py` and passes the calculation result to the `main()` function. pyan analyzes these data propagation paths to generate a data flow dependency graph.In the diagram, the flow of data is indicated by arrows, clearly showing the entire process from data generation to use. For example, data generated by the `process_data()` function is processed by the `calculate()` function and then flows to the `main()` function. These dependencies are recorded in detail in the data flow dependency graph. The `pyreverse` tool is used to partition the upgrade package code into modules. By inputting the upgrade package's code path into `pyreverse`, the tool identifies the boundaries of functional modules based on the code's package structure, class definitions, and function call relationships. For example, `pyreverse` analysis reveals that `lib / utils.py` and `lib / config.py` belong to the same functional module, while `bin / main.py` and `bin / process.py` belong to another functional module. Based on these analysis results, the code is divided into different functional modules, and the file and function composition of each module is recorded, resulting in the upgrade package's functional module partitioning data. The `pylint` tool is used to extract interface contract relationships from the upgrade package's functional module partitioning data. Through `pylint`'s plugin functionality, its analytical capabilities are extended to enable it to identify interface contract relationships between modules. For example, the `lib / utils.py` module provides a `calculate()` function interface, which the `bin / main.py` module uses by importing `lib / utils.py`. The `pylint` tool checks whether the definition and use of this interface conform to the contract, such as whether the parameter types and return value types are consistent. Based on the analysis results of `pylint`, the interface contract relationships between modules are extracted and recorded as interface dependency data for the upgrade package modules. A directed acyclic graph (DAG) is constructed using the `networkx` library for the interface dependency data of the upgrade package modules. The interface dependencies between modules are used as edges, and the modules are used as nodes, and input into `networkx`. For example, if `bin / main.py` depends on `lib / utils.py`, a directed edge from `bin / main.py` to `lib / utils.py` is added to the graph. Through the above operations, a directed acyclic graph is constructed, clearly showing the dependencies between functional modules. For detailed implementation of step S28, please refer to the sub-steps of step S28.

[0023] Of particular importance, step S28 also includes the following steps: Step S281: Identify the smallest functional units in the functional unit dependency graph of the upgrade package to obtain the set of atomic functional units of the upgrade package; Step S282: Determine the data molecule boundaries based on the set of atomic functional units in the upgrade package to obtain a candidate set of data molecules for the upgrade package; Step S283: Design an integrity verification mechanism for the candidate set of upgrade package data molecules to obtain the set of upgrade package data molecules with verification. Step S284: Calculate the molecular transmission priority based on the sleep cycle transmission scheduling benchmark to obtain the molecular priority weight of the upgrade package; Step S285: Extract the constraints from the sleep cycle transmission scheduling benchmark to obtain the transmission window constraint set; Step S286: Calculate the fragment size based on the priority weight of the upgrade packet molecule and the set of transmission window constraints to obtain the upgrade packet fragmentation parameters; Step S287: Fragment the set of checksum data molecules in the upgrade package according to the upgrade package fragmentation parameters to obtain the intelligent fragmented upgrade package.

[0024] In this embodiment, the networkx library is used to analyze the dependency graph of the upgrade package's functional units to identify the smallest functional units. Assume the dependency graph contains multiple modules, for example, the main module depends on the utils module, and the utils module depends on the config module. Using networkx's topology sorting function, the smallest functional units in the graph are identified—those that do not depend on other modules. For example, the config module is an atomic functional unit because it does not depend on other modules. Through the above operations, a set of atomic functional units in the upgrade package is obtained, such as {config, logger}, which are the smallest indivisible functional modules in the upgrade package. The pyan tool is used to perform static analysis on the upgrade package's code to determine the boundaries of data molecules. A data molecule refers to a code segment containing a set of related functions that are functionally relatively independent. For example, the load_config() and save_config() functions in the config module can be considered a data molecule because they jointly manage the loading and saving of configuration files. By analyzing the code's call relationships and data flow using pyan, the boundaries of these data molecules are identified, and they are recorded as a candidate set of upgrade package data molecules. For example, the candidate set includes {config_manager, logger_handler}, etc., and each candidate data molecule contains a set of related functions or classes. The hashlib library is used to generate a hash value for each data molecule. For example, for the config_manager data molecule, the SHA-256 hash value of its code file is calculated, and the hash value is embedded in the data molecule's metadata. In this way, each data molecule carries a checksum for verification of its integrity at the receiving end. Each data molecule in the upgrade package data molecule candidate set is processed through the above operations to obtain the upgrade package data molecule set with checksum. For example, each data molecule in the set contains code content and a corresponding hash value. Based on the vehicle's sleep cycle transmission scheduling baseline, the pandas library in Python is used to calculate the priority of the upgrade package data molecules. Assuming the sleep cycle transmission scheduling baseline indicates that the vehicle has a 10-second transmission window each time it wakes up, priority weights are assigned based on the size and functional importance of the data molecules. For example, the `config_manager` data molecule is smaller but functionally critical, so it is assigned a higher priority weight (e.g., 0.8); while the `logger_handler` data molecule is larger but functionally less important, so it is assigned a lower priority weight (e.g., 0.4). Through the above operations, the priority weights of the upgrade package molecule are obtained. Constraints are extracted from the vehicle's sleep cycle transmission scheduling benchmark, and these conditions are organized and analyzed using the pandas library. For example, the sleep cycle transmission scheduling benchmark indicates that the transmission window for each vehicle wake-up is 10 seconds, and the maximum data transmission size is 1MB.These conditions are extracted to form a transmission window constraint set, such as {max_time:10, max_size:1MB}. These constraints will be used for subsequent fragment size calculations, ensuring that the transmission time of each fragment does not exceed 10 seconds and the data size does not exceed 1MB. The fragment size of the upgrade package's checksum data set is calculated using Python's NumPy library. Based on the priority weight of the data element and the transmission window constraint set, the fragment size of each data element is calculated. For example, the priority weight of the `config_manager` data element is 0.8, and its size is 500KB, which is less than the maximum data size of the transmission window (1MB), so it can be transmitted as an independent fragment. However, the priority weight of the `logger_handler` data element is 0.4, and its size is 2MB, which exceeds the maximum data size of the transmission window, so it needs to be split into two fragments, each 1MB in size. Through the above operations, the upgrade package fragmentation parameters are obtained, including the size of each fragment and its corresponding priority weight. Based on the upgrade package fragmentation parameters, the `pyunpack` library is used to fragment the upgrade package's checksum data set. For example, the `config_manager` data element is treated as a separate shard, with its hash value and metadata preserved; while the `logger_handler` data element is split into two shards, each containing its corresponding hash value and metadata. These shards are then repackaged into a smart sharding upgrade package.

[0025] Preferably, step S3 includes the following steps: Step S31: Extract sharding metadata from the sharding upgrade package to obtain a smart sharding metadata set; Step S32: Construct the hash chain topology based on the intelligent sharding metadata set to obtain the initial hash chain state data; Step S33: Establish an incremental verification benchmark based on the initial hash chain state data to obtain the hash chain incremental verification benchmark; Step S34: Real-time data fragment capture is performed on the vehicle's network transmission channel to obtain real-time received data fragment segments; real-time hash calculation is performed on the real-time received data fragment segments to obtain the received fragment real-time hash data. Step S35: Perform integrity verification on the received fragment real-time hash data based on the hash chain incremental verification benchmark to obtain the fragment integrity verification result; Step S36: Filter verified molecules based on the fragment integrity verification results to obtain a set of verified molecule caches; Step S37: Perform transmission recovery scheduling on the verified molecular buffer set through the breakpoint resume scheduler to obtain fragment transmission recovery status data.

[0026] In this embodiment, Python's `json` module is used to process the shard upgrade packages. Each shard upgrade package contains a `metadata.json` file, recording metadata information such as shard size, hash value, and priority. These metadata files are read using the `json.load()` function to extract key information. The `hashlib` and `networkx` libraries are used to construct a hash chain topology. Based on the hash values ​​in the smart shard metadata set, the `hashlib.sha256()` function is used to verify whether the hash value of each shard is consistent with the metadata. A directed graph is created using the `networkx` library, with the hash value of each shard as a node, and directed edges are added based on the dependencies between shards (such as the `dependency` field). For example, if shard A depends on shard B, an edge from B to A is added to the graph. Through these operations, a hash chain topology graph is constructed, obtaining the initial hash chain state data. For example, the initial state data is represented as a graph structure containing nodes `abc123` and `def456`, and the dependencies between them. The `hashlib` library is used to establish an incremental verification benchmark for the initial hash chain state data. Assuming a hash chain topology has multiple nodes, starting from the root node (a node without dependencies), the hash value of each node is calculated sequentially and compared with the hash value in the metadata. If the hash value of a node changes, the hash values ​​of its dependent nodes need to be recalculated. For example, the hash value of the root node is abc123, and the hash value of its dependent nodes is def456. First, verify that the hash value of the root node is consistent with the metadata, then calculate the hash values ​​of the dependent nodes and compare them with the values ​​in the metadata. Through the above operations, an incremental verification benchmark for the hash chain is established. Real-time data fragments are captured using the vehicle's network transmission module (such as a 4G / 5G module). Assuming the vehicle's network module supports packet capture, it receives data in real time through the vehicle's communication interface (such as a CAN bus or Ethernet interface). For example, when the vehicle receives an upgrade package, the network module captures a data fragment of 512 bytes. The hashlib.sha256() function is used to perform real-time hash calculation on the captured data fragment to obtain the real-time hash data of the received fragment. For example, the calculated hash value is xyz789, which will be used for subsequent integrity verification. The integrity of the received fragment's real-time hash data is verified using a hash chain incremental verification benchmark. Assuming the received fragment's real-time hash value is xyz789, it is compared to the hash value in the hash chain incremental verification benchmark. If they match, the received fragment is intact; if they don't match, the fragment needs to be received again. For example, if the received fragment's hash value does not match the benchmark, it indicates that the fragment has been tampered with or corrupted during transmission.The above operations yield the integrity verification result of the fragment, for example, {"status":"failed","reason":"hashmismatch"}. Based on the fragment integrity verification result, the verified molecules are filtered. Assuming the integrity verification result shows that a fragment was successfully verified, it is stored in the verified molecule cache set. For example, the verified molecule cache set may contain multiple successfully verified fragments, such as: [{"hash":"abc123","size":512},{"hash":"def456","size":1024}]. For detailed implementation procedures of step S37, please refer to the sub-steps of step S37.

[0027] Of particular importance, step S37 also includes the following steps: Step S371: Perform dependency topology orchestration on the validated data molecule cache set to obtain fusionable molecular dependency sequence data; Step S372: Perform progressive fusion on the fusionable molecule-dependent sequence data to obtain progressive fusion upgrade package fragments; create state snapshots on the progressive fusion upgrade package fragments to obtain upgrade package fusion state snapshot data; Step S373: Construct a breakpoint recovery mapping mechanism based on the upgrade package fusion status snapshot data to obtain a breakpoint recovery mapping table; Step S374: Obtain the sleep / wake-up status signal of the communication controller; perform a status query on the breakpoint recovery mapping table based on the sleep / wake-up status signal to obtain the sleep interrupt location; Step S375: Locate the transmission recovery point based on the hibernation interruption location to obtain the transmission breakpoint recovery location; reconstruct the transmission task queue based on the transmission breakpoint recovery location to obtain the upgrade package recovery transmission scheduling data; Step S376: Perform dynamic balancing of transmission efficiency on the upgrade package recovery transmission scheduling data to obtain the upgrade package balanced recovery scheduling scheme; Step S377: Perform breakpoint resume operation according to the upgrade package balanced recovery scheduling scheme to obtain fragmented transmission recovery status data.

[0028] In this embodiment, the networkx library is used to perform dependency topology orchestration on a verified data molecule cache set. Assume the cache set contains multiple verified fragments, each with corresponding dependencies. For example, fragment A depends on fragment B, and fragment B depends on fragment C. A directed graph is constructed based on these dependencies, with each fragment as a node and dependencies as directed edges. The graph is sorted using networkx's topology sorting function to obtain a linear dependency sequence. For example, a sorted result of [C, B, A] indicates that fragment C is fused first, then fragment B, and finally fragment A. The shutil module in Python is used to progressively fuse the fused molecular dependency sequence data. Assuming the dependency sequence is [C, B, A], the contents of fragment C are first copied to a temporary directory, and then the contents of fragments B and A are merged into this directory sequentially. After each merge, the hash value of the current fused fragment is calculated using the hashlib library and recorded in a state snapshot file. For example, after merging shard C, the hash value is hashC; after merging shard B, the hash value is hashB; and finally, after merging shard A, the hash value is hashA. The state snapshot file records the hash value and merging status for each stage. A breakpoint recovery mapping mechanism is built using Python's sqlite3 module. Assuming the state snapshot file records the hash value and status information for each merging stage, this information is stored in an SQLite database, creating a breakpoint recovery mapping table. The table contains fields such as hash_value, stage, and timestamp, recording the hash value, merging stage, and timestamp, respectively. For example, a record in the table might be hashC,stage1,2024-05-31 10:00:00, representing the hash value and time during the first stage of merging shard C. This mapping table will be used to quickly locate the recovery point in case of transmission interruption. The sleep / wake-up status signal of the communication controller is obtained through the vehicle's CAN bus interface. Assuming the vehicle's communication controller is woken up after sleep mode, the socket library is used to listen for signals on the CAN bus. When a wake-up signal is detected, the breakpoint recovery mapping table is queried to find the last successful merging status. For example, the query result shows that the last successful fusion state is hashB, indicating that a hibernation interruption occurred during the fusion of shard B. This hibernation interruption location will be used to determine the recovery point. The transmission recovery point is located based on the hibernation interruption location (e.g., hashB). Assuming that fusion of shard B is the last successful state, detailed information about this state is obtained from the breakpoint recovery mapping table, including merged and unmerged shards. The transmission task queue is reconstructed, adding unmerged shards (e.g., shard A) back into the queue. For example, the reconstructed transmission task queue is [A], indicating that transmission continues from shard A. The upgrade package recovery transmission scheduling data is dynamically balanced for transmission efficiency using Python's numpy library.Assuming the reconstructed transmission task queue is [A], transmission parameters are dynamically adjusted based on the size of fragment A and the vehicle's current network status (such as bandwidth and latency). For example, if fragment A is 1MB in size and the current network bandwidth is 100KB / s, the calculated transmission time is 10 seconds. Transmission tasks are adjusted according to the vehicle's sleep cycle (e.g., waking up every 15 seconds) to ensure transmission is completed before the vehicle's next sleep cycle. The final balanced recovery scheduling scheme includes the transmission time, priority, and network parameters of fragment A. Breakpoint resumption is performed according to the upgrade package's balanced recovery scheduling scheme. Assuming the scheduling scheme indicates transmission starting from fragment A, the vehicle's network module (e.g., a 4G / 5G module) is used to restart the transmission of fragment A. During transmission, the transmission status is monitored in real time, and the transmission progress and hash value of fragment A are recorded. For example, after successful transmission of fragment A, its hash value is calculated as hashA and recorded in the status file. The final fragment transmission recovery status data includes the successful transmission status and hash value of fragment A.

[0029] Preferably, step S4, which involves obtaining the vehicle communication unit hardware configuration through the vehicle OBD-II diagnostic interface and identifying redundant paths, includes the following steps: Step S41: Obtain the hardware configuration of the vehicle communication unit through the vehicle OBD-II diagnostic interface; evaluate the communication capability of the communication unit hardware configuration to obtain the vehicle communication capability benchmark; Step S42: Initialize the multi-path communication channel based on the vehicle communication capability benchmark to obtain the initial state data of the vehicle communication channel; deploy a real-time monitoring mechanism for the initial state data of the vehicle communication channel to obtain the vehicle channel monitoring framework data; Step S43: Collect communication quality parameters through the vehicle-mounted channel monitoring frame data to obtain real-time multi-channel communication quality data; Step S44: Based on real-time multi-channel communication quality data, perform channel quality scoring to obtain a multi-path channel quality scoring table; Step S45: Perform redundant path topology modeling based on the multi-path channel quality scoring table to obtain the redundant communication path table; Step S46: Extract the current transmission task information based on the fragmented transmission recovery status data to obtain the upgrade packet transmission task queue.

[0030] In this embodiment, the hardware configuration of the vehicle's communication unit is read using a diagnostic tool (such as IntelliScan) through the vehicle's diagnostic interface (such as OBD-II). This data includes parameters such as the communication module model, supported frequency bands, and maximum transmission rate. For example, the vehicle's communication unit supports 4G and 5G networks, with a maximum downlink rate of 1Gbps and an uplink rate of 100Mbps. Based on this hardware configuration, combined with industry standards and empirical values, the communication capability is evaluated. For example, based on the communication unit's downlink rate and stability, its communication capability benchmark is rated as "high." A suitable multipath communication protocol (such as MPTCP—Multipath Transmission Control Protocol) is selected based on the communication capability benchmark (e.g., "high"). The multipath communication channel is initialized using the vehicle's communication module, for example, by simultaneously enabling 4G and 5G network paths. After initialization, a real-time monitoring mechanism is deployed, and a network monitoring tool (such as Wireshark) is used to capture the initial state data of the communication channel, including parameters such as channel quality, signal strength, and packet loss rate. For example, the initial channel quality of the 4G path is 70%, the signal strength is -70dBm, and the packet loss rate is 1%; the channel quality of the 5G path is 85%, the signal strength is -60dBm, and the packet loss rate is 0.5%. Using a pre-deployed monitoring framework, communication quality parameters are continuously collected. For example, channel quality, signal strength, packet loss rate, and transmission latency are collected every 5 seconds. Real-time data capture using Wireshark's real-time data capture function is used to record real-time data for each communication path. For example, at a certain moment, the channel quality of the 4G path drops to 60%, the signal strength is -80dBm, the packet loss rate rises to 3%, and the latency is 100ms; the channel quality of the 5G path is 80%, the signal strength is -65dBm, the packet loss rate is 1%, and the latency is 30ms. Based on the real-time multi-channel communication quality data, each communication path is scored using a preset scoring standard. For example, channel quality accounts for 40 points, signal strength for 30 points, packet loss rate for 20 points, and latency for 10 points. Based on these weights, a comprehensive score is calculated for each path. For example, the overall score for the 4G path is 65 (channel quality 24, signal strength 9, packet loss rate 4, latency 8); the overall score for the 5G path is 82 (channel quality 32, signal strength 18, packet loss rate 6, latency 6). Based on the multi-path channel quality scoring table, the path with higher quality is selected as the primary path, and the other paths are designated as redundant paths. For example, the 5G path, with a score of 82, is selected as the primary path; the 4G path, with a score of 65, is selected as the redundant path. A network topology modeling tool (such as GNS3) is used to construct a redundant path topology model, recording information such as the connection method and switching mechanism of the primary and redundant paths. For example, the model is set to automatically switch to the redundant path when the channel quality of the primary path drops below 70. The final redundant communication path table records the configuration information of the primary and redundant paths in detail.Based on the fragmented transmission recovery status data, a Python script is used to extract information about the current transmission tasks. For example, the script reads the successfully transmitted fragment numbers, sizes, and hash values, as well as information about untransmitted fragments, from the status data. Assume fragments 1 and 2 have been successfully transmitted, and fragments 3, 4, and 5 are untransmitted. The information about the untransmitted fragments is extracted to form a queue of upgrade package transmission tasks. For example, the task queue might be represented as: [{"id":3,"size":512},{"id":4,"size":1024},{"id":5,"size":768}], where each task contains a fragment number and size. For detailed implementation of step S47, please refer to the sub-steps of step S47.

[0031] Preferably, step S4, which ensures continuous transmission based on the redundant communication path table and fragmented transmission recovery status data, includes the following steps: Step S471: Allocate tasks according to the redundant communication path table and the upgrade package transmission task queue to obtain the initial transmission task allocation scheme; Step S472: Dynamically adjust the initial transmission task allocation scheme to obtain an adjusted transmission task allocation scheme; Step S473: Perform multi-path parallel transmission based on the adjusted transmission task allocation scheme to obtain multi-path parallel transmission status data; perform anomaly detection on the multi-path parallel transmission status data to obtain multi-path channel anomaly status data. Step S474: Predict the sleep trigger time based on the sleep cycle transmission scheduling benchmark to obtain the controller sleep warning time; Step S475: Based on the controller sleep warning time and multi-path channel abnormal status data, preheat the backup channel to obtain backup channel ready status data; Step S476: Based on the standby channel readiness status data, seamlessly switch the primary and standby channels using a preset hot-switching strategy to obtain channel switching execution data; Step S477: Perform transmission continuity assurance maintenance based on channel switching execution data to obtain upgrade package continuous transmission assurance data.

[0032] In this embodiment, a Python script is used to allocate tasks based on a redundant communication path table and an upgrade package transmission task queue. Assume the redundant communication path table defines two paths: the primary path (5G) and the redundant path (4G). The upgrade package transmission task queue contains three fragments: fragment 3 (512KB), fragment 4 (1024KB), and fragment 5 (768KB). Tasks are allocated to different paths based on the path's communication capacity and fragment size. For example, the primary path (5G) is allocated the larger fragment 4 (1024KB), while the redundant path (4G) is allocated the smaller fragments 3 (512KB) and 5 (768KB). The initial transmission task allocation scheme is as follows: the primary path transmits fragment 4, and the redundant path transmits fragments 3 and 5. A real-time monitoring tool (such as Wireshark) is used to continuously monitor the real-time status of the communication paths. Assume that during transmission, the channel quality of the primary path (5G) degrades, and the packet loss rate increases to 5%. Based on a preset dynamic adjustment strategy, a Python script is used to reallocate tasks. For example, a portion of data from fragment 4 (e.g., 512KB) is switched from the main path to the redundant path (4G) to reduce the load on the main path. The adjusted transmission task allocation scheme is as follows: the main path transmits the remaining portion of fragment 4 (512KB), and the redundant path transmits fragments 3, 5, and a portion of fragment 4 (512KB). Based on the adjusted transmission task allocation scheme, the vehicle's communication module (e.g., a 4G / 5G module) performs multi-path parallel transmission. For example, the main path (5G) continues to transmit the remaining portion of fragment 4 (512KB), while the redundant path (4G) simultaneously transmits fragments 3, 5, and a portion of fragment 4 (512KB). Multi-path parallel transmission status data, including transmission rate, packet loss rate, and latency, is collected in real time using network monitoring tools (e.g., Wireshark). For example, the main path has a transmission rate of 800KB / s, a packet loss rate of 2%, and a latency of 40ms; the redundant path has a transmission rate of 300KB / s, a packet loss rate of 3%, and a latency of 80ms. Anomaly detection algorithms (such as threshold-based detection) are used to analyze these status data. The analysis reveals that the packet loss rate on the main path exceeds a preset threshold (e.g., 2%), indicating an anomaly on the main path. Based on the sleep cycle transmission scheduling baseline, a Python script is used to predict the controller's sleep trigger time. Assuming a sleep cycle of 15 minutes and a wake-up time of 5 minutes, the warning time for the controller's next sleep cycle is calculated based on the current time and the amount of data already transmitted. For example, if the current time is 10:00, the amount of data already transmitted is 1024KB, and the current transmission task is expected to be completed at 10:10, the controller is predicted to enter sleep mode at 10:15, therefore the sleep warning time is 10:15. Based on the sleep warning time (10:15) and the multi-path channel anomaly data (main path packet loss rate exceeding the threshold), a Python script is used to initiate the warm-up operation of the backup channel (4G).For example, 5 minutes before the hibernation warning time (10:10), the backup channel is activated via the vehicle's communication module, putting it into a preheating state. The status of the backup channel is monitored in real time using network monitoring tools (such as Wireshark), and its readiness status data is recorded. For example, if the backup channel completes preheating at 10:12, with a channel quality of 80%, a signal strength of -65dBm, a packet loss rate of 1%, and a latency of 30ms, this data indicates that the backup channel is ready and can be switched over at any time. Based on the backup channel's readiness status data, a preset hot-switching strategy (such as a switching strategy based on signal strength and packet loss rate) is used to seamlessly switch between the primary and backup channels. For example, when the backup channel's channel quality reaches 80% and the packet loss rate is below 2%, a channel switching operation is performed via the vehicle's communication module. A Python script is used to record the execution data of the channel switching, including switching time, channel quality before and after the switching, signal strength, packet loss rate, and other parameters. For example, if the switchover time is 10:13, the channel quality of the primary path before the switchover is 60%, and the packet loss rate is 5%; after the switchover, the channel quality of the backup channel is 80%, and the packet loss rate is 1%. These data indicate that the channel switchover was successfully completed. Based on the channel switchover execution data, a Python script is used to ensure and maintain transmission continuity. For example, the transmission status after the switchover is checked to ensure that data transmission is not interrupted. If a decrease in transmission rate is found after the switchover, transmission parameters are adjusted (such as increasing the number of retransmissions) to optimize transmission performance. Data on transmission continuity assurance and maintenance is recorded, including parameters such as transmission rate, packet loss rate, and latency after the switchover. For example, the transmission rate after the switchover is 700KB / s, the packet loss rate is 1%, and the latency is 50ms.

[0033] Preferably, step S5 includes the following steps: Step S51: Verify the integrity of the upgrade package by continuously transmitting the data to ensure its integrity, and obtain the complete software upgrade package; Step S52: Perform system architecture analysis on the complete software upgrade package to obtain the system hierarchy data of the upgrade package; Step S53: Based on the upgrade package system hierarchy data, perform a criticality level assessment to obtain the criticality score of the upgrade package components; Step S54: Divide the system into layers according to the criticality score of the upgrade package components to obtain the three-layer system architecture of the upgrade package, which includes the bootstrap layer components, the core function layer and the application service layer; Step S55: Perform hierarchical upgrade sequence planning on the three-tier system architecture data of the upgrade package to obtain a hierarchical upgrade scheduling scheme for the upgrade package; Step S56: Initialize the upgrade verification environment based on the upgrade package hierarchical upgrade scheduling scheme to obtain the hierarchical verification environment configuration; Step S57: Perform layered progressive flashing verification and fault location on the three-layer system architecture of the upgrade package according to the layered verification environment configuration to obtain fault level location data; Step S58: Perform dynamic firmware image maintenance based on fault level location data to obtain minimum functional firmware image data; construct a fault recovery channel based on the minimum functional firmware image data to obtain remote recovery connection data for the communication controller. Step S59: Remotely restore connection data via the communication controller to execute the fault self-healing process and obtain the controller software upgrade result.

[0034] In this embodiment, the hashlib library is used to verify the integrity of data during continuous transmission of the upgrade package. It is assumed that the upgrade package is divided into multiple fragments during transmission, and each fragment is stored in the vehicle's local storage after transmission. First, the hash value of each fragment is read (these hash values ​​were calculated and recorded before fragment transmission). Then, the hash value of the locally stored fragment data is recalculated using the hashlib.sha256() function. For example, if the original hash value of fragment 1 is abc123, calculating the hash value of the locally stored fragment 1 data also yields abc123, indicating that fragment 1 is complete. This process is repeated for all fragments. After confirming that the hash values ​​of all fragments are consistent with the original values, these fragments are merged into a complete software upgrade package. The pyreverse tool is used to perform system architecture analysis on the complete software upgrade package. The code paths in the upgrade package are input into pyreverse, and the tool scans the package structure, class definitions, and function call relationships in the code to generate system hierarchy data. For example, the upgrade package contains three main modules: bootloader, kernel, and applications. The hierarchical structure data generated by pyreverse analysis shows that the bootloader is located in the boot layer, the kernel in the core functionality layer, and the applications in the application service layer. The pylint tool is used to evaluate the criticality level of the upgrade package's system hierarchy data. Based on the system hierarchy data, a criticality score is assigned to each component. For example, the bootloader module, responsible for the startup process, has a criticality score of 90 (out of 100); the kernel module, responsible for core functionality, also has a score of 90; and the applications module, containing some non-critical user applications, has a score of 70. Based on the component criticality scores, a Python script is used to further divide the system into layers. The script divides components into the boot layer, core functionality layer, and application service layer according to preset scoring thresholds. For example, components with scores higher than 85 are classified as either the boot layer or the core functionality layer, while components with scores lower than 85 are classified as the application service layer. Based on the previous scores, the bootloader and kernel are classified as the core functionality layer, and the applications are classified as the application service layer. The final upgrade package's three-tier system architecture includes a bootloader, a core functionality layer (such as the kernel), and application services (such as applications). Based on the upgrade package's three-tier system architecture data, a Python script is used to plan the hierarchical upgrade sequence. The script generates a layered upgrade scheduling scheme based on the dependencies and criticality of each layer.For example, bootstrap components (such as the bootloader) must be upgraded first because they are crucial for system startup; core functional layers (such as the kernel) are upgraded next because they provide the system's basic functions; and application service layers (such as applications) are upgraded last because they have less impact on system startup and basic functions. Based on these dependencies, a detailed upgrade sequence is generated, for example: upgrade the bootloader first, then the kernel, and finally the applications. According to the hierarchical upgrade scheduling scheme, the upgrade verification environment is initialized using the vehicle's diagnostic tools (such as IntelliScan). For example, for bootstrap components (such as the bootloader), the vehicle's startup mode is configured to "firmware upgrade mode," and the vehicle's power system is ensured to be stable. For core functional layers (such as the kernel), the vehicle's hardware interfaces (such as the CAN bus) are configured to support data transmission. For application service layers (such as applications), the vehicle's user interface is configured to display the upgrade progress. This configuration information is recorded to form the hierarchical verification environment configuration, for example: the bootstrap layer is configured to "firmware upgrade mode, power stable," the core functional layer is configured to "CAN bus interface, data transmission ready," and the application service layer is configured to "user interface display upgrade progress." For detailed implementation of step S57, please refer to the sub-steps of step S57. Based on the fault level location data, perform dynamic firmware image maintenance using the vehicle's firmware maintenance tool (such as U-Boot). For example, if the system fails to boot after a kernel upgrade, decide to revert to the previous firmware version. Use the U-Boot tool to load the old version of the kernel firmware image from the vehicle's backup storage and flash it. Record key information during the maintenance process to form minimal functional firmware image data, for example: the old version kernel's hash value is def456, and its size is 1MB. Use the vehicle's communication module (such as a 4G / 5G module) to build a fault recovery channel, ensuring the vehicle can perform firmware recovery via remote connection. Record the communication module's configuration information to form communication controller remote recovery connection data, for example: the communication module is configured as "4G network, maximum transmission rate is 100Mbps". Based on the communication controller's remote recovery connection data, use the vehicle's communication module (such as a 4G / 5G module) to execute the fault self-healing process. For example, send a recovery command via remote connection; after receiving the command, the vehicle's communication controller automatically starts the firmware recovery process. Monitor the recovery process in real time using vehicle diagnostic tools (such as INTELLIBSCAN) to ensure successful completion. Record key information during the recovery process to generate a controller software upgrade result, such as: recovery operation successful, vehicle communication controller has been restored to normal working state, and all functions are operating normally.

[0035] Of particular importance, step S57 also includes the following steps: Step S571: Perform pre-verification on the bootstrap component according to the layered verification environment configuration to obtain the bootstrap verification result; perform bootstrap flush operation based on the bootstrap verification result to obtain bootstrap flush status data; Step S572: Perform a functional integrity test on the bootstrap layer's write state data to obtain the bootstrap layer's functional test results; Step S573: Perform pre-verification of the core functional layer based on the bootstrap functional test results to obtain the core functional layer verification results; perform core functional layer flashing based on the core functional layer verification results to obtain core functional layer flashing status data. Step S574: Perform key function tests on the core function layer's write status data to obtain the core function layer test results; Step S575: Perform pre-verification of the application service layer based on the core functional layer test results to obtain the application service layer verification results; perform application service layer flashing based on the application service layer verification results to obtain application service layer flashing status data. Step S576: Perform end-to-end system testing on the application service layer's status data to obtain the service layer system integration test results; Step S577: Perform fault detection based on the service layer system integration test results to obtain service layer system fault status data; perform intelligent fault location based on the service layer system fault status data to obtain fault level location data.

[0036] In this embodiment, based on the layered verification environment configuration, vehicle diagnostic tools (such as INTELLIBSCAN) are used to pre-verify the bootloader components. Pre-verification includes checking the hash value and version information of the bootloader components to ensure they match expectations. For example, the hash value of the bootloader component (abc123) is read and compared with the hash value in the upgrade package. After confirming consistency, the bootloader flashing operation is performed. During the flashing process, the flashing progress and status are monitored, and bootloader flashing status data is recorded, such as "bootloader flashing successful, time taken 30 seconds." Vehicle hardware testing tools (such as a hardware-in-the-loop testing system, HIL) are used to perform functional integrity testing on the bootloader components. The test content includes the bootloader component's startup function and hardware initialization function. For example, the vehicle is started, and it is observed whether the bootloader component can correctly guide the system to the next startup stage. If the test result shows that the bootloader function is normal, the bootloader function test result is recorded as "bootloader function test passed, system startup normal." Based on the bootloader function test results, vehicle diagnostic tools are used to pre-verify the core functional layer (such as the kernel). Pre-verification includes checking the dependencies and interface compatibility of the core functional layer. For example, after confirming that the interfaces of the core functional layer and the bootstrap components match, the core functional layer flashing operation is performed. During the flashing process, the flashing progress and status are monitored, and the core functional layer flashing status data is recorded, such as "Core functional layer flashing successful, time taken 1 minute". The vehicle's software testing tools (such as the automated testing framework Selenium) are used to perform critical functional tests on the core functional layer. Test content includes the system stability of the core functional layer and the availability of critical services. For example, a series of test scripts are run to check the system's stability under high load. If the test results show that the core functional layer is running normally, the core functional layer test result is recorded as "Core functional layer test passed, system running stably". Based on the core functional layer test results, the vehicle's diagnostic tools are used to perform pre-verification of the application service layer (such as applications). Pre-verification includes checking the dependencies and data integrity of the application service layer. For example, after confirming that the interfaces of the application service layer and the core functional layer match, the application service layer flashing operation is performed. During the flashing process, monitor the flashing progress and status, and record the application service layer flashing status data, such as "Application service layer flashing successful, time taken 2 minutes". Use vehicle system testing tools (such as the end-to-end testing framework Cypress) to perform end-to-end system testing on the application service layer. The test content includes the user interaction functions and data processing functions of the application service layer. For example, simulate user operations to check whether the application service layer can correctly respond to user requests. If the test results show that the application service layer is running normally, record the service layer system integration test result as "Application service layer integration test passed, user interaction is normal". Based on the service layer system integration test results, use vehicle fault detection tools (such as the OBD-II fault diagnosis system) to perform fault detection.The detection includes abnormal logs and performance metrics during system operation. For example, if a brief response delay is detected in the application service layer under high load, the fault status data is recorded as "response delay, delay time is 500ms". Intelligent fault location tools (such as Fault Tree Analysis (FTA)) are used to analyze the fault, locating the fault level as "application service layer, data processing module".

[0037] Preferably, the present invention also provides a new energy vehicle communication controller software upgrade system for executing the new energy vehicle communication controller software upgrade method described above, the new energy vehicle communication controller software upgrade system comprising: The power consumption prediction module is used to acquire vehicle load current data; perform temperature compensation based on vehicle load current data to obtain a compensated battery power consumption feature vector; and perform sleep cycle prediction and power consumption scheduling for the vehicle based on the compensated battery power consumption feature vector to obtain a sleep cycle transmission scheduling benchmark. The fragmentation management module is used to obtain the original software upgrade package; construct a functional unit dependency graph based on the original software upgrade package; and fragment the original software upgrade package according to the sleep cycle transmission scheduling benchmark and the functional unit dependency graph to obtain fragmented upgrade packages. The verification and recovery module is used to verify the integrity of the fragmented upgrade package and obtain a set of verified molecular caches; the transmission recovery scheduling of the set of verified molecular caches is performed through the breakpoint resume scheduler to obtain fragmented transmission recovery status data. The transmission assurance module is used to obtain the hardware configuration of the vehicle communication unit through the vehicle OBD-II diagnostic interface and perform redundant path identification to obtain a redundant communication path table; based on the redundant communication path table and the fragmented transmission recovery status data, it performs continuous transmission assurance to obtain upgrade package continuous transmission assurance data. The fault handling module is used to locate fault levels based on the continuous transmission of protection data from the upgrade package, and obtain fault level location data; based on the fault level location data, it performs minimum functional firmware maintenance to obtain the controller software upgrade result.

[0038] 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.

[0039] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be 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 upgrading the communication controller software of a new energy vehicle, characterized in that, Includes the following steps: Step S1: Obtain vehicle load current data through the vehicle's built-in current sensor, and perform temperature compensation based on the vehicle load current data to obtain the compensated battery power consumption feature vector; based on the compensated battery power consumption feature vector, perform sleep cycle prediction and power consumption scheduling for the vehicle to obtain the sleep cycle transmission scheduling benchmark. Step S2: Obtain the original software upgrade package; construct a functional unit dependency graph based on the original software upgrade package; The original software upgrade package is fragmented based on the sleep cycle transmission scheduling benchmark and functional unit dependency graph to obtain fragmented upgrade packages. Step S3: Perform integrity verification on the data fragments received in real time during the transmission of the fragmented upgrade package, and filter the data fragments that pass the integrity verification based on the integrity verification results to obtain a set of verified fragment caches; perform transmission recovery scheduling on the set of verified fragment caches through the breakpoint resume scheduler to obtain fragmented transmission recovery status data; Step S4: Obtain the hardware configuration of the vehicle communication unit through the vehicle OBD-II diagnostic interface and identify redundant paths to obtain a redundant communication path table; ensure continuous transmission based on the redundant communication path table and the fragmented transmission recovery status data to obtain the upgrade package continuous transmission guarantee data. Step S5: Perform integrity verification and fragment merging on the continuous transmission guarantee data of the upgrade package to obtain the complete software upgrade package; The complete software upgrade package is divided into system layers to obtain the upgrade package layered system architecture; the upgrade package layered system architecture is verified by layered progressive flashing to locate the fault to the corresponding system layer in the upgrade package layered system architecture and obtain fault level location data. Based on the fault level location data, minimum functional firmware maintenance is performed on the faulty system level to obtain the controller software upgrade result.

2. The new energy vehicle communication controller software upgrade method according to claim 1, characterized in that, Step S1 involves acquiring vehicle load current data using the vehicle's built-in current sensor and performing temperature compensation based on the vehicle load current data, including the following steps: Step S11: Obtain vehicle ambient temperature data and acquire vehicle load current distribution monitoring data through the vehicle's built-in current sensor; Step S12: Simultaneously acquire vehicle load current distribution monitoring data through multiple channels to obtain vehicle load current data; Step S13: Perform Kalman time-domain filtering on the vehicle load current data to obtain steady-state load current signal data; Step S14: Evaluate battery capacity degradation based on steady-state load current signal data to obtain the vehicle battery capacity degradation coefficient; Step S15: Calculate the temperature influence factor based on the vehicle ambient temperature data and the vehicle battery capacity decay coefficient to obtain the temperature power consumption correction factor; Step S16: Perform power consumption distribution spectrum analysis based on the vehicle load current data to obtain the frequency domain characteristic data of load power consumption; Step S17: Perform spectral entropy weighted integration on the load power consumption frequency domain feature data and the temperature power consumption correction factor to obtain the compensated battery power consumption feature vector.

3. The new energy vehicle communication controller software upgrade method according to claim 2, characterized in that, Step S15 includes the following steps: Step S151: Perform time-domain waveform decomposition on the steady-state load current signal data to obtain the vehicle battery current waveform characteristic data; Step S152: Obtain the positive electrode material type parameters, negative electrode material type parameters, and electrolyte ionic conductivity attenuation coefficient of the vehicle battery; Step S153: Obtain vehicle battery calendar life data and vehicle deep discharge cycle count, and quantify historical degradation based on vehicle battery calendar life data and vehicle deep discharge cycle count using a preset aging accumulation model to obtain historical capacity degradation factor. Step S154: Based on the vehicle battery current waveform characteristic data, the positive electrode material type parameters of the vehicle battery, the negative electrode material type parameters of the vehicle battery, and the electrolyte ion conductivity decay coefficient, the active lithium ion loss is evaluated using a preset electrochemical degradation equation to obtain the electrochemical capacity decay characteristic value. Step S155: Obtain the temperature gradient distribution data of individual battery cells; perform temperature compensation on the electrochemical capacity decay characteristic value based on the temperature gradient distribution data of individual battery cells to obtain the temperature-calibrated electrochemical decay amount. Step S156: Perform a weighted fusion calculation based on the temperature-calibrated electrochemical decay amount and the historical capacity decay factor to obtain the battery capacity fusion decay coefficient; unify the dimensions of the battery capacity fusion decay coefficient to obtain the vehicle battery capacity decay coefficient.

4. The new energy vehicle communication controller software upgrade method according to claim 1, characterized in that, Step S1, which involves predicting the vehicle's sleep cycle and scheduling power consumption based on the compensated battery power consumption feature vector, includes the following steps: Step S181: Perform time-series alignment of the feature vectors based on the compensated battery power consumption feature vectors to obtain the time-series temperature compensated power consumption feature tensor; Step S182: Based on the preset LSTM network architecture, perform sequence modeling on the time-series temperature compensation power consumption feature tensor to obtain the vehicle power consumption time-series state prediction model. Step S183: Predict the future sleep cycle of the vehicle using the vehicle power consumption timing state prediction model to obtain sleep cycle prediction sequence data; Step S184: Perform sleep mode statistics on the sleep cycle prediction sequence data to obtain sleep mode statistical feature data; calculate the available transmission time window based on the sleep mode statistical feature data to obtain available transmission window time series data; Step S185: Obtain vehicle static configuration parameters and construct a set of vehicle power consumption constraints based on the vehicle static configuration parameters; Step S186: Optimize window scheduling based on available transmission window timing data and vehicle power consumption constraint set to obtain vehicle communication window scheduling table; Step S187: Construct the power consumption communication window mapping relationship based on the vehicle communication window scheduling table to obtain the sleep cycle transmission scheduling benchmark.

5. The new energy vehicle communication controller software upgrade method according to claim 1, characterized in that, Step S2 includes the following steps: Step S21: Obtain the original software upgrade package; perform integrity verification on the original software upgrade package to obtain the verified upgrade package data; Step S22: Parse the file format of the verified upgrade package data to obtain the upgrade package structure description data; identify code segment dependencies based on the upgrade package structure description data to obtain the upgrade package code dependency graph; Step S23: Deconstruct the control flow graph structure based on the upgrade package code dependency graph to obtain the upgrade package control flow graph; Step S24: Based on the upgrade package control flow graph and upgrade package structure description data, perform data flow dependency tracking to obtain the upgrade package data flow dependency graph; Step S25: Identify functional module boundaries based on the upgrade package data flow dependency graph to obtain upgrade package functional module partitioning data; Step S26: Extract the interface contract relationship between modules from the functional module partitioning data of the upgrade package to obtain the interface dependency data of the upgrade package modules; Step S27: Construct a directed acyclic graph based on the interface dependency data of the upgrade package module to obtain the functional unit dependency graph; Step S28: Fragment the original software upgrade package according to the hibernation cycle transmission scheduling benchmark and functional unit dependency graph to obtain fragmented upgrade packages.

6. The new energy vehicle communication controller software upgrade method according to claim 1, characterized in that, Step S3 includes the following steps: Step S31: Extract sharding metadata from the sharding upgrade package to obtain a smart sharding metadata set; Step S32: Construct the hash chain topology based on the intelligent sharding metadata set to obtain the initial hash chain state data; Step S33: Establish an incremental verification benchmark based on the initial hash chain state data to obtain the hash chain incremental verification benchmark; Step S34: Real-time data fragment capture is performed on the vehicle's network transmission channel to obtain real-time received data fragment segments; real-time hash calculation is performed on the real-time received data fragment segments to obtain the received fragment real-time hash data. Step S35: Perform integrity verification on the received fragment real-time hash data based on the hash chain incremental verification benchmark to obtain the fragment integrity verification result; Step S36: Filter verified molecules based on the fragment integrity verification results to obtain a set of verified molecule caches; Step S37: Perform transmission recovery scheduling on the verified molecular buffer set through the breakpoint resume scheduler to obtain fragment transmission recovery status data.

7. The new energy vehicle communication controller software upgrade method according to claim 1, characterized in that, Step S4, which involves obtaining the vehicle communication unit hardware configuration and identifying redundant paths via the vehicle OBD-II diagnostic interface, includes the following steps: Step S41: Obtain the hardware configuration of the vehicle communication unit through the vehicle OBD-II diagnostic interface; evaluate the communication capability of the communication unit hardware configuration to obtain the vehicle communication capability benchmark; Step S42: Initialize the multi-path communication channel based on the vehicle communication capability benchmark to obtain the initial state data of the vehicle communication channel; deploy a real-time monitoring mechanism for the initial state data of the vehicle communication channel to obtain the vehicle channel monitoring framework data; Step S43: Collect communication quality parameters through the vehicle-mounted channel monitoring frame data to obtain real-time multi-channel communication quality data; Step S44: Based on real-time multi-channel communication quality data, perform channel quality scoring to obtain a multi-path channel quality scoring table; Step S45: Perform redundant path topology modeling based on the multi-path channel quality scoring table to obtain the redundant communication path table; Step S46: Extract the current transmission task information based on the fragmented transmission recovery status data to obtain the upgrade packet transmission task queue.

8. The new energy vehicle communication controller software upgrade method according to claim 7, characterized in that, Step S4, which ensures continuous transmission based on the redundant communication path table and fragmented transmission recovery status data, includes the following steps: Step S471: Allocate tasks according to the redundant communication path table and the upgrade package to be transmitted task queue to obtain the initial transmission task allocation scheme; Step S472: Dynamically adjust the initial transmission task allocation scheme to obtain an adjusted transmission task allocation scheme; Step S473: Perform multi-path parallel transmission based on the adjusted transmission task allocation scheme to obtain multi-path parallel transmission status data; perform anomaly detection on the multi-path parallel transmission status data to obtain multi-path channel anomaly status data. Step S474: Predict the sleep trigger time based on the sleep cycle transmission scheduling benchmark to obtain the controller sleep warning time; Step S475: Based on the controller sleep warning time and multi-path channel abnormal status data, preheat the backup channel to obtain backup channel ready status data; Step S476: Based on the standby channel readiness status data, seamlessly switch the primary and backup channels using a preset hot-switching strategy to obtain channel switching execution data; Step S477: Perform transmission continuity assurance maintenance based on channel switching execution data to obtain upgrade package continuous transmission assurance data.

9. The method for upgrading the communication controller software of a new energy vehicle according to claim 1, characterized in that, Step S5 includes the following steps: Step S51: Perform hash verification on each fragment corresponding to the continuous transmission guarantee data of the upgrade package, and merge the fragments that pass the hash verification to obtain the complete software upgrade package; Step S52: Perform system architecture analysis on the complete software upgrade package to obtain the system hierarchy data of the upgrade package; Step S53: Based on the upgrade package system hierarchy data, perform a criticality level assessment to obtain the criticality score of the upgrade package components; Step S54: Divide the system into layers according to the criticality score of the upgrade package components to obtain the three-layer system architecture of the upgrade package, which includes the bootstrap layer components, the core function layer and the application service layer; Step S55: Perform hierarchical upgrade sequence planning on the three-tier system architecture data of the upgrade package to obtain a hierarchical upgrade scheduling scheme for the upgrade package; Step S56: Initialize the upgrade verification environment based on the upgrade package hierarchical upgrade scheduling scheme to obtain the hierarchical verification environment configuration; Step S57: Perform layered progressive flashing verification and fault location on the three-layer system architecture of the upgrade package according to the layered verification environment configuration to obtain fault level location data; Step S58: Perform dynamic firmware image maintenance based on fault level location data to obtain minimum functional firmware image data; construct a fault recovery channel based on the minimum functional firmware image data to obtain remote recovery connection data for the communication controller. Step S59: Remotely restore connection data via the communication controller to execute the fault self-healing process and obtain the controller software upgrade result.

10. A software upgrade system for a new energy vehicle communication controller, characterized in that, The new energy vehicle communication controller software upgrade system, used to perform the new energy vehicle communication controller software upgrade method as described in claim 1, comprises: The power consumption prediction module is used to acquire on-board load current data through the vehicle's built-in current sensor, and perform temperature compensation based on the on-board load current data to obtain a compensated battery power consumption feature vector; based on the compensated battery power consumption feature vector, the module performs sleep cycle prediction and power consumption scheduling for the vehicle to obtain a sleep cycle transmission scheduling benchmark. The fragmentation management module is used to obtain the original software upgrade package; construct a functional unit dependency graph based on the original software upgrade package; and fragment the original software upgrade package according to the sleep cycle transmission scheduling benchmark and the functional unit dependency graph to obtain fragmented upgrade packages. The verification and recovery module is used to verify the integrity of data fragments received in real time during the transmission of the fragmented upgrade package, and to filter the data fragments that pass the integrity verification based on the results to obtain a set of verified fragment caches. The transmission recovery scheduler performs transmission recovery scheduling on the set of verified fragment caches to obtain fragmented transmission recovery status data. The transmission assurance module is used to obtain the hardware configuration of the vehicle communication unit through the vehicle OBD-II diagnostic interface and perform redundant path identification to obtain a redundant communication path table; based on the redundant communication path table and the fragmented transmission recovery status data, it performs continuous transmission assurance to obtain upgrade package continuous transmission assurance data. The fault handling module is used to perform integrity verification and fragment merging on the continuous transmission guarantee data of the upgrade package to obtain a complete software upgrade package; to perform system layering on the complete software upgrade package to obtain the layered system architecture of the upgrade package; to perform layered progressive flashing verification on the layered system architecture of the upgrade package to locate the fault to the corresponding system level in the layered system architecture of the upgrade package and obtain fault level location data; and to perform minimum functional firmware maintenance on the system level where the fault occurred based on the fault level location data to obtain the controller software upgrade result.

Images