Cloud edge collaboration-based power battery full life cycle health state online correction method

Abstract

The application discloses a power battery full life cycle health state online correction method based on cloud edge cooperation and relates to the technical field of battery management. First, a unified multi-dimensional health state parameter group of the cloud end and the vehicle end is established, a limitation identifier is mapped and recorded at the single-body-module-pack level, and a vehicle-end health state initial value, a cloud-end health state estimated value and a confidence level are obtained respectively. Secondly, the cloud end defines a key control output index and constructs a control sensitivity relationship, solves a recommended correction amount in combination with a risk cost constraint, generates a correction instruction package containing a recommended working condition window, a maximum step and a maximum change rate, and issues the correction instruction package. Finally, the vehicle end executes according to the working condition gate, performs shadow verification, smoothes and fuses, and updates the control parameters in linkage, monitors the deviation and safety events in the verification window, and reports the abnormal rollback; the method reduces display jump and power limit value fluctuation, reduces false positives, and improves caliber consistency and stability.

Description

Technical Field

[0001] This invention relates to the field of battery management technology, specifically to a method for online correction of the health status of a power battery throughout its entire lifecycle based on cloud-edge collaboration. Background Technology

[0002] In new energy vehicles, battery swapping fleets, charging stations, and industrial and commercial energy storage systems, voltage, current, temperature, and other parameters are typically collected and protected by the on-board battery management system. This data is then uploaded to a cloud-based battery management platform via vehicle-to-everything (V2X) communication for health assessments, fault warnings, residual value assessments, and operational decisions. Currently, vehicle-side technologies primarily estimate parameters such as state of charge (SOC), capacity decay, and power capability through equivalent circuit and state observation methods. The cloud, on the other hand, can utilize historical data over longer time windows, data from other vehicles on the same platform, and charging / discharging event records to provide more accurate health estimates. Within a certain period, the cloud can transmit corrected results or calibration parameters back to the vehicle-side to support subsequent updates to range estimation, power limiting, and thermal management. Because multidimensional health parameters and control parameters are coupled in this closed loop, changes in health estimates such as capacity or internal resistance can trigger calculations of derived quantities such as available energy, available power, SOC display baseline, alarm thresholds, and temperature control trigger points.

[0003] Since cloud-based corrections are mostly based on long-window data statistics and model inference, their update speed and time differ from the real-time estimation on the vehicle side. Moreover, they are affected by communication delays, missing data, and changes in operating conditions. When corrections occur during driving, high-rate discharge, or fast charging, if only certain health parameters are updated in an overlay manner, or if the vehicle-side control parameters are not synchronized with the corrected health parameters, inconsistencies in health parameters, sudden changes in derived control quantities, and threshold boundary jitter are likely to occur.

[0004] Such inconsistencies can impact actual business operations: range or charge exhibits abrupt changes that are noticeably perceived by users; power limitation curves change drastically in a short period, affecting power performance and charging efficiency; alarm and protection thresholds change with corrections, leading to more false alarms or maintenance changes; and different health status definitions in fleet scheduling, battery swapping allocation, and energy storage power planning result in energy prediction deviations, leading to overly conservative or overly aggressive operational decisions, which increases the risk of lifespan depletion and passive shrinkage of safety margins.

[0005] Therefore, the current technical problem to be solved is: when the cloud-edge collaborative backhaul is used to correct the multi-dimensional health status of the power battery, how to ensure that the health parameters and derived control parameters are consistent in terms of scope and timing under different communication conditions and operating conditions, so as to avoid sudden changes in control outputs such as available power, available energy, display reference and alarm threshold, which could endanger operation and maintenance. Summary of the Invention

[0006] (a) Technical problems to be solved

[0007] To address the shortcomings of existing technologies, this invention provides an online correction method for the full lifecycle health status of power batteries based on cloud-edge collaboration. By defining key control output indicators and constructing control sensitivity relationships, and combining risk and cost constraints to solve for suggested correction amounts, a correction instruction package containing a recommended operating condition window, maximum step size, and maximum rate of change is generated and issued. Finally, the vehicle-side executes the control according to the operating condition gating, performing shadow verification followed by smooth fusion and synchronized updates to control parameters. Deviations and safety events are monitored within the verification window, and anomalies are rolled back and reported. This method reduces display jumps and power limit jitter, decreases false alarms, and solves the technical problems described in the background section.

[0008] (II) Technical Solution

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] The online correction method for the full life cycle health status of power batteries based on cloud-edge collaboration includes: defining a multi-dimensional health status parameter group between the cloud and the vehicle; mapping and recording the identification information of restricted cells or restricted modules from the individual cell layer to the whole pack layer; obtaining the initial value of the vehicle health status at the vehicle end; and obtaining the cloud health status estimate and the dimension-by-dimensional confidence level based on the full life cycle data at the cloud end.

[0011] The cloud defines key control output indicators and establishes control output sensitivity relationships; based on the initial value of vehicle health status, cloud health status estimate, and dimension-by-dimensional confidence level combined with risk cost constraints, the cloud calculates the suggested correction amount, generates a correction instruction package containing recommended operating condition window, maximum step size, and maximum rate of change, and issues it.

[0012] After receiving the correction instruction packet, the vehicle identifies the operating condition and gates the recommended correction amount according to the recommended operating condition window; after the candidate correction is verified by shadow verification, it is smoothly merged and the parameters are updated in conjunction with the maximum step size and maximum rate of change constraints; deviations and safety events are monitored in the verification window, and abnormal rollback is reported.

[0013] Furthermore, the multidimensional health status parameter group includes state of charge, capacity health, internal resistance or power health, available power capability, available energy capability, thermal safety health, and consistency health, and further includes fast charging ratio, number of deep discharge events, cumulative cycle and temperature exposure statistics, as well as overvoltage, overcurrent and overtemperature risk levels, lifespan degradation risk levels, and thermal runaway risk levels.

[0014] Furthermore, at the individual unit layer, each field is weighted and aggregated according to the individual unit weight coefficient to obtain the module layer field. At the module layer, each module layer field is aggregated according to the same caliber to obtain the whole package layer field. During each aggregation, the identification information of the restricted individual unit or restricted module is generated and inherited, so that the whole package layer field and the identification information correspond one-to-one.

[0015] Furthermore, the edge device performs timestamp alignment, missing and outlier marking, slope interpolation, and operating condition labeling on the vehicle-side sampling sequence. It then segments the data into data fragment indexes based on start and end times and uploads the data fragment indexes, field version numbers, and identification information of restricted cells or restricted modules along with the initial vehicle-side health status values ​​to the cloud-based battery management platform.

[0016] Furthermore, the cloud-based battery management platform calculates the residual energy ratio and the complete segment ratio based on the data segment index, and generates a dimension-by-dimensional confidence score accordingly. The complete segment ratio is determined by the coverage ratio of the effective data segment within a preset time window, and the residual energy ratio is determined by the energy normalization of the difference sequence between the cloud prediction output and the segment observation benchmark within the time window.

[0017] Furthermore, key control output indicators include maximum charging limit, maximum discharging limit, instrument display state of charge, thermal management target temperature and start / stop threshold, alarm and protection trigger threshold; the control output sensitivity relationship is obtained by applying perturbation to the multidimensional health status parameter group dimension by dimension and recalculating the key control output indicators under the same field version number and operating condition label, and stored in segments according to temperature range, multiplier range, and vehicle platform.

[0018] Furthermore, when solving for the suggested correction amount, the cloud-based battery management platform sets weights for each dimension corresponding to the confidence level of each dimension; and applies penalty constraints to the correction frequency, correction magnitude, and correctable dimensions. At the same time, it constrains the change magnitude and rate of change of key control output indicators with the control output sensitivity relationship, and outputs the solution results including the suggested correction amount of each dimension and the recommended operating condition window.

[0019] Furthermore, the correction instruction package also includes validity period, instruction version number, field version number, data fragment index, and identification information for restricting single entities or restricting modules. For dimensions with a confidence level lower than a preset threshold, it writes "only record, do not execute" to exclude the corresponding dimension from shadow verification and smooth fusion.

[0020] Furthermore, shadow verification includes: generating candidate health states based on the suggested correction amount and mapping them to obtain candidate control parameters; replaying recent typical operating condition segments to deduce the sequence of key control output indicators; checking the continuity of the display, the rate of change of power limits, and the voltage and temperature boundaries corresponding to the identification information of the limiting unit or limiting module; if it fails, it sequentially performs actions such as reducing the candidate correction magnitude, transferring to the pending execution queue, or changing to recording without execution.

[0021] Furthermore, the smooth fusion process writes the suggested correction amount into the initial value of the vehicle's health status in segments according to the maximum step size and the maximum rate of change, and simultaneously performs template migration of the control linkage update parameters.

[0022] The vehicle-side verification window monitors deviations based on residual energy ratio and records safety events. When the deviation exceeds a preset threshold, it rolls back to the health status and control configuration before correction and reports the instruction version number and anomaly record.

[0023] (III) Beneficial Effects

[0024] This invention provides an online method for correcting the health status of power batteries throughout their entire lifecycle based on cloud-edge collaboration, which has the following beneficial effects:

[0025] Establish a unified multi-dimensional health status parameter group between the cloud and the vehicle, and map and record the identification information of restricted individuals or restricted modules in a consistent manner at the individual layer, module layer, and whole package layer. This ensures that the health status definition is consistent and the source of the restricted boundary can be traced, providing a positioning basis for subsequent corrections.

[0026] The vehicle-side generates an initial health status value based on voltage, current, temperature, and event records. The edge side aligns the sampling sequence with timestamps and marks abnormal points to form a data segment index. The cloud side then generates a cloud health status estimate based on this and provides a dimension-by-dimensional confidence level, enabling the correction to have a credible basis for each dimension.

[0027] The cloud defines key control output indicators and constructs control output sensitivity relationships. Under risk and cost constraints, it solves for the recommended correction amount, so that the changes of the recommended correction amount, power limit, display reference, thermal management threshold, and alarm and protection trigger threshold are controlled. The cloud encapsulates the recommended correction amount, along with the recommended operating condition window, maximum step size, maximum rate of change, and gating flag, into a correction instruction package, so that the vehicle can still verify, execute, and trace according to a unified boundary even under communication delays and operating condition switching.

[0028] The vehicle-side performs operating condition gating based on the recommended operating condition window, and uses shadow verification to extrapolate and verify the candidate control parameters obtained by the candidate correction mapping. The extrapolation and verification generates criteria based on the control output sensitivity relationship, and performs downgrading or delaying on candidate corrections that do not meet the continuity and boundary conditions, thereby reducing sudden power limiting and threshold switching.

[0029] The vehicle-side system smoothly integrates under the constraints of maximum step size and maximum rate of change. It also smoothly migrates and synchronously updates the rated capacity, power limit curve, thermal management threshold, and equalization strategy through the control configuration template. Furthermore, it monitors deviations and safety events during the verification window and rolls back to the initial value of the vehicle-side health status when anomalies occur, while reporting the instruction version number and data fragment index. The system also enables the cloud to continuously revise the control output sensitivity relationship and correction rules based on data feedback, forming a closed loop. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the online correction method for the health status of a power battery throughout its entire life cycle, as presented in this invention. Detailed Implementation

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

[0032] Please see Figure 1 This invention provides an online correction method for the full life cycle health status of power batteries based on cloud-edge collaboration. The method includes the following steps: Step 1: Connecting the cloud and the vehicle with the same set of multi-dimensional health status parameters to form three types of basic data: initial health status value of the vehicle, estimated health status value of the cloud, and confidence level of each dimension, so that subsequent corrections can be aligned with objects, levels, and time windows.

[0033] When a power battery is running in a vehicle, its state of charge, capacity health, power capability, available energy, thermal safety margin, and consistency differences will simultaneously affect power limits, display benchmarks, and alarm thresholds. If the cloud and vehicle use different granularities or different sets of fields to describe the health status, even if the same value is obtained later, discrepancies will occur at the control layer due to missing fields or inconsistent aggregation rules. Therefore, the first step is to solidify what the object being described is before proceeding to how the value is estimated.

[0034] First, using a multidimensional health status parameter group as the sole terminology, its field set and field boundaries are defined, and each field is defined as an engineering quantity that can be collected or calculated at the vehicle end, verified or calculated in the cloud, and referenced in the overall package control. This field set includes at least seven categories of fields: state of charge, capacity health, internal resistance or power health, available power capability, available energy capability, thermal safety health, and consistency health. Furthermore, by using two types of extended fields—load and risk—it expresses the proportion of fast charging, the number of deep discharge events, cumulative cycle and temperature exposure statistics, high-rate event statistics, and the risk levels of overvoltage, overcurrent, and overtemperature, as well as the risk levels of lifespan degradation and thermal runaway. The above fields use fixed field names and fixed semantic boundaries, prohibiting homonyms or synonyms between the vehicle end and the cloud, thereby avoiding the confusion of quantities with different semantics as the same input during subsequent modifications.

[0035] While locking the fields, a fixed rule for limiting source identification is introduced: for each parameter in the entire package layer, in addition to recording the parameter value, its limiting source identification information is also recorded, including at least the limiting unit identifier, limiting module identifier, and limiting type identifier. The limiting type identifier is used to distinguish whether the parameter is triggered by a voltage boundary, temperature boundary, current boundary, or consistency boundary, so that subsequent steps can select different verification paths for different boundaries when processing corrections. Limiting source identification does not require the introduction of additional sensors, but rather forms a traceable index based on existing vehicle-side sampling and event records.

[0036] The field set, field version number, and restricted source identifier are written simultaneously in the vehicle-side parameter storage area and the cloud-based health record. The field version number and restricted source identifier are carried with each upload to ensure that the cloud and vehicle sides interpret the same field in a consistent manner.

[0037] When in use, the expression of health status is fixed within the set of fields that can be referenced by the control strategy to avoid implicit reinterpretation caused by missing fields in subsequent corrections; the source of the restriction of the entire package boundary is made explicit to provide a location entry point for subsequent corrections, so that the corrections can be directed to the key parts that affect the control boundary.

[0038] To address the most common source of ambiguity in the single-module-whole package structure—inconsistent aggregation rules—a unified hierarchical mapping method is proposed. Considering that the control boundary of the whole package is often affected by restricting single-modules or restricting modules, and that simple arithmetic averaging can easily mask local extreme values, weighted quantile aggregation is adopted as the preferred implementation, so that the module layer and the whole package layer can keep boundary-sensitive local features visible.

[0039] In terms of computational form, for a set of values ​​for a single layer of a health field, each single entity is first assigned a single entity weight coefficient to express sensing reliability and structural importance, and then the mapping result is determined by quantile level. Weighted quantile aggregation can be written as:

[0040]

[0041] Where: monomer eigenvalues : No. The values ​​of individual entities in the same field are determined by the physical boundaries of the field; individual entity weight coefficients. : No. The weight of each individual, and its range. and satisfy This is used to reflect the credibility or structural importance of the individual data;

[0042] Number of monomers : The number of monomers participating in the aggregation, taking a positive integer value, derived from the module's serial-parallel structure and available sampling channels; quantile level The quantile position used in the aggregation, and its value. This is used to determine whether the aggregation result is more biased towards the boundary-sensitive side or the center side; aggregation variables The desired aggregation result is a real number whose physical meaning is consistent with the field name; the aggregation result is... At the quantile level The optimal aggregated value is used as input for the module layer or whole package layer fields.

[0043] Define the valid flag of a single entity The value selection rule is as follows: when the single channel does not have any missing test or outlier markers in the current data segment index and the event record is not marked as a sampling failure, Conversely, take ,in Range of values Furthermore, the version number is fixed within the field. Based on this, the individual weight coefficient is given:

[0044]

[0045] Where: Individual weight coefficient : Range of values Used for weighted fractional aggregation; monomer validity marker : Set of values Used to reflect channel effectiveness; minimum effective weight : Range of values This is used to avoid the normalization denominator being zero and to retain weak contributions; number of monomers : The number of monomers participating in the aggregation, which is a positive integer.

[0046] The objective function of this formula consists of two parts, which apply asymmetric weights to deviations above and below the aggregate value, respectively, at the quantile level. The relative penalty for controlling the deviation on both sides, therefore when When the boundary side is favored, the aggregation results tend to reflect the influence of limiting monomers, thus aligning with the formation mechanism of the overall control boundary. This problem is a piecewise linear convex form, which can be solved using the subgradient method or coordinate descent method, and executed on the vehicle or cloud with a fixed number of iterations to ensure feasibility.

[0047] Weighted quantization aggregation is used as the main rule for hierarchical mapping. The same aggregation form is reused in both the module layer and the whole package layer. At the same time, the inheritance relationship and overriding rules of the source identifier are fixed and restricted.

[0048] It should be added that the percentile level should be written as the field percentile level. And fixed according to field category: for fields dominated by upper limit constraints (such as temperature-related safety margins, upper limit triggered consistency indicators), take near For fields dominated by lower bound constraints (such as low voltage margin indicators), take... near ;

[0049] Fields with a more significant central trend (such as the state of charge baseline used to display smoothness) are taken as... . The value is determined by the version number in the field, and it is consistent between the cloud and the vehicle.

[0050] When in use, the hierarchical mapping rules can be calculated and verified, and the same module layer and whole package layer fields can still be obtained on the cloud and vehicle side under different computing power. The aggregation process matches the control boundary formation mechanism, and the whole package layer fields maintain sensitivity to the restricted unit. The restriction source identifier is inherited with the aggregation link, and subsequent corrections can locate the restricted unit or restricted module along the mapping chain.

[0051] Vehicle-side estimation focuses on short time windows and sampling continuity, while cloud-based estimation focuses on long time windows and historical traceability. The two are inherently different in terms of time scale, data gaps, and operating condition coverage. If only two sets of estimates are output without outputting dimension-by-dimensional confidence scores, subsequent corrections will be unable to distinguish whether a difference in a certain field stems from estimation errors or from data gaps or operating condition mismatches. This makes it easier to trigger abrupt changes in control output during correction applications.

[0052] First, a traceable initial value of the vehicle's health status is generated on the vehicle side, and the uploaded data is organized into verifiable data fragments on the edge side. Then, a cloud-based health status estimate is generated in the cloud, and the confidence level of each field is calculated and output for each dimension, so that subsequent steps can use the confidence level as a field-level constraint or gating condition.

[0053] On-site executable actions for the vehicle battery management system: The vehicle battery management system collects voltage, current, temperature, and charging / discharging status and event records according to a preset sampling period, and forms an initial value of the vehicle's health status using equivalent circuits and state observation algorithms. To ensure that subsequent cloud-based estimations can verify the formation process of the initial vehicle-side estimation, the edge device performs three types of processing on the original sampling sequence:

[0054] First, align sampling timestamps with a unified clock to eliminate time drift between different sampling channels. Second, archive sampling sequences into data segments according to field type, with each data segment containing start and end times, operating condition labels, boundary event identifiers, and field version numbers. Third, perform slope-preserving interpolation and step blocking for obviously discontinuous sampling points. That is, when the rate of change of adjacent sampling points exceeds the physical allowable range of the field, the point is first marked as an outlier and interpolated using the trend of adjacent segments, while retaining the outlier mark so that the cloud can explicitly detect data anomalies during confidence calculation. The interpolation method can use slope-limited linear interpolation or monotonic cubic spline interpolation, with the field physical boundary as a constraint condition to prevent interpolated values ​​from crossing the feasible region.

[0055] While outputting the initial vehicle health status value at the vehicle end, the sampling sequence is organized into segments with timestamps, operating condition labels, boundary event identifiers, field version numbers, and outlier identifiers, and uploaded along with a restricted source identifier at the edge. When used, the initial vehicle health status value can be traced back to its input, and the cloud can verify the context in which this initial value was formed by data segments. Outlier markers and boundary event identifiers are saved to ensure that subsequent confidence calculations can distinguish between data anomalies and actual operating conditions. Data segments have field version numbers and restricted source identifiers to ensure that the cloud estimate and the initial vehicle estimate are aligned within a single field interpretation framework.

[0056] Using cloud-based health records as input, the system outputs two types of results for each field: a cloud-based health status estimate and a dimension-by-dimensional confidence score. The calculation of the cloud-based health status estimate relies on full lifecycle data, including production inspection records, factory inspection records, in-use operation records, maintenance inspection records, and decommissioning assessment records. The system aligns the uploaded data segments during estimation, enabling the cloud-based estimate to clearly identify which segments were used and which anomalies were ignored.

[0057] Instead of using simple discrete fluctuation statistics, the calculation of the confidence level for each dimension uses two types of interpretable quantities as input: residual energy ratio and data complete fragment ratio, which respectively characterize the explanatory power of the model for the field and the continuity of the data in the field.

[0058] Furthermore, the residual energy ratio can be defined as:

[0059]

[0060] Where: Field serial number : The ordinal number of the field in the multidimensional health status parameter group, which is a positive integer and is sorted in a fixed order according to the field set; residual energy ratio Field serial number The residual energy percentage, taking values This is used to characterize the strength of the interpretation error of the cloud estimation for this field;

[0061] residual function Field serial number In time The estimated residuals are typically formed by the difference between the cloud model output and the fragment observations, and their range is determined by the physical boundaries of the field; observation function Field serial number In time The observation benchmark can be either fragment observations or vehicle-end benchmark values ​​after standardization, and the range of values ​​is determined by the physical boundaries of the field.

[0062] For fields that can be directly observed (such as temperature-related fields). Take a segment of the observation sequence; for fields that cannot be directly observed (such as capacity health, internal resistance, or power health). The serialized output of the initial health status value of the vehicle is taken within the same window (generated by the vehicle algorithm by replaying the same sampling beat). Defined as a cloud-based health status estimate-driven predictive output and The difference is that the predicted output is obtained by running the model corresponding to the same field version number under the same data fragment index in the cloud. Time window start point. The start time of the confidence calculation window, which is a real number on the time axis; the end time of the time window. The end time of the confidence calculation window, which is a real number on the time axis, and satisfies the following conditions: ; Zero constant : To prevent the denominator from being zero, the value of the constant is determined. This is used to ensure numerical stability.

[0063] This formula uses a time integral form, making the confidence level insensitive to single-point anomalies while reflecting the accumulation of residual energy over a time window. The integral can be implemented in the cloud as a discrete summation, using anomaly markers as a mask to avoid the non-physical amplification of the residual energy ratio by anomalies.

[0064] Based on this, the dimension-wise confidence level is defined as a joint gating of the residual energy ratio and the ratio of complete data fragments:

[0065]

[0066] Where: Dimensional confidence level Field serial number The confidence level, with values ​​of This is used to indicate the reliability of the cloud-based estimate for this field; attenuation coefficient. The attenuation intensity of residual gating, and its value. It is used to control the suppression of the confidence level by the residual energy ratio;

[0067] Residual energy ratio As defined in the above formula, the value can be... Gain coefficient Gain of integrity gating, value This is used to control the rate at which the confidence level increases when comparing complete data segments; the complete data segment comparison... Time window The ratio of available fragments in an internal data fragment, with values ​​ranging from [value 1] to [value 2]. The calculation is based on the sum of the effective segment duration and the window duration, minus the duration of outliers that are masked.

[0068] Set in window shared within The data segment, the first The start and end times of each segment are , and define the field's valid indication When the field number in this fragment When there are no missing tests in the sampling and the proportion of outlier markers does not exceed the allowable limit configured for the field version number, Otherwise .but

[0069]

[0070] In the formula: the ratio of complete segments : Range of values , indicating field Effective coverage ratio; number of segments : Positive integer; field validity indicator : Set of values ; fragment time Real timestamp, satisfying Window endpoints Real timestamp, satisfying .

[0071] Dimensional confidence The construction mechanism is as follows: when the residual energy ratio decreases, the first exponential decay term approaches... This indicates that the suppression of confidence by the estimated residuals weakens; as the proportion of complete fragments increases, the second gating term approaches... This indicates that data coverage enhances the support for confidence levels. This joint gating ensures that neither cases with small residuals but insufficient data coverage nor cases with sufficient data coverage but large residuals will result in excessively high confidence levels, thus providing a field-level execution basis for subsequent corrections. As an equivalent implementation, the complete fragment ratio can be replaced with the boundary event coverage ratio, that is, using the fragment coverage near the boundary event as the confidence level. It is a component used to strengthen constraints on control boundary sensitive fields.

[0072] While outputting the cloud-based health status estimate, the cloud also outputs the confidence score by field number, and records the residual energy ratio to the complete segment ratio as a traceable intermediate quantity in the health profile, allowing the vehicle to verify the source of the confidence score. Data segments are divided by edge devices according to the following conditions: when the operating condition label changes, or when boundary event identifiers change in the event log, or when a dense segment of anomaly markers appears in the sampling channel, a new segment is formed. Each data segment is written with start and end times, operating condition label, boundary event identifier, field version number, and anomaly marker set.

[0073] When used, the confidence level is determined by the residual energy ratio and the complete fragment ratio, making the confidence level an interpretable input, which facilitates the formation of gating conditions on the vehicle side during the execution phase; outlier markers are included in the masking process to reduce the misleading effect of outliers on the confidence level; the cloud output estimate and the confidence level are aligned with the data fragments from the same source, ensuring that they can be compared with the initial value of the vehicle side health status under the same time window and the same field version.

[0074] Step 2: Based on the dual estimation and dimension-wise confidence in Step 1, construct the control output sensitivity relationship in the cloud and introduce risk cost constraints. Then, solve the control-friendly suggested correction amount and effective window. Finally, encapsulate it into an executable, rollback, and auditable correction instruction package and send it to the vehicle.

[0075] The state of charge, capacity health, internal resistance or power health, available power capability, available energy capability, thermal safety health, and consistency health parameters in the multi-dimensional health status parameter set may all trigger power limits, display baseline adjustments, thermal management threshold switching, and alarm protection threshold changes at the vehicle end. If the cloud does not explicitly consider these control outputs when solving the correction scheme, even if the correction command is reasonable in a health sense, it may cause abrupt changes in control outputs when executed at the vehicle end.

[0076] Therefore, the key control outputs that need to be constrained are solidified into computable objects, and then a sensitivity relationship is established on how changes in health fields are mapped to changes in control outputs, providing directly referable constraint quantities for solving the cost function.

[0077] The cloud first reads the field version number and restriction source identifier output in step one to ensure that the calculation caliber of the control output is consistent with that of the vehicle. Then, based on the same control configuration template, it extracts key control output indicators that are directly coupled with the health field and binds these indicators to a traceable set of fields. Subsequently, the cloud establishes the control output sensitivity relationship based on simulation calibration, bench testing or fleet historical data regression, and forms segmented configurations according to temperature range, multiplier range and vehicle platform, so that the sensitivity relationship can be reused and updated under different operating conditions.

[0078] Using key control output indicators as the sole terminology, it is ensured that their source is consistent with that of the vehicle, and that a traceable binding relationship is formed between them and the field version number and source restriction identifier of the multi-dimensional health status parameter group in step one. The cloud-based battery management platform first reads the field version number reported by the vehicle to ensure that the subsequent interpretation of state of charge, capacity health, internal resistance or power health, available power capability, available energy capability, thermal safety health, and consistency health is consistent with that of the vehicle. Then, based on the control configuration template currently enabled by the vehicle, it extracts a set of indicators directly related to the overall battery pack control boundary in the cloud, including at least the maximum charging limit, maximum discharging limit, state of charge or driving range displayed on the instrument panel, thermal management target temperature and start / stop threshold, and alarm and protection trigger threshold.

[0079] To avoid ambiguity caused by seemingly identical control output indicators originating from different sources, each key control output indicator is required to be recorded in the cloud. Three types of traceability information are written into these records: first, the corresponding health field sequence number and field version number; second, the restriction unit identifier or restriction module identifier pointed to by the restriction source identifier; and third, the operating condition label where the indicator is located under the current data segment index. Through this writing process, the cloud permanently records which field affects the control output, which restriction source drives it, and which type of operating condition segment it occurs in, within the same record. This prevents the subsequent calculation of sensitivity relationships from mistakenly conflating output changes under different operating conditions or restriction sources with the same pattern.

[0080] The cloud-based system creates an indicator record for each key control output indicator in the health record. The indicator record also carries a field version number, field sequence number, restriction source identifier, and operating condition label, and uses the indicator record as the input basis for the cost function.

[0081] When using it, key control output indicators are fixed as verifiable objects, so that subsequent correction constraints have a unique caliber; indicators are bound to limit source identifiers, so that changes in control output can be traced back to the limiting unit or limiting module; indicators are placed alongside operating condition labels, so that the segmented configuration of sensitivity relationships has clear operating condition boundaries.

[0082] This paper presents an feasible construction process based on the sensitivity of control outputs to changes in health fields, enabling the cloud to predict which type of control output change will be caused by a change in a certain health field when solving for correction schemes. Starting with established indicator records, the cloud selects a set of data segment indexes under the same vehicle platform, field version number, and operating condition label. Then, it performs a calibration process of small disturbance-recalculation-recording changes for each health field: the disturbance object is the suggested correction amount for the health field, and the disturbance reference is the initial vehicle health status value formed in step one and the cloud health status estimate; the recalculation object is the key control output indicators; and the recording object is the correspondence between the control output change amount and the disturbance amount.

[0083] In mathematical representation, the cloud-based system solidifies the sensitivity relationship into a set of sensitivity coefficients, while prioritizing linear approximation as the preferred option, thus mapping the correction amount to the change in control output at a lower cost.

[0084]

[0085] Control output variation : No. The change in a key control output indicator is determined by the physical boundary of that indicator and the control configuration template; Control output sequence number: the sequence number of the key control output indicator. value range to This is used to index control outputs under the same template; the number of control outputs... The number of the first key control output indicators is a positive integer, and the value is determined by the fixed set of indicators.

[0086] Health field correction amount : No. The suggested correction amount for each health field is constrained by the field's physical boundaries, maximum step size, and maximum rate of change; health field serial number. : The sequence number and possible values ​​for the health field. to The field set is sorted in the same way as in step one.

[0087] Number of health fields : The number of fields in the multidimensional health status parameter group, taking a positive integer value, representing the total number of fields in the field set from step one; sensitivity coefficient. : No. The health field for the first The sensitivity coefficient of the control output is a real number. Its sign indicates the direction of change, and its absolute value indicates the strength of the influence. Its value is obtained from simulation calibration, bench testing, or regression of historical data of the fleet and is selected in the segment configuration.

[0088] For a given vehicle model, platform, and operating condition label, select the baseline state as the initial value of the vehicle's health status. Take the field perturbation amplitude as the field perturbation amplitude. Its value range is and select the best The sensitivity coefficient can then be obtained by using the difference quotient:

[0089]

[0090] Where: sensitivity coefficient : Real number, representing a field For control output Local linear effects; control output function Under a fixed control configuration template, calculate the first value after specifying the health field value. The function of the key control output index is specifically implemented as a cloud-based isomorphic replay of the vehicle-side control logic; field perturbation amplitude. : Positive real number, range of values Maximum step size of the field : Positive real number, from the instruction packet constraint in step two; control output sequence number Field serial number :index.

[0091] To avoid nonlinearity, the cloud calculates and stores the data separately for temperature range and multiplier range. And write the index number of the coefficient set when issuing the instruction packet.

[0092] The control output function refers to a set of deterministic calculation relationships that determine key control output indicators based on a preset control configuration template, given a set of multi-dimensional health status parameters and input conditions such as the current overall voltage, overall temperature, operating condition label, and limiting unit or module identifiers. These key control output indicators include at least the maximum charging limit, maximum discharging limit, instrument-displayed state of charge or driving range reference, thermal management target temperature and start / stop threshold, alarm threshold, and protection trigger threshold. The control output function maps the multi-dimensional health status parameter set and the current sampled values ​​to corresponding control output values ​​through table lookup, minimum or maximum calculation, and amplitude limiting operations. The same control configuration template is used on both the cloud and vehicle sides to ensure consistent calculation methods.

[0093] The lookup table refers to the pre-stored mapping table in the control configuration template. This mapping table consists of an input breakpoint sequence and an output value sequence corresponding to the input breakpoint sequence. It is used to map the relevant fields in the multidimensional health status parameter group, as well as the currently collected whole package voltage, whole package temperature, operating condition label, and the lowest single-unit voltage or highest module temperature corresponding to the limiting single unit or limiting module identifier, into key control output indicators.

[0094] The table lookup process includes: determining the breakpoint interval to which the input quantity belongs; reading the output values ​​corresponding to the two endpoints of the interval; calculating the output within the interval according to the interpolation rules preset in the control configuration template; and retrieving the output value corresponding to the boundary breakpoint when the input quantity falls outside the breakpoint interval. The mapping table should at least include mapping tables related to the maximum charging limit, maximum discharging limit, instrument display state of charge or driving range reference, thermal management target temperature and start / stop threshold, and alarm and protection trigger threshold. The cloud and vehicle should use the same control configuration template version to ensure consistent value retrieval.

[0095] This formula approximates the change in control output as a linear superposition of the corrections for each health field. Its rationality is based on the premise of small disturbances, that is, the cloud limits the disturbance amplitude to the maximum step size allowed by the vehicle when constructing the sensitivity, so that higher-order nonlinear terms are absorbed into the piecewise configuration and coefficient update; when changes in operating conditions lead to increased nonlinearity, it is reselected according to temperature range, rate range, and vehicle platform. The corresponding set of coefficients preserves the linear approximation locally.

[0096] To ensure the feasibility of this sensitivity relationship, three engineering implementation paths are proposed: the first is to focus on simulation calibration, applying health field perturbations to typical operating condition sequences under the control configuration template and then fitting the data. Secondly, bench testing is the primary method, applying small-amplitude capacity or internal resistance equivalent disturbances to the entire package within the safety boundary and reading the changes in control output. Thirdly, historical data regression of the fleet is the primary method, using naturally occurring health differences and control output records to infer changes under the same operating condition label. All three paths use the indicator records as anchors to ensure that the coefficients and field version numbers, operating condition labels and restriction source identifiers are consistent.

[0097] The cloud uses the field version number and working condition label as indexes, maintains a set of sensitivity coefficients for each set of indexes, and selects the most matching set of sensitivity coefficients to participate in the calculation before solving the correction scheme.

[0098] When used, the rules that cause changes in control output are solidified into computable relationships, which can quantify and constrain abrupt changes in control output; through segmented configuration, the sensitivity relationship can still be selected under different temperature and magnification conditions without relying on a one-time fit; through joint indexing with the limiting source identifier, the sensitivity relationship remains sensitive to boundary changes driven by limiting individual units or limiting modules.

[0099] Cloud-based health status estimates have long-term windows and full lifecycle information, but their reliability varies across different fields. Step one explicitly expresses this difference as a dimension-by-dimensional confidence level. If the confidence level is not considered in each dimension... The proposed correction scheme, which significantly modifies low-confidence fields, can cause abrupt changes in control output. The frequency and magnitude of corrections will consume lifespan and operational costs. Without risk and cost constraints, correction instructions may switch repeatedly in a short period of time, leading to policy jitter.

[0100] The cloud first constructs an initial difference between the initial vehicle health status value obtained in step one and the cloud health status estimate, and then uses a dimension-wise confidence level. As field-level weights, the established sensitivity relationship is then introduced into the cost function, making the cost function more closely approximate the cloud estimation and control output changes more smoothly after the constraint correction. A risk cost term is then introduced to limit the cumulative effect of the correction frequency and correction magnitude. Finally, the suggested correction amount and recommended operating condition window are obtained and encapsulated into a correction instruction package containing validity period, verification information and rollback constraints.

[0101] First, replace the two sets of estimates obtained in step one with initial differences of the same caliber, and then directly apply the dimension-by-dimensional confidence scores to these initial differences. Constraints. To avoid introducing new ambiguities, the field sequence number... As a unique index, it is stipulated that the initial value of the vehicle's health status and the estimated value of the cloud-based health status must correspond one-to-one in terms of field sequence number to ensure that no field mismatch occurs in subsequent calculations. Initial difference definition:

[0102]

[0103] Where: initial difference : No. The initial difference of each health field takes the value of a real number, and its boundary is constrained by the physical range of the field and the feasible region of the initial estimate on the vehicle side. It is used to express the estimation deviation between the cloud and the vehicle side on this field.

[0104] Cloud-based estimates : No. The cloud-based health status estimates for each health field, with their ranges determined by the field's physical boundaries, are derived from the cloud-based estimation output in step one; vehicle-side estimates. : No. The initial values ​​of the vehicle health status for each health field are determined by the physical boundaries of the fields and are derived from the initial vehicle health estimate output in step one.

[0105] Health field serial number The sequence number of the health field, with a value range of [value range missing]. to The sorting is consistent with the fixed sorting of the field set in step one.

[0106] After obtaining the initial difference, the cloud does not directly... Instead of issuing suggested corrections, a cost function is constructed to calculate the confidence level dimension by dimension. Control output variation The cost function is included in the solution along with the risk cost term. A preferred form of the cost function is:

[0107]

[0108] Where: cost function : The cost function used to solve for the proposed correction amount, with values ​​ranging from non-negative real numbers, is used to comprehensively balance three objectives: approximating the initial difference, controlling output smoothness, risk, and cost constraints; correction vector : A vector composed of suggested corrections for each field, with the following components: The range of values ​​for each component is constrained by the field's physical boundaries, maximum step size, and maximum rate of change.

[0109] Field Correction : No. The suggested correction values ​​for each health field are real numbers, and the execution boundaries are determined by the effective policies allowed by the vehicle and the field safety boundary constraints; Dimensional confidence. : No. The confidence level of each health field is [value]. Based on the residual energy ratio of step one Compared to the complete segment The calculated field-level weights are used to approximate the initial difference term;

[0110] initial difference Same as above, used for terms that are close to the target term;

[0111] Trade-off coefficient The tradeoff coefficient for the control output smoothing term is a positive real number, used to adjust the constraint of control output changes on the cost function; the amount of control output change... : No. The range of changes in key control output indicators is calculated from the control configuration template and from the sensitivity relationship.

[0112] Control output sequence number The key control output indicators are numbered from 1 to... Control the number of outputs The number of key control output indicators takes positive integer values. Trade-off coefficients. The risk cost tradeoff coefficient is a positive real number, used to control the cumulative impact of proposed corrections and suppress short-cycle switching; scale parameter : No. The scale parameter of each field takes a positive real number and is used to characterize the soft boundary of the acceptable correction range of the field. The scale parameter is preset according to the field's physical unit, field's influence range and maintenance window strategy or selected by vehicle model platform.

[0113] For each field Define the maximum step size of the field. With the maximum rate of change of the field (All configured by the platform and written into the command package), and the duration of the valid command window is set to [duration missing]. Then, when solving in the cloud, the following amplitude constraint is applied: Rate constraints: Ultimately, both constraints are applied.

[0114] The cloud platform does not directly output abstract parking execution, but instead outputs a combination of determinable operating conditions, such as: vehicle speed is zero, charging connection status is connected or maintenance power connection, gear is parked, and boundary event flag is in non-emergency protection state. These operating condition combinations are fixed by field version numbers and can be directly determined by the vehicle.

[0115] The first term of the cost function is Weight constraints Close This makes high-confidence fields in the cloud more likely to be aligned with cloud estimates; the second item is achieved through... The changes in control output caused by health field corrections are explicitly incorporated, constraining the cost function to variations in power limits, display baselines, and threshold boundaries. The third term uses a saturation-type exponential penalty to characterize risk costs, preventing excessive accumulation of corrections within short periods or unnecessary large changes in low-confidence fields. During cost function solving, the cloud also applies hard constraints to conform to the vehicle-side executable boundaries. These hard constraints include the field's physical feasible region, maximum field step size, and maximum field change rate. Furthermore, constraints on fields that are only allowed to execute within the recommended operating condition window can be written into the solution boundaries.

[0116] In the cloud, sequential quadratic programming solvers, projective gradient methods, or constrained coordinate descent methods can be used to solve the problem. Take the smallest When a linear sensitivity relationship is adopted and the risk cost term is locally approximated as quadratic, a quadratic programming solver can be used to execute the solution with a fixed number of iterations, thereby ensuring that the solution process is reproducible and easy to audit.

[0117] Cloud-based dimensional confidence As the proximity term weight, the change in control output is calculated based on the sensitivity relationship. As a smoothing constraint, and using a saturation-type penalty to construct the risk cost term, the proposed correction amount that satisfies the hard constraint is obtained by solving. .

[0118] When used, the confidence level is directly converted into field-level weights, making high-confidence fields more trustworthy and low-confidence fields more suppressed; the change in control output is explicitly included in the solution, so that the suggested correction amount naturally tends to reduce the abrupt changes in power limits and threshold boundaries; the cumulative effect of the correction magnitude is limited by saturation-type penalty, providing a more stable input for subsequent hierarchical execution and rollback monitoring.

[0119] The proposed correction values ​​are transformed into actionable correction instruction packages that can be executed on the vehicle side, while also enabling rollback and auditability. The cloud not only writes the proposed correction values ​​themselves but also the execution boundaries and interpretation criteria. The vehicle side does not need to re-evaluate the cloud's intent to satisfy the shadow verification and smooth implementation in step three. This includes at least four categories: first, the proposed correction values ​​and field numbers for health fields, requiring the field numbers to match the field set in step one; second, the recommended operating condition window and validity period, which the vehicle side uses to determine execution based on the current operating condition and lifecycle stage; third, the maximum step size and maximum change rate of the field, providing clear boundaries for smooth integration on the vehicle side; and fourth, verification and traceability information, including field version numbers, data fragment indexes, restriction source identifiers, and instruction version numbers, allowing the vehicle side to restore to the same baseline during rollback.

[0120] To ensure that the instruction packets can be interpreted by the vehicle, gating instructions must also be written to the cloud. This means that for low-confidence fields, instructions should be given to either record the action without execution or postpone execution until the maintenance window. This allows the vehicle to filter out field corrections that should not be triggered in the current operating condition before shadow verification. The gating instructions are based on a one-dimensional confidence level. Based on this, its threshold is not expressed as a fixed constant, but rather as a field scale parameter. Trade-off coefficient with risk cost The combination rules ensure consistency in gating across different vehicle models, platforms, and field units. After being distributed from the cloud, a mirror record of the instruction is simultaneously written to the cloud-based health record. This mirror record includes a full-text summary of the instruction package and an index of the sensitivity coefficients used for solving, facilitating post-implementation auditing and review.

[0121] The cloud will encapsulate the suggested correction amount, recommended operating condition window, validity period, maximum field step size, maximum field change rate, field version number, data fragment index, and restriction source identifier into a correction instruction package and issue it. At the same time, the cloud health record will write the instruction mirror record for auditing.

[0122] When used, the instruction package carries a complete interpretation and execution boundary, so that the vehicle-side execution phase does not need to reverse-engineer the cloud-based solution context; the recommended operating condition window and gating instructions together limit unsuitable execution times, providing a direct basis for the operating condition classification and shadow verification in step three; the instruction mirror record enables the cloud to review when it was issued, based on which sensitivity coefficient, and corresponding to which data segment, thereby supporting traceability and re-solution after rollback.

[0123] Step 3: Package the correction instructions issued by the cloud and execute them on the vehicle according to the working conditions. First, use shadow verification to screen out candidate corrections that may cause sudden changes in control output. Then, smoothly implement the corrections within the allowable boundaries and complete the linkage update. Finally, use verification window monitoring and rollback to solidify the new baseline or restore the old baseline.

[0124] The correction instruction package contains suggested correction amounts for multiple health fields. Its consequential impact on the maximum charge limit, maximum discharge limit, alarm and protection trigger thresholds, and instrument display references carries different risks at different times. If it takes effect directly during driving, high-rate discharge, or rapid temperature changes, it can easily amplify the control output changes already constrained in step two.

[0125] Therefore, the vehicle's operating condition and life cycle stage are first identified, and the correction instructions are gating and graded accordingly. Then, the control effects of candidate corrections are pre-rehearsed in the shadow verification channel using the same control configuration template to ensure that corrections that take effect smoothly come only from an acceptable set of candidates.

[0126] The vehicle-side system uses the recommended operating condition window and validity period within the instruction package from step two as its external boundaries. Based on data collected by the vehicle-side, including vehicle speed, gear position, charging connection status, braking status, thermal management operation status, and alarm event records, it first generates operating condition tags and lifecycle stage tags. Therefore, the vehicle-side system can process each field... The decision is made to immediately enter shadow verification, enter the execution queue, and only record without execution. Subsequently, the vehicle-side system maps candidate corrections to candidate control parameters within the shadow verification channel, and sequentially deduces the change trajectories of the state of charge display, power limit curve, thermal management threshold, and alarm threshold, thereby filtering out candidate corrections that may cause sudden jumps or rate overruns.

[0127] Using the correction instruction package as the sole terminology input, it is explicitly stated that the vehicle-side is only allowed to enter the execution chain when the field version numbers are consistent, thereby avoiding the use of different field version numbers. It was misinterpreted.

[0128] The vehicle first reads the version number of the field in the instruction packet and compares it with the local field version number. If they match, it continues. Next, it reads the recommended operating condition window and validity period from the instruction packet, matching the current operating condition label with the recommended operating condition window. This ensures that gating actions are based on the execution boundaries explicitly written in the instruction packet, rather than relying on ad-hoc inferences from the vehicle. Subsequently, the vehicle uses a step-by-step confidence level... With the suggested revision amount Field-level gating is achieved through combination relationships: when a field is gated based on dimension-wise confidence... Significantly low and We have now entered step two, the cost function, and the scaling parameter. When the corresponding risk-sensitive interval is reached, the vehicle-side will mark this field as only recording and not executing; the end-user will then base its decision on the confidence level. When the recommended operating condition window matches the higher value, the vehicle terminal marks the field to enter shadow verification; when the recommended operating condition window does not match but the validity period has not expired, the vehicle terminal writes the field to the execution queue, and at the same time writes the maximum step size and the maximum change rate of the field, so that the instruction packet does not need to be parsed again when it takes effect smoothly in the future.

[0129] During queued writing, the vehicle-side component writes the restriction source identifier and field sequence number together, enabling subsequent execution chains to identify which individual restriction unit or module identifier the field correction is associated with. This allows for targeted checks of voltage and temperature boundaries near the restriction source during shadow verification and linked update phases. Simultaneously, the vehicle-side component writes the instruction version number to the head of the execution queue, ensuring that only the latest version of the same field is retained in the queue, avoiding switching jitter caused by multiple versions of the same field existing concurrently.

[0130] Assuming the version numbers in the vehicle-side fields are consistent, the recommended operating condition window, validity period, and dimension-by-dimensional confidence level are considered. Suggested correction amount With scale parameters The combined gating rules categorize each field into entering shadow verification, entering the execution queue, and recording without execution. The maximum step size, maximum change rate, source identifier, and instruction version number of the field are fixed in the queue records.

[0131] When in use, cloud-based instruction packages are broken down into executable categories, so driving conditions do not need to be affected by the size adjustment of the maintenance window; the source identifier is restricted to be bound to the queue record, and the boundary-sensitive areas can be selected during subsequent verification and monitoring; the single-version queue rule of the same field suppresses the superposition of instructions, providing stable input for smooth subsequent effects.

[0132] Using "shadow verification channel" as the sole term, it is clearly defined that it does not change the current control output of the vehicle, but only calculates candidate control parameters and deduces the control output change trajectory within an independent virtual control channel. The vehicle reads data from the set of fields marked as entering shadow verification. And based on the maximum step size and maximum change rate of the field written in the instruction packet, Pre-pruning is performed to ensure that the shadow verification input is consistent with the subsequent smoothing input. Then, the vehicle-side maps the candidate correction to candidate control parameters. The mapping process strictly uses the currently enabled control configuration template and the caliber information in the instruction package of step two to ensure that the inference results of shadow verification are consistent with the actual activation logic.

[0133] The shadow verification process employs a fixed-window forward inference method: the vehicle selects the operating condition segment corresponding to the most recent data segment index as the boundary condition, and reconstructs the current, voltage, and temperature trajectories within this operating condition segment into continuous inputs using spline interpolation, thus advancing within the shadow verification channel at fixed step sizes. During this advancement, the vehicle's parallel computing instruments display the trajectory of changes in state of charge or driving range, the trajectory of changes in maximum charging and maximum discharging limits, the switching points of thermal management thresholds, and the triggering status of alarm and protection thresholds. The shadow verification channel checks three types of constraints within each advancement step: firstly, display continuity constraints, requiring that the display reference does not exhibit a step jump within the window; secondly, boundary rate constraints, requiring that the power limit and threshold switching do not exceed the rate limit; and thirdly, safety approximation constraints, requiring that the predicted voltage and temperature values ​​near the limit unit identifier or limit module identifier corresponding to the limit source identifier do not suddenly approach the safety boundary.

[0134] When shadow verification fails, the vehicle executes a degradation strategy. This strategy follows a fixed priority path to prevent inconsistent behavior across different vehicles. The priority path is as follows: first, narrow down the fields that trigger the risk. The range is adjusted to the next step value allowed by the maximum step size of the field; if it still fails, the field is moved to the execution queue; if it still fails and the field belongs to internal resistance or power health, thermal safety health or consistency health, the field is changed to record only and not executed, and the shadow verification failure reason code is written in the instruction mirror record so that the cloud can review it when updating the sensitivity relationship later.

[0135] While driving on an urban elevated highway, the vehicle receives a correction command packet. The vehicle identifies the current operating condition as a driving condition with significant current fluctuations. Therefore, it marks the capacity health and available energy fields as entering shadow verification, and the internal resistance or power health fields as entering the execution queue. The shadow verification channel uses the most recent constant-speed driving data segment as boundary conditions to extrapolate changes in the baseline and power limits. It finds that candidate corrections to the capacity health field cause a step change in the instrument's remaining driving range. Therefore, the vehicle adopts a degradation strategy to remove this field. The value is narrowed down to the next tier and recalculated. Only after the recalculation is successful can the smoothing process be allowed to take effect. After the vehicle arrives at the service area and parks, the vehicle-side identification condition is switched to the parking condition. Then, the internal resistance or power health field is retrieved from the pending execution queue and entered into shadow verification. After the shadow verification is successful, it is included in the subsequent smoothing effect queue, thereby completing the tiered implementation in different operating condition windows.

[0136] The vehicle-side uses a separate shadow verification channel with pre-cropped data. Using the control configuration template as the input and the fixed window forward deduction as the verification method, the system checks three types of constraints: continuity, boundary rate, and safe approximation. If a constraint fails, the system will reduce the link size, delay, or prohibit execution according to a fixed priority, and the reason code will be recorded.

[0137] In practice, shadow verification removes high-risk candidate corrections without altering the control output, thus providing greater control over subsequent smooth-effect inputs. Shadow verification's degradation is executed on a fixed priority path, and different vehicles handle the same failure reason consistently. Shadow verification references the restriction source identifier, performing a check on the restriction source, which is exposed and processed before execution.

[0138] While the selected candidate corrections are executable, they may still cause slow drift or asymptotic boundary issues during the activation process. Therefore, it's necessary to decompose the correction action into controllable steps during the activation phase and simultaneously update the control configuration template coupled with the health field. This prevents discrepancies such as health fields changing while control parameters remain unchanged, or control parameters changing while the display baseline is misaligned. Furthermore, any health correction needs to be verified by operational facts within a verification window. Therefore, verification window monitoring and rollback are introduced to ensure that correction results can be solidified or revoked, maintaining a consistent traceability chain.

[0139] The vehicle-side application, based on the maximum step size and maximum change rate of the fields in the instruction packet, applies the shadow verification passed fields in periodic segments, enabling... The system gradually enters the effective state; then, based on changes in capacity health, internal resistance or power health, thermal safety health, and consistency health, the vehicle-side synchronously updates the maximum charging limit, maximum discharging limit, thermal management threshold, equalization strategy, and alarm protection threshold according to the smooth migration rules of the control configuration template; subsequently, the vehicle-side reuses the residual energy ratio from step one within the verification window. The method quantifies and monitors multidimensional residuals, identifies key monitoring points by limiting sources, and finally solidifies new baselines or rolls back old baselines based on monitoring results and reports anomalies.

[0140] Control configuration template interpolation migration refers to: for any control parameter Let the current template value be... The target template value is Define the migration factor:

[0141]

[0142] The migration is then:

[0143]

[0144] This method synchronizes the progress of control parameter migration with the progress of field corrections.

[0145] in, This represents the remaining correction amount of field k, used to characterize the portion of the suggested correction amount that has not yet taken effect during the smooth fusion process; at the start of smooth fusion, the remaining correction amount of field k is taken as the suggested correction amount;

[0146] Within each control cycle, the vehicle determines the write increment for this cycle based on the maximum step size and the maximum rate of change, and subtracts the write increment from the remaining correction amount to obtain the remaining correction amount for the next control cycle; when the absolute value of the remaining correction amount is not greater than the preset completion threshold, the smooth fusion of field k is determined to be completed and writing to field k is stopped.

[0147] Using "smooth activation queue" as the sole term, its input is explicitly stated to be the set of fields that have passed shadow verification, and its output is the progressive changes of vehicle health fields over multiple control cycles and the progressive migration of the corresponding control configuration templates. The vehicle reads from the set of fields that have passed shadow verification. The allowable increment for each control cycle is determined by the maximum step size and maximum rate of change of each field, ensuring that no field will experience boundary jumps during execution. To avoid the difficulty in interpreting the linkage caused by multiple fields changing simultaneously within the same cycle, the smoothing effect queue adopts a constraint source priority ordering: when the constraint source identifier points to the same constraint unit identifier or constraint module identifier, the fields associated with that constraint source are executed first, allowing the fields most sensitive to the control boundary to stabilize first, and then the fields that have a more significant impact on the display benchmark and energy estimation are executed.

[0148] At the control linkage level, control configuration template migration is treated as part of a smooth activation process, rather than a reactive patch. The vehicle-side system starts with the current control configuration template, updating the rated capacity and energy estimation baseline based on changes in capacity health, updating the maximum charging and maximum discharging limit curves based on changes in internal resistance or power health, updating the thermal management target temperature and start-stop thresholds based on changes in thermal safety health, and updating the balancing strategy and warning thresholds based on changes in consistency health. Template migration does not employ a one-time switch but rather a piecewise interpolation migration: key parameters of the current and target templates are interpolated and transitioned using the same control cycle. The interpolation step size of each parameter is driven by the smooth activation increment of its associated fields, ensuring that control parameters migrate to the same location as health field changes. The interpolation method can be monotonic cubic spline interpolation or piecewise linear interpolation, with monotonicity constraints used to prevent non-physical oscillations in the power limit curve.

[0149] The vehicle-side application is segmented based on the maximum step size and maximum rate of change of the field. The system organizes a smooth activation queue according to the priority of the restriction source identifier, and simultaneously migrates the maximum charging limit, maximum discharging limit, thermal management threshold, balancing strategy and alarm protection threshold in a segmented interpolation manner using the control configuration template, so that the linkage update and field activation keep the same rhythm.

[0150] When in use, segmented application gives the correction process an interpretable step size boundary, avoiding abrupt changes caused by a one-time effect; template migration and field effect are carried out in sync, eliminating the source of breakage caused by the asynchrony between health fields and control parameter caliber; limiting the source priority order allows the fields most sensitive to control boundaries to stabilize first, thereby reducing the cumulative impact of subsequent field effects on the boundary.

[0151] Using "verification window" as the sole term, the starting point of the verification window is defined as the moment when a certain field begins to enter the smoothing activation queue, and the ending point is the moment when the field completes the smoothing activation and experiences the preset running segment.

[0152] The vehicle-side does not rely on subjective threshold stacking within the verification window, but reuses the residual energy ratio already disclosed in step one. The calculation method normalizes the energy of the multidimensional residuals within a window, thus enabling a unified comparison of residuals under different field units and operating conditions. The vehicle-side constructs a residual function within each verification window. With observation function The residual function represents the difference between the predicted output after smoothing and the field observation, while the observation function represents the baseline quantity observed in the field. Higher monitoring priority is assigned to voltage and temperature channels near the limiting unit or module identifiers pointed to by the limiting source identifier, making the rollback trigger closer to the control boundary formation mechanism. The residual energy ratio is calculated and reused in the following form:

[0153]

[0154] Where: residual energy ratio Field serial number The percentage of residual energy within the validation window, taking the value... This is used to quantify the cumulative intensity of the deviation after execution and as a basis for triggering rollback;

[0155] residual function Field serial number In time The residuals, whose range is determined by the physical boundaries of the fields, are constructed by subtracting the field observation output from the model's predicted output after smoothing takes effect; the observation function Field serial number In time The observation benchmark, whose value range is determined by the physical boundaries of the field, is constructed from field observation output or vehicle-end benchmark output after standardization; the starting point of the time window. : The start time of the verification window, a real number on the timeline; the end time of the time window. The verification window's end time is a real number on the timeline, satisfying the following conditions: ; Zero constant : To prevent the denominator from being zero, the value of the constant is determined. Used to ensure numerical stability; field sequence number Health field serial number, with values ​​ranging from 1 to... The sorting is consistent with the fixed sorting of the field set in step one.

[0156] The vehicle-side integration is performed using a sampling sequence, employing trapezoidal quadrature and outlier markers as a mask to avoid outlier pairings. Non-physical amplification; when there is a sampling discontinuity within the verification window, first reconstruct the continuous sequence according to the slope of step one while maintaining the interpolation rule, and then perform the product.

[0157] For rollback triggering, no new opacity rules are introduced. Instead, rollback triggering is linked to the maximum change rate of the field, the maximum step size of the field, and the shadow verification reason code written in the step two instruction package: when a field is within the verification window... When the deviation continues and matches the risk type indicated by the shadow verification reason code, the vehicle immediately performs a rollback operation. The rollback operation includes restoring the field to the initial value of the vehicle's health status before the smoothing took effect. Restore the corresponding control configuration template to the template before migration, clear the remaining increment of this field in the smoothing effect queue, and write the rollback event to the event log and associate it with the instruction version number.

[0158] After the rollback, the vehicle will report the anomaly to the cloud. The report will include the instruction version number, data fragment index, restricted source identifier, shadow verification reason code, and verification window residual energy ratio. This aggregated value allows the cloud to have a traceable basis when subsequently updating the sensitivity coefficient index and cost function tradeoff coefficients.

[0159] The vehicle-side reuses the residual energy ratio within the verification window. Formal quantification of multidimensional residuals, combined with the maximum step size of the field, the maximum rate of change of the field, and the shadow verification reason code to form a rollback trigger chain, which restores the initial value of the vehicle's health status once triggered. With the control configuration template, and restrict the source identifier, instruction version number, data fragment index and The summarized records are reported to the cloud.

[0160] When used, the residual energy ratio The cumulative deviation after execution is quantified into a unified scale, which facilitates consistent rollback judgment across fields and operating conditions; the rollback operation restores the health field and control configuration template at the same time, avoiding new breaks in the caliber caused by only rolling back the field while the control remains in the transition state.

[0161] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0162] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0163] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0164] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0165] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A cloud-edge collaborative power battery full-life cycle health state online correction method, characterized in that: Comprise, Define cloud-to-vehicle multi-dimensional health status parameter group, map and record the identification information of the limiting monomer or limiting module at the monomer layer to the whole package layer; the vehicle end gets the initial value of the vehicle end health status, and the cloud end gets the estimated value of the cloud end health status and the confidence degree of each dimension based on the whole life cycle data; wherein, in the monomer layer, each field is weighted and divided into a module layer field according to the monomer weight coefficient, and in the module layer, each module layer field is aggregated according to the same caliber to obtain a whole package layer field, and the identification information of the limiting monomer or limiting module is generated and inherited at each aggregation, so that the whole package layer field corresponds to the identification information one by one; the edge side device performs timestamp alignment, missing and abnormal point marking, limit slope interpolation and working condition label labeling on the vehicle end sampling sequence, cuts the data segment index according to the start and end time, and uploads the data segment index, field version number and identification information of the limiting monomer or limiting module to the cloud end battery management platform together with the initial value of the vehicle end health status; the cloud end battery management platform calculates the residual energy ratio and the complete segment ratio based on the data segment index, and generates the confidence degree of each dimension according to the calculation results; the complete segment ratio is determined according to the coverage ratio of the effective data segment in the preset time window, and the residual energy ratio is determined according to the energy normalization of the difference sequence between the cloud prediction output and the segment observation benchmark in the time window; The cloud end defines key control output indicators and establishes control output sensitivity relationship; according to the initial value of the vehicle end health status, the estimated value of the cloud end health status and the confidence degree of each dimension, the risk cost constraint is solved to generate a correction instruction package containing the recommended working condition window, the maximum step and the maximum change rate, and is issued; wherein, the key control output indicators include the maximum charging limit, the maximum discharging limit, the instrument display state of charge, the thermal management target temperature and the start-stop threshold, the alarm and protection trigger threshold; the control output sensitivity relationship is obtained by applying disturbance to each dimension of the multi-dimensional health status parameter group and recalculating the key control output indicators under the same field version number and working condition label, and is stored according to the temperature interval, the rate interval and the vehicle platform; After receiving the correction instruction package, the vehicle end identifies the working condition and gates the recommended correction amount according to the recommended working condition window; after the shadow verification of the candidate correction is passed, the parameters are smoothly fused and linked to update under the constraints of the maximum step and the maximum change rate; monitor the deviation and safety events in the verification window, and roll back abnormally and report; wherein, when solving the recommended correction amount, the cloud end battery management platform sets a weight corresponding to the confidence degree of each dimension; and applies penalty constraints to the correction frequency, correction amplitude and correctable dimensions, while constraining the change amplitude and change rate of the key control output indicators by the control output sensitivity relationship, and outputs the solving results containing the recommended correction amount of each dimension and the recommended working condition window.

2. The power battery whole life cycle health status online correction method according to claim 1, wherein: The multi-dimensional health status parameter group includes state of charge, capacity health, internal resistance or power health, available power capability, available energy capability, thermal safety health, consistency health, and further includes fast charging proportion, deep discharge event number, cumulative cycle and temperature exposure statistics, and overvoltage, overcurrent and overtemperature risk levels, life degradation risk level, and thermal runaway risk level.

3. The method of claim 2, wherein the method further comprises: The correction instruction package further comprises a valid period, an instruction version number, a field version number, a data segment index, and identification information of a limited cell or a limited module, and writes a record-only-not-execution mark for a dimension with a confidence level lower than a preset threshold; and the vehicle-side record-only-not-execution mark excludes the corresponding dimension from shadow verification and smoothing fusion.

4. The method of claim 3, wherein the method further comprises: The shadow verification comprises: the vehicle side generates a candidate health status based on the recommended correction amount and maps to obtain a candidate control parameter, uses a recent typical working condition segment to replay and deduce a key control output index sequence, checks the continuity, the power limit change rate, and the voltage and temperature boundaries corresponding to the identification information of the limited cell or the limited module; and when the checks fail, sequentially performs a step of reducing the candidate correction amplitude, a step of switching to a to-be-executed queue, and a step of changing to a record-only-not-execution mode.

5. The method of claim 4, wherein the method further comprises: The smoothing fusion segments the recommended correction amount according to a maximum step and a maximum change rate, writes the recommended correction amount into a vehicle-side health status initial value, and simultaneously performs template migration of control linkage update parameters; The vehicle side monitors deviation based on residual energy ratio in a verification window and records a safety event, and when the deviation exceeds a preset threshold, rolls back to a health status and control configuration before correction, and reports an instruction version number and an exception record.

Images