Battery management unit detection method and system and fault data injection method

Abstract

The invention discloses a battery management unit detection method and system and a fault data injection method. The battery management unit detection method is applied to an emulator and comprises the steps that a target fault scene matched with the operation condition of a to-be-tested battery management unit BMU is loaded from a target fault library, and the target fault library comprises fault scenes obtained by conducting multi-dimensional quantification on historical faults of a target assembly; and transmitting simulation data generated when the simulator operates in the target fault scene to the to-be-tested BMU, so that the to-be-tested BMU outputs response data for the simulation data. Through the scheme provided by the invention, the authenticity of the response of the BMU to the simulation data can be improved, so that the accuracy of the BMU test is improved.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, and in particular to a method, system, and method for injecting fault data for testing a battery management unit. Background Technology

[0002] To test the operating logic of the battery management unit (BMU), it is usually necessary to simulate the actual components connected to the BMU and inject fault data into the simulator. The simulator then outputs simulation data to the BMU based on the fault data, and the BMU responds according to the simulation data. The operating logic of the BMU is then tested based on the response results output by the BMU.

[0003] However, in related technologies, the testing steps for the battery management unit are complex when injecting fault data into the simulator, resulting in low accuracy of battery management unit testing. Summary of the Invention

[0004] This application provides a method, system, and fault data injection method for detecting a battery management unit (BMU), which can improve the realism of the BMU's response to simulation data, thereby improving the accuracy of BMU testing.

[0005] In a first aspect, this application provides a method for detecting a battery management unit (BMU) and applying it in a simulator. The method includes: loading a target fault scenario from a target fault library that matches the operating conditions of the BMU to be tested, wherein the target fault library includes fault scenarios obtained by multi-dimensional quantification of historical faults occurring in the target component; and transmitting the simulation data generated by the simulator running under the target fault scenario to the BMU to be tested, so that the BMU to be tested outputs response data to the simulation data.

[0006] As described above, in this embodiment, when injecting a fault into the simulator, a target fault scenario corresponding to the operating condition is injected into the simulator, making the simulator's operation more closely resemble the actual scenario. This results in more accurate simulation data output by the simulator, leading to a more realistic response from the BMU under test to the simulation data and improving the accuracy of BMU testing. Furthermore, in this embodiment, the fault scenario includes data obtained through multi-dimensional quantification of the fault. Therefore, during BMU testing, scenario data of the fault in actual application is injected into the simulator, making the BMU's testing environment more closely resemble the actual operating environment. This further enhances the realism of the BMU's response to the simulation data and improves the accuracy of BMU testing.

[0007] In some embodiments, transmitting simulation data generated by the simulator running under a target fault scenario to the BMU under test includes: acquiring the communication protocol corresponding to the BMU under test and multiple data transmission channels communicating with the BMU under test; determining a target transmission channel that matches the communication protocol from the multiple data transmission channels; and transmitting the simulation data running under the target fault scenario to the BMU under test through the target transmission channel.

[0008] By selecting an appropriate data transmission channel to transmit simulation data according to the communication protocol corresponding to the BMU under test, the accuracy of simulation data transmission can be improved, thereby improving the accuracy of the BMU's response to the simulation data and ultimately enhancing the accuracy of BMU testing.

[0009] In some embodiments, the target component includes a data acquisition component and a target BMU, wherein the target BMU is a BMU other than the BMU to be tested.

[0010] By using the data acquisition component and the BMU as target components, the simulator can simulate the target components and then detect the operating logic of the BMU under test based on its response to the simulation data. This can improve the comprehensiveness and accuracy of BMU testing.

[0011] Secondly, this application also provides a method for injecting fault data, applied in a host computer. The method includes: obtaining the operating conditions of the battery management unit (BMU) to be tested; obtaining a target fault scenario that matches the operating conditions from a target fault library storing fault scenarios, wherein the target fault library includes fault scenarios obtained by multi-dimensional quantification of historical faults occurring in the target component; and injecting the target fault scenario into the simulator.

[0012] In this embodiment, when injecting a fault into the simulator, a target fault scenario corresponding to the operating conditions is injected into the simulator, making the simulator's operation more closely resemble the actual scenario. This results in more accurate simulation data output by the simulator, leading to a more realistic response from the BMU under test and improving the accuracy of BMU testing. Furthermore, in this embodiment, the fault scenario includes data obtained through multi-dimensional quantification of the fault. Therefore, during BMU testing, instead of simply injecting the fault into the simulator, scenario data of the fault in actual application is injected, making the test environment of the BMU under test more closely resemble the actual operating environment. This further enhances the realism of the BMU's response to the simulation data and improves the accuracy of BMU testing.

[0013] In some embodiments, before obtaining a target fault scenario matching the operating condition from the target fault scenario library of stored fault scenarios, the fault data injection method further includes: obtaining the fault type and fault cause of at least one historical fault of the target component; determining the fault scenario corresponding to each historical fault based on the fault type and fault cause; and constructing a target fault library based on the fault scenario corresponding to at least one historical fault.

[0014] By constructing a target fault library, multiple fault scenarios corresponding to a fault can be directly obtained from the target fault library during fault injection. Thus, when injecting a fault, not only a single fault is injected, but also the corresponding scenario is injected, making the test scenario of BMU more consistent with the actual operation scenario and improving the accuracy of BMU testing.

[0015] In some embodiments, determining the fault scenario corresponding to each historical fault based on the fault type and fault cause includes: analyzing the fault cause to determine the fault data corresponding to each fault type; extracting data from the fault data corresponding to each fault type from multiple dimensions to obtain the dimension data corresponding to each dimension, wherein the multiple dimensions include fault occurrence time, fault occurrence frequency and fault occurrence duration; and combining the dimension data of the multiple dimensions to obtain the fault scenario corresponding to each historical fault.

[0016] By quantifying the faults from multiple dimensions, we can obtain multiple fault scenarios that correspond to the actual operating scenarios of the BMU under test. Testing the BMU under these fault scenarios will yield accurate test results.

[0017] In some embodiments, injecting a target fault scenario into the simulator includes: obtaining the runtime sequence of the BMU to be tested; determining the scenario injection time of the target fault scenario based on the runtime sequence of the BMU to be tested and the fault occurrence time of the target fault scenario; and injecting the target fault scenario into the simulator according to the fault occurrence frequency, starting from the scenario injection time.

[0018] By injecting fault scenarios into the simulator according to the runtime sequence of the BMU under test, the problem of low fault injection efficiency caused by manually injecting single fault values ​​is not only solved; at the same time, since what is injected into the simulator is a fault scenario, rather than a simple fault value, the simulator can simulate simulation data that closely matches the actual working conditions, thus improving the accuracy of BMU testing.

[0019] In some embodiments, after injecting the target fault scenario into the simulator, the fault data injection method further includes: obtaining the actual response result of the BMU under test in response to the simulation data, wherein the simulation data is the data generated by the simulator running under the target fault scenario; and determining the test result of testing the running logic of the BMU under test based on the actual response result.

[0020] In the above embodiments, the operational logic of the BMU under test is tested by detecting its response to simulation data. This process eliminates the need to inject faults into the BMU, reducing the complexity and improving the efficiency of the test. Furthermore, testing the operational logic of the BMU under test in fault scenarios enhances the accuracy of the test.

[0021] In some embodiments, determining the test result of testing the operating logic of the BMU under test based on the actual response result includes: obtaining the expected response result, wherein the expected response result is used to characterize the response result of the operating logic in the BMU under test to the simulation data when the operating logic meets the preset conditions; determining that the operating logic of the BMU under test is abnormal when the actual response result does not match the expected response result; and recording the abnormal data of the BMU under test when the operating logic of the BMU is abnormal.

[0022] The test results of the BMU under test are determined based on the actual response results of the BMU under test, and the abnormal data when the BMU's operating logic is abnormal is recorded so that the abnormality can be handled manually, thereby improving the robustness of the BMU's operating logic design.

[0023] Thirdly, this application also provides a simulator, which includes: a controller for loading target fault scenarios from a target fault library that match the operating conditions of the battery management unit (BMU) under test, wherein the target fault library includes fault scenarios obtained by multi-dimensional quantification of historical faults occurring in the target component; the controller is also used to transmit simulation data generated by the simulator running under the target fault scenarios to the BMU under test, so that the BMU under test outputs response data to the simulation data, wherein the response data output by the BMU under test is used to characterize whether there is an anomaly in the operating logic of the BMU under test.

[0024] As described above, in this embodiment, when injecting a fault into the simulator, a target fault scenario corresponding to the operating condition is injected into the simulator, making the simulator's operation more closely resemble the actual scenario. This results in more accurate simulation data output by the simulator, leading to a more realistic response from the BMU under test to the simulation data and improving the accuracy of BMU testing. Furthermore, in this embodiment, the fault scenario includes data obtained through multi-dimensional quantification of the fault. Therefore, during BMU testing, scenario data of the fault in actual application is injected into the simulator, making the BMU's testing environment more closely resemble the actual operating environment. This further enhances the realism of the BMU's response to the simulation data and improves the accuracy of BMU testing.

[0025] In some embodiments, the controller includes: a system-on-chip (SoC) for loading a target fault scenario from a target fault library that matches the operating conditions of the BMU under test; and the SoC for running simulation data under the target fault scenario.

[0026] By loading fault scenarios from the target fault library, the simulator can generate simulation data that closely matches the actual fault scenarios, enabling the BMU under test to generate response data that closely matches the actual operating scenario. Analyzing this response data can improve the testing accuracy of the BMU under test.

[0027] In some embodiments, the controller further includes: a programmable logic device for converting simulation data into serial communication signals; and a communication circuit for transmitting the serial communication signals to the BMU under test.

[0028] In the above embodiments, a simulator is used to simulate real components, injecting fault scenarios into the simulator to simulate the operating state of real components under fault scenarios. The generated simulation data is then transmitted to the BMU under test, and the operating logic of the BMU under test is tested based on the response results of the BMU under test. This eliminates the need to use real components, reducing the cost of testing the BMU under test. At the same time, since the fault scenarios simulate the actual operating scenarios of real components, the test results of the BMU are more consistent with the actual scenarios, thus improving the accuracy of BMU testing.

[0029] Fourthly, this application also provides a host computer, which includes: a working condition acquisition module for acquiring the operating conditions of the battery management unit (BMU) to be tested; a fault acquisition module for acquiring a target fault scenario matching the operating conditions from a target fault library storing fault scenarios, wherein the target fault library includes fault scenarios obtained by multi-dimensional quantification of historical faults occurring in the target component; and a fault injection module for injecting the target fault scenario into the simulator.

[0030] Fifthly, this application provides a readable storage medium storing computer program instructions that, when executed by a processor, implement the detection method of the battery management unit as described in the first aspect, and / or the fault data injection method as described in the second aspect.

[0031] In a sixth aspect, this application provides a computer program product in which the instructions, when executed by a processor of an electronic device, cause the electronic device to perform the detection method of the battery management unit as described in the first aspect, and / or the fault data injection method as described in the second aspect.

[0032] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0033] The features, advantages, and technical effects of exemplary embodiments of this application will now be described with reference to the accompanying drawings.

[0034] Figure 1 This is a schematic diagram of the structure of a detection system for a battery management unit according to an embodiment of this application;

[0035] Figure 2 This is a schematic diagram of the structure of a simulator according to one embodiment of this application;

[0036] Figure 3 This is a flowchart of a detection method for a battery management unit according to an embodiment of this application;

[0037] Figure 4 This is a flowchart of a simulation data transmission method according to an embodiment of this application;

[0038] Figure 5 This is a schematic diagram of the structure of a host computer according to an embodiment of this application;

[0039] Figure 6 This is a flowchart of a fault data injection method according to an embodiment of this application;

[0040] Figure 7 This is a schematic diagram illustrating the type of data acquisition chip according to one embodiment of this application;

[0041] Figure 8 This is a schematic diagram illustrating the fault types of an AFE chip according to an embodiment of this application;

[0042] Figure 9 This is a schematic diagram illustrating the causes of failure in a battery cell voltage sampling chip according to an embodiment of this application.

[0043] Figure 10 A flowchart illustrating the injection of a fault scenario into a simulator according to one embodiment of this application.

[0044] The accompanying drawings are not necessarily drawn to scale. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0046] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0047] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0048] In this application, the term "embodiment" is used to mean that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

[0049] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0050] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0051] In the description of the embodiments in this application, the technical terms "center," "longitudinal," and "lateral" are used.

[0052] "Length", "Width", "Thickness", "Top", "Bottom", "Front", "Back", "Left", "Right"

[0053] "Vertical", "Horizontal", "Top", "Bottom", "Inner", "Outer", "Clockwise", "Counterclockwise"

[0054] The orientation or positional relationship indicated by "axial", "radial", "circumferential", etc., is based on the orientation or positional relationship shown in the accompanying drawings and is only for the purpose of facilitating the description of the embodiments of this application and simplifying the description. It is not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the embodiments of this application.

[0055] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0056] The internal design of the battery management unit is complex, and it is difficult to inject faults into the battery management unit. Therefore, the battery management unit is usually tested under normal scenarios. However, this method cannot cover abnormal scenarios. Moreover, when developing functional safety for the battery management unit, it is also very difficult to test the operating logic of the battery management unit under abnormal scenarios.

[0057] In response, related technologies typically employ a method of injecting fault data into components connected to the battery management unit when testing its internal operating logic.

[0058] However, in related technologies, when injecting fault data into the simulated components corresponding to real components, the fault data is usually injected into the simulator through manual control. This method not only increases the complexity and cost of battery management unit (BMU) testing but also reduces the accuracy of BMU testing. Furthermore, related technologies typically employ a single fault injection approach, which reduces the efficiency of fault data injection. Moreover, simply injecting fault data does not address the operating conditions of the system containing the BMU or the corresponding fault scenario, resulting in a significant difference between the BMU test scenario and the actual operating scenario, thus reducing the accuracy of BMU testing.

[0059] To address this issue, this application provides a method, system, and fault data injection method for detecting a battery management unit (BMU). In this embodiment, a fault scenario is selected based on the operating conditions corresponding to the BMU, and this scenario is injected into a simulator. The simulator then runs under the fault scenario and generates simulation data. This simulation data is input to the BMU under test, which responds to the simulation data to obtain the actual response result. By comparing the actual response result with the expected response result, it can be determined whether there is an anomaly in the internal operating logic of the BMU under test. This process considers both the scenario corresponding to the fault data and the operating conditions corresponding to the BMU under test, making the BMU testing environment more closely resemble the actual operating environment and improving the accuracy of BMU testing.

[0060] In one embodiment, the battery management unit detection system provided in this application embodiment may include a host computer and a simulator, wherein the host computer can execute the fault data injection method provided in this application embodiment, and the simulator can execute the battery management unit detection method provided in this application embodiment. Before introducing the battery management unit detection method and fault data injection method provided in this application embodiment, the battery management unit detection system will be introduced first.

[0061] In one embodiment, Figure 1 This illustration shows a schematic diagram of the detection system for the battery management unit provided in an embodiment of this application. Figure 1 As can be seen, in the embodiments of this application, the detection system of the battery management unit includes at least a host computer 10 and a simulator 20.

[0062] In this embodiment, the simulator 20 may exist in the form of a board, which is used to simulate real components, such as the data acquisition process of a data acquisition chip (e.g., a temperature acquisition chip or an electrical signal acquisition chip), generate simulation data under fault scenarios, and transmit the simulation data to the BMU under test so that the BMU under test can respond to the simulation data.

[0063] In one embodiment, such as Figure 2 The schematic diagram of the simulator 20 shown includes a controller 200. The controller 200 is used to load target fault scenarios from the target fault library that match the operating conditions of the battery management unit (BMU) under test. Then, it transmits the simulation data generated by the simulator running under the target fault scenarios to the BMU under test, so that the BMU under test outputs response data to the simulation data. The response data output by the BMU under test is used to characterize whether there is an anomaly in the operating logic of the BMU under test.

[0064] In the above embodiments, the target fault library includes fault scenarios obtained by multi-dimensional quantification of historical faults occurring in the target component. The target component may include a data acquisition component and a target BMU. The data acquisition component can be a data acquisition chip, such as a temperature acquisition chip, voltage acquisition chip, current acquisition chip, etc. The target BMU is a BMU other than the BMU under test. In one example, multiple BMUs also need to interact with each other. Therefore, it is necessary to test whether the response of the BMU under test to the fault is abnormal when other BMUs fail. That is, in this embodiment, the target BMU is the BMU to be simulated by the simulator.

[0065] It should be noted that using the data acquisition component and BMU as target components, allowing the simulator to simulate the target components, and then detecting the operating logic of the BMU under test based on the response of the BMU to the simulation data, can improve the comprehensiveness of BMU testing and thus improve the accuracy of BMU testing.

[0066] In addition, in the above embodiments, the dimensions for quantifying historical faults may include, but are not limited to, fault occurrence time, fault occurrence frequency, and fault occurrence duration. That is, in this embodiment, by extracting fault data corresponding to historical faults from fault occurrence time, fault occurrence frequency, and fault occurrence duration, a fault scenario can be obtained, which is more consistent with the actual scenario.

[0067] It should be noted that the fault scenario includes data obtained by quantifying the fault in multiple dimensions. Thus, during the BMU testing process, the scenario data of the fault in actual application is injected into the simulator, making the BMU test environment more closely resemble the actual operating environment. This improves the realism of the BMU's response to the simulation data and enhances the accuracy of the BMU test.

[0068] Furthermore, in the above embodiments, the operating condition corresponding to the BMU under test can be the operating condition of the system in which the BMU under test resides (e.g., a vehicle system). In one example, the host computer can monitor the BMU under test in real time to determine the operating condition of the system in which the BMU under test resides based on the operating status of the BMU under test, such as power-on condition, power-off condition, etc.

[0069] It should be noted that when injecting faults into the simulator, the target fault scenario corresponding to the operating conditions is injected into the simulator, making the simulator's operation more closely resemble the actual scenario. This makes the simulation data output by the simulator more accurate, and consequently, the BMU under test responds more realistically to the simulation data, thus improving the accuracy of BMU testing.

[0070] In one embodiment, such as Figure 2 As shown, the controller 200 includes: a system on chip (SoC) 201, a programmable logic device 202, and a communication circuit 203.

[0071] In this embodiment, the system-on-chip (SoC) can be connected to a target fault library to load target fault scenarios that match the operating conditions of the BMU under test, and run under the target fault scenarios to generate simulation data.

[0072] By loading fault scenarios from the target fault library, the simulator can generate simulation data that closely matches the actual fault scenarios, enabling the BMU under test to generate response data that closely matches the actual operating scenario. Analyzing this response data can improve the testing accuracy of the BMU under test.

[0073] In one embodiment, the programmable logic device 202 is used to convert simulation data into serial communication signals; the communication circuit 203 is used to transmit the serial communication signals to the BMU under test.

[0074] In this embodiment, the programmable logic device can be, but is not limited to, an FPGA (Field Programmable Gate Array), which connects to the SoC (System-on-a-Chip) via an AXI (Advanced Extensible Interface) bus. This AXI is used to generate simulation data by running the SoC under fault scenarios and convert the simulation data into serial communication signals, which are then transmitted to the BMU under test via a bus channel. The bus channel can include, but is not limited to, IO (Input / Output) channels, SPI (Serial Peripheral Interface) channels, UART (Universal Asynchronous Receiver / Transmitter) channels, and IIC (Integrated Circuit) channels. The channel for transmitting simulation data can be selected from among these channels according to the communication protocol supported by the BMU under test.

[0075] In addition, such as Figure 2 As shown, the communication circuit 203 is connected to the programmable logic device 202. This communication circuit can be a wireless communication module. In one example, the communication circuit can be connected to the programmable logic device via an I / O interface. The communication circuit can be an AFE (Analog Front End) communication simulation circuit, which can convert serial communication signals into daisy-chain signals and transmit the daisy-chain signals to the BMU under test through a daisy-chain channel.

[0076] By simulating real components (e.g., data acquisition chips) using a simulator, fault scenarios are injected into the simulator, simulating the operating state of the real components under fault conditions. The generated simulation data is then transmitted to the BMU under test. The operating logic of the BMU under test is tested based on the response results of the BMU under test. This eliminates the need to use real components, reducing the cost of testing the BMU under test. At the same time, since the fault scenarios simulate the actual operating conditions of real components, the test results of the BMU under test are more closely related to the actual scenario, improving the accuracy of the BMU test.

[0077] This concludes the introduction to the simulator provided in the embodiments of this application.

[0078] The following describes the detection method for the battery management unit executed by the simulator.

[0079] In one embodiment, Figure 3A flowchart illustrating the detection method for the battery management unit is shown, such as... Figure 3 As shown, the method may include the following steps S301 to S302:

[0080] Step S301: Load target fault scenarios from the target fault library that match the operating conditions of the battery management unit (BMU) under test.

[0081] In step S301, the operating condition corresponding to the BMU under test can be the operating condition of the system in which the BMU is located (e.g., a vehicle system). In one example, the host computer can monitor the BMU under test in real time to determine the operating condition of the system in which the BMU is located based on the operating status of the BMU under test, such as power-on condition, power-off condition, etc.

[0082] Additionally, in step S301, the target fault library includes fault scenarios obtained by multi-dimensional quantification of historical faults occurring in the target component. The target component may include a data acquisition component and a target BMU. The data acquisition component can be a data acquisition chip, such as a temperature acquisition chip, voltage acquisition chip, current acquisition chip, etc. The target BMU is a BMU other than the BMU under test. In one example, multiple BMUs also need to interact with each other; therefore, it is necessary to test whether the response of the BMU under test to the fault is abnormal when other BMUs fail. That is, in this embodiment, the target BMU is the BMU to be simulated by the simulator.

[0083] It should be noted that using the data acquisition component and BMU as target components, allowing the simulator to simulate the target components, and then detecting the operating logic of the BMU under test based on the response of the BMU to the simulation data, can improve the comprehensiveness of BMU testing and thus improve the accuracy of BMU testing.

[0084] In addition, in the above embodiments, the dimensions for quantifying historical faults may include, but are not limited to, fault occurrence time, fault occurrence frequency, and fault occurrence duration. That is, in this embodiment, by extracting fault data corresponding to historical faults from fault occurrence time, fault occurrence frequency, and fault occurrence duration, a fault scenario can be obtained, which is more consistent with the actual scenario.

[0085] It should be noted that the fault scenario includes data obtained by quantifying the fault in multiple dimensions. Thus, during the BMU testing process, the scenario data of the fault in actual application is injected into the simulator, making the BMU test environment more closely resemble the actual operating environment. This improves the realism of the BMU's response to the simulation data and enhances the accuracy of the BMU test.

[0086] Step S302: The simulation data generated by the simulator running under the target fault scenario is transmitted to the BMU under test so that the BMU under test outputs response data to the simulation data.

[0087] After obtaining the target fault scenario in step S302, the simulator can run under the target fault scenario and generate simulation data. This simulation data simulates the data generated by the real component running under the target fault scenario. After obtaining the simulation data, the simulator can transmit the simulation data to the BMU under test. The BMU under test can respond to the simulation data, for example, with an alarm response. The host computer can monitor the actual response result of the BMU under test and determine whether the response of the BMU under test is correct based on the actual response result. If it is correct, it can be determined that the operating logic of the BMU under test is normal; otherwise, it can be determined that the operating logic of the BMU under test is abnormal.

[0088] Based on the scheme defined in steps S301 to S303 above, it can be understood that in this embodiment, when injecting a fault into the simulator, a target fault scenario corresponding to the operating condition is injected into the simulator, making the simulator's operation more closely resemble the actual scenario. This results in more accurate simulation data output by the simulator, and consequently, a more realistic response of the BMU under test to the simulation data, improving the accuracy of BMU testing. Furthermore, in this embodiment, the fault scenario includes data obtained by multi-dimensional quantification of the fault. Therefore, during BMU testing, scenario data of the fault in actual application is injected into the simulator, making the BMU's testing environment more closely resemble the actual operating environment. This further improves the realism of the BMU's response to the simulation data and enhances the accuracy of BMU testing.

[0089] In one embodiment, the simulator, when transmitting simulation data to the BMU under test, can... Figure 4 The simulation data transmission method shown is implemented as follows: Figure 4 As shown, the process includes the following steps S401 to S403:

[0090] Step S401: Obtain the communication protocol corresponding to the BMU under test and multiple data transmission channels for communicating with the BMU under test;

[0091] Step S402: Determine the target transmission channel that matches the communication protocol from multiple data transmission channels;

[0092] Step S403: The simulation data running under the target fault scenario is transmitted to the BMU under test through the target transmission channel.

[0093] In the above embodiments, the multiple data transmission channels include at least daisy-chain channels and bus channels. The bus channels may include, but are not limited to, IO channels, SPI channels, UART channels, and IIC channels. The target transmission channel for transmitting simulation data can be selected from the multiple data transmission channels according to the communication protocol supported by the BMU under test.

[0094] By selecting an appropriate data transmission channel to transmit simulation data according to the communication protocol corresponding to the BMU under test, the accuracy of simulation data transmission can be improved, thereby improving the accuracy of the BMU's response to the simulation data and ultimately enhancing the accuracy of BMU testing.

[0095] This concludes the introduction to the detection method for the battery management unit provided in the embodiments of this application.

[0096] The host computer provided in the embodiments of this application will be described below.

[0097] Figure 5 A schematic diagram of the host computer structure is shown, such as... Figure 5 As shown, the host computer 100 includes: a working condition acquisition module 101, a fault acquisition module 102, and a fault injection module 103.

[0098] In this embodiment, the operating condition acquisition module is used to acquire the operating condition of the battery management unit (BMU) to be tested; the fault acquisition module is used to acquire a target fault scenario that matches the operating condition from the target fault database of stored fault scenarios; and the fault injection module is used to inject the target fault scenario into the simulator.

[0099] In the above embodiments, the target fault library includes fault scenarios obtained by multi-dimensional quantification of historical faults occurring in the target component. The relevant explanations of the fault scenarios have been explained above and will not be repeated here.

[0100] It should be noted that the host computer can execute the fault data injection method provided in the embodiments of this application, such as... Figure 6 As shown below, the method for injecting fault data provided in the embodiments of this application will be described with the host computer as the execution subject.

[0101] like Figure 6 As shown, the fault data injection method includes the following steps S601 to S603:

[0102] Step S601: Obtain the operating status of the battery management unit (BMU) to be tested.

[0103] In step S601, the operating condition corresponding to the BMU under test can be the operating condition of the system in which the BMU is located (e.g., a vehicle system). In one example, the host computer can monitor the BMU under test in real time to determine the operating condition of the system in which the BMU is located based on the operating status of the BMU under test, such as power-on condition, power-off condition, etc.

[0104] Step S602: Obtain the target fault scenario that matches the operating condition from the target fault scenario database of the stored fault scenarios.

[0105] In step S602, the target fault library includes fault scenarios obtained by multi-dimensional quantification of historical faults occurring in the target component. The target component may include a data acquisition component and a target BMU. The data acquisition component can be a data acquisition chip, such as a temperature acquisition chip, voltage acquisition chip, current acquisition chip, etc. The target BMU is a BMU other than the BMU under test. In one example, multiple BMUs also need to interact with each other; therefore, it is necessary to test whether the response of the BMU under test to the fault is abnormal when other BMUs fail. That is, in this embodiment, the target BMU is the BMU to be simulated by the simulator.

[0106] In addition, in step S602, the dimensions for quantifying historical faults may include, but are not limited to, fault occurrence time, fault occurrence frequency, and fault occurrence duration. That is, in this embodiment of the application, by extracting fault data corresponding to historical faults from fault occurrence time, fault occurrence frequency, and fault occurrence duration, a fault scenario can be obtained, which is more consistent with the actual scenario.

[0107] In this embodiment of the application, multiple fault scenarios can be obtained by performing multi-dimensional quantification on the same fault. In one example, after determining the operating conditions, the host computer can analyze the faults that the target component may produce under the operating conditions, and then obtain the fault scenario corresponding to each fault from the target fault database to obtain multiple fault scenarios.

[0108] Step S603: Inject the target fault scenario into the simulator.

[0109] In step S603, the host computer can control the simulator to traverse the target fault scenarios in the target fault library that match the operating conditions, and inject the traversed fault scenarios into the simulator so that the simulator runs under the fault scenarios and generates simulation data. Then, the simulator can transmit the simulation data to the BMU under test. The BMU under test can respond to the simulation data, for example, with an alarm response. The host computer monitors the actual response results of the BMU under test and determines whether the response of the BMU under test is correct based on the actual response results. If it is correct, it can be determined that the operating logic of the BMU under test is normal; otherwise, it can be determined that the operating logic of the BMU under test is abnormal.

[0110] Based on the scheme defined in steps S601 to S603 above, it can be understood that in this embodiment, when injecting a fault into the simulator, a target fault scenario corresponding to the operating condition is injected into the simulator, making the simulator's operation more closely resemble the actual scenario. This results in more accurate simulation data output by the simulator, and consequently, a more realistic response of the BMU under test to the simulation data, improving the accuracy of the BMU test. Furthermore, in this embodiment, the fault scenario includes data obtained by multi-dimensional quantification of the fault. Therefore, during the BMU testing process, the fault is no longer simply injected into the simulator, but rather scenario data of the fault in actual application is injected into the simulator. This makes the test environment of the BMU under test more closely resemble the actual operating environment, thereby improving the realism of the BMU's response to the simulation data and increasing the accuracy of the BMU test.

[0111] The following describes the specific implementation process of the fault data injection method provided in the embodiments of this application.

[0112] After obtaining the operating conditions corresponding to the BMU to be tested, the target fault scenarios that match the operating conditions need to be injected into the simulator. The target fault scenarios are stored in the target fault library, which can be obtained by analyzing the historical fault scenarios of each component.

[0113] In one embodiment, before obtaining a target fault scenario matching the operating condition from the target fault scenario library of stored fault scenarios, firstly, the fault type and fault cause of at least one historical fault of the target component are obtained; then, based on the fault type and fault cause, the fault scenario corresponding to each historical fault is determined; and then, based on the fault scenario corresponding to at least one historical fault, the target fault library is constructed.

[0114] In the above embodiments, the historical faults of the target component can be faults generated by the target component during its operation at historical moments, for example, such as Figure 7 The diagram shown illustrates the types of data acquisition chips, from...Figure 7 It is known that the types of faults in data acquisition chips may include, but are not limited to, daisy-chain communication failures, sampling line disconnection failures, equalization circuit failures, chip failures, voltage failures, and temperature failures.

[0115] In one example Figure 8 The fault types of the AFE chip are shown, such as... Figure 8 It can be seen that the AFE chip can include 11 types of faults, EV1-EV11. EV1 represents a detection fault in the multiplexer decoder; EV2 represents a fault where the reference voltage is less than the lower limit (e.g., 2990mV) or greater than the upper limit (e.g., 3014mV); EV3 represents a power supply voltage detection fault; EV4 represents a voltage sampling channel fault in the redundant digital differential converter (e.g., a difference between the sampled values ​​of the redundant digital differential converter and the main digital differential converter indicates a fault in the redundant digital differential converter); EV5 represents a digital filter fault (e.g., a signal conversion result from the digital filter does not match expectations indicates a fault in the digital filter); EV6 represents an ADC (Anatomy to Digital) fault. Converter (analog-to-digital converter) sampling faults, such as two ADCs sampling the same voltage, and the difference between the voltage values ​​sampled by the two ADCs being greater than a preset value (e.g., 3mV); EV7 indicates a register write fault; EV8 indicates an auxiliary channel (e.g., a general-purpose input / output interface) fault; EV9 indicates a current source fault; EV10 indicates a general-purpose input / output interface fault; EV11 indicates a redundant digital differential / differential converter injection fault.

[0116] In another example, Figure 9 The causes of failure in the battery cell voltage sampling chip are shown, such as... Figure 5 It can be seen that cell voltage sampling chips can be classified into four main categories of faults: module faults, Pack sampling line connection circuit faults, BMS (Battery Management System) faults, and external abnormal interference faults. Module faults include abnormal copper bar connections, abnormal cell components, and abnormal nickel sheet soldering or bonding. Pack sampling line connection circuit faults include abnormal FPC connector soldering and abnormal sampling line harnesses or connectors. BMS faults include BMS hardware faults and BMS software malfunctions. BMS hardware faults include poor conformal coating on the cell voltage sampling channel and hardware component failures. Hardware component failures include faulty sampling chip components, sampling circuit component failures, and sampling chip EOS (Electrical Over Stress).

[0117] After obtaining the fault types and causes of historical faults, a multi-dimensional analysis of the fault causes can be performed to obtain the fault scenarios corresponding to each fault. By constructing the correspondence between fault scenarios and fault types, the target fault library can be obtained.

[0118] By constructing a target fault library, multiple fault scenarios corresponding to a fault can be directly obtained from the target fault library during fault injection. Thus, when injecting a fault, not only a single fault is injected, but also the corresponding scenario is injected, making the test scenario of BMU more consistent with the actual operation scenario and improving the accuracy of BMU testing.

[0119] In one embodiment, when determining the fault scenario corresponding to each historical fault based on the fault type and fault cause, the host computer can analyze the fault cause and determine the fault data corresponding to each fault type; then, extract the fault data corresponding to each fault type from multiple dimensions to obtain the dimension data corresponding to each dimension; and then combine the dimension data of multiple dimensions to obtain the fault scenario corresponding to each historical fault.

[0120] In the above embodiments, multiple dimensions include fault occurrence time, fault occurrence frequency, and fault occurrence duration. For example, for Figure 8 The EV2 fault, occurring within 1000ms of BMU power-on, with a fault occurrence frequency of 1 and a fault duration of 100ms, is characterized by a 500mV deviation from the reference voltage within 100ms of power-on. Multiple fault scenarios corresponding to the EV2 fault can be obtained by adjusting one or more of the fault occurrence time, frequency, and duration.

[0121] By quantifying the faults from multiple dimensions, we can obtain multiple fault scenarios that correspond to the actual operating scenarios of the BMU under test. Testing the BMU under these fault scenarios will yield accurate test results.

[0122] It should be noted that the fault scenarios corresponding to the faults are constantly changing. In order to improve the target fault database, the fault scenarios in the target fault database can be updated in practical applications.

[0123] In one embodiment, before constructing a target fault library based on fault scenarios corresponding to multiple historical faults, the host computer may also respond to the user's input scenario selection instruction to determine the fault scenario to be adjusted from the fault scenarios corresponding to multiple historical faults; then, in response to the user's input scenario adjustment instruction, the fault scenario to be adjusted is adjusted to obtain the adjusted fault scenario.

[0124] In one example, the user can adjust one or more of the frequency factor, fault occurrence time, and fault occurrence duration of the fault scenario injected into the SoC via the host computer, thereby adding new fault scenarios and making all fault scenarios corresponding to the fault cover the entire test range of the BMU as much as possible.

[0125] By adjusting the fault scenarios and improving the target fault library, all fault scenarios corresponding to the faults can be covered in the entire BMU testing scope, thereby improving the accuracy of BMU testing.

[0126] Furthermore, after obtaining the adjusted fault scenarios, the host computer can construct a target fault library based on the fault scenarios corresponding to multiple historical faults and the adjusted fault scenarios. By updating and improving the target fault library, all fault scenarios corresponding to the faults can cover the entire test range of the BMU, thereby improving the accuracy of BMU testing.

[0127] After the target fault library is built, the target fault scenarios can be obtained from the target fault library and injected into the simulator when testing the BMU.

[0128] In one embodiment, Figure 10 A flowchart illustrating the simulator injecting fault scenarios is shown, such as... Figure 10 As shown, the process includes the following steps S1001 to S1003:

[0129] Step S1001: Obtain the runtime sequence of the BMU to be tested;

[0130] Step S1002: Determine the scenario injection time of the target fault scenario based on the runtime sequence of the BMU to be tested and the fault occurrence time of the target fault scenario.

[0131] Step S1003: Starting from the scene injection time, inject the target fault scene into the simulator according to the fault occurrence frequency.

[0132] In the above embodiments, the runtime sequence of the BMU under test may include, but is not limited to, power-on sequence and power-off sequence. For example, when the BMU under test is powered on, the host computer can traverse the target fault database to obtain the target faults that the target component may experience when the BMU under test is powered on. Then, the target fault scenario corresponding to the target fault is obtained, and the simulator is controlled to run under the target fault scenario. The generated simulation data is then transmitted to the BMU under test, thereby solving the problem of low fault injection efficiency caused by manually injecting a single fault value. At the same time, since what is injected into the simulator is a fault scenario, rather than a simple fault value, the simulator can simulate simulation data that closely matches the actual working conditions, thus improving the accuracy of BMU testing.

[0133] In one embodiment, after injecting the target fault scenario into the simulator, the host computer can also obtain the actual response results of the BMU under test in response to the simulation data, and determine the test results of testing the operating logic of the BMU under test based on the actual response results.

[0134] In the above embodiments, the simulation data is the data generated by the simulator running under the target fault scenario. That is, in this embodiment, the host computer can control the simulator to run under the fault scenario corresponding to the fault. The BMU under test responds to the simulation data generated by the simulator. By detecting the response result of the BMU under test to the simulation data, the operating logic of the BMU under test is tested. This process does not require injecting faults into the BMU under test, reducing the complexity of the BMU testing and improving the efficiency of the BMU testing. At the same time, testing the operating logic of the BMU under test under the fault scenario can improve the accuracy of the BMU testing.

[0135] In one embodiment, when determining the test result of testing the operating logic of the BMU to be tested based on the actual response result, the host computer can obtain the expected response result and compare the expected response result with the actual response result. If the actual response result does not match the expected response result, it is determined that the operating logic of the BMU to be tested is abnormal. If the operating logic of the BMU is abnormal, the abnormal data of the BMU to be tested is recorded.

[0136] In the above embodiments, the expected response result is used to characterize the response result of the BMU to the simulation data when the operating logic in the BMU under test meets the preset conditions. The preset conditions can be relevant conditions indicating that the operating logic of the BMU is normal; the expected response result corresponding to the BMU can also be stored in the target fault library, so that the expected response result corresponding to the target fault scenario can be obtained at the same time as the target fault scenario is obtained.

[0137] In addition, when it is determined that the BMU under test has an abnormal operating logic, the host computer can record the abnormal data of the BMU under test. This abnormal data includes, but is not limited to, the fault scenario corresponding to the abnormal operating logic of the BMU under test, the error response results generated by the BMU under test, and the runtime sequence of the BMU under test.

[0138] The test results of the BMU under test are determined based on the actual response results of the BMU under test, and the abnormal data when the BMU's operating logic is abnormal is recorded so that the abnormality can be handled manually, thereby improving the robustness of the BMU's operating logic design.

[0139] This concludes the explanation of the fault data injection method provided in the embodiments of this application.

[0140] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0141] In one embodiment, this application also provides a readable storage medium storing computer program instructions that, when executed by a processor, implement the above-described battery management unit detection method and / or fault data injection method.

[0142] In one embodiment, this application also provides a computer program product in which the instructions, when executed by the processor of an electronic device, cause the electronic device to perform the above-described battery management unit detection method and / or fault data injection method.

[0143] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0144] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0145] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0146] The flowcharts and / or block diagrams above, referring to embodiments of the battery management unit detection method, system, and fault data injection method according to embodiments of this application, have described various aspects of this application. It should be understood that each block in the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to create a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowcharts and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0147] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application. In particular, as long as there is no structural conflict, the various technical features mentioned in the embodiments can be combined in any way. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A method of detecting a battery management unit, characterized by, Applied to the simulator, comprising: loading a target fault scene matching the operating condition of the battery management unit (BMU) to be tested from a target fault library, wherein the target fault library comprises fault scenes obtained by multi-dimensionally quantifying historical faults of a target component; transmitting simulation data generated by running the simulator under the target fault scene to the BMU to be tested, so that the BMU to be tested outputs response data for the simulation data.

2. The method of claim 1, wherein, The simulation data generated by running the simulator under the target fault scene is transmitted to the BMU to be tested, comprising: obtaining a communication protocol corresponding to the BMU to be tested and a plurality of data transmission channels for communicating with the BMU to be tested; determining a target transmission channel matching the communication protocol from the plurality of data transmission channels; transmitting the simulation data running under the target fault scene to the BMU to be tested through the target transmission channel.

3. The method according to claim 1 or 2, characterized in that, The target component comprises a data acquisition component and a target BMU, wherein the target BMU is a BMU other than the BMU to be tested.

4. A method of injecting fault data, characterized by, Applied to the host computer, comprising: obtaining the operating condition of the battery management unit (BMU) to be tested; obtaining a target fault scene matching the operating condition from a target fault library storing fault scenes, wherein the target fault library comprises fault scenes obtained by multi-dimensionally quantifying historical faults of a target component; injecting the target fault scene into a simulator.

5. The method of claim 4, wherein, Before obtaining the target fault scene matching the operating condition from the target fault library storing fault scenes, the method further comprises: obtaining the fault type and fault reason of at least one historical fault of the target component; determining the fault scene corresponding to each historical fault according to the fault type and fault reason; constructing the target fault library based on the fault scenes corresponding to the at least one historical fault.

6. The method of claim 5, wherein, According to the fault type and fault reason, determining the fault scene corresponding to each historical fault, comprising: analyzing the fault reason to determine the fault data corresponding to each fault type; extracting data from multiple dimensions to obtain dimension data corresponding to each dimension, wherein the multiple dimensions include fault occurrence time, fault occurrence frequency, and fault occurrence duration; combining the dimension data of the multiple dimensions to obtain the fault scene corresponding to each historical fault.

7. The method of claim 6, wherein, Injecting the target fault scene into the simulator, comprising: obtaining the runtime sequence of the BMU to be tested; determining the scene injection time of the target fault scene according to the runtime sequence of the BMU to be tested and the fault occurrence time of the target fault scene; injecting the target fault scene into the simulator starting from the scene injection time according to the fault occurrence frequency.

8. The method of claim 4, wherein, After injecting the target fault scene into the simulator, the method further comprises: acquire an actual response result of the BMU to be tested to simulation data, wherein the simulation data is generated by the simulator running under the target fault scenario; determine a test result of testing the running logic of the BMU to be tested based on the actual response result.

9. The method of claim 8, wherein, determine a test result of testing the running logic of the BMU to be tested based on the actual response result, comprising: acquire an expected response result, wherein the expected response result is used to represent a response result made to the simulation data in a case where the running logic in the BMU to be tested meets a preset condition; determine that the running logic of the BMU to be tested is abnormal in a case where the actual response result does not match the expected response result; record abnormal data of the BMU to be tested in a case where the running logic of the BMU is abnormal.

10. An emulator, characterized by comprise: a controller configured to load a target fault scenario matching a running condition of a battery management unit (BMU) to be tested from a target fault library, wherein the target fault library comprises fault scenarios quantified in multiple dimensions based on historical faults of a target component; the controller is further configured to transmit simulation data generated by the simulator running under the target fault scenario to the BMU to be tested, so that the BMU to be tested outputs response data to the simulation data, and the response data output by the BMU to be tested is used to represent whether the running logic of the BMU to be tested is abnormal.

11. The emulator of claim 10, wherein, the controller comprises: a system on chip (SoC) configured to load the target fault scenario matching the running condition of the BMU to be tested from the target fault library; the SoC is further configured to generate the simulation data by running under the target fault scenario.

12. The emulator of claim 11, wherein, the controller further comprises: a programmable logic device configured to convert the simulation data into a serial communication signal; a communication circuit configured to transmit the serial communication signal to the BMU to be tested.

13. A host computer, comprising: comprise: a condition acquisition module configured to acquire a running condition of a battery management unit (BMU) to be tested; a fault acquisition module configured to acquire a target fault scenario matching the running condition from a target fault library storing fault scenarios, wherein the target fault library comprises fault scenarios quantified in multiple dimensions based on historical faults of a target component; a fault injection module configured to inject the target fault scenario into a simulator.

14. A battery management unit detection system, comprising: comprise: the host computer of claim 13 and the simulator of any one of claims 10 to 12.

15. A readable storage medium, characterized by, A computer program instruction is stored on a readable storage medium, and the computer program instruction is executed by a processor to implement a battery management unit detection method according to any one of claims 1-3, and / or a fault data injection method according to any one of claims 4-9.

16. A computer program product, characterised in that, The instructions in the computer program product, when executed by a processor of an electronic device, cause the electronic device to perform the detection method of the battery management unit as claimed in any one of claims 1-3, and / or the injection method of the fault data as claimed in any one of claims 4-9.

Images