Lithium battery charging and discharging test method and system, computer equipment and storage medium

Abstract

The invention relates to the technical field of battery charging and discharging testing, and provides a lithium battery charging and discharging testing method and system, computer equipment and a storage medium. The method comprises the following steps: constructing a test project comprising a test script, a communication abnormity monitoring program and a plurality of charge and discharge test cases based on a communication access programming language, deploying the test project to test analysis equipment, and starting and running the test project; and simulating charging and discharging interaction between the charging and discharging equipment and the to-be-tested battery through the bus simulation tool, performing anomaly detection and anomaly processing on the collected bus message through the communication anomaly monitoring program, and generating a charging and discharging test report until the operation of the test project is finished. According to the method, the data accuracy and real-time requirements of the test scene can be met, the test abnormal risk and the test cost are reduced, the test safety and efficiency are ensured, and the stability and reliability of the test process are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of battery charge and discharge testing, and in particular to a lithium battery charge and discharge testing method, system, computer equipment and storage medium. Background Art

[0002] Lithium batteries are the power source of electric vehicles and a key component of energy storage systems. Their performance and safety directly impact the operation and reliability of the entire system. To ensure that lithium batteries meet quality and performance requirements, battery testing has become an indispensable step in battery research and development, production, and use.

[0003] In battery charge and discharge testing, the CAN bus has become the most commonly used communication method due to its advantages such as high reliability, strong real-time performance, and good anti-interference ability. The actual battery charge and discharge test environment is relatively complex, with many communication interference factors such as electromagnetic interference, temperature changes, and vibration, which can easily cause CAN bus communication failures, resulting in poor test results, inability to guarantee battery quality, and even damage to the battery or test equipment, test interruption, or test failure. However, existing battery charge and discharge test methods do not focus on real-time communication anomaly monitoring and anomaly handling of the CAN bus during the test. With the continuous growth of test requirements and the continuous improvement of test complexity, the shortcomings of existing test methods in communication anomaly detection and handling have become increasingly prominent, making it difficult to ensure the stability and reliability of battery charge and discharge tests, and it is also impossible to ensure the safety of equipment during the test. Therefore, there is an urgent need to provide a lithium battery charge and discharge test method that can monitor communication anomalies in real time and handle them in a timely manner. Summary of the Invention

[0004] The purpose of the present invention is to provide a lithium battery charge and discharge test method. By adding parallel communication anomaly monitoring logic to the actual battery charge and discharge test process, bus communication data transmitted by the battery end during the test is collected and analyzed in real time, various types of bus communication anomalies are timely and accurately perceived and targeted anomaly processing is performed. While meeting the data accuracy and real-time requirements of the battery test scenario, the test anomaly risk and test cost are reduced, the test safety and efficiency are ensured, and the stability and reliability of the test process are improved.

[0005] In order to achieve the above objectives, it is necessary to provide a lithium battery charge and discharge test method, system, computer equipment and storage medium to address the above technical problems.

[0006] In a first aspect, an embodiment of the present invention provides a lithium battery charge and discharge test method, the method comprising the following steps:

[0007] A test project is constructed based on a communication access programming language according to a pre-built test environment, and the test project is deployed on a test and analysis device; the test environment includes a bus simulation tool, the test and analysis device communicatively connected to the bus simulation tool, a charge and discharge device, and a battery to be tested; the test project includes a test script, a communication anomaly monitoring program, and multiple charge and discharge test cases; the communication anomaly monitoring program includes communication anomaly monitoring logic and communication anomaly handling logic;

[0008] In response to the start-up of the test project, the test script is parsed to sequentially obtain each of the charge and discharge test cases, and according to the charge and discharge test cases, the charge and discharge interaction between the charge and discharge device and the battery under test is simulated by the bus simulation tool, and the bus messages collected in real time are analyzed for anomalies by the communication anomaly monitoring program. When it is determined that a communication anomaly exists, a corresponding anomaly handling strategy is executed;

[0009] When the test process is completed, a corresponding charge and discharge test report is generated.

[0010] Furthermore, the step of constructing a test project based on the communication access programming language includes:

[0011] Generate a corresponding bus database file according to the test environment and test requirements;

[0012] Constructing corresponding charge and discharge test cases according to each target test scenario, and generating the test script based on the communication access programming language according to each charge and discharge test case and the main test logic;

[0013] Generate corresponding communication anomaly detection rules and anomaly handling strategies based on bus communication protocol standards and transmission requirements of various bus communication messages, and generate the communication anomaly monitoring program based on the communication access programming language according to the communication anomaly detection rules and the anomaly handling strategies;

[0014] The test project is generated according to the communication anomaly monitoring program, the test script and each of the charge and discharge test cases.

[0015] Furthermore, the step of constructing a test project based on the communication access programming language also includes:

[0016] Based on regular expression matching technology, the communication anomaly monitoring program and the test script are statically analyzed, and according to the corresponding static check results, the communication anomaly monitoring program and the test script are updated; the static analysis includes variable declaration matching, data type consistency check, signal range check, message ID range check and message sending condition check.

[0017] Furthermore, the step of constructing a test project based on the communication access programming language also includes:

[0018] According to the pre-built program verification simulation environment, the communication anomaly monitoring program is simulated and run based on the preset simulation scenario, and the communication anomaly monitoring program is updated according to the corresponding simulation run results.

[0019] Furthermore, the communication anomaly monitoring logic includes communication message timeout monitoring logic and communication data anomaly monitoring logic;

[0020] The step of performing abnormality detection and analysis on the bus messages collected in real time by the communication abnormality monitoring program includes:

[0021] Acquire message information of each bus message; the message information includes message ID, data content and sending cycle;

[0022] Performing anomaly detection on the message information of each bus message according to the communication message timeout monitoring logic and the communication data anomaly monitoring logic, and generating corresponding anomaly detection results;

[0023] Visually display each of the bus messages and the corresponding anomaly detection results and test case execution status.

[0024] Furthermore, the communication anomaly includes communication message timeout and communication data anomaly;

[0025] When it is determined that a communication anomaly exists, the step of executing a corresponding anomaly handling strategy includes:

[0026] Automatically accumulate the communication abnormality duration corresponding to the message ID of the bus message, and determine whether the communication data corresponding to the message ID in the previous cycle is normal. If normal, send the communication data corresponding to the message ID in the previous cycle to the charging and discharging device through the bus simulation tool; otherwise, stop sending the communication data corresponding to the message ID;

[0027] Determine whether the communication abnormality duration exceeds a preset duration threshold. If so, control the bus simulation tool to stop sending communication data, generate an abnormality alarm through the charging and discharging device, and stop the current test process.

[0028] Furthermore, the step of executing a corresponding exception handling strategy when determining that a communication anomaly exists further includes:

[0029] Generate a corresponding communication anomaly report based on the charge and discharge test case corresponding to the communication anomaly, the anomaly occurrence time, the anomaly type, the anomaly details and the anomaly handling measures; the anomaly details include the message ID, data length and data content.

[0030] In a second aspect, an embodiment of the present invention provides a lithium battery charge and discharge test system, the system comprising:

[0031] A test project construction module is configured to construct a test project based on a pre-built test environment and a communication access programming language, and deploy the test project on a test and analysis device; the test environment includes a bus simulation tool, the test and analysis device communicatively connected to the bus simulation tool, a charge and discharge device, and a battery to be tested; the test project includes a test script, a communication anomaly monitoring program, and multiple charge and discharge test cases; the communication anomaly monitoring program includes communication anomaly monitoring logic and communication anomaly handling logic;

[0032] a test running module, configured to, in response to the start-up of the test project, parse the test script to sequentially obtain each of the charge and discharge test cases, and simulate the charge and discharge interaction between the charge and discharge device and the battery under test using the bus simulation tool according to the charge and discharge test cases, and perform anomaly detection and analysis on bus messages collected in real time using the communication anomaly monitoring program, and execute a corresponding anomaly handling strategy when it is determined that a communication anomaly exists;

[0033] The report generation module is used to generate a corresponding charge and discharge test report when the test project is completed.

[0034] In a third aspect, an embodiment of the present invention further provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0035] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of the above method when executed by a processor.

[0036] The above invention provides a lithium battery charge and discharge test method, system, computer equipment and storage medium. The method realizes a test environment based on a pre-built bus simulation tool, a test analysis device connected to the bus simulation tool, a charge and discharge device and a battery to be tested. A test project including a test script, a communication anomaly monitoring program and multiple charge and discharge test cases is constructed based on a communication access programming language and deployed on the test analysis device. In response to the start-up of the test project, the test script is parsed to obtain each charge and discharge test case in turn. According to the charge and discharge test case, the bus simulation tool is used to simulate the charge and discharge interaction between the charge and discharge device and the battery to be tested, and the communication anomaly monitoring program is used to perform anomaly detection and analysis on the bus messages collected in real time. When it is determined that there is a communication anomaly, the corresponding exception handling strategy is executed until the end of the test project, and a technical solution for generating a corresponding charge and discharge test report. Compared with the existing technology, this lithium battery charge and discharge test method can monitor communication anomalies in real time and handle them in a timely manner during actual battery charge and discharge tests. It can not only meet the data accuracy and real-time requirements of battery testing scenarios, but also reduce the risk of test anomalies and test costs, ensure test safety and efficiency, and improve the stability and reliability of the test process, thereby effectively improving test efficiency, safety and quality, and providing reliable protection for battery product quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 1 is a flow chart of a lithium battery charge and discharge test method according to an embodiment of the present invention;

[0038] Figure 2 is a schematic structural diagram of a test environment in an embodiment of the present invention;

[0039] Figure 3 Schematic diagram of the structure of the program verification simulation environment in an embodiment of the present invention;

[0040] Figure 4 1 is a schematic structural diagram of a lithium battery charge and discharge test system according to an embodiment of the present invention;

[0041] Figure 5 1 is a diagram showing the internal structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solutions and beneficial effects of the present invention more clear, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. Obviously, the embodiments described below are part of the embodiments of the present invention and are only used to illustrate the present invention, but are not used to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0043] The lithium battery charge and discharge test method provided by the present invention can be understood as a lithium battery charge and discharge test method that is based on the current application status that the existing battery charge and discharge test cannot perceive bus communication anomalies in real time and handle anomalies in a timely manner, making it difficult to effectively ensure the stability, reliability and safety of actual battery tests. The method proposes a method that adds a bus abnormality communication monitoring and abnormality handling program built based on an access programming language to the test project, so that it can perceive various types of communication anomalies in real time and perform adaptive abnormality handling by capturing and analyzing bus communication data during the execution of test cases. Since the CAN (Controller Area Network) bus is the most commonly used communication method in actual battery charge and discharge test scenarios, the following embodiment will take the monitoring and handling of CAN bus communication anomalies as an example to explain the lithium battery charge and discharge test method of the present invention in detail.

[0044] In one embodiment, Figure 1 As shown, a lithium battery charge and discharge test method is provided, comprising the following steps:

[0045] S10. According to the pre-built test environment, a test project is constructed based on the communication access programming language, and the test project is deployed on the test analysis equipment; the test environment includes a bus simulation tool, a test analysis equipment connected to the bus simulation tool, a charging and discharging equipment, and a battery to be tested; the test project includes a test script, a communication anomaly monitoring program, and multiple charging and discharging test cases; the communication anomaly monitoring program includes communication anomaly monitoring logic and communication anomaly handling logic.

[0046] The test environment can be understood as the test case running environment required for executing the battery charge and discharge test, wherein the bus simulation tool is understood as a bus simulation tool for realizing information interaction between the battery to be tested and the charging and discharging equipment; the battery to be tested can be understood as a battery sample to be evaluated that needs to be tested for charging and discharging functions or performance; the charging and discharging equipment can be understood as a charging pile device used to simulate the communication interaction with the battery to be tested during the actual charging and discharging process; the test and analysis equipment can be understood as a terminal device for testing, analyzing and displaying the collected relevant test data. In order to achieve reliable simulation of the CAN bus communication between the battery to be tested and the charging and discharging equipment in the battery charge and discharge test, this embodiment preferably selects the VN1640A device as the bus simulation tool, and the test and analysis equipment selects the terminal device installed with CANoe software; such as Figure 2 As shown, the test and analysis equipment is physically connected to the CAN interface card of the VN1640A device via USB, the CAN interface of the VN1640A device is connected to the battery to be tested via a CAN line, and at the same time, the VN1640A device is connected to the charging and discharging equipment via a CAN line.

[0047] The Control and Automation Programming Language (CAPL) is a scripting language specifically designed for automotive electronics testing and development. It can implement complex automated testing and control tasks. Specifically, the steps for building a test project based on the CAPL include:

[0048] Generate the corresponding bus database file according to the test environment and test requirements; the specific content of the test requirements will vary according to the actual test objectives, and may include the role of the object under test in the CAN bus network (sending node and / or receiving node), communication scenario (periodic message, event-triggered message, etc.), signal type (maximum single cell voltage value, minimum single cell voltage value, etc.) and hardware interface definition (CAN channel, baud rate, etc.) and other information; the corresponding bus database file is a DBC (Database Can) file, which is a standard file format for describing the CAN network data format, usually including messages (message ID, message period, data length, sending node, etc.), signals (name, starting position, bit width, offset, etc.) and network nodes (devices or controllers that send or receive CAN messages) and comments and other contents; the specific bus database file generation process can refer to the relevant existing technology implementation and will not be described in detail here.

[0049] According to each target test scenario, corresponding charge and discharge test cases are constructed respectively, and according to each charge and discharge test case and the main test logic, a test script is generated based on the communication access programming language.

[0050] Among them, the charge and discharge test cases can be understood as the use cases of related functional scenario tests that need to be performed during the actual lithium battery charging test process, which may include various normal charging scenario use cases, various abnormal charging scenario use cases, various normal discharge scenario use cases, various abnormal discharge scenario use cases and various normal charge and discharge scenario use cases, etc. The specific use case content varies according to the actual target test scenario; the corresponding main test logic can be understood as the automated test control logic that corresponds to the entire test project and organizes and manages the execution sequence of each charge and discharge test case, and each charge and discharge test case can be integrated into the main test logic through code calls, and a test script that can control the operation of the entire test project is generated based on the CAPL language.

[0051] Based on the bus communication protocol standards and the transmission requirements of various bus communication messages, corresponding communication anomaly detection rules and anomaly handling strategies are generated. Based on the communication anomaly detection rules and anomaly handling strategies, a communication anomaly monitoring program is generated based on the communication access programming language. Among them, the communication anomaly monitoring program can be understood as an independent module written separately based on the CAPL language for collecting and analyzing the bus communication messages of the battery under test. It can be executed in parallel during each charge and discharge test case to perceive and handle communication anomalies during the execution of each charge and discharge test case in real time, thereby ensuring the stability, reliability and safety of the execution of each charge and discharge test case. The corresponding communication anomaly detection rules and anomaly handling strategies serve as the processing basis for the communication anomaly monitoring program.

[0052] The communication anomaly detection rules in this embodiment can be understood as various communication anomaly determination rules set based on the CAN bus communication protocol and the actual transmission requirements (transmission cycle, effective range of communication data, etc.) of various CAN bus communication messages received and sent by the battery under test during the battery charge and discharge test. A series of detailed normal communication standards are defined in the CAPL language as the basis for determining whether there is an abnormality in the communication. For example, for the update cycle of the battery under test's CAN communication messages, certain important messages can be specified to be updated within a fixed time interval. For example, the maximum and minimum cell voltages must be updated within 3 seconds. The corresponding cell voltage update cycle anomaly detection rule is to determine whether the cell voltage communication message can be updated once within 3 seconds. If so, the communication cycle is considered normal. Otherwise, the message transmission or reception time exceeds the specified time range, indicating a communication message timeout. For another example, for CAN communication data anomaly detection, each type of data has a predetermined reasonable value range. Assuming that the collected cell temperature value should normally be between -30°C and 70°C, the corresponding cell temperature communication data anomaly detection rule is to determine whether the collected cell temperature is within this range. If so, the cell temperature communication data is considered normal. Otherwise, the data value is considered to be outside the specified reasonable range and the cell temperature communication data is considered abnormal. It should be noted that in actual applications, each anomaly type has corresponding characteristics and judgment conditions, which can be efficiently and accurately identified through logical judgment statements in the CAPL language.

[0053] Generate a test project based on the communication anomaly monitoring program, test scripts and various charge and discharge test cases.

[0054] In principle, the test project generated by the above method steps can be directly used for test operation. However, considering that in actual application, there may be risks of bus conflicts, message loss, test interruption, or potential damage to the battery or charging and discharging equipment under test during the test project operation due to errors in the generation of communication anomaly monitoring programs and test scripts in the test project, in order to ensure the stability and reliability of the actual test project operation process, this embodiment preferably performs static analysis of the communication anomaly monitoring program and test scripts at the code level before starting the test project operation, so as to discover construction problems of the test project at the front end, reduce test costs and improve test efficiency.

[0055] Specifically, the steps of constructing a test project based on the communication access programming language also include:

[0056] Based on regular expression matching technology, static analysis is performed on the communication anomaly monitoring program and test scripts, and the communication anomaly monitoring program and test scripts are updated according to the corresponding static inspection results.

[0057] Among them, static analysis can be understood as checking whether the code of the communication anomaly monitoring program and test script has irregularities, potential risks, and functional integrity issues based on preset specifications and rules; in order to ensure the comprehensiveness of static analysis, this embodiment preferably sets the static analysis to include variable declaration matching, data type consistency check, signal range check, message ID range check, and message sending condition check, that is, based on the corresponding static analysis rules, a static analysis script (which can be a Python script) is written using regular expression matching technology, and the static analysis script is called by the CAPL program to perform static analysis on the communication anomaly monitoring program and test script. After the static analysis is completed, the analysis results are output to a file to form a corresponding analysis report. The specific static analysis implementation process is as follows:

[0058] 1) Variable declaration matching to check whether each variable declaration has syntax errors and type errors. In actual applications, first use regular expressions to search for all variable declaration statements in the detected code content (communication anomaly monitoring program and test script), match common variable declaration types, such as integers int, floating point numbers float, characters char, double-precision floating point numbers double, long integers and other different types of variable declarations, and generate a corresponding matching result list; then, traverse each variable declaration in the matching result list and perform a syntax check, first check whether the declaration ends with a semicolon, if not, find the position of the declaration in the code, add the error position and error cause to the variable declaration error list, if so, extract the type part in the declaration based on the regular expression, and check whether the type is in the predefined valid type list (int, float, char, double, long), if not, also define it to the code position, and add the corresponding error position and error cause to the variable declaration error list;

[0059] 2) Data type consistency check to check whether the assigned data type of the data field of each message is consistent with the required field type. For example, a floating point number cannot be assigned to a character type message data field. In actual application, first use the regular expression message\s+(\w+)\s*{([^}]*)} to search for each message declaration statement to generate a tuple containing the message name and message body; then, use the regular expression (\w+)\s+(\w+) to extract the field information (data field and field type) from the message body, and store each message body and its corresponding field information list in the message dictionary; then use the regular expression (\w+)\.(\w+)\s*=\s*([^;]+) to search for the assignment statement of each message data field in the code to obtain the corresponding tuple containing the message name, field name and assigned value; finally, traverse each assignment statement to check whether the message name and field name exist in the message dictionary. If they exist, , then obtain the corresponding field type and perform an assignment type check on the field type (taking int, float, and byte as examples). For example, for the int type, the assigned value can be converted to an integer. If the converted value is not equal to the original floating-point number, it means that the value is a decimal, and a type mismatch error message is added to the message assignment type error list; for the float type, the assigned value can be converted to a floating-point number. If the conversion fails, the corresponding exception error message is added to the message assignment type error list; for the byte type, an attempt can be made to convert the assigned value to an integer. If the converted value is not equal to the original floating-point number or is not in the range of 0-255, a type mismatch error message is added to the message assignment type error list.

[0060] 3) Signal range check: This checks the validity of each signal value in each CAN message (whether it is within the valid value range). For example, if a message myMsg is defined, where the value range of the signal mySignal is 0 to 100, and if the value of mySignal is assigned to 150 in the program, it exceeds the valid range, and an error message should be output to ensure the legitimacy of the signal value. In actual applications, regular expressions are first used to extract the signal definition and valid value range from the code and store them in a signal matching dictionary. Then, regular expressions are used to find all signal assignment statements and each assignment statement is checked to determine whether the signal value is within the valid range. If it is out of range, the error message is recorded in the signal error list.

[0061] (4) Message ID range check to check whether each message ID (standard frame ID and extended frame ID) is within the valid value range. In actual applications, a regular expression is predefined to match the two message definitions of standard frame (message <message ID><message name>) and extended frame (extended message <message ID><message name>), and the matching items are stored in the form of a tuple list. Then, each matching item in the tuple is checked for standard message and extended message. If the first element of the tuple is message, it means it is a standard message definition. The captured message ID string (the second element of the tuple) is converted to a hexadecimal integer. If the conversion is successful, the message ID is checked to see if it is within the legal range of the standard frame ID (0-0x7FF). If the message ID is not within this range, an error message "Standard message ID out of range" will be output. Conversely, if an exception occurs during the conversion process, it means that the message ID format is incorrect, and an error message "Invalid message ID format" will be output. If the third element of the tuple is "extended," it indicates an extended message definition. Similarly, the captured message ID string (the fourth element of the tuple) can be converted to a hexadecimal integer. After successful conversion, the program checks whether the message ID is within the legal range of extended frame IDs (0-0x1FFFFFFF). If it is out of range, an error message indicating that the extended message ID is out of range is output. If an exception occurs during the conversion, an error message indicating that the message ID format is invalid is output.

[0062] (4) Check the message sending conditions to check whether there are any flag errors or missing necessary conditions in each message sending condition. In actual applications, the regular expression message\s+\w+\s+\w+;\s*output\s+\w+;can be used to find the message sending statements in the code, and for each message sending statement, the nearest if statement can be found, and the logical conditions in the brackets can be extracted and added to the condition list. Then, the flag list can be traversed, and the regular expression can be used to accurately match each flag to see if it appears in each logical condition in the condition list. The flags that do not appear can be added to the message sending condition problem list. Then, the logic analysis of each logical condition can be performed. For example, when two flags appear in the logical condition at the same time, it is determined whether they can be operated with an AND operation (&&) or an OR operation (||). If not, it is considered that a necessary condition is missing, and this problem is also added to the message sending condition problem list.

[0063] The above-mentioned method steps can complete a comprehensive static analysis of the communication anomaly monitoring program and the test script, so that the communication anomaly monitoring program and the test script can be efficiently adjusted according to the various error lists in the static inspection results finally obtained, which can effectively reduce the probability of test anomaly risks caused by errors in the test project construction. It should be noted that since the communication anomaly monitoring program and the test script are two independent code modules, in actual applications, the above-mentioned method steps can be used to perform static analysis on the communication anomaly monitoring program and the test script respectively, and obtain the corresponding static inspection results of the two. When there are code errors in the static inspection results corresponding to the communication anomaly monitoring program and the test script, the corresponding code is modified and updated according to the error locations and error types.

[0064] The above static analysis can detect basic errors at the code level, but considering that in actual applications there may be functional anomalies caused by logical errors in code implementation, which in turn affect the application effect of the test project, in order to ensure the reliability of the test project construction and the efficiency of the application as much as possible, this embodiment preferably performs a simulation run verification on the communication anomaly monitoring program and test scripts in the test project before the test project is run to detect errors at the code function logic level. Specifically, the steps of constructing a test project based on the communication access programming language also include:

[0065] According to the pre-built program verification simulation environment, the communication anomaly monitoring program is simulated and run based on the preset simulation scenario, and the communication anomaly monitoring program is updated according to the corresponding simulation run results; wherein, the program verification simulation environment can be understood as a simple simulation run environment directly constructed by using the test analysis equipment and bus simulation tools deployed with the test project, such as Figure 3As shown, the bus simulation tool can use the VN1640A device, the test and analysis device can use a terminal device installed with CANoe software, and the test and analysis device is physically connected to the CAN interface card of the VN1640A device via USB. The CAN1 channel interface of the VN1640A device is connected to the CAN3 channel and the CAN4 channel through the CAN line, and the CAN3 channel is used to simulate the battery sending communication messages, and the CAN1 channel simulates receiving the communication messages sent by the battery and forwarding them to the CAN4 channel to simulate the sending and receiving of CAN communication messages in the charge and discharge test.

[0066] In practical applications, based on Figure 3 The program verification simulation environment shown is pre-built based on CAPL language Figure 3 The program verification simulation environment shown matches the simulation verification project (including the communication anomaly monitoring program, simulation test scripts, normal communication process simulation use cases and abnormal communication process simulation use cases). Based on the simulation verification project, simulation runs of the normal communication process and abnormal communication process are performed respectively to verify whether the communication anomaly monitoring program in the test project can realize anomaly detection, analysis and anomaly handling of the real-time collected bus messages:

[0067] 1) Normal communication process simulation runs. When the communication anomaly monitoring program starts, a 100ms timer is set. Each time the timer times out, the simulation test script controls the sending of pre-initialized battery pack messages through the CAN3 channel. At the same time, the value of the message sending count variable is incremented by 1, and the message ID and sequence number of the message are recorded. When the CAN1 channel receives a battery pack message that matches the message ID, the corresponding message receiving count variable and message forwarding count variable are incremented by 1. At this point, the normal communication process simulation case is triggered, and the received message is forwarded from the CAN1 channel to the CAN4 channel. At the same time, the simulation test script records the message reception and forwarding information.

[0068] Then, during the data verification phase, when the CAN4 channel receives a message with a matching ID, the channel 4 message reception counter variable is incremented by 1 and the reception information is recorded. The communication anomaly monitoring program compares the channel 4 message reception counter variable with the message forwarding counter variable. If the two are not equal, it indicates possible data loss. The communication anomaly monitoring program also checks the message length and content and outputs a corresponding warning message if any inconsistency is found, thus completing the verification of sent and received data. After the normal communication process test is determined to be successful, the following abnormal communication test process is performed.

[0069] 2) Abnormal communication process simulation operation is divided into the following two parts:

[0070] Abnormal communication data simulation: This simulates abnormal communication on the CAN3 channel. A battery pack message is constructed with the highest cell voltage signal set to 65V. This message is then sent via the CAN3 channel, while recording information about the abnormal voltage. The communication anomaly monitoring program then continuously monitors messages received on the CAN4 channel. If the CAN4 channel receives a message with a normal voltage within 3 seconds and no related information is received after 3 seconds, this indicates that the communication anomaly monitoring program has successfully triggered the intended exception handling strategy.

[0071] Communication delay or interruption anomaly simulation: This process stops sending messages on the CAN3 channel by canceling the previously set timer and simultaneously records the information indicating that the CAN3 channel has stopped sending. The communication anomaly monitoring program then continuously monitors messages received on the CAN4 channel. If the message received on the CAN4 channel meets the exception handling strategy response rules in the abnormal communication process simulation use case, and the previous normal communication process test success flag is true, testing and verification of the abnormal communication process and the communication anomaly monitoring program's response after the CAN3 channel stops sending are complete.

[0072] Through the simulation runs in the above two aspects, the functional performance and data processing accuracy of the communication anomaly monitoring program under normal and abnormal communication conditions can be fully verified. It should be noted that if any functional anomaly is found during the above simulation run, it can be debugged and resolved immediately to ensure that during the actual charge and discharge test, the communication anomaly monitoring program can accurately identify various communication anomalies such as message loss, transmission delay, or message data anomalies in real time, and trigger the corresponding exception handling strategy in a timely manner according to the type and severity of the detected anomaly, so as to minimize the impact of communication anomalies on test results and test safety, and provide reliable support for the reliability and safety of the test.

[0073] After building a reliable test project through the above method steps, it needs to be deployed on the test and analysis equipment, and the relevant CAN channel configuration must be completed in the CANoe software installed on the test and analysis equipment: create a cpf file with two CAN channels (two CAN channels used to capture bus messages received and sent by the battery under test); open the "CAN Channel Configuration" window, select the channels corresponding to the two CAN interface cards, set the CAN channel baud rate according to the actual communication baud rate of the battery under test (for example, 500kbps), and then load the DBC (Database CAN) files corresponding to the battery under test on the two CAN channels. After completing the above CANoe software configuration, the test and analysis equipment can control the test project to run the required battery charge and discharge automation test process and collect data during the test in real time for analysis and display.

[0074] Before the test project is run, this embodiment conducts a comprehensive analysis and risk assessment of the communication anomaly monitoring program and test scripts, so as to facilitate the early adoption of preventive and optimization measures, which can effectively reduce the probability of actual test anomalies, thereby improving the actual test efficiency and test quality.

[0075] S20. In response to the start-up of the test project, the test script is parsed to obtain each charge and discharge test case in turn, and according to the charge and discharge test case, the charge and discharge interaction between the charge and discharge device and the battery to be tested is simulated by a bus simulation tool, and the bus message collected in real time is subjected to anomaly detection and analysis by a communication anomaly monitoring program. When it is determined that a communication anomaly exists, a corresponding anomaly handling strategy is executed; wherein, the test script is parsed to obtain each charge and discharge test case in turn, and according to the charge and discharge test case, the charge and discharge interaction between the charge and discharge device and the battery to be tested is simulated by a bus simulation tool. The process can be implemented by referring to relevant similar existing technologies and will not be elaborated here.

[0076] In order to ensure the comprehensiveness of communication anomaly monitoring, this embodiment preferably configures the communication anomaly monitoring logic to include communication message timeout monitoring logic and communication data anomaly monitoring logic. Specifically, the steps of performing anomaly detection and analysis on bus messages collected in real time by the communication anomaly monitoring program include:

[0077] Obtain message information of each bus message; wherein, the message information is information obtained by parsing and processing the bus messages collected in real time according to the preset collection frequency, including message ID, data content and sending cycle, and the message ID is used to indicate the message data type, the data content is the communication data transmitted by the message, such as single cell voltage and single cell temperature, etc., and the sending cycle can be understood as a fixed transmission cycle of the signal in the message, etc. The specific acquisition method can refer to the existing CAN bus message parsing technology and is not limited here.

[0078] According to the communication message timeout monitoring logic and the communication data anomaly monitoring logic, the message information of each bus message is detected for anomalies, and corresponding anomaly detection results are generated.

[0079] The message timeout monitoring logic can be understood as checking whether the real-time message sending period meets the expected requirements, and the communication data anomaly monitoring logic can be understood as checking whether the data content in the message is within the reasonable value range of the corresponding data item. The specific implementation process of obtaining anomaly detection results based on the communication message timeout monitoring logic and the communication data anomaly monitoring logic is as follows:

[0080] 1) Message timeout monitoring logic: When the communication anomaly monitoring program is started, a timer is set for each bus message type (message ID) with different sending cycles, and the corresponding timeout period is set according to the expected sending cycle; when a message with the expected ID is received, the reception flag of the message type is set to true and the timer is reset. If the timer times out and the message reception flag is false, the message is determined to be lost, and the corresponding anomaly detection result is set to a communication message timeout anomaly. After outputting the corresponding prompt information, the message reception flag of the corresponding message type is reset.

[0081] 2) Communication data anomaly monitoring logic: When the communication anomaly monitoring program is started, a corresponding data refresh frequency control timer is set for each type of communication data, and a data assignment variable and a corresponding variable flag are defined; when a message of a certain communication data is received, the communication value corresponding to the message is assigned to the corresponding data assignment variable; if the data assignment variable is within the normal range specified by the communication data, the corresponding variable flag is set to true; otherwise, it is determined that there is a communication data error, the corresponding anomaly detection result is set to communication data anomaly, the flag is set to false, and the corresponding prompt information is output.

[0082] Visually display each bus message and the corresponding anomaly detection results and test case execution status.

[0083] Among them, visual display can be understood as the ability to directly display the communication status and test progress of the test environment. This can be achieved through the Panel interface of the CANoe software, allowing operators to understand the test status in real time and promptly identify potential problems. In actual application, different color buttons can be used on the Panel interface to indicate normal and abnormal tests, allowing operators to intuitively observe the communication status. Using a bar chart to compare the number of occurrences of different types of abnormalities helps operators quickly identify the main abnormality types. The specific implementation process is as follows:

[0084] 1) Regarding communication anomaly handling: Create two icon controls (Icon Controls) in the Panel Editor of the CANoe software, one representing the normal state and the other representing the abnormal state. For example, name the normal state icon icoNormal and the abnormal state icon icoError. When the interface is initially displayed, the visibility of the abnormal state icon icoError can be set to hidden. If a communication anomaly is detected during the test, the normal icon icoNormal is hidden and the abnormal icon icoError is displayed. When communication remains normal, the normal icon is always displayed and the abnormal icon is hidden.

[0085] 2) About the display of different types of communication anomalies: Create rectangular controls on the Panel Editor to represent bar charts for different types of anomalies, and set the corresponding maximum bar height according to the preset maximum number of anomalies. In the communication anomaly monitoring program, set a counter for each type of anomaly, and when an anomaly of the corresponding type is detected, the corresponding counter value is increased. For example, define two counter variables, respectively used to record the number of communication message timeouts and communication data anomalies; when an anomaly occurs, add 1 to the corresponding counter value, and calculate the corresponding real-time bar height based on the current counter value relative to the maximum number of anomalies, based on the maximum height of the bar, to display a statistical bar chart of the number of occurrences of different anomaly types in real time, so that testers can understand the test communication situation in real time. In addition, you can also adjust the style of the rectangular control in the Panel Editor, set different colors to distinguish the types of anomalies, and mark the anomaly type and the number of anomalies for the bar chart.

[0086] The communication anomalies in this embodiment include communication message timeouts and communication data anomalies. Although different anomaly types may have different impacts on the test results, due to the high frequency of anomaly detection, the impact of a single anomaly or a communication anomaly within the test's permitted data anomaly duration on the test can be ignored. Preferably, based on the difference in the impact of different anomaly levels on the actual test, it is precisely determined whether the test can proceed smoothly as expected under different anomaly levels, and different anomaly strategies are provided for different anomaly levels to ensure the rationality and flexibility of actual communication anomaly handling. Specifically, when it is determined that a communication anomaly exists, the steps of executing the corresponding anomaly handling strategy include:

[0087] The communication abnormality duration corresponding to the message ID of the bus message is automatically accumulated, and it is determined whether the communication data corresponding to the message ID in the previous cycle is normal. If normal, the communication data corresponding to the message ID in the previous cycle is sent to the charging and discharging device through the bus simulation tool. Otherwise, the sending of the communication data corresponding to the message ID is stopped. Among them, the communication abnormality duration can be understood as the total duration used to count the communication message timeouts and communication data abnormalities in the bus message.

[0088] Determine whether the communication abnormality duration exceeds the preset duration threshold. If so, control the bus simulation tool to stop sending communication data, generate an abnormal alarm through the charging and discharging equipment, and stop the current test process.

[0089] To facilitate understanding of the execution logic of the above exception handling strategy, the following example illustrates the communication message timeout and communication data anomaly at the maximum cell voltage (which can be replaced by other communication signals) during the charge and discharge test of a 1P48S module composed of lithium iron phosphate cells:

[0090] Whenever a communication message timeout and / or communication data anomaly is detected at the maximum cell voltage, the corresponding communication anomaly duration is automatically added to the corresponding message transmission cycle (1 second). Subsequently, the exception handling strategy in the communication anomaly monitoring program immediately determines whether the maximum cell voltage value of the previous cycle (1 second) is less than 3.5V. If the voltage value is less than 3.5V, the exception handling strategy will control the bus simulation tool (VN1640A device) to send the relevant data of the previous cycle (the previous 1 second) to the charging and discharging device. Otherwise, data transmission will be stopped.

[0091] When it is detected that the communication abnormality duration corresponding to the maximum single-cell voltage signal exceeds the preset duration threshold (multiple transmission cycles, such as 3 seconds), the abnormality handling strategy will control the bus simulation tool (VN1640A device) to stop sending messages, so that the charging and discharging equipment will trigger an abnormal alarm and stop the current test process to ensure test safety.

[0092] It should be noted that, in actual applications, the communication anomaly handling strategies for different message signals can all refer to the situation where the communication anomaly of the above-mentioned maximum single-cell voltage signal occurs, and can reduce the impact of the corresponding communication anomaly on the test progress and test safety. It will not be repeated here.

[0093] In order to facilitate the tracing and analysis of communication anomalies detected during the test process after the test is completed, this embodiment preferably generates a communication anomaly report automatically by the communication anomaly monitoring program on a regular basis or when a communication anomaly is detected. The report is presented in an intuitive text format, which is convenient for the test operator to review and analyze. Specifically, when a communication anomaly is determined to exist, the step of executing the corresponding exception handling strategy also includes:

[0094] Generate a corresponding communication anomaly report based on the charge and discharge test case corresponding to the communication anomaly, the anomaly occurrence time, anomaly type, anomaly details, and anomaly handling measures. The anomaly details include the message ID, data length, and data content. Among them, the anomaly handling measures include using the previous cycle's communication data, stopping data transmission, and stopping the test process, as given in the above-mentioned anomaly strategy. The information content in the corresponding communication anomaly report can also be displayed in real time by popping up a prompt box on the Panel interface, so that operators can take timely measures to maintain the stability and reliability of the test and ensure the test progress and test results.

[0095] S30. When the test project is completed, a corresponding charge and discharge test report is generated; wherein the charge and discharge report can be understood as the battery performance test results obtained by executing each charge and discharge test case to test the battery under test in different charge and discharge scenarios. The specific data content of the charge and discharge test report and the generation process of the charge and discharge test report can refer to the relevant existing technology and are not specifically limited here.

[0096] It should be noted that during the actual test process, the bus communication message log can also be recorded to achieve traceability analysis of the communication situation during the test process. Specifically, when the test project is started, the test script can open a log file to store key information such as the message ID, data length, and data content of the CAN bus messages received during the entire test process. The log file is written until the test project stops running and the log file is closed. After the test is completed, the operation effect of the communication anomaly monitoring program can be evaluated based on the relevant log file data, and the communication anomaly monitoring program can be further optimized and adjusted based on the evaluation results.

[0097] The embodiment of the present invention provides a test project based on a communication access programming language, which includes a test script, a communication anomaly monitoring program and multiple charge and discharge test cases and is deployed on a test analysis device. After the test analysis device, the charge and discharge device and the battery to be tested are connected to a bus simulation tool, in response to the start-up of the test project, the test script is parsed to obtain each charge and discharge test case in turn, and according to the charge and discharge test case, the charge and discharge interaction between the charge and discharge device and the battery to be tested is simulated by the bus simulation tool, and the bus message collected in real time is analyzed for anomaly detection by the communication anomaly monitoring program. When it is determined that there is a communication anomaly, the corresponding anomaly handling strategy is executed until the end of the test project operation, and the corresponding charge and discharge test report is generated. The technical solution can not only be used in the test Before operation, a comprehensive analysis and risk assessment of the test project is conducted, and preventive and optimization measures are taken in advance to effectively reduce the probability of actual test anomalies, meet the data accuracy and real-time requirements of battery test scenarios, and improve the efficiency and quality of actual tests. In addition, through real-time collection and processing of bus communication data, various communication anomalies can be discovered promptly and accurately, and reliable anomaly handling can be performed, effectively avoiding test safety risks caused by abnormal situations, reducing test costs, ensuring test safety and test quality, and improving the stability and reliability of the test process. In addition, the system can automatically generate detailed anomaly reports and visually display test process information on the Panel interface to enhance operators' problem perception capabilities, facilitate optimization and adjustment of test design, and thus provide reliable guarantees for battery product quality.

[0098] It should be noted that although the steps in the above flowchart are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders.

[0099] In one embodiment, Figure 4 As shown, a lithium battery charge and discharge test system is provided, the system comprising:

[0100] Test project construction module 1 is used to construct a test project based on a pre-built test environment and a communication access programming language, and deploy the test project on the test analysis equipment; the test environment includes a bus simulation tool, the test analysis equipment connected to the bus simulation tool, the charging and discharging equipment, and the battery to be tested; the test project includes a test script, a communication anomaly monitoring program, and multiple charge and discharge test cases; the communication anomaly monitoring program includes communication anomaly monitoring logic and communication anomaly handling logic;

[0101] Test running module 2 is used to respond to the start-up of the test project, parse the test script to obtain various charge and discharge test cases in sequence, and simulate the charge and discharge interaction between the charge and discharge equipment and the battery under test through a bus simulation tool according to the charge and discharge test cases. It also uses a communication anomaly monitoring program to perform anomaly detection and analysis on the bus messages collected in real time. When it is determined that there is a communication anomaly, the corresponding anomaly handling strategy is executed;

[0102] The report generation module 3 is used to generate a corresponding charge and discharge test report when the test project is completed.

[0103] For the specific definition of the lithium battery charge and discharge test system, please refer to the definition of the lithium battery charge and discharge test method above. The corresponding technical effects can also be obtained equivalently, so we will not go into details here. Each module in the above-mentioned lithium battery charge and discharge test system can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0104] Figure 5 FIG. 1 shows an internal structure diagram of a computer device in one embodiment, which may be a terminal or a server. Figure 5 As shown, the computer device includes a processor, memory, network interface, display, camera and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a lithium battery charge and discharge test method can be implemented. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad provided on the computer device housing, or an external keyboard, touchpad or mouse.

[0105] It can be understood by those skilled in the art that Figure 5 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present invention and does not constitute a limitation on the computer device to which the solution of the present invention is applied. The specific computing device may include more or fewer components than shown in the figure, or combine certain components, or have the same component arrangement.

[0106] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0107] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above method are implemented.

[0108] In summary, the embodiments of the present invention provide a lithium battery charge and discharge test method, system, computer equipment and storage medium. The lithium battery charge and discharge test method realizes a technical solution by adding parallel communication anomaly monitoring logic in the actual battery charge and discharge test process to perform real-time collection and analysis of bus communication data transmitted by the battery end during the test, timely and accurately perceive various types of bus communication anomalies and perform targeted anomaly processing. This method can not only comprehensively analyze and assess the test project before the test is run, take preventive and optimization measures in advance, effectively reduce the probability of occurrence of actual test anomalies, meet the data accuracy and real-time requirements of the battery test scenario, and improve the efficiency and quality of the actual test, but also can timely and accurately detect various types of communication anomalies and perform reliable anomaly processing by real-time collection and processing of bus communication data, effectively reduce the safety risks and testing costs caused by abnormal situations, ensure test safety and test quality, and improve the stability and reliability of the test process. It can also automatically generate detailed anomaly reports and visually display test process information on the Panel interface to enhance the operator's ability to perceive problems, facilitate the optimization and adjustment of the test design, and thus provide reliable protection for the quality of battery products.

[0109] Each embodiment in this specification is described in a progressive manner, and the same or similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. It should be noted that the various technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the various technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0110] The above-described embodiments merely represent several preferred implementations of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the patent. It should be noted that a person skilled in the art can make several improvements and substitutions without departing from the technical principles of the present invention, and such improvements and substitutions should also be considered within the scope of protection of the present invention. Therefore, the scope of protection of the patent for this invention shall be based on the scope of protection of the claims.

Claims

1. A lithium battery charge and discharge test method, characterized in that: The method comprises the following steps: A test project is constructed based on a communication access programming language according to a pre-built test environment, and the test project is deployed on a test and analysis device; the test environment includes a bus simulation tool, the test and analysis device communicatively connected to the bus simulation tool, a charge and discharge device, and a battery to be tested; the test project includes a test script, a communication anomaly monitoring program, and multiple charge and discharge test cases; the communication anomaly monitoring program includes communication anomaly monitoring logic and communication anomaly handling logic; In response to the start-up of the test project, the test script is parsed to sequentially obtain each of the charge and discharge test cases, and according to the charge and discharge test cases, the charge and discharge interaction between the charge and discharge device and the battery under test is simulated by the bus simulation tool, and the bus messages collected in real time are analyzed for anomalies by the communication anomaly monitoring program. When it is determined that a communication anomaly exists, a corresponding anomaly handling strategy is executed; When the test process is completed, a corresponding charge and discharge test report is generated.

2. The lithium battery charge and discharge test method according to claim 1, wherein: The steps of constructing a test project based on a communication access programming language include: Generate a corresponding bus database file according to the test environment and test requirements; Constructing corresponding charge and discharge test cases according to each target test scenario, and generating the test script based on the communication access programming language according to each charge and discharge test case and the main test logic; Generate corresponding communication anomaly detection rules and anomaly handling strategies based on bus communication protocol standards and transmission requirements of various bus communication messages, and generate the communication anomaly monitoring program based on the communication access programming language according to the communication anomaly detection rules and the anomaly handling strategies; The test project is generated according to the communication anomaly monitoring program, the test script and each of the charge and discharge test cases.

3. The lithium battery charge and discharge test method according to claim 1, wherein: The step of constructing a test project based on the communication access programming language also includes: Based on regular expression matching technology, the communication anomaly monitoring program and the test script are statically analyzed, and according to the corresponding static check results, the communication anomaly monitoring program and the test script are updated; the static analysis includes variable declaration matching, data type consistency check, signal range check, message ID range check and message sending condition check.

4. The lithium battery charge and discharge test method according to claim 1 or 3, wherein: The step of constructing a test project based on the communication access programming language also includes: According to the pre-built program verification simulation environment, the communication anomaly monitoring program is simulated and run based on the preset simulation scenario, and the communication anomaly monitoring program is updated according to the corresponding simulation run results.

5. The lithium battery charge and discharge test method according to claim 1, wherein: The communication anomaly monitoring logic includes communication message timeout monitoring logic and communication data anomaly monitoring logic; The step of performing abnormality detection and analysis on the bus messages collected in real time by the communication abnormality monitoring program includes: Acquire message information of each bus message; the message information includes message ID, data content and sending cycle; Performing anomaly detection on the message information of each bus message according to the communication message timeout monitoring logic and the communication data anomaly monitoring logic, and generating corresponding anomaly detection results; Visually display each of the bus messages and the corresponding anomaly detection results and test case execution status.

6. The lithium battery charge and discharge test method according to claim 1, wherein: The communication anomaly includes communication message timeout and communication data anomaly; When it is determined that a communication anomaly exists, the step of executing a corresponding anomaly handling strategy includes: Automatically accumulate the communication abnormality duration corresponding to the message ID of the bus message, and determine whether the communication data corresponding to the message ID in the previous cycle is normal. If normal, send the communication data corresponding to the message ID in the previous cycle to the charging and discharging device through the bus simulation tool; otherwise, stop sending the communication data corresponding to the message ID; Determine whether the communication abnormality duration exceeds a preset duration threshold. If so, control the bus simulation tool to stop sending communication data, generate an abnormality alarm through the charging and discharging device, and stop the current test process.

7. The lithium battery charge and discharge testing method according to claim 1 or 6, wherein: The step of executing a corresponding exception handling strategy when determining that a communication anomaly exists further includes: Generate a corresponding communication anomaly report based on the charge and discharge test case corresponding to the communication anomaly, the anomaly occurrence time, the anomaly type, the anomaly details and the anomaly handling measures; the anomaly details include the message ID, data length and data content.

8. A lithium battery charge and discharge test system, characterized in that: The system comprises: A test project construction module is configured to construct a test project based on a pre-built test environment and a communication access programming language, and deploy the test project on a test and analysis device; the test environment includes a bus simulation tool, the test and analysis device communicatively connected to the bus simulation tool, a charge and discharge device, and a battery to be tested; the test project includes a test script, a communication anomaly monitoring program, and multiple charge and discharge test cases; the communication anomaly monitoring program includes communication anomaly monitoring logic and communication anomaly handling logic; a test running module, configured to, in response to the start-up of the test project, parse the test script to sequentially obtain each of the charge and discharge test cases, and simulate the charge and discharge interaction between the charge and discharge device and the battery under test using the bus simulation tool according to the charge and discharge test cases, and perform anomaly detection and analysis on bus messages collected in real time using the communication anomaly monitoring program, and execute a corresponding anomaly handling strategy when it is determined that a communication anomaly exists; The report generation module is used to generate a corresponding charge and discharge test report when the test project is completed.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images