Test device, test system and test method

Abstract

The application discloses a test device, a test system and a test method. The test device comprises a communication device and a fault simulation device which are connected with each other. The communication device is used for receiving battery state data of a battery device in a battery system, and sending the battery state data to the fault simulation device. The fault simulation device is used for obtaining a fault data type and a fault data range corresponding to a fault type to be tested, modifying data belonging to the fault data type in the battery state data to be within the fault data range, keeping data not belonging to the fault data type unchanged, obtaining fault state data, and sending the fault state data to the communication device. The communication device is used for sending the fault state data to a main battery management unit in the battery system, so as to test the main battery management unit. Since all the data in the fault state data except the modified part is real data collected from the battery device, the fault state data is closer to a real fault state, and the test authenticity and reliability can be improved.

Description

Technical Field

[0001] This application relates to the field of testing technology, specifically to a testing device, a testing system, and a testing method. Background Technology

[0002] As the power source for electric ships or the energy storage carrier for energy storage power stations, the safety and reliability of battery systems are of paramount importance. The safe operation of battery systems depends on accurate condition monitoring of the battery devices and timely fault protection.

[0003] Therefore, in order to improve the reliability of battery system operation, a solution is needed to test the battery system.

[0004] The above statements are for the purpose of providing background information in relation to this application only and do not necessarily constitute prior art. Summary of the Invention

[0005] In view of the above problems, this application provides a testing device, testing system and testing method, which can modify the data of the fault data type corresponding to the fault type to be tested in the real battery state data of the battery device to be within the fault data range, while the data that does not belong to the fault data type remains unchanged, thereby obtaining fault state data. The fault state data is sent to the main battery management unit to test the fault identification capability of the main battery management unit. Since the fault state data, except for the modified part of the data, is all real data collected from the battery device, it is closer to the real fault state, which can improve the authenticity and reliability of the test.

[0006] In a first aspect, this application provides a testing apparatus, comprising: a communication device and a fault simulation device interconnected; the communication device is used to connect to a battery system, receive battery state data of the battery devices in the battery system, and send the battery state data to the fault simulation device; the fault simulation device is used to modify the battery state data to obtain fault state data and send the fault state data to the communication device; the communication device is also used to send the fault state data to the main battery management unit in the battery system to test the main battery management unit; wherein, the fault simulation device is specifically used to obtain the fault data type and fault data range corresponding to the fault type to be tested; modify the data in the battery state data that belongs to the fault data type to be within the fault data range, and leave the data that does not belong to the fault data type unchanged, to obtain the fault state data.

[0007] Therefore, the communication device can receive battery status data from the battery unit in the battery system and send it to the fault simulation device. The fault simulation device modifies the data of the fault type corresponding to the fault to be tested in the real battery status data of the battery unit to be within the fault data range, while leaving the data of the non-fault type unchanged, thus obtaining fault status data. This fault status data is then sent to the main battery management unit to test the fault identification capability of the main battery management unit. Since the main battery management unit receives a large amount of battery status data during normal operation and identifies faults from it, and the fault status data, except for the modified data, is all real battery status data collected from the battery unit, it is closer to the real state. This allows for testing the main battery management unit's ability to accurately identify faults from a large amount of real battery status data, thereby improving the realism and reliability of the test.

[0008] Moreover, fault simulation equipment generates fault state data by modifying data belonging to the fault data type in battery state data to the fault data range, which can quickly simulate different types of faults and improve the efficiency and diversity of testing.

[0009] In some embodiments, the communication device is configured to connect to a main battery management unit and a slave battery management unit in a battery system, receive battery status data sent by the slave battery management unit, and send fault status data to the main battery management unit; the slave battery management unit is connected to a battery device and is configured to obtain battery status data of the battery device.

[0010] In this way, the testing device connects to both the slave battery management unit (SBMU) and the main battery management unit (MBMU) via communication equipment. It can receive battery status data obtained from the battery device by the SBMU and send fault status data simulated by the fault simulation device to the MBMU, thus integrating into the existing communication link of the battery system and establishing a complete communication link from battery status data acquisition to fault status data injection. This allows for testing of the MBMU's fault identification and response capabilities without altering the internal hardware structure and connections of the battery system, significantly improving testing convenience.

[0011] In some embodiments, the slave battery management unit is also connected to the master battery management unit; the fault simulation device is used to send a first control command to the communication device before sending fault status data to the communication device; the communication device is used to send the first control command to the slave battery management unit to control the slave battery management unit to stop sending signals to the master battery management unit.

[0012] In this way, by first controlling the battery management unit to stop sending signals to the main battery management unit, and then sending fault status data to the main battery management unit, the main battery management unit can successfully receive accurate fault status data, reducing the possibility of interference from battery status data sent by the battery management unit, thereby improving the stability and reliability of the test.

[0013] In some embodiments, the communication device is configured to receive target response information of the battery system to fault state data and send the target response information to the fault simulation device; the fault simulation device is configured to determine the test result of the battery system based on the target response information and the preset response information corresponding to the fault state data.

[0014] In this way, by comparing the target response information of the battery system's actual response with the preset response information, the fault simulation equipment can automatically determine whether the battery system's identification and response to a specific fault are correct, thereby automatically obtaining test results, which helps to improve the automation and efficiency of testing.

[0015] In some embodiments, the fault simulation device is used to determine, based on the consistency between the target response information and the preset response information, that the test result is that the battery system responds correctly to the fault state data.

[0016] In this way, the fault simulation equipment can determine whether the battery system is responding correctly to the fault state data when the target response information and the preset response information are consistent. It can automatically determine whether the battery system is correctly identifying and responding to a specific fault, which is beneficial to improving the automation and efficiency of testing.

[0017] In some embodiments, the communication device supports multiple communication protocols, and is used to select a communication protocol that matches the communication protocol of the battery system from among the multiple communication protocols for communication.

[0018] In this way, by supporting multiple communication protocols and selecting the matching communication protocol according to the communication protocol of the battery system, the communication device can be adapted to battery systems with different communication protocols, which is beneficial to improving the versatility and compatibility of the testing device.

[0019] In some embodiments, the communication device is connected to the battery system via the battery system's communication interface.

[0020] In this way, the communication device connects to the battery system through the battery system's communication interface, enabling data exchange between the testing device and the battery system without changing the battery system's internal structure or wiring, which helps improve the convenience and safety of testing.

[0021] Secondly, this application provides a testing system, including: a testing apparatus and a battery system as shown in any embodiment of the first aspect.

[0022] In some embodiments, the battery system includes: a controller; the controller is connected to a main battery management unit and a safety protection device, and is configured to receive target response information of the main battery management unit to fault state data, generate a second control command based on the target response information, send the second control command to the safety protection device, and determine the test result of the battery system based on the execution result of the safety protection device, wherein the second control command is used to control the safety protection device to perform safety protection actions.

[0023] In this way, the controller controls the safety protection device to perform safety protection actions based on the target response information of the main battery management unit, and determines the test results based on the execution results of the safety protection device. This can verify whether the main battery management unit correctly identifies and responds to fault status data from the execution level of the safety protection device, and can also test whether the controller's response is correct, as well as whether the communication between the main battery management unit and the controller is normal, which helps to improve the comprehensiveness and reliability of the test.

[0024] In some embodiments, the method further includes: the battery system includes: a display; the display is connected to the main battery management unit, for receiving target response information of the main battery management unit to fault state data, and displaying the target response information to determine the test results of the battery system based on the target response information.

[0025] In this way, by displaying the target response information of the main battery management unit on the monitor, testers can intuitively understand the test results of the battery system, which helps to improve the convenience of testing.

[0026] Thirdly, this application provides a testing method, comprising: receiving battery state data of a battery device in a battery system; modifying the battery state data to obtain fault state data; sending the fault state data to a main battery management unit in the battery system to test the main battery management unit; wherein modifying the battery state data to obtain fault state data comprises: obtaining the fault data type and fault data range corresponding to the fault type to be tested; modifying the data in the battery state data belonging to the fault data type to fall within the fault data range, while leaving the data not belonging to the fault data type unchanged, thereby obtaining the fault state data.

[0027] Therefore, the communication device can receive battery status data from the battery unit in the battery system and send it to the fault simulation device. The fault simulation device modifies the data of the fault type corresponding to the fault to be tested in the actual battery status data of the battery unit to bring it within the fault data range, while leaving the data of the non-fault type unchanged, thus obtaining fault status data. This fault status data is then sent to the main battery management unit to test the fault identification capability of the main battery management unit. Since the fault status data, except for the modified data, is all real data collected from the battery unit, it is closer to the actual fault state, which can improve the authenticity and reliability of the test.

[0028] Moreover, fault simulation equipment generates fault state data by modifying data belonging to the fault data type in battery state data to the fault data range, which can quickly simulate different types of faults and improve the efficiency and diversity of testing.

[0029] In some embodiments, the method further includes: receiving target response information of the battery system to fault state data; and determining the test result of the battery system based on the target response information and preset response information corresponding to the fault state data.

[0030] In this way, by comparing the target response information of the battery system's actual response with the preset response information, it is possible to automatically determine whether the battery system's identification and response to a specific fault are correct, thereby automatically obtaining test results, which is conducive to improving the automation and efficiency of testing.

[0031] In some embodiments, the test result of the battery system is determined based on the target response information and the preset response information corresponding to the fault state data, including: if the target response information and the preset response information are consistent, the test result is determined to be that the battery system responds correctly to the fault state data.

[0032] Thus, by determining that the battery system responds correctly to the fault state data when the target response information and the preset response information are consistent, the battery system's ability to identify specific fault types can be accurately tested, which helps to improve the accuracy of the test.

[0033] In some embodiments, battery state data includes data on the battery device in a high-voltage state.

[0034] In this way, fault state data can be simulated using real high-voltage battery state data when the battery system is under high voltage conditions. This allows for testing the battery system's fault identification capability under realistic high-voltage operating conditions, improving the realism and reliability of the test. Simultaneously, since it is not necessary for the battery device to actually malfunction under high voltage conditions, the risk of battery device damage and safety arising from physical fault simulation is reduced, thus enhancing the safety and feasibility of the test.

[0035] 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

[0036] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiments below. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is one of the structural schematic diagrams of a testing device provided in some embodiments of this application; Figure 2 This is a second schematic diagram of the structure of a testing device provided in some embodiments of this application; Figure 3 This is the third schematic diagram of a testing device provided in some embodiments of this application; Figure 4 Fourth schematic diagram of a testing device provided in some embodiments of this application; Figure 5 Fifth schematic diagram of a testing device provided in some embodiments of this application; Figure 6 This application provides one of the structural schematic diagrams of a testing system according to some embodiments; Figure 7 This is a second schematic diagram of the structure of a testing system provided in some embodiments of this application; Figure 8 This is the third schematic diagram of the structure of a testing system provided in some embodiments of this application; Figure 9 Fourth schematic diagram of a test system provided in some embodiments of this application; Figure 10 One of the flowcharts for a testing method provided in some embodiments of this application; Figure 11This is a second flowchart of a testing method provided for some embodiments of this application.

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

[0038] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

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

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

[0041] In this document, the term "embodiment" means that a particular 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 throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

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

[0043] 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).

[0044] In the description of the embodiments of this application, the term "determine" may encompass a wide variety of actions. For example, "determine" may include calculation, operation, processing, deduction, investigation, search (e.g., searching in a table, database, or other data structure), assertion, etc. Furthermore, "determine" may include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. In addition, "determine" may include parsing, selecting, picking, building, etc.

[0045] In this application, the battery cell can be a rechargeable battery, which refers to a battery cell that can be recharged after discharge to activate the active materials and continue to be used. A battery cell generally includes an electrode assembly. The electrode assembly includes a positive electrode, a negative electrode, and a separator. During the charging and discharging process of the battery cell, active ions (e.g., lithium ions) repeatedly insert and extract between the positive and negative electrodes. The separator is positioned between the positive and negative electrodes to prevent short circuits while allowing active ions to pass through.

[0046] The Battery Management System (BMS) of this application is used to perform at least one of the following functions for individual battery cells: state monitoring, state analysis, charge / discharge control, safety protection, thermal management, high-voltage power distribution, and information management. In addition, the BMS of this application can also perform the functions of a controller in an electrical device, such as a vehicle control unit (VCU) or a motor control unit (MCU), etc., and this application does not impose any limitations on this.

[0047] It should be noted that the BMS in this application can be integrated as a controller into the battery device, such as into the battery pack or energy storage box; the BMS in this application can also be integrated as a controller into the power-consuming device, such as into the vehicle or vehicle chassis; the BMS in this application can also be integrated as a controller into the charging device, such as into the charging device or battery swapping device; the BMS in this application can also be deployed as control software on a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, such as vehicle networking cloud, application (APP) backend, etc.

[0048] As the power source for electric ships or the energy storage carrier for energy storage power stations, the safety and reliability of battery systems are of paramount importance, thus subject to stringent industry certification requirements. The safe operation of battery systems depends on accurate condition monitoring and timely fault protection of the battery devices. Therefore, to improve the reliability of battery system operation, a testing solution for battery systems is needed.

[0049] This application provides a testing device, testing system, and testing method. It can receive battery state data from a battery device in a battery system, modify data belonging to the fault type under test within the actual battery state data of the battery device to fall within the fault data range, while leaving data not belonging to the fault data type unchanged, thereby obtaining fault state data. This fault state data is then sent to the main battery management unit to test the fault identification capability of the main battery management unit. Since the fault state data, except for the modified data, consists entirely of real data collected from the battery device, it more closely reflects the actual fault state, improving the realism and reliability of the test.

[0050] The testing apparatus, testing system, and testing method provided in some embodiments of this application can be used to test any battery system. For example, the testing apparatus, testing system, and testing method provided in the embodiments of this application can be used to test a box-type power supply system applied to a ship.

[0051] First, combined Figure 1 The testing apparatus provided in the embodiments of this application will be described in detail.

[0052] Figure 1 This illustration shows one of the structural schematic diagrams of a testing apparatus provided in one embodiment of this application. Figure 1 As shown, the testing device 100 may include: a communication device 110 and a fault simulation device 120 that are interconnected; Communication device 110 can be used to connect to battery system 200, receive battery status data of battery device 210 in battery system 200, and send battery status data to fault simulation device 120. The fault simulation device 120 can be used to modify battery status data, obtain fault status data, and send the fault status data to the communication device 110. The communication device 110 can also be used to send fault status data to the main battery management unit in the battery system 200 for testing the main battery management unit.

[0053] The communication device 110 and the fault simulation device 120 can be connected via wired or wireless means. The communication device 110 and the battery system 200 can also be connected via wired or wireless means. The communication device 110 and the battery system 200 can establish a connection when testing is required and disconnect when testing is not required or after testing is completed.

[0054] The communication device 110 can be a device with data transmission and reception capabilities. The communication device 110 can realize data interaction between the test device and the battery system 200. The communication device 110 can support one or more communication protocols, such as Controller Area Network (CAN) protocol, Modbus protocol, etc. CAN can be an effective serial communication network supporting distributed control systems, a serial communication protocol bus that can be used for real-time applications. The CAN bus adopts a multi-master control structure and a non-destructive arbitration mechanism, supports broadcast communication, and its physical layer includes twisted-pair transmission medium and terminating resistor design. The data link layer covers frame structures such as standard frames (11-bit identifiers) and extended frames (29-bit identifiers).

[0055] The fault simulation device 120 can be a device with data processing capabilities, which can be used to modify the received battery status data to simulate fault status data. The fault simulation device 120 can be implemented by software, hardware, or a combination of software and hardware, such as a computer device, embedded device, or dedicated hardware device running a fault simulation program.

[0056] The battery system 200 may include a battery device 210, which can be used to provide electrical power to electrical devices or to store energy. For example, the battery system 200 may be a box-type power system for electric ships or an energy storage system for energy storage power stations. The battery device 210 may include one or more battery cells.

[0057] The battery device 210 in this embodiment can be a fault-free battery device; in other words, it can be a normal, qualified battery device. Thus, the battery state data of the battery device 210 can be normal battery state data without fault state data. The fault state data obtained by the fault simulation device 120 after modifying this battery state data only contains the fault generated by the fault simulation device 120, and does not contain other fault state data caused by faults in the battery device 210 itself. Therefore, interference from other faults can be isolated, which is beneficial for accurately testing the main battery management unit's ability to identify specific faults. It can also test whether the main battery management unit will identify unmodified normal battery state data as a fault.

[0058] Battery status data can be collected and output by the battery management unit in the battery system 200. The battery status data can be data related to the operating status of the battery device 210. For example, the battery status data can include the cell identifier of each cell and the status data of the cell corresponding to that cell identifier. The cell identifier can be used to uniquely identify a cell in the battery device 210, and the status data can characterize the operating status of that cell. The status data can include, but is not limited to, at least one of voltage data, temperature data, current data, and insulation data. For example, the battery status data can include cell number #05 and its corresponding voltage data 3.5V and temperature data 27°C. Thus, the fault simulation device 120 can locate the target cell based on the cell identifier and modify the status data corresponding to the target cell to simulate the fault status data of the target cell.

[0059] The fault state data can be data used to simulate the state of the battery device 210 when a fault occurs. The fault state data may include at least one of the following: abnormal voltage data (such as overvoltage data or undervoltage data), abnormal temperature data (such as overtemperature data), and abnormal current data of the cells in the battery device 210. The fault simulation device 120 can generate fault state data by modifying one or more of the state data in the battery state data, so that the battery system 200 can trigger the corresponding fault identification and protection logic after receiving the fault state data.

[0060] Testing the battery system 200 can refer to testing its fault identification and response capabilities. Specifically, this can be done by sending fault status data to the battery system 200 and verifying whether it can correctly identify and respond to the fault status data, thus obtaining test results. The test results can reflect the battery system 200's ability to identify and respond to specific faults, thereby assessing the reliability of the battery system 200.

[0061] Specifically, during the testing process, the data flow can include two directions: the first direction is that the communication device 110 receives battery status data from the battery system 200 to obtain the real battery status data of the battery device 210 as the basis for fault simulation; the second direction is that the communication device 110 sends the fault status data generated by the fault simulation device 120 to the battery system 200 to trigger the fault identification and response of the battery system 200 and complete the test of the battery system 200.

[0062] Therefore, the communication device 110 can receive battery status data from the battery device 210 in the battery system 200 and send it to the fault simulation device 120. The fault simulation device 120 modifies the battery status data to obtain fault status data, and then the communication device 110 sends the fault status data to the battery system 200 for testing. Since the fault status data sent to the battery system is obtained by modifying the actual battery status data of the battery device, this fault status data is based on real data and is closer to real fault scenarios. Therefore, the fault identification capability of the battery system 200 can be tested under real working conditions, improving the authenticity and reliability of the test.

[0063] In this embodiment, the testing device 100 includes a communication device 110 and a fault simulation device 120, requiring no additional hardware configuration, which helps reduce the system complexity, hardware cost, and deployment difficulty of the testing device 100. Furthermore, fault testing can be achieved simply by communicating with the battery system 200 through the communication device 110, without altering the internal hardware structure and connections of the battery system 200, nor requiring high-performance computing equipment or substantial computing resources, making it easily applicable to different testing scenarios. In addition, the fault simulation device 120 modifies the actual battery state data of the battery device 210 to obtain fault state data, allowing for flexible simulation of different faults, which improves the flexibility and real-time performance of fault testing.

[0064] In this embodiment, the communication device 110 receives the actual battery status data of the battery device 210 in the battery system 200, and the fault simulation device 120 modifies the actual battery status data into fault status data before sending it to the battery system 200 for testing. Compared with the method of directly injecting preset fault codes into the battery system 200 for testing, this embodiment tests the battery system 200's ability to identify and respond to faults based on the status data of the battery device 210 when a fault occurs, while the method of directly injecting preset fault codes tests the battery system 200's ability to identify preset fault codes. Therefore, this embodiment can more comprehensively test the battery system 200's fault identification and response capabilities throughout the entire process during actual operation.

[0065] In some embodiments, the fault simulation device 120 can be used to obtain the fault data type and fault data range corresponding to the fault type to be tested; and modify the data in the battery status data that belongs to the fault data type to be within the fault data range to obtain the fault status data.

[0066] The fault type to be tested can be any fault type to be tested in this test. This test will examine whether the battery system can accurately identify and respond to the fault of the fault type to be tested. Therefore, this test will simulate the fault state data corresponding to the fault type to be tested. For example, the fault type to be tested can be, but is not limited to, at least one of the following: cell overvoltage fault, cell undervoltage fault, cell overtemperature fault, and cell overcurrent fault.

[0067] The fault data type can be the data parameter type corresponding to the type of fault being tested. For example, the fault data type corresponding to a cell overvoltage fault can be voltage data, and the fault data type corresponding to a cell overtemperature fault can be temperature data.

[0068] The fault data range can be a numerical range used to simulate faults. For example, the fault data range corresponding to a cell overvoltage fault can be a numerical range greater than the overvoltage threshold, such as greater than 3.6V; the fault data range corresponding to a cell undervoltage fault can be a numerical range less than the undervoltage threshold, such as less than 2.5V; and the fault data range corresponding to a cell overtemperature fault can be a numerical range greater than the overtemperature threshold, such as greater than 60℃.

[0069] Specifically, the fault simulation device 120 can pre-store the fault data type and fault data range corresponding to each type of fault to be tested. The fault simulation device 120 can determine the corresponding fault data type and fault data range according to the type of fault to be tested, and then obtain the data belonging to the fault data type from the battery status data and modify it to the fault data range.

[0070] For example, when the fault type to be tested is a cell overvoltage fault, the fault data type is voltage type, and the fault data range is greater than 3.6V. The fault simulation device 120 determines the voltage data of the target cell from the battery status data to be 3.5V, modifies it to 3.8V, and obtains the fault status data. When the fault type to be tested is a cell undervoltage fault, the fault data range is less than 2.5V, and the fault simulation device 120 can modify the voltage data of the target cell to 2.3V to obtain the fault status data. When the fault type to be tested is a cell overtemperature fault, the fault data type is temperature type, and the fault data range is greater than 60℃, and the fault simulation device 120 can modify the temperature data of the target cell to 65℃ to obtain the fault status data.

[0071] In this way, the fault simulation device 120 generates fault status data by modifying the data belonging to the fault data type in the battery status data to the fault data range, which can realize the rapid simulation of different types of faults and is conducive to improving the efficiency and diversity of testing.

[0072] Therefore, the communication device 110 can receive battery status data from the battery device 210 in the battery system 200 and send it to the fault simulation device 120. The fault simulation device 120 modifies the data of the fault data type corresponding to the fault type under test in the real battery status data of the battery device 210 to be within the fault data range, while leaving the data that does not belong to the fault data type unchanged, thereby obtaining fault status data. This fault status data is then sent to the main battery management unit to test the fault identification capability of the main battery management unit. Since the fault status data, except for the modified data, is all real data collected from the battery device 210, it is closer to the real fault state, which can improve the authenticity and reliability of the test.

[0073] In some examples, communication device 110 receives battery status data from battery device 210 stating that "cell #05 has a cell temperature of 27°C, a voltage of 3.4V, and a current of 30A," and sends it to fault simulation device 120. If the goal is to test the main battery management unit's ability to identify cell over-temperature faults, then the cell over-temperature fault can be considered as the fault type to be tested. Fault simulation device 120 can determine the fault data type corresponding to the cell over-temperature fault as the cell temperature type, and the corresponding fault data range as greater than 60°C, based on pre-stored fault data types and fault data ranges for different fault types to be tested. Then, the cell temperature data in the battery status data can be modified to any temperature greater than 60°C. For example, "cell temperature is 27°C" can be changed to "cell temperature is 65°C", while keeping other data unchanged. This will give the fault status data as "cell #05 has a cell temperature of 65°C, a voltage of 3.4V, and a current of 30A". This fault status data is then sent to the main battery management unit to test whether the main battery management unit can identify the cell over-temperature fault.

[0074] In this way, the fault status data sent to the main battery management unit, apart from the modified "cell temperature is 65℃", the remaining "voltage is 3.4V and current is 30A" are all the real status data of normal cells. Therefore, the data received by the main battery management unit can be closer to the real state, thereby improving the authenticity and reliability of the test.

[0075] Furthermore, the pre-stored fault data types and fault data ranges corresponding to different types of faults to be tested can be set according to the fault identification logic of the main battery management unit. For example, if the fault identification logic of the main battery management unit is: if the cell temperature is greater than 60℃, it is identified as a cell over-temperature fault, then the fault data type corresponding to the cell over-temperature fault is the cell temperature type, and the corresponding fault data range is a cell temperature greater than 60℃; if the fault identification logic of the main battery management unit is: if the cell temperature is greater than 60℃ and the voltage is greater than 3.6V, it is identified as a cell over-temperature fault, then the fault data type corresponding to the cell over-temperature fault is the cell temperature type and the cell voltage type, and the corresponding fault data range is a cell temperature greater than 60℃ and a cell voltage greater than 3.6V.

[0076] In some embodiments, such as Figure 2 As shown, the battery system 200 may include a battery device 210, a main battery management unit 220, and a slave battery management unit 230. The slave battery management unit 230 may be connected to the battery device 210 and may be used to acquire battery status data of the battery device 210.

[0077] The communication device 110 can be used to connect to the main battery management unit 220 and the slave battery management unit 230 in the battery system 200, receive battery status data sent by the slave battery management unit 230, and send fault status data to the main battery management unit 220.

[0078] The communication device 110 can be connected to the main battery management unit 220 and the slave battery management unit 230 via wired or wireless means. The communication device 110 can establish a connection with the main battery management unit 220 and the slave battery management unit 230 when testing is required, and disconnect the connection when testing is not required or after testing is completed.

[0079] The battery system 200 may include a battery management system (BMS), which can be used for intelligent management and maintenance of each battery cell, collect battery information, and monitor battery status to prevent overcharging and over-discharging, thereby extending battery life. The BMS may include a main battery management unit 220 and a slave battery management unit 230.

[0080] The main battery management unit 220 can be the core control unit in the battery system 200 for monitoring the status of the battery device 210, diagnosing faults, providing safety protection, and managing information. The main battery management unit 220 can receive battery status data reported from the battery management unit 230 and perform fault identification and protection control based on the battery status data.

[0081] The slave battery management unit 230 is a unit in the battery system 200 used to collect battery status data from the battery device 210. The slave battery management unit 230 can be connected to the battery device 210 and can be used to obtain the status data of each cell in the battery device 210, that is, the battery status data, and send the collected battery status data to the main battery management unit 220.

[0082] Specifically, the battery status data of the battery device 210 can be obtained from the battery management unit 230 and sent to the communication device 110. The communication device 110 can send the battery status data to the fault simulation device 120. The fault simulation device 120 can modify the battery status data to obtain fault status data and then send the fault status data to the communication device 110. The communication device 110 can send the fault status data to the main battery management unit 220 to test the main battery management unit 220.

[0083] Testing the main battery management unit 220 can refer to testing its fault identification and response capabilities. Specifically, this can be done by sending fault status data to the main battery management unit 220 and verifying whether it can correctly identify and respond to the fault status data, thus obtaining test results. The test results can reflect the main battery management unit 220's ability to identify and respond to specific faults, thereby assessing the reliability of the main battery management unit 220.

[0084] Thus, the test device 100 is connected to both the slave battery management unit 230 and the main battery management unit 220 via the communication device 110. It can receive battery status data obtained by the slave battery management unit 230 from the battery device 210 and send fault status data simulated by the fault simulation device 120 to the main battery management unit 220, thereby integrating into the existing communication link of the battery system 200 and establishing a complete communication link from battery status data acquisition to fault status data injection. In this way, without changing the internal hardware structure and connections of the battery system 200, the fault identification and response capabilities of the main battery management unit 220 can be tested, improving the convenience of the test.

[0085] In some embodiments, such as Figure 2 As shown, the battery management unit 230 can also be connected to the main battery management unit 220; the fault simulation device 120 can be used to send a first control command to the communication device 110 before sending fault status data to the communication device 110. The communication device 110 can be used to send a first control command to the slave battery management unit 230 to control the slave battery management unit 230 to stop sending signals to the main battery management unit 220.

[0086] The first control command may be a command used to control the battery management unit 230 to stop sending signals to the main battery management unit 220.

[0087] During normal operation of the battery system 200, the battery management unit 230 continuously sends battery status data of the battery device 210 to the main battery management unit 220. During testing of the battery system 200, the fault simulation device 120 simulates fault status data based on the battery status data of the battery device 210 and sends this fault status data to the main battery management unit 220 via the communication device 110. Since both the battery management unit 230 and the communication device 110 are connected to the main battery management unit 220, both can send data to the main battery management unit 220. If, while the fault simulation device 120 is sending fault status data to the main battery management unit 220 via the communication device 110, the battery management unit 230 is still sending battery status data to the main battery management unit 220, the two types of data may become confused or conflict at the main battery management unit 220. Therefore, before sending fault status data to communication device 110 and causing communication device 110 to send fault status data to main battery management unit 220, it is necessary to control battery management unit 230 to stop sending signals to main battery management unit 220.

[0088] Specifically, the fault simulation device 120 can first send a first control command to the communication device 110, causing the communication device 110 to send the first control command to the slave battery management unit 230, controlling the slave battery management unit 230 to stop sending signals to the main battery management unit 220, and then send fault status data to the communication device 110, causing the communication device 110 to send the fault status data to the main battery management unit 220. Stopping the sending of signals to the main battery management unit 220 may include stopping the sending of battery status data to the main battery management unit 220.

[0089] For example, a scenario where the battery management unit 230 stops sending signals to the main battery management unit 220 can be as follows: Figure 3 As shown.

[0090] Furthermore, after the test is completed, the fault simulation device 120 can send a third control command to the communication device 110. The communication device 110 can then send this third control command to the slave battery management unit 230 to control the slave battery management unit 230 to continue sending signals to the main battery management unit 220. The third control command can be an instruction used to control the slave battery management unit 230 to continue sending signals to the main battery management unit 220. In this way, the battery system 200 can automatically resume normal operation after the test is completed.

[0091] Thus, by first controlling the battery management unit 230 to stop sending signals to the main battery management unit 220, and then sending fault status data to the main battery management unit 220, the main battery management unit 220 can successfully receive accurate fault status data, reducing the possibility of interference from battery status data sent from the battery management unit 230, thereby improving the stability and reliability of the test.

[0092] In some embodiments, the battery management unit 230 can be disconnected from the main battery management unit 220 to stop sending signals to the main battery management unit 220. Specifically, disconnection can include unplugging the connection cable or setting a switch between the battery management unit 230 and the main battery management unit 220 and disconnecting the switch.

[0093] For example, a controllable switch can be provided between the slave battery management unit 230 and the main battery management unit 220, and the communication device 110 is connected to the control terminal of the controllable switch. Before sending fault status data to the communication device 110, the fault simulation device 120 first sends a disconnect switch control command to the communication device 110. The communication device 110 can send the disconnect switch control command to the control terminal of the controllable switch to control the controllable switch to disconnect, thereby preventing the slave battery management unit 230 from sending signals to the main battery management unit 220. Alternatively, the controllable switch can also be manually disconnected.

[0094] In some embodiments, after the test is completed, the battery management unit 230 can continue to send signals to the main battery management unit 220 by restoring the connection between the battery management unit 230 and the main battery management unit 220. Specifically, restoring the connection may include inserting a connection cable, or it may include setting a switch between the battery management unit 230 and the main battery management unit 220 and restoring the connection by closing the switch.

[0095] For example, a controllable switch can be provided between the slave battery management unit 230 and the main battery management unit 220, and the communication device 110 is connected to the control terminal of the controllable switch. After the fault simulation device 120 completes the test, it sends a closing switch control command to the communication device 110. The communication device 110 can then send the closing switch control command to the control terminal of the controllable switch to control the switch to close, thereby allowing the slave battery management unit 230 to continue sending signals to the main battery management unit 220. Alternatively, the closing of the controllable switch can also be manually controlled.

[0096] In some embodiments, the communication device 110 can be used to receive target response information of the main battery management unit 220 to fault status data and send the target response information to the fault simulation device 120. The fault simulation device 120 can be used to determine the test results of the main battery management unit 220 based on the preset response information corresponding to the target response information and the fault state data.

[0097] like Figure 4 As shown, the communication device can be connected not only to the input terminal of the main battery management unit 220, but also to the output terminal of the main battery management unit 220 to receive the target response information output by the main battery management unit 220.

[0098] The target response information can be response information generated by the main battery management unit 220 based on the fault status data after receiving it. The target response information can characterize the main battery management unit 220's identification and response results to the fault status data. For example, the target response information may include at least one of the following: fault type, fault parameter value, fault code, and fault cell number identified by the main battery management unit 220.

[0099] The preset response information can be the expected response information corresponding to the fault state data. The preset response information can characterize the expected result that the main battery management unit 220 should identify and respond to after receiving the fault state data, assuming the main battery management unit 220 is operating normally. The preset response information can be pre-stored in the fault simulation device 120, or it can be obtained by the fault simulation device 120 from identifying the fault state data. For example, the preset response information can include at least one of the following: a preset fault type, a preset fault parameter value, a preset fault code, and a preset fault cell number.

[0100] The test result can be information indicating whether the main battery management unit 220 correctly identifies and responds to fault state data. The test result can include whether the test passed or failed. For example, if the target response information matches the preset response information, the test result can be determined as passed, indicating that the main battery management unit 220 correctly identifies and responds to fault state data; if the target response information does not match the preset response information, the test result can be determined as failed, indicating that the main battery management unit 220 incorrectly identifies and responds to fault state data. Through the test results, the main battery management unit 220's ability to identify and respond to specific faults can be determined, thereby evaluating the reliability of the main battery management unit 220's fault protection function.

[0101] For example, when simulating fault state data, the fault simulation device 120 can record preset response information corresponding to the fault state data, such as a preset fault code of 0x01. After the communication device 110 receives the target response information of the main battery management unit 220 for the fault state data, the fault simulation device 120 can compare the target response information with the preset response information. If the target response information is consistent with the preset response information, for example, if the target fault code in the target response information and the preset fault code in the preset response information are both 0x01, then it can be determined that the test result of the main battery management unit 220 for the fault state data is passed; if the target response information is inconsistent with the preset response information, then it can be determined that the test result of the main battery management unit 220 for the fault state data is failed.

[0102] In this way, by comparing the target response information of the actual response of the main battery management unit 220 with the preset response information, the fault simulation device 120 can automatically determine whether the identification and response of the main battery management unit 220 to a specific fault is correct, thereby automatically obtaining the test results, which is conducive to improving the automation and efficiency of the test.

[0103] In some embodiments, the fault simulation device 120 can be used to determine that the test result is correct for the main battery management unit 220 to respond to the fault state data based on the consistency between the target response information and the preset response information; and to determine that the test result is abnormal for the main battery management unit 220 to respond to the fault state data based on the inconsistency between the target response information and the preset response information.

[0104] The target response information may include at least one of the following: target fault type, target fault code, target fault parameter value, and target fault cell number determined by the main battery management unit 220 based on the fault status data. The preset response information may include at least one of the following: the type of fault to be tested, the fault code to be tested, the fault parameter value to be tested, and the fault cell number to be tested, corresponding to the fault status data. By comparing one or more of the above information, the accuracy of the main battery management unit 220's identification of the fault status data can be more comprehensively verified.

[0105] The target fault type can be the fault type determined by the main battery management unit 220 after receiving fault status data and identifying the fault status data. For example, the target fault type can include, but is not limited to, at least one of cell overvoltage fault, cell undervoltage fault, cell overtemperature fault, and cell overcurrent fault.

[0106] The type of fault to be tested can be the type of fault that needs to be simulated in this test, that is, the type of fault that the battery system is expected to identify in the preset response information. For example, the type of fault to be tested can include, but is not limited to, at least one of the following: cell overvoltage fault, cell undervoltage fault, cell overtemperature fault, and cell overcurrent fault.

[0107] Specifically, when simulating fault state data, the fault simulation device 120 can generate corresponding fault state data based on the selected fault type to be tested in this test, and record the fault type to be tested as preset response information. After receiving the fault state data, the main battery management unit 220 can identify the fault state data and generate target response information including the target fault type. After receiving the target response information, the communication device 110 sends it to the fault simulation device 120. The fault simulation device 120 can compare the target fault type with the fault type to be tested. If the target fault type is consistent with the fault type to be tested, it can be determined that the test result is that the main battery management unit 220 responds correctly to the fault state data, and the test passes; if the target fault type is inconsistent with the fault type to be tested, it can be determined that the main battery management unit 220 responds abnormally to the fault state data, and the test fails.

[0108] For example, when testing the main battery management unit 220's ability to identify and respond to cell overvoltage faults, since the fault data type for cell overvoltage faults is voltage-type and the fault data range is greater than 3.6V, the fault simulation device 120 modifies the voltage value of the target cell with cell number 05 in the battery status data from the normal voltage value to 3.8V, obtains fault status data, and sends the fault status data to the main battery management unit 220. After receiving the fault status data, the main battery management unit 220 compares the voltage value of 3.8V with the preset overvoltage fault threshold of 3.6V, determines that a cell overvoltage fault has occurred, and generates target response information including the target fault type "cell overvoltage fault" and the target fault code "03". After receiving the target response information, the fault simulation device 120 compares the target fault type "cell overvoltage fault" with the test fault type "cell overvoltage fault" and compares the target fault code "03" with the test fault code "03". If both comparisons are consistent, it can be determined that the main battery management unit 220 responds correctly to the fault status data; if either comparison is inconsistent, it can be determined that the main battery management unit 220 responds abnormally to the fault status data.

[0109] In another example, when testing the main battery management unit 220's ability to identify and respond to cell over-temperature faults, since the fault state data type for cell over-temperature faults is temperature-related and the fault data range is greater than 60°C, the fault simulation device 120 modifies the temperature value of the target cell with cell number 05 in the battery status data from the normal temperature value to 65°C, obtains the fault state data, and sends the fault state data to the main battery management unit 220. After receiving the fault state data, the main battery management unit 220 compares the temperature value of 65°C with the preset over-temperature fault threshold of 60°C, determines that a cell over-temperature fault has occurred, and generates target response information including the target fault type "cell over-temperature fault" and the target fault code. After receiving the target response information, the fault simulation device 120 compares the target fault type "cell over-temperature fault" with the preset fault type "cell over-temperature fault" and compares the target fault code with the preset fault code. If both comparisons are consistent, it can be determined that the main battery management unit 220 responds correctly to the fault status data; if either comparison is inconsistent, it can be determined that the main battery management unit 220 responds abnormally to the fault status data.

[0110] Thus, the fault simulation device 120 determines that the main battery management unit 220 responds correctly to the fault status data when the target response information and the preset response information are consistent. It can automatically determine whether the main battery management unit 220 correctly identifies and responds to a specific fault, which helps to improve the automation and efficiency of the test.

[0111] In some embodiments, the communication device 110 may support multiple communication protocols and may be used to select a communication protocol that matches the communication protocol of the battery system 200 from among the multiple communication protocols for communication.

[0112] The communication protocol can be the protocol followed by which the communication device 110 and the battery system 200 exchange data. For example, the communication protocol may include the CAN protocol, Modbus protocol, RS-485 protocol, etc.

[0113] The battery system 200 can support one or more of the aforementioned communication protocols, and different battery systems 200 can support different communication protocols. Since the communication device 110 can support multiple communication protocols, the testing device 100 can be applied to different battery systems 200 that support different communication protocols, which is beneficial to improving the versatility and compatibility of the testing device 100.

[0114] Specifically, after the testing device 100 is connected to the battery system 200, the communication device 110 can identify the communication protocols supported by the battery system 200, and select the communication protocol that matches the communication protocol of the battery system 200 from among the various communication protocols it supports, so as to realize data interaction with the battery system 200. For example, the communication device 110 can identify the communication protocols supported by the battery system 200 by performing a handshake interaction with the battery system 200.

[0115] In this way, by supporting multiple communication protocols and selecting the matching communication protocol according to the communication protocol of the battery system 200, the communication device 110 can adapt the test device 100 to battery systems 200 with different communication protocols, which is beneficial to improving the versatility and compatibility of the test device 100.

[0116] In some embodiments, such as Figure 1 and Figure 2 As shown, the communication device 110 can be connected to the battery system 200 through the communication interface 240 of the battery system.

[0117] The communication interface 240 may be an interface inherent to the battery system 200 for data interaction with external devices. The communication interface 240 may be located on the outer surface of the battery system 200 or near its edge to facilitate connection and disconnection with external devices.

[0118] The communication device 110 can be connected to the communication bus of the battery system 200 via the communication interface 240. The communication device 110 and the communication interface 240 can be connected by a cable.

[0119] For example, the communication interface 240 can be an on-board diagnostic (OBD) system interface, the communication bus of the battery system 200 can be a CAN bus, and the communication device 110 can be a CAN communication device.

[0120] In this way, the communication device 110 connects to the battery system 200 through the communication interface 240 of the battery system 200, and data interaction between the test device 100 and the battery system 200 can be realized without changing the internal structure or wiring of the battery system 200, which is beneficial to improving the convenience and safety of the test.

[0121] In some examples, it can be like Figure 5 As shown, the fault simulation device 120 may include: a data acquisition module 510, a database module 520, a data simulation module 530, and a data detection module 540.

[0122] The data acquisition module 510 can be used to receive battery status data sent by the communication device 110, and to perform real-time analysis and preprocessing of the battery status data. Preprocessing may include at least one of filtering, calibration, and format conversion.

[0123] The database module 520 can be used to classify and structure the battery status data parsed by the data acquisition module 510 using the cell identifier as an index. It can also be used to store historical fault records, thereby centrally managing the historical parameters and real-time status of the cells.

[0124] The data simulation module 530 can be used to obtain battery status data from the database module 520, modify the battery status data, and obtain fault status data. Specifically, the data simulation module 530 can perform high-precision, programmable, real-time adjustments to parameters such as voltage and temperature of a target battery cell selected by the user, to simulate different fault status data. The simulated fault status data can be used to trigger different types of faults in the battery system 200, such as overvoltage faults, undervoltage faults, and overtemperature faults, to simulate the state of a single specified battery cell in the battery system 200 when a corresponding fault occurs.

[0125] The data detection module 540 can be used to receive target response information from the battery system 200 to fault state data, compare the target response information with preset response information, and determine the test results of the battery system 200. The data detection module 540 can also be used to display the fault simulation process and the response status of the battery system 200 to the user in real time.

[0126] The fault simulation device 120, through the coordinated operation of the data acquisition module 510, database module 520, data simulation module 530 and data detection module 540, achieves accurate analysis, classification and storage and directional parameter adjustment of BMS data, and realizes precise control and display of fault simulation.

[0127] The main flow of the test device 100 provided in this application embodiment follows a closed-loop control logic of data acquisition, analog signal generation, threshold comparison, fault judgment and response. Through a layered and decoupled system design, mutual interference between different parameters can be effectively isolated, which helps reduce the false alarm rate and improve detection robustness. To improve the effectiveness, safety, and universality of the test, this application embodiment follows the following constraints and mechanisms: protocol compatibility constraints: the communication protocol used by the test device 100 is compatible with the protocol of the battery system 200; the interface design follows standardization principles; for example, the communication protocol can be the Controller Area Network (CAN) protocol; data verification: Cyclic Redundancy Check (CRC) and other verification mechanisms are added to the data receiving and sending stages to verify the integrity of data transmission; during actual testing, before sending fault status data, the fault simulation device 120 disconnects the communication connection between the battery management unit 230 and the main battery management unit 220 to prevent the fault status data sent by the fault simulation device 120 from conflicting with the normal battery status data sent by the battery management unit 230 at the main battery management unit 220.

[0128] CRC (Corrective Chronology) is a hash function that generates a short, fixed-length checksum based on data such as network packets or computer files. It can be used to detect or verify errors that may occur during data transmission or storage. The generated number is calculated before transmission or storage and appended to the data, which the receiver then checks to determine if the data has been altered.

[0129] Based on the same inventive concept, embodiments of this application also provide a testing system. The following, in conjunction with… Figure 6 The testing system provided in the embodiments of this application will be described in detail.

[0130] Figure 6 This illustration shows one of the structural schematic diagrams of a testing system provided in one embodiment of this application. For example... Figure 6 As shown, the test system 1000 may include a test device 100 and a battery system 200 as shown in any of the above embodiments.

[0131] For details, please refer to the above embodiments, which will not be repeated here.

[0132] Therefore, the testing device 100 can receive battery state data from the battery device in the battery system 200, modify the battery state data to obtain fault state data, and then send the fault state data to the battery system 200 for testing. Since the fault state data sent to the battery system 200 is obtained by modifying the actual battery state data of the battery device, this fault state data is based on real data and is closer to real fault scenarios. Therefore, the fault identification capability of the battery system 200 can be tested under real operating conditions, improving the authenticity and reliability of the test.

[0133] In some embodiments, such as Figure 7 As shown, the battery system 200 may include a controller 250.

[0134] The controller 250 can be connected to the main battery management unit 220 and the safety protection device 260. It can be used to receive the target response information of the main battery management unit 220 to the fault state data, generate a second control command based on the target response information, and send the second control command to the safety protection device 260 to determine the test result of the battery system 200 based on the execution result of the safety protection device 260.

[0135] The controller 250 may be a device with data processing and control functions. For example, the controller 250 may be a programmable logic controller (PLC).

[0136] Safety protection device 260 can be a device used to perform safety protection actions when the battery system 200 fails. For example, safety protection device 260 may include at least one of thermal management equipment, fire-fighting equipment, and high-voltage circuit control equipment. Thermal management equipment can be used to regulate the temperature of the battery system 200, and can cool the battery system 200 when the cell temperature is too high; fire-fighting equipment can be used to perform fire extinguishing actions when a fire occurs in the battery system 200; high-voltage circuit control equipment can be used to control the connection or disconnection of the high-voltage circuit of the battery system 200, and can disconnect the high-voltage circuit when the cell experiences overvoltage, undervoltage, or overtemperature faults.

[0137] The controller 250 can receive target response information from the main battery management unit 220 regarding fault status data, generate a second control command based on the target response information, and then send the second control command to the safety protection device 260. The second control command can be used to control the safety protection device 260 to perform safety protection actions.

[0138] Specifically, the controller 250 can generate a second control command corresponding to the fault type or fault code indicated by the target response information. Different fault types or fault codes can correspond to different safety protection actions. Therefore, the controller 250 can determine the control command matching the fault type or fault code from a variety of preset control commands as the second control command. For example, if the fault type indicated by the target response information is an over-temperature fault, the controller 250 can generate a second control command to start the thermal management equipment for cooling; if the fault type indicated by the target response information is a fire fault, the controller 250 can generate a second control command to start the fire-fighting equipment to perform fire extinguishing actions; if the fault type indicated by the target response information is an over-voltage fault or an under-voltage fault, the controller 250 can generate a second control command to control the high-voltage circuit control equipment to disconnect the high-voltage circuit.

[0139] After receiving the second control command, the safety protection device 260 can execute safety protection actions according to the second control command and generate execution results. The execution results can indicate the execution status of the safety protection actions, such as whether they were executed or not. The test results of the battery system 200 can be determined based on the execution results. Specifically, if the execution result is successful, it can be determined that the main battery management unit 220 successfully identified the fault state data and correctly generated the target response information, and the controller 250 correctly received the target response information and generated the correct second control command. Therefore, the test result of the battery system 200 is passed. If the execution result is unsuccessful, it can be determined that the main battery management unit 220 failed to correctly identify the fault state data or failed to correctly generate the target response information, or the controller 250 failed to correctly receive the target response information or failed to correctly generate the second control command. Therefore, the test result of the battery system 200 is unsuccessful.

[0140] In this way, the controller 250 controls the safety protection device 260 to perform safety protection actions based on the target response information of the main battery management unit 220, and determines the test results based on the execution results of the safety protection device 260. This can verify whether the main battery management unit 220 correctly identifies and responds to the fault status data from the execution level of the safety protection device 260, and can also test whether the response of the controller 250 is correct, as well as test whether the communication between the main battery management unit 220 and the controller 250 is normal, which helps to improve the comprehensiveness and reliability of the test.

[0141] In some embodiments, such as Figure 8 As shown, the battery system 200 may include a display 270.

[0142] The display 270 can be connected to the main battery management unit 220 and can be used to receive target response information of the main battery management unit 220 to fault status data and display the target response information to determine the test results of the battery system 200 based on the target response information.

[0143] Display 270 can be a device with information display function. Display 270 can be a human-machine interface (HMI). For example, display 270 can be a liquid crystal display, a touch display, etc.

[0144] After receiving fault status data, the main battery management unit 220 can identify the fault status data and generate target response information. Specifically, after receiving the fault status data, the main battery management unit 220 can compare the parameter values ​​in the fault status data with preset fault thresholds. If the parameter values ​​in the fault status data exceed the preset fault thresholds, a fault can be identified, the fault type can be determined, and target response information can be generated based on the fault type. For example, if the voltage value of the target cell in the fault status data received by the main battery management unit 220 is 3.8V, and the preset overvoltage fault threshold is 3.6V, then the main battery management unit 220 can determine that an overvoltage fault has occurred and generate target response information including the overvoltage fault type. The main battery management unit 220 can send the target response information to the display 270, and the display 270 can receive and display the target response information.

[0145] During the test, the tester can observe the target response information displayed on the display 270, such as whether the correct fault code is displayed on the display 270, to determine whether the battery system 200 correctly identifies and responds to the fault status data, thereby determining the test result of the battery system 200.

[0146] Specifically, the display 270 can display at least one of the following: fault type, fault parameter value, fault code, and fault cell number identified by the main battery management unit 220. Testers can determine the test result by comparing the target response information displayed on the display 270 with the preset response information. If the target response information displayed on the display 270 matches the preset response information, the test result for the battery system 200 is that the battery system 200 responds correctly to the fault state data, and the test passes. If the target response information displayed on the display 270 does not match the preset response information, the test result for the battery system 200 is that the battery system 200 responds abnormally to the fault state data, and the test fails. In this way, testers can intuitively obtain the test results of the battery system 200 by observing the display content on the display 270, which improves the convenience of testing.

[0147] For example, such as Figure 9 As shown, the battery system 200 may include a controller 250 and a display 270. The main battery management unit 220 can be connected to the controller 250, and the controller 250 can be connected to the display 270. Specifically, the connection between the controller 250 and the display 270 can be via Ethernet for Control Automation Technology (EtherCAT), and the controller 250 can drive the display 270 to display information. The main battery management unit 220 sends target response information to the controller 250, and the controller 250 then sends the target response information to the display 270 for display. Thus, by determining whether the target response information displayed on the display 270 is consistent with the preset response information, it is possible not only to test whether the main battery management unit 220, the controller 250, and the display 270 respond correctly to faults, but also to test whether the communication link between the main battery management unit 220, the controller 250, and the display 270 is normal.

[0148] Thus, by displaying the target response information of the main battery management unit 220 on the display 270, the tester can intuitively obtain the test results of the battery system 200, which helps to improve the convenience of testing.

[0149] Since the protection functions of the Battery Management System (BMS) for critical parameters such as cell voltage, current, and temperature are the core content of testing, and it is also crucial to intuitively and reliably verify the effectiveness of these protection mechanisms in user-facing system function demonstrations, the current industry standard for testing BMS protection functions is to trigger preset fault codes via software commands. However, this method can only verify whether the BMS software logic can recognize an existing fault state; it cannot perform continuous, high-precision real-time adjustments to battery status data such as voltage or temperature of a single specified cell. This limitation directly leads to poor testing flexibility and inconvenience, making the test results insufficient to fully demonstrate the reliable protection capabilities of the battery system when facing real-world faults during actual operation. Therefore, in this embodiment of the application, the fault state data obtained by modifying the real battery state data can reflect the real parameters of a specific cell in the battery device. Thus, it is possible to achieve high-precision real-time adjustment of battery state data such as voltage or temperature of a single specified cell, and can simulate fault state data that is closer to the real fault scenario. This allows for testing of the fault identification capability of the main battery management unit under real working conditions, improving the authenticity and reliability of the test, and meeting the high-standard certification requirements of the industry and the high-quality demonstration needs of users.

[0150] This application proposes a hardware implementation architecture for a testing system. This architecture is based on a box-type power supply system containing inherent components such as a battery pack, high-voltage box, MBMU, and display screen, and is constructed by adding an externally designed testing device. Its core lies in reusing the original hardware resources of the box-type power supply system and connecting the testing device via a CAN network, thereby achieving high-precision simulation of cell parameters and fault injection without altering the main structure of the battery pack.

[0151] The testing system proposed in this application, through deep collaboration among its modules, achieves a fully controllable testing chain, from precise BMS data analysis to programmable cell parameter simulation and dynamic fault triggering, significantly improving the accuracy, flexibility, and visualization of fault simulation. Specifically, by reading real battery state data from the battery device, the system enhances the relevance and realism of fault simulation, reflecting the actual location and data of a specific cell within the system, thus resolving the disconnect between general test signals and actual conditions. Simultaneously, it addresses the issues of directly enabling corresponding fault codes in the fault code table, lacking dynamic cell voltage adjustment capabilities, or using complex hardware and software systems unsuitable for field applications, introducing convenient, dynamic, and real-time fault simulation.

[0152] In some examples, the battery system 200 may include a data acquisition layer, a data aggregation layer, and a data monitoring layer. The data acquisition layer is used to collect key parameters such as voltage, temperature, and current of the cells in each battery pack in real time. The data aggregation layer is used to send the raw data collected by the data acquisition layer to the system monitoring layer via an internal CAN bus for preliminary integration and processing. The system monitoring layer is used to communicate with a PLC via the CAN bus. The PLC, acting as a host computer, can continuously monitor the status of the entire battery system. Simultaneously, the PLC can drive a display screen to show the system status, operating data, and historical fault records in real time, providing a human-machine interface.

[0153] In addition, the battery system 200 may also include a built-in OBD diagnostic port. To enable fault simulation, a test device can be connected in parallel to the CAN network of the battery management unit through this OBD diagnostic port. This allows for lossless monitoring and acquisition of real-time data from all battery cells, providing a data foundation for subsequent accurate fault injection.

[0154] The test system 1000 provided in this application embodiment and the test device 100 provided in this application embodiment are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0155] Based on the same inventive concept, this application also provides a testing method. It should be noted that this testing method can be applied to the testing apparatus or fault simulation device shown in any of the above embodiments. The following describes... Figure 10 The test methods provided in the embodiments of this application will be described in detail.

[0156] Figure 10 One of the flowcharts of a testing method provided in one embodiment of this application is shown. Figure 10 As shown, the testing method may include the following steps: S1010, receives battery status data from the battery device in the battery system; S1020, Modify the battery status data to obtain fault status data; S1030 sends fault status data to the main battery management unit in the battery system to test the main battery management unit.

[0157] For details, please refer to the above embodiments, which will not be repeated here.

[0158] Therefore, fault status data can be obtained by receiving and modifying the battery status data from the battery device in the battery system. This fault status data is then sent to the main battery management unit (BMU) for testing. Since the fault status data sent to the BMU is obtained by modifying the actual battery status data of the battery device, it is based on real data and more closely resembles real fault scenarios. Therefore, the fault identification capability of the BMU can be tested under real operating conditions, improving the realism and reliability of the test.

[0159] In some embodiments, S1020 may include: Obtain the fault data type and fault data range corresponding to the fault type to be tested; Modify the data in the battery status data that belongs to the fault data type to be within the fault data range to obtain the fault status data.

[0160] For a detailed description, please refer to the above embodiments, which will not be repeated here.

[0161] In this way, the fault simulation device generates fault state data by modifying the data belonging to the fault data type in the battery state data to the fault data range, which can realize the rapid simulation of different types of faults and help improve the efficiency and diversity of testing.

[0162] Therefore, the communication device can receive battery status data from the battery unit in the battery system and send it to the fault simulation device. The fault simulation device modifies the data of the fault type corresponding to the fault to be tested in the actual battery status data of the battery unit to bring it within the fault data range, while leaving the data of the non-fault type unchanged, thus obtaining fault status data. This fault status data is then sent to the main battery management unit to test the fault identification capability of the main battery management unit. Since the fault status data, except for the modified data, is all real data collected from the battery unit, it is closer to the actual fault state, which can improve the authenticity and reliability of the test.

[0163] In some embodiments, the testing method may further include: Receive target response information from the main battery management unit in response to fault status data; Based on the preset response information corresponding to the target response information and fault status data, the test results of the main battery management unit are determined.

[0164] For details, please refer to the above embodiments, which will not be repeated here.

[0165] In this way, by comparing the target response information of the main battery management unit with the preset response information, it is possible to automatically determine whether the main battery management unit correctly identifies and responds to a specific fault, thereby automatically obtaining the test results, which helps to improve the automation and efficiency of the test.

[0166] In some embodiments, determining the test result of the main battery management unit based on preset response information corresponding to the target response information and fault state data may include: Based on the consistency between the target response information and the preset response information, it is determined that the test result indicates that the main battery management unit responded correctly to the fault status data.

[0167] For details, please refer to the above embodiments, which will not be repeated here.

[0168] Thus, by determining that the main battery management unit responds correctly to the fault status data when the target response information and the preset response information are consistent, it is possible to automatically determine whether the main battery management unit correctly identifies and responds to a specific fault, which is beneficial to improving the automation and efficiency of testing.

[0169] In some embodiments, battery state data may include data on the battery device in a high voltage state.

[0170] A high-voltage state can refer to a state where the battery system is in a high-voltage circuit conduction state. In a high-voltage state, the battery device can output high-voltage electricity to the outside or receive high-voltage electricity from the outside for charging. Data of the battery device in a high-voltage state may include, but is not limited to, at least one of the following: data from the battery device's resting process, charging process, and discharging process. For example, data of the battery device in a high-voltage state may include, but is not limited to, at least one of the following: voltage data, current data, and temperature data of the battery device in a high-voltage circuit conduction state.

[0171] If a battery system operates at high voltage and a cell experiences overvoltage, undervoltage, or overtemperature faults that are not promptly identified and protected against, irreversible damage to the battery device may occur. This could even lead to serious safety accidents such as thermal runaway, fire, or explosion, endangering personal and equipment safety. Therefore, testing and verifying the fault identification capability of the main battery management unit under high voltage conditions is a crucial step in improving the operational safety of the battery system.

[0172] However, directly simulating faults through physical means under high voltage conditions, such as overcharging, heating, or short-circuiting the battery device, poses a high safety risk and may damage the battery device or cause a safety accident.

[0173] Therefore, in this embodiment, when the battery device is in a high-voltage state, data from the battery device in the battery system under this high-voltage state is received via a communication device. A fault simulation device then simulates fault state data based on this high-voltage data and transmits the fault state data to the main battery management unit via the communication device. The entire fault simulation process only requires the battery device to be in a high-voltage state, without actually causing a fault in the battery device under this state. This not only enables fault simulation testing under high-voltage conditions but also reduces safety risks and improves the safety and feasibility of the test.

[0174] In this way, fault state data can be simulated using real high-voltage battery state data when the battery system is under high voltage conditions. This allows for testing the battery system's fault identification capability under realistic high-voltage operating conditions, improving the realism and reliability of the test. Simultaneously, since it is not necessary for the battery device to actually malfunction under high voltage conditions, the risk of battery device damage and safety arising from physical fault simulation is reduced, thus enhancing the safety and feasibility of the test.

[0175] To better describe the overall solution, based on the above embodiments, an example is given, such as... Figure 11 As shown, the test method may include S1101-S1105. Wherein: S1101, Receives battery status data of the battery device in the battery system; S1102, Obtain the fault data type and fault data range corresponding to the fault type to be tested; S1103, Modify the data in the battery status data that belongs to the fault data type to be within the fault data range to obtain fault status data; S1104, Receive target response information from the main battery management unit for fault status data; S1105, based on the preset response information corresponding to the target response information and fault status data, determine the test result of the main battery management unit.

[0176] The specific processes of S1101-S1105 can be found in the above embodiments, and will not be repeated here. In addition, this application does not limit the order of S1101 and S1102.

[0177] To better describe the entire solution, based on the above embodiments, let's take another specific example: the testing method may include: S1. Establish the physical connection between the test device and the battery system. Connect the fault simulation device to the CAN communication port of the battery management unit in parallel through the OBD diagnostic port, configure the CAN communication parameters (such as baud rate), enable the CAN function, and enable the host computer software of the fault simulation device to establish a stable data link layer communication with the battery management unit through the CAN communication device.

[0178] S2 continuously collects battery status data from the battery management unit, including cell number, voltage, temperature, branch current, and state of charge (SOC). This data is encapsulated into CAN frames conforming to a predetermined protocol and simultaneously transmitted via the CAN bus to the main battery management unit and a network-connected fault simulation device. Upon receiving the raw CAN data, the fault simulation device verifies, decodes, and parses the data packets according to the preset CAN communication protocol and CRC check algorithm, accurately reconstructing the various parameters of the battery system and obtaining the battery status data. For example, it can read cell voltage number 05 in battery cluster 1 from communication frame 0x156DEFF1; cell voltage 05 in battery cluster 1 with voltage number 3.5V from frame 0x156DEFF2; and cell temperature 27℃ from battery cluster 1 with voltage number 05 from frame 0x189BEFF3. SOC refers to the percentage of usable battery capacity relative to the nominal capacity, a crucial monitoring data point for the BMS, which can control the battery's operating state based on the SOC value.

[0179] S3 performs structured processing on the parsed battery status data, establishing a data foundation for accurate fault simulation. The fault simulation device intelligently categorizes the data stream from the battery management unit according to the defined communication protocol. Using the cell number as a key index, it automatically groups the voltage, temperature, and other parameters corresponding to each cell and stores them in a structured internal database. This database provides a quick access interface for subsequent cell-based location and modification of specific parameters. For example, battery status data can be arranged by cell number and displayed on the fault simulation device's interface: Cell number: 05, Cell voltage 3.5V, Cell temperature 27℃; other cell data are displayed synchronously.

[0180] S4 enables precise modification of specific battery status data to simulate a fault. The fault simulation device simulates sending cell data from the slave battery management unit (BMU) to the master BMU. Disconnecting the physical connection between the slave and master BMU beforehand helps reduce conflicts between the CAN communication data sent by the fault simulation device and the slave BMU. Then, the fault simulation device simulates the function of the slave BMU, sending fault status data to the master BMU. The operator selects the target cell number (cell #05) and modifies a parameter value of that cell in the host computer interface of the fault simulation device. For example, manually changing the currently read voltage value from the normal 3.5V to 3.8V. The fault simulation device then sends a CAN frame (0x156DEFF2) containing this modified data to the master BMU, following the prescribed message format, period, and CRC encryption.

[0181] S5 verifies the correct diagnosis and handling process of the main battery management unit (BMU) for injected faults. Upon receiving CAN communication frame 0x156DEFF2 and parsing the voltage value of cell #05 as 3.8V, the BMU immediately compares it with the internally preset cell overvoltage protection threshold (e.g., 3.6V). Since 3.8V > 3.6V, the BMU determines that cell #05 has experienced an "overvoltage fault" and generates target response information containing a fault code, the highest fault voltage value, and the corresponding cell number. The BMU sends this target response information to the PLC via the CAN bus. The PLC forwards the target response information to the display screen for real-time alarm and recording. Operators can verify the normality and accuracy of the entire BMU's fault detection, reporting, and display link by observing whether the display screen accurately displays "Cell #05 voltage 3.8V" and "Cell overvoltage fault."

[0182] The testing methods and testing devices and systems provided in this application are based on the same inventive concept and have the same beneficial effects as the methods they employ, operate, or implement.

[0183] One or more of the components, steps, features, and / or functions disclosed in this application may be rearranged and / or combined into a single component, step, feature, or function, or distributed among several components, steps, or functions. Those skilled in the art may also add additional elements, components, steps, and / or functions without departing from the scope disclosed herein.

[0184] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0185] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0186] 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 testing device, characterized in that, include: Interconnected communication equipment and fault simulation equipment; The communication device is used to connect to the battery system, receive battery status data of the battery devices in the battery system, and send the battery status data to the fault simulation device. The fault simulation device is used to modify the battery status data to obtain fault status data and send the fault status data to the communication device. The communication device is also used to send the fault status data to the main battery management unit in the battery system to test the main battery management unit; Specifically, the fault simulation device is used to obtain the fault data type and fault data range corresponding to the fault type to be tested; modify the data in the battery status data that belongs to the fault data type to be within the fault data range, and leave the data that does not belong to the fault data type unchanged, thereby obtaining the fault status data.

2. The testing apparatus according to claim 1, characterized in that, The communication device is used to connect to the main battery management unit and the slave battery management unit in the battery system, receive the battery status data sent by the slave battery management unit, and send the fault status data to the main battery management unit; The battery management unit is connected to the battery device and is used to obtain the battery status data of the battery device.

3. The testing apparatus according to claim 2, characterized in that, The slave battery management unit is also connected to the main battery management unit; the fault simulation device is used to send a first control command to the communication device before sending the fault status data to the communication device; The communication device is configured to send the first control command to the slave battery management unit to control the slave battery management unit to stop sending signals to the master battery management unit.

4. The testing apparatus according to any one of claims 1-3, characterized in that, The communication device is used to receive the target response information of the main battery management unit to the fault status data, and send the target response information to the fault simulation device; The fault simulation device is used to determine the test results of the main battery management unit based on the target response information and the preset response information corresponding to the fault state data.

5. The testing apparatus according to claim 4, characterized in that, The fault simulation device is used to determine, based on the consistency between the target response information and the preset response information, that the test result indicates that the main battery management unit responded correctly to the fault state data.

6. The testing apparatus according to any one of claims 1-3, characterized in that, The communication device supports multiple communication protocols and is used to select a communication protocol that matches the communication protocol of the battery system from among the multiple communication protocols for communication.

7. The testing apparatus according to any one of claims 1-3, characterized in that, The communication device is connected to the battery system through the communication interface of the battery system.

8. A testing system, characterized in that, include: The test apparatus and battery system as described in any one of claims 1-7.

9. The testing system according to claim 8, characterized in that, The battery system includes: a controller; The controller is connected to the main battery management unit and the safety protection device. It is used to receive the target response information of the main battery management unit to the fault status data, generate a second control command based on the target response information, and send the second control command to the safety protection device to determine the test result of the battery system based on the execution result of the safety protection device. The second control command is used to control the safety protection device to perform safety protection actions.

10. The testing system according to claim 8 or 9, characterized in that, The battery system includes: a display; The display is connected to the main battery management unit and is used to receive target response information from the main battery management unit in response to the fault status data, and to display the target response information in order to determine the test results of the battery system based on the target response information.

11. A testing method, characterized in that, include: Receive battery status data from battery devices in the battery system; The battery status data is modified to obtain fault status data; The fault status data is sent to the main battery management unit in the battery system to test the main battery management unit; The modification of the battery status data to obtain fault status data includes: Obtain the fault data type and fault data range corresponding to the fault type to be tested; The data in the battery status data that belongs to the fault data type is modified to fall within the fault data range, while the data that does not belong to the fault data type remains unchanged, thus obtaining the fault status data.

12. The test method according to claim 11, characterized in that, The method further includes: Receive the target response information from the main battery management unit in response to the fault status data; Based on the target response information and the preset response information corresponding to the fault status data, the test result of the main battery management unit is determined.

13. The test method according to claim 12, characterized in that, The step of determining the test result of the main battery management unit based on the preset response information corresponding to the target response information and the fault state data includes: Based on the consistency between the target response information and the preset response information, the test result is determined to be that the main battery management unit responds correctly to the fault status data.

14. The test method according to any one of claims 11-13, characterized in that, The battery status data includes data on the battery device under high voltage conditions.

Images