Automated testing method and system for on-board electronic control unit

Abstract

The application provides an automatic test method and system for an on-vehicle electronic control unit, wherein the test method comprises: a client obtaining test data of a test case, and performing reading and analysis processing to obtain corresponding test signals and sequentially send the test signals to a server; the server performs analysis processing on the test signals to obtain analysis signals, and transmits the analysis signals to corresponding to-be-tested electronic control units according to receiving nodes; the to-be-tested electronic control units generate corresponding feedback signals according to the analysis signals, and return the feedback signals to the server; the server performs secondary analysis processing on the feedback signals to obtain corresponding return signal values, and transmits the return signal values to the client; the client compares the return signal values with corresponding expected response values to obtain result data of the test case, and outputs a test report. The automatic test method and system provided by the application simplify the steps of the diagnostic automatic test method, and reduce the cost of the automobile automatic test system.

Description

Technical Field

[0001] This invention belongs to the field of automotive automated testing, and specifically relates to an automated testing method for an on-board electronic control unit and a system for executing the automated testing method. Background Technology

[0002] During vehicle development, the development, diagnosis, and testing of the Electronic Control Unit (ECU) is a crucial step. Traditional manual testing methods require staff to manually connect the ECU's ports using testing tools to perform step-by-step testing of each item under test. This process is cumbersome and inefficient.

[0003] Existing technologies also employ automated testing components developed by different companies, achieving automated testing through relay control, ECU connection, and data input / output. However, these automated testing components require multiple test simulation modules to simulate various test signals, resulting in high testing system costs and complex test control processes. Summary of the Invention

[0004] The purpose of this invention is to solve the problems of complex processes and high costs associated with existing automated testing methods for vehicle-mounted electronic control units (ECUs). This invention provides an automated testing method and system for ECUs, which simulates load and completes automated testing through communication between a client and a server.

[0005] To address the above problems, this invention discloses an automated testing method for vehicle-mounted electronic control units, comprising:

[0006] S1: The client obtains the test data of the test case. The test data of the test case includes at least one test step and the corresponding signal value and expected response value for each test step.

[0007] S2: The client reads and parses the signal values ​​corresponding to each test step of the test case to obtain the corresponding test signals. The test signals include message information, receiving node information, and execution order information. The client sends the test signals to the server in sequence according to the execution order information in the test signals.

[0008] S3: The server processes the received test signals sequentially according to the receiving order to obtain at least one parsed signal, and transmits the parsed signal to the corresponding electronic control unit under test according to the receiving node information in each test signal. The parsed signal includes the parsed message information.

[0009] S4: The electronic control unit under test performs logical processing on the parsed message information in each received parsed signal and generates a corresponding feedback signal, and then sends the feedback signal back to the server;

[0010] S5: The server performs secondary parsing on the feedback signal to obtain the corresponding return signal value, and transmits the return signal value to the client, where the return signal value includes the actual response value;

[0011] S6: The client compares the actual response value in the received return signal value with the corresponding expected response value, obtains the test case result data based on the comparison result, and outputs a test report based on the result data.

[0012] By adopting the above technical solution, the automotive automated testing method provided by the present invention redefines the signal values ​​and semaphores of test cases through test cases, realizes load simulation through communication between the client and the server, completes the automated testing of the vehicle electronic control unit, simplifies the automated testing method steps, and eliminates the need for a test simulation module, thereby reducing the cost of the automotive automated testing system.

[0013] According to another specific embodiment of the present invention, the automated testing method disclosed in the present invention, when there are multiple test cases, each test signal further includes a test process signal, which is one of a test case start signal, a step process signal, a test case end signal, and a test end signal; and step S6 further includes:

[0014] The client also enables real-time monitoring. After receiving each returned signal value, it monitors the test process signal type contained in the returned signal value in real time and determines the subsequent processing steps based on the test process signal type. If the test process signal is a test case start signal, it iterates through the test steps of the corresponding test case and enters the test process of the test step of the test case. If the test process signal is a test case end signal, it ends the test steps of the corresponding test case and enters the test steps of the next test case or the test end step. If the test process signal is a test end signal, it turns off real-time monitoring, outputs the final test report, and ends all test processes.

[0015] According to another specific embodiment of the present invention, the automated testing method disclosed in this embodiment further includes step S3: the server reads the test process signal in the test signal and performs operations according to the type of the test process signal; wherein if the test process signal in the test signal is a step process signal, the server determines the execution type information in the test process signal, and the execution type information includes program control signal, security access signal and ordinary diagnostic step signal.

[0016] Furthermore, if the server determines that the execution type information is a program-controlled signal, the server generates a parsing signal including program-controlled instructions and sends the parsing signal to the control unit under test through the program-controlled device; if the server determines that the execution type information is a secure access signal, the server generates a parsing signal including a request seed signal and sends it to the control unit under test, and after obtaining the returned seed, the server calculates the key using the seed; the server then sends the key to the control unit under test for verification, and performs subsequent operations after the verification is successful; if the server determines that the execution type information is a normal diagnostic step signal, the server generates a parsing signal including extracting parameters from the execution type information and assembling them to obtain a diagnostic test message, and sends the diagnostic test message to the control unit under test.

[0017] Furthermore, if the test process signal in the test signal is any one of the test case start signal, test case end signal, and test end signal, the server generates a parsed signal including the system initialization signal and performs system initialization operations.

[0018] According to another specific embodiment of the present invention, the automated testing method disclosed in this embodiment of the present invention, when the execution type information is a normal diagnostic step type signal, after the server obtains the diagnostic test message, it determines whether the diagnostic test message is a periodic message; if so, the server periodically sends the diagnostic test message at regular intervals.

[0019] According to another specific embodiment of the present invention, the automated testing method disclosed in this embodiment includes a programmable power supply and at least one programmable relay in the programmable device; wherein the programmable relay in the programmable device controls the disconnection and connection of the circuit of the electrical control unit under test according to the control command; and the programmable power supply in the programmable device controls the voltage and current changes of the electrical control unit under test according to the control command.

[0020] According to another specific embodiment of the present invention, the automated testing method disclosed in this embodiment includes a test rule identifier, a transmission semaphore, an execution cycle, an execution step, and a return semaphore for the transmission signal value of the test data of each test case; each test signal also includes execution cycle information, special step information, initialization information, and sleep information.

[0021] According to another specific embodiment of the present invention, the automated testing method disclosed in this embodiment of the present invention includes reading and parsing the sent signal values ​​by the client, which includes: reading the sent signal values ​​of multiple test cases in a preset Excel file, converting them into JSON format data, and storing the data.

[0022] According to another specific embodiment of the present invention, the automated testing method disclosed in this embodiment transmits test signals and return signal values ​​via socket format.

[0023] The present invention discloses an automated testing system for an on-board electronic control unit, used to execute the automated testing method provided by the present invention.

[0024] The automated testing system comprises a client, a server, and a device under test (DUT) connected in sequence. The client acquires test data from test cases, reads and parses the transmitted signal values ​​from the test data, generates test signals, and sends these test signals to the server. The server parses the test signals and generates parsed signals, which are then transmitted to the DUT. The DUT receives the parsed signals, generates corresponding feedback signals, and transmits these feedback signals to the server. The server performs a second parsing of the feedback signals to obtain return signal values, which are then transmitted to the client. The client obtains the test case result data based on the return signal values ​​and outputs a test report accordingly.

[0025] According to another specific embodiment of the present invention, the automated testing system disclosed in this embodiment further includes a programmable control device, which is connected to a server and the electronic control unit under test. The server transmits the analytical signal to the programmable control device, and the programmable control device transmits the analytical signal to the electronic control unit under test.

[0026] According to another specific embodiment of the present invention, the automated testing system disclosed in this embodiment includes a programmable power supply and at least one programmable relay. The programmable relay is used to control the disconnection and connection of the circuit of the electronic control unit under test (ECU) according to the analytical signal. The programmable power supply is used to control the voltage and current changes of the ECU according to the analytical signal. When multiple programmable relays are included, each programmable relay is connected to a different ECU under test. The server also includes a control module, and multiple programmable relays are connected to the control module. The control module is equipped with a switch corresponding to each programmable relay for controlling the opening and closing of each programmable relay.

[0027] According to another specific embodiment of the present invention, the automated testing system disclosed in this embodiment further includes a timer. When the server receives a test signal that is a normal diagnostic step signal, the server extracts parameters from the execution step information and assembles them to obtain a diagnostic test message. Furthermore, when the diagnostic test message is a periodic message, the timer is started to enable the server to periodically send the diagnostic test message at regular intervals, and the timer is turned off after the execution is completed.

[0028] According to another specific embodiment of the present invention, the automated testing system disclosed in this embodiment of the present invention has a module for automated testing methods executed by the client developed based on Python + QT, and a module for automated testing methods executed by the server built using CANoe and developed based on the CAPL language.

[0029] The beneficial effects of this invention are:

[0030] The automated testing method and system for vehicle ECUs provided by this invention redefines the signal values ​​and semaphores of test cases through test cases, simulates the load through communication between the client and server, and achieves automated data input and output testing through signal transmission between the server and the ECU under test, forming a closed-loop automated testing system and process. It can realize protocol diagnosis and business logic diagnosis of automotive ECUs, supporting both physical addressing and functional addressing diagnostic methods. Furthermore, during the testing process, only test cases need to be retrieved; the testing system will automatically run the entire test process and output a test report, simplifying the automated testing method and making it easy to operate. Practical verification shows that it has fast testing speed and high stability, significantly improving the efficiency and coverage of diagnostic testing. Moreover, the automated testing system of this invention does not require a simulation module, reducing the cost of the testing system. Attached Figure Description

[0031] Figure 1 This is a structural block diagram of the automated testing system for vehicle-mounted electronic control units provided by the present invention;

[0032] Figures 2-8 The diagrams show the circuits of seven different programmable relays connected to different ECUs under test in the automated testing system for vehicle electronic control units provided by this invention.

[0033] Figure 9 The control panel is installed on the control module of the server in the automated testing system for the vehicle-mounted electronic control unit provided by this invention;

[0034] Figure 10 A flowchart of the automated testing method for vehicle-mounted electronic control units provided by the present invention;

[0035] Figure 11 The automated testing method for the vehicle electronic control unit provided by this invention includes multiple test cases and test reports in a preset Excel file;

[0036] Figure 12 In the automated testing method for vehicle-mounted electronic control units provided by this invention, the client reads a test case from an Excel file and converts it into JSON format data;

[0037] Figure 13 The flowchart shows the process of automatically traversing and executing multiple test cases in the automated testing method for vehicle electronic control units provided by this invention.

[0038] Figure 14 The flowchart shows the processing of test signals received by the server in the automated testing method for the vehicle-mounted electronic control unit provided by the present invention.

[0039] Explanation of reference numerals in the attached figures:

[0040] 10: Client; 20: Server; 30: Electrical control unit under test; 40: Programmable control equipment. Detailed Implementation

[0041] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Although the description of the present invention is presented in conjunction with preferred embodiments, this does not mean that the features of the invention are limited to these embodiments. On the contrary, the purpose of describing the invention in conjunction with embodiments is to cover other options or modifications that may be derived based on the claims of the present invention. To provide a deep understanding of the invention, many specific details will be included in the following description. The invention may also be implemented without using these details. Furthermore, to avoid confusion or obscuring the focus of the invention, some specific details will be omitted in the description. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0042] It should be noted that in this specification, similar reference numerals and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0043] In the description of this embodiment, it should be noted that the terms "upper", "lower", "inner", "bottom", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship that the product of the invention is usually placed in during use. They are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting the present invention.

[0044] The terms “first”, “second”, etc., are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0045] In the description of this embodiment, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set up," "connected," and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this embodiment based on the specific circumstances.

[0046] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0047] To address the issues of complex processes and high costs associated with existing automated testing methods for vehicle-mounted electronic control units (ECUs), an automated testing method for ECUs and a system for executing this method are provided, as detailed below.

[0048] Example 1

[0049] This invention provides an automated testing system for vehicle-mounted electronic control units, such as... Figure 1 As shown, the automated testing system includes a client 10, a server 20, and an electrical control unit under test 30, which are connected in sequence via communication.

[0050] The client 10 is used to acquire test data for test cases, read and parse the transmitted signal values ​​in the test data, generate test signals, and send the test signals to the server 20. The server 20 is used to parse the test signals and generate parsed signals, and transmit the parsed signals to the electronic control unit under test (ECU) 30. The ECU 30 receives the parsed signals and generates corresponding feedback signals, and transmits the feedback signals to the server 20. The server 20 performs secondary parsing of the feedback signals to obtain return signal values, and transmits the return signal values ​​to the client 10. The client 10 obtains the test case result data based on the return signal values, and outputs a test report based on the result data.

[0051] More specifically, the client 10 can be a computer with an automated testing module that executes automated testing methods. In one specific embodiment, the automated testing module is developed based on Python + QT. The server 20 can also be a computer with a signal transceiver module that executes automated testing methods. In one specific embodiment, the signal transceiver module is built using CANoe and developed based on the CAPL language. The electronic control unit (ECU) under test 30 includes a vehicle infotainment system and related peripheral accessories, wherein the vehicle infotainment system and related peripheral accessories are interconnected to perform logical processing on the received and analyzed signals to generate corresponding feedback signals. The vehicle infotainment system specifically includes an entertainment head unit, instrument cluster, etc., and peripheral accessories include a steering wheel controller, speakers, microphones, cameras, antennas, etc. In one specific embodiment, the client 10 and the server 20 are connected via Socket communication, and the server 20 and the ECU under test 30 are connected via CAN bus communication.

[0052] According to another specific embodiment of the present invention, such as Figure 1As shown, the automated testing system also includes a programmable controller 40, which is connected to both the server 20 and the ECU under test 30. The server 20 transmits the analyzed signals to the programmable controller 40, which in turn transmits the analyzed signals to the ECU under test 30. In one specific embodiment, the server 20 and the programmable controller 40 communicate via an RS232 serial interface.

[0053] Furthermore, the programmable device 40 includes a programmable power supply (DC power supply) and at least one programmable relay; the programmable relay is used to control the disconnection and connection of the circuit of the electrical control unit 30 under test according to the analytical signal; the programmable power supply is used to control the voltage change of the electrical control unit 30 under test according to the analytical signal.

[0054] Furthermore, when there are multiple programmable relays, each programmable relay is connected to a different ECU under test 30. Specifically, in one embodiment, there are seven programmable relays, each connected to a different ECU under test 30. Figures 2-8 The circuit diagrams show the connections of seven different programmable relays to different ECUs under test (ECUs 30). Figure 2 This is a circuit diagram showing the connection between the programmable relay 1 and the front right-side speaker (SPKFR) and the radio antenna (TUNER). Figure 3 This is a circuit diagram showing the connection between the programmable relay 2 and the front left horn (SPKFL) and the reversing camera (RVC). Figure 4 This is a circuit diagram showing the connection between the programmable relay 3 and the left-side direction control (WHEELL), right-side direction control (WHEELR), and microphones (MIC1 and MIC2). Figure 5 This is a circuit diagram showing the connection between the programmable relay 4, the front left horn (SPKFL), and the USB ports (USB1 and USB2). Figure 6 This is a circuit diagram showing the connection between the programmable relay 5 and the front right horn (SPKFR) and the reversing camera (RVC). Figure 7 This is a circuit diagram showing the connection between the programmable relay 6 and the 360-degree right-side camera (RIGCAM) and the 360-degree front-view camera (FRTCAM). Figure 8 This is a circuit diagram showing the connection between the programmable relay 7 and the 4G main antenna (4G-Main), 4G auxiliary antenna (4G-Aux), and GPS antenna (GPS). The seven programmable relays control and adjust the voltage of each ECU under test (ECU 30), which can basically meet all test conditions.

[0055] Server 20 also includes a control module, with multiple programmable relays connected to it. The control module has a switch for each programmable relay, used to control the opening and closing of each relay. Specifically, for example... Figure 9As shown, the control module of server 20 is equipped with a control panel displayed on the display device. By operating the control panel, the connection and disconnection of each circuit of the programmable relay can be manually controlled. The control module can achieve both automatic and manual control of the programmable relays to check whether each programmable relay circuit can be opened and closed normally.

[0056] According to another specific embodiment of the present invention, the server 20 of the automated testing system further includes a timer. When the server 20 receives a test signal that is a normal diagnostic step signal, the server 20 extracts parameters from the execution step information and assembles them to obtain a diagnostic test message. When the diagnostic test message is a periodic message, the timer is started to make the server 20 periodically send the diagnostic test message at regular intervals, and the timer is turned off after the execution is completed.

[0057] Example 2

[0058] This invention also provides an automated testing method for vehicle-mounted electronic control units, executed by the automated testing system provided in Example 1. Wherein, as Figure 10 As shown, the automated testing method includes the following steps:

[0059] S1: The client obtains the test data of the test case. The test data of the test case includes at least one test step and the corresponding signal value and expected response value for each test step.

[0060] S2: The client reads and parses the signal values ​​corresponding to each test step of the test case to obtain the corresponding test signals. Each test signal includes message information, receiving node information, and execution order information. The client sends the test signals to the server in sequence according to the execution order information in the test signals.

[0061] S3: The server processes the received test signals sequentially according to the receiving order to obtain at least one parsed signal, and transmits the parsed signal to the corresponding electronic control unit under test according to the receiving node information in each test signal. The parsed signal includes the parsed message information.

[0062] S4: The electronic control unit under test performs logical processing on the parsed message information in each received parsed signal and generates a corresponding feedback signal, and then sends the feedback signal back to the server;

[0063] S5: The server performs secondary parsing on the feedback signal to obtain the corresponding return signal value, and transmits the return signal value to the client, where the return signal value includes the actual response value;

[0064] S6: The client compares the actual response value in the received return signal value with the corresponding expected response value, obtains the test case result data based on the comparison result, and outputs a test report based on the result data.

[0065] Of the steps described above, steps S1, S2, and S6 are executed by the client. Figure 10 The steps on the left side of the page; steps S3 and S5 are executed by the server, i.e. Figure 10 The middle part of the steps; step S4 is executed by the electronic control unit under test, that is Figure 10 The steps are shown on the right side. To make the explanation clearer, the following sections provide specific details on the automated testing methods for different execution devices within the system.

[0066] For the client, a test case library is constructed by redefining signal values ​​and semaphores according to certain logic based on the test requirements and characteristics of the ECU under test. In step S1, the client's automated testing module retrieves the test data of the test cases from the test case library. It should be noted that a test case includes test data and result data. The test data is the part sent to the ECU under test for testing, and the result data is the test result. There can be multiple test cases. The test data of each test case includes at least one test step and the corresponding sent signal value and expected response value for each test step. In one specific embodiment, the sent signal value of the test data for each test case includes a test rule identifier, sent semaphore, execution cycle, execution step, and return semaphore. In one specific embodiment, the test cases are stored in a preset Excel file, specifically as follows: Figure 11 As shown in the table below, multiple test cases are displayed in a preset Excel file. In the first row, TestID is the test rule identifier, CANID is the sent semaphore, Cycletime is the execution cycle, TestStep is the execution step, and RespID is the return semaphore. These are the sent semaphore values. ExpectedResp in the first row is the expected response value. Of course, the test data also includes the test rule description (TestItem in the first row).

[0067] In step S2, a submodule of the client's automated testing module reads and parses the sent signal values ​​corresponding to each test step of the test case to obtain the corresponding test signal; wherein, the test signal includes message information, receiving node information, and execution order information. In one specific embodiment, reading and parsing the sent signal values ​​includes: traversing and reading the sent signal values ​​of multiple test cases in a preset Excel file, parsing and converting them into JSON format data, and storing the data in a structure; wherein, for example... Figure 12The diagram illustrates how a client reads a test case from an Excel file and converts it into JSON format. More specifically, using the aforementioned test case in a pre-defined Excel file as an example, the execution order information can be obtained by parsing the order in which the Excel file is read and the execution steps. Based on this order, test signals corresponding to each test step are then sent to the server sequentially. In one specific implementation, the test signals are transmitted via socket format. This format enables the client to maintain a stable and continuous connection with the server, achieving directed bidirectional communication. By parsing the sent semaphores and execution steps, the receiving node information of the test signals can be obtained; by parsing the sent signal values, the message information can be obtained.

[0068] In step S6, the client receives the return signal value sent back by the server and compares the actual response value with the corresponding expected response value. It should be noted that the client-side automated testing module can also parse the expected response value simultaneously in step S2, and upon receiving the actual response value, automatically compare the results to obtain the comparison results, and then obtain the test case result data based on the comparison results; alternatively, comparison results can be obtained through other methods, such as manual comparison. Furthermore, after obtaining the result data, the result data and test data are assembled into complete test cases. Following the above method, hundreds or even thousands of test cases can be automatically assembled; among them... Figure 11 The lower table shows the complete assembled test cases, and the upper table shows the output test report.

[0069] In a specific real-time mode, each test signal also includes execution cycle information, special step information, initialization information, and sleep information. For example, in step S2, the format of a single test signal sent by the client can be as follows:

[0070] {RowNum:33,CANID:0x761,CycleTime:0,TestStep:021003,RespID:0x769,IsSpecialStep:0,IsInitStep:0,SleepAfterSend:0}&&;

[0071] RowNum represents the row number, reflecting the execution order information; CANID represents the receiving node information; CycleTime represents the execution cycle information; IsSpecialStep represents special step information to determine whether it is a special step; IsInitStep represents initialization information to determine whether initialization is required; and SleepAfterSend represents sleep information to determine whether sleep is needed.

[0072] In step S6, the client receives the return signal value sent back by the server, which can be in the following format:

[0073] {RowNum:33,CANID:0x761,CycleTime:0,TestStep:021003,RespID:0x769,IsSpecialStep:0,IsInitStep:0,SleepAfterSend:200}{065003003201F4AA}&&;where 065003003201F4AA is the actual response value.

[0074] According to another specific embodiment of the present invention, when there are multiple test cases, in order to ensure that the client receives all return signal values ​​from the server, to better perform testing in the execution order, and to improve the efficiency of diagnostic testing, a separate subprocess is started on the client for real-time monitoring of the server's return signal values. Specifically, to facilitate real-time monitoring of the testing process, during the parsing process, a test signal indicating the start and end of a test case is inserted before the start and end of the transmission of test signals corresponding to all test steps of each test case, respectively; and a test signal indicating the end of the test is inserted after all test cases have been executed. Therefore, based on the position and type of the test signal, each test signal also includes a test process signal, which is one of the following: test case start signal, step process signal, test case end signal, and test end signal.

[0075] Furthermore, step S6 also includes the client listening in real time to the test process signal type contained in each returned signal value after receiving it, and determining the subsequent processing steps based on the test process signal type. Specifically, if the test process signal is a test case start signal, the client iterates through the test steps of the corresponding test case and enters the test process of the test step of the test case; if the test process signal is a test case end signal, the client ends the test steps of the corresponding test case and enters the test steps of the next test case or the test end step; if the test process signal is a test end signal, the client turns off real-time listening and outputs the final test report, ending all test processes.

[0076] Specifically, on the client side, when there are multiple test steps or multiple test cases, steps S2 to S6 are not performed linearly, but rather in a partially cyclical manner. Step S2, based on the test process signal types contained in the return signal values ​​monitored in real-time by step S6, sends the next required test signals to the server in sequence; and once all tests are confirmed to be complete, the sending ends, and step S6 outputs a test report. This method achieves automatic traversal and execution of all test cases.

[0077] More specifically, the processing flow when the client automatically iterates through and executes multiple test cases is as follows: Figure 13As shown, firstly, real-time monitoring is enabled. All test cases are iterated through to determine the first test case, whose corresponding test process signal is the test signal for the test case start signal. This test signal is then sent. Upon receiving the return signal value, the test steps of the corresponding individual test case are iterated through to determine the first test step. The test process signal for this test step is then sent, and real-time monitoring continues to check for a return signal value. If no return signal value is received, monitoring continues. If a return signal value is received, the actual response value for that test step is compared with the corresponding expected response value. The system obtains the comparison result of the test step and determines whether the test of the corresponding individual test case has ended. If it has not ended, it continues to traverse the test steps of the corresponding individual test case, determines the next test step of the test case, and sends the test process signal corresponding to the test step as the test process signal. If it has ended, it sends the test process signal of the test case as the test case end signal. At the same time, the client merges and processes the results of each step in the test case, writes the results of each test step and the execution result of the individual test case into the test report file, and ends the test step of the corresponding test case after receiving the corresponding return signal value. It also continues to determine whether the overall test result of multiple test cases has ended. If it has not ended, it traverses all test cases, determines the next test case, and performs subsequent test steps. If it has ended, it sends the test process signal as the test end signal, and after receiving the return signal value, it closes real-time listening and outputs the final test report, ending all test processes. It should be noted that after sending the test case start signal corresponding to an individual test case, it can also determine whether a delay is needed. If a delay is needed, the test signal corresponding to the test step is sent after a specified sleep duration.

[0078] It's important to note that the acquired test cases typically number in the hundreds or thousands, forming several lists. Automatically traversing and executing all test cases requires reading and parsing all test cases, sending test signals, and then receiving and evaluating the returned signal values. Automatically traversing and executing a single test case refers to traversing and executing all test steps of that single test case, such as... Figure 11 In the Excel file shown, Diag_Attest_01 is a test case with three test steps. Therefore, it's necessary to iterate through these three test steps. For each test step, a test signal needs to be sent, the return signal value received, and the result evaluated. After all steps of one test case have been executed, the next test case will be executed automatically. This process repeats until all test cases have been executed.

[0079] For the server, in step S3, when the signal transceiver module is built using CANoe and developed based on the CAPL language, the server uses CAPL to parse the received test signal into a signal that CANoe can recognize, and then sends it to the ECU under test after splicing it through CANoe.

[0080] According to another specific embodiment of the present invention, step S3 further includes: the server reads the test process signal in the test signal and performs operations according to the type of the test process signal.

[0081] Figure 14 The flowchart shows the process of the server receiving a test signal. Figure 14 As shown, if the test process signal in the test signal is a step process signal, the server determines the execution type information in the test process signal. The execution type information includes program control signals, security access signals, and ordinary diagnostic step signals.

[0082] Furthermore, if the server determines that the execution type information is a program-controlled signal, the server generates a parsing signal including program-controlled instructions and sends the parsing signal to the control unit under test through the program-controlled device; if the server determines that the execution type information is a secure access signal, the server generates a parsing signal including a request seed signal and sends it to the control unit under test, and after receiving the returned seed, the server calculates and verifies the key using the seed; the server then sends the key to the control unit under test for verification, and performs subsequent operations after the verification is successful; if the server determines that the execution type information is a normal diagnostic step signal, the server generates a parsing signal including extracting parameters from the execution type information and assembling them to obtain a diagnostic test message, and sends the diagnostic test message to the control unit under test.

[0083] Furthermore, if the test process signal in the test signal is any one of the test case start signal, test case end signal, and test end signal, the server generates a parsed signal including system initialization signals and performs system initialization operations, specifically including: resetting the relay circuit, restoring the default voltage and current, canceling the timer, and disabling secure access.

[0084] And as Figure 14 As shown, the order for determining the type of test process signals is as follows: first, determine whether it is any one of the test case start signal, test case end signal, and test end signal; then, determine the execution type information, in turn, whether it is a program control signal or a security access signal; if it is neither, it is determined to be a normal diagnostic step signal; and then perform the operation according to the determination result.

[0085] Furthermore, when the execution type information is a normal diagnostic step signal, after the server receives the diagnostic test message, it also determines whether the diagnostic test message is a periodic message; if so, it starts a timer to make the server periodically send diagnostic test messages; if not, it sends a single frame diagnostic test message and receives a single frame feedback signal; and further determines whether it is a multi-frame transmission; if so, the server receives feedback signals for multiple consecutive frames and sends return signal values ​​for multiple consecutive frames; if not, the server sends return signal values ​​together.

[0086] Furthermore, the programmable device includes a programmable power supply and at least one programmable relay; wherein the programmable relay in the programmable device controls the disconnection and connection of the circuit of the electronic control unit under test according to the control command, and is used to test various scenarios; the programmable power supply in the programmable device controls the voltage and current changes of the electronic control unit under test according to the control command, so as to regulate the voltage and current through the server and provide it to the vehicle machine.

[0087] Furthermore, in the automated testing system of Example 1, when multiple programmable relays are included, each programmable relay is connected to a different electronic control unit under test; and when it is also connected to the control module of the server, the specific steps of the method for controlling the relay switch through the control module include: Figure 9 As shown, first select the desired programmable relay ID in the control panel, i.e., configure the IP address and port number, and click the "start listening" button to prepare for receiving diagnostic test cases. Then configure the serial port of the programmable relay and click the "set" button to enable serial communication. Use the corresponding control buttons on the control panel to control each switch. For example, clicking the first switch button to open line one sends an "open first switch" command (FE 05 00 00 FF 00 98 35) to the programmable relay. Clicking the first switch button again to close line one sends a corresponding "close line one" command (FE 05 00 00 00 00 D9 C5) to the relay. Continue this process until multiple lines are controlled, checking whether each programmable relay line can be opened and closed normally.

[0088] Specifically, the differences between the three execution types of information are based on the message information of the test signals, which is reflected in the test cases, as follows: Figure 11 As shown, they are distinguished according to TestItem, CANIC, TestStep, etc. Among them, in test case Diag_Attest_07, the step of adjusting the voltage is a programmable signal, specifically controlling the power supply; and in Diag_Attest_08, the connection line 1, disconnect line 2, etc. are programmable signals, specifically relay control steps, used to test whether the signals fed back by the ECU under test are correct under different power supply or relay states.

[0089] The 27 service diagnostic test step in test case Diag_Attest_02 belongs to the security access signal category. It needs to be decrypted first, and then the signal fed back by the ECU under test needs to be judged to see if it is correct.

[0090] Other steps are considered ordinary diagnostic steps, such as multi-message single-frame test, multi-frame reception test, and diagnostic test. When encountering such steps, the data in the TestStep column is directly read out, assembled into a diagnostic test message, and sent. Then, it is determined whether the signal fed back from the ECU under test is consistent with the expected return value.

[0091] The automated testing method and system for vehicle ECUs provided by this invention redefines the signal values ​​and semaphores of test cases through test cases, simulates the load through communication between the client and server, and achieves automated data input and output testing through signal transmission between the server and the ECU under test, forming a closed-loop automated testing system and process. It can realize protocol diagnosis and business logic diagnosis of automotive ECUs, supporting both physical addressing and functional addressing diagnostic methods. Furthermore, during the testing process, only test cases need to be retrieved; the testing system will automatically run the entire test process and output a test report, simplifying the automated testing method and making it easy to operate. Practical verification shows that it has fast testing speed and high stability, significantly improving the efficiency and coverage of diagnostic testing. Moreover, the automated testing system of this invention does not require a simulation module, reducing the cost of the testing system.

[0092] Furthermore, this invention also provides a connection scheme for programmable relays, which can be used for the connection control of each ECU under test and the peripheral devices involved in each ECU. Using programmable relays to automatically control the connection and disconnection of vehicle-mounted equipment circuits such as audio systems, microphones, 360-degree cameras, antennas, instruments, and steering controls eliminates the need for manual intervention, significantly improving testing efficiency.

[0093] While the present invention has been illustrated and described with reference to certain preferred embodiments, those skilled in the art should understand that the above description is a further detailed explanation of the invention in conjunction with specific embodiments, and should not be construed as limiting the specific implementation of the invention to these descriptions. Various changes in form and detail can be made by those skilled in the art, including several simple deductions or substitutions, without departing from the spirit and scope of the invention.

Claims

1. An automated testing method for an on-board electronic control unit, characterized in that, include: S1: The client obtains the test data of the test case, wherein the test data of the test case includes at least one test step and the sent signal value and expected response value corresponding to each test step; S2: The client reads and parses the sent signal value corresponding to each test step of the test case to obtain the corresponding test signal. The test signal includes message information, receiving node information, and execution order information. When there are multiple test cases, each test signal also includes a test process signal, which is one of the following: test case start signal, step process signal, test case end signal, and test end signal. The client sends the test signals to the server sequentially according to the execution order information in the test signals. S3: The server sequentially parses the received test signals according to the receiving order to obtain at least one parsed signal, and transmits the parsed signal to the corresponding electronic control unit under test according to the receiving node information in each test signal. The parsed signal includes parsed message information. The server reads the test process signal from the test signals and performs operations according to the type of the test process signal. If the test process signal in the test signal is the step process signal, then the server determines the execution type information in the test process signal, and the execution type information includes program-controlled signals, security access signals, and ordinary diagnostic step signals; and If the server determines that the execution type information is a program-controlled signal, the server generates a parsing signal including program-controlled instructions and sends the parsing signal to the electronic control unit under test through the program-controlled device. S4: The electronic control unit under test performs logical processing on the parsed message information in each of the received parsed signals and generates a corresponding feedback signal, and then sends the feedback signal back to the server; S5: The server performs secondary parsing processing on the feedback signal to obtain the corresponding return signal value, and transmits the return signal value to the client, wherein the return signal value includes the actual response value; S6: The client compares the actual response value in the received return signal value with the corresponding expected response value, obtains the result data of the test case based on the comparison result, and outputs a test report based on the result data; and, The client also enables a real-time monitoring function. After receiving each returned signal value, it monitors in real time to detect the test process signal type contained in the returned signal value and determines subsequent processing steps based on the test process signal type. If the test process signal is the test case start signal, traverse the test steps of the corresponding test case and enter the test process of the test step of the test case; If the test process signal is the test case end signal, the test steps of the corresponding test case are terminated; proceed to the test steps of the next test case or the test end step; if the test process signal is the test end signal, turn off real-time monitoring and output the final test report, and end all test processes.

2. The automated testing method for vehicle-mounted electronic control units as described in claim 1, characterized in that, Step S3 further includes: If the server determines that the execution type information is a secure access signal, the server generates a parsing signal including a request seed signal and sends it to the electronic control unit under test. After obtaining the returned seed, the server calculates the key using the seed. The server then sends the key to the electronic control unit under test for verification. If the verification is successful, subsequent operations are performed. If the server determines that the execution type information is a normal diagnostic step signal, the parsing signal generated by the server includes extracting parameters from the execution type information, assembling them to obtain a diagnostic test message, and sending the diagnostic test message to the electronic control unit under test; and If the test process signal in the test signal is any one of the test case start signal, the test case end signal, and the test end signal, then the server generates a parsing signal including a system initialization signal and performs a system initialization operation.

3. The automated testing method for the vehicle-mounted electronic control unit as described in claim 2, characterized in that, When the execution type information is a normal diagnostic step signal, after the server obtains the diagnostic test message, it determines whether the diagnostic test message is a periodic message. If so, the server periodically sends the diagnostic test messages.

4. The automated testing method for on-board electronic control units as described in claim 2, characterized in that, The programmable device includes a programmable power supply and at least one programmable relay; The programmable relay in the programmable device controls the disconnection and connection of the circuit of the electrical control unit under test according to the control command; the programmable power supply in the programmable device controls the voltage and current changes of the electrical control unit under test according to the control command.

5. The automated testing method for an on-board electronic control unit as described in any one of claims 1-4, characterized in that, The transmitted signal value of the test data for each test case includes the test rule identifier, transmitted semaphore, execution cycle, execution steps, and return semaphore; Each of the test signals also includes execution cycle information, special step information, initialization information, and sleep information.

6. The automated testing method for an on-board electronic control unit as described in claim 5, characterized in that, The client reads and parses the transmitted signal value, including: The signal values ​​of the test cases in the preset Excel file are read, converted into JSON format, and stored.

7. The automated testing method for an on-board electronic control unit as described in any one of claims 1-4, characterized in that, The test signal and the return signal value are transmitted via socket format.

8. An automated testing system for vehicle-mounted electronic control units, characterized in that, Used to perform the automated testing method as described in any one of claims 1-7; The automated testing system includes a client, a server, an electronic control unit under test (ECU), and a programmable controller (CNC) connected sequentially via communication; wherein... The client is used to acquire test data for test cases, read and parse the signal values ​​in the test data, generate test signals, and send the test signals to the server. The server is used to parse the test signal and generate a parsed signal, and transmit the parsed signal to the electronic control unit under test; The electronic control unit under test is used to receive the analyzed signal and generate a corresponding feedback signal, and transmit the feedback signal to the server; The server performs secondary parsing of the feedback signal to obtain a return signal value, and then transmits the return signal value to the client; The client obtains the result data of the test case based on the returned signal value, and outputs a test report based on the result data; The programmable device is connected to the server and the electrical control unit under test respectively. The server transmits the analytical signal to the programmable device, and the programmable device transmits the analytical signal to the electrical control unit under test.

9. The automated testing system as described in claim 8, characterized in that, in The programmable device includes a programmable power supply and at least one programmable relay; The programmable relay is used to control the disconnection and connection of the circuit of the electronic control unit under test according to the analytical signal; the programmable power supply is used to control the voltage and current changes of the electronic control unit under test according to the analytical signal. When there are multiple programmable relays, each programmable relay is connected to a different electronic control unit under test; the server also includes a control module, and each programmable relay is connected to the control module; the control module is equipped with a switch corresponding to each programmable relay, which is used to control the opening and closing of each programmable relay.

10. The automated testing system as described in claim 8, characterized in that, The server also includes a timer. When the server receives a test signal that is a normal diagnostic step signal, the server extracts parameters from the execution step information and assembles them to obtain a diagnostic test message; and... When the diagnostic test message is a periodic message, the timer is started to make the server periodically send the diagnostic test message, and the timer is turned off after the execution is completed.

11. The automated testing system as described in any one of claims 8-10, characterized in that, The client module that executes the automated testing method is developed using Python + QT, and the server module that executes the automated testing method is built using CANoe and developed using the CAPL language.

Images