Vehicle diagnostic method and system, vehicle and storage medium

Abstract

This application provides a vehicle diagnostic method and system, a vehicle, and a storage medium, belonging to the field of vehicle technology. The method includes: a user terminal sending a diagnostic request to an in-vehicle controller via a gateway controller; the in-vehicle controller executing a diagnostic operation based on the diagnostic request and generating diagnostic response data; the user terminal receiving the diagnostic response data and sending it to the cloud; the cloud interpreting the diagnostic response data to obtain diagnostic interpretation information; and the user terminal receiving and displaying the diagnostic interpretation information. This application enables real-time vehicle diagnostics, improves diagnostic accuracy and boundary conditions, and provides diagnostic basis for vehicle maintenance, thereby improving vehicle maintenance efficiency and accuracy.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to a vehicle diagnostic method and system, a vehicle, and a storage medium. Background Technology

[0002] In related technologies, vehicle diagnostics rely on the physical wiring harness connection of the vehicle's diagnostic interface. The diagnostic tool must establish a local area network (LAN) bus connection with the vehicle before reading fault indicators collected by the electronic control unit. Therefore, users must drive or tow their vehicles to a local repair shop equipped with professional diagnostic tools to establish a diagnostic session via a wired connection. This fixed "vehicle-person-shop" three-in-one diagnostic model not only significantly increases the time and economic costs of troubleshooting but also prevents the active triggering of diagnostic commands while the vehicle is in motion. Consequently, the fault indicators obtained by wired diagnostics cannot reproduce transient anomalies during driving, affecting the accuracy and efficiency of fault diagnosis.

[0003] In summary, the vehicle diagnostic methods in related technologies need to be improved. Summary of the Invention

[0004] The main objective of this application is to provide a vehicle diagnostic method and system, a vehicle, and a storage medium, which aims to improve the convenience and accuracy of vehicle diagnostics and also increase vehicle maintenance efficiency.

[0005] To achieve the above objectives, one aspect of this application provides a vehicle diagnostic method, the method comprising: The user sends a diagnostic request to the in-vehicle controller via the gateway controller; The in-vehicle controller performs diagnostic operations and generates diagnostic response data based on the diagnostic request. The user terminal receives the diagnostic response data and sends the diagnostic response data to the cloud; The cloud platform interprets and processes the diagnostic response data to obtain diagnostic interpretation information. The user terminal receives and displays the diagnostic interpretation information.

[0006] In some embodiments, the in-vehicle controller performs diagnostic operations and generates diagnostic response data based on the diagnostic request, including: The in-vehicle controller parses the diagnostic request to obtain request parsing information; wherein, the request parsing information includes: diagnostic switching command, vehicle version reading command, and fault reading command; The in-vehicle controller verifies the diagnostic request based on the diagnostic switching command, the vehicle version reading command, and the fault reading command to obtain request verification information; wherein, the request verification information indicates whether the diagnostic request is valid or invalid. If the request verification information indicates that the diagnostic request is valid, the in-vehicle controller performs diagnostic operations and generates the diagnostic response data according to the diagnostic switching instruction, the vehicle version reading instruction, and the fault reading instruction.

[0007] In some embodiments, if the request verification information indicates that the diagnostic request is valid, the in-vehicle controller performs a diagnostic operation and generates the diagnostic response data according to the diagnostic switching instruction, the vehicle version reading instruction, and the fault reading instruction, including: If the request verification information indicates that the diagnostic request is valid, the in-vehicle controller reads the version number according to the vehicle version reading instruction to obtain the target version number; The in-vehicle controller reads the fault code according to the diagnostic switching command and the fault reading command. The in-vehicle controller concatenates the target version number and the fault code to obtain the diagnostic response data.

[0008] In some embodiments, the cloud performs interpretation processing on the diagnostic response data to obtain diagnostic interpretation information, including: The cloud platform parses the diagnostic response data to obtain response parsing information; wherein, the response parsing information includes: target version number and fault code; The cloud extracts reference diagnostic parsing configuration parameters from a preset diagnostic parsing configuration library based on the target version number; The cloud platform selects the target fault description information from the preset candidate fault description information based on the fault code; The cloud platform compares the target version number with the preset version number to obtain version comparison information; The cloud platform constructs the diagnostic interpretation information based on the reference diagnostic parsing configuration parameters, the target fault description information, the version comparison information, and the target version number.

[0009] In some embodiments, the cloud constructs the diagnostic interpretation information based on the reference diagnostic parsing configuration parameters, the target fault description information, the version comparison information, and the target version number, including: The cloud platform classifies faults based on the reference diagnostic parsing configuration parameters, the target fault description information, and the version comparison information to obtain fault categories. The cloud platform performs fault root cause prediction based on the reference diagnostic parsing configuration parameters, the target fault description information, and the version comparison information to obtain fault root cause prediction information. The cloud platform encapsulates the target version number, the target fault description information, the fault category, and the fault root cause prediction information to obtain the diagnostic interpretation information.

[0010] In some embodiments, the user terminal sends a diagnostic request to the in-vehicle controller via the gateway controller, including: The user terminal sends the diagnostic request to the gateway controller; The gateway controller selects the in-vehicle controller from a preset pool of candidate controllers based on the request identifier of the diagnostic request. The gateway controller sends the diagnostic request to the in-vehicle controller.

[0011] In some embodiments, after the user receives and displays the diagnostic interpretation information, the method further includes: In response to the user's confirmation of the diagnostic interpretation information, the user terminal sends a repair appointment request to the cloud. The cloud sends the repair appointment request to the repair terminal and receives the appointment feedback information from the repair terminal. The cloud platform sends the reservation feedback information to the user's terminal.

[0012] To achieve the above objectives, another aspect of this application provides a vehicle diagnostic system, the system comprising: a user terminal, an in-vehicle gateway, a vehicle, and a cloud; the gateway includes a gateway controller, and the vehicle includes an in-vehicle controller; The user terminal is used to send diagnostic requests to the in-vehicle controller via the gateway controller; The in-vehicle controller is used to perform diagnostic operations and generate diagnostic response data according to the diagnostic request; The user terminal is also used to receive the diagnostic response data and send the diagnostic response data to the cloud; The cloud platform is used to interpret and process the diagnostic response data to obtain diagnostic interpretation information. The user terminal is also used to receive and display the diagnostic interpretation information.

[0013] To achieve the above objectives, another aspect of this application provides a vehicle, which includes a body, an in-vehicle controller, and an in-vehicle memory. The in-vehicle memory stores a computer program, and the in-vehicle controller executes the computer program to implement the above-described method.

[0014] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0015] The embodiments of this application include at least the following beneficial effects: This application provides a vehicle diagnostic method and system, a vehicle, and a storage medium. This solution constructs a closed-loop remote diagnostic chain of "user terminal—vehicle gateway—in-vehicle controller—cloud." First, the user terminal actively sends diagnostic commands to the in-vehicle controller via the gateway controller, breaking through the spatial limitations of traditional diagnostics that require a physical connection to the repair station. This makes diagnostic triggering no longer geographically restricted and can effectively capture intermittent faults. Then, the user terminal transfers the acquired diagnostic response data to the cloud, giving full play to the powerful storage and computing resources of the cloud. This allows for in-depth interpretation and intelligent reasoning of the original fault codes and related data, overcoming the limitations of traditional equipment that only outputs simple codes and lacks historical data support. Finally, a structured and visualized diagnostic report is sent back to the user terminal for display. This not only significantly improves the accuracy of fault diagnosis and the work efficiency of repair personnel, but also realizes a real-time closed loop in the diagnostic process and full lifecycle traceability of vehicle health status, significantly enhancing the intelligence level, communication reliability, and user experience of the remote diagnostic system. Attached Figure Description

[0016] Figure 1 This is a system framework diagram of the vehicle diagnostic method provided in the embodiments of this application; Figure 2 This is a flowchart of the vehicle diagnostic method provided in the embodiments of this application; Figure 3 yes Figure 2 The flowchart of step S201 in the text; Figure 4 yes Figure 2 The flowchart of step S202 in the text; Figure 5 yes Figure 4 The flowchart of step S403 in the process; Figure 6 yes Figure 2 The flowchart of step S204 in the process; Figure 7 yes Figure 6 The flowchart of step S605 in the process; Figure 8 This is a flowchart of a vehicle diagnostic method provided in another embodiment of this application; Figure 9 This is a schematic diagram showing the diagnostic interpretation information in the vehicle diagnostic method provided in this application embodiment; Figure 10 This is an overall flowchart of the vehicle diagnostic method provided in the embodiments of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0018] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0019] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0021] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0022] 1) Diagnostic Trouble Code (DTC): A standardized digital code used by the vehicle's electronic control unit (ECU) to identify specific fault states and to quickly locate vehicle problems.

[0023] 2) Electronic Control Unit (ECU): This is the core electronic component of modern automobiles, often referred to as the "brain" of the car. The ECU is an embedded computer system that manages various vehicle functions by receiving and processing signals from various sensors and precisely controlling actuators.

[0024] In related technologies, vehicle fault diagnosis heavily relies on physical spatial intersections. Once a vehicle's electronic control system generates a fault indication, the user must drive or tow the entire vehicle to an offline repair shop equipped with professional diagnostic equipment to establish a diagnostic session via a wired connection. This fixed "vehicle-person-shop" three-in-one diagnostic model not only significantly increases the time and economic costs of fault diagnosis, but more importantly, it cannot proactively trigger diagnostic commands during the vehicle's dynamic operation. Because faults are often intermittent, when the vehicle arrives at the repair center, the fault codes captured by the on-site wired diagnostics often cannot reproduce the transient anomalies encountered en route, resulting in a large number of intermittent faults going undetected in a timely manner.

[0025] In view of this, this application provides a vehicle diagnostic method and system, a vehicle, and a storage medium. By constructing a closed-loop remote diagnostic chain of "user terminal - gateway controller - in-vehicle controller - cloud," the user terminal first actively sends a diagnostic request to the in-vehicle controller via the gateway controller, breaking through the spatial limitations of traditional diagnostics that require a physical connection to a repair station. This allows diagnostic triggering to be no longer geographically restricted and can effectively capture intermittent faults. The diagnostic response data acquired by the user terminal is then transferred to the cloud, fully leveraging the powerful storage and computing resources of the cloud to perform in-depth interpretation and intelligent reasoning on the original fault codes and related data. This overcomes the limitations of traditional equipment that only outputs simple codes and lacks historical data support. Finally, a structured and visualized diagnostic report is sent back to the user terminal for display. This not only significantly improves the accuracy of fault diagnosis and the work efficiency of repair personnel, saving manpower, but also achieves a real-time closed-loop diagnostic process and full lifecycle traceability of vehicle health status, significantly enhancing the intelligence level, communication reliability, and user experience of the remote diagnostic system.

[0026] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user will be obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent will the necessary user-related data for the normal operation of the embodiments of this application be obtained.

[0027] Figure 1 This is a system framework diagram of the vehicle diagnostic method provided in the embodiments of this application. Figure 1The system includes a user terminal 101, an in-vehicle gateway 102, a vehicle 103, and a cloud platform 104. The in-vehicle gateway 102 includes a gateway controller 121, and the vehicle 103 includes a bus controller and an in-vehicle controller 131. The user terminal 101 controls the gateway controller 121 to diagnose the in-vehicle controller 131 and obtains diagnostic results. The in-vehicle controller 131 transmits the diagnostic results to the user terminal 101, which then transmits the diagnostic results to the cloud platform 104. The cloud platform 104 interprets the diagnostic results based on its database and generates a diagnostic report based on the interpretation results.

[0028] By constructing a vehicle diagnostic system consisting of a user terminal 101, an on-board gateway 102, a vehicle 103, and a cloud platform 104, and remotely controlling the gateway controller 121 via the user terminal 101, vehicle diagnostics can be performed anytime, anywhere, significantly improving diagnostic efficiency, convenience, and accuracy. Furthermore, remote data sharing and in-depth diagnostic analysis are achieved through the user terminal 101 and the cloud platform 104, providing repair personnel with diagnostic information far exceeding that of simple fault codes.

[0029] The user terminal 101 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The cloud terminal 104 can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will now be described in detail through specific embodiments.

[0030] Figure 2 This is an optional flowchart of the vehicle diagnostic method provided in the embodiments of this application. Figure 2 The method may include, but is not limited to, steps S201 to S205.

[0031] Step S201: The user terminal sends a diagnostic request to the in-vehicle controller through the gateway controller; In step S202, the in-vehicle controller performs diagnostic operations and generates diagnostic response data based on the diagnostic request; Step S203: The user terminal receives the diagnostic response data and sends the diagnostic response data to the cloud; Step S204: The cloud interprets and processes the diagnostic response data to obtain diagnostic interpretation information; Step S205: The user terminal receives and displays the diagnostic interpretation information.

[0032] Steps S201 to S205 of this application embodiment construct a closed-loop remote diagnostic chain of "user terminal—vehicle gateway—in-vehicle controller—cloud." First, the user terminal actively sends diagnostic commands to the in-vehicle controller via the gateway controller, breaking through the spatial limitations of traditional diagnostics requiring a physical connection to a repair station. This frees diagnostic triggering from geographical constraints and effectively captures intermittent faults. Then, the user terminal relays the acquired diagnostic response data to the cloud, fully leveraging the cloud's powerful storage and computing resources to perform in-depth interpretation and intelligent reasoning of the original fault codes and related data. This overcomes the limitations of traditional equipment that only outputs simple codes and lacks historical data support. Finally, a structured and visualized diagnostic report is sent back to the user terminal for display. This not only significantly improves the accuracy of fault diagnosis and the work efficiency of repair personnel but also achieves a real-time closed-loop diagnostic process and full lifecycle traceability of vehicle health status, significantly enhancing the intelligence level, communication reliability, and user experience of the remote diagnostic system.

[0033] In step S201 of some embodiments, before the user terminal sends a diagnostic request, after the gateway controller starts up and establishes a communication connection with the user terminal, the user terminal needs to perform initialization operations. Initialization operations include: clock configuration, peripheral initialization, communication parameter configuration, and memory preparation. Clock configuration ensures correct module timing; peripheral initialization configures the hardware modules related to communication between the user terminal and the vehicle; communication parameter configuration sets the baud rate, data frame format, filter, and mask of the user terminal's CAN bus; and memory preparation allocates transmit and receive buffers on the user terminal.

[0034] Please see Figure 3 In some embodiments, step S201 may include, but is not limited to, steps S301 to S303: Step S301: The user sends a diagnostic request to the gateway controller; Step S302: The gateway controller selects the in-vehicle controller from the preset candidate controllers based on the request identifier of the diagnostic request. In step S303, the gateway controller sends a diagnostic request to the in-vehicle controller.

[0035] In steps S301-S302 of some embodiments, the user sends a diagnostic request to the gateway controller via a user terminal. Upon receiving the diagnostic request, the gateway controller, running its internal communication protocol stack, can correctly identify, verify, and fully receive the diagnostic request from the user terminal. Furthermore, the gateway controller, based on vehicle bus protocols such as CAN / LIN / FlexRay, unpacks and repackages the diagnostic request to ensure that the in-vehicle controller can recognize it. It should be noted that there are dozens or even hundreds of candidate controllers inside the vehicle. The gateway controller stores a routing mapping table, which can parse the request identifier of the diagnostic request. The request identifier is the target address, and the in-vehicle controller is selected from the candidate controllers based on the target address.

[0036] In step S303 of some embodiments, when the gateway controller sends the diagnostic request to the in-vehicle controller, the gateway controller also performs bus arbitration to ensure that the diagnostic request does not affect the control signals currently running on the in-vehicle controller, thereby reducing the impact on vehicle driving safety. Specifically, by acquiring the operating status and operating parameters of the in-vehicle controller, a diagnostic impact assessment is performed on the in-vehicle controller based on the operating status and operating parameters to obtain diagnostic impact assessment information. The diagnostic impact assessment information characterizes the degree of impact of the in-vehicle controller performing diagnostic operations. If the degree of impact of the in-vehicle controller performing diagnostic operations is lower than a preset threshold, the diagnostic request is sent to the in-vehicle controller.

[0037] In steps S301-S303 of this embodiment, the gateway controller accurately selects the target in-vehicle controller from the preset candidate controllers based on the request identifier in the diagnostic request. This significantly improves the routing efficiency and targeting of diagnostic commands and effectively avoids the network congestion problems caused by the waste of bus resources and invalid responses from multiple controllers due to traditional broadcast-style distribution.

[0038] In step S202 of some embodiments, after receiving a diagnostic request, the in-vehicle controller performs diagnostic operations according to the request and outputs diagnostic response data. It should be noted that the in-vehicle controller includes a diagnostic communication management module, which parses, authenticates, and schedules the received diagnostic request, and calls the corresponding underlying software to perform diagnostic operations. These diagnostic operations include reading data, running tests, and querying status.

[0039] Please see Figure 4 In some embodiments, step S202 may include, but is not limited to, steps S401 to S403: Step S401: The in-vehicle controller parses the diagnostic request to obtain request parsing information; wherein, the request parsing information includes: diagnostic request instruction, vehicle version read instruction, and fault read instruction; In step S402, the in-vehicle controller verifies the diagnostic request based on the diagnostic switching command, vehicle version reading command, and fault reading command to obtain the request verification information; wherein, the request verification information indicates whether the diagnostic request is valid or invalid. In step S403, if the requested verification information indicates that the diagnostic request is valid, the in-vehicle controller performs diagnostic operations and generates diagnostic response data according to the diagnostic switching instruction, vehicle version reading instruction, and fault reading instruction.

[0040] In step S401 of some embodiments, the diagnostic request is parsed to obtain a diagnostic switching instruction, a vehicle version read instruction, and a fault read instruction. The diagnostic switching instruction is used to switch the in-vehicle controller from the operating mode to the diagnostic session mode. The vehicle version read instruction is used to read information such as the software version number, hardware version number, or serial number of the in-vehicle controller. The fault read instruction is used to read the fault codes currently stored in the in-vehicle controller.

[0041] In step S402 of some embodiments, the in-vehicle controller first verifies the diagnostic request by combining the diagnostic request command, the vehicle version read command, and the fault read command to verify the validity of the diagnostic request. Specifically, the verification of the diagnostic request includes format verification, permission verification, and runtime environment verification. Format verification checks whether the message length and format of the diagnostic request conform to the protocol specification; permission verification assesses whether the user terminal has sufficient permissions; and runtime environment verification determines whether the in-vehicle controller meets the runtime environment requirements of the diagnostic request. Therefore, this embodiment sets up a multi-level verification mechanism from format and permission to runtime environment to ensure that each diagnostic request undergoes strict identity verification and feasibility assessment.

[0042] In step S403 of some embodiments, if the request verification information indicates that the diagnostic request is valid, the in-vehicle controller performs diagnostic operations according to the diagnostic switching instruction, vehicle version reading instruction, and fault reading instruction, and generates diagnostic response data. If the request verification information indicates that the diagnostic request is invalid, negative response data and an error code are generated, and the negative response data and error code are sent to the user terminal through the gateway controller.

[0043] In steps S401-S403 of this embodiment, the in-vehicle controller performs structured parsing of the diagnostic requests, accurately identifying three key request information types: diagnostic switching instructions, vehicle version reading instructions, and fault reading instructions. Based on this, a targeted multi-dimensional verification mechanism is constructed to pre-verify the validity of the diagnostic requests, effectively eliminating invalid diagnostic requests and avoiding the in-vehicle controller's blind execution of invalid instructions and waste of resources. After the request verification is passed, the controller performs differentiated operations such as diagnostic session switching, version information reading, and fault code retrieval according to the three types of instructions, and generates structured diagnostic response data. This ensures the legality and security of the diagnostic operations and improves the adaptability to different diagnostic scenarios through the classification processing mechanism, significantly improving the processing efficiency of diagnostic requests.

[0044] Please see Figure 5 In some embodiments, step S403 may include, but is not limited to, steps S501 to S503: Step S501: If the requested verification information indicates that the diagnostic request is valid, the in-vehicle controller reads the version number according to the vehicle version reading instruction to obtain the target version number. In step S502, the in-vehicle controller reads the fault code according to the diagnostic switching command and the fault reading command. In step S503, the in-vehicle controller concatenates the target version number and the fault code to obtain diagnostic response data.

[0045] In step S501 of some embodiments, the in-vehicle controller reads the target version number according to the vehicle version reading instruction. Specifically, the vehicle version reading instruction is first parsed to obtain the version number reading message, and the in-vehicle controller detects whether the current diagnostic session allows reading the version number. If it is supported, the target version number is read from the local memory.

[0046] In step S502 of some embodiments, the in-vehicle controller switches to diagnostic session mode according to the diagnostic switching instruction and reads the fault code, also known as DTC fault code, according to the fault code reading instruction.

[0047] In steps S501-S503 of this embodiment, after the request verification is valid, the in-vehicle controller executes the vehicle version reading command in parallel or sequentially to obtain the target version number, executes the diagnostic switching command and the fault reading command to obtain the fault code, and then structurally concatenates the two to generate unified diagnostic response data, realizing multi-dimensional information fusion and standardized output of diagnostic results. This embodiment improves the information density and transmission efficiency of diagnostic data, and lays a solid data foundation for subsequent version-based fault clustering analysis and precise repair plan recommendation.

[0048] In step S203 of some embodiments, information is transmitted between the in-vehicle controller and the user terminal via a wireless transmission protocol or a wired transmission protocol. The wireless transmission protocol includes Bluetooth, Wi-Fi, etc. For example, the in-vehicle controller transmits diagnostic response data to the user terminal via Bluetooth at a rate of 1 Mbps. The user terminal receives and parses the diagnostic response data, then transmits it to the cloud via the network. The cloud interprets the diagnostic response data without consuming the user terminal's computing resources.

[0049] In step S204 of some embodiments, network interfaces are configured between the user terminal and the cloud, and data transmission is completed using a network standard. Therefore, the cloud receives diagnostic response data through a network transmission protocol and, in conjunction with a database, interprets the diagnostic response data to generate diagnostic interpretation information.

[0050] Please see Figure 6 In some embodiments, step S204 may include, but is not limited to, steps S601 to S605: Step S601: The cloud parses the diagnostic response data to obtain response parsing information; the response parsing information includes: target version number and fault code; Step S602: The cloud extracts reference diagnostic parsing configuration parameters from the preset diagnostic parsing configuration library according to the target version number; Step S603: The cloud selects the target fault description information from the preset candidate fault description information based on the fault code; Step S604: The cloud compares the target version number with the preset version number to obtain version comparison information; In step S605, the cloud constructs diagnostic interpretation information based on the reference diagnostic parsing configuration parameters, target fault description information, version comparison information, and target version number.

[0051] In step S601 of some embodiments, the cloud parses the diagnostic response data to obtain the target version number and fault code, and completes the diagnostic interpretation based on the target version number and fault code.

[0052] In step S602 of some embodiments, the diagnostic parsing configuration library is the underlying infrastructure for cloud data storage and management. It is used to store DTC definition tables, vehicle configuration tables, software version baseline libraries, historical diagnostic records, etc. Reference diagnostic parsing parameters are extracted from the diagnostic parsing configuration library according to the target version number. The reference diagnostic parsing parameters include the vehicle's historical diagnostic records and past fault information.

[0053] In step S603 of some embodiments, candidate fault description information is recorded in the DTC definition table. The corresponding candidate fault description information is retrieved from the DTC definition table based on the fault code and used as the target fault description information. The target fault description information includes a fault description, a fault cause, and fault suggestion information. For example, the fault description is "random engine misfire," and the fault cause is engine failure.

[0054] In step S604 of some embodiments, the cloud compares the target version number with the preset version number to determine whether the software and hardware versions of the in-vehicle controller need to be upgraded, and obtains version comparison information.

[0055] In step S605 of some embodiments, the cloud combines the reference diagnostic parsing configuration parameters, target fault description information and version comparison information into diagnostic interpretation information. The diagnostic interpretation information can be used as a reference for fault repair, improving the accuracy and efficiency of fault repair.

[0056] In steps S601-S605 of this embodiment, the diagnostic response data is structured and analyzed in the cloud to accurately identify two core types of information: the target version number and the fault code. Based on this, a multi-dimensional, parallel intelligent diagnostic interpretation mechanism is constructed: on the one hand, reference diagnostic parsing configuration parameters adapted to the current software version are dynamically extracted from the preset diagnostic parsing configuration library according to the target version number, ensuring the compatibility and accuracy of the diagnostic logic with different versions of ECUs; on the other hand, the corresponding target fault description information is accurately selected from the candidate fault description information according to the fault code, and the target version number is compared with the preset version number to obtain version comparison information, realizing automatic perception of software version differences and proactive identification of potential version defects; finally, the reference diagnostic parsing configuration parameters, target fault description information, version comparison information, and target version number are fused in multiple dimensions to construct structured diagnostic interpretation information, so that the diagnostic results are no longer limited to the isolated surface meaning of the fault code, but a comprehensive diagnostic conclusion that integrates version adaptation parameters, semantic fault description, and version consistency assessment, significantly improving the intelligence level of cloud-based diagnosis.

[0057] Please see Figure 7 In some embodiments, step S605 includes, but is not limited to, steps S701 to S703: Step S701: The cloud performs fault classification based on the reference diagnostic parsing configuration parameters, target fault description information and version comparison information to obtain the fault category; Step S702: The cloud performs fault root cause prediction based on the reference diagnostic parsing configuration parameters, target fault description information and version comparison information to obtain fault root cause prediction information. In step S703, the cloud encapsulates the target version number, target fault description information, fault category, and fault root cause prediction information to obtain diagnostic interpretation information.

[0058] In step S701 of some embodiments, after the cloud determines the reference diagnostic parsing configuration parameters, target fault description information and version comparison information, it further performs fault classification. The fault classification is any one of hardware fault category, software fault category, communication fault category and environment-triggered fault category, which also serves as the basis for fault repair.

[0059] In step S702 of some embodiments, the root cause prediction of the fault is performed by combining the diagnostic reasoning model with the reference diagnostic parsing configuration parameters, the target fault description information and the version comparison information to infer the cause of the fault. The fault root cause prediction information is gradually inferred from the threshold fault tree knowledge base in the diagnostic reasoning model.

[0060] In step S703 of some embodiments, the cloud encapsulates the target version number, target fault description information, fault category, and fault root cause prediction information. Specifically, the cloud selects a report template from the candidate report templates based on the target version number, and inputs the target version number, target fault description information, fault category, and fault root cause prediction information into the selected report template to obtain diagnostic interpretation information.

[0061] In steps S701-S703 of this embodiment, the diagnostic data is fused and reasoned from multiple dimensions in the cloud. Based on the reference diagnostic parsing configuration parameters, target fault description information, and version comparison information, two intelligent analysis tasks, fault classification and fault root cause prediction, are executed in parallel. On the one hand, the faults are systematically classified, mapping the original fault codes into clear fault categories, which facilitates users and maintenance personnel to quickly locate the problematic system. On the other hand, deep reasoning is performed by combining version difference information and configuration parameters to predict the possible root causes of the faults and output fault root cause prediction information, providing accurate directional guidance for maintenance decisions. Finally, the target version number, target fault description information, fault category, and fault root cause prediction information are encapsulated in a structured manner to construct a multi-level diagnostic interpretation information covering version status, fault phenomena, fault classification, and root cause reasoning. This provides a complete and logically rigorous diagnostic conclusion basis for the subsequent generation of a user-understandable and maintenance-operable diagnostic report.

[0062] In step S205, the user terminal receives diagnostic interpretation information from the cloud via the network and displays the diagnostic interpretation information to the user, showing the current vehicle fault problems and root causes, as reference information for subsequent fault repair, thereby improving the accuracy and efficiency of vehicle fault repair.

[0063] Please see Figure 8In some embodiments, after step S205, the vehicle diagnostic method may also include, but is not limited to, steps S801 to S803: In step S801, the user terminal responds to the user's confirmation of the diagnostic interpretation information by sending a repair appointment request to the cloud. Step S802: The cloud sends the repair appointment request to the repair terminal and receives the appointment feedback information from the repair terminal. In step S803, the cloud sends the reservation feedback information to the user's terminal.

[0064] In step S801 of some embodiments, such as Figure 9 As shown, the user interface displays visualized diagnostic interpretation information and pops up "Confirm," "Reanalyze," and "Ignore" buttons. If the user clicks the "Confirm" button, it indicates acceptance of the diagnostic interpretation information. A repair appointment request is then generated and sent to the cloud via the network, enabling remote advance repair scheduling and improving the efficiency of vehicle fault repair. It should be noted that the repair appointment request includes both repair appointment information and diagnostic interpretation information. This allows repair personnel to inform the vehicle fault and repair time in advance, facilitating their preparation and ensuring a quick and efficient repair process upon the vehicle's arrival at the repair center, thus improving both repair efficiency and the user's repair experience.

[0065] In steps S802 and S803 of some embodiments, the cloud only acts as a forwarding center for the repair appointment request. The cloud sends the repair appointment request to the repair terminal selected by the user and receives appointment feedback information from the repair personnel at the repair terminal. It should be noted that the appointment feedback information includes confirmed appointment information, returned appointment information, and modified appointment information. Confirmed appointment information indicates that the repair terminal has made a unified repair appointment request. Modified appointment information indicates that the user terminal needs to adjust the repair time or repair location. Returned appointment information indicates that the repair terminal cannot perform the repair and the user terminal needs to find a repair center again and re-initiate the repair appointment information to a new repair terminal.

[0066] In steps S801-S803 of this embodiment, the user terminal responds to the user's confirmation of the diagnostic interpretation information by sending a repair appointment request to the cloud. The cloud, acting as an intelligent relay, forwards the appointment request to the repair terminal and receives the appointment feedback information from it. Finally, the appointment feedback information is sent back to the user terminal for user confirmation, thus constructing a complete appointment closed loop of "user triggering—cloud forwarding—repair terminal processing—cloud feedback—user terminal confirmation". This embodiment, on the one hand, achieves accurate transmission and standardized format of appointment information through the structured forwarding and standardized response processing of appointment requests by the cloud, avoiding information errors and communication losses that may occur when users directly contact the repair terminal. On the other hand, it greatly simplifies the user's operation path from diagnosis completion to repair arrangement. The entire process of diagnosis confirmation, appointment request, and appointment confirmation can be completed within the same user terminal interface without switching multiple communication channels, significantly improving the automation level of post-diagnosis services.

[0067] The following is a detailed description and explanation of the solutions in the embodiments of the present invention, using specific application examples: Please refer to Figure 10 The user sends a diagnostic request through the user terminal. The gateway controller receives the request and sends it to the corresponding in-vehicle controller. The in-vehicle controller verifies the request to obtain verification information. If the verification information indicates the diagnostic request is valid, the in-vehicle controller executes the diagnostic request, such as reading DTC fault codes and / or target version numbers, and then generates positive response data based on the DTC fault codes and / or target version numbers. The in-vehicle controller then sends the positive response data to the gateway controller. The gateway controller receives and sends the positive response data to the user terminal. If the diagnostic request is invalid, the in-vehicle controller generates negative response data and an error code, and sends the negative response data and error code to the user terminal through the gateway controller. In addition, the gateway controller uploads the positive response data to the cloud. The cloud receives and parses the positive response data through its database. The cloud also performs deep data analytics on the positive response data and generates a value-added report, which is stored in a cloud database and sent to the user terminal. After receiving the value-added report, the user terminal displays the report and asks the user to confirm whether there is a problem with the vehicle. If the user confirms, the cloud automatically schedules vehicle repair; otherwise, the diagnostic process ends.

[0068] In summary, this embodiment transforms vehicle diagnostics from an offline service relying on specialized equipment and facilities into an intelligent, cloud-based online service. Furthermore, this embodiment provides a completely new remote diagnostic and repair support model, aligning with the development trend of vehicle connectivity and intelligence, and improving the convenience, accuracy, and efficiency of vehicle diagnostics.

[0069] Please see Figure 1This application also provides a vehicle diagnostic system that can implement the above-described vehicle diagnostic method. The vehicle diagnostic system includes: a user terminal 101, an in-vehicle gateway 102, a vehicle 103, and a cloud 104. The gateway 102 includes a gateway controller 121, and the vehicle 103 includes an in-vehicle controller 131. The user terminal 101 is used to send a diagnostic request to the in-vehicle controller 131 through the gateway controller 121. The in-vehicle controller 131 is used to perform diagnostic operations and generate diagnostic response data according to the diagnostic request. The user terminal 101 is also used to receive the diagnostic response data and send it to the cloud 104. The cloud 104 is used to interpret and process the diagnostic response data to obtain diagnostic interpretation information. The user terminal 101 is also used to receive and display the diagnostic interpretation information.

[0070] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0071] This application also provides a vehicle, which includes a body, an in-vehicle controller, and an in-vehicle memory. The in-vehicle memory stores a computer program, and the in-vehicle controller executes the computer program to implement the above-described method.

[0072] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0073] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0074] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0075] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0076] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0077] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0078] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0079] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0080] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0081] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0082] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0083] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0084] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0085] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A vehicle diagnostic method, characterized in that, The method includes the following steps: The user sends a diagnostic request to the in-vehicle controller via the gateway controller; The in-vehicle controller performs diagnostic operations and generates diagnostic response data based on the diagnostic request. The user terminal receives the diagnostic response data and sends the diagnostic response data to the cloud; The cloud platform interprets and processes the diagnostic response data to obtain diagnostic interpretation information. The user terminal receives and displays the diagnostic interpretation information.

2. The method according to claim 1, characterized in that, The in-vehicle controller performs diagnostic operations and generates diagnostic response data based on the diagnostic request, including: The in-vehicle controller parses the diagnostic request to obtain request parsing information; wherein, the request parsing information includes: diagnostic switching command, vehicle version reading command, and fault reading command; The in-vehicle controller verifies the diagnostic request based on the diagnostic switching command, the vehicle version reading command, and the fault reading command to obtain request verification information; wherein, the request verification information indicates whether the diagnostic request is valid or invalid. If the request verification information indicates that the diagnostic request is valid, the in-vehicle controller performs diagnostic operations and generates the diagnostic response data according to the diagnostic switching instruction, the vehicle version reading instruction, and the fault reading instruction.

3. The method according to claim 2, characterized in that, If the request verification information indicates that the diagnostic request is valid, the in-vehicle controller performs diagnostic operations and generates the diagnostic response data according to the diagnostic switching instruction, the vehicle version reading instruction, and the fault reading instruction, including: If the request verification information indicates that the diagnostic request is valid, the in-vehicle controller reads the version number according to the vehicle version reading instruction to obtain the target version number; The in-vehicle controller reads the fault code according to the diagnostic switching command and the fault reading command. The in-vehicle controller concatenates the target version number and the fault code to obtain the diagnostic response data.

4. The method according to claim 1, characterized in that, The cloud platform interprets and processes the diagnostic response data to obtain diagnostic interpretation information, including: The cloud platform parses the diagnostic response data to obtain response parsing information; wherein, the response parsing information includes: target version number and fault code; The cloud extracts reference diagnostic parsing configuration parameters from a preset diagnostic parsing configuration library based on the target version number; The cloud platform selects the target fault description information from the preset candidate fault description information based on the fault code; The cloud platform compares the target version number with the preset version number to obtain version comparison information; The cloud platform constructs the diagnostic interpretation information based on the reference diagnostic parsing configuration parameters, the target fault description information, the version comparison information, and the target version number.

5. The method according to claim 4, characterized in that, The cloud platform constructs the diagnostic interpretation information based on the reference diagnostic parsing configuration parameters, the target fault description information, the version comparison information, and the target version number, including: The cloud platform classifies faults based on the reference diagnostic parsing configuration parameters, the target fault description information, and the version comparison information to obtain fault categories. The cloud platform performs fault root cause prediction based on the reference diagnostic parsing configuration parameters, the target fault description information, and the version comparison information to obtain fault root cause prediction information. The cloud platform encapsulates the target version number, the target fault description information, the fault category, and the fault root cause prediction information to obtain the diagnostic interpretation information.

6. The method according to any one of claims 1 to 5, characterized in that, The user terminal sends a diagnostic request to the in-vehicle controller through the gateway controller, including: The user terminal sends the diagnostic request to the gateway controller; The gateway controller selects the in-vehicle controller from a preset pool of candidate controllers based on the request identifier of the diagnostic request. The gateway controller sends the diagnostic request to the in-vehicle controller.

7. The method according to any one of claims 1 to 5, characterized in that, After the user receives and displays the diagnostic interpretation information, the method further includes: In response to the user's confirmation of the diagnostic interpretation information, the user terminal sends a repair appointment request to the cloud. The cloud sends the repair appointment request to the repair terminal and receives the appointment feedback information from the repair terminal. The cloud platform sends the reservation feedback information to the user's terminal.

8. A vehicle diagnostic system, characterized in that, The system includes: a user terminal, an in-vehicle gateway, a vehicle, and a cloud; the gateway includes a gateway controller, and the vehicle includes an in-vehicle controller; The user terminal is used to send diagnostic requests to the in-vehicle controller via the gateway controller; The in-vehicle controller is used to perform diagnostic operations and generate diagnostic response data according to the diagnostic request; The user terminal is also used to receive the diagnostic response data and send the diagnostic response data to the cloud; The cloud platform is used to interpret and process the diagnostic response data to obtain diagnostic interpretation information. The user terminal is also used to receive and display the diagnostic interpretation information.

9. A vehicle, characterized in that, The vehicle includes a body, an in-vehicle controller, and an in-vehicle memory. The in-vehicle memory stores a computer program, and when the in-vehicle controller executes the computer program, it implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images