Test case generation method and system based on small model

Abstract

The invention relates to the technical field of test technologies, and discloses a test case generation method and system based on a small model. The method comprises the following steps: receiving a vehicle-mounted ECU control code, extracting a hardware interface, a control logic and a time sequence constraint feature, and generating a lightweight feature vector set; constructing a weight sharing feedforward neural network to train a vehicle-mounted test small model; establishing a security level constraint system to generate constraint-oriented test parameters; organizing test parameters according to real-time requirements, and generating a battery management and motor control test input sequence; and mapping to be an executable test function based on the code template, and compiling to generate an HIL test bench execution script. The problems that an existing large model test generation method cannot be deployed in real time in a vehicle-mounted edge environment and lacks real-time constraint perception capability are solved, and the real-time performance and pertinence of vehicle-mounted test case generation are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of testing technology, and in particular to a test case generation method and system based on a small model. BACKGROUND

[0002] With the rapid development of the new energy vehicle industry, the complexity of the vehicle-mounted ECU (Electronic Control Unit) system is continuously improving. The traditional test case generation method mainly relies on model-based testing or simulation environment, and uses a large deep learning model to generate test cases automatically. In the prior art, the test case generation system usually uses a Transformer model or a large language model with a parameter quantity of hundreds of millions or even tens of billions, analyzes the vehicle-mounted software code through complex semantic understanding and context reasoning, and generates corresponding test inputs and verification scripts.

[0003] However, the existing large model test generation method has the following significant deficiencies: first, the large parameter quantity of the large model results in a high demand for computing resources, which cannot be deployed in real time in the vehicle-mounted edge computing environment, and the inference delay often exceeds the millisecond-level response requirement of the vehicle-mounted safety-critical system; second, the existing method lacks a deep understanding of the real-time constraints and safety level requirements specific to vehicle-mounted systems, and it is difficult to generate test cases that meet both functional coverage and timing performance verification; third, the traditional method cannot effectively model the complex interaction and timing dependencies between different subsystems such as battery management and motor control when dealing with vehicle-mounted multi-system collaborative testing.

[0004] Based on the above analysis, the problem of the prior art is the contradiction between the high computational complexity of the large model and the resource limitations of the vehicle-mounted edge environment, as well as the mismatch between the general test generation method and the specific needs of the vehicle-mounted system. This mismatch further results in the inability of the test case generation to simultaneously consider real-time constraint awareness and multi-system collaborative verification requirements, especially in safety-critical scenarios such as battery thermal management and motor torque control of new energy vehicles, the existing method is difficult to generate high-quality test cases that can verify millisecond-level response performance. SUMMARY

[0005] The present application provides a test case generation method and system based on a small model, which solves the problem that the existing large model test generation method cannot be deployed in real time in the vehicle-mounted edge environment and lacks real-time constraint awareness, and improves the real-time performance and relevance of vehicle-mounted test case generation.

[0006] In a first aspect, the present application provides a test case generation method based on a small model, which comprises:

[0007] receive the vehicle-mounted ECU control code, perform control flow graph analysis to extract hardware interface features, control logic features and timing constraint features, and generate a lightweight feature vector set;

[0008] construct a weight-shared feedforward neural network, use the lightweight feature vector set to perform small model training, and generate a vehicle-mounted test small model;

[0009] establish a safety level constraint system, and the vehicle-mounted test small model generates constraint-oriented test parameters according to the safety level constraint system;

[0010] organize the constraint-oriented test parameters according to real-time requirements to generate a vehicle-mounted test input sequence containing battery management test data and motor control test data;

[0011] map the vehicle-mounted test input sequence to an executable test function based on a preset code template, and compile to generate an HIL test bench execution script.

[0012] In a second aspect, the present application provides a small model-based test case generation system, comprising:

[0013] The receiving module is configured to receive the vehicle-mounted ECU control code, perform control flow graph analysis to extract hardware interface features, control logic features and timing constraint features, and generate a lightweight feature vector set;

[0014] The training module is configured to construct a weight-shared feedforward neural network, use the lightweight feature vector set to perform small model training, and generate a vehicle-mounted test small model;

[0015] The generation module is configured to establish a safety level constraint system, and the vehicle-mounted test small model generates constraint-oriented test parameters according to the safety level constraint system;

[0016] The test module is configured to organize the constraint-oriented test parameters according to real-time requirements to generate a vehicle-mounted test input sequence containing battery management test data and motor control test data;

[0017] The compiling module is configured to map the vehicle-mounted test input sequence to an executable test function based on a preset code template, and compile to generate an HIL test bench execution script.

[0018] In a third aspect, a small model-based test case generation device is provided, comprising a memory and at least one processor, the memory storing instructions; the at least one processor invokes the instructions in the memory to enable the small model-based test case generation device to perform the small model-based test case generation method described above.

[0019] In a fourth aspect, a computer readable storage medium is provided, and the computer readable storage medium stores instructions which, when executed on a computer, cause the computer to perform the small model-based test case generation method described above.

[0020] In the technical solution provided in the application, the hardware interface features, control logic features and timing constraint features of the vehicle-mounted ECU control code are extracted through control flow graph analysis to form a set of lightweight feature vectors, effectively solving the problem of excessively high computational complexity when a traditional large model method performs deep semantic analysis on vehicle-mounted code. The construction of the weight-shared feedforward neural network significantly reduces the number of model parameters, enabling the vehicle-mounted test small model to run in real time in a resource-constrained edge computing environment, overcoming the technical bottleneck that the prior art cannot be deployed in real time. The establishment of the safety level constraint system targets the safety-critical features of the vehicle-mounted system, classifying functions such as brake anti-lock and motor torque control according to millisecond, tens of milliseconds and seconds, ensuring that the generated constraint-oriented test parameters can accurately match the real-time requirements of different safety levels, solving the problem that general test methods cannot handle vehicle-mounted specific constraints.

[0021] The real-time organization mode of the vehicle-mounted test input sequence arranges battery management test data and motor control test data according to timing priority, realizing the orderly execution of multi-system collaborative testing and avoiding the problems of system test conflicts and timing confusion in traditional methods. The mapping mechanism based on the preset code template converts the test input sequence into executable test functions and compiles to generate HIL test bench execution scripts, establishing a direct conversion path from abstract test parameters to specific hardware operations, eliminating the tedious process and potential errors of manually writing test scripts. In the specific application field of vehicle-mounted test case generation, the lightweight feature extraction algorithm avoids complex natural language processing and large-scale semantic modeling, the weight-sharing mechanism significantly reduces the computational overhead of network training and inference through parameter reuse, and the safety level constraint algorithm ensures that the test case focuses on covering the vehicle-mounted safety-critical functions, so that the application realizes real-time and specialization of test case generation while ensuring test quality. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are some embodiments of the application, and for those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0023] Figure 1 An embodiment of the small model-based test case generation method in the embodiments of the application is shown in the figure.

[0024] Figure 2 An embodiment of a small model based test case generation system in the present application is shown in the figure;

[0025] Figure 3 An embodiment of a small model based test case generation system in the present application is shown in the figure; DETAILED DESCRIPTION

[0026] The present application provides a small model based test case generation method and system. The terms "first", "second", "third", "fourth" and the like (if any) in the specification and claims of the present application and the above-mentioned figures are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the term "comprising" or "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device comprising a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to the process, method, product or device.

[0027] For the sake of understanding, the specific process of the embodiments of the present application is described below. Please refer to Figure 1 An embodiment of a small model based test case generation method in the present application includes:

[0028] Step S101, receiving the vehicle-mounted ECU control code, performing control flow graph analysis to extract hardware interface features, control logic features and timing constraint features, and generating a set of lightweight feature vectors;

[0029] Step S102, constructing a weight sharing feedforward neural network, using the set of lightweight feature vectors to train a small model, and generating a vehicle-mounted test small model;

[0030] Step S103, establishing a safety level constraint system, and generating constraint oriented test parameters according to the safety level constraint system;

[0031] Step S104, organizing the constraint oriented test parameters according to real-time requirements, and generating a vehicle-mounted test input sequence containing battery management test data and motor control test data;

[0032] Step S105, mapping the vehicle-mounted test input sequence to an executable test function based on a preset code template, and compiling to generate an HIL test bench execution script.

[0033] It can be understood that the execution subject of the present application can be a small model based test case generation system, and can also be a terminal or a server, and the specific embodiments are not limited herein. The server is taken as an example for illustration in the embodiments of the present application.

[0034] Specifically, the vehicle-mounted ECU control code is received and control flow graph parsing is performed. The control flow graph parsing refers to a static analysis technique for converting program code into a graphical representation. The nodes in the graph represent program basic blocks, and the edges represent control flow transfer relationships. The static analysis process identifies function call relationships, conditional branching structures, and loop control structures in the code, forms a code structure tree, and the code structure tree is a tree representation of the program syntax structure. The conditional branching structure includes if-else statements and switch statements, and the loop control structure includes for loops and while loops. The hardware interface recognition process extracts sensor input interface features, actuator output interface features, and CAN bus communication interface features from the code structure tree. The sensor input interface features refer to variables and functions that read sensor data in the code. The actuator output interface features refer to output variables that control actuator actions. The CAN bus communication interface features refer to message sending and receiving functions related to network communication. The data type extraction process converts these interface features into hardware interface feature vectors containing data type identifiers and value range parameters. The data type identifier distinguishes between integer, floating point, Boolean, and other data types. The value range parameter records the minimum and maximum values of the variable. The logic path analysis process traverses the branching and loop structures in the code structure tree, generating control logic feature vectors and timing constraint feature vectors. The control logic feature vector records the branching conditions and jump relationships of the program execution path. The timing constraint feature vector contains real-time parameters such as interrupt response time and task execution period.

[0035] A weight sharing feedforward neural network is constructed for small model training. Weight sharing refers to a technique in which multiple neurons in a network use the same weight parameters, reducing the number of independent parameters to reduce model complexity. A three-layer feedforward neural network architecture includes an input layer, a hidden layer, and an output layer. The number of input layer neurons is equal to the feature dimension of the lightweight feature vector set. The feature dimension is the number of elements in the vector. The grouping weight sharing configuration process divides the hidden layer neurons into four neuron groups. The neurons in each neuron group share the same weight matrix. The weight matrix is a parameter matrix that connects adjacent layer neurons. The gradient descent training process updates the shared weight matrix parameters using the backpropagation algorithm. The backpropagation algorithm adjusts the parameter values by calculating the partial derivative of the loss function with respect to the weight parameters. Gradient descent finds the minimum value of the loss function by moving in the negative direction of the gradient. The parameter solidification process saves the network weight parameters after training convergence as a vehicle-mounted test small model.

[0036] A safety level constraint system is established, and the safety critical functions of the vehicle-mounted system are divided into three levels according to the response time requirements. Millisecond-level response requirements are applicable to the anti-lock braking system and motor torque control, which need to respond within milliseconds to ensure driving safety. Ten-millisecond-level response requirements are applicable to battery thermal management and charging overcurrent protection, which are important but have relatively loose time requirements. Second-level response requirements are applicable to vehicle energy management and fault diagnosis functions. The safety factor parameter setting assigns different values according to the strictness of the response time requirements, with millisecond-level corresponding to a safety factor of four, ten-millisecond-level corresponding to a safety factor of three, and second-level corresponding to a safety factor of two. The higher the safety factor value, the stricter the test coverage requirements for the function. After receiving the safety factor weight table, the vehicle-mounted test small model calculates the constraint weight values corresponding to each safety level, and the constraint weight values are obtained by multiplying the safety factor and the base weight. Then, the activation intensity of the output layer neurons is adjusted according to the constraint weight values, and the neurons with high activation intensity have higher priority for test parameters.

[0037] The constraint-oriented test parameters are organized into a vehicle-mounted test input sequence according to the real-time requirements, and battery management-related parameters and motor control-related parameters are identified. The battery management-related parameters include battery temperature parameters, charging and discharging current parameters, and SOC state parameters. The motor control-related parameters include torque command parameters, speed command parameters, and load change parameters. The time sequence priority arrangement sorts the test parameters according to the millisecond-level, ten-millisecond-level, and second-level constraints, generates a parameter sequence with timestamp markers, and records the execution time point of each parameter. The parameter range setting sets the battery temperature parameter as a temperature change curve from negative forty degrees Celsius to sixty degrees Celsius, the charging and discharging current parameter as a current level sequence from zero point one times to three times, and the torque command parameter as a torque command sequence from ten percent to one hundred and twenty percent of the rated torque. These parameter ranges cover the normal working interval and boundary conditions of the vehicle-mounted system.

[0038] The vehicle-mounted test input sequence is mapped into an executable test function based on a preset code template. The preset code template library includes a bus message sending template, a sensor signal simulation template, and an actuator response detection template. These templates define standard test function structures and interface specifications. Template matching selects a corresponding code template based on the test data types in the vehicle-mounted test input sequence, including temperature data, current data, torque data, and the like. Parameter mapping replaces specific values in the test input sequence with parameter placeholders in the template. Temperature variation curve parameters are mapped into input parameters of a temperature sensor signal injection function, and current level sequence parameters are mapped into input parameters of a current sensor signal injection function. Time sequence control statement conversion converts timestamp information into delay control statements for function calls, calculates the time interval between adjacent function calls, and inserts wait synchronization statements to ensure that the test function is executed according to the predetermined time sequence. A compiler performs syntax checking to verify that the generated code meets the programming language specifications, and time sequence verification ensures that the time relationship of function calls meets the real-time requirements, and an HIL test bench execution script is generated.

[0039] In a specific embodiment, the process of performing step S101 can specifically include the following steps:

[0040] Performing static analysis on the vehicle-mounted ECU control code to obtain a code structure tree containing function call relationships, conditional branch structures, and loop control structures;

[0041] Performing hardware interface recognition processing based on the code structure tree to obtain sensor input interface features, actuator output interface features, and CAN bus communication interface features;

[0042] Performing data type extraction processing on the sensor input interface features, actuator output interface features, and CAN bus communication interface features to obtain a hardware interface feature vector containing data type identifiers and value range parameters;

[0043] Performing logic path analysis processing on the conditional branch structures and loop control structures in the code structure tree to obtain a control logic feature vector and a time sequence constraint feature vector containing interrupt response times and task execution periods, and combining to form a lightweight feature vector set.

[0044] Specifically, the static analysis process of the vehicle-mounted ECU control code adopts lexical analysis and syntax analysis techniques. Lexical analysis decomposes the source code character stream into a token sequence, and syntax analysis constructs an abstract syntax tree according to the syntax rules of the programming language. The static analysis process scans the code file to identify language elements such as function definitions, variable declarations, and control statements, and then constructs a function call relationship graph that records the dependency relationship between each function and the other functions it calls. Conditional branch structure recognition extracts branch condition expressions and branch body code blocks by parsing if statements, switch statements, and ternary operators. Loop control structure recognition extracts loop initialization conditions, loop continuation conditions, and loop body code blocks by parsing for loops, while loops, and do-while loops. The code structure tree uses a tree data structure to represent the syntax structure of the program, with the root node representing the entire program, internal nodes representing functions, control statements, and other program constructs, and leaf nodes representing variables, constants, and other basic elements.

[0045] The hardware interface recognition process is based on pattern matching and symbol table lookup of the code structure tree. Sensor input interface feature recognition searches for function calls and variable access statements in the code that contain the "read", "input", "sensor" keywords. Actuator output interface feature recognition searches for function calls and variable assignment statements that contain the "write", "output", "actuator" keywords. CAN bus communication interface feature recognition searches for function calls and data structure definitions that contain the "CAN", "bus", "message" keywords. The interface feature extraction process traverses each node of the code structure tree, checks the node type and attribute information, and records the node and its child node information as interface features when the node type matches the predefined interface pattern. Sensor input interface features include sensor type identification, data reading function name, and data variable name. Actuator output interface features include actuator type identification, control function name, and control variable name. CAN bus communication interface features include message identifier, sending function name, and receiving function name.

[0046] The data type extraction process analyzes the variable declaration and function signature corresponding to each interface feature. The variable declaration contains data type information such as int, float, bool, and composite types such as struct and union. The data type identifier is obtained by parsing the type keyword in the variable declaration statement, and the value range parameter is obtained by analyzing the constant definition, boundary check statement, and annotation information in the code. The hardware interface feature vector is represented by a fixed-length numerical array, and each element of the array corresponds to a specific interface attribute. The data type identifier is mapped to an integer code, with integer type mapped to code 1, float type mapped to code 2, and boolean type mapped to code 3. The value range parameter records the minimum and maximum values of the variable. When there is a boundary check statement in the code, the numerical boundary is extracted from the conditional expression. When there is a constant definition in the code, the value range is derived from the constant value.

[0047] The logical path analysis process uses a control flow graph traversal algorithm. The control flow graph is a graphical representation of program control flow transitions, with nodes representing basic blocks and edges representing control flow transitions. The conditional branch structure analysis traverses the branch paths in the control flow graph using a depth-first search, recording the entry node, exit node, and branch condition of each branch. The loop control structure analysis detects back edges in the control flow graph, which are edges that point from the loop body to the loop header. The loop header is the entry node of the loop. The control logic feature vector records the branch decision points and jump targets of the program execution path. The branch decision points correspond to the conditional judgments of if statements, and the jump targets correspond to the code positions after branch execution. The timing constraint feature vector extracts real-time requirement information from code annotations, function attributes, and system configuration files. The interrupt response time is obtained by analyzing the function attributes of the interrupt service program, and the task execution period is obtained by analyzing the task scheduling configuration and timer settings. The lightweight feature vector set concatenates the hardware interface feature vector, control logic feature vector, and timing constraint feature vector to form a unified feature representation. The concatenation process ensures that the dimensions of different types of feature vectors are aligned and the data types are consistent.

[0048] In a specific embodiment, the process of performing step S102 can specifically include the following steps:

[0049] A three-layer feedforward neural network architecture is constructed, including an input layer, a hidden layer, and an output layer. The feature dimension of the lightweight feature vector set is set as the number of input layer neurons, and the network topology structure is obtained.

[0050] The hidden layer neurons in the network topology structure are configured with group weight sharing. The hidden layer neurons are divided into four neuron groups, and the neurons in each neuron group share the same weight matrix. The weight sharing network structure is obtained.

[0051] The lightweight feature vector set is input into the weight sharing network structure for gradient descent training processing, and the shared weight matrix parameters are updated through a back propagation algorithm to obtain converged network weight parameters.

[0052] The network structure is parameterized based on the converged network weight parameters, and the total parameter amount is controlled within a preset threshold range to obtain a vehicle-mounted test small model.

[0053] Specifically, the three-layer feedforward neural network architecture construction process determines the network hierarchy. The feedforward neural network refers to a network structure in which data flows in one direction. Information flows from the input layer to the hidden layer and then to the output layer, and there is no feedback connection. The number of input layer neurons directly corresponds to the feature dimension of the lightweight feature vector set. The feature dimension is the number of numerical elements contained in the vector. When the lightweight feature vector set contains a total of 128 numerical elements including hardware interface features, control logic features, and timing constraint features, 128 neurons are set in the input layer. The number of hidden layer neurons is determined according to the input dimension and output requirement, and is usually set to half of the number of input layer neurons, i.e., 64 neurons. The number of output layer neurons corresponds to the encoding dimension of the test parameters. When the test parameters to be generated include 32 different types such as temperature, current, and torque, 32 neurons are set in the output layer. The network topology adopts a full connection mode, each input layer neuron is connected to all hidden layer neurons, and each hidden layer neuron is connected to all output layer neurons. The connection weight is initialized with random values.

[0054] The grouping weight sharing configuration process divides the 64 neurons of the hidden layer into 4 neuron groups, each group containing 16 neurons. Weight sharing refers to the use of the same weight parameters for calculation by neurons within a group. The weight matrix is a parameter matrix that connects adjacent layer neurons. The weight matrix from the input layer to the hidden layer originally requires 8192 independent parameters, and after weight sharing, only 2048 independent parameters are required. Each neuron group uses the same weight matrix for input weighted summation calculation. The weight sharing network structure reduces the total parameter amount of the model through a parameter reuse mechanism. The weight matrix of the first group of neurons is denoted as W1, the weight matrix of the second group of neurons is denoted as W2, the weight matrix of the third group of neurons is denoted as W3, and the weight matrix of the fourth group of neurons is denoted as W4. The dimension of each weight matrix is 128 rows and 16 columns. Each neuron within a neuron group receives the same input vector and uses the same weight matrix for matrix multiplication operation, and then obtains the output value through an activation function.

[0055] The gradient descent training process adopts a supervised learning manner, and the training data contains a lightweight feature vector as input and a corresponding test parameter as target output. The back propagation algorithm updates the parameter values by calculating the gradient of the network weight parameters with respect to the loss function, which measures the difference between the network prediction output and the target output. Common loss functions include mean square error and cross entropy. Gradient calculation is performed layer by layer from the output layer to the input layer. The output layer gradient is obtained by taking the partial derivative of the loss function with respect to the output layer weight. The hidden layer gradient is obtained by back propagation from the output layer gradient using the chain rule. The weight update uses the gradient descent formula, where the new weight is equal to the old weight minus the learning rate multiplied by the gradient value. The learning rate controls the step size of parameter update. The update of the shared weight matrix requires the accumulation of the gradient values of all neurons in the same group. The accumulated gradient reflects the contribution of the entire neuron group to the loss function. Convergence is determined by monitoring the change in the loss function value during training. When the loss function value changes for consecutive training rounds are less than a pre-set threshold, it is considered that the network weight parameters have converged.

[0056] The parameter solidification process saves the trained weight matrices W1, W2, W3, W4 and bias vectors as a model file. The total parameter amount includes the weight parameters from the input layer to the hidden layer, the hidden layer bias parameters, the weight parameters from the hidden layer to the output layer, and the output layer bias parameters. The pre-set threshold range is determined according to the memory limit of the vehicle-mounted edge computing device. When the device memory is 2MB, the model parameter amount needs to be controlled within 500,000 floating-point numbers, each floating-point number occupies 4 bytes, and the total memory occupancy does not exceed 2MB. The inference process of the vehicle test small model includes forward propagation calculation. The input feature vector is processed through weight matrix multiplication, bias addition, and activation function, and the final test parameter output is calculated layer by layer.

[0057] In a specific embodiment, the process of performing step S103 can specifically include the following steps:

[0058] Establish a vehicle system safety critical function classification standard, divide the anti-lock braking system and motor torque control into millisecond-level response requirements, divide the battery thermal management and charging overcurrent protection into ten-millisecond-level response requirements, divide the vehicle energy management and fault diagnosis into second-level response requirements, and form a three-level safety level constraint system;

[0059] Set the safety factor parameters of the three-level safety level constraint system, the millisecond-level response requirement corresponds to a safety factor of four, the ten-millisecond-level response requirement corresponds to a safety factor of three, and the second-level response requirement corresponds to a safety factor of two, and generate a safety factor weight table;

[0060] The vehicle test small model receives the safety factor weight table, calculates the constraint weight values corresponding to each safety level, adjusts the activation intensity of the output layer neurons according to the constraint weight values, and generates a test parameter candidate set with safety level identification;

[0061] Screening parameter combinations in the candidate set of test parameters that meet the response time requirements of the corresponding safety level, and generating constraint-oriented test parameters.

[0062] Specifically, the vehicle system safety-critical function classification standard establishment process classifies vehicle functions according to their impact on driving safety and response time requirements. The anti-lock braking system belongs to the active safety system, which must adjust the brake pressure within milliseconds when the wheels are about to lock to prevent the vehicle from losing control, so it is classified as a millisecond-level response requirement. Motor torque control directly affects vehicle acceleration and driving performance, and abnormal torque output can cause sudden acceleration or loss of power, so it also requires a millisecond-level response to ensure driving safety. Battery thermal management is responsible for monitoring and controlling battery temperature, and needs to start the cooling system when the battery temperature exceeds the safety threshold. Although important, the time requirement is relatively loose, and it is classified as a ten-millisecond-level response requirement. The overcurrent protection monitors whether the charging current exceeds the safety limit, and needs to cut off the charging circuit in the case of overcurrent, which also belongs to the ten-millisecond-level response requirement. Vehicle energy management is responsible for optimizing the energy consumption distribution of each system, and fault diagnosis is responsible for detecting and reporting system abnormalities, both of which have the lowest real-time requirements and are classified as a second-level response requirement. The three-level safety level constraint system classifies vehicle functions according to the strictness of response time into three levels: millisecond-level for the highest safety level, ten-millisecond-level for the medium safety level, and second-level for the basic safety level.

[0063] The safety coefficient parameter setting assigns different numerical weights according to the importance of each safety level. The safety coefficient is a numerical index that quantifies the importance of safety, and the larger the value, the higher the safety priority. The millisecond-level response requirement corresponds to a safety coefficient of 4, reflecting its critical impact on driving safety. The ten-millisecond-level response requirement corresponds to a safety coefficient of 3, reflecting its important but non-critical safety status. The second-level response requirement corresponds to a safety coefficient of 2, indicating its basic safety guarantee function. The safety coefficient weight table uses a lookup table structure for storage, with each row recording the identifier of a vehicle function and the corresponding safety coefficient value. The anti-lock braking system identifier ABS corresponds to a safety coefficient of 4, the motor torque control identifier ETC corresponds to a safety coefficient of 4, the battery thermal management identifier BTM corresponds to a safety coefficient of 3, the overcurrent protection identifier OCP corresponds to a safety coefficient of 3, the vehicle energy management identifier VEM corresponds to a safety coefficient of 2, and the fault diagnosis identifier FDM corresponds to a safety coefficient of 2. The weight table data structure includes a function identifier field, a safety coefficient field, and a response time requirement field, making it easy for vehicle test small models to quickly query and calculate.

[0064] The vehicle-mounted test small model receives the safety coefficient weight table, adjusts the neural network output through a constraint weight value calculation process, the constraint weight value is equal to the product of the safety coefficient and the basic weight, and the basic weight reflects the basic importance of the function in the test coverage. When the basic weight of the anti-lock braking system is 0.1, the constraint weight value is 4 times 0.1, equal to 0.4, and when the basic weight of the battery thermal management is 0.1, the constraint weight value is 3 times 0.1, equal to 0.3. The output layer neuron activation intensity adjustment is realized by modifying the activation function parameters of the neurons, and the neurons with high activation intensity have larger output values, and the corresponding test parameters have higher priorities. The safety level identifier is realized by adding a safety level field in the test parameter code, and the test parameters of the millisecond-level function are marked as level 1, the test parameters of the ten-millisecond-level function are marked as level 2, and the test parameters of the second-level function are marked as level 3. The test parameter candidate set contains all test parameter combinations of the neural network output, and each parameter combination is attached with safety level identifier and constraint weight value information.

[0065] The screening process filters the test parameter candidate set according to the response time requirement, and the response time requirement is the maximum allowed response delay corresponding to each safety level. The millisecond-level function requires a response time less than 10 milliseconds, the ten-millisecond-level function requires a response time less than 100 milliseconds, and the second-level function requires a response time less than 1000 milliseconds. The parameter combination screening is realized by calculating the expected execution time of each test parameter combination, comparing the execution time with the response time requirement of the corresponding safety level, and eliminating the parameter combinations whose execution time exceeds the requirement. The constraint-oriented test parameters are the parameter combinations that meet the time constraints after screening, and these parameters can verify the correctness of the function and meet the real-time requirements.

[0066] In a specific embodiment, the process of performing step S104 can specifically include the following steps:

[0067] Identify the battery management related parameters and motor control related parameters in the constraint-oriented test parameters, classify the battery temperature parameters, charge and discharge current parameters and SOC state parameters into a battery management test data group, and classify the torque instruction parameters, speed instruction parameters and load change parameters into a motor control test data group;

[0068] According to the real-time constraint level of the battery management test data group and the motor control test data group, arrange the test parameters in the order of millisecond, ten-millisecond and second in time sequence priority, and generate a parameter sequence with timestamp markers;

[0069] The battery temperature parameters in the parameter sequence with timestamp markers are set as a temperature change curve in the range of -40℃ to 60℃, the charge and discharge current parameters are set as a current level sequence of 0.1C to 3C rate, and the torque instruction parameters are set as a torque instruction sequence of 10% to 120% of the rated torque.

[0070] The temperature change curve, the current level sequence and the torque instruction sequence are combined to form a vehicle test input sequence in time stamp order.

[0071] Specifically, the constraint-oriented test parameter identification process is implemented through parameter identifier matching and functional domain classification. The parameter identifier is a unique identification string of the test parameter, which contains the parameter type and the system information to which it belongs. The battery management related parameter identification is achieved by searching the parameter items containing the keywords such as "battery", "temp", "current", "SOC" in the parameter identifier. The battery temperature parameter identifier is "battery_temp", the charging and discharging current parameter identifier is "battery_current", and the SOC state parameter identifier is "battery_SOC". The motor control related parameter identification is achieved by searching the parameter items containing the keywords such as "motor", "torque", "speed", "load" in the parameter identifier. The torque instruction parameter identifier is "motor_torque", the speed instruction parameter identifier is "motor_speed", and the load change parameter identifier is "motor_load". The battery management test data set contains all test parameters related to the battery system. The data set structure is stored in an array form, and each array element contains a parameter identifier, a parameter value and a parameter unit. The motor control test data set contains all test parameters related to the motor system. The organization method is the same as that of the battery management test data set, and the two data sets are distinguished by the system type field.

[0072] The real-time constraint level arrangement is based on the time sequence priority rules of the aforementioned safety level constraint system. The millisecond level constraint corresponds to the highest priority 1, the ten-millisecond level constraint corresponds to the medium priority 2, and the second level constraint corresponds to the lowest priority 3. The battery temperature parameter and the charging and discharging current parameter in the battery management test data set belong to the ten-millisecond level response requirement, the SOC state parameter belongs to the second level response requirement, the torque instruction parameter and the speed instruction parameter in the motor control test data set belong to the millisecond level response requirement, and the load change parameter belongs to the ten-millisecond level response requirement. The time sequence priority arrangement algorithm adopts the quicksort method, taking the priority value as the sorting key. The parameters with smaller priority values are arranged in front, and the parameters with the same priority value are arranged in the lexicographical order of the parameter identifier. The time stamp marker is obtained by accumulating the time interval. The time stamp of the first parameter is set to 0, and the time stamp of the subsequent parameter is equal to the time stamp of the previous parameter plus the execution time interval of the parameter. The execution time interval of the millisecond level parameter is 5 milliseconds, the execution time interval of the ten-millisecond level parameter is 50 milliseconds, and the execution time interval of the second level parameter is 500 milliseconds. The parameter sequence with the time stamp marker is represented by a structure array. Each structure contains a parameter identifier, a parameter value, a time stamp and a priority field.

[0073] The parameter range setting process determines the value interval according to the working environment and performance specifications of the vehicle-mounted system. The battery temperature parameter is set to a range of -40°C to 60°C to cover extreme environmental conditions. -40°C corresponds to the lower limit of battery operation in extremely cold environments, and 60°C corresponds to the upper limit of battery safety in high-temperature environments. The temperature change curve is generated by a linear interpolation method. The starting temperature is set to 25°C, and the ending temperature is set to 45°C. The intermediate temperature points are calculated by equal interval interpolation, with an interval of 5°C. The temperature sequence includes 25°C, 30°C, 35°C, 40°C, and 45°C. The charge and discharge current parameter uses the C-rate representation method. C-rate is the ratio of battery charge and discharge current to battery rated capacity. 0.1C represents charging and discharging at one-tenth of the rated capacity, and 3C represents charging and discharging at three times the rated capacity. The current level sequence includes 0.1C, 0.5C, 1C, 2C, and 3C. The actual current value is calculated by multiplying the battery rated capacity by the C-rate. When the battery rated capacity is 100 Ah, 1C corresponds to a current of 100 A. The torque command parameter is expressed as a percentage of the rated torque. The rated torque is the maximum continuous output torque of the motor under rated operating conditions. 10% of the rated torque corresponds to light load conditions, and 120% of the rated torque corresponds to short-term overload conditions. The torque command sequence includes 10%, 25%, 50%, 75%, 100%, and 120% torque levels. The actual torque value is obtained by multiplying the motor rated torque by the percentage.

[0074] The combination process merges the three parameter sequences in timestamp order. Merge sort is an algorithm that combines multiple ordered sequences into one ordered sequence. The timestamp order arrangement ensures that test parameters are arranged in the order of execution time, avoiding timing conflicts and resource competition. The vehicle-mounted test input sequence is stored in a linked list structure. The linked list node contains the parameter type, parameter value, execution time, and next node pointer. The head node of the linked list records the total length and starting time of the sequence. The sequence verification process checks whether the time interval between adjacent parameters meets the hardware response capability. When the time interval between two parameters is less than the minimum hardware response time, the timestamp of the latter parameter is adjusted to meet the time constraint.

[0075] In a specific embodiment, the process of performing step S105 can specifically include the following steps:

[0076] A preset code template library containing bus message sending templates, sensor signal simulation templates, and actuator response detection templates is called. According to the test data type in the vehicle-mounted test input sequence, the corresponding code template is selected to generate a template matching result.

[0077] mapping the temperature change curve parameters in the vehicle test input sequence as input parameters of the temperature sensor signal injection function, mapping the current level sequence parameters as input parameters of the current sensor signal injection function, and mapping the torque instruction sequence parameters as input parameters of the torque instruction sending function, to generate a parameter mapping code segment;

[0078] Based on the parameter mapping code segment and the template matching result, the timestamp information is converted into a timing control statement of function call, and a test function code containing timing logic is generated;

[0079] The test function code is input into a compiler for syntax checking and timing verification processing, and a HIL test bench execution script is generated.

[0080] Specifically, the preset code template library calling process is implemented through a template index table and data type matching. The preset code template library is a pre-written standardized code framework set, which contains function templates and code structures commonly used in vehicle testing. The bus message sending template defines the standard format of CAN bus message sending, including message identifier, data length and data content fields. The sensor signal simulation template defines the function interface of sensor data injection, including sensor type, signal value and signal time parameters. The actuator response detection template defines the detection logic of actuator action verification, including expected response, actual response and comparison judgment code. The test data type identification is implemented by analyzing the data type identifier of each parameter in the vehicle test input sequence. The temperature data type identifier is "TEMP_DATA", the current data type identifier is "CURRENT_DATA", and the torque data type identifier is "TORQUE_DATA". The code template selection adopts a hash table lookup method, taking the data type identifier as the key value, and the corresponding code template as the hash value. When "TEMP_DATA" type is detected, the sensor signal simulation template is selected, and when "TORQUE_DATA" type is detected, the bus message sending template is selected. The template matching result records the code template type and template content corresponding to each test parameter, which is stored in an array structure. The array index corresponds to the position of the test parameter in the input sequence, and the array element contains the template type field and the template code field.

[0081] The parameter mapping process replaces specific values in the on-board test input sequence with parameter placeholders in the code template, which are variables to be replaced represented by specific markers in the code template. The temperature profile parameter mapping is implemented through string replacement operations. The temperature sensor signal injection function template contains a temperature value placeholder "<TEMP_VALUE>" and a timestamp placeholder "<TIME_STAMP>". When the temperature profile contains values such as 25°C, 30°C, and 35°C, "<TEMP_VALUE>" is replaced with 25, 30, and 35, respectively. The current level sequence parameter mapping replaces the current value placeholder "<CURRENT_VALUE>" in the current sensor signal injection function template with actual current values corresponding to 0.1C, 0.5C, and 1C. When the battery rated capacity is 100 Ah, the actual current value corresponding to 0.1C is 10 A, and "<CURRENT_VALUE>" is replaced with 10. The torque command sequence parameter mapping replaces the torque value placeholder "<TORQUE_VALUE>" in the torque command sending function template with actual torque values corresponding to 10%, 25%, and 50%. When the motor rated torque is 200 Nm, the actual torque value corresponding to 10% is 20 Nm, and "<TORQUE_VALUE>" is replaced with 20. The parameter mapping code segment is a collection of code segments after parameter replacement. Each code segment corresponds to a specific test operation, and the code segment contains a function name, a parameter list, and an execution logic.

[0082] The timing control statement conversion is based on timestamp information and function call relationships. The timestamp information records the execution time points of each test parameter, and the function call relationship describes the sequential dependency between test functions. The timing control statement includes a delay control statement and a synchronization waiting statement. The delay control statement inserts a waiting instruction by calculating the time interval between adjacent function calls. When the timestamp of the temperature sensor signal injection function is 10 milliseconds and the timestamp of the current sensor signal injection function is 60 milliseconds, the time interval between them is 50 milliseconds, and a waiting statement with a delay of 50 milliseconds is inserted. The synchronization waiting statement ensures that the next function is started after the previous function is executed. The synchronization control is achieved by checking the function return status and execution flag. The test function code adopts a sequential execution structure, and the function call statements are arranged in chronological order according to the timestamp. A corresponding timing control statement is inserted before each function call. The test function code structure containing timing logic includes an initialization part, a parameter setting part, a function execution part, and a result verification part. The initialization part sets up the test environment and hardware interface. The parameter setting part configures test parameters and timing relationships. The function execution part calls test functions in sequence. The result verification part checks test outputs and expected results.

[0083] The compiler processing includes two stages of syntax checking and timing verification. The syntax checking verifies whether the generated test function code conforms to the syntax specifications of the programming language, including variable declaration, function call, operator use, and statement structure. Syntax error detection is achieved through lexical analysis and syntax analysis. Lexical analysis decomposes the code text into a sequence of tokens, and syntax analysis constructs a syntax tree according to the language syntax rules. Syntax errors include undeclared variables, mismatched function parameters, missing semicolons, and other common programming errors. Timing verification checks whether the timing relationship of function calls meets the hardware response capability and system constraints. Verification content includes whether the function execution time exceeds the allocated time slice, whether the interval between adjacent function calls meets the hardware minimum response time, and whether the total execution time is within the test time window. The HIL test bench executes scripts, which are executable files output by the compiler, containing machine code instructions and test configuration information. Machine code instructions control specific operations of test hardware, and test configuration information defines test environment parameters and expected result thresholds.

[0084] In a specific embodiment, the step of converting the timestamp information into the timing control statements of the function calls based on the parameter mapping code segment and the template matching result can specifically include the following steps:

[0085] Extract the timestamp information of each function call in the parameter mapping code segment, and standardize the timestamp values according to millisecond, tenth of a second, and second-level time units to generate a timing marker list;

[0086] Calculate the delay time between adjacent function calls according to the time interval in the timing marker list, insert delay control statements and wait synchronization statements, and generate timing control code blocks;

[0087] Logically combine the function declarations in the template matching result with the timing control code blocks, arrange the function call statements according to the timestamp order, and generate test flow code;

[0088] Insert response time detection statements and timeout exception handling statements in the test flow code to generate test function code containing timing logic.

[0089] Specifically, the timestamp information extraction process is implemented by parsing the time attribute of each function call statement in the parameter mapping code segment, and the timestamp information is recorded in the comment or parameter list of the function call statement, represented by a specific format identifier. The timestamp value extraction uses a regular expression matching method, and the regular expression pattern is "@TIME:(\d+)(ms|s)", where \d+ matches the numerical part, and ms or s matches the time unit part. The standardization process converts the numerical values of different time units into a unified millisecond unit, and the conversion rule is that the second-level numerical value is multiplied by 1000 to obtain the millisecond numerical value, the ten-millisecond-level numerical value is multiplied by 10 to obtain the millisecond numerical value, and the millisecond-level numerical value remains unchanged. The time sequence label list is stored in a structure array, each structure element contains a function name field, an original timestamp field, a standardized timestamp field and a time unit field, and the structure array is sorted in ascending order according to the standardized timestamp value. The standardization process traverses all the extracted timestamp values, identifies the time unit identifier and performs the corresponding numerical conversion operation, converts "5s" to 5000 milliseconds, keeps "50ms" as 50 milliseconds, and converts "2x10ms" to 20 milliseconds.

[0090] The time interval calculation is based on the difference between the standardized timestamps of adjacent elements in the time sequence label list, and the delay time is equal to the timestamp of the next function minus the timestamp of the previous function. The delay control statement generation inserts the corresponding wait instruction by judging the time interval value, and inserts the delay statement when the time interval is greater than zero, and the delay statement format is "delay(time interval)", and when the time interval is equal to zero, it means simultaneous execution, and no delay statement is inserted. The wait synchronization statement is used to ensure that the next function is started after the previous function is executed, and the synchronization mechanism is implemented by checking the function return state flag bit, and the wait synchronization statement format is "wait_for_completion(function handle)". The time sequence control code block organizes the delay control statement and the wait synchronization statement according to the execution order to form a complete time sequence control logic, and the code block structure includes time point label, delay instruction, synchronization check and error handling. In the time interval calculation process, when the timestamp of the temperature sensor function is 10 milliseconds and the timestamp of the current sensor function is 60 milliseconds, the time interval between them is 60 minus 10 equal to 50 milliseconds, and the "delay(50)" delay control statement is generated.

[0091] The logical combination process merges the function declaration in the template matching result with the time sequence control code block, and the function declaration contains complete information such as function name, parameter list, return type and function body. The logical combination adopts a code snippet splicing method, inserts the function declaration into the corresponding position of the time sequence control code block, and forms a code segment with complete execution logic. The timestamp sequence arrangement is implemented by sorting the function call statements according to the timestamp values, and the sorting algorithm adopts a quick sorting method with the timestamp value as the sorting key value. The test flow code structure includes three parts of an initialization section, an execution section and a cleaning section. The initialization section sets the test environment and variable declaration, the execution section includes function call statements and time sequence control statements arranged in sequence, and the cleaning section includes resource release and state reset statements. In the function call statement arrangement process, the timestamp of the torque instruction sending function is 0 milliseconds, arranged in the first place, the timestamp of the temperature sensor function is 10 milliseconds, arranged in the second place, and the timestamp of the current sensor function is 60 milliseconds, arranged in the third place, forming a test flow code that is executed in time sequence.

[0092] The response time detection statement insertion process adds time measurement code after each key function call, and the time measurement is implemented by recording the system timestamps before and after the function call. The response time calculation method is to subtract the timestamp before the function call from the timestamp after the function call, and the calculation result is compared with the preset response time threshold for judgment. The timeout exception handling statement adopts a conditional judgment structure, which triggers the exception handling logic when the actual response time exceeds the preset threshold. The exception handling includes error log recording, test termination and resource cleaning operations. The complete structure of the time sequence logic test function code includes global variable declaration, function definition, main execution flow and exception handling mechanism. The global variable records test state and time information, the function definition includes specific implementation of each test operation, the main execution flow calls each test function according to the time sequence control logic, and the exception handling mechanism monitors time violations and error states in the execution process.

[0093] The above describes the test case generation method based on the small model in the embodiments of the application, and the test case generation system based on the small model in the embodiments of the application is described below. Please refer to Figure 2 The test case generation system based on the small model in the embodiments of the application includes one embodiment:

[0094] The receiving module is configured to receive the vehicle-mounted ECU control code, analyze and extract hardware interface features, control logic features and time sequence constraint features to generate a set of lightweight feature vectors;

[0095] The training module is configured to construct a weight-shared feedforward neural network, train a small model using the set of lightweight feature vectors, and generate a vehicle-mounted test small model;

[0096] The generating module is configured to establish a security level constraint system, and the vehicle-mounted test small model generates constraint-oriented test parameters according to the security level constraint system.

[0097] The testing module is configured to organize the constraint-oriented test parameters according to real-time requirements, and generate a vehicle-mounted test input sequence containing battery management test data and motor control test data.

[0098] The compiling module is configured to map the vehicle-mounted test input sequence into an executable test function based on a preset code template, and compile to generate an HIL test bench execution script.

[0099] The above Figure 2 The small-model-based test case generation system in the embodiment of the application is described in detail from the perspective of a modular functional entity, and the small-model-based test case generation device in the embodiment of the application is described in detail from the perspective of hardware processing.

[0100] Referring to Figure 3 , the embodiment of the application further provides a small-model-based test case generation device, which can be a server, and the internal structure of the small-model-based test case generation device can be as shown in Figure 3 . The small-model-based test case generation device includes a processor, a memory, a display screen, an input device, a network interface and a database connected through a system bus. The processor of the computer is configured to provide computing and control capabilities. The memory of the small-model-based test case generation device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The database of the small-model-based test case generation device is configured to store corresponding data in the embodiment. The network interface of the small-model-based test case generation device is configured to communicate with an external terminal through a network connection. The computer program is executed by the processor to implement the above method.

[0101] Those skilled in the art can understand Figure 3 that the structure shown in the embodiment is only a block diagram of part of the structure related to the scheme of the application, and does not constitute a limitation on the small-model-based test case generation device to which the scheme of the application is applied.

[0102] The application further provides a computer readable storage medium, which can be a non-volatile computer readable storage medium or a volatile computer readable storage medium. The computer readable storage medium stores instructions, and when the instructions are run on a computer, the computer is caused to perform the steps of the small-model-based test case generation method.

[0103] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described system, system and unit can refer to the corresponding processes in the foregoing method embodiments, and will not be described here.

[0104] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application or the entire or part of the technical solutions that essentially contribute to the prior art can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing a small model-based test case generation device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program code storage media.

[0105] The above embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A test case generation method based on a small model, characterized in that, The method includes: Receive vehicle ECU control code, perform control flow graph parsing to extract hardware interface features, control logic features and timing constraint features, and generate a lightweight feature vector set; A weight-shared feedforward neural network is constructed, and a small model is trained using the lightweight feature vector set to generate an in-vehicle test small model. A safety level constraint system is established, and the vehicle-mounted test mini-model generates constraint-guided test parameters based on the safety level constraint system. The constraint-guided test parameters are organized according to real-time requirements to generate an on-board test input sequence containing battery management test data and motor control test data. Based on a preset code template, the vehicle-mounted test input sequence is mapped to an executable test function, and compiled to generate an HIL test bench execution script.

2. The test case generation method based on a small model according to claim 1, characterized in that, The process involves receiving the vehicle ECU control code, performing control flow graph analysis to extract hardware interface features, control logic features, and timing constraint features, and generating a lightweight feature vector set, including: Static analysis is performed on the vehicle ECU control code to obtain a code structure tree containing function call relationships, conditional branching structures, and loop control structures. Hardware interface identification processing is performed based on the code structure tree to obtain sensor input interface features, actuator output interface features, and CAN bus communication interface features. The sensor input interface features, actuator output interface features, and CAN bus communication interface features are processed by data type extraction to obtain a hardware interface feature vector containing data type identifiers and value range parameters. Logical path analysis is performed on the conditional branch structure and loop control structure in the code structure tree to obtain control logic feature vectors and timing constraint feature vectors containing interrupt response time and task execution cycle, which are then combined to form the lightweight feature vector set.

3. The test case generation method based on a small model according to claim 1, characterized in that, The construction of a weight-shared feedforward neural network, using the lightweight feature vector set for small model training, and generating a vehicle-mounted test small model includes: A three-layer feedforward neural network architecture consisting of an input layer, a hidden layer, and an output layer is constructed. The feature dimension of the lightweight feature vector set is set to the number of neurons in the input layer, resulting in the network topology. The hidden layer neurons in the network topology are grouped into four groups of neurons, and the neurons in each group share the same weight matrix, thus obtaining a weight-sharing network structure. The lightweight feature vector set is input into the weight-sharing network structure for gradient descent training, and the shared weight matrix parameters are updated through backpropagation algorithm to obtain converged network weight parameters. Based on the converged network weight parameters, the network structure is subjected to parameter solidification processing, and the total number of parameters is controlled within a preset threshold range to obtain the vehicle-mounted test small model.

4. The test case generation method based on a small model according to claim 1, characterized in that, The establishment of a safety level constraint system, wherein the on-board test mini-model generates constraint-guided test parameters based on the safety level constraint system, including: Establish a classification standard for key safety functions of vehicle systems, classify anti-lock braking system and motor torque control as millisecond-level response requirements, battery thermal management and charging overcurrent protection as ten-millisecond-level response requirements, and vehicle energy management and fault diagnosis as second-level response requirements, forming a three-level safety level constraint system; Set the safety factor parameters of the three-level safety constraint system. The safety factor is four for millisecond-level response requirements, three for ten-millisecond-level response requirements, and two for second-level response requirements. Generate a safety factor weight table. The vehicle-mounted test mini-model receives the safety coefficient weight table, calculates the constraint weight value corresponding to each safety level, adjusts the activation intensity of the output layer neurons according to the constraint weight value, and generates a candidate set of test parameters with safety level identifiers. The constraint-guided test parameters are generated by filtering the candidate set of test parameters and selecting the parameter combinations whose response times meet the corresponding safety level requirements.

5. The test case generation method based on a small model according to claim 1, characterized in that, The step of organizing the constraint-guided test parameters according to real-time requirements to generate an on-board test input sequence containing battery management test data and motor control test data includes: Identify the battery management-related parameters and motor control-related parameters in the constraint-guided test parameters, classify the battery temperature parameters, charging and discharging current parameters, and SOC state parameters into the battery management test data group, and classify the torque command parameters, speed command parameters, and load change parameters into the motor control test data group; Based on the real-time constraint levels of the battery management test data group and the motor control test data group, the test parameters are arranged according to the time priority of milliseconds, tens of milliseconds, and seconds, and a parameter sequence with timestamps is generated. The battery temperature parameter in the timestamped parameter sequence is set to a temperature change curve in the range of -40℃ to 60℃, the charge and discharge current parameter is set to a current level sequence of 0.1C to 3C, and the torque command parameter is set to a torque command sequence of 10% to 120% of the rated torque. The temperature change curve, current level sequence, and torque command sequence are combined and arranged in timestamp order to form the on-board test input sequence.

6. The test case generation method based on a small model according to claim 1, characterized in that, The process of mapping the vehicle-mounted test input sequence to executable test functions based on a preset code template and compiling them to generate HIL test bench execution scripts includes: Call the preset code template library containing bus message sending templates, sensor signal simulation templates, and actuator response detection templates; select the corresponding code template according to the test data type in the vehicle test input sequence; and generate template matching results. The temperature change curve parameters in the vehicle test input sequence are mapped to the input parameters of the temperature sensor signal injection function, the current level sequence parameters are mapped to the input parameters of the current sensor signal injection function, and the torque command sequence parameters are mapped to the input parameters of the torque command sending function, generating a parameter mapping code segment. Based on the parameter mapping code segment and template matching results, the timestamp information is converted into timing control statements for function calls, generating test function code containing timing logic; The test function code is input into the compiler for syntax checking and timing verification to generate the HIL test bench execution script.

7. The test case generation method based on a small model according to claim 6, characterized in that, Based on the parameter mapping code segment and template matching results, the timestamp information is converted into timing control statements for function calls, generating test function code containing timing logic, including: Extract the timestamp information of each function call in the parameter mapping code segment, standardize the timestamp values ​​according to the time units of milliseconds, tens of milliseconds, and seconds, and generate a time sequence tag list; Calculate the delay time between adjacent function calls based on the time interval in the timing marker list, insert delay control statements and wait synchronization statements, and generate timing control code blocks; The function declarations in the template matching results are logically combined with the timing control code block, and the function call statements are arranged in the order of timestamps to generate test flow code. Insert response time detection statements and timeout exception handling statements into the test process code to generate the test function code containing timing logic.

8. A test case generation system based on a small model, characterized in that, For implementing the test case generation method based on a small model as described in any one of claims 1-7, the test case generation system based on a small model comprises: The receiving module is used to receive the control code from the vehicle ECU, perform control flow graph parsing to extract hardware interface features, control logic features and timing constraint features, and generate a lightweight feature vector set. The training module is used to construct a weight-shared feedforward neural network, and to train a small model using the lightweight feature vector set to generate a vehicle-mounted test small model. The generation module is used to establish a safety level constraint system, and the vehicle-mounted test mini-model generates constraint-guided test parameters based on the safety level constraint system. The test module is used to organize the constraint-guided test parameters according to real-time requirements and generate an on-board test input sequence containing battery management test data and motor control test data; The compilation module is used to map the vehicle-mounted test input sequence into executable test functions based on a preset code template, and compile and generate HIL test bench execution scripts.

9. A test case generation device based on a small model, characterized in that, The method includes a memory and a processor, the memory storing a computer program that can run on the processor, and the processor executing the computer program to implement the test case generation method based on a small model as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by a processor, it causes the processor to execute the test case generation method based on a small model as described in any one of claims 1 to 7.

Images