Bms firmware logic test method, device, equipment and medium

Abstract

This application relates to the field of BMS firmware testing technology, and discloses a BMS firmware logic testing method, apparatus, device, and medium. The method includes: acquiring character test cases composed of character data in natural language form; performing instruction conversion processing on the character test cases to obtain a parameter update instruction sequence; sending the parameter update instruction sequence to the BMS firmware under test, and obtaining firmware response information after the BMS firmware under test updates its parameters based on the parameter update instruction sequence; and performing a logical evaluation on the BMS firmware under test based on the firmware response information to generate a logical test result for the BMS firmware under test. The embodiments of this application can reduce the operational difficulty of BMS firmware logic testing and improve testing efficiency.

Description

Technical Field

[0001] This application relates to the field of BMS firmware testing technology, and in particular to a BMS firmware logic testing method, apparatus, device and medium. Background Technology

[0002] As the core control unit of new energy batteries, the reliability of the firmware logic of the battery management system directly determines the safety, stability and range of battery use.

[0003] However, in related technologies, BMS firmware logic testing relies on real sensors, battery packs, or dedicated hardware-in-the-loop devices, making it difficult to quickly simulate extreme operating conditions and limiting the test scenarios that can be covered. Furthermore, adjusting the operating parameters of the BMS firmware requires rewriting the firmware code or CAN commands, which is cumbersome, inefficient, and makes it difficult to quickly iterate test cases to adapt to the testing needs of different BMS firmware models. Summary of the Invention

[0004] The purpose of this application is to provide a BMS firmware logic testing method, apparatus, device, and medium, which can reduce the difficulty of operation and improve the testing efficiency when performing BMS firmware logic testing.

[0005] This application provides a BMS firmware logic testing method, including: Obtain character test cases; the character test cases consist of character data in natural language form; The character test cases are processed by instruction conversion to obtain a parameter update instruction sequence; The parameter update instruction sequence is sent to the BMS firmware under test, and the firmware response information after the BMS firmware under test updates the parameters based on the parameter update instruction sequence is obtained. Based on the firmware response information, a logical evaluation is performed on the BMS firmware under test to generate the logical test results of the BMS firmware under test.

[0006] In some embodiments, prior to obtaining the character test case, the method further includes: In response to a received test request, the corresponding test case template is displayed; In response to the editing operation on the test case template, corresponding character data is inserted into the test case template to obtain character test data; The character test data is encapsulated to obtain the character test cases.

[0007] In some embodiments, the instruction conversion processing of the character test cases includes: The character test cases are parsed to identify the corresponding character data; Based on the character data, construct multiple sets of character instruction data; Based on a preset character-instruction mapping relationship, the character instruction data is mapped to obtain a parameter update instruction sequence consisting of a corresponding number of parameter update instructions.

[0008] In some embodiments, the character data includes firmware identifier characters, parameter identifier characters, parameter range identifier characters, and parameter change rate identifier characters. The step of constructing multiple sets of character instruction data based on the character data includes: Based on the parameter change rate identifier character, generate a corresponding number of time identifier characters; Based on the parameter range identifier character and the parameter change rate identifier character, a corresponding number of instantaneous parameter identifier characters are generated; the instantaneous parameter identifier characters are linearly distributed within the parameter range represented by the parameter range identifier character based on the parameter change rate represented by the parameter change rate identifier character. Based on the firmware identifier character, the parameter identifier character, the time identifier character, and the instantaneous parameter identifier character, multiple sets of character instruction data are constructed.

[0009] In some embodiments, sending the parameter update instruction sequence to the BMS firmware under test includes: Send a test request to the BMS firmware under test, so that the BMS firmware under test blocks the sensor detection information and changes the CAN permission to a readable and writable state. After sending the test request, the system communicates with the BMS firmware under test via the CAN bus interface, configures communication parameters that are compatible with the BMS firmware under test, and sends parameter update instructions from the parameter update instruction sequence to the BMS firmware under test according to a preset time step.

[0010] In some embodiments, the logical evaluation of the BMS firmware under test based on the firmware response information includes: Determine whether the firmware response information meets the preset firmware response conditions; If the conditions are met, a logic test result is generated indicating that the firmware logic of the BMS under test is normal. If it does not meet the requirements, generate a logic test result that characterizes the logical anomaly of the BMS firmware under test.

[0011] In some embodiments, the BMS firmware logic testing method further includes: Store the character test cases and the corresponding parameter update instruction sequence; In response to a received test request, display the currently saved character test cases; In response to the selection operation for the currently saved character test case, the parameter update instruction sequence corresponding to the currently saved character test case is invoked.

[0012] This application embodiment also provides a BMS firmware logic testing device, including: The first module is used to obtain character test cases; the character test cases consist of character data in natural language form. The second module is used to perform instruction conversion processing on the character test cases to obtain a parameter update instruction sequence. The third module is used to send the parameter update instruction sequence to the BMS firmware under test and obtain the firmware response information after the BMS firmware under test updates the parameters based on the parameter update instruction sequence. The fourth module is used to perform logical evaluation on the BMS firmware under test based on the firmware response information, so as to generate logical test results for the BMS firmware under test.

[0013] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described BMS firmware logic testing method.

[0014] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described BMS firmware logic testing method.

[0015] The beneficial effects of this application are as follows: By converting character test cases composed of character data in natural language form into instructions, and then using the converted parameters to update the instruction sequence of the BMS firmware under test for firmware logic testing, the professional skills required of testers are greatly reduced. This allows non-professional programmers to easily create and execute tests, thereby reducing the professional requirements and manpower costs of the testing team. Compared with the cumbersome operation of rewriting firmware code or CAN instructions when adjusting operating parameters, this application allows users to directly modify natural language descriptions and automatically complete instruction conversion, improving the iteration efficiency and flexibility of test cases and better adapting to the testing needs of different BMS firmware models. Attached Figure Description

[0016] Figure 1 This is a flowchart of the BMS firmware logic testing method provided in the embodiments of this application.

[0017] Figure 2 This is a flowchart of the method provided in this application embodiment for obtaining character test cases before obtaining them.

[0018] Figure 3This is a flowchart of a method for performing instruction conversion processing on character test cases provided in an embodiment of this application.

[0019] Figure 4 This is a flowchart of a method for performing instruction conversion processing on character test cases provided in an embodiment of this application.

[0020] Figure 5 This is a schematic diagram of the structure of the BMS firmware logic testing device provided in the embodiments of this application.

[0021] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0023] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and drawings are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0025] In battery management system firmware testing, the construction of the test environment relies on real sensors, battery packs, or dedicated hardware-in-the-loop devices, making it difficult to quickly simulate extreme operating conditions. Simultaneously, test operations require personnel to possess knowledge of firmware programming or controller area network (CLAN) communication protocols. Furthermore, adjusting test case parameters necessitates modifying firmware code or CLAN commands, resulting in low testing efficiency and limited scenario coverage. The dynamic characteristics of operating parameters cannot be flexibly reproduced; for example, the simulation of voltage surges or temperature gradient changes is limited by the physical constraints of the hardware. Moreover, the specialized requirements of the testing team lead to strained human resource allocation, impacting the controllability of the testing cycle. For example, when verifying the response of a battery management system to overcharge protection logic, it is necessary to simulate an extreme scenario where the cell voltage jumps instantaneously from 4.0 volts to 4.5 volts. In traditional methods, testers must recompile the firmware code to inject the simulated voltage value or manually parse the controller area network protocol frame format to construct the instruction sequence. This process involves modifying the underlying firmware logic and accurately mastering the protocol details, which significantly increases the time required for each parameter adjustment. At the same time, the differences in communication parameters between different battery management system models require repeated configuration of hardware-in-the-loop devices, making it impossible to quickly adapt to the iterative requirements of voltage change rate or range, thereby reducing the reusability of test cases.

[0026] If the above problems are not addressed, the testing process will struggle to cover critical safety conditions, potentially leading to firmware logic defects going undetected. Furthermore, the lack of extreme condition simulation creates blind spots in the verification of protection mechanisms such as over-temperature or over-discharge. Additionally, excessively high testing thresholds will limit the expansion of the testing team and impact the progress of firmware iteration. Consequently, the safety risks of the battery system will increase due to insufficient testing completeness, which is detrimental to ensuring product reliability.

[0027] Based on this, embodiments of this application provide a BMS firmware logic testing method, apparatus, device, and medium. By converting character test cases composed of character data in natural language form into instructions, and then using the converted parameters to update the instruction sequence to perform firmware logic testing on the BMS firmware under test, efficient and flexible BMS firmware logic testing is achieved, reducing operational difficulty and improving testing efficiency.

[0028] See Figure 1 In one embodiment, a BMS firmware logic testing method is provided, wherein the execution subject of the method is a test terminal, including but not limited to steps S101 to S104.

[0029] Step S101: Obtain character test cases.

[0030] Character test cases consist of character data in natural language form. In essence, a character test case is a set of test scripts or instructions written in human-readable natural language. This test case does not directly contain machine-executable binary code or specific protocol instructions; instead, it uses descriptive text to express the test scenario, expected parameter changes, and desired BMS behavior.

[0031] Natural language character data refers to the basic information units that constitute character test cases. This data typically includes textual descriptions of battery parameters (such as voltage, current, and temperature), time series, and trends of change, and its format and content are designed to facilitate understanding and writing by testers.

[0032] Character test cases can be obtained by testers manually entering a series of descriptive character data using a text editor, such as "Cell1_Voltage: 2000~3000, 100, 100", indicating that the voltage of cell 1 linearly increases from 2000mV to 3000mV, with a total of 100+1 values ​​sent, each sent at 100ms intervals. This character data constitutes character test cases, which are easy for humans to understand and write, requiring no in-depth understanding of underlying communication protocols or programming languages. As an optional implementation, testers can import existing test scenario descriptions from predefined text files. These files may contain descriptions of parameter changes under different operating conditions, such as "Cell2_Voltage: 2000~3000, 100, 100".

[0033] Step S102: Perform instruction conversion processing on the character test cases to obtain the parameter update instruction sequence.

[0034] Instruction conversion processing refers to the process of converting character test cases in natural language form into machine instruction sequences that can be recognized and executed by the BMS firmware. This process involves parsing character data, semantic understanding, and generating corresponding low-level communication instructions according to preset rules.

[0035] A parameter update instruction sequence refers to a series of ordered instructions generated after instruction conversion processing to simulate changes in firmware parameters. These instructions typically contain specific parameter values, update frequency, target address, and other information, and can be directly sent to the BMS firmware via the communication interface to simulate sensor input.

[0036] The purpose of instruction conversion processing for character test cases is to transform them into a sequence of parameter update instructions that the BMS firmware can understand and execute. Specifically, this conversion can be performed using keyword matching. For example, the test terminal can recognize keywords such as "Cell1," "Voltage," and "2000~3000," and combine this with numerical information and character positions to generate a series of parameter update instructions simulating voltage changes. As another example, for a description such as "simulating battery temperature rising from 25 degrees Celsius to 60 degrees Celsius at a rate of 1 degree per second," the test terminal can parse it into a series of instructions that update temperature parameters at different times, each containing a specific temperature value. These parameter update instructions are organized into a parameter update instruction sequence, awaiting transmission to the BMS firmware under test.

[0037] Step S103: Send the parameter update command sequence to the BMS firmware under test, and obtain the firmware response information after the BMS firmware under test updates the parameters based on the parameter update command sequence.

[0038] The BMS firmware under test refers to the program code inside the battery management system that is undergoing logic testing. This firmware is responsible for functions such as monitoring battery status, performing equalization control, fault diagnosis, and protection. Its logical behavior is the object of evaluation in this test method.

[0039] Firmware response information refers to the internal state changes, output signals, or log records generated by the firmware under test (BMS) after receiving and processing a sequence of parameter update instructions. This information reflects the firmware's processing results of analog inputs and forms the basis for logic evaluation.

[0040] The parameter update command sequence is sent to the BMS firmware under test (DUT). This can be done by sending the parameter update commands one by one through a simple serial communication interface (such as UART) or a CAN bus interface. Upon receiving the parameter update commands, the DUT firmware updates its internal parameter status and may generate corresponding output signals or internal logs. While sending the parameter update commands, the test terminal continuously monitors the output port of the DUT firmware or reads its internal registers to obtain the firmware response information after the DUT updates its parameters based on the parameter update command sequence. This response information may include BMS protection actions, fault indications, equalization status changes, or real-time parameter readings.

[0041] Step S104: Based on the firmware response information, perform a logical evaluation on the BMS firmware under test to generate logical test results for the BMS firmware under test.

[0042] Logical evaluation refers to the process of determining whether the behavior of the firmware under test (BMS) conforms to expected logical rules and security standards based on the firmware response information. This evaluation aims to identify logical errors, anomalous behavior, or potential defects in the firmware.

[0043] Logic test results refer to the final output of the logic evaluation process, used to characterize whether the logic of the BMS firmware under test is normal or abnormal. These results can be presented in the form of reports, status indicators, or error codes, providing a basis for firmware development and optimization.

[0044] Logical evaluation of the BMS firmware under test is performed based on firmware response information. The aim is to determine whether the firmware's logical behavior meets expectations based on its actual response. For example, in a simulated overcharge scenario, if the BMS firmware fails to trigger overcharge protection in a timely manner after the voltage reaches a set threshold, its logic is considered abnormal. The evaluation process can be easily conducted by manually comparing the firmware response information with the preset expected behavior. For instance, testers can check the BMS firmware logs to determine whether the firmware outputs the correct fault code or executes the expected protection measures under specific parameter changes. If the firmware response matches the expected behavior, a test result indicating normal logic is generated; otherwise, a test result indicating abnormal logic is generated.

[0045] The following example will provide a more detailed explanation of the above technical solution: Suppose user A needs to test the logic response of a BMS firmware in a "battery overcharge protection" scenario. Traditional methods might require setting up a complex test environment or writing complex CAN command sequences. However, using the method in this embodiment, user A can operate by following these steps.

[0046] First, in the character test case acquisition phase, user A does not need to understand the CAN protocol or firmware programming. They simply need to input a string of character data into the test interface, such as: "Cell1_Voltage: 2000~3000, 100, 100". The test terminal receives this character data and converts it into the corresponding character test case.

[0047] Secondly, after receiving the character test case, the test terminal performs instruction conversion processing. Specifically, the test terminal parses key information such as "Cell1", "Voltage", "2000~3000", "100", and "100". Based on this character data, the test terminal constructs a parameter update instruction sequence. For example, the test terminal generates a series of voltage update instructions, starting from 2000mV, increasing by 10mV every 100ms, up to 3000mV, containing a total of 101 parameter update instructions. Each parameter update instruction contains a specific voltage value and a corresponding simulation time. Thus, the test scenario described in natural language is transformed into a machine-executable, ordered sequence of parameter update instructions.

[0048] Next, the test terminal sends the parameter update command sequence to the BMS firmware under test. For example, through a simulated CAN bus interface, the test terminal sends a parameter update command to the BMS firmware under test according to the time step information carried in the parameter update command. After receiving these commands, the BMS firmware under test updates its internal battery voltage parameters to the values ​​specified in the command, thereby simulating the actual change in battery voltage. During the command transmission process, the test terminal continuously monitors and acquires the firmware response information of the BMS firmware under test. This response information may include the BMS's internal status register values, fault indicator status, protection relay action signals, or real-time data broadcast via the CAN bus. For example, the test terminal records whether the BMS outputs an overcharge fault code or disconnects the charging / discharging circuit at a specific voltage point during the voltage rise process.

[0049] Finally, based on the acquired firmware response information, the test terminal performs a logical evaluation of the BMS firmware under test. The test terminal checks whether the BMS firmware under test promptly triggers the overcharge protection mechanism (e.g., outputting an overcharge fault code or disconnecting a relay) when the simulated voltage reaches 2500mV. If the BMS firmware's response information shows that it has successfully triggered overcharge protection when the voltage reaches 2500mV, a logical test result indicating that the BMS firmware under test is logically normal is generated. Conversely, if the BMS firmware fails to trigger overcharge protection promptly or correctly, a logical test result indicating that the BMS firmware under test is logically abnormal is generated. Through this process, user A can clearly understand whether the logical behavior of the BMS firmware in an overcharge scenario meets expectations, thereby verifying its reliability.

[0050] Based on the above examples, the BMS firmware logic testing method provided in this embodiment demonstrates significant technical contributions.

[0051] Firstly, regarding test environment setup, this method converts character test cases in natural language format into parameter update instruction sequences, achieving software-level simulation of BMS firmware input parameters. Compared to existing technologies that rely on real sensors, battery packs, or dedicated hardware-in-the-loop (HIL) devices for testing, this method eliminates the need for complex physical hardware setups, enabling rapid and flexible simulation of various extreme conditions, such as instantaneous voltage surges or temperature gradient changes, effectively reducing hardware costs and the complexity of the test environment.

[0052] Secondly, regarding the testing threshold, this method allows testers to write test cases in natural language, greatly reducing the professional skills required of testers. Unlike existing technologies that require testers to have firmware programming skills or be proficient in CAN communication protocols and command formats, this method automates the complex command generation process, enabling non-professional programmers to easily create and execute tests, thereby reducing the professional requirements and labor costs for the testing team.

[0053] Furthermore, regarding test case flexibility, this method enables rapid definition and modification of test scenarios through natural language descriptions of character-based test cases. Compared to the cumbersome operation of rewriting firmware code or CAN commands for adjusting operating parameters in existing technologies, this method allows users to directly modify natural language descriptions, and the test terminal automatically completes command conversion, thereby improving the iteration efficiency and flexibility of test cases and better adapting to the testing needs of different BMS firmware models.

[0054] In summary, this embodiment effectively solves the technical problems of complex test environment setup, high testing threshold, and poor test case flexibility in existing BMS firmware testing methods by introducing character test cases in natural language form and an automated instruction conversion mechanism. It provides a simple, comprehensive, and user-friendly BMS firmware logic testing method that does not require professional programming or CAN instruction knowledge, and has significant progressive and practical value.

[0055] See Figure 2 In one embodiment, before obtaining character test cases, the BMS firmware logic test method includes, but is not limited to, steps S201 to S203.

[0056] Step S201: In response to the received test request, display the corresponding test case template.

[0057] Step S202: In response to the editing operation on the test case template, insert the corresponding character data into the test case template to obtain character test data.

[0058] Step S203: Encapsulate the character test data to obtain character test cases.

[0059] When the test terminal receives a test request, it displays the corresponding test case template. The test request can be an instruction issued by the user through a graphical user interface (GUI), such as clicking the "Create New Test Case" button, or it can be a program call from an automated test script. The test case template aims to provide a predefined, structured input framework to guide the user or automated program in inputting the required information for the test in a standardized manner. This template can be an interactive form containing multiple preset fields and prompts, or a text file with specific labels and structure.

[0060] Subsequently, the test terminal responds to the editing operation on the test case template by inserting corresponding character data into the template, thereby obtaining character test data. The editing operation can be a user manually entering specific numerical values, text descriptions, or selecting preset options in various fields of the test case template, such as entering battery voltage range, temperature change rate, etc. Alternatively, the editing operation can be an automated test program filling specific locations in the template with character information read from external data sources (such as databases or configuration files) via a programming interface (API). In this way, a generic template is filled to form specific, structured character test data.

[0061] Finally, the test terminal encapsulates the character test data to obtain character test cases. The encapsulation process integrates and organizes the aforementioned structured character test data according to preset formats and syntax rules, forming a complete character test case that can be processed later. For example, the character test data can be combined into a string that conforms to specific natural language description habits, or it can be converted into a standardized data format, such as JSON, XML, or other file formats, to facilitate subsequent parsing and instruction conversion.

[0062] This application's solution standardizes and automates the character test case generation process by introducing test case templates, editing operations, and data encapsulation steps before acquiring character test cases. When the test terminal receives a test request, it first displays a structured test case template. This template predefines the parameters and formats required for the test cases, guiding the user or automated program to input accurate data. The user or program then edits the template, filling in the corresponding fields with specific character data to form structured character test data. Subsequently, the test terminal encapsulates this character test data, converting it into character test cases in a unified format. This preprocessing mechanism ensures that the generated character test cases have good structure and consistency, providing high-quality input for subsequent instruction conversion processing, thereby guaranteeing the accuracy and reliability of the logic evaluation of the BMS firmware under test.

[0063] The above technical solution effectively addresses the problems of low efficiency, error-proneness, and inconsistency in manually creating natural language test cases during BMS firmware logic testing. By providing structured test case templates and guided editing operations, the efficiency and standardization of test case creation are greatly improved, ensuring the quality and accuracy of character-based test cases. This lays a solid foundation for subsequent instruction conversion and firmware logic evaluation, significantly enhancing the reliability and automation level of the entire testing process.

[0064] See Figure 3 In one embodiment, the method for performing instruction conversion processing on character test cases includes, but is not limited to, steps S301 to S303.

[0065] Step S301: Parse the character test cases to identify the corresponding character data.

[0066] Step S302: Based on the character data, construct multiple sets of character instruction data.

[0067] Step S303: Based on the preset character-instruction mapping relationship, perform data mapping on the character instruction data to obtain a parameter update instruction sequence consisting of a corresponding number of parameter update instructions.

[0068] Parsing character test cases aims to extract meaningful, structured information units from natural language-based test cases, such as firmware identifiers, parameter names, numerical ranges, or trends. Rule-based parsers can be used, predefining a series of grammatical rules and keywords, and identifying and extracting character data through pattern matching. For example, regular expressions can be used to match specific parameter names, numerical ranges, or time points. Alternatively, natural language processing (NLP) techniques, such as named entity recognition and intent recognition, can be used to semantically understand character test cases, thereby identifying the various character data they contain.

[0069] Based on character data, multiple sets of character instruction data are constructed. The aim is to further organize the parsed raw character data into an intermediate data structure that more closely resembles the instruction format, preparing for subsequent instruction mapping. For example, identified parameter identifiers, values, time, and other information can be combined into structured data objects or tuples, each representing a component of the instruction to be generated. Alternatively, according to a preset instruction template, the parsed character data can be filled into the corresponding fields of the template to form semi-structured character instruction data, facilitating subsequent unified processing.

[0070] Based on a pre-defined character-command mapping relationship, character command data is mapped to convert intermediate character command data into parameter update commands that the BMS firmware can directly understand and execute. A mapping table or database can be maintained, storing the correspondence between character command data and specific BMS parameter update commands. The test terminal looks up the corresponding parameter update command in the mapping table based on the character command data. Alternatively, code generation or a template engine can be used to dynamically generate parameter update commands that conform to the BMS firmware communication protocol based on the type and content of the character command data; for example, generating specific CAN message IDs, data fields, and checksums.

[0071] This application's solution effectively addresses the challenge of converting natural language test cases into executable instructions for BMS firmware by performing instruction conversion processing on character test cases. Specifically, firstly, by parsing the character test cases, key character data can be accurately identified from unstructured natural language descriptions, laying the foundation for subsequent instruction generation. Secondly, based on this identified character data, multiple sets of character instruction data are constructed. This process organizes discrete character information into a structured intermediate form, making instruction generation more systematic and standardized. Finally, based on a preset character-instruction mapping relationship, these character instruction data are mapped to obtain a parameter update instruction sequence consisting of a corresponding number of parameter update instructions. This series of interconnected steps ensures accurate and efficient conversion from natural language descriptions to machine-executable instructions, greatly improving the automation capabilities of test case processing and the accuracy of instruction generation, thus providing reliable input for the logical evaluation of the BMS firmware under test.

[0072] Through the above technical solution, this application enables efficient and accurate instruction conversion processing of character test cases in natural language form. By employing a structured parsing, construction, and mapping process, unstructured test descriptions are transformed into parameter update instruction sequences that can be directly executed by the BMS firmware, significantly improving the automation level and accuracy of instruction generation. This not only reduces the complexity and error rate of manually writing and maintaining test instructions but also ensures the accuracy and consistency of the parameter update instruction sequences sent to the BMS firmware under test. This provides high-quality input for subsequent firmware response information acquisition and logic evaluation, ultimately improving the reliability and efficiency of BMS firmware logic testing.

[0073] In some embodiments, the character data includes firmware identifier characters, parameter identifier characters, parameter range identifier characters, and parameter change rate identifier characters.

[0074] Based on character data, multiple sets of character instruction data are constructed, including: generating a corresponding number of time identifier characters based on parameter change rate identifier characters; generating a corresponding number of instantaneous parameter identifier characters based on parameter range identifier characters and parameter change rate identifier characters; and constructing multiple sets of character instruction data based on firmware identifier characters, parameter identifier characters, time identifier characters, and instantaneous parameter identifier characters.

[0075] The instantaneous parameter identifier character is based on the parameter change rate identifier character, which indicates that the parameter change rate is linearly distributed within the parameter range indicated by the parameter range identifier character.

[0076] Firmware identification characters are used to uniquely identify the BMS firmware under test, ensuring that the instruction sequence targets the correct firmware. It can be represented by the BMS firmware model code, for example, "Cell1" and "Cell2", representing cell 1 and cell 2 respectively.

[0077] Parameter identifiers are used to uniquely identify specific parameters in the BMS firmware that need to be updated or monitored, clearly indicating which parameter the command sequence operates on. They can be represented by the parameter's English abbreviation or Chinese name, such as "CellVoltage_Max" (maximum cell voltage) or "SOC" (state of charge).

[0078] Parameter range identifiers define the numerical range that a specific parameter should cover during testing, guiding the generation of instantaneous parameter values ​​and ensuring that the test covers the effective operating range of the parameter. It can be represented as a pair of values, such as "[3.0V, 4.2V]" indicating a voltage range, or "[0%, 100%]" indicating a state of charge range.

[0079] The parameter change rate identifier character is used to define the rate or trend of change of a specific parameter during the test, simulating the dynamic change process of the parameter. It can be represented by a numerical value, such as "0.1V / s" which means a change of 0.1 volts per second, or "5% / min" which means a change of 5% per minute.

[0080] This system generates a corresponding number of time marker characters based on the parameter change rate identifier, aiming to provide discrete points on the time axis for the dynamic changes of the parameters, allowing parameter values ​​to be defined and updated at these points. This can be calculated based on the preset test duration and parameter change rate, determining the required number of time steps, with each step corresponding to one time marker character. For example, if the change rate is 1V / s and the test duration is 10s, then 10 time marker characters can be generated, such as t=1s, t=2s, ..., t=10s.

[0081] Based on the parameter range identifier and the parameter change rate identifier, a corresponding number of instantaneous parameter identifier characters are generated. Their function is to generate the specific value of the parameter at each time step at the identifier character. This can be achieved by combining the parameter range and the change rate, and using algorithms such as interpolation, linear increment / decrement, etc., to calculate the parameter value at each time step. For example, if the parameter range is [3.0V, 4.2V] and the change rate is 0.1V / s, it can start at 3.0V and increase by 0.1V per second until it reaches 4.2V or the test ends.

[0082] Based on firmware identifier characters, parameter identifier characters, time identifier characters, and instantaneous parameter identifier characters, multiple sets of character instruction data are constructed. These generated identifier characters are then combined to form complete character instruction data that can be subsequently mapped to machine instructions. This allows these identifier characters to be concatenated according to a preset format, such as "firmware ID_parameter name_time_instantaneous value".

[0083] This application introduces firmware identifier characters, parameter identifier characters, parameter range identifier characters, and parameter change rate identifier characters to provide a more refined and dynamic descriptive capability for the construction of character command data. Specifically, when constructing multiple sets of character command data, a series of discrete time identifier characters are first generated based on the parameter change rate identifier characters, which constitute the time axis of parameter changes. Subsequently, combined with the parameter range identifier characters and parameter change rate identifier characters, corresponding instantaneous parameter identifier characters are generated for each time identifier character. The values ​​of these instantaneous parameter identifier characters are designed to be linearly distributed within the parameter range represented by the parameter range identifier characters, based on the parameter change rate represented by the parameter change rate identifier characters. Finally, the firmware identifier characters, parameter identifier characters, time identifier characters, and instantaneous parameter identifier characters are combined to construct multiple sets of character command data. This approach enables the generated character command data to accurately simulate the dynamic changes of parameters in the BMS firmware within a specific time period according to a preset range and rate, greatly improving the coverage and realism of test cases and effectively solving the shortcomings of traditional methods in simulating complex dynamic parameter changes.

[0084] For example, suppose we need to test the response logic of the BMS firmware when the battery cell voltage changes linearly from low to high. In this case, the firmware identifier can be set to "Cell1", the parameter identifier to "Voltage", the parameter range identifier to "2000~3000", and the parameter change rate identifier to "100, 100". Based on this, the test terminal can first generate a series of time markers, for example, from t=0ms to t=10000ms, a total of 101 time points. Then, at each time point, based on the initial voltage of 2000mV and the change rate at 100ms intervals, the instantaneous parameter value is calculated linearly. For example, at t=100ms, the instantaneous parameter identifier is 2010; at t=200ms, the instantaneous parameter identifier is 2010; and at t=10000ms, the instantaneous parameter identifier is 3000. Finally, these firmware identifier characters, parameter identifier characters, time identifier characters, and instantaneous parameter identifier characters are combined to form a series of character command data such as "Cell1, 0ms, Voltage=2000", "Cell1, 100ms, Voltage=2010", "Cell1, 200ms, Voltage=2020", ..., "Cell1, 10000ms, Voltage=3000". This character command data can accurately simulate the smooth rise of the cell voltage during the charging process, providing realistic test input for the overvoltage protection, equalization management, and other logic of the BMS firmware.

[0085] The above technical solution enables the systematic and precise construction of multiple sets of character instruction data based on firmware identifier characters, parameter identifier characters, parameter range identifier characters, and parameter change rate identifier characters. This construction method allows the generated character instruction data to simulate the dynamic changes of parameters within a specific range at a preset rate, thereby providing test inputs for the BMS firmware under test that more closely resemble actual operating conditions. This significantly improves the comprehensiveness and accuracy of BMS firmware logic testing, especially in evaluating the firmware's responsiveness to dynamic parameter changes, effectively avoiding potential logic defects caused by insufficient test scenario coverage, and thus improving the reliability and security of the BMS firmware.

[0086] In some embodiments, sending a parameter update instruction sequence to the BMS firmware under test includes: sending a test request to the BMS firmware under test, causing the BMS firmware under test to mask sensor detection information and change the CAN permission to a read-write state; after sending the test request, communicating with the BMS firmware under test through the CAN bus interface, configuring communication parameters that are compatible with the BMS firmware under test, and sending parameter update instructions in the parameter update instruction sequence to the BMS firmware under test according to a preset time step.

[0087] This application's solution, through a series of preparatory and control steps, ensures that the parameter update command sequence can be accurately and effectively sent to the BMS firmware under test (DUT) and obtain a reliable firmware response. First, before sending the specific parameter update command, the test terminal sends a test request to the DUT firmware. This test request puts the DUT firmware into a controlled test state, specifically by shielding its internal sensor detection information, thereby eliminating interference from real-time environmental data and ensuring that the firmware's logical behavior is driven solely by the test command. Simultaneously, this test request prompts the DUT firmware to change its CAN access permission to a read-write state, which is crucial for subsequently writing parameter update commands to the firmware via the CAN bus, solving the problem of being unable to write parameters under the default read-only permission. After the DUT firmware enters test mode and has read-write permissions, the test terminal establishes communication with the firmware through the CAN bus interface. To ensure the stability and correctness of communication, the test terminal configures communication parameters compatible with the DUT firmware, such as baud rate and CANID, thereby ensuring that data packets can be correctly parsed and processed. Subsequently, the test terminal sends each parameter update instruction in the parameter update instruction sequence to the BMS firmware under test one by one according to a preset time step. This time-step sending method not only simulates the dynamic process of parameter changes in actual applications, but also provides sufficient processing time for the BMS firmware, avoiding internal firmware state disorder or instruction loss caused by sending instructions too quickly, thereby ensuring the integrity and effectiveness of the parameter update instruction sequence. Through the above synergistic effect, this solution provides a stable, controllable, and efficient parameter update mechanism for BMS firmware logic testing, greatly improving the accuracy and reliability of testing, and enabling natural language-based test cases to be transformed into actually executable and measurable firmware behaviors.

[0088] The following is a concrete example. Suppose the BMS firmware under test needs to be tested to assess its charging control logic response as the battery voltage rises from 3.0V to 4.2V. First, the test terminal sends a diagnostic service request (e.g., UDS service 0x10, sub-function 0x02, entering extended diagnostic session) to the BMS firmware via the CAN bus; this request is the test request. Upon receiving this request, the BMS firmware enters test mode and executes its internal logic. For example, it sets an internal flag to stop reading real-time battery voltage, current, and temperature data from the analog front-end (AFE) chip, thus masking sensor detection information. Simultaneously, the CAN communication module of the BMS firmware responds to this diagnostic request, switching access permissions for specific parameter areas from read-only mode to read-write mode. Subsequently, the test terminal physically connects to the CAN bus of the BMS firmware via its integrated CAN interface and configures communication parameters, such as setting the CAN baud rate to 500kbps and setting corresponding CANID filtering rules to ensure that only test-related messages are received and sent. Once communication is established and configured, the test terminal will retrieve one instruction from a pre-generated parameter update instruction sequence at preset time steps (e.g., every 100 milliseconds) and send it to the BMS firmware under test via the CAN bus. For example, the first instruction might set the battery voltage parameter to 3.0V, the second instruction sent 100 milliseconds later sets the voltage to 3.01V, and so on, until the voltage reaches 4.2V. Each instruction is encapsulated in a specific CAN message format, containing the parameter's CANID, data length, and specific parameter value.

[0089] Through the above technical solutions, the test terminal can effectively place the BMS firmware under test in a controlled test environment before sending the parameter update command sequence to the firmware under test. Specifically, shielding sensor detection information avoids interference from real-time environmental data on the test results, ensuring that the firmware logic response is entirely driven by test commands, thereby improving the accuracy and repeatability of the test. Simultaneously, changing the CAN permission to a read-write state solves the problem of being unable to write firmware parameters under the default read-only permission, ensuring that parameter update commands can be successfully delivered and processed by the firmware. Furthermore, by configuring appropriate communication parameters and sending commands according to a preset time step, the stability of communication between the test terminal and the BMS firmware under test and the orderliness of command transmission are ensured, avoiding firmware state abnormalities caused by poor communication or excessively fast commands, thus significantly improving the reliability and efficiency of BMS firmware logic testing. These measures work together to make the entire testing process more stable and controllable, providing a solid foundation for accurately evaluating the logical behavior of the BMS firmware.

[0090] See Figure 4In one embodiment, the method for performing instruction conversion processing on character test cases includes, but is not limited to, steps S401 to S403.

[0091] Step S401: Determine whether the firmware response information meets the preset firmware response conditions.

[0092] If the conditions are met, proceed to step S402; otherwise, proceed to step S403.

[0093] Step S402: Generate logic test results indicating that the firmware logic of the BMS under test is normal.

[0094] Step S403: Generate logic test results that characterize the logical anomalies of the BMS firmware under test.

[0095] This application's solution addresses the problems of low evaluation efficiency and high subjectivity in traditional testing by systematically evaluating the firmware response information obtained from the BMS firmware under test. Specifically, upon receiving the firmware response information returned by the BMS firmware under test after updating parameters based on the parameter update command sequence, the test terminal first performs a precise judgment on these response information according to pre-defined firmware response conditions. These conditions are pre-defined based on the expected behavior and specifications of the BMS firmware, ensuring the objectivity and accuracy of the evaluation. If all firmware response information matches these pre-defined conditions, it indicates that the logical behavior of the BMS firmware under test is as expected, and the test terminal generates a test result clearly indicating that the logic is normal. Conversely, if any firmware response information is found to be inconsistent with the pre-defined conditions, it means that the logic of the BMS firmware under test is abnormal, and the test terminal immediately generates a test result indicating that the logic is abnormal. This judgment and result generation mechanism automates and standardizes the logical testing process of the BMS firmware, avoiding errors and efficiency bottlenecks that may be caused by manual judgment, thereby ensuring the reliability of the test results and providing a clear basis for subsequent firmware debugging and optimization. In this way, the solution proposed in this application is closely integrated with the aforementioned steps of obtaining character test cases, instruction conversion, sending parameter update instruction sequences and obtaining firmware response information, forming a complete, closed-loop automated testing process, which greatly improves the efficiency and accuracy of BMS firmware logic testing.

[0096] The following is a concrete example. Assume that after receiving the parameter update command "set battery voltage to 3.8V", the BMS firmware under test is expected to return a CAN message containing the actual battery voltage value, battery temperature value, and a status code. The preset firmware response conditions can be set as follows: the actual battery voltage value should be between 3.75V and 3.85V (allowing for some error), the battery temperature value should be between 20℃ and 30℃, and the status code should be 0x00 (indicating normal operation). When the test terminal receives the firmware response information, for example, a CAN message showing an actual battery voltage of 3.81V, a battery temperature of 25℃, and a status code of 0x00, the test terminal will then check these values ​​one by one: 3.81V is within the range of 3.75V to 3.85V, 25℃ is within the range of 20℃ to 30℃, and the status code is 0x00. Since all conditions are met, the test terminal will generate a logical test result, for example, displaying "Test passed: BMS voltage, temperature, and status code are all normal". However, if the firmware response shows an actual battery voltage of 4.5V, a battery temperature of 25℃, and a status code of 0x01, the test terminal determines that the actual battery voltage of 4.5V exceeds the preset range of 3.75V to 3.85V, and the status code 0x01 may indicate some kind of error. Because of this discrepancy with the preset conditions, the test terminal will generate a logical test result, such as "Test failed: Battery voltage abnormal (4.5V), status code abnormal (0x01)".

[0097] Through the above technical solution, this application enables automated and standardized evaluation of BMS firmware response information, effectively solving the problems of low efficiency, strong subjectivity, and potential for misjudgment caused by manual judgment in traditional testing. This solution provides a clear basis for logical evaluation through preset firmware response conditions, ensuring the objectivity and accuracy of test results. When the firmware response information meets expectations, it can quickly generate logically normal test results, confirming the correct firmware function; when unexpected situations occur, it can promptly generate logically abnormal test results and point out potential problems, thereby significantly improving the efficiency and reliability of BMS firmware logic testing. This not only shortens the firmware development and verification cycle but also provides strong technical support for the quality control of BMS firmware.

[0098] In some embodiments, the BMS firmware logic testing method further includes: storing character test cases and corresponding parameter update instruction sequences; displaying currently saved character test cases in response to a received test request; and invoking the parameter update instruction sequence corresponding to the currently saved character test cases in response to a selection operation for the currently saved character test cases.

[0099] This application's solution optimizes the BMS firmware logic testing process by introducing a storage and reuse mechanism. Specifically, after performing instruction conversion processing on character test cases to obtain parameter update instruction sequences, this solution further stores the character test cases and their corresponding parameter update instruction sequences. When subsequent testing is required, the test terminal can respond to the received test request and display the currently saved character test cases to the user. Once the user performs a selection operation on these saved character test cases, the test terminal can directly call the parameter update instruction sequence associated with the selected character test case. This mechanism eliminates the need for re-converting instructions from character test cases each time during the testing process; instead, it allows direct use of pre-generated and stored instruction sequences. In this way, this solution effectively reduces the time spent on repetitive calculations and processing, significantly improving testing efficiency and convenience, and is particularly suitable for scenarios requiring frequent execution of the same test cases, such as regression testing.

[0100] The following example illustrates how a test management system can be set up, including a database module and a user interface module. When a character test case is processed to generate a parameter update instruction sequence, the test management system stores the text content of the character test case and the generated parameter update instruction sequence (e.g., serialized in JSON format) together in a specific table in the database. This table can contain fields such as "Test Case ID," "Character Test Case Content," and "Parameter Update Instruction Sequence Data." When a user initiates a test request through the user interface, the user interface module queries the database and displays a list of all saved "Character Test Case Contents." The user can select an item by clicking on it. Once a user selects a character test case, the user interface module sends a request to the backend service, carrying the "Test Case ID" of the selected character test case. Upon receiving the request, the backend service retrieves the corresponding "Parameter Update Instruction Sequence Data" from the database based on the "Test Case ID" and directly passes it to the BMS firmware test execution module, thereby initiating the test process.

[0101] Through the above technical solution, this application effectively solves the problem of time-consuming instruction conversion processing during repeated testing. By storing character test cases and their corresponding parameter update instruction sequences and providing a convenient display and recall mechanism, testers can quickly reuse existing test cases, avoiding the overhead of re-processing instruction conversion for each test. This not only significantly improves the efficiency of BMS firmware logic testing and shortens the testing cycle, but also ensures that the same character test cases always use the same parameter update instruction sequence in different test rounds, thereby improving the reliability and consistency of test results.

[0102] See Figure 5 This application also provides a BMS firmware logic testing device, which can implement the above-mentioned BMS firmware logic testing method. The device includes: The first module, 501, is used to obtain character test cases; character test cases consist of character data in natural language form. The second module 502 is used to perform instruction conversion processing on character test cases to obtain parameter update instruction sequences; The third module 503 is used to send the parameter update command sequence to the BMS firmware under test and obtain the firmware response information after the BMS firmware under test updates the parameters based on the parameter update command sequence. The fourth module 504 is used to perform logical evaluation on the BMS firmware under test based on the firmware response information, so as to generate logical test results for the BMS firmware under test.

[0103] The specific implementation of this BMS firmware logic testing device is basically the same as the specific implementation of the BMS firmware logic testing method described above, and will not be repeated here.

[0104] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0105] The following reference Figure 6 To describe an electronic device 600 according to such an embodiment of the present disclosure. Figure 6 The electronic device 600 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0106] like Figure 6 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0107] The storage unit stores program code, which can be executed by the processing unit 610, causing the processing unit 610 to perform the steps described in the above-described BMS firmware logic test method section of this specification according to various exemplary embodiments of this disclosure.

[0108] Storage unit 620 may include a readable medium in the form of a volatile storage unit, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include a read-only memory (ROM) 6203.

[0109] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0110] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0111] Electronic device 600 can also communicate with one or more external devices 600' (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0112] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0113] The BMS firmware logic testing method, apparatus, device, and medium provided in this application embodiment converts character test cases composed of character data in natural language form into instructions, and then uses the converted parameters to update the instruction sequence of the BMS firmware under test for firmware logic testing. This greatly reduces the professional skill requirements for testers, allowing non-professional programmers to easily create and execute tests, thereby reducing the professional requirements and manpower costs of the testing team. Compared with the cumbersome operation of rewriting firmware code or CAN instructions for adjusting operating parameters, it allows users to directly modify natural language descriptions and automatically complete instruction conversion, improving the iteration efficiency and flexibility of test cases, and better adapting to the testing needs of different BMS firmware models.

[0114] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the methods described above according to the embodiments of this disclosure.

[0115] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0116] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0117] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0118] Exemplary embodiments of this disclosure have been specifically shown and described above. It should be understood that this disclosure is not limited to the detailed structures, arrangements, or implementations described herein; rather, this disclosure is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A BMS firmware logic testing method, characterized in that, include: Obtain character test cases; the character test cases consist of character data in natural language form; The character test cases are processed by instruction conversion to obtain a parameter update instruction sequence; The parameter update instruction sequence is sent to the BMS firmware under test, and the firmware response information after the BMS firmware under test updates the parameters based on the parameter update instruction sequence is obtained. Based on the firmware response information, a logical evaluation is performed on the BMS firmware under test to generate the logical test results of the BMS firmware under test.

2. The BMS firmware logic testing method according to claim 1, characterized in that, Before obtaining the character test case, the following is also included: In response to a received test request, the corresponding test case template is displayed; In response to the editing operation on the test case template, corresponding character data is inserted into the test case template to obtain character test data; The character test data is encapsulated to obtain the character test cases.

3. The BMS firmware logic testing method according to claim 1, characterized in that, The instruction conversion processing for the character test cases includes: The character test cases are parsed to identify the corresponding character data; Based on the character data, construct multiple sets of character instruction data; Based on a preset character-instruction mapping relationship, the character instruction data is mapped to obtain a parameter update instruction sequence consisting of a corresponding number of parameter update instructions.

4. The BMS firmware logic testing method according to claim 3, characterized in that, The character data includes firmware identifier characters, parameter identifier characters, parameter range identifier characters, and parameter change rate identifier characters. Based on the character data, multiple sets of character instruction data are constructed, including: Based on the parameter change rate identifier character, generate a corresponding number of time identifier characters; Based on the parameter range identifier character and the parameter change rate identifier character, a corresponding number of instantaneous parameter identifier characters are generated; the instantaneous parameter identifier characters are linearly distributed within the parameter range represented by the parameter range identifier character based on the parameter change rate represented by the parameter change rate identifier character. Based on the firmware identifier character, the parameter identifier character, the time identifier character, and the instantaneous parameter identifier character, multiple sets of character instruction data are constructed.

5. The BMS firmware logic testing method according to claim 1, characterized in that, Sending the parameter update instruction sequence to the BMS firmware under test includes: Send a test request to the BMS firmware under test, so that the BMS firmware under test blocks the sensor detection information and changes the CAN permission to a readable and writable state. After sending the test request, the system communicates with the BMS firmware under test via the CAN bus interface, configures communication parameters that are compatible with the BMS firmware under test, and sends parameter update instructions from the parameter update instruction sequence to the BMS firmware under test according to a preset time step.

6. The BMS firmware logic testing method according to claim 1, characterized in that, The step of performing a logical evaluation of the BMS firmware under test based on the firmware response information includes: Determine whether the firmware response information meets the preset firmware response conditions; If the conditions are met, a logic test result is generated indicating that the firmware logic of the BMS under test is normal. If it does not meet the requirements, generate a logic test result that characterizes the logical anomaly of the BMS firmware under test.

7. The BMS firmware logic testing method according to claim 1, characterized in that, Also includes: Store the character test cases and the corresponding parameter update instruction sequence; In response to a received test request, display the currently saved character test cases; In response to the selection operation for the currently saved character test case, the parameter update instruction sequence corresponding to the currently saved character test case is invoked.

8. A BMS firmware logic testing device, characterized in that, include: The first module is used to obtain character test cases; the character test cases consist of character data in natural language form. The second module is used to perform instruction conversion processing on the character test cases to obtain a parameter update instruction sequence; The third module is used to send the parameter update instruction sequence to the BMS firmware under test and obtain the firmware response information after the BMS firmware under test updates the parameters based on the parameter update instruction sequence. The fourth module is used to perform logical evaluation on the BMS firmware under test based on the firmware response information, so as to generate logical test results for the BMS firmware under test.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the BMS firmware logic testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the BMS firmware logic test method according to any one of claims 1 to 7.

Images