Automatic test platform of battery management system

Abstract

The invention discloses an automatic test platform of a battery management system. The automatic test platform comprises an upper computer, a CAN analyzer, a tested system and a battery information simulation system. The tested system is provided with a debugging port for feeding back a system state and a communication port for intranet communication, and the battery information simulation system is provided with a calibration port for calibrating a battery parameter value and a sending port for sending a message; a debugging port of the tested system and a calibration port of the battery information simulation system are on the same CAN bus and are connected with the upper computer through the analyzer, and a sending port of the battery information simulation system is connected with a communication port of the tested system so as to send battery parameters; and the upper computer calibrates the battery parameters by sending the calibration message, and receives the verification message fed back by the debugging port of the tested equipment for verification. According to the test platform disclosed by the invention, automatic test can be realized, the problems that the test is tedious and the test system is inconvenient to move are solved, and the application environment of the automatic test is greatly improved.

Description

Technical Field

[0001] The present invention relates to the technical field of energy storage batteries, and in particular to an automatic testing platform for a battery management system. Technical Background

[0002] With the development of the energy storage field, lithium-ion battery systems have been widely used in the energy storage field, among which lithium-ion battery management systems have gradually become the main guarantee for ensuring the safety of energy storage products. Lithium-ion liquid-cooled battery packs in the energy storage field have increasingly higher requirements for the reliability and stability of battery management systems. At the same time, for different projects and different environments, the software iteration speed of battery management systems is also getting faster and faster. In the prior art, when testing lithium-ion battery systems, battery modules are generally required to cooperate in charging and discharging to complete relevant tests. The required test environment conditions are harsh, which is not conducive to the test, greatly prolongs the test cycle, and cannot achieve automated testing. If a battery simulator on the market is used, its size, communication compatibility, and low mobility and portability must also be considered, and it is impossible to quickly respond to fast and changing test tasks. Summary of the invention

[0003] In view of the above problems, the present invention provides an automated testing platform for a battery management system, which can realize automated testing, solve the problems of cumbersome testing and inconvenient movement of the testing system, and greatly improve the application environment of automated testing.

[0004] Technical Solution

[0005] An automated test platform for a battery management system comprises a host computer, a CAN analyzer, a system under test and a battery information simulation system, wherein the system under test has a debugging port for feeding back system status and a communication port for intranet communication, and the battery information simulation system has a calibration port for calibrating battery parameter values ​​and a sending port for sending messages; the debugging port of the system under test and the calibration port of the battery information simulation system are on a CAN bus and are connected to the host computer via the CAN analyzer, and the sending port of the battery information simulation system is connected to the communication port of the system under test to send battery parameters; the host computer calibrates the battery parameters by sending calibration messages, and simultaneously receives verification messages fed back by the debugging port of the device under test as test results for verification.

[0006] Preferably, the battery parameters are calibrated by extracting the minimum, maximum and other single cell temperatures from a CAN frame, and performing corresponding conversion and storage.

[0007] Preferably, the battery parameters are calibrated as follows: check the ID of the received CAN frame, read the 0th and 1st bytes, the 2nd and 3rd bytes, and the 4th and 5th bytes in the frame data respectively, and the three parts represent the temperature data of three different cells respectively; the data is in binary form, and the actual temperature value is obtained by subtracting a fixed offset and multiplying by a coefficient, and the calculated temperature value is saved in the corresponding global variable for access by subsequent program modules.

[0008] Preferably, sending the battery parameters includes: constructing a CAN frame including the battery cell voltage information, and sending it through the User_CanSend function.

[0009] Preferably, sending battery parameters is specifically as follows: defining a function SendCellVolt_1 for sending battery cell voltage information, calling the User_CanSend function, passing in infoMsgS as a parameter, a function for actually sending CAN messages; setting the ID field of infoMsgS to 0x00001001UL and the data length to 8 bytes; setting the content of the infoMsgS.Data array, each element is an 8-bit integer, and assigning it to specific battery cell voltage information, wherein the first and second bytes are set to the lowest 8 bits and highest 8 bits of g_CellVolltMin, the third and fourth bytes are set to the lowest 8 bits and highest 8 bits of g_CellVolltMax, the fourth and sixth bytes are set to the result of g_CellVolltNorm divided by 3200, in mV, and the fifth and seventh bytes are set to the result of taking the high bit of g_CellVolltNorm divided by 3200.

[0010] Preferably, the test cases are written based on the ZCANPRO tool. First, the calibration message and the verification message are decoded, that is, the message protocol is converted into a DBC file through the DB++ tool, and then the DBC file is imported into the ZCANPRO tool for test case writing.

[0011] Preferably, the test case writing includes sending, waiting and verification operations. The sending operation is to convert the battery parameters to be set into a calibration message in the CAN message format through a CAN analyzer through a DBC file and send it to the calibration port of the battery simulation system; after the battery simulation system sets the parameters, it sends a message to the communication port of the system under test based on the sending port, and the system under test feeds back a verification message according to its own internal logic; the waiting operation corresponds to the delay trigger condition in the logic to be tested; the verification operation is to verify the verification message fed back by the system under test, and judge the test result according to the verification result. Among them, the internal logic refers to the response logic of the BMS system (i.e., the system under test) itself, which is generally reflected in its strategy file or product specification.

[0012] Preferably, in terms of hardware, the host computer adopts a microcontroller supporting the CAN protocol, and the CAN analyzer adopts a CAN transceiver, and converts the TTL signal of the microcontroller into a CAN signal based on a CAN communication level conversion circuit.

[0013] Preferably, the CAN0 RX / TX port of the microcontroller MCU is connected to the CAN bus, the CAN transceiver chip adopts ISO7721QDRQ1 and TJA1042T / 3, CAN0 RX and CAN0TX are respectively connected to the OUTA and INB ports of ISO7721QDRQ1, the INA and OUTB ports of ISO7721QDRQ1 are respectively connected to the TXD and STB ports of TJA1042T / 3, and the CAN_H and CAN_L of TJA1042T / 3 are connected to the CAN network of the cluster control board through the output interfaces EXT_CAN0_H and EXT_CAN0_L after signal conditioning, ESD protection and terminal matching.

[0014] The present invention also discloses a test method for an automated test platform of a battery management system, which is based on the test platform and includes the following steps: S1, initializing a CAN interface; S2, setting a baud rate, wherein the baud rate of the sending port is consistent with that of the communication port, and the baud rate of the calibration port is consistent with that of the debugging port; S3, a host computer decodes and converts a calibration message for sending battery parameters into a DBC file, imports the DBC file into a ZCANPRO tool for writing, and then converts the DBC file into a CAN message format through a CAN analyzer and sends it to a calibration port of a battery simulation system, wherein the battery simulation system sets the battery parameters according to the received message, and sends the battery simulation information to the communication port of the system under test through the sending port; S4, the system under test judges according to its own internal logic and sequentially feeds back verification messages to the CAN analyzer and the host computer PC through the debugging port; S5, the host computer PC converts the received feedback message into a DBC format and performs verification, and judges the test result according to the verification result.

[0015] Beneficial Effects

[0016] (1) The automated test platform for the battery management system disclosed in the present invention is a solution for rapid automated testing of the battery management system, which meets the technical requirements of automation, speed, convenience, etc. The test cases adopt a modular design and can be expanded and quickly modified without using the underlying code;

[0017] (2) The automated test platform for the battery management system disclosed in the present invention has a small system size and simple power supply.

[0018] It can be powered by common power sources such as single or 12V. It is a portable automated test system that greatly improves the problems of cumbersome automated test systems and inconvenient mobility, and improves the application environment of automated testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a CAN communication level conversion circuit of some embodiments of the present invention;

[0020] Figure 2 It is a battery parameter sending function code of some embodiments of the present invention;

[0021] Figure 3 It is a battery parameter calibration function code of some embodiments of the present invention;

[0022] Figure 4 is a schematic diagram of a test platform for some embodiments of the present invention;

[0023] Figure 5 It is a test case editing interface of some embodiments of the present invention;

[0024] Figure 6 It is a test execution interface of some embodiments of the present invention. DETAILED DESCRIPTION

[0025] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0026] In the description of the present application, it should be understood that the terms "center", "upper", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside" and the like indicate positions or positional relationships based on the positions or positional relationships shown in the drawings, which are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present application. In addition, the terms "first" and "second" are only used for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the present application, unless otherwise specified, "multiple people" and "several" mean two or more.

[0027] In the description of this application, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0028] Example

[0029] The present application discloses an automated test platform for a battery management system. This embodiment will be described from three aspects: automated test platform, software design, and hardware design:

[0030] 1. Automated testing platform

[0031] like Figure 4 As shown, the automated test platform includes a host computer, a CAN analyzer, a system under test, and a battery information simulation system, wherein the system under test has a debugging port for feedback of system status and a communication port for intranet communication, and the battery information simulation system has a calibration port for calibrating battery parameter values ​​and a sending port for sending messages;

[0032] The debugging port of the system under test and the calibration port of the battery information simulation system are on a CAN bus and connected to the host computer through a CAN analyzer, and the sending port of the battery information simulation system is connected to the communication port of the system under test;

[0033] The host computer calibrates the battery parameters by sending calibration messages, and receives the verification messages fed back from the debug port of the device under test as test results for verification.

[0034] The data flow of each module on the platform is as follows: the host computer sends a calibration message to the calibration port, the battery information simulation system calibrates the battery parameters, and sends a message to the communication port of the system under test based on the sending port, the system under test judges and generates a feedback message, and sends it to the CAN analyzer based on the debugging port as a test result for verification.

[0035] The present invention also discloses a testing method for an automated testing platform, comprising:

[0036] S1, initialize the CAN interface; S2, set the baud rate, the baud rate of the sending port is consistent with that of the communication port, and the baud rate of the calibration port is consistent with that of the debugging port; S3, the host computer decodes and converts the calibration message of the battery parameters into a DBC file, imports the DBC file into the ZCANPRO tool for writing, and then converts the DBC file into a CAN message format through the CAN analyzer and sends it to the calibration port of the battery simulation system. The battery simulation system sets the battery parameters according to the received message, and sends the battery simulation information to the communication port of the system under test through the sending port; S4, the system under test judges according to its own internal logic and feeds back the verification message to the CAN analyzer and the host computer PC in sequence through the debugging port; S5, the host computer PC converts the received feedback message into DBC format and performs verification, and judges the test result according to the verification result.

[0037] 2. Software Design

[0038] The purpose of the software design and the functions to be achieved are to send battery-related parameter information (voltage / temperature / current) and calibrate these parameters.

[0039] It includes two parts: battery parameter sending function code and battery parameter calibration function code:

[0040] The battery parameter sending function code is as follows Figure 2 As shown,

[0041] The SendCellVolt_1 function is defined to send the battery cell voltage information, and a function named User_CanSend is called, passing in infoMsgS as a parameter, which is used to actually send the CAN message. Specifically,

[0042] S1 defines the empty parameter function SendCellVolt_1, which has no return value; declares the variable infoMsgS of the structure type, which contains the information to be sent;

[0043] S2, set the ID field of infoMsgS to 0x00001001UL and the data length to 8 bytes; set the content of the infoMsgS.Data array, each element is an 8-bit integer (uint8), and assign it to specific battery cell voltage information, specifically:

[0044] infoMsgS.Data[0] is set to the lowest 8 bits of g_CellVolltMin.

[0045] infoMsgS.Data[1] is set to the highest 8 bits of g_CellVolltMin,

[0046] infoMsgS.Data[2] is set to the lowest 8 bits of g_CellVolltMax,

[0047] infoMsgS.Data[3] is set to the highest 8 bits of g_CellVolltMax,

[0048] infoMsgS.Data[4] is set to g_CellVolltNorm divided by 3200, in mV.

[0049] infoMsgS.Data[5] is set to the high digit of g_CellVolltNorm divided by 3200.

[0050] infoMsgS.Data[6] is set to the result of g_CellVolltNorm divided by 3200, in mV, and infoMsgS.Data[7] is set to the result of g_CellVolltNorm divided by 3200 and taking the high digit.

[0051] The battery parameter calibration function code is as follows: Figure 3 As shown,

[0052] Get the cell temperature data from the CAN bus, decode and convert it so that other program modules can use this data correctly.

[0053] S1, check the ID of the received CAN frame, if it is 0x181808F3, start processing the frame data;

[0054] S2, read the 0th and 1st bytes, the 2nd and 3rd bytes, and the 4th and 5th bytes in the frame data respectively. These three parts represent the temperature data of three different monomers. These data exist in binary form and need to be converted to get the real temperature value;

[0055] S3, performs a conversion operation on the original data, mainly subtracting a fixed offset 0x8000, and then multiplying it by a coefficient 0.1 to obtain the actual temperature value. The calculated temperature value will be saved in the corresponding global variable for subsequent program module access.

[0056] 3.Battery simulation board hardware

[0057] For the automated testing solution of battery management system, currently the market mostly uses large battery simulation equipment as the hardware basis. In order to solve the problems of expensive battery simulation system and strict testing environment requirements caused by the mobile portability, this application proposes to adopt a single-chip microcomputer hardware solution with simple message receiving and sending functions. Even the original BMS main control board can be used as the battery information sending hardware device to meet the platform construction requirements.

[0058] The specific implementation plan is as follows:

[0059] The hardware design mainly includes a microcontroller and a CAN transceiver (the CAN analyzer is equivalent to a CAN transceiver, because the test operation interface is on the computer side, and a CAN transceiver is required to connect the computer and the test system). Among them, the microcontroller selects a microcontroller that supports the CAN protocol, such as the STM32 series, PIC series or Arduino (using the MCP2515 module); the CAN transceiver selects a transceiver such as MCP2551 or TJA0427 to convert the microcontroller's TTL signal into a CAN signal.

[0060] CAN communication level conversion circuit such as Figure 1 As shown, the CAN bus circuit is Figure 1 As shown in the figure, MCU CAN0 RX / TX is the CAN receiver (RX) and transmitter (TX) of the microcontroller unit (MCU). These two ports are connected to the CAN bus, allowing the microcontroller to communicate with other devices. The CAN transceiver chip uses ISO7721QDRQ1 and TJA1042T / 3. Among them, ISO7721QDRQ1 is an isolated CAN transceiver chip used to enhance the anti-interference ability of the CAN bus. ISO7721QDRQ1 provides electrical isolation protection to prevent electromagnetic interference from affecting the microcontroller or other sensitive components. TJA1042T / 3 is used to drive the CAN bus, which can increase the transmission distance and speed of the bus, while providing functions such as overvoltage protection. TVS diodes (transient suppression diodes) are used to protect circuits from surges. They can absorb instantaneous high-voltage pulses, thereby protecting the subsequent components from damage. Resistors and capacitors play a filtering and stabilizing role in the network. For example, R40 and C41 form a low-pass filter to reduce high-frequency noise. C46 and L6 form a notch filter to further reduce the noise level. GND_CAN0: Ground connection point, used to ensure good grounding performance of the entire circuit, which is especially important for high-speed digital signals. EXT CAN0 H / L: Connection point of the external CAN bus, where H represents the high level line and L represents the low level line. These two lines form a pair of differential signal lines for transmitting data.

[0061] The RXD and TXD pins of the CAN interface chip are connected to a dual-channel isolation chip (ISO7721QDRQ1) to interact with the main processor. Specifically, the OUTA and INB pins of the isolation chip ISO7721QDRQ1 are connected to the MCU_CAN0_RX and MCU_CAN0_TX pins of the main control chip. The INA and OUTB ports of ISO7721QDRQ1 are connected to the TXD and STB ports of TJA1042T / 3 respectively. The CAN_H and CAN_L of TJA1042T / 3 are connected to the external CAN network through the output interfaces EXT_CAN0_H and EXT_CAN0_L after signal conditioning (pull-up resistor R42 and pull-down resistor R43, used to maintain the state of CAN_H and CAN_L lines when there is no active node driving), ESD protection (TVS12, TVS8, TVS9 and TVS45 are used to protect the CAN bus from damage by electrostatic discharge (ESD) and surge voltage, and ESD protection devices SMBJ33CA, SMBJ12CA, to further improve the system's immunity) and terminal matching (terminal resistor R58, used to match the characteristic impedance of the CAN bus, reduce signal reflections, and improve signal integrity). Design the power supply circuit according to the operating voltage of the selected microcontroller and transceiver, usually 5V or 3.3V. Use DB9 or other suitable connectors to easily connect to the CAN bus.

[0062] The CAN communication level conversion circuit disclosed in this embodiment builds a reliable CAN bus interface, which can maintain stable communication quality in complex environments. By using a variety of protection measures and technical means, it is ensured that the system can operate normally under various conditions.

[0063] The hardware design disclosed in this embodiment has the function of sending and receiving CAN messages, and the built-in microcontroller can be used to control software programming and define the sent and received messages.

[0064] Example

[0065] This embodiment discloses a specific automated test case writing and execution scheme design.

[0066] The test case writing in this embodiment is based on the ZCANPRO tool. The ZCANPRO tool provides a basic template for automated test case writing, which can be used to quickly and efficiently write test cases. In order to make the test case writing more intuitive and convenient, it is necessary to decode the calibration message and the verification message before writing, that is, convert the message protocol into the DBC file format. Then, import the DBC file into the ZCANPRO tool, and you can start writing the test case.

[0067] (1) DBC file writing

[0068] DBC (Database Container) files are a standard format for describing messages, signals, and their properties in CAN networks. Through DBC files, the structure and meaning of each CAN message can be clearly defined, which facilitates subsequent test case writing and data analysis.

[0069] Use the DB++ tool to convert the message protocol into a DBC file. DB++ is a CAN database editing tool that can convert the message protocol into a DBC file format. The specific steps are as follows: open the DB++ tool, import the message protocol file, create messages and signals according to the definition in the message protocol file, and save the generated DBC file.

[0070] (2) Test case writing

[0071] The ZCANPRO tool provides an intuitive test case editing interface, such as Figure 5 As shown in the figure. In this interface, users can easily write and manage test cases.

[0072] Test case input conditions, including sending, waiting and verification:

[0073] Send: The battery parameters to be set are converted into CAN message format through the DBC file by the CAN analyzer, and then sent to the battery simulation system. After receiving these parameters, the battery simulation system will generate corresponding response messages according to the set parameters.

[0074] Wait: Wait operation is mainly used to deal with delayed trigger conditions in the logic to be tested. Delay is set to adapt to the protection and alarm time of the BMS strategy. There is a logic processing circuit with filter delay judgment function in the BMS logic to be tested, which can flexibly set the failure alarm indication signal delay time according to different transient conditions to ensure the accuracy of the test.

[0075] Verification: Verification is the process of verifying the feedback message of the system under test. According to the preset standards, check whether the feedback message meets the expectations. If the verification passes, the test result is successful; otherwise, the test result is failed.

[0076] Test cases are flexible and can be quickly modified and written in a modular way. The templates and editing interface provided by the ZCANPRO tool make it very convenient to modify test cases. Users can adjust the parameters and steps of test cases at any time as needed. At the same time, test cases can be written in modules, and each module is responsible for a specific function or test scenario. This modular writing method not only improves the maintainability of the code, but also facilitates reuse and expansion.

[0077] (3) Example process

[0078] Preparation stage: Use the DB++ tool to convert the message protocol into a DBC file, and import the generated DBC file into the ZCANPRO tool.

[0079] Write test cases: In the test case editing interface of the ZCANPRO tool, define the sending operation and set the battery parameters to be sent; add the waiting operation and set the appropriate waiting time; define the verification operation and set the expected feedback message format and content; finally, save the test case.

[0080] Test execution:

[0081] Run test cases and send messages through the CAN analyzer; monitor the response of the system under test; verify the feedback messages and record the test results.

[0082] The test can be executed step by step, which can greatly improve the test efficiency. It is flexible and convenient to select any test item or combine any test items for testing.

[0083] Report analysis: In this embodiment, Figure 6 As shown, the PASS item is marked with a green sign and the FAIL item is marked with a red sign. It is simple and clear, and each step of the test case can be traced back.

[0084] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art can still modify the technical solutions described in the aforementioned embodiments or replace some of the technical features therein by equivalents. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. An automated test platform for a battery management system, characterized in that: It includes a host computer, a CAN analyzer, a system under test and a battery information simulation system, wherein the system under test has a debugging port for feedback of system status and a communication port for intranet communication, and the battery information simulation system has a calibration port for calibrating battery parameter values ​​and a sending port for sending messages; The debugging port of the system under test and the calibration port of the battery information simulation system are on a CAN bus and connected to a host computer via a CAN analyzer. The sending port of the battery information simulation system is connected to the communication port of the system under test to send battery parameters. The host computer calibrates the battery parameters by sending calibration messages, and at the same time receives the verification message fed back from the debugging port of the device under test as the test result for verification.

2. The automated testing platform according to claim 1, characterized in that: The battery parameters are calibrated as follows: the minimum, maximum and other single cell temperatures are extracted from a CAN frame and converted and stored accordingly.

3. The automated testing platform according to claim 2, characterized in that: The specific steps for calibrating the battery parameters are as follows: check the ID of the received CAN frame, read the 0th and 1st bytes, the 2nd and 3rd bytes, and the 4th and 5th bytes in the frame data respectively. The three parts represent the temperature data of three different cells respectively; the data is in binary form, and the actual temperature value is obtained by subtracting a fixed offset and multiplying by a coefficient. The calculated temperature value is saved in the corresponding global variable for access by subsequent program modules.

4. The automated testing platform according to any one of claims 1 to 3, characterized in that: Sending battery parameters is as follows: construct a CAN frame containing battery cell voltage information and send it through the User_CanSend function.

5. The automated testing platform according to claim 4, characterized in that: Sending battery parameters is as follows: define the SendCellVolt_1 function to send battery cell voltage information, call the User_CanSend function, pass in infoMsgS as a parameter, and use it to actually send the CAN message function; set the ID field of infoMsgS to 0x00001001UL and the data length to 8 bytes; set the content of the infoMsgS.Data array, each element is an 8-bit integer, and assign it to specific battery cell voltage information, where the first and second bytes are set to the lowest 8 bits and highest 8 bits of g_CellVolltMin, the third and fourth bytes are set to the lowest 8 bits and highest 8 bits of g_CellVolltMax, and the fourth and sixth bytes are set to g_CellVolltNorm The result after dividing by 3200 is in mV. The fifth and seventh bytes are set to the high digit of g_CellVolltNorm divided by 3200.

6. The automated testing platform according to claim 1, characterized in that: Write test cases based on the ZCANPRO tool. First, decode the calibration message and the verification message, and then pass the message protocol to DB++ The tool will convert it into a DBC file, and then import the DBC file into the ZCANPRO tool for test case writing.

7. The automated testing platform according to claim 5, characterized in that: The test case writing includes sending, waiting and verification operations. The sending operation is to convert the battery parameters to be set into a calibration message in the CAN message format through a CAN analyzer through a DBC file and send it to the calibration port of the battery simulation system; after the battery simulation system sets the parameters, it sends a message to the communication port of the system under test based on the sending port, and the system under test feeds back the verification message according to its own internal logic; the waiting operation corresponds to the delay trigger condition in the logic to be tested; the verification operation is to verify the verification message fed back by the system under test, and judge the test result according to the verification result.

8. The automated testing platform according to claim 1, characterized in that: In terms of hardware, the host computer adopts a microcontroller supporting the CAN protocol, and the CAN analyzer adopts a CAN transceiver, which converts the TTL signal of the microcontroller into a CAN signal based on a CAN communication level conversion circuit.

9. The automated testing platform according to claim 8, characterized in that: The CAN0RX / TX port of the microcontroller MCU is connected to the CAN bus, the CAN transceiver chip uses ISO7721QDRQ1 and TJA1042T / 3, CAN0 RX and CAN0TX are respectively connected to the OUTA and INB ports of ISO7721QDRQ1, the INA and OUTB ports of ISO7721QDRQ1 are respectively connected to the TXD and STB ports of TJA1042T / 3, and the CAN_H and CAN_L of TJA1042T / 3 are connected to the CAN network of the cluster control board through the output interfaces EXT_CAN0_H and EXT_CAN0_L after signal conditioning, ESD protection and terminal matching.

10. A testing method for an automated testing platform for a battery management system according to any one of claims 1 to 9, characterized in that: The method comprises the following steps: S1, initializing the CAN interface; S2, setting the baud rate, wherein the baud rate of the sending port is consistent with that of the communication port, and the baud rate of the calibration port is consistent with that of the debugging port; S3, the upper computer decodes and converts the calibration message of the sent battery parameters into a DBC file, imports the DBC file into the ZCANPRO tool for writing, and then converts the DBC file into a CAN message format through a CAN analyzer and sends it to the calibration port of the battery simulation system, the battery simulation system sets the battery parameters according to the received message, and sends the battery simulation information to the communication port of the system under test through the sending port; S4, the system under test judges according to its own internal logic and feeds back the verification message to the CAN analyzer and the upper computer PC in sequence through the debugging port; S5, the upper computer PC converts the received feedback message into the DBC format and performs verification, and judges the test result according to the verification result.

Images