Diagnostic test method and device, computer equipment and storage medium

Abstract

The invention discloses a diagnosis test method and device, computer equipment and a storage medium, and the method comprises the steps: setting a target virtual response model corresponding to a virtual vehicle communication interface module and a target control module in a diagnosis test system, and obtaining a diagnosis test instruction for the target control module when the diagnosis test instruction for the target control module is obtained; a diagnosis test instruction can be sent to a corresponding target virtual response model through a virtual vehicle communication interface module, and a target control module is simulated through the target virtual response model to respond to the diagnosis test instruction so as to obtain a corresponding control module operation result; the virtual vehicle communication interface module and the target virtual response model are arranged in the diagnostic test system, so that the diagnostic software is separated from the constraint of physical hardware and a real vehicle environment when carrying out diagnostic test on the electronic control unit, and diversified test scenes can be flexibly constructed according to diagnostic test requirements; the diagnosis test and verification cost is remarkably reduced, and the diagnosis test and verification efficiency of the automobile diagnosis software is greatly improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a diagnostic testing method, apparatus, computer equipment, and storage medium. Background Technology

[0002] To meet people's pursuit of a higher quality of life, vehicles that facilitate user travel have emerged. With the advancement of vehicle intelligence, vehicles are capable of more and more functions, and people's attention to vehicles is no longer limited to their quality; they are also extremely concerned about vehicle maintenance and management. Currently, users can maintain their vehicles using connected automotive diagnostic equipment. Specifically, automotive diagnostic software can be used to perform diagnostic tests on the vehicle's Electronic Control Unit (ECU), including fault diagnosis, parameter reading, function debugging, and program rewriting.

[0003] In the current technology, when users use automotive diagnostic software to perform diagnostic tests on ECUs, the testing and flashing verification processes generally rely on the vehicle's physical Controller Area Network (CAN) bus hardware and the actual vehicle environment. However, under the current technology, each diagnostic test operation of automotive diagnostic software needs to be carried out based on a real physical link, resulting in high diagnostic testing costs and low diagnostic testing efficiency. Summary of the Invention

[0004] To address the aforementioned technical issues, embodiments of this application provide a diagnostic testing method, apparatus, computer equipment, and storage medium, which can flexibly construct diverse testing scenarios according to diagnostic testing needs, significantly reducing diagnostic testing and verification costs and greatly improving the efficiency of diagnostic testing and verification of automotive diagnostic software.

[0005] In a first aspect, embodiments of this application provide a diagnostic testing method applied to a diagnostic testing system, comprising: Obtain diagnostic test instructions for the target control module of the target vehicle model; The diagnostic test command is sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system. The target virtual response model is a model generated by simulating the target control module based on the module configuration file of the target control module. The target virtual response model simulates the target control module's response to the diagnostic test command to obtain the control module's operating result corresponding to the diagnostic test command, and sends the control module's operating result to the virtual vehicle communication interface module. The virtual vehicle communication interface module sends the operation results of the control module to the diagnostic test module of the diagnostic test system, so that the diagnostic test module can determine the diagnostic test result corresponding to the diagnostic test instruction based on the operation results of the control module.

[0006] Secondly, embodiments of this application provide a diagnostic testing device applied to a diagnostic testing system, comprising: The acquisition unit is used to acquire diagnostic test instructions for the target control module of the target vehicle model. The first processing unit is used to send the diagnostic test command to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system. The target virtual response model is a model generated by simulating the target control module based on the module configuration file of the target control module. The second processing unit is used to simulate the target control module's response to the diagnostic test command through the target virtual response model, so as to obtain the control module's running result corresponding to the diagnostic test command, and send the control module's running result to the virtual vehicle communication interface module. The third processing unit is used to send the operation result of the control module to the diagnostic test module of the diagnostic test system through the virtual vehicle communication interface module, so that the diagnostic test module can determine the diagnostic test result corresponding to the diagnostic test instruction based on the operation result of the control module.

[0007] Thirdly, embodiments of this application also provide a computer device, including a memory storing multiple instructions; a processor loads instructions from the memory to execute the steps of any of the diagnostic testing methods provided in embodiments of this application.

[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the steps of any of the diagnostic testing methods provided in embodiments of this application.

[0009] Fifthly, embodiments of this application also provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in any of the diagnostic testing methods provided in embodiments of this application.

[0010] The solution adopted in this application embodiment sets up a virtual vehicle communication interface module and a target virtual response model corresponding to the target control module in the diagnostic test system. When a diagnostic test command for the target control module is obtained, the diagnostic test command can be sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module. The target virtual response model simulates the target control module's response to the diagnostic test command to obtain the control module's operating result corresponding to the diagnostic test command. By setting up a virtual vehicle communication interface module and a target virtual response model corresponding to the target control module in the diagnostic test system, the diagnostic software can be freed from the constraints of physical hardware and the actual vehicle environment when performing diagnostic tests on electronic control units. It can flexibly construct diverse test scenarios according to diagnostic test requirements, significantly reducing diagnostic test and verification costs and greatly improving the efficiency of diagnostic test and verification of automotive diagnostic software. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the diagnostic testing system of the diagnostic testing method provided in the embodiments of this application; Figure 2 This is a schematic flowchart of one embodiment of the diagnostic testing method provided in this application. Figure 3 This is a timing acceleration diagram of the refresh process of the diagnostic testing method provided in the embodiments of this application; Figure 4 This is an overall architecture diagram of the diagnostic testing system provided in the embodiments of this application; Figure 5 This is a flowchart of the communication layer interface switching of the diagnostic testing method provided in the embodiments of this application; Figure 6 This is a comparison table of time acceleration ratio and verification time in the diagnostic testing method provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of the diagnostic testing device provided in the embodiments of this application; Figure 8 This is a schematic diagram of the internal structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. At the same time, in the description of the embodiments of this application, the terms "first," "second," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0014] In one embodiment of this application, the diagnostic testing method can run on a local terminal device or a server. When the diagnostic testing method runs on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and a client device.

[0015] To better understand the diagnostic testing method, apparatus, computer equipment, and storage medium provided in the embodiments of this application, the application environment applicable to the embodiments of this application is described below.

[0016] Please see Figure 1 , Figure 1 This is a schematic diagram of a diagnostic testing system provided in an embodiment of this application. The diagnostic testing system may include a diagnostic software module (i.e., a processing module), a communication interface module, a virtual CAN model engine (i.e., a virtual vehicle communication interface module), an XML configuration loader, and a time control and log analysis module (i.e., a time control module).

[0017] The diagnostic software module is used to generate diagnostic test instructions for the target vehicle model or target control module, and to receive and determine the diagnostic test results based on the diagnostic test execution results corresponding to the diagnostic test instructions.

[0018] The communication interface module provides a unified test interface function SetTestMode(enable, xmlPath). When the diagnostic test system enables the virtual test diagnostic mode, the system instructs the communication layer of the communication interface module to automatically connect the send and receive functions to the virtual CAN model engine, and instructs the XML configuration loader to load the XML model file (i.e., module configuration file) of the control module of the corresponding target vehicle model, thereby realizing virtualized diagnostic testing.

[0019] The virtual CAN model engine is used to simulate the sending and receiving of CAN bus frames in memory, so as to simulate the communication of the real CAN bus on the vehicle.

[0020] The diagnostic test system also includes an ISO-TP transport layer module, which is used to simulate the segmentation and reassembly logic of the ISO-TP protocol, supports the interaction process of single frames, first frames, continuous frames and flow control frames, and allows the adjustment of protocol parameters (STmin, BS, BlockDelay) in virtual diagnostic test mode to simulate different transmission environments.

[0021] The diagnostic testing system also includes a virtual UDS response engine (i.e., a virtual command parsing module). This engine parses UDS requests issued by the diagnostic software and generates corresponding responses based on the configuration model. Common services it supports include: 0x10 (DiagnosticSessionControl), 0x22 (ReadDataByIdentifier), 0x27 (SecurityAccess), 0x31 (RoutineControl), 0x34, 0x36, 0x37 (flash services), etc. The virtual UDS response engine internally maintains a DID mapping table, routine response table, and security access policies, and supports NRC injection and delayed responses.

[0022] The XML configuration loader loads the XML model file of the control module for the corresponding target vehicle model. The XML model file describes the behavior of the virtual ECU response model. Each XML model file corresponds to a vehicle model or ECU module and defines the request ID, response ID, SID mapping, DID value, timing parameters, NRC rules, and delay. The request ID is the CAN bus message identifier sent by the diagnostic device to the ECU, indicating which ECU a diagnostic request is sent to. The response ID is the CAN message identifier used by the ECU to reply to the diagnostic device, allowing the diagnostic device to identify which ECU's response came from. The SID mapping associates the UDS service code (e.g., 10, 22, 34) with the corresponding response logic, determining which type of diagnostic service is received and executing the appropriate processing. The DID value refers to the UDS data identifier (e.g., F190). The preset return values ​​(such as VIN, F187 software version, etc.) are used to control what content the virtual ECU should return in the data read service. Timing parameters refer to the time control parameters in diagnostic communication, such as P2, P2*, STmin, inter-block delay, etc., which are used to determine how long after the virtual ECU returns a response and the time interval between consecutive frames. NRC rules and delays define the conditions under which the virtual ECU returns a negative response code (such as 78, 31, etc.) and the rules that generate response delays, which are used to simulate the abnormal or timeout behavior of the real ECU.

[0023] The time control and log analysis module is used to scale all time parameters (P2, P2*, STmin, BlockDelay) of the communication layer and UDS layer, reducing physical latency proportionally through the acceleration ratio parameter (accel_ratio). For example, when accel_ratio is set to 0.01, all latency is only 1% of the original. The time control and log analysis module can also record every request issued by the diagnostic software and the response returned by the virtual CAN model engine, automatically comparing the results and generating reports after the test, supporting automatic regression and batch verification.

[0024] It should be understood that Figure 1 The diagnostic testing system provided is merely illustrative. The module structure and number of modules in the diagnostic testing system can be adjusted arbitrarily according to implementation needs.

[0025] The following detailed description, in conjunction with the accompanying drawings, illustrates the process. This embodiment uses a diagnostic testing system as an example. It should be noted that the order of description in the following embodiments is not intended to limit the preferred order of the embodiments. Although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown in the drawings.

[0026] The following detailed description, in conjunction with the accompanying drawings, illustrates the process. This embodiment uses a diagnostic testing system as an example. It should be noted that the order of description in the following embodiments is not intended to limit the preferred order of the embodiments. Although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown in the drawings.

[0027] Please see Figure 2 The diagnostic testing methods provided in this application are described below. Please refer to [link / reference needed] for details. Figure 2 The specific procedure for this diagnostic test method can be summarized in steps 101 to 104, where: Step 101: Obtain the diagnostic test instructions for the target control module of the target vehicle model.

[0028] In this embodiment, the virtual communication layer of the diagnostic test system is used to simulate the frame transmission and reception of the CAN bus in memory, providing function interfaces completely consistent with the real communication interface, such as SendFrame and RecvFrame. The upper-layer diagnostic software can run in virtual diagnostic test mode without modification. At this time, the virtual communication layer supports two modes: 1) real communication mode (i.e., the mode where the diagnostic test system connects to the CAN bus of a real vehicle or a hardware CAN box for diagnostic testing); 2) virtual diagnostic test mode (i.e., loading a virtual CAN model file). This embodiment allows switching between the two modes at runtime through a unified interface manager.

[0029] In one specific embodiment, after the step of "obtaining the diagnostic test instructions for the target control module of the target vehicle model", the method further includes: The diagnostic test command is parsed by the virtual command parsing module of the diagnostic test system to obtain the parsed diagnostic test command. The parsed diagnostic test command is sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system.

[0030] The diagnostic test command can be a Unified Diagnostic Services (UDS) request. The UDS protocol is a standard diagnostic communication protocol used by the ECUs in a vehicle. A UDS request refers to a diagnostic command frame sent by the diagnostic equipment (i.e., diagnostic instrument / diagnostic software / diagnostic test system) to the ECU according to the UDS protocol format. In virtual diagnostic test mode, these UDS requests are parsed by the virtual UDS response engine (i.e., the virtual command parsing module) and a simulated response result is generated and returned through the virtual ECU response model (i.e., the virtual response model), thus eliminating the need to rely on the real ECU.

[0031] Step 102: The diagnostic test command is sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system. The target virtual response model is a model generated by simulating the target control module based on the module configuration file of the target control module.

[0032] In this embodiment, the diagnostic testing system only establishes a virtual ECU response model (i.e., virtual response model) after loading the XML file. The function of the virtual ECU response model is to simulate the diagnostic test request and response behavior of the corresponding ECU in diagnostic communication, so as to test and verify the diagnostic software in the absence of a real vehicle and real ECU hardware.

[0033] The module configuration file also includes time control parameters, which are used to control the response time of the target virtual response model when simulating the target control module's response to the diagnostic test command.

[0034] In this embodiment, the XML configuration model loader parses the module configuration file of the control module to establish a corresponding virtual ECU response model. The module configuration file defines the request ID, response ID, SID mapping, DID value, timing parameters, NRC rules, and delay. Timing parameters refer to time control parameters in diagnostic communication, such as P2, P2*, STmin, and inter-block delay, used to determine how long the virtual ECU should wait before returning a response and the time interval between consecutive frames. P2, P2*, STmin, and inter-block delay are time parameters specified in the UDS and ISO-TP protocols, used to control the timing behavior of diagnostic communication. P2 is the maximum waiting time for the ECU to return its first response after receiving a request. P2* is the extended waiting time after the ECU sends a "response pending" (0x78). STmin refers to the minimum time interval that must be maintained between consecutive frames, used to control the data transmission rate. Inter-block delay refers to the waiting time required after sending each set of data blocks during the flashing data transmission process. These parameters collectively determine the overall communication timing of the diagnostic and flashing process. Subsequent acceleration of the flashing process can be achieved by shortening these time parameters.

[0035] In one embodiment, before the step of "obtaining the diagnostic test instructions for the target control module of the target vehicle model", the method further includes: Obtain the module configuration file of the target control module of the target vehicle model, wherein the module configuration file is used to indicate the operating logic of the target control module; The module configuration file is parsed and loaded to generate the target virtual response model of the target control module.

[0036] In another embodiment, prior to the step of "obtaining the diagnostic test instructions for the target control module of the target vehicle model", the method further includes: Obtain the module configuration file of at least one control module of the target vehicle model, wherein the module configuration file is used to indicate the operating logic of the control module; The module configuration files are parsed and loaded to generate virtual response models corresponding to each control module; After obtaining the diagnostic test instructions for the target control module of the target vehicle model, the method further includes: Based on the diagnostic test instructions, the target control module is determined from each of the control modules, and the target virtual response model corresponding to the target control module is determined from the virtual response models corresponding to each of the control modules.

[0037] Specifically, the diagnostic testing system provided in this application allows for the simultaneous loading of multiple XML model files, and establishes an independent virtual ECU response model for each XML model file. The virtual CAN model engine can manage multiple model instances simultaneously within the system, enabling diagnostic testing processes for different vehicle models and / or different control modules to run in parallel on the same device without requiring a real vehicle or multiple hardware interfaces, thus achieving parallel diagnostic testing for multiple vehicle models and / or multiple control modules.

[0038] Step 103: Simulate the target control module's response to the diagnostic test command using the target virtual response model to obtain the control module's operating result corresponding to the diagnostic test command, and send the control module's operating result to the virtual vehicle communication interface module.

[0039] In one embodiment, the step "simulating the target control module's response to the diagnostic test command through the target virtual response model to obtain the control module's operating result corresponding to the diagnostic test command" includes: The target virtual response model simulates the target control module's response to the parsed diagnostic test command based on the module configuration file, so as to obtain the simulated response result, and the simulated response result is used as the running result of the control module corresponding to the diagnostic test command.

[0040] In this embodiment, when the diagnostic software or diagnostic software module sends a UDS request to the virtual CAN model engine, the virtual CAN model engine sends the UDS request to the virtual ECU response model so that it can simulate the response according to the rules defined in the corresponding XML model file to obtain the result, and return the result to the diagnostic software or diagnostic software module to obtain the diagnostic test result.

[0041] Step 104: The virtual vehicle communication interface module sends the operation result of the control module to the diagnostic test module of the diagnostic test system, so that the diagnostic test module can determine the diagnostic test result corresponding to the diagnostic test instruction based on the operation result of the control module.

[0042] Based on the above description, the diagnostic testing method of this application will be further illustrated with examples below. Specific embodiments are described below.

[0043] In this embodiment of the application, the time control and log analysis module can scale all time parameters (P2, P2*, STmin, BlockDelay) of the communication layer and UDS layer according to the acceleration ratio parameter. Before the step "simulating the target control module's response to the diagnostic test command through the target virtual response model to obtain the control module's running result corresponding to the diagnostic test command", the method further includes: Get the specified time scaling parameters; The time control module of the diagnostic test system adjusts the time control parameters in the module configuration file based on the specified time scaling parameters to obtain the adjusted module configuration file. The step of simulating the target control module's response to the diagnostic test command through the target virtual response model to obtain the control module's operating result corresponding to the diagnostic test command includes: The target control module responds to the diagnostic test command by simulating the target virtual response model and the adjusted module configuration file, so as to obtain the control module operation result corresponding to the diagnostic test command.

[0044] For example, please see Figure 3 , Figure 3 To accelerate the timing graph of the flashing process, in the virtual diagnostic test mode, the time control module of the diagnostic test system can adjust parameters such as P2, P2*, STmin, and inter-block delay, compressing the time interval by a set ratio to accelerate verification. For example, when accel_ratio is set to 0.01, the original 10-minute flashing process can be completed in about 6 seconds, ensuring that the verification process fully covers the request, data block transmission, verification, and end command, consistent with the real logic. Since the time consumption of flashing diagnostic tests and flashing processes is mainly determined by communication waiting time, on the real ECU and CAN bus, the waiting time specified by the protocol must be strictly followed, such as P2, P2*, STmin, and inter-block delay. These times often account for the majority of the entire flashing process; for example, flashing 1MB in reality may require tens of thousands of waits, each lasting from a few milliseconds to hundreds of milliseconds. Therefore, in the virtual diagnostic test mode provided in this application embodiment, these waiting times are compressed proportionally (e.g., shortened to 1% or 0.1% of the original), without changing the logical order of the flashing process or the number of data blocks. Therefore, although the execution steps are exactly the same, the total time can be reduced from the original 10 minutes to a few seconds because most of the waiting time is shortened, thus enabling rapid execution of diagnostic tests.

[0045] Optionally, embodiments of this application can also record each diagnostic test command issued by the diagnostic software module and the response results returned by the virtual CAN model engine through a time control and log analysis module. After the diagnostic test is completed, the results are automatically compared and a report is generated and stored to support automatic regression and batch verification.

[0046] This application embodiment also supports extended features such as multi-vehicle parallel testing, dynamic expression calculation of DID values, Seed / Key script callbacks, exception scenario injection, and log replay. Specifically, the diagnostic testing system provided in this application embodiment allows the simultaneous loading of multiple XML model files and establishes an independent virtual ECU response model for each XML model file. The virtual CAN model engine can manage multiple model instances simultaneously within the system, thereby enabling diagnostic testing processes for different vehicle models and / or different control modules to run in parallel on the same device without requiring real vehicles or multiple hardware interfaces, thus achieving parallel diagnostic testing for multiple vehicle models and / or multiple control modules.

[0047] For example, please see Figure 4 , Figure 4 This is an overall architecture diagram of a diagnostic testing system provided in an embodiment of this application. Specifically, it includes an upper-layer diagnostic application (i.e., a diagnostic software module), a communication layer virtualization interface (i.e., a communication interface module), and a virtual CAN model engine. The communication layer virtualization interface is associated with an XML model loader, a time control module, and a log and comparison module. The XML model loader is used to load a virtual ECU response model according to a model configuration file. The time control module is used to scale and control the time control parameters. The log and comparison module is used to compare results and export reports.

[0048] For example, please see Figure 5 , Figure 5 The flowchart of the communication layer interface switching is shown. After the diagnostic test system is initialized, the test interface function (SetTestMode(enable, xmlModelPath)) in the communication layer can be used to instruct the system to automatically bind the underlying transceiver functions to the virtual CAN engine and load the XML model file of the corresponding vehicle model or control module to obtain the virtual ECU response model, so as to realize virtualized testing. Specifically, it can perform diagnostic or refresh processes. The time control module can also adjust the time control parameters in the model configuration file to accelerate the above processes. Finally, the virtual test mode can be turned off or switched to the real CAN bus mode to connect with the CAN bus on the real vehicle to perform diagnostic tests in a real environment.

[0049] For example, please see Figure 6 , Figure 6The table comparing the time acceleration ratio and verification time in the diagnostic testing method provided for the implementation of this application is as follows. Specifically, it can include ECU-A and ECU-B. The original time for diagnostic testing of ECU-A is 30 minutes. When the acceleration ratio is set to 10× (i.e., 10 times), the accelerated time is 3 minutes. The original time for diagnostic testing of ECU-B is 12 minutes. When the acceleration ratio is set to 6× (i.e., 6 times), the accelerated time is 2 minutes, thereby achieving rapid execution of diagnostic tests.

[0050] The operation flow of the diagnostic testing system provided in this application is as follows: 1) The user or test script calls the communication layer interface to enable the virtual diagnostic test mode and loads the XML model file of the target vehicle model; 2) The diagnostic software module sends flashing or diagnostic commands according to the normal procedure; 3) After receiving the request, the virtual communication layer hands it over to the virtual UDS engine for parsing; 4) The virtual CAN model engine generates response data based on the XML configuration and returns it according to the accelerated timing sequence; 5) The upper-layer flushing logic is executed completely, including handshake, block transfer, verification, and termination steps; 6) The diagnostic testing system records logs and generates verification result reports.

[0051] This application embodiment sets up a virtual CAN model engine in the diagnostic test system within the diagnostic equipment, and establishes a virtual ECU response model based on the loaded vehicle model XML file to simulate the diagnostic test behavior of the corresponding ECU. When the diagnostic equipment module sends a UDS request, these requests do not enter the real vehicle. Instead, the virtual CAN model engine generates a response result according to the rules defined in the XML, using the virtual ECU response model, and returns it to the diagnostic equipment module, thereby completing the diagnostic and flashing process test. The virtual ECU response model is used immediately after the diagnostic equipment sends a UDS request. When the diagnostic software module sends a UDS request to the virtual CAN engine, the virtual ECU response model generates a corresponding simulated response according to the rules defined in the XML file and returns it to the diagnostic software. This achieves complete replacement of the communication behavior of the real ECU in the absence of a real vehicle and a real ECU, and is used to test and verify the diagnostic process, flashing process, and exception handling logic of the diagnostic software. In the testing phase of the communication and flashing process of the diagnostic test software, complete software-level simulation and time-controllable acceleration are achieved, fundamentally eliminating the dependence on hardware CAN simulators and real vehicle environments.

[0052] This application introduces a switchable virtual CAN interface mechanism into the communication layer of the diagnostic testing system. The communication layer can dynamically switch between real hardware communication and the virtual model, enabling the diagnostic software to run without relying on any physical CAN device during the testing phase. Furthermore, this application can also establish a virtual ECU response model based on XML configuration files. The diagnostic services (SID, DID, routines, secure access, etc.) for each vehicle model or ECU are defined by the module configuration file. The diagnostic testing system can automatically generate corresponding responses based on the content of the XML model file, achieving high reusability and configurability. Furthermore, a time control and acceleration mechanism is introduced into the virtual CAN model engine. By adjusting timing parameters such as P2, P2*, STmin, and BlockDelay, time scaling and accelerated verification are supported. In accelerated mode, the flashing process logic is executed completely, but the physical time is greatly compressed, completing the flashing verification that originally required tens of minutes within seconds.

[0053] Furthermore, the diagnostic testing system provided in this application provides a unified test interface in the communication layer. Different vehicle models' software can enable virtualization during the testing phase by calling the test mode interface provided by the communication layer, achieving rapid model loading, automated testing, and result comparison. Further, the diagnostic testing system provided in this application also supports parallel testing and automated verification of multiple vehicle models. The system allows the simultaneous loading of multiple XML models, enabling parallel testing of multiple ECUs and multiple vehicle models, improving the utilization rate of testing resources. Finally, this application provides an automatic log recording and result comparison mechanism. The diagnostic testing system automatically records each request and response, generates a report after testing, and supports automatic PASS or FAIL determination for continuous integration or regression verification. It also supports anomaly scenario injection functionality, allowing configuration of NRC responses, timeout delays, random frame drops, or error frames in the XML model to verify the stability and recovery capability of the diagnostic software under abnormal communication conditions. It can also achieve complete flashing logic verification through pure software simulation. The virtual CAN model of this invention can cover the complete process of diagnostic communication, flashing download, verification, and exit, enabling the software to complete algorithm-level and process-level verification without any hardware devices. Therefore, the automatic testing system combining the virtual CAN model engine and the configurable time acceleration mechanism, as well as the response generation method of the communication layer virtualization interface and XML driver provided in this application embodiment, are used to achieve efficient, automated, and reproducible verification of diagnostic and flashing software.

[0054] In summary, this embodiment of the application obtains a diagnostic test command for the target control module of a target vehicle model; then, it sends the diagnostic test command to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system. The target virtual response model is a model generated by simulating the target control module based on the module configuration file of the target control module; next, it simulates the target control module's response to the diagnostic test command through the target virtual response model to obtain the control module's operating result corresponding to the diagnostic test command, and sends the control module's operating result to the virtual vehicle communication interface module; finally, it sends the control module's operating result to the diagnostic test module of the diagnostic test system through the virtual vehicle communication interface module, so that the diagnostic test module can determine the diagnostic test result corresponding to the diagnostic test command based on the control module's operating result. This application establishes a virtual vehicle communication interface module and a target virtual response model corresponding to the target control module in the diagnostic testing system. When a diagnostic test command is received for the target control module, it can be sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module. The target virtual response model simulates the target control module's response to the diagnostic test command to obtain the control module's operating result corresponding to the diagnostic test command. By establishing a virtual vehicle communication interface module and a target virtual response model corresponding to the target control module in the diagnostic testing system, the diagnostic software is freed from the constraints of physical hardware and the actual vehicle environment when performing diagnostic tests on electronic control units. It can flexibly construct diverse test scenarios according to diagnostic test requirements, significantly reducing diagnostic testing and verification costs and greatly improving the efficiency of diagnostic testing and verification of automotive diagnostic software.

[0055] It should be understood that although each step in the flowcharts of the above embodiments is shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0056] Based on the same inventive concept, this application also provides a diagnostic testing apparatus for implementing the diagnostic testing method described above, and a diagnostic testing apparatus for implementing the diagnostic testing method described above. The solution provided by this apparatus is similar to the solution described in the above method. Therefore, the specific limitations of the embodiments of one or more diagnostic testing apparatuses and diagnostic testing apparatuses provided below can be found in the limitations of the diagnostic testing method and diagnostic testing method described above, and the specific limitations will not be repeated here.

[0057] This embodiment also provides a diagnostic testing device, which can be integrated into a terminal device. For example, such as... Figure 7 As shown, the diagnostic testing device may include: Acquisition unit 201 is used to acquire diagnostic test instructions for the target control module of the target vehicle model; The first processing unit 202 is used to send the diagnostic test command to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system. The target virtual response model is a model generated by simulating the target control module based on the module configuration file of the target control module. The second processing unit 203 is used to simulate the target control module's response to the diagnostic test command through the target virtual response model, so as to obtain the control module's running result corresponding to the diagnostic test command, and send the control module's running result to the virtual vehicle communication interface module. The third processing unit 204 is used to send the operation result of the control module to the diagnostic test module of the diagnostic test system through the virtual vehicle communication interface module, so that the diagnostic test module can determine the diagnostic test result corresponding to the diagnostic test instruction based on the operation result of the control module.

[0058] In some embodiments, the diagnostic testing apparatus further includes: The first acquisition subunit is used to acquire the module configuration file of the target control module of the target vehicle model, wherein the module configuration file is used to indicate the operating logic of the target control module; The first processing subunit is used to parse and load the module configuration file to generate the target virtual response model of the target control module.

[0059] In some embodiments, the diagnostic testing apparatus further includes: The second acquisition subunit is used to acquire the module configuration file of at least one control module of the target vehicle model, wherein the module configuration file is used to indicate the operating logic of the control module. The second processing subunit is used to parse and load the module configuration file to generate virtual response models corresponding to each control module.

[0060] In some embodiments, the diagnostic testing apparatus further includes: The determination subunit is used to determine the target control module from each of the control modules based on the diagnostic test instructions, and to determine the target virtual response model corresponding to the target control module from the virtual response models corresponding to each of the control modules.

[0061] In some embodiments, the diagnostic testing apparatus further includes: The third processing subunit is used to parse the diagnostic test command through the virtual command parsing module of the diagnostic test system to obtain the parsed diagnostic test command. The third processing subunit is used to send the parsed diagnostic test command to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system.

[0062] In some embodiments, the diagnostic testing apparatus further includes: The fourth processing subunit is used to simulate the target control module's response to the parsed diagnostic test command based on the module configuration file using the target virtual response model, so as to obtain the simulated response result, and use the simulated response result as the running result of the control module corresponding to the diagnostic test command.

[0063] In some embodiments, the module configuration file further includes time control parameters, which are used to control the response time when the target virtual response model simulates the target control module responding to the diagnostic test command.

[0064] In some embodiments, the diagnostic testing apparatus further includes: The third acquisition subunit is used to acquire the specified time scaling parameters; The fourth processing subunit is used to adjust the time control parameters in the module configuration file based on the specified time scaling parameters through the time control module of the diagnostic test system, so as to obtain the adjusted module configuration file.

[0065] In some embodiments, the diagnostic testing apparatus further includes: The fifth processing subunit is used to simulate the target control module's response to the diagnostic test command through the target virtual response model and based on the adjusted module configuration file, so as to obtain the control module's operating result corresponding to the diagnostic test command.

[0066] Using the device of this embodiment, the acquisition unit 201 acquires the diagnostic test command for the target control module of the target vehicle model; the first processing unit 202 sends the diagnostic test command to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system, the target virtual response model being a model generated by simulating the target control module based on the module configuration file of the target control module; the second processing unit 203 simulates the target control module's response to the diagnostic test command through the target virtual response model to obtain the control module's operating result corresponding to the diagnostic test command, and sends the control module's operating result to the virtual vehicle communication interface module; the third processing unit 204 sends the control module's operating result to the diagnostic test module of the diagnostic test system through the virtual vehicle communication interface module, so that the diagnostic test module determines the diagnostic test result corresponding to the diagnostic test command based on the control module's operating result. This application embodiment sets up a virtual vehicle communication interface module and a target virtual response model corresponding to the target control module in the diagnostic test system. When a diagnostic test command for the target control module is obtained, the diagnostic test command can be sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module. The target virtual response model simulates the target control module's response to the diagnostic test command to obtain the control module's operating result corresponding to the diagnostic test command. By setting up a virtual vehicle communication interface module and a target virtual response model corresponding to the target control module in the diagnostic test system, the diagnostic software can be freed from the constraints of physical hardware and the actual vehicle environment when performing diagnostic tests on electronic control units. It can flexibly construct diverse test scenarios according to diagnostic test requirements, significantly reducing diagnostic test and verification costs and greatly improving the efficiency of diagnostic test and verification of automotive diagnostic software.

[0067] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0068] Accordingly, this application also provides a computer device, which can be a terminal, such as a smartphone, tablet computer, laptop computer, touch screen, game console, personal computer (PC), personal digital assistant (PDA), or other terminal device. Alternatively, the electronic device can be a server.

[0069] like Figure 8 As shown, Figure 8This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device 300 includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored in the memory 302 and executable on the processor. The processor 301 and the memory 302 are electrically connected. Those skilled in the art will understand that the computer device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0070] The processor 301 is the control center of the computer device 300. It connects various parts of the computer device 300 via various interfaces and lines. By running or loading software programs and / or units stored in the memory 302, and by calling data stored in the memory 302, it executes various functions of the computer device 300 and processes data, thereby providing overall monitoring of the computer device 300. The processor 301 can be a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), etc., and can implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application.

[0071] In this embodiment, the processor 301 in the computer device 300 loads the instructions corresponding to the processes of one or more applications into the memory 302 according to the following steps, and the processor 301 runs the applications stored in the memory 302 to realize various functions, such as: Obtain diagnostic test instructions for the target control module of the target vehicle model; The diagnostic test command is sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system. The target virtual response model is a model generated by simulating the target control module based on the module configuration file of the target control module. The target virtual response model simulates the target control module's response to the diagnostic test command to obtain the control module's operating result corresponding to the diagnostic test command, and sends the control module's operating result to the virtual vehicle communication interface module. The virtual vehicle communication interface module sends the operation results of the control module to the diagnostic test module of the diagnostic test system, so that the diagnostic test module can determine the diagnostic test result corresponding to the diagnostic test instruction based on the operation results of the control module.

[0072] The computer device provided in this application embodiment can set up a virtual vehicle communication interface module and a target virtual response model corresponding to the target control module in the diagnostic test system. When a diagnostic test command for the target control module is obtained, the diagnostic test command can be sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module. The target virtual response model simulates the target control module's response to the diagnostic test command to obtain the control module's operating result corresponding to the diagnostic test command. By setting up a virtual vehicle communication interface module and a target virtual response model corresponding to the target control module in the diagnostic test system, the diagnostic software can be freed from the constraints of physical hardware and the actual vehicle environment when performing diagnostic tests on electronic control units. It can flexibly construct diverse test scenarios according to diagnostic test requirements, significantly reducing diagnostic test and verification costs and greatly improving the efficiency of diagnostic test and verification of automotive diagnostic software.

[0073] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0074] Optional, such as Figure 8 As shown, the computer device 300 also includes: a touch screen display 303, a radio frequency circuit 304, an audio circuit 305, an input unit 306, and a power supply 307. The processor 301 is electrically connected to the touch screen display 303, the radio frequency circuit 304, the audio circuit 305, the input unit 306, and the power supply 307. Those skilled in the art will understand that... Figure 8 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0075] The touch display screen 303 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 303 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 301. It can also receive and execute commands from the processor 301. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 301 to determine the type of touch event. Subsequently, the processor 301 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the touch display screen 303 to achieve input and output functions. However, in some embodiments, the touch panel and the touch display screen 303 can be implemented as two independent components to achieve input and output functions. That is, the touch display screen 303 can also be used as part of the input unit 306 to achieve input functions.

[0076] The radio frequency circuit 304 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices.

[0077] Audio circuitry 305 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuitry 305 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 305, converted back into audio data, and then processed by processor 301 before being transmitted via radio frequency circuitry 304 to, for example, another electronic device, or output to memory 302 for further processing. Audio circuitry 305 may also include an earphone jack to facilitate communication between peripheral headphones and electronic devices.

[0078] The input unit 306 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0079] Power supply 307 is used to supply power to various components of computer device 300. Optionally, power supply 307 can be logically connected to processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 307 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0080] although Figure 8 As not shown in the diagram, computer equipment 300 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0081] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0082] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0083] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of computer programs, which can be loaded by a processor to execute any of the diagnostic testing methods provided in embodiments of this application. The computer program can perform the steps of the following diagnostic testing method: Obtain diagnostic test instructions for the target control module of the target vehicle model; The diagnostic test command is sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system. The target virtual response model is a model generated by simulating the target control module based on the module configuration file of the target control module. The target virtual response model simulates the target control module's response to the diagnostic test command to obtain the control module's operating result corresponding to the diagnostic test command, and sends the control module's operating result to the virtual vehicle communication interface module. The virtual vehicle communication interface module sends the operation results of the control module to the diagnostic test module of the diagnostic test system, so that the diagnostic test module can determine the diagnostic test result corresponding to the diagnostic test instruction based on the operation results of the control module.

[0084] Because the computer program stored in this storage medium can be configured in the diagnostic test system with a virtual vehicle communication interface module and a target virtual response model corresponding to the target control module, when a diagnostic test command for the target control module is obtained, it can be sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module. The target virtual response model simulates the target control module's response to the diagnostic test command to obtain the control module's operating result corresponding to the diagnostic test command. By configuring the virtual vehicle communication interface module and the target virtual response model corresponding to the target control module in the diagnostic test system, the diagnostic software can be freed from the constraints of physical hardware and the actual vehicle environment when performing diagnostic tests on electronic control units. It can flexibly construct diverse test scenarios according to diagnostic test requirements, significantly reducing diagnostic test and verification costs and greatly improving the efficiency of diagnostic test and verification of automotive diagnostic software.

[0085] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0086] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0087] Since the computer program stored in the computer-readable storage medium can execute any of the diagnostic testing methods provided in the embodiments of this application, it can achieve the beneficial effects that any of the diagnostic testing methods provided in the embodiments of this application can achieve, as detailed in the preceding embodiments, and will not be repeated here.

[0088] According to one aspect of this application, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in the various optional implementations of the above embodiments.

[0089] In some embodiments, this application also provides a controller, including a memory and a processor; thereon storing a computer program, and the processor running the computer program in the memory, which, when executed by the processor, implements the steps in the embodiments of this application.

[0090] In some embodiments, this application also provides a vehicle; the vehicle can send vehicle fault codes to a terminal via a network so that the terminal can execute the diagnostic test method provided in the embodiments of this application; or, the vehicle includes a controller, and the vehicle executes the diagnostic test method provided in the embodiments of this application through the controller.

[0091] It should be noted that all data involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above.

[0092] In the above embodiments of the diagnostic testing apparatus, computer-readable storage medium, computer device, and computer program product, the descriptions of each embodiment have different focuses. Parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes and beneficial effects of the diagnostic testing apparatus, computer-readable storage medium, computer program product, electronic device, and their corresponding units described above can be referred to the description of the diagnostic testing methods in the above embodiments, and will not be repeated here.

[0093] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0094] The above provides a detailed description of a diagnostic testing method, apparatus, electronic device, computer-readable storage medium, and computer program product provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A diagnostic testing method, characterized in that, The method, applied to a diagnostic testing system, includes: Obtain diagnostic test instructions for the target control module of the target vehicle model; The diagnostic test command is sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system. The target virtual response model is a model generated by simulating the target control module based on the module configuration file of the target control module. The target virtual response model simulates the target control module's response to the diagnostic test command to obtain the control module's operating result corresponding to the diagnostic test command, and sends the control module's operating result to the virtual vehicle communication interface module. The virtual vehicle communication interface module sends the operation results of the control module to the diagnostic test module of the diagnostic test system, so that the diagnostic test module can determine the diagnostic test result corresponding to the diagnostic test instruction based on the operation results of the control module.

2. The method according to claim 1, characterized in that, Before obtaining the diagnostic test instructions for the target control module of the target vehicle model, the method further includes: Obtain the module configuration file of the target control module of the target vehicle model, wherein the module configuration file is used to indicate the operating logic of the target control module; The module configuration file is parsed and loaded to generate the target virtual response model of the target control module.

3. The method according to claim 1, characterized in that, Before obtaining the diagnostic test instructions for the target control module of the target vehicle model, the method further includes: Obtain the module configuration file of at least one control module of the target vehicle model, wherein the module configuration file is used to indicate the operating logic of the control module; The module configuration files are parsed and loaded to generate virtual response models corresponding to each control module; After obtaining the diagnostic test instructions for the target control module of the target vehicle model, the method further includes: Based on the diagnostic test instructions, the target control module is determined from each of the control modules, and the target virtual response model corresponding to the target control module is determined from the virtual response models corresponding to each of the control modules.

4. The method according to claim 1, characterized in that, After obtaining the diagnostic test instructions for the target control module of the target vehicle model, the method further includes: The diagnostic test command is parsed by the virtual command parsing module of the diagnostic test system to obtain the parsed diagnostic test command. The parsed diagnostic test command is sent to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system.

5. The method according to claim 4, characterized in that, The step of simulating the target control module's response to the diagnostic test command through the target virtual response model to obtain the control module's operating result corresponding to the diagnostic test command includes: The target virtual response model simulates the target control module's response to the parsed diagnostic test command based on the module configuration file, so as to obtain the simulated response result, and the simulated response result is used as the running result of the control module corresponding to the diagnostic test command.

6. The method according to any one of claims 1 to 5, characterized in that, The module configuration file also includes time control parameters, which are used to control the response time of the target virtual response model when simulating the target control module's response to the diagnostic test command.

7. The method according to claim 6, characterized in that, Before simulating the target control module's response to the diagnostic test command using the target virtual response model to obtain the control module's operating result corresponding to the diagnostic test command, the method further includes: Get the specified time scaling parameters; The time control module of the diagnostic test system adjusts the time control parameters in the module configuration file based on the specified time scaling parameters to obtain the adjusted module configuration file. The step of simulating the target control module's response to the diagnostic test command through the target virtual response model to obtain the control module's operating result corresponding to the diagnostic test command includes: The target control module responds to the diagnostic test command by simulating the target virtual response model and the adjusted module configuration file, so as to obtain the control module operation result corresponding to the diagnostic test command.

8. A diagnostic testing device, characterized in that, Applications in diagnostic testing systems include: The acquisition unit is used to acquire diagnostic test instructions for the target control module of the target vehicle model. The first processing unit is used to send the diagnostic test command to the target virtual response model corresponding to the target control module through the virtual vehicle communication interface module of the diagnostic test system. The target virtual response model is a model generated by simulating the target control module based on the module configuration file of the target control module. The second processing unit is used to simulate the target control module's response to the diagnostic test command through the target virtual response model, so as to obtain the control module's running result corresponding to the diagnostic test command, and send the control module's running result to the virtual vehicle communication interface module. The third processing unit is used to send the operation result of the control module to the diagnostic test module of the diagnostic test system through the virtual vehicle communication interface module, so that the diagnostic test module can determine the diagnostic test result corresponding to the diagnostic test instruction based on the operation result of the control module.

9. A computer device, characterized in that, It includes a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to perform the steps of the diagnostic testing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the diagnostic test method as described in any one of claims 1 to 7.

Images