Vehicle diagnosis method, vehicle diagnosis server and storage medium

Abstract

The application provides a vehicle diagnosis method, a vehicle diagnosis server and a storage medium, and the method comprises the following steps: obtaining vehicle information of a vehicle to be diagnosed, wherein the vehicle information comprises a vehicle type and ECU information, the ECU information comprises each functional component in the vehicle to be diagnosed and the data structure of each functional component; according to the functions corresponding to the vehicle type and each functional component, a target diagnosis sequence is matched from a diagnosis sequence set, the diagnosis sequences in the diagnosis sequence set are constructed according to the data structure of each functional component in each vehicle type, and the diagnosis sequence comprises diagnosis data packets of various functions in each vehicle type; the target diagnosis sequence is sent to the vehicle to be diagnosed to perform diagnosis, and diagnosis log information is obtained; in combination with a preset diagnosis database and an exception pool, the diagnosis log information is analyzed, an abnormal error point is located, and a repair method is fed back. The diagnosis of the vehicle is realized by means of the diagnosis sequence sent by the server, a cloud-end and client-end architecture is proposed, and the high expansibility of the diagnosis system is realized.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and in particular to a vehicle diagnostic method, a vehicle diagnostic server, and a storage medium. Background Technology

[0002] With the rapid development of the new energy vehicle industry in recent years, the huge number of new energy vehicles has brought about a greater demand for fault diagnosis. Vehicle diagnosis mainly relies on diagnostic tools, which use vehicle communication protocols to communicate with the vehicle's ECU (Electronic Control Unit). For example, the OBD-II (On-Board Diagnostics II) protocol is one of the most commonly used communication protocols. OBD-II allows the diagnostic tool to read fault codes stored in the ECU. Through OBD-II, the diagnostic tool can monitor the data streams of various vehicle sensors in real time, such as engine speed, vehicle speed, coolant temperature, and oxygen sensor data. In addition, the diagnostic tool also has a human-machine interface, including a display screen, buttons, and a touch screen, enabling users to easily perform diagnostic operations.

[0003] In related technologies, diagnostic tools typically employ a "client-heavy, cloud-light" architecture, meaning that diagnostic-related code and resources are stored locally on the client, while the cloud only handles account distribution. This architecture leads to two significant problems. First, low scalability: currently, diagnostic tools can usually only diagnose one or two specific vehicle models, and even minor modifications to the client require a complete update. Second, low security: diagnostic tools often collect vehicle data and fault information, raising data privacy and security concerns. Storing this data locally exposes users to unauthorized access and malicious software modifications. Therefore, there is an urgent need for a highly scalable and secure intelligent vehicle diagnostic solution. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, this application discloses a vehicle diagnostic method, a vehicle diagnostic server, and a storage medium to solve the technical problem of low scalability of the diagnostic system in the prior art.

[0005] In a first aspect, this application provides a vehicle diagnostic method, the method comprising: acquiring vehicle information of a vehicle to be diagnosed, the vehicle information including vehicle model and ECU information, the ECU information including various functional components in the vehicle to be diagnosed and the data structure of each functional component; matching a target diagnostic sequence from a diagnostic sequence set according to the vehicle model and the functions corresponding to each functional component, wherein the diagnostic sequences in the diagnostic sequence set are constructed according to the data structure of each functional component in each vehicle model, and the diagnostic sequence includes diagnostic data packages for various functions in each vehicle model; sending the target diagnostic sequence to the vehicle to be diagnosed to diagnose the vehicle and obtaining diagnostic log information; and analyzing the diagnostic log information in conjunction with a preset diagnostic database and an anomaly pool to locate anomaly error points and provide feedback on repair methods.

[0006] In one embodiment of this application, the method for constructing the diagnostic sequence set includes: obtaining a diagnostic script file and the data structure corresponding to the functions of each component in each vehicle model, and creating a diagnostic sequence file according to the diagnostic script file; based on the diagnostic sequence file, converting the data structure corresponding to each functional component in each vehicle model into a diagnostic sequence file format to obtain an initial diagnostic data package for each functional component in each vehicle model; separating the diagnostic logic and diagnostic data in the initial diagnostic sequence to obtain the diagnostic data package corresponding to each functional component in each vehicle model, wherein the diagnostic logic is sent to the client for storage; and generating the diagnostic sequence for each vehicle model based on the diagnostic data package corresponding to each functional component in each vehicle model to obtain the diagnostic sequence set.

[0007] In one embodiment of this application, after generating the diagnostic sequence for each vehicle model, the method further includes: sending the diagnostic sequence to the client so that the client loads the diagnostic sequence and verifies and debugs the diagnostic sequence, wherein the verification step includes: diagnostic sequence format, diagnostic sequence content, diagnostic logic and diagnostic compatibility; configuring exception handling logic in the diagnostic sequence, wherein the exception handling logic is used to handle diagnostic exceptions during diagnosis.

[0008] In one embodiment of this application, before configuring a target diagnostic sequence from the diagnostic sequence set according to the vehicle model and the function corresponding to each functional component, the method further includes: monitoring new vehicle models and / or new functions in each vehicle model; if the new vehicle model and / or the new function is detected, constructing a new diagnostic sequence corresponding to the new vehicle model and / or the new function; and adding the new diagnostic sequence to the diagnostic sequence set.

[0009] In one embodiment of this application, the method for determining the vehicle model includes: obtaining part number information of the vehicle to be diagnosed, the part number information including multiple part numbers; determining whether there is a unique part number in the part number information, wherein the unique part number is used to directly distinguish different vehicle models; if so, determining the vehicle model based on the unique part number; if not, determining the unique intersection of the vehicle models corresponding to all part numbers in the part number information, and determining the vehicle model based on the unique intersection.

[0010] In one embodiment of this application, the vehicle to be diagnosed is a plurality of vehicles, and the diagnostic data package includes a software upgrade package; the step of sending the target diagnostic sequence to the vehicle to be diagnosed, diagnosing the vehicle to be diagnosed, and obtaining diagnostic log information includes: creating a task pool and placing the electronic control unit flashing operation in each of the vehicles to be diagnosed as a flashing task into the task pool; establishing a connection between the client and each of the vehicles to be diagnosed, and assigning the plurality of flashing tasks in the task pool to corresponding channels; concurrently flashing the plurality of software upgrade packages, and after detecting that the plurality of flashing tasks have been completed, performing vehicle network recovery and receiving the diagnostic log information returned by each of the vehicles to be diagnosed.

[0011] In one embodiment of this application, before obtaining the vehicle information of the vehicle to be diagnosed, the method further includes: monitoring whether the diagnostic agent in the vehicle to be diagnosed is enabled; if not, using a preset key to securely unlock the ECU of the vehicle to be diagnosed; if yes, obtaining the vehicle identification code of the vehicle to be diagnosed and determining whether the vehicle identification code is stored in advance; if yes, requesting a random key to securely unlock the ECU of the vehicle to be diagnosed; if no, generating a temporary authorization file based on the vehicle identification code, and securely unlocking the ECU of the vehicle to be diagnosed based on the validity period and temporary authorization key in the temporary authorization file.

[0012] In one embodiment of this application, the step of analyzing the diagnostic log information by combining a preset diagnostic database and an anomaly pool, locating the anomaly error point, and feeding back a repair method includes: matching the diagnostic log information with the diagnostic database to locate the anomaly error point; and matching the repair method from the anomaly pool based on the anomaly error point, wherein the anomaly pool includes repair methods corresponding to each anomaly error point.

[0013] Secondly, this application provides a vehicle diagnostic server, the server comprising: a determination module, used to acquire vehicle information of a vehicle to be diagnosed, the vehicle information including vehicle model and ECU information, the ECU information including each functional component in the vehicle to be diagnosed and the data structure of each functional component; a matching module, used to match a target diagnostic sequence from a diagnostic sequence set according to the vehicle model and the function corresponding to each functional component, wherein the diagnostic sequences in the diagnostic sequence set are constructed according to the data structure of each functional component in each vehicle model, and the diagnostic sequence includes diagnostic data packets for various functions in each vehicle model; a diagnostic module, used to send the target diagnostic sequence to the vehicle to be diagnosed, diagnose the vehicle to be diagnosed, and obtain diagnostic log information; and an analysis module, used to analyze the diagnostic log information in conjunction with a preset diagnostic database and an anomaly pool, locate the anomaly error point, and provide feedback on the repair method.

[0014] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer's processor, causes the computer to perform the vehicle diagnostic method described in the first aspect.

[0015] As described above, the vehicle diagnostic method, vehicle diagnostic server, and storage medium provided in this application have the following beneficial effects:

[0016] First, the vehicle model and ECU information of the vehicle to be diagnosed are obtained. This ECU information includes the functional components in the vehicle and their data structures. Then, based on the vehicle model and the corresponding functions of each functional component, a target diagnostic sequence is matched from the diagnostic sequence set. The diagnostic sequences in this set are constructed based on the data structures of each functional component in each vehicle model. The diagnostic sequences include diagnostic data packages for various functions in each vehicle model. The target diagnostic sequence is sent to the vehicle to be diagnosed for diagnosis, and diagnostic log information is obtained. Finally, the diagnostic log information is analyzed in conjunction with the diagnostic database and anomaly pool to locate anomaly error points and provide feedback on repair methods. By constructing diagnostic sequences for various functional components in various vehicle models through the server, the vehicle diagnosis relies on the diagnostic sequences sent by the server. This proposes a cloud-heavy, client-light architecture that is adaptable to various functional components of various vehicle models, achieving high scalability of the diagnostic system.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0019] Figure 1 This is a schematic diagram illustrating an implementation environment of a vehicle diagnostic server, as shown in an exemplary embodiment of this application.

[0020] Figure 2 This is a flowchart illustrating a vehicle diagnostic method as shown in an exemplary embodiment of this application;

[0021] Figure 3 This is a schematic diagram illustrating a diagnostic system architecture as shown in an exemplary embodiment of this application;

[0022] Figure 4 This is a flowchart illustrating a secure unlocking process, as shown in an exemplary embodiment of this application.

[0023] Figure 5 This is a flowchart illustrating an exemplary embodiment of this application, showing an automatic adaptation process for a new vehicle model;

[0024] Figure 6 This is a flowchart illustrating a parallel flashing process for a vehicle, as shown in an exemplary embodiment of this application;

[0025] Figure 7 This is a block diagram illustrating a vehicle diagnostic server as an exemplary embodiment of this application. Detailed Implementation

[0026] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0027] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the illustrations only show the components related to this application and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0028] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0029] Diagnostic tools typically employ a "client-heavy, cloud-light" architecture, meaning that diagnostic-related code and resources are stored locally on the client, while the cloud only handles account distribution. However, the inventors of this application have discovered that this architecture leads to two significant problems. First, there is low scalability; currently, diagnostic tools can usually only diagnose one or two specific vehicle models, and even minor modifications to the client require a complete client update. Second, there is low security; diagnostic tools typically collect vehicle data and fault information, raising data privacy and security concerns. Storing this data locally exposes user data to unauthorized access and malicious software modifications.

[0030] Therefore, please see Figure 1 , Figure 1 This is a schematic diagram illustrating an implementation environment of a vehicle diagnostic server, as shown in an exemplary embodiment of this application. Figure 1 As shown, the implementation environment includes the vehicle to be diagnosed, the diagnostic system client, and the diagnostic system server. The diagnostic system client is connected to the vehicle to be diagnosed, and the diagnostic system server is connected to the diagnostic system client. The diagnostic system server is used to diagnose the vehicle to be diagnosed. The server constructs diagnostic sequences for various functional components in various vehicle models, so that the vehicle diagnosis relies on the diagnostic sequences issued by the server. This proposes a cloud-heavy, client-light architecture that is adaptable to various functional components of various vehicle models and achieves high scalability of the diagnostic system.

[0031] Please see Figure 2 , Figure 2 This is a flowchart illustrating a vehicle diagnostic method as shown in an exemplary embodiment of this application. This method can be applied to... Figure 1 The implementation environment shown is intended to illustrate a method that can also be applied to other exemplary implementation environments. This embodiment does not limit the implementation environment to which the method is applicable.

[0032] like Figure 2 As shown, in an exemplary embodiment, the vehicle diagnostic method includes at least steps S210 to S240, which are described in detail below:

[0033] Step S210: Obtain vehicle information of the vehicle to be diagnosed. The vehicle information includes vehicle model and ECU information. The ECU information includes the functional components in the vehicle to be diagnosed and the data structure of each functional component.

[0034] Please see Figure 3 , Figure 3 This is a schematic diagram illustrating a diagnostic system architecture, as shown in an exemplary embodiment of this application. Figure 3 As shown, the diagnostic system architecture includes the vehicle to be diagnosed, the diagnostic system client, and the diagnostic system server. The diagnostic system client establishes a connection with the vehicle to be diagnosed via the OBD (On-Board Diagnostics) interface and with the diagnostic system server via WLAN (Wireless Local Area Networks). The diagnostic system client locally stores vehicle diagnostic communication protocols, such as the DOCAN (Diagnostic Over CAN) protocol (diagnostic communication on the CAN (Controller Area Network) bus) and the DOIP (Diagnostic Over IP) protocol (an Ethernet-based vehicle diagnostic protocol), enabling compatibility with various vehicle diagnostic protocols. It also stores diagnostic logic, writes and sends diagnostic commands, and provides response parsing code. All vehicle diagnostic functions implemented by the diagnostic system client are achieved through diagnostic sequence distribution from the server.

[0035] After establishing a connection with the vehicle to be diagnosed, the diagnostic system client first determines whether the vehicle diagnostics uses the DOCAN, DOIP, or other protocols by comparing protocols. This allows the diagnostic system to directly support vehicles with multiple diagnostic protocols, enhancing its scalability. Once the protocol is determined, the diagnostic system client uses the corresponding protocol interface to read data from the vehicle to be diagnosed. Based on the diagnostic request, the diagnostic system server can obtain the vehicle equipment information and ECU information corresponding to the vehicle to be diagnosed through the diagnostic system client. It should be noted that the ECU information includes the various functional components in the vehicle to be diagnosed and their data structures. These functional components include both hardware and software, and the data structure of each functional component refers to the data format for data transmission and functional operation within that component.

[0036] In one embodiment, before obtaining the vehicle information of the vehicle to be diagnosed, the method further includes: monitoring whether the diagnostic agent in the vehicle to be diagnosed is enabled; if not, using a preset key to securely unlock the ECU of the vehicle to be diagnosed; if yes, obtaining the vehicle identification code of the vehicle to be diagnosed and determining whether the vehicle identification code is stored in advance; if yes, requesting a random key to securely unlock the ECU of the vehicle to be diagnosed; if no, generating a temporary authorization file based on the vehicle identification code, and securely unlocking the ECU of the vehicle to be diagnosed based on the validity period and temporary authorization key in the temporary authorization file.

[0037] It should be noted that, in order to improve the security of communication between the diagnostic system and the vehicle under test, the diagnostic system client communicates directly with the diagnostic agent in the vehicle under test, and then communicates with the ECU through the diagnostic agent. The diagnostic agent acts as an intermediary layer between the vehicle and the ECU.

[0038] In addition, the ECU is securely unlocked to prevent unauthorized access and malicious attacks from external devices.

[0039] In this embodiment, please refer to Figure 4 , Figure 4 This is a flowchart illustrating a secure unlocking process, as shown in an exemplary embodiment of this application. Figure 4 As shown, after the diagnostic system client connects with the vehicle to be diagnosed, if the diagnostic agent in the vehicle to be diagnosed is not activated, the diagnostic system client communicates with the ECU. At this time, a preset key is used to securely unlock the ECU of the vehicle to be diagnosed. The preset key is the key written by the supplier at the factory. If the diagnostic agent is activated, the diagnostic system client communicates with the diagnostic agent. At this time, the diagnostic system server needs to further determine whether the VIN (Vehicle Identification Number) of the vehicle to be diagnosed is stored in advance. If it is stored, the vehicle to be diagnosed is securely unlocked by requesting a random key from the diagnostic system server. If it is not stored, the vehicle to be diagnosed is not in the diagnostic system server, so the VIN is written to a temporary authorization file, and the ECU of the vehicle to be diagnosed is securely unlocked within the validity period based on the temporary authorization key in the temporary authorization file. The validity period can be set according to specific circumstances to improve the security of accessing ECU data.

[0040] In this embodiment, please continue to refer to Figure 4 If the temporary authorization file becomes invalid, an abnormal situation is determined. In this case, the user should be reminded to close the diagnostic agent and continue to use the preset key to securely unlock the ECU.

[0041] In this embodiment, the key for securely unlocking the ECU is no longer stored on the diagnostic system client. Instead, the key is obtained from the diagnostic system server, encrypted, and then sent to the diagnostic system client. The logic for determining the secure unlocking method for the ECU is also performed by the diagnostic system server. By determining whether the diagnostic agent is enabled and whether the vehicle to be diagnosed is in the diagnostic system server, the above three methods can meet the diagnostic needs of the entire life cycle of a car: R&D, production, and after-sales service. That is, secure unlocking of the ECU in these three periods has wide applicability, improves the applicability of the diagnostic system, and can also significantly improve the diagnostic efficiency of staff in the above three scenarios.

[0042] In one embodiment, the method for determining the vehicle model includes: obtaining part number information of the vehicle to be diagnosed, the part number information including multiple part numbers; determining whether there is a unique part number in the part number information, wherein the unique part number is used to directly distinguish different vehicle models; if so, determining the vehicle model based on the unique part number; if not, determining the unique intersection of the vehicle models corresponding to all part numbers in the part number information, and determining the vehicle model based on the unique intersection.

[0043] In this embodiment, the diagnostic system client stores various part numbers corresponding to various vehicle models. The vehicle model to be diagnosed can be determined by the part number of the vehicle to be diagnosed. Subsequent additions of vehicle models only require part number adaptation on the diagnostic system server to meet the diagnostic needs of multiple vehicle models.

[0044] In addition, in this embodiment, the unique intersection of all vehicle models corresponding to all part numbers in the part number information means that there is a unique vehicle model in the intersection, which is the vehicle model of the vehicle to be diagnosed.

[0045] In one possible embodiment, based on the difference algorithm and the vehicle model data stored on the diagnostic system server, automatic adaptation to new vehicle models is performed to determine the vehicle model to be diagnosed, in order to adapt to the needs of multiple vehicle models. The steps are as follows: input the stored vehicle model data, and cluster all entries according to vehicle model, part number, and supplier; place the new vehicle model configuration at the center of the cluster; starting from the cluster center, use the difference algorithm to search for all clusters that adapt to the new vehicle model; after determining the clusters, filter for unique part numbers (for example, uniqueness means that there is only one ECU part number for this vehicle model) to determine the vehicle model; if there are no unique part numbers, select at least two part numbers to combine to determine the vehicle model.

[0046] Please see Figure 5 , Figure 5 This is a flowchart illustrating an exemplary embodiment of this application, showing an automatic adaptation process for a new vehicle model. For example... Figure 5As shown, the process first involves inputting vehicle model data for clustering. The clustering method is K-means clustering, hierarchical clustering, or other clustering algorithms. Each cluster includes two fields: part number and supplier. Next, new vehicle models are configured as cluster centers, and the number of sub-clusters corresponding to each cluster center is obtained, i.e., the number of different vehicle models corresponding to the same part number and supplier (COUNT1). Then, it is determined whether COUNT1 is greater than 1. If COUNT1 is greater than 1, the shortest distance D from each sub-cluster's adjacent cluster points to all violated cluster points in the cluster family is calculated using part number fit as an indicator. Each sub-cluster is then used as the cluster center. Recalculate the number of subclusters at the cluster center until COUNT1 is not greater than 1; if COUNT1 is not greater than 1, check if COUNT1 is equal to 1; if COUNT1 is equal to 1, add the subcluster to the path and use the subcluster as the cluster center, recalculate the number of subclusters at the cluster center until COUNT1 is less than 1; if COUNT1 is less than 1, take the shortest path and check if the path is unique; if there is one and only one path, determine the vehicle model based on this unique path; if the path is not unique, select at least two part numbers to combine to determine the vehicle model.

[0047] As one possible implementation, using a differential algorithm, logic can be automatically organized based on the vehicle model information of the vehicle to be diagnosed to adapt to the needs of multiple models. A car brand usually includes multiple models. Using a differential algorithm to integrate all models into a single diagnostic system can also achieve automatic adaptation to the diagnostic needs of new models. Furthermore, the differential algorithm is placed on the diagnostic system server, which improves the intelligence of the diagnostic system.

[0048] Step S220: Based on the vehicle model and the functions corresponding to each functional component, a target diagnostic sequence is matched from the diagnostic sequence set. The diagnostic sequences in the diagnostic sequence set are constructed based on the data structure of each functional component in each vehicle model. The diagnostic sequences include diagnostic data packages for various functions in each vehicle model.

[0049] In this embodiment, considering that different vehicle models or different functional components of the same vehicle model require different diagnostic data packages, the diagnostic system server matches the target diagnostic sequence from the diagnostic sequence set according to the specific vehicle model and the specific function to be diagnosed. Therefore, the target diagnostic sequence may include diagnostic data packages for all functional components in the vehicle to be diagnosed, or it may include diagnostic data packages for some functional components in the vehicle to be diagnosed. The diagnostic system server matches and issues the diagnostic sequence according to the specific diagnostic requirements.

[0050] It should be noted that the above-mentioned diagnostic sequence set is stored in a diagnostic database.

[0051] In one embodiment, the method for constructing a diagnostic sequence set includes: obtaining a diagnostic script file and the data structure corresponding to the functions of each component in each vehicle model, and creating a diagnostic sequence file based on the diagnostic script file; converting the data structure corresponding to each functional component in each vehicle model into a diagnostic sequence file format based on the diagnostic sequence file to obtain an initial diagnostic data package for each functional component in each vehicle model; separating the diagnostic logic and diagnostic data in the initial diagnostic sequence to obtain a diagnostic data package corresponding to each functional component in each vehicle model, wherein the diagnostic logic is sent to the client for storage; and generating a diagnostic sequence for each vehicle model based on the diagnostic data package corresponding to each functional component in each vehicle model to obtain a diagnostic sequence set.

[0052] In this embodiment, a data structure corresponding to the vehicle ECU is defined, a diagnostic sequence file (e.g., a JSON format diagnostic sequence file) is created, the data structure is converted to the diagnostic sequence file format, and the logic and data of the initial diagnostic data package are separated. This ensures that the diagnostic data package contains only data and no logic or functions, while the logic and functions are stored locally on the diagnostic system client. That is, only basic runtime code is stored locally, and all diagnostic functions are implemented through diagnostic sequences issued by the diagnostic system server. In this way, the diagnostic system server stores diagnostic data packages for various functions in various vehicle models, improving the practicality of the diagnostic system.

[0053] In one embodiment, after generating diagnostic sequences for each vehicle model, the method further includes: sending the diagnostic sequences to the client so that the client can load the diagnostic sequences and verify and debug the diagnostic sequences. The verification steps include: diagnostic sequence format, diagnostic sequence content, diagnostic logic and diagnostic compatibility; configuring exception handling logic in the diagnostic sequences, wherein the exception handling logic is used to handle diagnostic exceptions during diagnosis.

[0054] In this embodiment, the generated diagnostic sequences are verified and debugged so that when the diagnostic system client needs to use a certain diagnostic function, it requests the diagnostic system server to send the corresponding diagnostic sequence and load it onto the client. The client can then successfully implement the corresponding diagnostic function based on the diagnostic sequence. Furthermore, exception handling logic is pre-configured in the diagnostic sequences. This allows for timely and effective handling of situations such as loading failures or data format errors during the process of the diagnostic system client loading the diagnostic sequences for vehicle diagnosis. This approach improves the construction, use, and maintenance of diagnostic sequences, enabling a highly scalable diagnostic system and enhancing the user experience.

[0055] In one embodiment, before configuring a target diagnostic sequence from the diagnostic sequence set according to the vehicle model and the function corresponding to each functional component, the method further includes: monitoring new vehicle models and / or new functions in each vehicle model; if a new vehicle model and / or a new function is detected, constructing a new diagnostic sequence corresponding to the new vehicle model and / or the new function; and adding the new diagnostic sequence to the diagnostic sequence set.

[0056] In this embodiment, as vehicle models and functions are added, the diagnostic sequence set needs to be updated and maintained in a timely manner to ensure that the data is consistent with the latest vehicle models and functions. When a new vehicle model or function is added, the diagnostic system client does not need to make any modifications to the diagnostic system client. That is, the diagnostic system client does not need to be updated. Only the new diagnostic sequence needs to be configured on the diagnostic system server. All diagnostic functions of the diagnostic system client rely on the diagnostic sequences issued by the diagnostic system server. The diagnostic system client does not need to store any data related to vehicle models, which solves the problem of low scalability of the diagnostic system and improves the user experience.

[0057] Step S230: Send the target diagnostic sequence to the vehicle to be diagnosed, perform diagnosis on the vehicle to be diagnosed, and obtain diagnostic log information.

[0058] In this embodiment, the diagnostic system server sends the target diagnostic sequence to the diagnostic system client based on the diagnostic request. The diagnostic system client performs diagnosis on the vehicle to be diagnosed according to the logic of the stored diagnostic sequence. The diagnostic system client reads the message logs, operation logs and running logs of the functions in the vehicle to be diagnosed, i.e., the diagnostic log information, and uploads them to the diagnostic system server.

[0059] It should also be noted that all data returned to the diagnostic system from the vehicle to be diagnosed is stored locally on the diagnostic system client in an encrypted format. After the diagnostic process is completed, it is uploaded to the diagnostic system server along with the diagnostic log information for parsing and management. In other words, all data generated by the user during the use of the diagnostic system is encrypted before being uploaded to the diagnostic system server for storage, parsing, and management. The diagnostic system server can use this data to trace all diagnostic operations, preventing malicious access to user data and malicious data spoofing, thereby improving the traceability of the diagnostic system and the security of vehicle diagnostic data.

[0060] In one embodiment, there are multiple vehicles to be diagnosed, and the diagnostic data package includes a software upgrade package. The process involves sending a target diagnostic sequence to each vehicle to be diagnosed, performing a diagnostic test on each vehicle, and obtaining diagnostic log information. This includes: creating a task pool and placing the electronic control unit (ECU) flashing operation in each vehicle to be diagnosed as a flashing task into the task pool; establishing a connection between the client and each vehicle to be diagnosed and assigning multiple flashing tasks from the task pool to corresponding channels; concurrently flashing multiple software upgrade packages, and after detecting the completion of multiple flashing tasks, performing vehicle network recovery and receiving diagnostic log information returned by each vehicle to be diagnosed.

[0061] It should be noted that software flashing is divided into local flashing and online flashing. Online flashing involves distributing the software upgrade package to the diagnostic system server. After the software upgrade package is downloaded to the local machine of the diagnostic system client, it is XORed and encrypted. The encrypted package is automatically deleted after the flashing is completed. Local flashing involves storing and parsing the software upgrade package locally on the diagnostic system client.

[0062] In this embodiment, the task pool is created in two ways: first, the diagnostic system server distributes the software upgrade package, in which case the task pool is created via OTA (Over-the-Air Technology); second, the diagnostic system client locally stores and parses the software upgrade package, in which case the task pool is created by flashing the software on the diagnostic system client. Furthermore, both local and online flashing employ a parallel flashing scheme, the specific method for which parallel flashing needs to be determined based on the network topology of each vehicle model.

[0063] In this embodiment, please refer to Figure 6 , Figure 6 This is a flowchart illustrating a parallel flashing process for a vehicle, as shown in an exemplary embodiment of this application. Figure 6 As shown, each ECU flashing is treated as a task and placed in a task pool. A connection is created between the host computer (i.e., the diagnostic system client) and the VDC (Vehicle Dynamic Control) of each vehicle to be diagnosed. This connection is used to send vehicle-level commands to each vehicle to be diagnosed for pre-flashing preparations, including entering an extended session for the entire vehicle and disabling DTC (Diagnostic Trouble Code) recording. Then, a classifier is used to assign tasks in the task pool to the corresponding channels. All channels share the connection created above. Then, the parsing of software packages and the transmission of data are processed concurrently, and it is determined whether all tasks are completed. If not all tasks in the task pool are completed, the flashing operation continues. After all tasks are completed, the connection created above is used again to send vehicle-level commands for vehicle network recovery and DTC recording functions after the flashing is completed, so as to return the diagnostic log information of each vehicle to be diagnosed.

[0064] In this embodiment, the diagnostic system integrates a parallel flashing method, which improves the efficiency and success rate of ECU software flashing.

[0065] Step S240: Combine the preset diagnostic database and anomaly pool to analyze the diagnostic log information, locate the anomaly error points, and provide feedback on the repair methods.

[0066] In this embodiment, since the states of the vehicles to be diagnosed vary, many unexpected situations may occur when using the diagnostic system client. In order to deal with such abnormal situations, the diagnostic system server has built an anomaly monitoring system. That is, various abnormal codes are defined in the diagnostic database, and the anomaly pool includes various vehicle anomalies and corresponding recovery methods. The diagnostic database and the anomaly pool can be combined to analyze the diagnostic log information, locate the anomaly error point, and provide feedback on the repair method.

[0067] In one embodiment, the diagnostic log information is analyzed by combining a preset diagnostic database and an anomaly pool to locate anomaly error points and provide feedback on repair methods. This includes: matching the diagnostic log information with the diagnostic database to locate anomaly error points; and matching repair methods from the anomaly pool based on the anomaly error points, wherein the anomaly pool includes repair methods corresponding to each anomaly error point.

[0068] In this embodiment, the diagnostic system server also constructs an alarm system that can define monitoring indicators, abnormal thresholds, alarm rules, and other data. Based on the diagnostic database of each ECU, it locates abnormal error points and provides corresponding error prompts to the user. The error pop-up also prompts the user on how to resolve the problem. If the problem is not in the abnormal pool, the system will record the problem and upload it to the diagnostic system server along with the log file. The diagnostic system server maintenance personnel can continuously improve the diagnostic sequence by identifying problems, thereby ensuring the stability of the entire diagnostic system.

[0069] Please continue reading Figure 3 In this embodiment, the diagnostic system server implements the above solution by integrating unified login authentication, ECU key management, vehicle configuration information, maintenance plan integration, software flashing, electrical configuration information, vehicle authorization management, and diagnostic database.

[0070] The aforementioned vehicle diagnostic method first obtains the vehicle model and ECU information of the vehicle to be diagnosed. This ECU information includes the functional components in the vehicle and their data structures. Then, based on the vehicle model and the corresponding functions of each functional component, a target diagnostic sequence is matched from a diagnostic sequence set. The diagnostic sequences in this set are constructed based on the data structures of each functional component in each vehicle model. The diagnostic sequences include diagnostic data packages for various functions in each vehicle model. The target diagnostic sequence is then sent to the vehicle to be diagnosed for diagnosis to obtain diagnostic log information. Finally, the diagnostic log information is analyzed in conjunction with the diagnostic database and anomaly pool to locate anomaly error points and provide feedback on repair methods. By constructing diagnostic sequences for various functional components in various vehicle models through the server, vehicle diagnosis relies on diagnostic sequences sent by the server. This proposes a cloud-heavy, client-light architecture that is adaptable to various functional components of various vehicle models, achieving high scalability of the diagnostic system.

[0071] Please see Figure 7 , Figure 7 This is a block diagram illustrating a vehicle diagnostic server as an exemplary embodiment of this application. This server can be applied to... Figure 1 The implementation environment shown is intended to be understood in light of other exemplary implementation environments. This embodiment does not limit the implementation environment to which the server is applicable.

[0072] like Figure 7 As shown, in an exemplary embodiment, the vehicle diagnostic server 700 includes at least a determination module 710, a matching module 720, a diagnostic module 730, and an analysis module 740, which are described in detail below:

[0073] The determination module 710 is used to obtain vehicle information of the vehicle to be diagnosed. The vehicle information includes vehicle model and ECU information. The ECU information includes the functional components in the vehicle to be diagnosed and the data structure of each functional component.

[0074] The matching module 720 is used to match the target diagnostic sequence from the diagnostic sequence set according to the vehicle model and the function corresponding to each functional component. The diagnostic sequences in the diagnostic sequence set are constructed according to the data structure of each functional component in each vehicle model. The diagnostic sequences include diagnostic data packages of various functions in each vehicle model.

[0075] The diagnostic module 730 is used to send the target diagnostic sequence to the vehicle to be diagnosed, perform diagnosis on the vehicle to be diagnosed, and obtain diagnostic log information.

[0076] The analysis module 740 is used to analyze diagnostic log information by combining a preset diagnostic database and an error pool, locate the error points, and provide feedback on the repair methods.

[0077] It should be noted that the vehicle diagnostic server provided in the above embodiments and the vehicle diagnostic method provided in the above embodiments belong to the same concept. The content of the operation performed by each module has been described in detail in the method embodiments, and will not be repeated here.

[0078] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer's processor, causes the computer to perform the vehicle diagnostic method described above. This computer-readable storage medium may be included within an electronic device or may exist independently, not assembled into an electronic device.

[0079] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0080] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0081] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0082] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A vehicle diagnosis method characterized by, Applied to a server, the method comprises: Obtaining vehicle information of a vehicle to be diagnosed, the vehicle information comprising a vehicle model and ECU information, the ECU information comprising each functional component in the vehicle to be diagnosed and a data structure of each functional component; Matching a target diagnosis sequence from a diagnosis sequence set according to a function corresponding to the vehicle model and each functional component, wherein the diagnosis sequence in the diagnosis sequence set is constructed according to the data structure of each functional component in each vehicle model, and the diagnosis sequence comprises diagnosis data packets of various functions in each vehicle model; Downlinking the target diagnosis sequence to the vehicle to be diagnosed to diagnose the vehicle to be diagnosed and obtain diagnosis log information; Analyzing the diagnosis log information in combination with a preset diagnosis database and an exception pool, locating an exception error point and feeding back a repair method; The construction method of the diagnosis sequence set comprises: obtaining a diagnosis script file and the data structure corresponding to each functional component in each vehicle model, and creating a diagnosis sequence file according to the diagnosis script file; converting the data structure corresponding to each functional component in each vehicle model into a diagnosis sequence file format based on the diagnosis sequence file to obtain initial diagnosis data packets of each functional component in each vehicle model; separating diagnosis logic from diagnosis data in the initial diagnosis data packets to obtain the diagnosis data packets corresponding to each functional component in each vehicle model, wherein the diagnosis logic is downlinked to a client for storage; generating the diagnosis sequence of each vehicle model based on the diagnosis data packets corresponding to each functional component in each vehicle model to obtain the diagnosis sequence set.

2. The vehicle diagnosis method according to claim 1, characterized by, After the diagnosis sequence of each vehicle model is generated, the method further comprises: Downlinking the diagnosis sequence to the client to enable the client to load the diagnosis sequence, verify and debug the diagnosis sequence, wherein the verification step comprises diagnosis sequence format, diagnosis sequence content, diagnosis logic and diagnosis compatibility; Configuring an exception handling logic in the diagnosis sequence, wherein the exception handling logic is used to handle diagnosis exceptions in diagnosis.

3. The vehicle diagnostic method of claim 1, wherein Before the target diagnosis sequence is matched from the diagnosis sequence set according to the function corresponding to the vehicle model and each functional component, the method further comprises: Monitoring a new vehicle model and / or a new function in each vehicle model; If the new vehicle model and / or the new function is detected, constructing a new diagnosis sequence corresponding to the new vehicle model and / or the new function; Adding the new diagnosis sequence to the diagnosis sequence set.

4. The vehicle diagnostic method of claim 1, wherein The determination method of the vehicle model comprises: Obtaining part number information of the vehicle to be diagnosed, the part number information comprising a plurality of part numbers; Determining whether there is a unique part number in the part number information, wherein the unique part number is used to directly distinguish different vehicle models; If yes, determining the vehicle model according to the unique part number; if no, determining a unique intersection of vehicle models corresponding to all part numbers in the part number information, and determining the vehicle model according to the unique intersection.

5. The vehicle diagnostic method of claim 1, wherein The vehicle to be diagnosed is a plurality of vehicles, and the diagnosis data packet comprises a software upgrade package. The target diagnosis sequence is sent to the vehicle to be diagnosed, diagnosis is performed on the vehicle to be diagnosed, and diagnosis log information is obtained, including: A task pool is created, and an electronic control unit flashing operation in each vehicle to be diagnosed is put into the task pool as a flashing task; A connection between a client and each vehicle to be diagnosed is established, and multiple flashing tasks in the task pool are distributed to corresponding channels; Multiple software upgrade packages are concurrently flashed, and after it is monitored that multiple flashing tasks are completed, vehicle network recovery is performed, and the diagnosis log information returned by each vehicle to be diagnosed is received.

6. The vehicle diagnostic method according to any one of claims 1 to 5, characterized by, Before the vehicle information of the vehicle to be diagnosed is obtained, the method further includes: It is monitored whether a diagnosis agent in the vehicle to be diagnosed is started; If not, a preset secret key is used to safely unlock the ECU of the vehicle to be diagnosed; if yes, a vehicle identification code of the vehicle to be diagnosed is obtained, and it is judged whether the vehicle identification code is pre-stored; If yes, a random secret key is requested to safely unlock the ECU of the vehicle to be diagnosed; if not, a temporary authorization file is generated based on the vehicle identification code, and the ECU of the vehicle to be diagnosed is safely unlocked based on an effective period and a temporary authorization secret key in the temporary authorization file.

7. The vehicle diagnostic method according to any one of claims 1 to 5, characterized by, The diagnosis log information is analyzed in combination with a preset diagnosis database and an exception pool, an abnormal error point is located, and a repair method is fed back, including: The diagnosis log information is matched with the diagnosis database to locate the abnormal error point; Based on the abnormal error point, the repair method is matched from the exception pool, wherein the exception pool includes a repair method corresponding to each abnormal error point.

8. A vehicle diagnostic server, characterized by The server includes: A determination module configured to obtain vehicle information of a vehicle to be diagnosed, the vehicle information including vehicle type and ECU information, the ECU information including each functional component in the vehicle to be diagnosed and a data structure of each functional component; A matching module configured to match a target diagnosis sequence from a diagnosis sequence set according to a function corresponding to each functional component of the vehicle type, wherein a diagnosis sequence in the diagnosis sequence set is constructed according to the data structure of each functional component in each vehicle type, and the diagnosis sequence includes diagnosis data packets of various functions in each vehicle type; A diagnosis module configured to send the target diagnosis sequence to the vehicle to be diagnosed, perform diagnosis on the vehicle to be diagnosed, and obtain diagnosis log information; An analysis module configured to analyze the diagnosis log information in combination with a preset diagnosis database and an exception pool, locate an abnormal error point, and feed back a repair method; The matching module is further configured to obtain the data structure corresponding to each functional component in each vehicle model and each diagnostic script file, and create a diagnostic sequence file according to the diagnostic script file; convert the data structure corresponding to each functional component in each vehicle model into a diagnostic sequence file format based on the diagnostic sequence file, to obtain an initial diagnostic data packet of each functional component in each vehicle model; separate the diagnostic logic from the diagnostic data in the initial diagnostic data packet, to obtain the diagnostic data packet corresponding to each functional component in each vehicle model, wherein the diagnostic logic is sent to a client for storage; and generate the diagnostic sequence of each vehicle model based on the diagnostic data packet corresponding to each functional component in each vehicle model, to obtain the diagnostic sequence set.

9. A computer-readable storage medium, characterized in that, A computer readable instruction is stored thereon, and when the computer readable instruction is executed by a processor of a computer, the computer is caused to perform the vehicle diagnostic method of any one of claims 1 to 7.

Images