Vehicle simulation diagnosis method and system, test equipment and storage medium

Abstract

The invention relates to the technical field of vehicle diagnosis, and discloses a vehicle simulation diagnosis method and system, test equipment and a storage medium, and the method comprises the steps that a vehicle simulation tool receives request data of vehicle diagnosis equipment, and forwards the analyzed request data to a client; the client verifies the request data, generates initial diagnosis request data based on the diagnosis rule set, dynamically adjusts and packages the initial diagnosis request data in combination with load state information fed back by the vehicle simulation tool to form a diagnosis data packet, and sends the diagnosis data packet to the vehicle simulation tool; and the vehicle simulation tool receives the diagnosis test data packet and forwards the diagnosis test data packet to the vehicle diagnosis equipment for diagnosis test until the vehicle simulation diagnosis is completed. According to the vehicle simulation diagnosis method, dependence on a real vehicle is reduced, loss caused by frequent testing is avoided, the testing safety is improved, rapid iteration is supported, and the vehicle simulation diagnosis method can adapt to different diagnosis scenes.

Description

Technical Field

[0001] The present application relates to the field of vehicle diagnosis technology, and in particular to a vehicle simulation diagnosis method, system, test equipment and storage medium. Background Art

[0002] In the development process of automotive vehicle diagnostic equipment, traditional methods rely heavily on real vehicle testing to verify the effectiveness of diagnostic software. Developers need to connect vehicle diagnostic equipment to real vehicles, debug software functions through the real vehicle operating environment, verify communication protocol compatibility, and simulate diagnostic responses under different fault scenarios. Although this model can reflect real working conditions, it exposes significant defects in actual applications:

[0003] (1) Low efficiency of real vehicle testing

[0004] Diagnostic software development requires repeated iterations, while real-vehicle testing requires frequent deployment of hardware equipment and connection to vehicle systems, resulting in lengthy debugging cycles. During the testing process, direct operations must be performed on the vehicle, which is limited by vehicle availability, site conditions (e.g., power supply, network), and physical space constraints, which seriously slows down development progress.

[0005] (2) Poor consistency of test results

[0006] Since the vehicle status (e.g., ECU firmware version, sensor data) and environmental conditions (e.g., temperature, voltage fluctuations) of each test are difficult to fully reproduce, the test results of different versions of software lack comparability. For example, the same diagnostic protocol may perform differently in multiple rounds of testing due to bus load fluctuations, making it impossible for developers to accurately locate software defects or optimization effects.

[0007] (3) High human resource costs

[0008] Real vehicle testing requires professional technicians to operate equipment on site, monitor bus data and record abnormalities, and even many people to collaborate in complex scenarios (for example, multi-ECU collaborative diagnosis). In addition, frequent real vehicle testing will accelerate vehicle wear and tear, increase maintenance costs, and real vehicle testing of extreme fault scenarios (for example, short circuit, overvoltage) poses safety risks.

[0009] Therefore, how to build a standardized and repeatable testing environment without relying on real vehicles, achieve efficient verification and iteration of diagnostic software, and reduce testing costs and risks has become a key issue that needs to be urgently addressed in the field of automotive diagnosis. Summary of the invention

[0010] In view of this, the embodiments of the present application provide a vehicle simulation diagnosis method, system, test equipment and storage medium, which can effectively solve the problems of low test efficiency, poor result consistency and high resource consumption caused by strong dependence on real vehicles in the prior art.

[0011] In a first aspect, an embodiment of the present application provides a vehicle simulation diagnosis method, which is applied to a client and includes:

[0012] Receiving request data forwarded by a vehicle simulation tooling, verifying the request data, and generating initial diagnostic request data based on a request matching rule and a response generation policy in a diagnostic rule set;

[0013] According to the load status information monitored and fed back by the vehicle simulation tooling, and in combination with the multi-frame response rules defined in the diagnostic rule set, dynamically adjusting the initial diagnostic request data to generate dynamic diagnostic data;

[0014] Encapsulating the dynamic diagnostic data into a data packet conforming to a target communication protocol, and forwarding the encapsulated diagnostic data packet to a vehicle diagnostic device through the vehicle simulation tooling for diagnostic testing until the vehicle simulation diagnosis is completed.

[0015] In some embodiments, after encapsulating the dynamic diagnostic data into a data packet conforming to a target communication protocol and forwarding the encapsulated diagnostic data packet to a vehicle diagnostic device through the vehicle simulation tooling for diagnostic testing, it further includes:

[0016] Updating the diagnostic test set of the client according to the test result of the vehicle diagnostic device.

[0017] In some embodiments, the receiving request data forwarded by a vehicle simulation tooling, verifying the request data, and generating initial diagnostic request data based on a request matching rule and a response generation policy in a diagnostic rule set includes:

[0018] Receiving the request data forwarded by the vehicle simulation tooling, and parsing the request data to obtain a diagnostic request type and parameters;

[0019] Traversing the preset request matching rules in the diagnostic rule set, obtaining a matching rule entry that is the same as the diagnostic request type and parameters, and extracting corresponding response data content and protocol encapsulation format from the matching rule entry;

[0020] Encapsulating the response data content according to the protocol encapsulation format to generate the initial diagnostic request data.

[0021] In some embodiments, the according to the load status information monitored and fed back by the vehicle simulation tooling, and in combination with the multi-frame response rules defined in the diagnostic rule set, dynamically adjusting the initial diagnostic request data to generate dynamic diagnostic data includes:

[0022] Receiving the current resource load status information fed back by the vehicle simulation tooling;

[0023] Match the current resource load status information with the multi-frame response rules defined in the diagnostic rule set to determine the corresponding adjustment strategy;

[0024] Based on the adjustment strategy, perform multi-frame splitting or frame interval adjustment on the initial diagnostic request data to generate the dynamic diagnostic data.

[0025] In some embodiments, updating the diagnostic test set of the client according to the test result of the vehicle diagnostic device includes:

[0026] According to the test result sent by the vehicle diagnostic device forwarded by the vehicle simulation tooling, modify the parameters of the request matching rule, the response generation strategy, the multi-frame response rule, and the target communication protocol in the diagnostic rule set.

[0027] In a second aspect, an embodiment of the present application provides a vehicle simulation diagnosis method, which is applied to a vehicle simulation tooling and includes:

[0028] Receive the request data sent by the vehicle diagnostic device, parse the request data, and forward the parsed request data to the client, so that the client generates initial diagnostic request data based on the request matching rule and the response generation strategy in the diagnostic rule set;

[0029] Monitor the load status information in real time and feedback the load status information to the client, so that the client dynamically adjusts the initial diagnostic request data according to the load status information to generate dynamic diagnostic data; and encapsulate the dynamic diagnostic data into a data packet conforming to the target communication protocol;

[0030] Receive the diagnostic data packet sent by the client and forward the diagnostic data packet to the vehicle diagnostic device.

[0031] In some embodiments, before receiving the request data sent by the vehicle diagnostic device, it includes:

[0032] Receive the predefined diagnostic rule set sent by the client;

[0033] Parse the predefined diagnostic rule set to obtain the configuration information in the diagnostic rule set, and trigger the initialization configuration of the vehicle simulation tooling according to the configuration information.

[0034] In a third aspect, an embodiment of the present application provides a vehicle simulation diagnosis system, including:

[0035] A vehicle simulation tooling for receiving the request data sent by the vehicle diagnostic device, parsing the request data, and forwarding the parsed request data to the client;

[0036] A client, configured to receive request data forwarded by a vehicle simulation tooling, verify the request data, and generate initial diagnostic request data based on request matching rules and response generation policies in a diagnostic rule set.

[0037] The vehicle simulation tooling is further configured to monitor load status information in real time and feed back the load status information to the client.

[0038] The client is further configured to dynamically adjust the initial diagnostic request data based on the load status information monitored and fed back by the vehicle simulation tooling and in combination with multi-frame response rules defined in the diagnostic rule set to generate dynamic diagnostic data.

[0039] The client is further configured to encapsulate the dynamic diagnostic data into a data packet conforming to a target communication protocol and send the encapsulated diagnostic data packet to the vehicle simulation tooling.

[0040] The vehicle simulation tooling is further configured to receive the diagnostic data packet sent by the client and forward the diagnostic data packet to a vehicle diagnostic device for diagnostic testing until the vehicle simulation diagnosis is completed.

[0041] In a fourth aspect, an embodiment of the present application provides a testing device, which includes a processor and a memory. The memory stores a computer program, and the processor is configured to execute the computer program to implement the vehicle simulation diagnosis method in the first aspect and the second aspect above.

[0042] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium. When the computer program is executed on a processor, the vehicle simulation diagnosis method in the first aspect and the second aspect above is implemented.

[0043] The embodiments of the present application have the following beneficial effects:

[0044] The vehicle simulation diagnosis method of the present application adopts an architecture in which a vehicle simulation tooling collaborates with a client: The vehicle simulation tooling communicates with a vehicle diagnosis device through an interface, is responsible for listening to, parsing, and forwarding the request data of the vehicle diagnosis device, and at the same time monitors its own resource load status in real time and feeds it back to the client; After receiving the request forwarded by the vehicle simulation tooling, the client first verifies the request data, matches the diagnosis rules, and generates initial test data, then dynamically processes the initial diagnosis request data in combination with the load status information fed back by the vehicle simulation tooling, and finally sends the encapsulated diagnosis data packet back to the vehicle simulation tooling; After receiving it, the vehicle simulation tooling forwards the diagnosis data packet to the vehicle diagnosis device for diagnosis testing until the vehicle simulation diagnosis is completed, forming a fast-iterative closed-loop diagnosis testing process. By conducting diagnosis testing in a simulation environment, the present application greatly reduces the usage frequency of real vehicles, avoids wear or failures of vehicles during frequent testing, and saves maintenance and replacement costs. At the same time, extreme fault scenarios or dangerous operations can be safely tested in the simulation environment without worrying about potential risks to real vehicles or personnel. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present application and should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0046] Figure 1 FIG. shows an application scenario diagram of a vehicle simulation diagnosis system according to an embodiment of the present application;

[0047] Figure 2 FIG. shows a flowchart of a vehicle simulation diagnosis system according to an embodiment of the present application;

[0048] Figure 3 FIG. shows a flowchart on the client side in a vehicle simulation diagnosis method according to an embodiment of the present application;

[0049] Figure 4 FIG. shows a flowchart on the vehicle simulation tooling side in a vehicle simulation diagnosis method according to an embodiment of the present application.

[0050] MAIN ELEMENT SYMBOL DESCRIPTION: 10: Client; 20: Vehicle simulation tooling; 30: Vehicle diagnosis device. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0051] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments.

[0052] The components of the embodiments of the present application that are generally described and illustrated in the accompanying drawings herein may be arranged and designed in a variety of different configurations. Accordingly, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed present application, but is merely representative of selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative efforts fall within the scope of protection of the present application.

[0053] In the following, the terms "comprising", "having" and their cognates that may be used in various embodiments of the present application are only intended to denote a specific feature, number, step, operation, element, component or combination of the foregoing items, and should not be construed as precluding the existence or adding the possibility of one or more other features, numbers, steps, operations, elements, components or combinations of the foregoing items at first. In addition, the terms "first", "second", "third", etc. are only used for distinguishing descriptions and cannot be construed as indicating or implying relative importance.

[0054] Unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art to which the various embodiments of the present application belong. The terms (such as those defined in a commonly used dictionary) will be interpreted as having the same meaning as the contextual meaning in the relevant technical field and will not be interpreted as having an idealized meaning or an overly formal meaning unless clearly defined in the various embodiments of the present application.

[0055] The following describes in detail some embodiments of the present application in conjunction with the accompanying drawings. Without conflict, the following embodiments and the features in the embodiments may be combined with each other.

[0056] Considering the problems of low test efficiency, poor result consistency and high resource consumption caused by the strong dependence on real vehicles in existing vehicle diagnosis or test technologies, therefore, the present application proposes a vehicle simulation diagnosis method, that is, a vehicle simulation tooling 20 is designed, and a hierarchical processing architecture for division of labor and cooperation is established between the vehicle simulation tooling 20 and the client 10, such as Figure 1As shown, the vehicle simulation tooling 20 is mainly responsible for listening to the requests of the vehicle diagnostic device 30 and monitoring its own load status in real time, while the client 10 is used for protocol parsing, rule matching, response data generation, and multi-frame splitting. Through this processing architecture, the frequent testing requirements for real vehicles can be reduced, vehicle wear can be minimized, and safety can be enhanced. At the same time, different diagnostic strategies or software versions can be rapidly iterated and verified in a simulated environment, thus realizing a low-risk, low-cost, and highly efficient and flexible automotive diagnostic simulation process. In addition, this division of labor mode can also reduce the design logic complexity of the vehicle simulation tooling 20, while improving the flexibility of the client 10, enabling it to dynamically call updated rules according to each received diagnostic request, achieving rapid iteration and testing, and enhancing the scalability and adaptability of the system, etc.

[0057] Figure 2 The figure shows a flowchart of a vehicle simulation diagnostic system according to an embodiment of the present application. Exemplarily, it includes the following steps:

[0058] Step S100, the vehicle simulation tooling 20 receives the request data sent by the vehicle diagnostic device 30, parses the request data, and forwards the parsed request data to the client.

[0059] Exemplarily, the vehicle simulation tooling 20 establishes a physical connection with the vehicle diagnostic device 30 through the OBDII interface and continuously remains in a listening state to receive the request data sent by the vehicle diagnostic device 30 in real time. When the vehicle simulation tooling 20 detects a diagnostic request frame sent by the vehicle diagnostic device 30, it will perform preliminary parsing and processing on this frame, specifically including but not limited to: verifying the integrity of the frame header, extracting key control bytes, checking the data length and error detection code, to ensure that the received data meets the basic requirements of the target communication protocol (for example, UDS on CAN, ISO-TP, etc.).

[0060] After completing the basic parsing, the vehicle simulation tooling 20 will package the processed request data according to a predefined data encapsulation protocol. Specifically, in the implementation based on the CAN bus protocol, the vehicle simulation tooling 20 will organize the data structure according to the message ID, data length code, and payload field; if the UDS protocol is adopted, it will further identify service IDs, sub-function codes, and additional parameter fields, etc.

[0061] After processing, the vehicle simulation tooling 20 forwards the parsed and encapsulated diagnostic request data to the client 10 through communication interfaces such as USB, serial port, or Ethernet for subsequent operations such as rule matching and response data generation by the client.

[0062] Step S200: The client 10 receives the request data forwarded by the vehicle simulation tooling 20, verifies the request data, and generates initial diagnostic request data based on the request matching rules and response generation policies in the diagnostic rule set.

[0063] Exemplarily, after receiving the request data forwarded by the vehicle simulation tooling 20, the client 10 first verifies the basic format of the request data. For example, it checks whether key elements such as the frame header, data area length, service identifier (SID), and parameter fields match the expected communication protocol. If a field is missing or the data length does not match, the client 10 can directly record and discard the request or generate an error report. Subsequently, the client 10 searches for a policy entry that matches the request type and parameters according to the request matching rules in the diagnostic rule set. If the match is successful, it calls the corresponding response generation policy to assemble the initial diagnostic request data.

[0064] Step S300: The vehicle simulation tooling 20 monitors the load status information in real time and feeds back the load status information to the client 10.

[0065] Exemplarily, the vehicle simulation tooling 20 is built-in with a resource monitoring module for real-time sampling and statistics of its own key resource usage, such as bandwidth occupancy rate, cache usage rate, and processor load. Subsequently, the vehicle simulation tooling 20 packages the monitored resource load status information into a feedback report and sends it to the client 10, so that the client 10 can fully consider the current system load status when generating or adjusting diagnostic test data, improving the efficiency and stability of the overall diagnostic simulation.

[0066] Step S400: The client 10 dynamically adjusts the initial diagnostic request data according to the load status information monitored and fed back by the vehicle simulation tooling 20, in combination with the multi-frame response rules defined in the diagnostic rule set, to generate dynamic diagnostic data.

[0067] Exemplarily, after generating the initial diagnostic request data each time, the client 10 determines the available bandwidth and cache of the current communication environment based on the load status information fed back by the vehicle simulation tooling 20 (such as CPU occupancy rate, memory usage, communication queue depth), and combines the multi-frame response rules in the diagnostic rule set (such as CAN / LIN frame splitting strategy, frame interval parameter) and the requirements of the target communication protocol (such as baud rate, check method) to adjust the initial diagnostic request data, thereby dynamically generating dynamic diagnostic data adapted to the current load status.

[0068] Step S500: The client 10 encapsulates the dynamic diagnostic data into a diagnostic data packet that conforms to the target communication protocol and sends the encapsulated diagnostic data packet to the vehicle simulation tooling 20.

[0069] Exemplarily, the client 10 will add necessary protocol headers, sequence numbers, checksum fields or flow control identifiers to the dynamic diagnostic data according to the frame structure and check mechanism of the target communication protocol; if the protocol requires multi-frame distribution or message merging, the client 10 will also write multi-frame splitting (or merging) information into the message header or specific control fields at this stage. After the above encapsulation is completed, the client 10 will perform a check on the encapsulated data packet. For example, it will check whether the protocol header is complete, whether the length field matches the actual data volume, whether the checksum or CRC is correct, etc. Once confirmed to be correct, the client 10 will send the diagnostic data packet to the vehicle simulation tooling 20 through a communication link (such as a USB cable or Ethernet) connected to the vehicle simulation tooling 20.

[0070] Step S600, the vehicle simulation tooling 20 receives the diagnostic data packet sent by the client 10 and forwards the diagnostic data packet to the vehicle diagnostic device 30 for diagnostic testing until the vehicle simulation diagnosis is completed.

[0071] Exemplarily, after receiving the diagnostic data packet sent by the client 10, the vehicle simulation tooling 20 forwards the diagnostic data packet to the vehicle diagnostic device 30 through the OBDII interface or other standard communication links (such as the CAN physical layer). After receiving the data packet, the vehicle diagnostic device 30 can perform parsing, verification, and diagnosis according to the established protocol to complete the response operation for the simulated diagnostic data in this round.

[0072] It should be noted that when all diagnostic data has been sent and diagnosed, or when it is detected that a preset diagnostic termination condition is met (including but not limited to the number of test rounds reaching the upper limit, the diagnostic coverage rate meeting the requirements, no new abnormal data being found, etc.), it can be determined that the vehicle simulation diagnostic task for the current round has been completed, and the vehicle simulation diagnostic task ends accordingly.

[0073] Figure 3 Shows a flowchart of a vehicle simulation diagnostic method according to an embodiment of the present application. Exemplarily, this method is applied to a client and includes the following steps:

[0074] Step S101, receive the request data forwarded by the vehicle simulation tooling, check the request data, and generate initial diagnostic request data based on the request matching rules and response generation strategies in the diagnostic rule set.

[0075] After the client obtains the request data forwarded by the vehicle simulation tooling, it will first perform a basic check on the request data. If the format is correct, the client will retrieve the request matching rules in the diagnostic rule set to find entries that match the current request type or parameters. After successful matching, the client combines the necessary response information according to the corresponding response generation strategy to generate the initial diagnostic request data.

[0076] In an alternative embodiment, step S101 includes:

[0077] Receiving request data forwarded by a vehicle simulation tooling, and parsing the request data to obtain a diagnostic request type and parameters.

[0078] Exemplarily, after receiving the request data forwarded by the vehicle simulation tooling, the client first performs a verification: including checking whether the data frame header, data length, service identifier (SID), and parameter fields conform to the established communication protocol. If abnormal situations such as missing fields, length mismatches, or checksum errors are found at this stage, the client can directly record an error log or generate an error report to prevent interference with subsequent processes. After passing the verification, the client further parses the data packet to obtain the diagnostic request type (such as "read trouble code UDS $19 service") and necessary parameter fields (such as DTC number, sub-function parameter).

[0079] Traversing the preset request matching rules in the diagnostic rule set, obtaining the matching rule entries that are the same as the diagnostic request type and parameters, and extracting the corresponding response data content and protocol encapsulation format from the matching rule entries.

[0080] Subsequently, the client traverses the preset request matching rules in the diagnostic rule set to obtain the matching rule entries that are the same as the request type and parameters; for example, if the request is "read engine trouble code (DTC P0101)", the "DTC P0101" entry predefined in the rule set is matched. Extract the response data content and protocol encapsulation format corresponding to the preset matching rule entry from the diagnostic rule set.

[0081] Encapsulating the response data content according to the protocol encapsulation format to generate initial diagnostic request data.

[0082] Exemplarily, the client extracts the response data content (such as trouble code status "Confirmed") and protocol encapsulation format (such as CAN frame ID, LIN check mode) from the corresponding entry, and packs the response data content according to the protocol encapsulation format, for example, adding a message header, checksum, or sequence identification information, and finally generating the initial diagnostic request data.

[0083] In the case where no matching rule entry is found, the client can adopt a default processing strategy, for example, returning a general error code, recording it in an error log, or sending a preset "unrecognized request" response to ensure that the system still has a controllable response ability in abnormal scenarios.

[0084] Step S102, dynamically adjusting the initial diagnostic request data according to the load status information monitored and fed back by the vehicle simulation tooling, and combining the multi-frame response rules defined in the diagnostic rule set to generate dynamic diagnostic data.

[0085] Exemplarily, after generating the initial test data, the client will further adjust the initial diagnostic request data according to the resource load status information (such as bandwidth occupancy rate, cache usage rate, processor load, etc.) feedback by the vehicle simulation tooling, in combination with the multi-frame response rules defined in the diagnostic rule set. Specifically, the client may adapt to the current load environment and avoid network congestion or cache overflow by means such as extending the frame interval, splitting large data frames, or injecting random delays. Finally, the dynamic diagnostic data generated by the client can better match the real-time state of the vehicle simulation tooling side, improving the data transmission efficiency and system stability.

[0086] In an alternative embodiment, step S102 includes:

[0087] Receiving the current resource load status information feedback by the vehicle simulation tooling.

[0088] Exemplarily, the client first receives a feedback report containing real-time resource load status information from the vehicle simulation tooling, such as CPU occupancy rate 65%, remaining memory capacity 512KB, and communication queue depth, such as backlog of 10 frames, etc.

[0089] Matching the current resource load status information with the multi-frame response rules defined in the diagnostic rule set to determine the corresponding adjustment strategy.

[0090] Exemplarily, after reading these reports, the client will search for the adjustment strategy corresponding to the current load conditions in the diagnostic rule set to determine the frame splitting strategy or frame interval adjustment method to be executed: for example, when the bandwidth or cache pressure is high, the client may extend the frame interval, delay sending, or split large data frames, thus reducing the resource consumption on the vehicle simulation tooling side; when the load is light, the frame interval can be shortened or some data frames can be merged to improve communication efficiency.

[0091] Performing multi-frame splitting or frame interval adjustment on the initial diagnostic request data based on the adjustment strategy to generate dynamic diagnostic data.

[0092] Exemplarily, according to the adjustment strategy, the initial diagnostic request data is split into multiple frames or the frame interval is adjusted to generate dynamic diagnostic data; specifically, to accelerate the response speed in scenarios with a large frame interval, the client adopts a dynamic loading strategy: when the vehicle simulation tooling receives the first frame of data from the vehicle diagnostic device, the client will parse this first frame and load the corresponding rules in the diagnostic rule set accordingly. When the frame interval exceeds the preset threshold, the client will determine more rule data to be loaded based on the content of the subsequent request frames, so as to complete the strategy preparation in time before the next frame arrives. Since the request frame interval depends on the vehicle diagnostic device, the client can call or update the diagnostic rule set in real time after receiving each frame of data, thereby minimizing unnecessary waiting and improving the response efficiency. Through this "frame interval trigger + dynamic loading" method, the client can not only meet the requirements of the target communication protocol for multi-frame sending and recombination, but also quickly obtain the rule content for processing in the case of large frames or long intervals, achieving efficient multi-frame response and improved communication speed.

[0093] Step S103, encapsulate the dynamic diagnostic data into a data packet conforming to the target communication protocol, and forward the encapsulated diagnostic data packet to the vehicle diagnostic device through the vehicle simulation tooling for diagnostic testing until the vehicle simulation diagnosis is completed.

[0094] After obtaining the dynamic diagnostic data, the client will encapsulate it according to the format requirements of the target communication protocol, including adding necessary protocol headers, frame control information, checksum fields, and possible multi-frame identifiers or sequence numbers. After encapsulation, the client sends the data packet to the vehicle simulation tooling through a communication link (e.g., USB or Ethernet). The vehicle simulation tooling then performs protocol adaptation or encapsulation (e.g., in a CAN or K-Line environment) and forwards the data to the vehicle diagnostic device through the OBDII interface or other physical interfaces, ensuring that the vehicle diagnostic device can correctly parse and respond. After receiving the simulation test data, the vehicle diagnostic device parses, identifies, and processes the diagnostic data packet based on its internal ECU program and protocol parsing logic, and makes a response according to the response mechanism in the established diagnostic protocol (e.g., returns test results, fault code confirmation, status information, etc.). This process can continue until the client determines that this round of simulation test reaches the termination condition, such as completing all rule coverage, reaching the preset number of frames, receiving the target response, or meeting the protocol test integrity requirements, thus completing a vehicle simulation diagnosis process.

[0095] That is, the vehicle diagnostic device conducts tests based on the diagnostic rule set and generates corresponding simulation data according to the response logic of the ECU and returns it to the vehicle simulation tooling. The vehicle simulation tooling then encapsulates and transmits the response data to the client, which can be used for further rule optimization and debugging after parsing.

[0096] In an alternative embodiment, after step S103, it includes:

[0097] Update the diagnostic test set of the client according to the test results of the vehicle diagnostic device.

[0098] Based on the test results of the vehicle diagnostic device, update the request matching rule response generation strategy, multi-frame response rule, and target communication protocol in the diagnostic rule set. Specifically, if the test results indicate situations such as detecting a fault code or field anomaly, the response frame not conforming to the expected protocol format, or incorrect multi-frame response timing, etc., the relevant parameters of the request matching rule, response generation strategy, multi-frame response rule, and target communication protocol in the diagnostic rule set will be updated accordingly. The updated rule set is stored and called in the next diagnostic simulation test, thereby realizing a fast iteration and continuously optimized simulation process.

[0099] In an alternative implementation manner, updating the diagnostic test set of the client according to the test results of the vehicle diagnostic device includes:

[0100] Modify the parameters of the request matching rule, response generation strategy, multi-frame response rule, and target communication protocol in the diagnostic rule set according to the test results sent by the vehicle diagnostic device forwarded by the vehicle simulation tooling.

[0101] Exemplarily, the test results may include situations such as request matching failure, fault code or sensor data anomaly, multi-frame response anomaly, protocol verification failure, or communication error. Based on the parsed test results, the client determines whether it is necessary to adjust the parameters of the request matching rule, response generation strategy, multi-frame response rule, and target communication protocol in the diagnostic rule set. If the test results indicate that the request data field matching fails, for example, the data format does not meet the expectation, a field is missing, or the field order is incorrect, the client adjusts the request matching rule. The adjustment methods include optimizing the field mapping relationship, adjusting the data format (e.g., converting the format of integers and floating-point numbers), and complementing the missing fields (e.g., adding necessary identifier fields) to ensure that the request data meets the expected requirements of the vehicle diagnostic device.

[0102] If the test results indicate a fault code or sensor data anomaly, for example, the fault code is not recognized or the sensor data deviates from the reasonable range, the client modifies the response generation strategy. The adjustment methods include updating the fault code mapping table (e.g., adding new fault code categories), adjusting the simulated data generation rule (e.g., improving the sensor data calculation model), or optimizing the calculation logic to ensure that the simulated generated data better meets the actual needs of the vehicle diagnostic device.

[0103] If the test result indicates abnormal multi-frame response, for example, the vehicle diagnostic device reports that the frame interval does not meet the protocol requirements, or the segmentation strategy causes data parsing errors, the client will redefine the multi-frame response rules. The adjustment methods include adjusting the continuous frame sending interval (for example, increasing the frame interval to avoid data loss), optimizing the data segmentation strategy (for example, splitting large data packets into small frames for sending), or modifying the frame control field (for example, adjusting the sending logic of flow control frames), to ensure that the multi-frame response meets the requirements of the target communication protocol.

[0104] If the test result indicates protocol verification failure or communication error, for example, message format mismatch, checksum error, data frame loss, the client will modify the relevant parameters of the target communication protocol. The adjustment methods include modifying the frame format (for example, adjusting the data packet structure), optimizing the message header structure (for example, adding a protocol identifier), or modifying the verification method (for example, replacing the CRC verification algorithm), to ensure that the data can be correctly recognized and parsed by the vehicle diagnostic device during transmission.

[0105] After completing the above rule adjustments, the client will store the updated parameters in the diagnostic rule set and apply them to the next round of diagnostic simulation tests. In this way, through continuous optimization, it can be ensured that the diagnostic simulation test data is consistent with the requirements of the vehicle diagnostic device, improving the accuracy and adaptability of the test.

[0106] For example, during the vehicle simulation diagnostic interaction, the vehicle simulation tooling completes the request recognition and response generation of diagnostic data according to the diagnostic rule set. As the following examples:

[0107] Req:04 E8 80 03 19 02 09

[0108] ans:04 C8 80 03 59 02 09

[0109] Req:04 EB E0 03 22 F0 80

[0110] ans:MN 08 CB E0 10 19 62 F0 80 98 13 35

[0111] Req:03 EB E0 30 00 00

[0112] ans:1n 08 CB E0 21 41 80 00 02 98 36 54

[0113] ans:1n 08 CB E0 22 89 80 13 85 FF FF FF

[0114] ans:08 CB E0 23 01 FF FF FF FF 00 00

[0115] Among them, Req: represents the diagnostic request sent by the vehicle diagnostic device, and ans: represents the response content of the vehicle simulation tooling. When the vehicle simulation tooling receives a request frame, it will retrieve the response content that matches the request from the diagnostic rule set and make a response.

[0116] In the case of a single-frame request, for example:

[0117] Req:04 E8 80 03 19 02 09

[0118] ans:04 C8 80 03 59 02 09

[0119] The vehicle diagnostic device sends "04 E8 80 03 19 02 09" as a request frame. The vehicle simulation tooling parses this request, looks up the corresponding single-frame response in the diagnostic rule set, and then returns "04 C8 80 03 59 02 09" as the response data. Both this request and the response conform to the single-frame transmission format and are applicable to short data interactions, such as ECU version query, single-time reading of fault codes, etc.

[0120] In the scenario of multi-frame response, for example:

[0121] Req:04 EB E0 03 22 F0 80

[0122] ans:MN 08 CB E0 10 19 62 F0 80 98 13 35

[0123] Req:03 EB E0 30 00 00

[0124] ans:1n 08 CB E0 21 41 80 00 02 98 36 54

[0125] ans:1n 08 CB E0 22 89 80 13 85 FF FF FF

[0126] ans:08 CB E0 23 01 FF FF FF FF 00 00

[0127] When the diagnostic device sends "04EB E0 03 22F0 80" as a request frame, the vehicle simulation tooling recognizes that the response data for this request is relatively long and not suitable for single-frame transmission. Therefore, it returns a multi-frame response:

[0128] The "MN" indicates that this response is the start frame of multiple frames, that is, the vehicle simulation tooling is ready to send multiple response frames, and the content of the first frame is "08CB E0 10 19 62F0 80 98 13 35".

[0129] The vehicle diagnostic device then sends a flow control frame "03EB E0 30 0000", allowing the vehicle simulation tooling to continue sending subsequent data frames.

[0130] The vehicle simulation tooling sequentially sends the remaining data:

[0131] Frame number 1 (1n): "08CB E0 21 41 80 00 02 98 36 54"

[0132] Frame number 2 (1n): "08CB E0 22 89 80 13 85FF FF FF"

[0133] Final frame: "08CB E0 23 01FF FF FF FF 00 00"

[0134] During the entire multi-frame transmission process, the vehicle simulation tooling strictly follows the UDS on CAN (ISO-TP) protocol to ensure that the data is fragmented and transmitted according to the regulations of the flow control frame, and uses "1n" to identify the subsequent frame numbers to ensure the integrity of the response data and the protocol consistency.

[0135] Through the diagnostic rule set, the vehicle simulation tooling can accurately identify the request data, match the response content, and perform data encapsulation and transmission according to the protocol rules, so as to realize the efficient simulation of the real ECU diagnostic response.

[0136] It can be understood that the method of this embodiment corresponds to the operations performed by the client in the system of the above embodiment. The optional items regarding the client in this embodiment also apply to the above embodiment, so they will not be repeated here.

[0137] In an alternative embodiment, before step S201 and before receiving the request data sent by the vehicle simulation tooling, it includes:

[0138] Receiving a predefined diagnostic rule set sent by the client;

[0139] Parsing the predefined diagnostic rule set to obtain the configuration information in the diagnostic rule set, so as to trigger the vehicle simulation tooling to perform initialization configuration according to the configuration information.

[0140] Exemplarily, a predefined set of diagnostic rules sent by the client is received. This set of diagnostic rules contains multiple parameter information: the target communication protocol type (e.g., UDS on CAN), communication baud rate (e.g., 500 kbps), pin definitions of the OBDII interface (e.g., CAN_H / CAN_L), the correspondence between request IDs and response IDs, response frame structure, etc.

[0141] After the vehicle simulation tooling successfully receives the set of diagnostic rules, it first parses and validates the syntax and structure of the rule set to ensure its content is complete and the format is legal. For example, the simulation tooling will verify whether the communication protocol field is a supported type, whether the communication pins are clearly defined, whether the ID matching relationships exist in pairs, etc.

[0142] After completing the above verification work, the vehicle simulation tooling extracts the required configuration information from the rule set and, based on this, automatically performs initialization operations for the communication interface, including selecting the target protocol type, configuring the physical communication channel, setting baud rate parameters, etc., so that the vehicle simulation tooling is in a "ready state", providing a reliable communication foundation for subsequent receiving requests from vehicle diagnostic devices, performing forwarding and responses.

[0143] Figure 4 A flowchart of a vehicle simulation diagnostic method according to an embodiment of the present application is shown. Exemplarily, this method is applied to vehicle simulation tooling and includes the following steps:

[0144] Step S201, receive the request data sent by the vehicle diagnostic device, parse the request data, and forward the parsed request data to the client, so that the client generates initial diagnostic request data based on the request matching rules and response generation strategies in the set of diagnostic rules;

[0145] Exemplarily, the vehicle simulation tooling is physically connected to the vehicle diagnostic device through the OBDII interface and is in a listening state to obtain the request data sent by the vehicle diagnostic device in real time. When it detects that a new request frame arrives, the vehicle simulation tooling first performs a preliminary analysis of the data, checks basic elements such as the frame header, protocol identifier, and data length of the data, and performs data conversion or repackaging on it according to the predefined communication protocol. For example, for diagnostic instructions under the CAN protocol, the vehicle simulation tooling will read the frame ID, data field, and verify the CRC check; if the data is legal, the processed request data will be forwarded to the client through a USB or network communication link.

[0146] Step S202, monitor the load status information in real time and feedback the load status information to the client, so that the client dynamically adjusts the initial diagnostic request data according to the load status information to generate dynamic diagnostic data; and encapsulate the dynamic diagnostic data into a data packet that conforms to the target communication protocol.

[0147] Specifically, the vehicle simulation tooling periodically or event-triggeredly monitors its internal resource usage, including key metrics such as bandwidth occupancy, memory or cache queue length, and processor load. When it is found that these metrics reach or exceed the preset thresholds, the vehicle simulation tooling generates a resource load report and sends the report to the client through a USB or network interface. After receiving this load status information, the client combines the request matching rules, response generation strategies, multi-frame response rules, and target communication protocols in the diagnostic rule set to decide on dynamic adjustment methods such as segmenting the request data, delaying the transmission, or changing the frame interval, so as to generate dynamic diagnostic data adapted to the current load condition.

[0148] Step S203: Receive the diagnostic data packet sent by the client and forward the diagnostic data packet to the vehicle diagnostic device.

[0149] Exemplarily, after the client generates and sends the diagnostic data packet, the vehicle simulation tooling receives the data packet again and performs physical layer or link layer encapsulation and adaptation operations according to the target communication protocol. Then, the encapsulated data is sent to the vehicle diagnostic device through the OBDII interface, ensuring that the vehicle diagnostic device can correctly parse and respond to the test data.

[0150] It can be understood that the method of this embodiment corresponds to the operations performed by the simulation tooling in the system of the above embodiment. The optional items regarding the simulation tooling in this embodiment are also applicable to the above embodiment, so they will not be repeated here.

[0151] This application also provides a test device. Exemplarily, the test device includes a processor and a memory. Among them, the memory stores a computer program, and the processor runs the computer program to enable the test device to execute the functions of the above method or each module in the above system.

[0152] Among them, the processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc., and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0153] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electric Erasable Programmable Read-Only Memory (EEPROM), etc. Among them, the memory is used to store a computer program, and after receiving an execution instruction, the processor can execute the computer program accordingly.

[0154] This application also provides a computer-readable storage medium for storing the computer program used in the above test device. For example, the computer-readable storage medium may include, but is not limited to: USB flash drives, mobile hard disks, Read-Only Memory (ROM), Random Access Memory (RAM), magnetic disks, or optical discs and other media that can store program codes.

[0155] In several embodiments provided by this application, it should be understood that the disclosed systems and methods can also be implemented in other ways. The system embodiments described above are merely illustrative. For example, the flowcharts and structure diagrams in the drawings show the possible architectures, functions, and operations of systems, methods, and computer program products according to multiple embodiments of this application. In this regard, each block in the flowchart or block diagram can represent a module, a program segment, or a part of code, and the module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in an alternative implementation, the functions marked in the blocks may occur in a different order than marked in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and they can sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the structure diagram and / or flowchart, as well as the combination of blocks in the structure diagram and / or flowchart, can be implemented by a dedicated hardware-based system that executes the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0156] In addition, in each embodiment of this application, each functional module or unit can be integrated together to form an independent part, or each module can exist alone, or two or more modules can be integrated to form an independent part.

[0157] When the above-described functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a test device to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0158] As described above, the above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present application can easily think of changes or substitutions, which should all be covered within the protection scope of the present application.

Claims

1. A vehicle simulation diagnosis method, characterized in that: Applied to a client, the method comprises: Receiving request data forwarded by the vehicle simulation tooling, verifying the request data, and generating initial diagnostic request data based on a request matching rule and a response generation strategy in a diagnostic rule set; According to the load state information monitored and fed back by the vehicle simulation tooling, in combination with the multi-frame response rule defined in the diagnosis rule set, the initial diagnosis request data is dynamically adjusted to generate dynamic diagnosis data; The dynamic diagnostic data is encapsulated into a data packet that complies with the target communication protocol, and the encapsulated diagnostic data packet is forwarded to the vehicle diagnostic equipment through the vehicle simulation tooling for diagnostic testing until the vehicle simulation diagnosis is completed.

2. The vehicle simulation diagnosis method according to claim 1, characterized in that: After encapsulating the dynamic diagnostic data into a data packet that complies with the target communication protocol, and forwarding the encapsulated diagnostic data packet to the vehicle diagnostic device for diagnostic testing via the vehicle simulation tooling, the method further includes: The diagnostic test set of the client is updated according to the test result of the vehicle diagnostic device.

3. The vehicle simulation diagnosis method according to claim 1, characterized in that: The receiving of the request data forwarded by the vehicle simulation tooling, verifying the request data, and generating initial diagnosis request data based on the request matching rule and the response generation strategy in the diagnosis rule set, includes: Receiving request data forwarded by the vehicle simulation tooling, parsing the request data to obtain a diagnosis request type and parameters; Traversing the preset request matching rules in the diagnostic rule set, obtaining matching rule entries with the same type and parameters as the diagnostic request, and extracting corresponding response data content and protocol encapsulation format from the matching rule entries; The response data content is encapsulated according to the protocol encapsulation format to generate the initial diagnosis request data.

4. The vehicle simulation diagnosis method according to claim 1, characterized in that: The method of dynamically adjusting the initial diagnostic request data according to the load state information monitored and fed back by the vehicle simulation tooling and combining the multi-frame response rule defined in the diagnostic rule set to generate dynamic diagnostic data includes: Receiving current resource load status information fed back by the vehicle simulation tooling; Matching the current resource load status information with the multi-frame response rule defined in the diagnostic rule set to determine a corresponding adjustment strategy; Based on the adjustment strategy, the initial diagnosis request data is split into multiple frames or the frame interval is adjusted to generate the dynamic diagnosis data.

5. The vehicle simulation diagnosis method according to claim 2, characterized in that: The updating of the diagnostic test set of the client according to the test result of the vehicle diagnostic device comprises: According to the test results sent by the vehicle diagnostic device and forwarded by the vehicle simulation tooling, parameters of the request matching rule, the response generation strategy, the multi-frame response rule and the target communication protocol in the diagnostic rule set are modified.

6. A vehicle simulation diagnosis method, characterized in that: Applied to vehicle simulation tooling, the method comprises: Receiving request data sent by the vehicle diagnostic device, parsing the request data, and forwarding the parsed request data to the client, so that the client generates initial diagnostic request data based on the request matching rule and response generation strategy in the diagnostic rule set; monitoring load status information in real time, and feeding back the load status information to the client, so that the client dynamically adjusts the initial diagnostic request data according to the load status information to generate dynamic diagnostic data; and encapsulating the dynamic diagnostic data into a data packet that complies with the target communication protocol; Receive the diagnostic data packet sent by the client, and forward the diagnostic data packet to the vehicle diagnostic device.

7. The vehicle simulation diagnosis method according to claim 6, characterized in that: Before receiving the request data sent by the vehicle diagnostic device, the method includes: Receiving a predefined diagnostic rule set sent by the client; The predefined diagnostic rule set is parsed to obtain configuration information in the diagnostic rule set, so as to trigger the vehicle simulation tooling to perform initialization configuration according to the configuration information.

8. A vehicle simulation diagnostic system, characterized in that: The system comprises: The vehicle simulation tool is used to receive the request data sent by the vehicle diagnostic device, parse the request data, and forward the parsed request data to the client; The client is used to receive the request data forwarded by the vehicle simulation tooling, verify the request data, and generate initial diagnosis request data based on the request matching rules and response generation strategy in the diagnosis rule set; The vehicle simulation tool is also used to monitor load status information in real time and feed back the load status information to the client; The client is further configured to dynamically adjust the initial diagnostic request data according to the load status information monitored and fed back by the vehicle simulation tooling and in combination with a multi-frame response rule defined in the diagnostic rule set to generate dynamic diagnostic data; The client is further used to encapsulate the dynamic diagnostic data into a data packet that complies with the target communication protocol, and send the encapsulated diagnostic data packet to the vehicle simulation tooling; The vehicle simulation tool is also used to receive the diagnostic data packet sent by the client, and forward the diagnostic data packet to the vehicle diagnostic device for diagnostic testing until the vehicle simulation diagnosis is completed.

9. A testing device, characterized in that: The test device comprises a processor and a memory, wherein the memory stores a computer program, and the processor is configured to execute the computer program to implement the vehicle simulation diagnosis method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The device stores a computer program, which, when executed on a processor, implements the vehicle simulation diagnosis method according to any one of claims 1 to 7.

Images