Automatic testing method and device for VCU system

Abstract

The invention provides an automatic test method and device for a VCU system, and belongs to the field of automobile electronic control system testing. Comprising an HIL test cabinet, and the Simulink is used for compiling a rack Simulink model; the rack Simulink model is burnt in a machine cabinet board card of the HIL test machine cabinet; the AutomationDesk is used for controlling a cabinet board card of the HIL test cabinet and sending a CAN network fault simulated by the rack Simulink model and a diagnosis instruction to a tested ECU (Electronic Control Unit); and calling a message recorder of the ControlDesk to record a corresponding log. According to the method and the device, the fault code can be automatically triggered and read, when the test requirement is changed or the test needs to be carried out under specific conditions, the process of compiling the model can be omitted, the test file configuration flow can be directly modified, and the flexible test is facilitated; and meanwhile, the message receiving and transmitting precision can be effectively controlled, and the control error of the test is controlled within the test requirement.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic control system testing technology, specifically to an automated testing method and apparatus for a VCU system. Background Technology

[0002] Diagnostic testing is a crucial part of VCU software development. It verifies the VCU software's handling of faults such as message loss, checksum errors, and RC errors, ensuring it follows the fault diagnosis strategy. Precise control of message transmission and reception timing is essential to ensure messages are sent according to a specific frame count. Currently, there are two main methods for controlling message transmission in diagnostic testing: one is using CANoe hardware with corresponding test code, and the other is using CANTest and its corresponding software. Existing solutions have the following limitations: both CANoe and CANTest require additional CAN hardware, increasing testing costs; CANoe requires using its built-in scripting language, requiring additional learning time; CANTest has low time accuracy, with transmission delays, and cannot achieve the required time accuracy under high CAN network load conditions; both CANoe and CANTest require manual control of fault message transmission, preventing fully automated testing and resulting in low test coverage. Summary of the Invention

[0003] The purpose of this invention is to solve the problems existing in the prior art and provide an automated fault testing device for hardware-in-the-loop system testing environment, which is used to simulate typical test scenarios and diagnostic tests under other special working conditions.

[0004] This invention is achieved through the following technical solution:

[0005] In a first aspect, the present invention provides an automated testing device for a VCU system, comprising software and hardware. The hardware is a HIL test cabinet, and the software includes Simulink, AutomationDesk, and ControlDesk. The device is characterized in that: Simulink is used to write a bench Simulink model; the bench Simulink model is burned into the cabinet boards of the HIL test cabinet; AutomationDesk is used to control the cabinet boards of the HIL test cabinet, sending CAN network faults and diagnostic commands simulated by the bench Simulink model to the ECU under test; and calling the message logger of ControlDesk to record corresponding logs.

[0006] Furthermore, the bench Simulink model includes: an external environment simulation module, a controller simulation module, and a message transmission and reception control module;

[0007] The message transmission and reception control module consists of an automatic diagnostic testing module and a message transmission and reception module.

[0008] The automatic diagnostic test module includes a unit for sending fault code reading instructions and a unit for sending fault code clearing instructions, used to load instructions into the cabinet boards of the HIL test cabinet and send fault code reading instructions and fault code clearing instructions.

[0009] Furthermore, the Simulink model of the test bench performs the following operations:

[0010] The first step is to send a fault code reading command for one cycle to query the relevant fault codes of the ECU under test;

[0011] The second step is to send extended frames and read fault codes.

[0012] The third step is to send a fault code clearing command to the ECU after the fault codes are read, clearing all historical fault codes.

[0013] Furthermore, the AutomationDesk performs the following operations:

[0014] Import the Mapping variable through the variable table, obtain the correspondence between message ID, message name, and message period through the Mapping variable, and store it in the SigAssignment dictionary;

[0015] A preset test sequence is invoked to perform diagnostic problem testing. The diagnostic problem testing includes starting message recording, configuring messages and message periods, configuring test files, controlling message loss according to the test files, and stopping message recording.

[0016] Furthermore, the ControlDesk is a tool for recording messages. It receives message recording controller call requests through the COM interface and controls the message recording controller to record messages during the test process.

[0017] A second aspect of the present invention provides an automated testing method for a VCU system, characterized in that: the method includes:

[0018] Step 1: Configure the software and hardware, including writing an automatic diagnostic test module for the Simulink model, compiling the Simulink model and burning it into the rack board of the HIL test cabinet.

[0019] Step 2: Initialize the test sequence, start log recording, and define message control parameters;

[0020] Step 3: Generate an automation configuration file in .stz format to automatically define trial cases;

[0021] Step 4: Send messages via AutomationDesk to simulate a fault and send diagnostic commands;

[0022] Step 5: Call the preset test sequence in AutomationDesk to perform diagnostic problem tests, save the log after the test is completed, and verify the diagnostic function.

[0023] Furthermore, step 2 includes:

[0024] Step 201: AutomationDesk calls the COM interface to control ControlDesk to start the message recording controller and record message logs;

[0025] Step 202: Define the SigAssignment dictionary and obtain the basic parameters for message control;

[0026] Step 203: Define the control variables for the diagnostic command to trigger the diagnostic query.

[0027] Furthermore, step 3, the operation of generating the .stz format automated configuration file, includes:

[0028] Step 301: Create a blank .stz file in AutomationDesk as the input template for the SignalGenerator module of AutomationDesk;

[0029] Step 302: Calculate the message loss time based on the diagnostic strategy;

[0030] Step 303: Add control signals and diagnostic command signals for non-diagnostic messages to the .stz file;

[0031] Step 304: Save the generated .stz file to the specified path.

[0032] Furthermore, step 4 includes:

[0033] Step 401: Import the .stz file into the SignalGenerator module to control the sending and receiving of messages;

[0034] Step 402: Trigger fault scenarios based on test cases to simulate faults;

[0035] Step 403: Send a diagnostic message via AutomationDesk.

[0036] Furthermore, the operation of verifying the diagnostic function in step 5 includes: checking the fault code response, message timing and error events in the log to verify whether the diagnostic strategy meets expectations; and outputting a diagnostic test report containing the fault code status and test results.

[0037] The beneficial effects of this invention are as follows: Besides automatically triggering and reading fault codes, avoiding the hassle of manual operation, AutomationDesk, being software for automated testing, can be extended to enable repeated testing or testing under specific conditions (e.g., sleep / power-on), improving testing efficiency. Compared to directly compiling modules to control the number of message transmission and reception frames or time within the Simulink model, using AutomationDesk to control the number of message transmission and reception frames eliminates the need for model compilation when testing requirements change or when testing under specific conditions. Instead, the test file configuration process can be directly modified, or the .stz file can be directly modified, facilitating flexible testing. Calling AutomationDesk's SignalGenerator module effectively controls message transmission and reception accuracy, ensuring that test control errors are kept within test requirements. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the testing device architecture of the present invention.

[0039] Figure 2 This is the architecture diagram of the Simulink software optimized according to the present invention.

[0040] Figure 3 This is the control sequence diagram of AutomationDesk and ControlDesk in this invention.

[0041] Figure 4 This is a schematic diagram of the configuration .stz test file of this invention. Detailed Implementation

[0042] The present invention will now be described in further detail with reference to the accompanying drawings:

[0043] This invention proposes a solution that does not require additional equipment for diagnostic testing. This solution can utilize the existing dSPACE platform to perform precise control and diagnosis of message transmission and reception. The key point is that it can automatically generate the corresponding configuration file based on only the message or signal, without the need for manual configuration.

[0044] like Figure 1As shown, the testing device of the present invention can be divided into two parts: software and hardware. The hardware part is the HIL test cabinet, and the software part includes Simulink, AutomationDesk, and ControlDesk.

[0045] During the testing process, it is first necessary to write a model in Simulink to send diagnostic commands (i.e., the bench Simulink model) and burn it into the cabinet board of the HIL test cabinet. Then, AutomationDesk is used to control the cabinet board of the HIL test cabinet. The cabinet board sends the simulation of CAN network faults and diagnostic commands to the ECU under test, and at the same time, the message logger of ControlDesk is called to record the corresponding log.

[0046] I. Bench Simulink Model

[0047] like Figure 2 As shown, the Simulink bench model of the present invention includes three parts: an external environment simulation module, a controller simulation module (other controllers in the vehicle besides the ECU under test), and a message transmission and reception control module. The three parts transmit signals to each other and jointly simulate the real vehicle environment.

[0048] The message transmission and reception control module consists of an automatic diagnostic test module and a message transmission and reception module. The automatic diagnostic test module includes units for sending fault code reading commands and fault code clearing commands. By adding the automatic diagnostic test module to the bench Simulink model and loading the commands into the HIL test cabinet, the AutomationDesk and ControlDesk can call this part to send fault code reading commands and fault code clearing commands, controlling the HIL test cabinet to perform tests.

[0049] The steps for running the Simulink model on the test bench of this invention are as follows:

[0050] The first step is to send a fault code reading command. Set the Send_1902 input bit of the Simulink bench model to 1, which triggers the fault code reading command. The model will send the first cycle message through the Rising trigger in the Simulink software, and trigger the 742_Enable bit of the first cycle. This will cause the HIL test cabinet to send a one-cycle 03 19 02 09 00 00 00 00 on the 0x742 message to query the fault codes of the vehicle controller ECU.

[0051] The second step is to send an extended frame to read the fault codes. The decision to send an extended frame is determined by the response command from the controller ECU. If the number of fault codes in the response command is greater than one, an extended frame command is sent to read all fault codes.

[0052] The third step is to send a fault code clearing command to the ECU after all fault codes have been read, clearing all historical fault codes and preparing for the next cycle of testing.

[0053] II. AutomationDesk

[0054] The testing process handled by AutomationDesk can be divided into message loss & recovery testing, checksum error & recovery testing, signal invalid & recovery testing, and RC error & recovery testing. The main difference in their processing logic lies in the different signals configured when configuring messages and message periods. The processing steps for all of them include:

[0055] First, prepare for the test. Before testing, you need to import the Mapping variable through the AutomationDesk variable table. Use the Mapping variable to obtain the correspondence between the message ID, message name, and message period, and save it in a dictionary (SigAssignment dictionary) for later configuration of the test file.

[0056] The test sequence is used to perform diagnostic tests by calling the preset test sequences in AutomationDesk. The basic structure of the test sequence is as follows: Figure 3 As shown, the diagnostic test can be divided into starting message recording, configuring messages and message cycles, configuring test files, controlling message loss according to the test files, and stopping message recording.

[0057] Taking a sequence of lost messages as an example, the workflow is as follows:

[0058] The sequence defines a variable called `SigAsssignment`, a dictionary object used to specify the mapping between message IDs and messages manipulated in AutomationDesk, enabling message control. In addition, all sequences share a common variable `LogFilePath`, which defines the directory for storing log files (hereinafter referred to as log files). The test sequence consists of:

[0059] 1. Start message recording using the message recording controller. This is done by calling the `Logger.start()` function of the message recording controller (Logger) within ControlDesk via the COM interface. Specifically, this involves automatically executing Python code files, including:

[0060] The first step is to import the relevant Python libraries. This step requires using the `Dispatch` command from the `win32com` library to call the ControlDesk COM interface, the `os` library to create and save log files, the `time` library for file naming, and the `mainlibrary` library included with AutomationDesk to control the operation of the software within AutomationDesk.

[0061] Define the function get_current_time_file_name(), which is used to name the log file with the current time when no log file name is specified.

[0062] The second step involves accessing the ControlDesk COM object structure level by level to obtain the handle of the Logger object. The Bus Navigator structure is Application->BusNavigator->Busplatform->Bussystem->PhysicalBusAccess->Loggers. This process is repeated until the corresponding ECAN and PCAN Loggers are accessed.

[0063] The third step is to set the log save path. Before executing the test, a LogFilePath object should be defined in the AutomationDesk sequence, and the save path of the log file on disk should be defined within this object.

[0064] Since setting the log save path must be done when the logs are not activated, first change the activation status of both logs to 0. Then, construct the log file path according to the rule LogFilePath + current time + "_ECAN.asc", and set it as the log save path. Finally, change the log activation status to 1 to start recording.

[0065] Step four: Start recording.

[0066] After message recording is enabled, ControlDesk's message recording component will continuously record the entire test process in the background, recording the time of message loss, the sending of fault code reading commands, and other processes for analyzing test results. Specifically, AutomationDesk triggers a call to ControlDesk to implement the message recording function.

[0067] Fifth, release all local variables that have acquired COM handles to prevent them from occupying memory for an extended period.

[0068] 2. Configure messages and their periodicity. This section configures the SigAssignment dictionary, which maps message IDs to message control variables in AutomationDesk. This step can be performed in parallel with the message recording controller initiating message recording.

[0069] Message loss time control: In Automation Desk, message control is based on time, not frame count. Therefore, the message loss time needs to be determined by multiplying the preset message period by the number of lost frames. The message control variable is "TX_message name".

[0070] The system consists of "_Enable". By using the dictionary that maps message names to their IDs, the control variables for each message can be obtained and controlled.

[0071] In addition to controlling the messages, a control variable for diagnostic commands needs to be added to send diagnostic messages.

[0072] 3. Configure the test file

[0073] The SigAssignment dictionary maps message IDs to message names and generates corresponding configuration files based on the message names. These files are in .stz format. This format, combined with dSPACE's SignalGenerator module, allows for precise time-based control of a variable within the rack model. For example... Figure 4 As shown, configuring the test file involves four steps.

[0074] The first step is to initialize and generate a blank .stz file. This step can be done by calling the module inside AutomationDesk that generates .stz files.

[0075] The second step is to determine the time during testing when to stop sending messages, based on the fault diagnosis strategy and message cycle. Figure 4 The text refers to "message loss time and diagnostic command sending time". The diagnostic strategy in this invention requires that for messages with a period ≤ 50ms, a fault code should be reported after a message loss of 250ms; for messages with a period > 50ms, a fault code should be reported after a message loss of 10 periods. Based on this, the formula for calculating the message loss time can be determined as follows:

[0076] lostTime=0.25+cycleTime (if cycleTime<50ms)

[0077] Alternatively, lostTime = 10 × cycleTime + cycleTime (if cycleTime > 50ms)

[0078] Here, lostTime refers to the time during which the message is lost, and cycleTime is the message cycle.

[0079] After calculating the message loss time (lostTime), a message control variable signal can be configured. This signal should be a square wave with values ​​of 1->0->1 (corresponding to message transmission, pause, and transmission respectively), where the time of 0 corresponds to the calculated lostTime. Simultaneously, the time when message loss ends is recorded, which is used to send a diagnostic message with the timing of the diagnostic command after the message loss ends. Finally, the calculated results are saved to two dictionaries, Configuration and DiagTimeSet, for signal generation in the third step. By modifying the calculation formula for lostTime in the SignalConfiguration.py file, boundary cases such as 4 or 6 cycles of message loss can be easily tested. If other special operating conditions are required in diagnostic testing, corresponding modifications can also be made in this file.

[0080] The third step is to generate all control signals for non-diagnostic instructions based on the above results and add them to a blank .stz file. This step can be done by calling the relevant AutomationDesk library functions.

[0081] The fourth step is to add diagnostic command signals to the .stz file. This step is separated from adding non-diagnostic command signals because a For loop is used during the addition of non-diagnostic commands; this prevents the duplicate addition of diagnostic command signals.

[0082] 4. Control messages are lost according to the test file, i.e., the transmission of control messages is affected.

[0083] Use the SignalGenerator module in AutomationDesk to control message sending and receiving. Import the .stz configuration file generated in the previous step into the SignalGenerator module to precisely control the message sending time. Since the SignalGenerator module cannot pause the sequence execution during message sending, it needs to be used in conjunction with the Sleep module to pause the sequence execution and prevent the final step from prematurely stopping log recording. After sending is complete, the SignalGenerator module needs to be used to release memory.

[0084] 5. Stop message recording

[0085] After the message loss is completed, the diagnostic command is successfully sent, and a response is received from the ECU, the test is complete. The message recording controller stops message recording by calling the Logger.stop() function through the ControlDesk COM interface.

[0086] III. ControlDesk

[0087] In this invention, ControlDesk is used only as a tool for recording messages.

[0088] When ControlDesk's COM interface receives a request to call the message recording controller, the controller is used to record messages during the test.

[0089] This solution utilizes the dSPACE test bench to achieve automated diagnostic testing, the core of which is to reduce manual intervention through software automation.

[0090] The testing method consists of five steps, as follows:

[0091] 1. System preparation: Set up the hardware and software environment.

[0092] Before testing, complete the basic hardware and software configuration. No additional equipment is needed; the dSPACE rack resources can be used directly.

[0093] 1-1. Develop an automated diagnostic testing module in Simulink:

[0094] Write a diagnostic command module in the Simulink model, namely the automatic diagnostic test module, which sends commands to read fault codes and clear fault codes.

[0095] 1-2. Burn the model to the rack board:

[0096] The Simulink model is compiled and burned into the cabinet board of the HIL test cabinet, enabling the test bench to execute diagnostic commands and send the simulation of CAN network faults and diagnostic commands to the ECU under test through the cabinet board.

[0097] 2. Test sequence initialization: Start log recording and configure message control.

[0098] In AutomationDesk, initialize the test sequence, start log recording, and define message control parameters.

[0099] 2-1 Start the message recording controller:

[0100] In the AutomationDesk sequence, the COM interface is called to control the message recording controller of ControlDesk to start recording message logs.

[0101] The specific operations include:

[0102] The first step is to import the Python libraries.

[0103] The second step involves accessing the ControlDesk COM object structure step by step, specifically accessing the Logger object and activating and setting the log storage path (LogFilePath variable).

[0104] The third step is to name the log files with the time (e.g., "current time_ECAN.asc") to ensure uniqueness.

[0105] 2-2 Configure messages and their cycles:

[0106] The first step is to define the SigAssignment dictionary: mapping message IDs to AutomationDesk control variables (such as "TX message name Enable").

[0107] The second step is to obtain basic message control parameters according to the test requirements: for example, the message cycle time is used for subsequent loss time calculation.

[0108] 2-3 Add diagnostic command variables:

[0109] Define control variables for diagnostic commands (such as Send_1902) in the sequence for subsequent triggering of diagnostic queries.

[0110] This stage outputs the activation logs and the configured SigAssignment variables, laying the foundation for test file generation.

[0111] 3. Test file configuration: Generate automated configuration files.

[0112] This stage generates .stz configuration files, enabling the automated definition of test cases.

[0113] 3-1 Initialize the .stz file:

[0114] Create a blank .stz file in AutomationDesk to serve as the input template for the SignalGenerator module.

[0115] 3-2 Calculate and test fault codes:

[0116] Based on the diagnostic strategy, the lost time (lostTime) is calculated. For packets with a period ≤ 50ms, a fault code should be reported after the packet is lost for 250ms; for packets with a period > 50ms, a fault code should be reported after the packet is lost for 10 periods.

[0117] The results are saved to the Configuration and DiagTimeSet dictionaries.

[0118] 3-3 Generate control signals:

[0119] Add control signals for non-diagnostic messages to the .stz file; add diagnostic command signals to the .stz file, such as fault code lookup or clearing commands, and process them separately from non-diagnostic signals to avoid conflicts.

[0120] 3-4 Save the configuration file:

[0121] Save the generated .stz file to the specified path for use by the SignalGenerator module.

[0122] 4. Test execution: Precisely control message sending and fault simulation.

[0123] The AutomationDesk console can be used to send messages, simulate faults, and send diagnostic commands. Time-sensitive operations can be implemented using the SignalGenerator module.

[0124] 4-1 Import the .stz file and start the SignalGenerator module:

[0125] In AutomationDesk, import the .stz file into the SignalGenerator module to control message sending and receiving. The SignalGenerator module precisely controls variables (such as the TX_Enable signal) according to the configuration file to implement message sending, stopping, and resuming.

[0126] 4-2 Simulate network failure:

[0127] Based on the test cases, trigger fault scenarios to simulate faults, for example:

[0128] Simulated message loss: Simulated checksum error: Inject error checksum, set a specified time for stopping message transmission (based on lostTime). During fault simulation, the bench model simulates the fault and sends it to the ECU. The ECU responds with the diagnostic strategy and replies with a fault code.

[0129] 4-3. Send diagnostic command:

[0130] The diagnostic message is sent by calling the bench model through AutomationDesk.

[0131] For example: Inputting Send_1902 and setting it to 1 triggers the fault code reading command (sending a 1902 message); the controller's response determines whether to send an extended frame (e.g., if the VCU fault code is greater than 1). After the test, a clear command is sent to clear the fault codes.

[0132] 4-4 System response data after simulated fault:

[0133] The system response data after simulating a fault is recorded in real time by the message recording controller.

[0134] Furthermore, the Sleep module is used to pause the AutomationDesk sequence to ensure that the SignalGenerator module completes sending, thus preventing the log recording from stopping prematurely in the final step.

[0135] 5. Recording and Analysis: Stop recording and analyze the logs.

[0136] The system calls the preset test sequence in AutomationDesk to perform diagnostic tests. After AutomationDesk completes the test automatically, it stops logging, saves and analyzes the data to verify the diagnostic function.

[0137] 5-1 Stop message recording:

[0138] Within the AutomationDesk sequence, the message recording controller of ControlDesk is invoked via the COM interface. Specifically, the Logger object is accessed, and its activation state is set to 0.

[0139] 5-2. Save the log file:

[0140] Log files (e.g., .asc format) are saved to a predefined path (LogFilePath), and the filename should include a timestamp (e.g., "current time_ECAN.asc").

[0141] 5-3. Analyze log data:

[0142] Check the fault code responses, message timings, and error events in the logs to verify that the diagnostic strategy is in line with expectations (e.g., does a fault code be triggered if a message is lost for 250ms).

[0143] The final output is a diagnostic test report containing fault code status and test results.

[0144] The above technical solution is only one embodiment of the present invention. For those skilled in the art, based on the principles disclosed in the present invention, it is easy to make various types of improvements or modifications, and not limited to the technical solutions described in the specific embodiments of the present invention. Therefore, the foregoing description is only a preferred option and is not restrictive.

Claims

1. An automated testing device for a VCU system, comprising software and hardware, wherein the hardware is a HIL test cabinet, and the software includes Simulink, AutomationDesk, and ControlDesk, characterized in that: The Simulink is used to write the bench Simulink model; the bench Simulink model is burned into the cabinet board of the HIL test cabinet; the AutomationDesk is used to control the cabinet board of the HIL test cabinet, send the CAN network faults and diagnostic commands simulated by the bench Simulink model to the ECU under test; and call the message logger of the ControlDesk to record the corresponding logs.

2. The automated testing device for the VCU system according to claim 1, characterized in that: The Simulink model of the test bench includes: an external environment simulation module, a controller simulation module, and a message transmission and reception control module; The message transmission and reception control module consists of an automatic diagnostic testing module and a message transmission and reception module. The automatic diagnostic test module includes a unit for sending fault code reading instructions and a unit for sending fault code clearing instructions, used to load instructions into the cabinet boards of the HIL test cabinet and send fault code reading instructions and fault code clearing instructions.

3. The automated testing device for the VCU system according to claim 2, characterized in that: The Simulink model of the test bench performs the following operations: The first step is to send a fault code reading command for one cycle to query the relevant fault codes of the ECU under test; The second step is to send extended frames and read fault codes. The third step is to send a fault code clearing command to the ECU after the fault codes are read, clearing all historical fault codes.

4. The automated testing device for the VCU system according to claim 3, characterized in that: The AutomationDesk performs the following operations: Import Mapping variables through the variable table, obtain the correspondence between message ID, message name, and message period through the Mapping variables, and store it in the SigAssignment dictionary; A preset test sequence is invoked to perform diagnostic problem testing. The diagnostic problem testing includes starting message recording, configuring messages and message periods, configuring test files, controlling message loss according to the test files, and stopping message recording.

5. The automated testing device for the VCU system according to claim 4, characterized in that: The ControlDesk is a tool for recording messages. It receives message recording controller call requests through the COM interface and controls the message recording controller to record messages during the test process.

6. An automated testing method for a VCU system, characterized in that: The method includes: Step 1: Configure the software and hardware, including writing an automatic diagnostic test module for the Simulink model, compiling the Simulink model and burning it into the rack board of the HIL test cabinet. Step 2: Initialize the test sequence, start log recording, and define message control parameters; Step 3: Generate an automation configuration file in .stz format to automatically define trial cases; Step 4: Send messages via AutomationDesk to simulate a fault and send diagnostic commands; Step 5: Call the preset test sequence in AutomationDesk to perform diagnostic problem tests, save the log after the test is completed, and verify the diagnostic function.

7. The automated testing method for the VCU system according to claim 6, characterized in that: Step 2 includes: Step 201: AutomationDesk calls the COM interface to control ControlDesk to start the message recording controller and record message logs; Step 202: Define the SigAssignment dictionary and obtain the basic parameters for message control; Step 203: Define the control variables for the diagnostic command to trigger the diagnostic query.

8. The automated testing method for the VCU system according to claim 7, characterized in that: The step 3, generating the .stz format automated configuration file, includes: Step 301: Create a blank .stz file in AutomationDesk as the input template for the SignalGenerator module of AutomationDesk; Step 302: Calculate the message loss time based on the diagnostic strategy; Step 303: Add control signals and diagnostic command signals for non-diagnostic messages to the .stz file; Step 304: Save the generated .stz file to the specified path.

9. The automated testing method for the VCU system according to claim 8, characterized in that: Step 4 includes: Step 401: Import the .stz file into the SignalGenerator module to control the sending and receiving of messages; Step 402: Trigger fault scenarios based on test cases to simulate faults; Step 403: Send a diagnostic message via AutomationDesk.

10. The automated testing method for the VCU system according to claim 9, characterized in that: The verification and diagnostic function operation in step 5 includes: checking the fault code response, message timing and error events in the log to verify whether the diagnostic strategy meets expectations; and outputting a diagnostic test report containing the fault code status and test results.

Images