A BMS simulation verification method and platform based on fault injection closed-loop joint debugging

Abstract

The present application relates to the technical field of energy storage system, and particularly to a BMS simulation verification method and platform based on fault injection closed-loop joint debugging.A BMS simulation verification method and platform based on fault injection closed-loop joint debugging, the platform comprises the following: a model management layer; a scene generation and scheduling layer; a fault injection layer; a closed-loop joint debugging layer; a result collection and evaluation layer; a report generation and backfilling layer.Compared with the prior art, through the combination of the model library, the scene library and the fault injection library, the virtual BMS is quickly verified under different objects, different working conditions and different fault types; through the closed-loop joint debugging between the battery model, the thermal management model, the actuator model and the communication model, the closeness of the verification result to the real system is improved; through a unified coverage, response quality and protection effect evaluation mechanism, the comparability and screening efficiency between different verification tasks are improved.

Description

Technical Field

[0001] This invention relates to the field of energy storage system technology, specifically a BMS simulation verification method and platform based on fault injection closed-loop joint commissioning. Background Technology

[0002] During the development and operation of energy storage systems, BMS algorithms typically need to be fully validated under different battery cluster models, different ambient temperatures, different charging and discharging conditions, and different fault scenarios to ensure the reliability of SOC estimation, SOH assessment, equalization control, thermal management linkage, and protection logic.

[0003] Existing verification methods mostly rely on physical prototype benches, manually constructed test procedures, or partial offline data playback. These methods have high testing costs, limited scenario coverage, and difficulty in simultaneously covering extreme operating conditions, complex faults, and cross-system linkage situations.

[0004] As the scale and functional complexity of energy storage systems increase, it is difficult to fully assess the BMS's response capabilities to time-series changes, sensor malfunctions, actuator lags, and communication malfunctions before the algorithm goes live, simply by relying on static data playback or single-device testing. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this invention provides a BMS simulation verification method and platform based on fault injection closed-loop joint debugging. By combining model libraries, scenario libraries, and fault injection libraries, it enables rapid verification of virtual BMS under different objects, operating conditions, and fault types. Closed-loop joint debugging between battery models, thermal management models, actuator models, and communication models improves the closeness of verification results to the real system. A unified evaluation mechanism for coverage, response quality, and protection effectiveness enhances the comparability and screening efficiency between different verification tasks. A mechanism for feeding back problem parameters and suggested results forms a continuous iterative closed loop of "simulation verification—problem identification—parameter revision—re-verification."

[0006] To achieve the above objectives, a BMS simulation verification method and platform based on fault injection closed-loop joint debugging are designed, characterized in that the platform includes the following:

[0007] Model management layer: includes battery cluster maintenance model, thermal management model, balancing execution model, contactor and protection execution model, communication link model and environmental model;

[0008] Scene generation and scheduling layer: Generates verification scenes based on working condition templates, environmental parameters, load curves and fault templates, and schedules the execution order and duration of the scenes;

[0009] Fault injection layer: Performs controlled injection for events such as sensor drift, sensor loss, actuator jamming, communication delay, individual unit mismatch, local thermal abnormality, and protection failure;

[0010] Closed-loop integration layer: Outputs the estimation results, balancing commands, current limiting commands, thermal management linkage commands and protection actions of the virtual BMS to each simulation model, and returns the feedback results to the BMS;

[0011] Results Acquisition and Evaluation Layer: Conducts a unified evaluation of scene coverage, state estimation error, control response time, effectiveness of protection actions, and recovery stability;

[0012] Report generation and backfeeding layer: Generates validation reports, issue lists, parameter revision suggestions, and regression validation plans, and feeds key results back to the BMS parameter library or algorithm version library;

[0013] The BMS simulation verification method flow is as follows:

[0014] S1, Loading the Model Library: After the platform starts, it first reads all the simulation models required by the target verification object from the model management layer, including the battery cluster model, thermal management model, equalization execution model, contactor and protection execution model, communication link model, and environmental model. After loading, the platform verifies the model interface mapping relationship one by one to confirm that the voltage, current, and temperature ports of the battery model are correctly connected to the corresponding ports of the thermal management model and the actuator model. S2, Loading the BMS Test Object: The platform imports the BMS algorithm modules to be verified, including the SOC estimation module, SOH evaluation module, equalization control module, current limiting protection module, and thermal management linkage module. At the same time, it reads the BMS configuration parameter table, including the protection thresholds at all levels, equalization trigger conditions, and version identifier. The platform initializes the internal state of the BMS, setting the initial SOC value, initial SOH value, equalization status flag, and protection status flag to the default values. If there are historical version regression baseline parameters, the baseline parameters are loaded synchronously for subsequent comparison.

[0015] S3, Generate Verification Scenarios: Based on the working condition templates and fault templates of the scenario generation module, automatically generate a set of verification scenarios covering multiple dimensions;

[0016] S4, Configure Fault Injection Plan: For each fault scenario, the fault injection layer reads the fault template and configures the injection parameters.

[0017] S5, Initialize closed-loop simulation state: Align all simulation models and BMS internal states to a unified initial time.

[0018] S6, Perform time-step simulation: using discrete time steps As the unit of advancement, the state of each model is updated in a prescribed order at each time step k;

[0019] S7, Execute BMS decision output: After receiving the state input at the current time step, BMS executes calculations sequentially according to its internal algorithm logic;

[0020] S8, Write-back Output: Feed back the various control commands output by the BMS in step 7 to the corresponding simulation model to form a closed loop. After the write-back is completed, each simulation model will recalculate the state based on the updated control commands in the next time step, thus forming a closed-loop joint debugging where the BMS output affects the platform state and the platform state is fed back to the BMS.

[0021] S9, Injecting Fault Events: During the simulation, the fault injection layer continuously monitors whether the current time step k reaches the preset fault triggering condition and performs fault injection in accordance with the prescribed method. The platform continuously records the key state variables at each time before, during and after fault injection for subsequent evaluation.

[0022] S10, Collect and verify results: In each simulation time step, the result acquisition layer records state estimation data, control response data, protection action data, and anomaly statistics.

[0023] S11, Perform scenario-level assessment: For each completed scenario s, the assessment layer calculates the response quality score and protection effectiveness score respectively;

[0024] S12, Perform version-level evaluation: After all scenarios have been executed, the scenario-level results of all scenarios are weighted and summarized to form a comprehensive version score. At the same time, a problem list is generated, recording the fault type, failure reason and parameters involved in each failure scenario.

[0025] S13, Report Generation and Regression Suggestions: The report generation layer outputs a verification report, a list of failure scenarios, parameter revision suggestions, and regression verification suggestions based on the version comprehensive score and issue list;

[0026] S14, write back parameters and arrange regression verification: The management team will convert the revision suggestions in the report into specific parameter update operations. After the backfeed is completed, the platform will automatically write the revised parameters into the BMS parameter library or algorithm version library and schedule the next round of regression verification tasks. Starting from S3, the affected scenarios will be re-executed to form a continuous iterative closed loop of "simulation verification - problem identification - parameter revision - re-verification".

[0027] In step S1, for the battery cluster model, the platform reads the equivalent circuit parameters of the individual battery cells, including the open-circuit voltage curve U. ocv (SOC), internal resistance R0, polarization resistance R p and polarization capacitor C p The terminal voltage of a single battery cell is calculated using the following equivalent circuit equation: U cell,k =U ocv(SOC k )-I k ·R0-U p,k Among them, U cell,k U represents the terminal voltage of a single battery cell at the k-th simulation time step, in V. ocv (SOC k ) represents the open-circuit voltage corresponding to the SOC state, in V; I k U is the current at the k-th time step, negative for charging and positive for discharging, in A; R0 is the internal resistance in ohms, in Ω; U p,k Polarization voltage, in volts (V).

[0028] The polarization voltage is updated according to the following first-order RC recursion: ;in, The polarization voltage of the previous time step, in V; Polarization resistance, unit: Ω; Polarization capacitance, unit F; The simulation time step is expressed in seconds (s).

[0029] In step S2, the protection threshold at each level is the overvoltage V. ov Undervoltage V uv Overheating T ot Overcurrent I oc The equilibrium trigger condition is the single-cell pressure difference threshold ΔV. bal .

[0030] In step S3, the scene generation process includes a combination of the following three types of scenes:

[0031] S31, Normal Operating Conditions: Covers constant current charging and discharging, stepped power variation, dynamic load following, and static recovery conditions. Each normal scenario defines a current sequence using a load curve template. Duration sequence and ambient temperature setting ;

[0032] S32, Boundary Operating Condition Scenarios: Covering high-rate charge / discharge (≥1C), low-temperature start-up ( ≤-10℃), high temperature operation ( Extreme conditions such as ≥45℃ and recovery after deep discharge;

[0033] S33, Fault Condition Scenario: The fault type (sensor drift, sensor loss, actuator jamming, communication delay, individual unit mismatch, local thermal anomaly) and triggering time are specified by the fault template.

[0034] The generated scene set is used for coverage evaluation using the scene coverage formula: ;in, Let be the coverage of the s-th scene; The number of working condition categories covered by scenario s; This represents the total number of preset operating condition categories; The number of environment categories covered by scene s; The total number of preset environment categories; The number of fault categories covered by scenario s; The total number of preset fault categories; The number of object categories covered by scene s; The total number of preset object categories; , , , For coverage weighting coefficients, satisfying + + + =1; The scene scheduler arranges the scene execution order according to priority, and prioritizes the execution of scene combinations with lower coverage.

[0035] In step S4, the injection of each type of fault includes the following elements:

[0036] S41, Sensor Drift: Set drift direction and drift amplitude Drift start time and duration ;

[0037] S42, Sensor Loss: Set the start time of loss, duration of loss, and default replacement value after loss;

[0038] S43, Actuator Stuck: Set the stuck object, stuck state and stuck duration;

[0039] S44, Communication Delay: Set the delay amount, delay start time, and affected communication channels;

[0040] S45, Cell Mismatch: Set the abnormal cell number, capacity deviation percentage and internal resistance deviation percentage;

[0041] S46, Localized Thermal Anomaly: Sets the location of the thermal anomaly, the additional heating power, and the duration;

[0042] The injection intensity for each type of fault is quantified using the following formula: ;in, Let f be the injection intensity of the type f fault in scenario s; This represents the fault offset magnitude. This serves as the reference offset amplitude for this type of fault; The duration of the fault is expressed in seconds (s). The reference duration for this type of fault, in seconds; This refers to the number of combinations that can be simultaneously superimposed with other faults. , , The fault intensity weighting coefficient is preset by the fault template.

[0043] In step S5, the specific initialization content includes:

[0044] S51, Battery Cluster Model: Setting the Initial SOC Value for Each Individual Cell Initial temperature Initial polarization voltage =0;

[0045] S52, Thermal Management Model: Sets the initial coolant temperature Initial flow and ambient temperature ;

[0046] S53, Actuator Model: Set the initial state of the equalizer switch and the initial state of the contactor;

[0047] S54, Communication Model: Set the initial value of communication delay to zero and the initial value of data packet loss rate to zero;

[0048] S55, BMS internal state: Set initial SOC estimation value Initial value of SOH estimation The protection status indicator is "normal".

[0049] In step S6, the model states are updated in the following order at each time step k:

[0050] S61, Battery Model Update: Based on the current from the previous time step And control commands, update the SOC of each unit: ;in, Let i be the charge state of the i-th individual at the k-th time step; Let be the current of the i-th cell in the previous time step, in amperes (A). The nominal capacity of the i-th monomer is expressed in Ah. The simulation time step is expressed in seconds (s).

[0051] S62, Thermal Model Update: Updates cell temperature based on battery heating power and cooling power. ;in, Let be the temperature of the i-th monomer at the k-th time step, in °C; Heating power, in watts (W). Cooling power, measured in watts (W), is determined by coolant flow rate and temperature difference. This refers to the mass of a single unit, expressed in kg. Specific heat capacity, unit: J / (kg·℃);

[0052] S63, Actuator Model Update: Update the actuator state according to the equalization, current limiting and protection instructions issued by the BMS in the previous step;

[0053] S64, Communication Model Update: Apply corresponding delay and packet loss handling to the data received by the BMS according to the communication delay setting;

[0054] S65, the platform packages the current state output by each model into an input data frame for the BMS.

[0055] In step S7, after receiving the state input of the current time step, the BMS performs the following calculations sequentially according to its internal algorithm logic:

[0056] S71, SOC Calculation: The BMS uses the ampere-hour integration method combined with voltage correction to update the SOC. ;in, The SOC estimate for BMS at the k-th time step; This is the voltage correction gain coefficient; The unit voltage is the single-cell terminal voltage collected at the current time step, in volts (V). The open-circuit voltage is obtained by looking up the table based on the SOC estimated in the previous time step, in V;

[0057] S72, SOH Assessment: Upon meeting specific triggering conditions (such as completing a full charge-discharge cycle), the BMS updates the SOH based on the ratio of the actual discharge capacity to the nominal capacity. ;in, Here is the estimated SOH value at the k-th time step, in % (%). The actual released capacity, in Ah;

[0058] S73, Equilibrium Command Generation: When the maximum pressure difference between individual cells exceeds the equilibrium threshold. At that time, the BMS sends an equalization command to the cell with the largest voltage difference, and the equalization current is... ;

[0059] S74, Current Limiting Command Generation: When any single cell voltage approaches the overvoltage or undervoltage threshold, the BMS calculates the current limiting factor according to the following formula: ;in, This is the current limiting coefficient, with a value range of [0,1]. Hard protection limit, unit: V; This is the soft current limiting start-up threshold, in volts (V). The BMS outputs the current limiting coefficient to the PCS or load controller to ensure that the actual current does not exceed [the specified value]. ;

[0060] S75, Protection Action Decision: When any parameter triggers a hard protection condition, the BMS outputs a protection action command and records the protection trigger time. .

[0061] In step S8, the control commands output by the BMS in step S7 are fed back to the corresponding simulation model to form a closed loop, including the following cases:

[0062] S81, Current Distribution Writeback: Rewrite the current limiting coefficient Write back to the battery model to update the actual current for the next time step. ;in, Request current for the load;

[0063] S82, Equalization Status Write-back: Write the equalization command back to the actuator model, turn the equalization switch of the corresponding unit on or off, and update the equalization current distribution;

[0064] S83, Thermal Management Linkage Write-back: If the BMS issues a liquid cooling enhancement command, the flow rate increase command will be written back to the thermal management model, causing the coolant flow rate to increase from... Upgraded to ;

[0065] S84, Protection Action Write-back: If the BMS issues a protection command, the contactor disconnect command will be written back to the actuator model, so that the battery cluster current will drop to zero in the next time step.

[0066] S85, Communication Status Write-back: If the BMS detects a communication anomaly and switches to the backup channel, the channel switching information will be written back to the communication model.

[0067] In step S9, when the triggering condition is met, fault injection is performed as follows:

[0068] S91, Sensor Drift Injection: An offset is superimposed on the true value of the target sensor, so that the sensor value actually received by the BMS becomes... ;

[0069] S92, Sensor Loss Injection: The target sensor data is marked as invalid, and the field in the corresponding data frame received by the BMS is set to the default replacement value or NaN;

[0070] S93, Actuator Stuck Injection: Locks the state of the target actuator, preventing it from responding to BMS commands until the fault duration ends;

[0071] S94, Communication Delay Injection: Delays the data frames received by the BMS. Milliseconds cause the data processed by the BMS to lag behind the actual state;

[0072] S95, Monomer Mismatch Injection: Modify the capacity parameter of the target monomer to... The internal resistance parameter is ;in, and These are the capacity deviation rate and the internal resistance deviation rate, respectively.

[0073] S96, Localized Thermal Anomaly Injection: Adds an extra term to the heating power of the target unit. ,make .

[0074] In step S11,

[0075] Response quality score: a weighted sum of normalized estimation error, response time, false alarms, and false negatives. ;in, Let be the response quality score for scene s, with a value range of [0,1]. To estimate the error of the normalized state, normalize it according to the maximum value of all scenarios; This is the normalized average response time; The number of false alarms after normalization; This represents the normalized number of missed reports; , , , In response to the quality weighting coefficient, satisfy + + + =1;

[0076] Protection effectiveness score: ;in, Let be the protection effectiveness score for scenario s, with a value range of [0,1]. This is a protection action triggering correctness indicator; a correct trigger is 1, and a incorrect trigger is 0. To restore the accuracy of the movement; Delay in protection actions after normalization; This is a normalized residual risk indicator; , , , In response to the quality weighting coefficient, satisfy + + + =1.

[0077] In step 12, the formula for the overall version score is as follows: ;in, The overall score for the version ranges from [0,1]; S represents the total number of scenes. The coverage of scene s; The response quality score for scenario s; The protection effectiveness score for scenario s; This is a penalty term for scenario s, which takes a positive value when there are false alarms, missed alarms, or protection failures in the scenario. The weights of scenario s are: fault scenarios and boundary scenarios have higher weights than normal operating condition scenarios. , , , This is the weighting coefficient for the overall score.

[0078] In step 14, the reflow management layer translates the revision suggestions in the report into specific parameter update operations: for the p-th parameter to be revised, the reflow update relationship is: ;in, This refers to the p-th parameter after recharge; These are the original parameter values; The amount of parameter revision for simulation verification output; The parameter is the recharge coefficient, with a value range of [0,1], used to control the revision range.

[0079] Compared with existing technologies, this invention provides a BMS simulation verification method and platform based on fault injection closed-loop joint debugging. By combining model libraries, scenario libraries, and fault injection libraries, it enables rapid verification of virtual BMS under different objects, operating conditions, and fault types. Through closed-loop joint debugging between battery models, thermal management models, actuator models, and communication models, it improves the closeness of verification results to the real system. Through a unified evaluation mechanism for coverage, response quality, and protection effect, it improves the comparability and screening efficiency between different verification tasks. Through a problem parameter and suggestion result feedback mechanism, it forms a continuous iterative closed loop of "simulation verification - problem identification - parameter revision - re-verification". Attached Figure Description

[0080] Figure 1 This is a schematic diagram of the overall architecture of the present invention.

[0081] Figure 2 This is a flowchart of the software control process of the present invention.

[0082] Figure 3 A schematic diagram for scene generation and fault injection.

[0083] Figure 4 This is a schematic diagram of closed-loop joint debugging and result evaluation.

[0084] Figure 5 A diagram illustrating the cross-model migration comparison. Detailed Implementation

[0085] The present invention will now be further described with reference to the accompanying drawings.

[0086] like Figure 1 As shown, this invention presents the overall system architecture.

[0087] 1. Model Management Layer: This includes the battery cluster maintenance model, thermal management model, balancing execution model, contactor and protection execution model, communication link model, and environmental model.

[0088] 2. Scenario Generation and Scheduling Layer: Generates verification scenarios based on operating condition templates, environmental parameters, load curves, and fault templates, and schedules the execution order and duration of the scenarios.

[0089] 3. Fault Injection Layer: Performs controlled injection of events such as sensor drift, sensor loss, actuator jamming, communication delay, individual unit mismatch, local thermal abnormality, and protection failure.

[0090] 4. Closed-loop integration layer: Outputs the estimation results, balancing commands, current limiting commands, thermal management linkage commands, and protection actions of the virtual BMS to each simulation model, and returns the feedback results to the BMS.

[0091] 5. Results Acquisition and Evaluation Layer: Conducts a unified evaluation of scene coverage, state estimation error, control response time, effectiveness of protection actions, and recovery stability.

[0092] 6. Report Generation and Feedback Layer: Generate validation reports, issue lists, parameter revision suggestions, and regression validation plans, and feed back key results to the BMS parameter library or algorithm version library.

[0093] The functions of the key modules of this invention are shown in Table 1.

[0094] Table 1

[0095] Model Management Layer Managing various models under test and interfaces Battery model, thermal model, actuator model, communication model Callable model collection Scene generation and scheduling layer Generate normal and abnormal verification scenarios Operating condition template, environmental parameters, load curve, fault template Scenario Examples Fault Injection Layer Controlling fault type and injection timing Fault template, injection strength, trigger conditions Inject event stream Closed-loop integration layer Perform bidirectional joint debugging between BMS and simulation object BMS output, model status, injection events Closed-loop simulation state Result Acquisition Layer Summarize the results and logs from each scenario Simulation state, control action, protection action Original verification results Results Evaluation Layer Calculate coverage, response quality, and overall score. Original verification results, evaluation rules Rating results, question tags Report generation layer Generate a verification report and recommendations Rating results, issue tags, log summary Verification report, recommendation list recharge layer Write-back parameters and regression plan Recommended list, version information Reinjection parameters, regression task

[0096] This invention is not simply a data playback, but rather a process of writing back the BMS output to the battery, thermal management, actuators, and communication models to form a closed-loop integrated debugging system.

[0097] This invention does not only verify normal operating conditions, but also introduces layered fault injection and composite fault combination verification.

[0098] This invention does not only output test logs, but forms a quantifiable verification score and parameter feedback closed loop.

[0099] like Figure 2 As shown, the process of this invention is as follows:

[0100] Step 1, Load the model library: After the platform starts, it first reads all the simulation models required by the target verification object from the model management layer, including the battery cluster model, thermal management model, equalization execution model, contactor and protection execution model, communication link model and environmental model.

[0101] For the battery cluster model, the platform reads the equivalent circuit parameters of each battery cell, including the open-circuit voltage curve U. ocv (SOC), internal resistance R0, polarization resistance R p and polarization capacitor C p The terminal voltage of a single battery cell is calculated using the following equivalent circuit equation: U cell,k =U ocv (SOC k )-I k ·R0-U p,k Among them, U cell,k U represents the terminal voltage of a single battery cell at the k-th simulation time step, in V. ocv (SOC k ) represents the open-circuit voltage corresponding to the SOC state, in V; I k U is the current at the k-th time step, negative for charging and positive for discharging, in A; R0 is the internal resistance in ohms, in Ω; U p,k Polarization voltage, in volts (V).

[0102] The polarization voltage is updated according to the following first-order RC recursion: ;in, The polarization voltage of the previous time step, in V; Polarization resistance, unit: Ω; Polarization capacitance, unit F; The simulation time step is expressed in seconds (s).

[0103] After loading, the platform verifies the mapping relationship of the model interfaces one by one to confirm that the voltage, current, and temperature ports of the battery model are correctly connected to the corresponding ports of the thermal management model and the actuator model.

[0104] Step 2, Load the BMS under test: Import the BMS algorithm modules to be verified, including the SOC estimation module, SOH assessment module, equalization control module, current limiting protection module, and thermal management linkage module. Simultaneously, read the BMS configuration parameter table, including the protection thresholds for each level (overvoltage V). ov Undervoltage V uv Overheating T ot Overcurrent I oc ), Equilibrium triggering condition (individual pressure difference threshold ΔV) bal ) and version identifier.

[0105] The platform initializes the internal state of the BMS, setting the initial values ​​of SOC, SOH, equilibrium status flag, and protection status flag to their default values. If historical regression baseline parameters exist, these parameters are loaded synchronously for subsequent comparisons.

[0106] Step 3, as follows Figure 3As shown, the verification scenario generation process automatically generates a set of verification scenarios covering multiple dimensions based on the working condition template and fault template from the scenario generation module. The scenario generation process includes a combination of the following three types of scenarios:

[0107] (1) Normal operating conditions: covering constant current charging and discharging, stepped power variation, dynamic load following, and static recovery conditions. Each normal operating condition defines a current sequence through a load curve template. Duration sequence and ambient temperature setting .

[0108] (2) Boundary operating condition scenarios: covering high-rate charge and discharge (≥1C), low-temperature start-up ( ≤-10℃), high temperature operation ( Extreme conditions such as ≥45℃ and recovery after deep discharge.

[0109] (3) Fault Condition Scenarios: The fault type (sensor drift, sensor loss, actuator jamming, communication delay, individual unit mismatch, local thermal anomaly) and triggering timing are specified by the fault template. The generated scenario set is evaluated for coverage using the scenario coverage formula: ;in, Let be the coverage of the s-th scene; The number of working condition categories covered by scenario s; This represents the total number of preset operating condition categories; The number of environment categories covered by scene s; The total number of preset environment categories; The number of fault categories covered by scenario s; The total number of preset fault categories; The number of object categories covered by scene s; The total number of preset object categories; , , , For coverage weighting coefficients, satisfying + + + =1; The scene scheduler arranges the scene execution order according to priority, and prioritizes the execution of scene combinations with lower coverage.

[0110] Step 4, Configure the fault injection plan: For each fault scenario, the fault injection layer reads the fault template and configures the injection parameters. The injection of each type of fault includes the following elements:

[0111] (1) Sensor drift: Set the drift direction (positive / negative) and drift amplitude. Drift start time and duration .

[0112] (2) Sensor loss: Set the start time of loss, duration of loss and default replacement value after loss.

[0113] (3) Actuator jamming: Set the jamming object (balanced switch, contactor, liquid cooling valve), jamming state (open / closed / intermediate position) and jamming duration.

[0114] (4) Communication delay: Set the delay amount (unit: ms), the delay start time, and the communication channel affected.

[0115] (5) Cell mismatch: Set the abnormal cell number, capacity deviation percentage and internal resistance deviation percentage.

[0116] (6) Local thermal anomaly: Set the location of the thermal anomaly, the additional heating power (unit: W) and the duration.

[0117] The injection intensity for each type of fault is quantified using the following formula: ;in, Let f be the injection intensity of the type f fault in scenario s; This represents the fault offset magnitude. This serves as the reference offset amplitude for this type of fault; The duration of the fault is expressed in seconds (s). The reference duration for this type of fault, in seconds; This refers to the number of combinations that can be simultaneously superimposed with other faults. , , The fault intensity weighting coefficient is preset by the fault template.

[0118] Step 5, as follows Figure 4 As shown, the closed-loop simulation state is initialized by aligning all simulation models and BMS internal states to a unified initial time. Specific initialization steps include:

[0119] (1) Battery cluster model: Set the initial SOC value of each cell. (i is the individual unit number), initial temperature Initial polarization voltage =0.

[0120] (2) Thermal management model: Set the initial temperature of the coolant Initial flow and ambient temperature .

[0121] (3) Actuator model: Set the initial state of the equalization switch (all closed) and the initial state of the contactor (main contactor closed).

[0122] (4) Communication model: Set the initial value of communication delay to zero and the initial value of data packet loss rate to zero.

[0123] (5) BMS internal status: Set initial value for SOC estimation Initial value of SOH estimation The protection status indicator is "normal".

[0124] Step 6, Perform time-step simulation: using discrete time steps As a unit of advancement, the model states are updated in the following order at each time step k:

[0125] (1) Battery model update: based on the current of the previous time step And control commands, update the SOC of each unit: ;in, Let i be the charge state of the i-th individual at the k-th time step; Let be the current of the i-th cell in the previous time step, in amperes (A). The nominal capacity of the i-th monomer is expressed in Ah. The simulation time step is expressed in seconds (s).

[0126] (2) Thermal model update: The cell temperature is updated based on the battery's heating power and cooling power. ;in, Let be the temperature of the i-th monomer at the k-th time step, in °C; Heating power, in watts (W). Cooling power, measured in watts (W), is determined by coolant flow rate and temperature difference. This refers to the mass of a single unit, expressed in kg. Specific heat capacity, unit: J / (kg·℃).

[0127] (3) Actuator model update: Update the actuator state according to the equalization, current limiting and protection instructions issued by the BMS in the previous step.

[0128] (4) Communication model update: Based on the communication delay setting, apply corresponding delay and packet loss processing to the data received by BMS.

[0129] (5) The platform packages the current status (single unit voltage, current, temperature, actuator status, communication status) output by each model into the input data frame of the BMS.

[0130] Step 7, Execute BMS Decision Output: After receiving the state input at the current time step, the BMS executes the following calculations sequentially according to its internal algorithm logic:

[0131] (1) SOC calculation: The BMS uses the ampere-hour integration method combined with voltage correction to update the SOC: ;in, The SOC estimate for BMS at the k-th time step; This is the voltage correction gain coefficient; The unit voltage is the single-cell terminal voltage collected at the current time step, in volts (V). The open-circuit voltage is obtained by looking up the table based on the SOC estimated in the previous time step, in V.

[0132] (2) SOH Assessment: When specific triggering conditions are met (such as completing a full charge-discharge cycle), the BMS updates the SOH based on the ratio of the actual discharge capacity to the nominal capacity. ;in, Here is the estimated SOH value at the k-th time step, in % (%). The actual released capacity is expressed in Ah.

[0133] (3) Equilibrium command generation: When the maximum pressure difference between individual cells exceeds the equilibrium threshold At that time, the BMS sends an equalization command to the cell with the largest voltage difference, and the equalization current is... .

[0134] (4) Current limiting command generation: When the voltage of any single cell approaches the overvoltage or undervoltage threshold, the BMS calculates the current limiting coefficient according to the following formula: ;in, This is the current limiting coefficient, with a value range of [0,1]. Hard protection limit, unit: V; This is the soft current limiting start-up threshold, in volts (V). The BMS outputs the current limiting coefficient to the PCS or load controller to ensure that the actual current does not exceed [the specified value]. .

[0135] (5) Protection action determination: When any parameter triggers a hard protection condition (overvoltage, undervoltage, overtemperature, overcurrent), the BMS outputs a protection action command (disconnects the contactor, cuts off the charging and discharging circuit) and records the protection trigger time. .

[0136] Step 8, Write-back Output: Feed back the control commands output by the BMS in Step 7 to the corresponding simulation model to form a closed loop, including the following cases:

[0137] (1) Current distribution write-back: Write the current limiting coefficient back Write back to the battery model to update the actual current for the next time step. ;in, Request current for the load.

[0138] (2) Equalization status write-back: Write the equalization command back to the actuator model, turn on or off the equalization switch of the corresponding unit, and update the equalization current distribution.

[0139] (3) Thermal management linkage write-back: If the BMS issues a liquid cooling enhancement command, the flow rate increase command is written back to the thermal management model, so that the coolant flow rate is increased from Upgraded to .

[0140] (4) Protection action write-back: If the BMS issues a protection command, the contactor disconnect command will be written back to the actuator model so that the battery cluster current drops to zero in the next time step.

[0141] (5) Communication status write-back: If the BMS detects a communication anomaly and switches to the backup channel, it writes the channel switching information back to the communication model.

[0142] After the write-back is completed, each simulation model will recalculate its state based on the updated control commands in the next time step, thus forming a closed-loop joint debugging where the BMS output affects the platform state and the platform state is fed back to the BMS.

[0143] Step 9, Inject Fault Events: During simulation, the fault injection layer continuously monitors whether the current time step k reaches the preset fault triggering condition. When the triggering condition is met, fault injection is performed as follows:

[0144] (1) Sensor drift injection: An offset is superimposed on the true value of the target sensor, so that the sensor value actually received by the BMS becomes .

[0145] (2) Sensor loss injection: The target sensor data is marked as invalid, and the field in the corresponding data frame received by BMS is set to the default replacement value or NaN.

[0146] (3) Actuator jamming injection: Lock the state of the target actuator so that it no longer responds to BMS commands until the fault duration ends.

[0147] (4) Communication delay injection: delay the data frames received by the BMS. Milliseconds cause the data processed by the BMS to lag behind the actual state.

[0148] (5) Monomer mismatch injection: Modify the capacity parameter of the target monomer to The internal resistance parameter is ;in, and These are the capacity deviation rate and the internal resistance deviation rate, respectively.

[0149] (6) Local thermal anomaly injection: Add an extra item to the heating power of the target unit. ,make .

[0150] The platform continuously records key state parameters (voltage, current, temperature, SOC, protection flags) at each moment before, during, and after fault injection for subsequent evaluation.

[0151] Step 10, Collect and verify the results: In each simulation time step, the result collection layer records the following data:

[0152] (1) State estimation data: reference SOC value SOC k BMS estimates SOC value Reference SOH value k BMS estimates SOH value .

[0153] (2) Control response data: the time when the equalization command is issued, the actual time when the equalization takes effect, the value of the current limiting command, and the response time of the current limiting action.

[0154] (3) Protection action data: protection trigger time Protection condition type, protection action execution time, and recovery time. .

[0155] (4) Abnormal statistics: number of false alarms (BMS triggers protection but protection conditions are not actually met), number of missed reports (The protection conditions were actually met, but the BMS triggered the protection).

[0156] After the scene is completed, calculate the state estimation error for that scene: ;in, Estimating the state error for scenario s; Let be the total number of simulation steps for scenario s; , These are the reference state values ​​at time k; , These are the estimated values ​​of BMS at time k; , Let be the error weighting coefficient, satisfying + =1.

[0157] Step 11, Perform scenario-level evaluation: For each completed scenario s, the evaluation layer calculates the following metrics:

[0158] (1) Response quality score: Weighted sum of estimation error, response time, false alarms and false misses after normalization: ;in, Let be the response quality score for scene s, with a value range of [0,1]. To estimate the error of the normalized state, normalize it according to the maximum value of all scenarios; This is the normalized average response time; The number of false alarms after normalization; This represents the normalized number of missed reports; , , , In response to the quality weighting coefficient, satisfy + + + =1.

[0159] (2) Protection effectiveness score: ;in, Let be the protection effectiveness score for scenario s, with a value range of [0,1]. This is a protection action triggering correctness indicator; a correct trigger is 1, and a incorrect trigger is 0. To restore the accuracy of the movement; Delay in protection actions after normalization; This is a normalized residual risk indicator; , , , In response to the quality weighting coefficient, satisfy + + + =1.

[0160] Step 12, as follows Figure 5 As shown, a version-level evaluation is performed: after all scenarios have been executed, the scenario-level results of all scenarios are weighted and summarized to form a comprehensive version score. ;in, The overall score for the version ranges from [0,1]; S represents the total number of scenes. The coverage of scene s (calculated in step 3); The response quality score for scenario s (calculated in step 11); The protection effectiveness score for scenario s (calculated by step 11); This is a penalty term for scenario s, which takes a positive value when there are false alarms, missed alarms, or protection failures in the scenario. The weights of scenario s are: fault scenarios and boundary scenarios have higher weights than normal operating condition scenarios. , , , This serves as the weighting coefficient for the overall score. Simultaneously, a problem list is generated, recording the fault type, cause of failure, and involved parameters for each failure scenario.

[0161] Step 13, Generate Report and Refactoring Recommendations: The report generation layer outputs the following content based on the overall version score and issue list:

[0162] (1) Verification report: includes version information, scenario list, scoring results for each scenario, coverage statistics, problem distribution and comprehensive score.

[0163] (2) List of Failure Scenarios: List all scenarios with an overall score below the passing threshold. The scenario is described, and the reason for failure is noted.

[0164] (3) Parameter revision suggestions: Based on the failure mode of the failure scenario, promote the BMS parameters that need to be modified and the direction of revision.

[0165] (4) Regression verification recommendations: List the set of scenarios that need to be re-executed after parameter revision.

[0166] Step 14, Write Back Parameters and Arrange Regression Validation: The backfeedback management team translates the revision suggestions in the report into specific parameter update operations. For the p-th parameter to be revised, the backfeedback update relationship is: ;in, This refers to the p-th parameter after recharge; These are the original parameter values; The amount of parameter revision for simulation verification output; The parameter is the recharge coefficient, with a value range of [0,1], used to control the revision range.

[0167] After the backfeedback is completed, the platform automatically writes the revised parameters into the BMS parameter library or algorithm version library, and schedules the next round of regression verification tasks. Starting from step 3, the affected scenarios are re-executed, forming a continuous iterative closed loop of "simulation verification - problem identification - parameter revision - re-verification".

[0168] Example:

[0169] BMS was originally developed for 100Ah ternary lithium battery clusters, but needs to be migrated to 314Ah lithium iron phosphate battery clusters.

[0170] (1) Model loading and migration configuration: The platform simultaneously loads the old model (100Ah ternary lithium, ) and the new model (314Ah lithium iron phosphate, The battery parameter template is used. The BMS algorithm module remains unchanged at V2.2.0, but the configuration parameter table is switched to the new model threshold.

[0171] (2) Historical Fault Replay: Three typical fault cases were extracted from the historical problem database for replay:

[0172] Case A: Actuator jamming caused equalization failure. The original model had a single-unit pressure difference that continued to expand to 120mV.

[0173] Case B: The monomer temperature rose abnormally to 58°C, triggering over-temperature protection, but the recovery time was too long (>30 minutes).

[0174] Case C: Protection false triggering, BMS misjudges overcurrent during normal 0.8C discharge.

[0175] (3) Composite fault injection and regression verification: New environmental conditions are superimposed on historical cases: Case A is superimposed with a -5°C low temperature environment, Case B is superimposed with a 1.2C high rate discharge, and Case C is superimposed with a 100ms CAN communication delay.

[0176] Regression validation results:

[0177] Case A (Superimposed Low Temperature): The new model has lower internal resistance, resulting in a slower rate of differential voltage increase (from 120mV to 45mV), thus improving the effectiveness of voltage equalization. = 0.89.

[0178] Case B (High-rate superposition): Due to its larger capacity and lower single-unit heating power density, the new model's peak temperature dropped from 58°C to 52°C, and the recovery time was shortened from 30 minutes to 18 minutes. = 0.87.

[0179] Case C (Superimposed Communication Delay): Overcurrent Threshold in New Models ( At 628A, 2C, the 0.8C discharge current is approximately 251A, which is far below the threshold, and the false triggering problem disappears. = 0.95.

[0180] (4) Continuous iteration: The management team found that the recovery time in Case B was still too long, and suggested that the over-temperature recovery threshold be increased from... -5℃ adjusted to -8°C (i.e., adjusted from 50°C to 47°C), and then written into the parameter library before scheduling the next round of regression validation.

Claims

1. A BMS simulation verification method and platform based on fault injection closed-loop joint debugging, characterized in that, The platform includes the following: Model management layer: includes battery cluster maintenance model, thermal management model, balancing execution model, contactor and protection execution model, communication link model and environmental model; Scene generation and scheduling layer: Generates verification scenes based on working condition templates, environmental parameters, load curves and fault templates, and schedules the execution order and duration of the scenes; Fault injection layer: Performs controlled injection for events such as sensor drift, sensor loss, actuator jamming, communication delay, individual unit mismatch, local thermal abnormality, and protection failure; Closed-loop integration layer: Outputs the estimation results, balancing commands, current limiting commands, thermal management linkage commands and protection actions of the virtual BMS to each simulation model, and returns the feedback results to the BMS; Results Acquisition and Evaluation Layer: Conducts a unified evaluation of scene coverage, state estimation error, control response time, effectiveness of protection actions, and recovery stability; Report generation and backfeeding layer: Generates validation reports, issue lists, parameter revision suggestions, and regression validation plans, and feeds key results back to the BMS parameter library or algorithm version library; The BMS simulation verification method flow is as follows: S1, Loading the Model Library: After the platform starts, it first reads all the simulation models required by the target verification object from the model management layer, including the battery cluster model, thermal management model, equalization execution model, contactor and protection execution model, communication link model, and environmental model. After loading, the platform verifies the model interface mapping relationship one by one to confirm that the voltage, current, and temperature ports of the battery model are correctly connected to the corresponding ports of the thermal management model and the actuator model. S2, Loading the BMS Test Object: The platform imports the BMS algorithm modules to be verified, including the SOC estimation module, SOH evaluation module, equalization control module, current limiting protection module, and thermal management linkage module. At the same time, it reads the BMS configuration parameter table, including the protection thresholds at all levels, equalization trigger conditions, and version identifier. The platform initializes the internal state of the BMS, setting the initial SOC value, initial SOH value, equalization status flag, and protection status flag to the default values. If there are historical version regression baseline parameters, the baseline parameters are loaded synchronously for subsequent comparison. S3, Generate Verification Scenarios: Based on the working condition templates and fault templates of the scenario generation module, automatically generate a set of verification scenarios covering multiple dimensions; S4, Configure Fault Injection Plan: For each fault scenario, the fault injection layer reads the fault template and configures the injection parameters. S5, Initialize closed-loop simulation state: Align all simulation models and BMS internal states to a unified initial time. S6, Perform time-step simulation: using discrete time steps As the unit of advancement, the state of each model is updated in a prescribed order at each time step k; S7, Execute BMS decision output: After receiving the state input at the current time step, BMS executes calculations sequentially according to its internal algorithm logic; S8, Write-back Output: Feed back the various control commands output by the BMS in step 7 to the corresponding simulation model to form a closed loop. After the write-back is completed, each simulation model will recalculate the state based on the updated control commands in the next time step, thus forming a closed-loop joint debugging where the BMS output affects the platform state and the platform state is fed back to the BMS. S9, Injecting Fault Events: During the simulation, the fault injection layer continuously monitors whether the current time step k reaches the preset fault triggering condition and performs fault injection in accordance with the prescribed method. The platform continuously records the key state variables at each time before, during and after fault injection for subsequent evaluation. S10, Collect and verify results: In each simulation time step, the result acquisition layer records state estimation data, control response data, protection action data, and anomaly statistics. S11, Perform scenario-level assessment: For each completed scenario s, the assessment layer calculates the response quality score and protection effectiveness score respectively; S12, Perform version-level evaluation: After all scenarios have been executed, the scenario-level results of all scenarios are weighted and summarized to form a comprehensive version score. At the same time, a problem list is generated, recording the fault type, failure reason and parameters involved in each failure scenario. S13, Report Generation and Regression Suggestions: The report generation layer outputs a verification report, a list of failure scenarios, parameter revision suggestions, and regression verification suggestions based on the version comprehensive score and issue list; S14, write back parameters and arrange regression verification: The management team will convert the revision suggestions in the report into specific parameter update operations. After the backfeed is completed, the platform will automatically write the revised parameters into the BMS parameter library or algorithm version library and schedule the next round of regression verification tasks. Starting from S3, the affected scenarios will be re-executed to form a continuous iterative closed loop of "simulation verification - problem identification - parameter revision - re-verification".

2. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step S1, for the battery cluster model, the platform reads the equivalent circuit parameters of the individual battery cells, including the open-circuit voltage curve U. ocv (SOC), internal resistance R0, polarization resistance R p and polarization capacitor C p The terminal voltage of a single battery cell is calculated using the following equivalent circuit equation: U cell,k =U ocv (SOC k )-I k ·R0-U p,k ; Among them, U cell,k U represents the terminal voltage of a single battery cell at the k-th simulation time step, in V. ocv (SOC k () represents the open-circuit voltage corresponding to the SOC state, in volts (V). I k U is the current at the k-th time step, negative for charging and positive for discharging, in A; R0 is the internal resistance in ohms, in Ω; U p,k Polarization voltage, in volts (V).

3. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 2, characterized in that: The polarization voltage is updated according to the following first-order RC recursion: ;in, The polarization voltage of the previous time step, in V; Polarization resistance, unit: Ω; Polarization capacitance, unit F; The simulation time step is expressed in seconds (s).

4. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging as described in claim 1, characterized in that: In step S2, the protection threshold at each level is the overvoltage V. ov Undervoltage V uv Overheating T ot Overcurrent I oc The equilibrium trigger condition is the single-cell pressure difference threshold ΔV. bal .

5. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step S3, the scene generation process includes a combination of the following three types of scenes: S31, Normal Operating Conditions: Covers constant current charging and discharging, stepped power variation, dynamic load following, and static recovery conditions. Each normal scenario defines a current sequence using a load curve template. Duration sequence and ambient temperature setting ; S32, Boundary Operating Condition Scenarios: Covering high-rate charge / discharge (≥1C), low-temperature start-up ( ≤-10℃), high temperature operation ( Extreme conditions such as ≥45℃ and recovery after deep discharge; S33, Fault Condition Scenario: The fault type (sensor drift, sensor loss, actuator jamming, communication delay, individual unit mismatch, local thermal anomaly) and triggering time are specified by the fault template.

6. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 5, characterized in that: The generated scene set is used for coverage evaluation using the scene coverage formula: ;in, Let be the coverage of the s-th scene; The number of working condition categories covered by scenario s; This represents the total number of preset operating condition categories; The number of environment categories covered by scene s; The total number of preset environment categories; The number of fault categories covered by scenario s; The total number of preset fault categories; The number of object categories covered by scene s; The total number of preset object categories; , , , For coverage weighting coefficients, satisfying + + + =1; The scene scheduler arranges the scene execution order according to priority, and prioritizes the execution of scene combinations with lower coverage.

7. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step S4, the injection of each type of fault includes the following elements: S41, Sensor Drift: Set drift direction and drift amplitude Drift start time and duration ; S42, Sensor Loss: Set the start time of loss, duration of loss, and default replacement value after loss; S43, Actuator Stuck: Set the stuck object, stuck state and stuck duration; S44, Communication Delay: Set the delay amount, delay start time, and affected communication channels; S45, Cell Mismatch: Set the abnormal cell number, capacity deviation percentage and internal resistance deviation percentage; S46, Localized Thermal Anomaly: Sets the location of the thermal anomaly, the additional heating power, and the duration; The injection intensity for each type of fault is quantified using the following formula: ;in, Let f be the injection intensity of the type f fault in scenario s; This represents the fault offset magnitude. This serves as the reference offset amplitude for this type of fault; The duration of the fault is expressed in seconds (s). The reference duration for this type of fault, in seconds; This refers to the number of combinations that can be simultaneously superimposed with other faults. , , The fault intensity weighting coefficient is preset by the fault template.

8. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step S5, the specific initialization content includes: S51, Battery Cluster Model: Setting the Initial SOC Value for Each Individual Cell Initial temperature Initial polarization voltage =0; S52, Thermal Management Model: Sets the initial coolant temperature Initial flow and ambient temperature ; S53, Actuator Model: Set the initial state of the equalizer switch and the initial state of the contactor; S54, Communication Model: Set the initial value of communication delay to zero and the initial value of data packet loss rate to zero; S55, BMS internal state: Set initial SOC estimation value Initial value of SOH estimation The protection status is marked as "normal".

9. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step S6, the model states are updated in the following order at each time step k: S61, Battery Model Update: Based on the current from the previous time step And control commands, update the SOC of each unit: ;in, Let i be the charge state of the i-th individual at the k-th time step; Let be the current of the i-th cell in the previous time step, in amperes (A). The nominal capacity of the i-th monomer is expressed in Ah. The simulation time step is expressed in seconds (s). S62, Thermal Model Update: Updates cell temperature based on battery heating power and cooling power. ;in, Let be the temperature of the i-th monomer at the k-th time step, in °C; Heating power, in watts (W). Cooling power, measured in watts (W), is determined by coolant flow rate and temperature difference. This refers to the mass of a single unit, expressed in kg. Specific heat capacity, unit: J / (kg·℃); S63, Actuator Model Update: Update the actuator state according to the equalization, current limiting and protection instructions issued by the BMS in the previous step; S64, Communication Model Update: Apply corresponding delay and packet loss handling to the data received by the BMS according to the communication delay setting; S65, the platform packages the current state output by each model into an input data frame for the BMS.

10. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step S7, after receiving the state input of the current time step, the BMS performs the following calculations sequentially according to its internal algorithm logic: S71, SOC Calculation: The BMS uses the ampere-hour integration method combined with voltage correction to update the SOC. ;in, The SOC estimate for BMS at the k-th time step; This is the voltage correction gain coefficient; The unit voltage is the single-cell terminal voltage collected at the current time step, in volts (V). The open-circuit voltage is obtained by looking up the table based on the SOC estimated in the previous time step, in V; S72, SOH Assessment: Upon meeting specific triggering conditions (such as completing a full charge-discharge cycle), the BMS updates the SOH based on the ratio of the actual discharge capacity to the nominal capacity. ;in, Here is the estimated SOH value at the k-th time step, in % (%). The actual released capacity, in Ah; S73, Equilibrium Command Generation: When the maximum pressure difference between individual cells exceeds the equilibrium threshold. At that time, the BMS sends an equalization command to the cell with the largest voltage difference, and the equalization current is... ; S74, Current Limiting Command Generation: When any single cell voltage approaches the overvoltage or undervoltage threshold, the BMS calculates the current limiting factor according to the following formula: ;in, This is the current limiting coefficient, with a value range of [0,1]. Hard protection limit, unit: V; This is the soft current limiting start-up threshold, in volts (V). The BMS outputs the current limiting coefficient to the PCS or load controller to ensure that the actual current does not exceed [the specified value]. ; S75, Protection Action Decision: When any parameter triggers a hard protection condition, the BMS outputs a protection action command and records the protection trigger time. .

11. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step S8, the control commands output by the BMS in step S7 are fed back to the corresponding simulation model to form a closed loop, including the following cases: S81, Current Distribution Writeback: Rewrite the current limiting coefficient Write back to the battery model to update the actual current for the next time step. ;in, Request current for the load; S82, Equalization Status Write-back: Write the equalization command back to the actuator model, turn the equalization switch of the corresponding unit on or off, and update the equalization current distribution; S83, Thermal Management Linkage Write-back: If the BMS issues a liquid cooling enhancement command, the flow rate increase command will be written back to the thermal management model, causing the coolant flow rate to increase from... Upgraded to ; S84, Protection Action Write-back: If the BMS issues a protection command, the contactor disconnect command will be written back to the actuator model, so that the battery cluster current will drop to zero in the next time step. S85, Communication Status Write-back: If the BMS detects a communication anomaly and switches to the backup channel, the channel switching information will be written back to the communication model.

12. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step S9, when the triggering condition is met, fault injection is performed as follows: S91, Sensor Drift Injection: An offset is superimposed on the true value of the target sensor, so that the sensor value actually received by the BMS becomes... ; S92, Sensor Loss Injection: The target sensor data is marked as invalid, and the field in the corresponding data frame received by the BMS is set to the default replacement value or NaN; S93, Actuator Stuck Injection: Locks the state of the target actuator, preventing it from responding to BMS commands until the fault duration ends; S94, Communication Delay Injection: Delays the data frames received by the BMS. Milliseconds cause the data processed by the BMS to lag behind the actual state; S95, Monomer Mismatch Injection: Modify the capacity parameter of the target monomer to... The internal resistance parameter is ;in, and These are the capacity deviation rate and the internal resistance deviation rate, respectively. S96, Localized Thermal Anomaly Injection: Adds an extra term to the heating power of the target unit. ,make .

13. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step S11, Response quality score: a weighted sum of normalized estimation error, response time, false alarms, and false negatives. ;in, Let be the response quality score for scene s, with a value range of [0,1]. To estimate the error of the normalized state, normalize it according to the maximum value of all scenarios; This is the normalized average response time; The number of false alarms after normalization; This represents the normalized number of missed reports; , , , In response to the quality weighting coefficient, satisfying + + + =1; Protection effectiveness score: ;in, Let be the protection effectiveness score for scenario s, with a value range of [0,1]. This is a protection action triggering correctness indicator; a correct trigger is 1, and a incorrect trigger is 0. To restore the accuracy of the movement; Delay in protection actions after normalization; This is a normalized residual risk indicator; , , , In response to the quality weighting coefficient, satisfying + + + =1.

14. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step 12, the formula for the overall version score is as follows: ;in, The overall score for the version ranges from [0,1]; S represents the total number of scenes. The coverage of scene s; The response quality score for scenario s; The protection effectiveness score for scenario s; This is a penalty term for scenario s, which takes a positive value when there are false alarms, missed alarms, or protection failures in the scenario. The weights of scenario s are: fault scenarios and boundary scenarios have higher weights than normal operating condition scenarios. , , , This is the weighting coefficient for the overall score.

15. The BMS simulation verification method and platform based on fault injection closed-loop joint debugging according to claim 1, characterized in that: In step 14, the reflow management layer translates the revision suggestions in the report into specific parameter update operations: for the p-th parameter to be revised, the reflow update relationship is: ;in, This refers to the p-th parameter after recharge; These are the original parameter values; The amount of parameter revision for simulation verification output; The parameter is the recharge coefficient, with a value range of [0,1], used to control the revision range.

Images