Vehicle-mounted test execution system based on process editing and control method thereof

Abstract

The invention discloses a vehicle-mounted test execution system for process editing, which comprises a test process editing platform, VCI equipment and a vehicle ECU, and is characterized in that the test process editing platform is connected with the vehicle ECU through the VCI equipment, and the test process editing platform comprises a test process demand confirmation unit, a test process editing unit, a test process judgment unit and a test process execution unit; meanwhile, the invention further discloses a control method thereof, the test process is flexibly edited, a single VCI device is connected with the vehicle ECU, the vehicle model is identified through the diagnosis process so as to implement different adaptive vehicle model test processes, the operation is simple, the compatibility is good, and the efficiency is high.

Description

Technical Field

[0001] This invention belongs to the field of vehicle-mounted test process editing, specifically a vehicle-mounted test execution system and its control method based on process editing. Background Technology

[0002] Onboard testing refers to the testing of a vehicle's intelligent modules and is part of road testing. Onboard testing includes functional testing, performance testing, and safety testing. Testing methods include software testing and hardware testing. Currently, onboard testing for new energy vehicles mainly refers to the functional testing of the vehicle's software, that is, system functional testing targeting a specific function implemented by the vehicle.

[0003] The vehicle ECU (Electronic Control Unit) is the core computing and control device of the automotive electronic system, responsible for managing various vehicle functions, such as engine control, transmission logic, braking system, battery management, etc.

[0004] UDS (Unified Diagnostic Services) is the most commonly used diagnostic protocol standard in automotive electronic systems, defined in ISO 14229-1. It is used for functions such as fault diagnosis, parameter configuration, and software remapping of vehicle ECUs.

[0005] A VCI device is a device that records CAN messages and also supports statistics, sending and receiving CAN messages, sending and receiving UDS commands, and sending and receiving calibration measurement messages.

[0006] However, current VCI devices that support offline diagnostics require multiple diagnostic operation processes to be written into multiple VCIs when dealing with different vehicle models. Even some VCIs that support the same VCI for different vehicles only add buttons to the VCI and perform diagnostic operations on different vehicles by pressing different buttons. However, the total number of buttons on a VCI device cannot be increased indefinitely, and with many buttons, it is easy to confuse the correspondence between vehicles and buttons. Summary of the Invention

[0007] To address the technical problems existing in the prior art, the present invention provides an on-board test execution system and its control method based on process editing.

[0008] The technical problem solved by this invention is achieved through the following technical solution: An on-board test execution system for process editing includes a test process editing platform, a VCI device, and a vehicle ECU. The test process editing platform is connected to the vehicle ECU via the VCI device. The test process editing platform includes a test process requirement confirmation unit, a test process editing unit, a test process determination unit, and a test process execution unit. The test process requirements confirmation unit is used to confirm the requirements of the test process to be edited. The test process editing and judgment unit is used to edit the test process according to the requirements of the test process to be edited and to make a rational judgment on the edited test process; The test process diagnostic and execution unit is used by a single VCI device to match different vehicle ECUs through the diagnostic process and execute the test process that passes the diagnostic rationalization judgment.

[0009] A control method for an on-board test execution system based on process editing includes the following steps: Step S1: Create an in-vehicle process editing task in the test process editing platform, and enter the requirements of the test process to be edited in the test process requirement confirmation unit; Step S2: In the process editing unit, select the steps to be executed according to the requirements, edit and combine them into a test process that meets the requirements, and then inform the IProcessBlock base class to perform C language code conversion according to the process management class to which each step belongs, and then input the C program module. Then, in the process judgment unit, perform the rationality judgment of the test process. If the judgment fails, stop editing and repeat step S2. If the judgment passes, the test process editing is completed and the test process result is output. Step S3: Transfer the output test process results to the C script input management script module of the VCI device, and then download them to the VCI device; Step S4: Write the diagnostic operation into the VCI, then connect the VCI to the vehicle ECU and perform the diagnostic operation. After the diagnosis, match the corresponding test process that the vehicle can run, and then the VCI device executes the C script of the current required test process. The interaction with the vehicle ECU device is realized through the compiled UDS diagnostic instructions.

[0010] Furthermore, in step S2, the IProcessBlock base class contains properties and operations common to all test processes within the use case.

[0011] Furthermore, in step S2, the rationalization and judgment process of the test procedure is specifically as follows: In C++ syntax, the decision step is a conditional operation, a loop operation, or a loop keyword operation. In C++ syntax, elseif / else must follow if, and break / continue must be used within the scope of the loop operation. Here, it will determine whether the currently added flow control step conforms to the usage of C++ syntax. When there are multiple nested relationships, it will check whether the previous step is reasonable.

[0012] Furthermore, in step S4, the diagnostic operation includes the following steps: Step S4.1: Obtain and match vehicle information by reading the DID of the vehicle ECU; Step S4.2: Verify the return value of DID and determine the fault detection and processing corresponding to the information of different vehicles; Step S4.3: Perform DTC detection and cycle ten times, returning the fault code. If no fault code is returned after ten detections, the buzzer will sound twice to indicate to the tester that the test has passed. Step S4.4: If a fault code is returned in any of the ten tests, the fault code information is recorded in the statistical log, and a continuous beeping is sounded after the test is completed to indicate that a fault code exists in this test. Afterwards, the specific fault can be viewed through the contents of the statistical log, and then the process jumps to step S4.5. Step S4.5: Clear fault information.

[0013] Further, step S4.5 specifically involves sending a fault code clearing request message to clear the diagnosed fault information.

[0014] Furthermore, the VCI device can also flash ECUs in batches. If there are multiple vehicle ECU models, the test process in the VCI device reads the DID value of each vehicle ECU data to obtain the corresponding vehicle ECU version information. Based on the version information, it determines whether flashing is required. If the version is the latest, a beeping step is executed, indicating that no update is needed. The beeping step uses a frequency of 5000 Hz and a duration of 500 ms. If the version is not the latest, a security algorithm is used to access the VCI device to download the executable file and update the vehicle ECU software version.

[0015] Furthermore, the security algorithm obtains advanced privileges of the vehicle's ECU through a secure access algorithm.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1) This invention innovatively sets up a test process editing platform to edit specific test processes. The specific test process steps are communicated to the IProcessBlock base class through the process management class for C code conversion. Finally, the edited and combined C applet code is compiled and executed by the system.

[0017] 2) This invention only requires a single VCI device. The converted C code is downloaded to the VCI device. When offline, the VCI device identifies the vehicle model through the diagnostic process and performs the corresponding test process, which greatly reduces the operational complexity of on-board testing and reduces the cost of setting up the VCI device.

[0018] 3) The VCI device of the present invention can refresh or diagnose the ECUs of a batch of vehicles, adapt to the diagnostic operations of different vehicles, which is convenient and simple and improves the overall efficiency. Attached Figure Description

[0019] Figure 1 This is a flowchart of the diagnostic steps of the present invention; Figure 2 This is a flowchart of the version information flashing steps of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0021] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0022] It should be noted that similar labels 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.

[0023] Example 1 An on-board test execution system for process editing includes a test process editing platform, a VCI device, and a vehicle ECU. The test process editing platform is connected to the vehicle ECU via the VCI device. The test process editing platform includes a test process requirement confirmation unit, a test process editing unit, a test process determination unit, and a test process execution unit. The test process requirements confirmation unit is used to confirm the requirements of the test process to be edited. The test process editing and judgment unit is used to edit the test process according to the requirements of the test process to be edited and to make a rational judgment on the edited test process; The test process diagnostic and execution unit is used by a single VCI device to match different vehicle ECUs through the diagnostic process and execute the test process that passes the diagnostic rationalization judgment.

[0024] A control method for an on-board test execution system based on process editing includes the following steps: Step S1: Create an in-vehicle process editing task in the test process editing platform, and enter the requirements of the test process to be edited in the test process requirement confirmation unit; Step S2: In the process editing unit, select the steps to be executed according to the requirements, edit and combine them into a test process that meets the requirements, and then inform the IProcessBlock base class to perform C language code conversion according to the process management class to which each step belongs, and then input the C program module. Then, in the process judgment unit, perform the rationality judgment of the test process. If the judgment fails, stop editing and repeat step S2. If the judgment passes, the test process editing is completed and the test process result is output. It should be noted that the rationality determination process of the above testing procedure is as follows: In C++ syntax, the decision step is a conditional operation, a loop operation, or a loop keyword operation. In C++ syntax, elseif / else must follow if, and break / continue must be used within the scope of the loop operation. Here, it will determine whether the currently added flow control step conforms to the usage of C++ syntax. When there are multiple nested relationships, it will check whether the previous step is reasonable.

[0025] It should be noted that the IProcessBlock base class contains attributes and operations common to all test processes within the use case. It also includes a special category, namely the process management class, which stores the specific steps of each process in all test processes.

[0026] Furthermore, specifically, the characteristics of the IProcessBlock base class are: ①Basic information of the IProcessBlock base class ProcessUuid: A unique identifier for the process; all operations involving adding, deleting, modifying, and querying will revolve around this field. ProcessName: The name of the step displayed in the interface; ProcessBasicType: The basic type of the step (e.g., API functions, sequences, IF, ELSEIF, etc. all belong to the basic type, while diagnostic-related steps belong to the user-defined type); ProcessType: Distinguishes different sub-step types under the same basic type (e.g., API functions and sequences both belong to the basic type, and this field can reflect the specific type of the step). ProcessBaseProperty: The basic property of the step; isShowInView: Whether to display in the process tree; canHaveChild: Whether it can have child nodes; canEdit: Whether it can be edited; canAdd: Whether to add; canRename: Whether the name can be renamed; canTag: Whether a tag can be set; canLoop: Can a loop be set? canPreCondition: Whether execution conditions can be set; canPostAction: Can a post-redirect be set? ②General settings information for steps in the IProcessBlock base class Tagsetting: Step tagging settings; LoopSetting: The settings are executed in a loop; the default is no loop. PreConditionCode: The condition for the step to be executed. If the condition is not met, the step will not be executed. PostActionSetting: This setting determines the jump after a step is executed. It allows you to judge and jump based on specified conditions after a step is completed. The default setting is to continue to the next step. You can jump to other steps, other sequences in the same process, or end the process directly. PreExpressionCode: Actions performed before the step is executed, which can initialize some variables; PostExpressionCode: The action performed after the step is executed, which can release memory for unused variables; ③ Generic functions for steps in the IProcessBlock base class Code generation: toCCode(); Serialization: toJsonStr() / fromJson(); Cloning (used when retrieving business plugins): clone(); Data update: updateProcessBlockData(); ③ Design features of the IProcessBlock base class Polymorphism: Implementing specific behaviors for different step types through pure virtual functions; Scalability: Supports custom step types and attributes; Serialization support: Full JSON serialization / deserialization functionality; Flow control: Rich conditional statements, loops, and jump mechanisms; Hierarchical structure: Supports complex parent-child step relationships; Access control: Fine-grained control over operation permissions for each step is achieved through BaseStepProperty.

[0027] This data structure design supports complex workflow editing functions, including advanced features such as conditional branching, loop control, step jump, and tag management, making it suitable for automated testing or business process management systems that require flexible workflow control.

[0028] Furthermore, the above-mentioned process editing can adapt to various CAN / LIN / ETH communication devices, various diagnostic ECU flashing process methods, and various process measurement calibration measurement process editing and execution methods. According to the specific requirements of the test process, the process is added by means of drag and drop in the software system. Then, the specific process steps are informed to the IProcessBlock base class through the process management class for C code conversion. Finally, the required C applet code is edited and combined, and then compiled and executed by the system.

[0029] Step S3: Transfer the output test process results to the C script input management script module of the VCI device, and then download them to the VCI device; Step S4: Write the diagnostic operation into the VCI, then connect the VCI to the vehicle ECU and perform the diagnostic operation. After the diagnosis, match the corresponding test process that the vehicle can run, and then the VCI device executes the C script of the current required test process. The interaction with the vehicle ECU device is realized through the compiled UDS diagnostic instructions.

[0030] Among them, such as Figure 1 As shown, the diagnostic procedure includes the following steps: Step S4.1: Obtain and match vehicle information by reading the DID of the vehicle ECU. Specifically, read the diagnostic information to obtain vehicle information and return the corresponding vehicle information. Step S4.2: Verify the return value of DID and determine the fault detection processing corresponding to the information of different vehicles, that is, add branch judgment for different vehicle scenarios; Step S4.3: Perform DTC detection and loop 10 times. Return the fault code. If no fault code is returned after 10 detections, the beep will sound twice to indicate to the tester that the test has passed. Specifically, read the DTC information, send 19 02 to obtain the vehicle ECU fault code, return the corresponding fault code, and then use the fault code statistics in the combined service to record it to the specified CSV file. Loop 10 times. Step S4.4: If a fault code is returned in any of the ten tests, the fault code information is recorded in the statistical log, and a continuous beeping is sounded after the test is completed to indicate that a fault code exists in this test and this test has failed. Afterwards, the specific fault can be viewed through the contents of the statistical log, and then the process jumps to step S4.5. Step S4.5: Send a fault code clearing request message to clear the diagnosed fault information.

[0031] like Figure 2 As shown, the VCI device can also flash batch vehicle ECUs. If multiple vehicle ECU models exist, the VCI device's test process and diagnostic session control read the DID value of each vehicle ECU's data (i.e., 22 f1 88) to obtain the corresponding vehicle ECU version information. Based on the version information, it determines whether flashing is needed. This involves using branch judgment to evaluate the returned version information. If the version is the latest, it returns 0 and executes a beeping step (using a 5000Hz frequency and 500ms beeping parameter), indicating the version is the latest and no update is needed. If the version is not the latest, it returns -1 and uses a secure algorithm to access the VCI device to download the executable file and update the vehicle ECU software version. The secure algorithm obtains high-level privileges for the vehicle ECU through a secure access algorithm.

[0032] The VCI device involved in this embodiment supports CANFD data recording and XCP observation data, supports real-time CANFD data transmission and reception, supports UDS diagnostics and flashing, and supports offline execution of flashing scripts. Compared with existing VCI devices, the VCI device involved in this embodiment is small and portable, uses WiFi and USB interfaces for communication, supports control via mobile APP and computer, has a standard OBD interface definition for direct connection to the vehicle's OBD, and has 128GB of large memory to support long-term recording.

[0033] The above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. A vehicle-mounted test execution system for workflow editing, characterized in that, The system includes a test process editing platform, a VCI device, and a vehicle ECU. The test process editing platform is connected to the vehicle ECU via the VCI device. The test process editing platform includes a test process requirement confirmation unit, a test process editing unit, a test process determination unit, and a test process execution unit. The test process requirements confirmation unit is used to confirm the requirements of the test process to be edited. The test process editing and judgment unit is used to edit the test process according to the requirements of the test process to be edited and to make a rational judgment on the edited test process; The test process diagnostic and execution unit is used by a single VCI device to match different vehicle ECUs through the diagnostic process and execute the test process that passes the diagnostic rationalization judgment.

2. The control method for the vehicle-mounted test execution system based on the process editing of claim 1, characterized in that, Includes the following steps: Step S1: Create an in-vehicle process editing task in the test process editing platform, and input the requirements of the test process to be edited in the test process requirement confirmation unit; Step S2: In the process editing unit, select the steps to be executed according to the requirements, edit and combine them into a test process that meets the requirements, and then, according to the process management class to which each step belongs, inform the IProcessBlock base class to perform C language code conversion, and then input the C program module. Then, in the process judgment unit, perform a rationality judgment on the test process. If the judgment fails, stop editing and repeat step S2. If the judgment passes, the test process editing is completed and the test process result is output. Step S3: Transfer the output test process results to the C script input management script module of the VCI device, and then download them to the VCI device; Step S4: Write the diagnostic operation into the VCI, then connect the VCI to the vehicle ECU and perform the diagnostic operation. After the diagnosis, match the corresponding test process that the vehicle can run, and then the VCI device executes the C script of the current required test process. The interaction with the vehicle ECU device is realized through the compiled UDS diagnostic instructions.

3. The control method for the vehicle-mounted test execution system of the process editing according to claim 2, characterized in that, In step S2, the IProcessBlock base class contains attributes and operations common to all test processes within the usage scenario.

4. The control method for the vehicle-mounted test execution system of the process editing according to claim 2, characterized in that, In step S2, the rationalization and determination process of the test procedure specifically includes: In C++ syntax, the decision step is a conditional operation, a loop operation, or a loop keyword operation. In C++ syntax, elseif / else must follow if, and break / continue must be used within the scope of the loop operation. Here, it will determine whether the currently added flow control step conforms to the usage of C++ syntax. When there are multiple nested relationships, it will check whether the previous step is reasonable.

5. The control method for the vehicle-mounted test execution system of the process editing according to claim 2, characterized in that, In step S4, the diagnostic operation includes the following steps: Step S4.1: Obtain and match vehicle information by reading the DID of the vehicle ECU; Step S4.2: Verify the return value of DID and determine the fault detection and processing corresponding to the information of different vehicles; Step S4.3: Perform DTC detection and cycle ten times, returning the fault code. If no fault code is returned after ten detections, the buzzer will sound twice to indicate to the tester that the test has passed. Step S4.4: If a fault code is returned in any of the ten tests, the fault code information is recorded in the statistical log, and a continuous beeping is sounded after the test is completed to indicate that a fault code exists in this test. Afterwards, the specific fault can be viewed through the contents of the statistical log, and then the process jumps to step S4.

5. Step S4.5: Clear fault information.

6. The control method for the vehicle-mounted test execution system of the process editing according to claim 5, characterized in that, Step S4.5 specifically involves sending a fault code clearing request message to clear the diagnosed fault information.

7. The control method for the vehicle-mounted test execution system of the process editing according to claim 5, characterized in that, The VCI device can also flash ECUs in batches. If there are multiple models of vehicle ECUs, the test process in the VCI device reads the DID value of each vehicle ECU data to obtain the corresponding vehicle ECU version information. Based on the version information, it determines whether flashing is required. If the version is the latest, a beeping step is executed, indicating that no update is needed. The beeping step uses a frequency of 5000 Hz and a duration of 500 ms. If the version is not the latest, a security algorithm is used to access the VCI device to download the executable file and update the vehicle ECU software version.

8. The control method for the vehicle-mounted test execution system of the process editing according to claim 7, characterized in that, The security algorithm obtains advanced privileges of the vehicle's ECU through a secure access algorithm.

Images