CN116166524A

CN116166524A - BMS HIL testing method, device and equipment

Info

Publication number: CN116166524A
Application number: CN202211303893.8A
Authority: CN
Inventors: 詹多强
Original assignee: SAIC Motor Corp Ltd
Current assignee: SAIC Motor Corp Ltd
Priority date: 2022-10-24
Filing date: 2022-10-24
Publication date: 2023-05-26

Abstract

The application discloses a BMS HIL test method, device and equipment, comprising: generating an initial interface document according to the attribute of the Controller Area Network (CAN) signal; generating a test case group according to the initial interface document, wherein the test case group comprises test cases of input signals in the CAN signals and test cases of output signals in the CAN signals; generating a test script according to the test case group; and running the test script through test software to test the BMS HIL. According to the BMS HIL automatic test method and device, automatic test of the BMS HIL is achieved through the script, so that test cases do not need to be manually written, the development period of the test cases is shortened, and the development efficiency is improved.

Description

BMS HIL testing method, device and equipment

Technical Field

The application relates to the technical field of testing, in particular to a BMS HIL testing method, device and equipment.

Background

Battery management system (Battery Management System, BMS) Hardware In the Loop (HIL) typically includes functions such as signal input processing, high-low voltage power-up, high voltage interlock detection, insulation monitoring, equalization control, thermal management, high voltage signal sampling, and fault diagnosis. In order to test the functions of the BMS, a user writes test cases, and the computer tests the BMS HIL by running the test cases.

At present, in the test case development process of the BMS HIL, repeated and mechanical case writing problems exist, so that the development efficiency is low.

Disclosure of Invention

The application provides a BMS HIL testing method, device and equipment, which can improve the development efficiency of test cases.

In a first aspect of the present application, a method for testing a battery management system hardware-in-the-loop BMS HIL is provided, including:

generating an initial interface document according to the attribute of the Controller Area Network (CAN) signal;

generating a test case group according to the initial interface document, wherein the test case group comprises test cases of input signals in the CAN signals and test cases of output signals in the CAN signals;

generating a test script according to the test case group;

and running the test script through test software to test the BMS HIL.

In some embodiments, the running the test script by test software includes:

the vehicle speed signal is sent to the BMS controller by an 8-bit Cyclic Redundancy Check (CRC) check rule.

In some embodiments, the generating the initial interface document according to the attribute of the CAN signal includes:

and generating an initial interface document according to the variable name, the identifier, the boundary value, the precision and the offset of the CAN signal.

In some embodiments, before the generating the test script according to the test case group, the method further includes:

packaging test cases corresponding to various fault types to obtain a model library;

and inserting the model library into the test script.

In some embodiments, the test cases corresponding to the multiple fault types include a fault injected test case and a fault overtime test case.

In some implementations, the generating the test script from the set of test cases includes:

and calling an API interface of INCA and an interface in Veristand to convert the test case group into a test script suitable for TAE.

In some embodiments, the running the test script by test software includes:

and stopping sending the message of the frame current sensor.

In some embodiments, before the generating the test case group according to the initial interface document, the method further includes:

and setting a separation point, tolerance and time delay corresponding to each CAN signal in the initial interface document.

In some embodiments, the test software is a TAE, and running the test script through the test software comprises:

and replacing the map file and the seq file in the TAE by using the test script.

In a second aspect, a testing apparatus for battery management system hardware-in-the-loop BMS HIL is provided, including:

the generation module is used for generating an initial interface document according to the attribute of the Controller Area Network (CAN) signal;

the generating module is further configured to generate a test case group according to the initial interface document, where the test case group includes a test case of an input signal in the CAN signal and a test case of an output signal in the CAN signal;

the generating module is further used for generating a test script according to the test case group;

and the running module is used for running the test script through test software so as to test the BMS HIL.

In some embodiments, the running module is configured to send the vehicle speed signal to the BMS controller through an 8-bit Cyclic Redundancy Check (CRC) check rule.

In some embodiments, the generating module is configured to generate the initial interface document according to a variable name, an identifier, a boundary value, an accuracy, and an offset of the CAN signal.

In some embodiments, the apparatus further comprises:

the packaging module is used for packaging the test cases corresponding to the multiple fault types to obtain a model library;

and the insertion module is used for inserting the model library into the test script.

In some embodiments, the generating module is configured to call an API interface of INCA and an interface in Veristand to convert the test case group into a test script suitable for TAE.

In some embodiments, the operation module is configured to stop sending a message from the frame current sensor.

In some embodiments, the apparatus further comprises:

and the setting module is used for setting the separation point, tolerance and time delay corresponding to each CAN signal in the initial interface document.

In some embodiments, the test software is a TAE, and the execution module is configured to replace a. Map file and a. Seq file in the tee with the test script.

In a third aspect, there is provided a computer device comprising: a processor, a memory;

the memory is used for storing computer readable instructions or computer programs;

the processor is configured to read the computer readable instructions or the computer program, so that the device implements the BMS HIL testing method according to the first aspect or any alternative implementation of the first aspect.

In a fourth aspect, a computer readable storage medium is provided, comprising instructions or a computer program, which when run on a computer, causes the computer to perform the method for testing BMS HIL according to the first aspect or any alternative embodiment of the first aspect.

From this, this application has following beneficial effect:

according to the BMS HIL automatic test method and device, automatic test of the BMS HIL is achieved through the script, so that test cases do not need to be manually written, the development period of the test cases is shortened, and the development efficiency is improved.

Drawings

Fig. 1 is an electrical schematic diagram of a BMS HIL test system according to an embodiment of the present application;

FIG. 2 is a test software interaction diagram provided in an embodiment of the present application;

FIG. 3 is a diagram of a Veristan configuration interface provided in an embodiment of the present application;

FIG. 4 is a diagram illustrating a HIL interface and model interface association interface according to an embodiment of the present application;

fig. 5 is a schematic view of an INCA engineering environment provided in an embodiment of the present application;

FIG. 6 is a TAE configuration interface diagram provided by an embodiment of the present application;

FIG. 7 is a schematic diagram of a TAE function test sequence provided in an embodiment of the present application;

FIG. 8 is a flow chart of project testing provided in an embodiment of the present application;

fig. 9 is a schematic diagram of a BMS HIL model architecture according to an embodiment of the present application;

fig. 10 is a schematic diagram of interaction between a model and a BMS according to an embodiment of the present application;

FIG. 11 is a schematic diagram of an interface model according to an embodiment of the present disclosure;

FIG. 12 is a schematic diagram of code for generating an interface model according to an embodiment of the present application;

FIG. 13 is a schematic diagram of an automatically generated partial interface model according to an embodiment of the present application;

fig. 14 is a flowchart of a BMS HIL testing method provided in an embodiment of the present application;

FIG. 15 is a flowchart for implementing automation of an interface test case according to an embodiment of the present application;

FIG. 16 is a flow chart of an automated generation interface test sequence provided by an embodiment of the present application;

FIG. 17 is a diagram of a Veristan UI test interface provided by an embodiment of the present application;

FIG. 18 is a schematic diagram of a fault injection board card protocol according to an embodiment of the present application;

FIG. 19 is a schematic diagram of a partial BMS model library provided in an embodiment of the present application;

FIG. 20 is a schematic diagram of a portion of a script developed within a TAE provided by an embodiment of the present application;

FIG. 21 is a functional test case interface diagram provided by an embodiment of the present application;

FIG. 22 is a flowchart of a functional test case development provided by an embodiment of the present application;

FIG. 23 is a flow chart of a full function requirement to automated test implementation provided by an embodiment of the present application;

FIG. 24 is a schematic diagram of a test case design according to an embodiment of the present application;

fig. 25 is a schematic diagram of a script for implementing a speed output of the ESC23Ch according to an embodiment of the present application;

FIG. 26 is a schematic diagram of a power-on operation of a vehicle according to an embodiment of the present application;

FIG. 27 is a schematic diagram of a post-manufacturing CABERR fault reset provided by an embodiment of the present application;

fig. 28 is a schematic structural diagram of a BMS HIL testing device according to an embodiment of the present application;

fig. 29 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

In order to make the above objects, features and advantages of the present application more comprehensible, embodiments accompanied with figures and detailed description are described in further detail below.

The architecture of the BMS HIL test system provided in the embodiment of the present application is described below.

The BMS HIL test system provided by the embodiment of the application comprises a master control bench, a slave control bench and a BMS controller. The main control rack comprises a low-voltage programmable power supply, a high-voltage programmable power supply, a switch box, a fault injection box, an NI board card and a conditioning board card; the slave control rack comprises a single voltage simulation board card and a temperature simulation board card; the BMS controller includes a battery management controller (Battery Management Controller, BMC, BMS control part) and a cell management controller (Cell Management Controller, CMC). The CMC is used for collecting electric signal data of the slave console, the BMC interacts with a hard wire interface of the master console, and simultaneously, analog signals from the CMC and the console are processed in a daisy chain connection mode. The electrical principle of the BMS HIL test system is shown in fig. 1.

The BMS HIL test environment is constructed by various test software. For example, the BMS HIL test environment is implemented by the interaction of Veristand, TAE, INCA and Matlab. FIG. 2 shows an interactive schematic diagram of test software, and as shown in FIG. 2, a dll file is obtained through Matlab modeling and compiling, and Veristan is imported. And configuring a Veristand path through TAE, mapping the engineering environment, and calling an interface of the HL system downwards. And configuring an INCA engineering path through TAE, mapping the engineering environment, and calling the internal variables of the ECU.

Veristand is key engineering configuration software in an NI test system, and CAN realize CAN signal configuration according to ID (identity) by loading a project CAN Matrix file; the board card resource can be configured, mainly the board card is inserted into the NI industrial personal computer; and the downloading of a model dynamic link library (dll) file into the industrial personal computer is also supported. Fig. 3 is a Veristand configuration interface.

The BMS HIL needs to build various controllers, dynamic models and the like, simulates the whole vehicle simulation environment, and is convenient for testing the BMS controllers of the controlled objects. And configuring a code generation file environment suitable for the NI Veristand by means of Simulink modeling in Matlab, compiling to obtain dll files, loading the dll files into the VeriStand, and finally downloading the dll files into an NI industrial personal computer to construct a whole vehicle simulation environment.

After the model is loaded, as shown in fig. 4, each signal in the model is associated with each ID in the hardware board card required in the HIL and the CAN communication board card.

For INCA observation calibration software, as shown in FIG. 5, A2L and Hex files of BMS items are added first, then Workspace and Experiment are added, INCA hardware is connected, and initialization is achieved, namely the configuration of the part is completed.

TAE is test execution software developed based on Veristand. The replication of the Veistank engineering configuration can be realized, so that the Veistank environment variable can be called in the TAE environment; the experimental interface variables of INCA can also be called on line, so that the acquisition of the required test variables is realized.

Fig. 6 shows a tee configuration method: and importing the xml file in the ECU to complete the configuration of XCP. And after XCP configuration is completed, the quantity to be observed or calibrated in the test is selected one by one, and the quantity to be observed or calibrated in the test can be added by clicking Add Channel(s).

TAE is test execution software for constructing an automatic test sequence, and functions of the TAE comprise fault injection, calibration observation, diagnosis and the like, script development is supported, a model library is constructed, and the automation efficiency is further improved. By modularized instructions, the following test sequence shown in fig. 7 is developed, and the BMS HIL test can be performed.

In the embodiment of the application, the automatic testing program is provided, so that the automatic testing degree of the BMS HIL is improved. The specific lifting links are as shown in the model simulation environment set up in the figure 8, the test cases of programming interfaces, functions and the like, and the automatic script is developed from three aspects of interface model, test case programming and automatic test case programming.

When the whole vehicle environment is built, a BMS HIL embedded Model (downloaded to an industrial personal computer) can be regarded as two parts as shown in FIG. 9: part is a vehicle function model and part is an interface model. Because the whole vehicle parameters and the non-controlled object information are locked in the early stage of the project, the whole vehicle function model is not greatly changed, and the interface model needs to be frequently built because the controller area network (Controller Area Network) CAN Matrix defined by the project architecture is different, therefore, if the part of interface model is automatically generated, the environment building time CAN be greatly shortened.

As shown in fig. 10, the interface model connects the output signal of the functional model with NI out, the NI out is mapped with the BMS HIL rack board card, and the rack is connected with the BMS, so as to achieve the purpose of controlling the BMS by the model instruction; the BMS output instructions can also be fed back to the functional model through the input of the interface model.

Taking the interface model control BMS as an example, a model similar to that of fig. 11 needs to be built. Each signal requires the construction of a similar model, which is repeated and mechanical in part, and which can be generated in batch by an automated procedure.

The interface model is divided into model constant, switch and NI out control, the positions of each module are determined, the signal names in CAN Matrix are read and assigned to the relevant modules, and finally, a single interface model is obtained by connecting wires, and then batch generation is realized by means of circulation.

And reading the related signal names, and running the script to realize batch generation models, wherein the realization effect is shown in fig. 13.

The following illustrates an automated process of interface test cases provided in an embodiment of the present application.

Taking interface test as an example, each time a project is changed, input and output signals are changed, the interface test needs to be retested, and in order to ensure the test integrity, a total regression test may be needed. If the related automation program is developed, the test case is quickly generated and converted into a test sequence suitable for TAE, and then the regression test and project version management of the interface can be quickly realized.

Fig. 14 is a flowchart of a BMS HIL testing method according to an embodiment of the present application. As shown in fig. 14, the test flow includes:

s141, the computer equipment reads the attribute of each CAN signal in the CAN matrix (CAN matrix). And generating an initial interface document according to the attribute of each CAN signal.

The properties of the CAN signal include, but are not limited to, variable name, ID, boundary value, accuracy, offset, etc. By analyzing the attributes of the CAN signals, interface models CAN be generated in batches.

S142, the computer equipment sets a separation point, tolerance and delay corresponding to each CAN signal in the initial interface document, classifies the input signals and the output signals of the CAN signals, and obtains a Test Case Group (TCG)

S143, the computer equipment generates a test script according to the related information of the signals in the test case group.

S144, the computer equipment generates complete test cases of the input end and the output end, and converts the test cases into scripts which can be used for TAE operation.

And S145, the computer device runs the test script through the test software to test the BMS HIL.

The test software is, for example, a TAE.

According to the method provided by the embodiment, the automatic test of the BMS HIL is realized through the script, so that the test case does not need to be manually written, the development period of the test case is shortened, and the development efficiency is improved.

In some embodiments, running the test script through the test software includes:

and sending a vehicle speed signal to the BMS controller through the CRC8 check rule. Through CRC8 check, operations such as vehicle speed, battery heater, collision, relay closing request and the like can be simulated to replace a real controller.

In some embodiments, the method further comprises: packaging test cases corresponding to various fault types to obtain a model library; the model library is inserted into the test script.

By building the model library, a specific library can be built for different projects, a conventional model library can be built for general functions, and unified use rules are followed, so that the development difficulty of test cases is reduced, and errors caused by manual development cases are reduced. The function classification and the modularization processing are adopted, so that the function cutting in the project test process is facilitated, and the updating difficulty of the function test case in the project switching process is improved.

In some embodiments, the test cases corresponding to the plurality of fault types include a fault injected test case and a fault overtime test case. And the automatic fault injection test is realized through the script, so that the risk of human contact with high voltage is reduced, and the damage to the controller is reduced.

In some implementations, generating the test script from the test case set includes:

and calling an API interface of INCA and an interface in Veristand to convert the test case group into a test script suitable for TAE. Through the mode, the script suitable for TAE can be generated rapidly, and testing and version management are convenient.

and stopping sending the message of the frame current sensor.

In some implementations, before generating the test case set from the initial interface document, the method further includes:

In some embodiments, the test software is a TAE, and running the test script through the test software includes:

the test script is used to replace the.map file and the.seq file in the TAE.

The map file is a board card with controllable TAE and veristand engineering, and the visual quantity and the calibration quantity of the TAE and INCA experimental interface are mapped.

The seq file is a sequence, i.e. a file containing a test sequence. The map file and the seq file are standard files for TAE implementation automation.

The replaced file contains the relevant board interfaces in veristand and the observed quantity in INCA. By modifying the output parameters of the board card, the change condition can be checked through observational quantity, or the standard quantity can be modified to check whether the input content of the board card is matched with the modified value

The test script is written by VBA, and mainly reads an excel file through macro realization in the script and generates a test case in a corresponding format. The test case automation generation step is shown in fig. 15.

Generating an initial interface document: the CAN Matrix is configured in the program, and the macro at the 1 part is double-clicked, so that an initial interface document CAN be generated, and the input signal and the output signal are marked by different numbers respectively, thereby facilitating the subsequent classification processing.

Generating TCG: and configuring the initial interface document into a path of the program, clicking the macro at 2 points to generate a TCG document, and modifying the separation point, tolerance and test delay of the document.

Generating test scripts of the component categories: and configuring a TCG document path in the program, configuring a related model path, clicking a macro at 3 places, and generating test cases for signal input and signal output.

Generating test sequences suitable for TAE: the test cases of the input signals or the output signals are loaded into the program, and the test cases are converted into an automatic test sequence which can be identified by the TAE by simulating the TAE to call the api interface function of the INCA and the model interface in the Veristand. As shown in fig. 16.

Thus, by the automatic test program, the interface test can rapidly realize regression test and version management work as long as the related excel document is reserved.

The following describes the process of automated test case development.

For the process of automatizing the interface use case, firstly, a blank TAE project is newly created, the project environment is configured according to the operation described in the description of the TAE, the interface test script generated in fig. 14 is replaced under the project path designated folder, the map file and the seq file are replaced, and the TAE environment is updated, so that the interface test script can be run, thereby realizing the automatization test.

Because the Testcase and mapping files read by the TAE are at two addresses and are independently called, the testing environment is not changed, so that the map and seq files in the addresses are updated, and the automatic test can be realized.

Aiming at the process of functional test automation, veristand realizes the control of the lower computer by the upper computer of the HIL system by setting the mapping of the model path and the HIL board card. The control in Veristand through the interface shown in fig. 17 can simulate related variables, control input signals and observe feedback of the BMS. The test case simulates the change of the related control, and the automation of the functional test is realized.

TAE supports the development of functional test cases, and the development of the test cases can be intuitively and rapidly carried out through a graphical module instruction. However, aiming at the positive and negative verification of the test case, the condition verification and the complex working condition test, the problem that repeated operation and instantaneous operation which cannot be realized by module operation are inevitably encountered in the case development process. The following model libraries and specific scripts are thus developed, contributing to further improvement of automation capabilities.

For the process of building a model library, as shown in fig. 18, the fault injection test needs to select a specific channel of a specific fault injection board card, configure a required fault type and execute a fault injection action; and then the fault injection action is exited, and related faults are cleared. According to protocol operation, fault injection test is complicated, fault injection actions are packaged into a library, and development difficulty of the fault injection test is greatly reduced.

And when BMS items are switched, different configurations and differentiated test scenarios of the same function are often encountered. The function modules commonly used in BMS function test are packaged into the library, so that the configuration process of similar functions in the function test case building process can be simplified, and the error probability can be reduced. If the model library is in error, the use cases referring to the library can be corrected after synchronous updating by changing the content of the library. As shown in fig. 19.

Taking writing data as an example, determining a channel, judging through a selection statement and writing the data in a process of developing the modularized test script. The complex test environment is realized by a script, and the package similar to a model library can be realized, and the script developed in the TAE is shown in figure 20. The channel refers to a hardware interface channel of the HIL, such as a channel of a digital board card. The channel is selected so that the written data can be controlled to be of a digital type.

Aiming at the process of developing the functional test cases, iterative work of case development and project functional test can be rapidly realized by loading a model library and an embedded script; meanwhile, the functional test cases are supported in one test sequence, batch operation of the test sequences is realized, and the preset and repeated test work can be carried out at night without human intervention, so that the test depth and coverage are improved to a greater extent within a limited time, and the test period is shortened. The actual effect is shown in fig. 21.

For the functional test development flow, as shown in fig. 22, a functional test case development flow chart is shown.

The flow of the automated test development example is shown in fig. 23, and fig. 23 shows the flow from the whole vehicle function requirement to the automated test implementation.

The above-described embodiments are illustrated below in conjunction with a specific example.

In the EV51Q2, since the CAB500 sensor is unstable during the power-on process, a fault code is prone to be generated by mistake, so that the CAB err fault is shielded at the initial time of power-on, and the detection is continuously received after the CAB500 is stable. Thus, if the CAB500Err fault is received after the BMS passes the self-test, the CABACUNce is set for 800ms

The test case comprises common test scenes such as BMS low-voltage power-on, high-voltage power-on and pre-charging processes, and the like, and when the trigger of the CAB500 signal in 800ms is considered, the communication fault of the CAB500 can be simulated by stopping sending a message of one frame of CAB500 and normally sending the rest time, the current sensor is not required to be considered to be disconnected, and the reset time is far longer than 800ms of delay reaction. For testing, for example, as shown in FIG. 24,

According to the design analysis of the functional test case in fig. 23, two functions of driving working conditions and simulating and sending a frame of CABErr fault are required to be realized on the BMS HIL. The two functions are disassembled.

The driving working condition is a series of operations such as pressing a key, stepping on a brake, applying high pressure, releasing the brake, stepping on an accelerator and the like by a driver in the BMS HIL simulation whole vehicle environment. The output vehicle speed is an important index in the project development function safety, and the CRC8 check rule needs to be met, so that the BMS HIL is required to simulate the vehicle body stability controller to send a vehicle speed signal to calculate and realize the driving working condition through the CRC8 check rule. As shown in fig. 25: the script realizes the vehicle speed output of the vehicle body stability controller message 23 Ch.

The complete driving test case is shown in fig. 26, and the BMS displays the high voltage relay closed by simulating the operation of the driver.

Manufacturing a frame of CABErr fault at 800ms normally achieves CABErr, i.e., a current sensor fault, requiring the current sensor connector to be unplugged. However, this scenario involves a high pressure environment such as a traveling crane where manual injection of faults is not desirable and it is not necessarily possible to reset the connector after 800ms manufacturing faults, but BMS HIL can solve this problem through automated testing. The BMS acquires the current through the signal transmission of the analog current sensor, and if the current sensor message can be stopped, the CABACRR can be realized, the message can be sent again, and the fault can be cleared (the fault is a low-level fault, cleared after reset and not locked). As shown in fig. 27. And combining the two test scenes to meet the functional test requirement. Because the scene requirements are consistent, the scenes are packaged into a library, and the development efficiency of the functional test cases can be improved.

Summarizing, through the method, a complete tool chain of BMS HIL automatic test is opened, and the test case development period is shortened.

Further, the functions are modularized, so that project function grading and decoupling and splitting work are facilitated.

Further, a model library and scripts for developing sub functions are built, so that the function test efficiency is further improved, the use case development difficulty is reduced, and errors caused by manual use case development are reduced.

Furthermore, the fault injection test is automated, and the risk that high voltage needs to be manually contacted due to the fault injection test is avoided. In addition, the classification management of the test cases can be carried out, so that the relevant test case recurrence defects can be found out rapidly when the test defects are positioned.

Further, CRC8 checking may be performed to realize an analog signal output to the BMS controller.

Fig. 28 is a schematic structural diagram of a BMS HIL testing device 800 according to an embodiment of the present application, including:

a generating module 801, configured to generate an initial interface document according to an attribute of a controller area network CAN signal;

the generating module 801 is further configured to generate a test case set according to the initial interface document, where the test case set includes a test case of an input signal in the CAN signal and a test case of an output signal in the CAN signal;

the generating module 801 is further configured to generate a test script according to the test case set;

and an operation module 802 for operating the test script through the test software to test the BMS HIL.

In some embodiments, a module 802 is executed to send a vehicle speed signal to the BMS controller via an 8-bit Cyclic Redundancy Check (CRC) check rule.

In some embodiments, the generating module 801 is configured to generate an initial interface document according to a variable name, an identifier, a boundary value, an accuracy, and an offset of the CAN signal.

In some embodiments, the apparatus 800 further comprises:

and the inserting module is used for inserting the model library into the test script.

In some embodiments, a generating module 801 is configured to call an API interface of INCA and an interface within Veristand to convert the test case group into a test script suitable for use in TAEs.

In some embodiments, the module 802 is configured to stop sending a message from the frame current sensor.

In some embodiments, the apparatus 800 further comprises:

the setting module is used for setting the separation point, tolerance and time delay corresponding to each CAN signal in the initial interface document.

In some implementations, the test software is a TAE, and the module 802 is operable to replace the.map file and the.seq file in the TAE with a test script.

Fig. 29 is a schematic structural diagram of a computer device 600 provided in an embodiment of the present application, where the computer device 600 includes a processor 601 and a memory 602, where the memory 602 stores computer program instructions, and the processor 601 implements the steps in the method shown in the embodiment of fig. 14 when executing the computer program instructions.

In some embodiments, a computer readable storage medium is also provided, comprising instructions or a computer program, which when run on a computer, causes the computer to perform the method of testing the BMS HIL described above.

It should be noted that, in the present description, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different manner from other embodiments, and identical and similar parts between the embodiments are all enough to refer to each other. For the system or device disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and the relevant points refer to the description of the method section.

It should be understood that in this application, "at least one" means one or more, and "a plurality" means two or more. "and/or" for describing the association relationship of the association object, the representation may have three relationships, for example, "a and/or B" may represent: only a, only B and both a and B are present, wherein a, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b or c may represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b, c may be single or plural.

It is further noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software modules may be disposed in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for testing hardware-in-the-loop BMS HIL of a battery management system, comprising:

generating a test script according to the test case group;

and running the test script through test software to test the BMS HIL.

2. The method of claim 1, wherein the running the test script by test software comprises:

and sending a vehicle speed signal to the BMS controller through the CRC8 check rule.

3. The method of claim 1, wherein generating the initial interface document from the properties of the CAN signal comprises:

4. The method of claim 1, wherein prior to generating the test script from the set of test cases, the method further comprises:

and inserting the model library into the test script.

5. The method of claim 4, wherein the test cases corresponding to the plurality of fault types include a fault injected test case and a fault timeout test case.

6. The method of claim 1, wherein the generating a test script from the set of test cases comprises:

7. The method of claim 1, wherein the running the test script by test software comprises:

and stopping sending the message of the frame current sensor.

8. The method of claim 1, wherein prior to generating the test case set from the initial interface document, the method further comprises:

9. The method of claim 1, wherein the test software is a TAE, and wherein running the test script through the test software comprises:

10. A test apparatus for a battery management system hardware-in-the-loop BMS HIL, comprising:

11. A computer device, comprising: a processor, a memory;

the processor for reading the computer readable instructions or the computer program to cause the device to implement the test method of BMS HIL according to any of claims 1-9.

12. A computer readable storage medium comprising instructions or a computer program which, when run on a computer, causes the computer to perform the method of testing the BMS HIL of any of the preceding claims 1-9.