A vehicle fault diagnosis system, method, vehicle terminal and storage medium

Abstract

The application relates to the technical field of fault diagnosis, and discloses a vehicle fault diagnosis system and method, a vehicle terminal and a storage medium, the system comprising a vehicle terminal and an edge computing center, the vehicle terminal being used for collecting diagnosis fault codes of the vehicle terminal and vehicle operation data, if a first fault code is found in the diagnosis fault codes, a first fault result is determined according to the first fault code; if a second fault code is found in the diagnosis fault codes, an edge node is determined according to position information of the vehicle terminal, the edge node is connected, and the second fault code and second operation data corresponding to the second fault code are sent to the edge node, the edge node being at least one of the edge computing center, the edge node being used for, if a third fault code is found in the received second fault code, performing fault diagnosis according to the third fault code and third operation data corresponding to the third fault code to obtain a second diagnosis result; and the above method provides a more practical and more accurate vehicle fault diagnosis system.

Description

Technical Field

[0001] This application relates to the field of fault diagnosis technology, specifically to a vehicle fault diagnosis system, method, vehicle terminal, and storage medium. Background Technology

[0002] With the development of big data and artificial intelligence, in-vehicle applications and networks are becoming increasingly complex, leading to a surge in data volume. This results in challenges such as difficult data management, complex data maintenance, and high costs. In-vehicle network diagnostic data involves vehicle safety, maintenance, and repair. This data typically has high requirements for network latency and reliability. Centralized cloud-based remote diagnostics cannot meet real-time needs, and large amounts of data can cause cloud network congestion. Urgent data is often difficult to process efficiently, and poor cloud network coverage can also affect data transmission speed and quality.

[0003] Edge computing refers to providing services at the nearest point in time by using an open platform that integrates networking, computing, storage, and applications, located close to the source of the object or data. Applications originate at the edge, resulting in faster network service responses and meeting the industry's basic needs in real-time business, application intelligence, security, and privacy protection. Therefore, addressing the shortcomings of centralized cloud-based remote diagnostics in terms of network latency, network performance, and diagnostic speed, this solution provides a vehicle fault diagnosis system based on edge computing to solve at least one of these problems.

[0004] It should be noted that the above content only provides background information related to this application and does not necessarily constitute prior art. Summary of the Invention

[0005] In view of the shortcomings of the prior art described above, this application provides a vehicle fault diagnosis system, method, vehicle terminal and storage medium to reduce the transmission time and processing time of fault data, improve the real-time performance of fault diagnosis and improve the efficiency of fault data processing.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to one aspect of the embodiments of this application, a vehicle fault diagnosis system is provided, the vehicle fault diagnosis system including a vehicle terminal and an edge computing center; the vehicle terminal is used to collect diagnostic fault codes and vehicle operating data of the vehicle terminal; if a first fault code is found in the diagnostic fault codes, a first fault result is determined based on the first fault code; if a second fault code is found in the diagnostic fault codes, an edge node is determined based on the location information of the vehicle terminal, the edge node is connected, and the second fault code and the second operating data corresponding to the second fault code are sent to the edge node, the edge node being at least one of the edge computing centers; the edge node is used to perform fault diagnosis based on the third fault code and the third operating data corresponding to the third fault code if a third fault code is found in the received second fault code, to obtain a second diagnostic result, wherein the second operating data includes the third operating data.

[0008] In one embodiment of this application, based on the foregoing scheme, the vehicle fault diagnosis system further includes a server, which is connected to the edge node and the vehicle terminal. The server is used for at least one of the following: if it receives a fourth fault code and the fourth operating data corresponding to the fourth fault code sent by the edge node, it performs fault diagnosis based on the fourth fault code and the fourth operating data to obtain a third diagnostic result, wherein the fourth fault code is obtained by the edge node from the second fault code, and the second operating data includes the fourth operating data; if it obtains multiple historical operating data and fault results corresponding to each historical operating data, it uses each historical operating data as an operating data sample and labels the operating data samples according to the fault results to obtain result sample labels corresponding to each operating data sample; it trains a model on the operating data samples with result sample labels to obtain a fault diagnosis model and sends the fault diagnosis model to the edge node; if it receives a first diagnostic result and a second diagnostic result sent by the edge node, it generates a repair suggestion by combining the first diagnostic result, the second diagnostic result and the third diagnostic result, and sends the repair suggestion to the vehicle terminal, wherein the first diagnostic result is sent from the vehicle terminal to the edge node.

[0009] In one embodiment of this application, based on the foregoing scheme, the edge node is further configured to: perform preprocessing operations on the received second fault code and second operating data; encrypt the preprocessed second fault code and preprocessed second operating data according to a preset encryption algorithm and send them to the server; wherein the preprocessing operations include at least one of data cleaning, anomaly detection, data compression, feature extraction, and data conversion; receive the first diagnostic result sent by the vehicle terminal; determine the vehicle operating status corresponding to the vehicle terminal based on the first diagnostic result, the second fault code, and the second operating data; if the vehicle operating status is detected to be abnormal, generate a prompt message based on the vehicle operating status and send the prompt message to the vehicle terminal to prompt the user; receive a fault diagnosis model sent by the server; perform fault diagnosis on the third fault code and the third operating data based on the fault diagnosis model to obtain the second diagnostic result.

[0010] In one embodiment of this application, based on the aforementioned scheme, the vehicle terminal enables the remote diagnostic function in the following manner: receiving a remote diagnostic enable request sent by the server and obtaining current vehicle data; matching the current vehicle data with preset vehicle data and determining the current vehicle conditions based on the matching result; if the current vehicle conditions are the preset vehicle conditions, then enabling the remote diagnostic function and sending the enable result to the server, wherein the remote diagnostic function is to perform fault diagnosis on the fourth fault code and the fourth operating data through the server.

[0011] In one embodiment of this application, based on the foregoing scheme, the vehicle fault diagnosis system disables the remote diagnosis function by at least one of the following methods: after the server enables the remote diagnosis function, it starts a first timer; if the first time value of the first timer is greater than or equal to a first time threshold, the remote diagnosis function is disabled; after the server sends the remote diagnosis enable request, it starts a second timer; if the second time value of the second timer is greater than or equal to a second time threshold, the remote diagnosis function is disabled.

[0012] In one embodiment of this application, based on the aforementioned scheme, the vehicle terminal connects to the server in the following manner: if the opening result is successful, the server sends a connection establishment request and a route activation request to the vehicle terminal; after receiving the connection establishment request and the route activation request, the vehicle terminal establishes a connection and activates the route through the vehicle gateway, the electronic control unit connected to the vehicle gateway, and the vehicle sensors, so as to connect the vehicle terminal to the server.

[0013] According to one aspect of the embodiments of this application, a vehicle fault diagnosis method is provided, applied to an edge computing center. The vehicle fault diagnosis method includes: acquiring diagnostic fault codes and vehicle operating data of a vehicle terminal, wherein the vehicle terminal is used to collect the diagnostic fault codes and vehicle operating data; if a first fault code is found in the diagnostic fault codes, a first fault result is determined based on the first fault code; if a second fault code is found in the diagnostic fault codes, an edge node is determined based on the location information of the vehicle terminal, the edge node is connected, and the second fault code and the second operating data corresponding to the second fault code are sent to the edge node, wherein the edge node is at least one of the edge computing centers; if a third fault code is found in the received second fault code, a fault diagnosis is performed based on the third fault code and the third operating data corresponding to the third fault code to obtain a second diagnostic result, wherein the second operating data includes the third operating data.

[0014] According to one aspect of the embodiments of this application, a vehicle fault diagnosis method is provided, applied to a vehicle terminal. The vehicle fault diagnosis method includes: collecting diagnostic fault codes and vehicle operating data of the vehicle terminal; if a first fault code is found in the diagnostic fault codes, determining a first fault result based on the first fault code; if a second fault code is found in the diagnostic fault codes, determining an edge node based on the location information of the vehicle terminal, connecting the edge node, and sending the second fault code and the second operating data corresponding to the second fault code to the edge node. The edge node is at least one of an edge computing center. If a third fault code is found in the received second fault code, the edge node is used to perform fault diagnosis based on the third fault code and the third operating data corresponding to the third fault code to obtain a second diagnostic result, wherein the second operating data includes the third operating data.

[0015] According to one aspect of the embodiments of this application, a vehicle terminal is provided, the vehicle terminal comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the vehicle terminal enables the vehicle fault diagnosis method as described in the above embodiments.

[0016] This application also 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 fault diagnosis method as described in any of the above embodiments.

[0017] The beneficial effects of this application are as follows: This application provides a vehicle fault diagnosis system including a vehicle terminal and an edge computing center. The vehicle terminal is used to collect diagnostic fault codes and vehicle operating data. If a first fault code is found in the diagnostic fault codes, a first fault result is determined based on the first fault code. By determining the diagnostic result at the vehicle terminal, data transmission time is reduced, and diagnostic efficiency is improved. If a second fault code is found in the diagnostic fault codes, an edge node is determined based on the location information of the vehicle terminal, the edge node is connected, and the second fault code and the second operating data corresponding to the second fault code are sent to the edge node. The edge node is at least one of the edge computing centers. The edge node is used to... If a third fault code is found among the received second fault codes, fault diagnosis is performed based on the third fault code and the corresponding third operating data to obtain a second diagnostic result. The second operating data includes the third operating data. By determining the diagnostic result at the edge node, the data transmission time is reduced compared to transmitting all fault data to the cloud, thus improving diagnostic efficiency. This is especially true for fault data with high timeliness requirements, which can obtain diagnostic results faster and avoid safety hazards caused by long transmission times or high latency. This improves the user experience and satisfaction. Furthermore, performing fault diagnosis through edge nodes that are closer to the vehicle terminal reduces reliance on the network, saving bandwidth and costs.

[0018] In addition, the vehicle fault diagnosis system provided in this application can improve data privacy and security, reduce the amount of data transmitted to the server, thereby reducing network bandwidth usage and lowering costs.

[0019] 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

[0020] 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:

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

[0022] Figure 2 This is a block diagram illustrating a vehicle fault diagnosis system as shown in an exemplary embodiment of this application;

[0023] Figure 3 This is a schematic diagram of the architecture of a vehicle fault diagnosis system shown in an exemplary embodiment of this application;

[0024] Figure 4 This is a schematic flowchart illustrating a vehicle fault diagnosis method according to an exemplary embodiment of this application;

[0025] Figure 5 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. 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] First, it should be noted that MQTT (Message Queue Telemetry Transport) is a lightweight communication protocol based on the publish / subscribe model. It is built on top of the TCP / IP protocol and is a standard transmission protocol in the Internet of Things (IoT).

[0030] SOME / IP (Scalable Service-Oriented Middleware over IP) is a powerful, flexible, and reliable communication protocol primarily used in automotive and embedded systems for service discovery, description, configuration, and invocation within a network. SOME / IP is widely used to implement vehicle-to-everything (V2X) communication, enabling vehicles to exchange information securely and efficiently, improving driving safety and efficiency. Through SOME / IP, vehicles can discover services from other vehicles and infrastructure and communicate with them as needed. It also provides scalable communication capabilities for devices, making it particularly suitable for resource-constrained environments. As a lightweight communication protocol, SOME / IP can operate efficiently in these environments.

[0031] OTA (Over-the-Air) updates are a technology that delivers software updates, patches, or new versions to devices via a wireless network (such as Wi-Fi or mobile data). OTA updates allow for remote software upgrades by pushing new software versions or updates directly to the device via a wireless network without requiring physical contact. In the automotive industry, OTA updates are widely used for software updates in vehicle systems such as ECUs (Electronic Control Units).

[0032] OBD (On-Board Diagnostics) enables information exchange and fault diagnosis between various control units within a vehicle through standardized data interfaces and diagnostic protocols. The main function of the OBD system is to monitor engine operation and exhaust emissions, ensuring that the vehicle meets environmental and safety standards during use. When a vehicle malfunctions, the OBD system automatically records fault codes and alerts the driver via the MIL (Malfunction Indicator Light) on the dashboard. OBD occupancy primarily refers to the situation where the vehicle's OBD interface (on-board diagnostics interface) is used or occupied by external devices.

[0033] Cockpit self-check refers to a comprehensive check performed by the vehicle's computer system upon startup, examining all systems, components, and sensors within the cockpit to ensure they are functioning properly and meet the vehicle's safety and reliability requirements. The purpose of this process is to promptly detect and address potential faults or problems, preventing unexpected situations during vehicle operation. Cockpit self-checks typically include the following aspects: sensor checks (such as temperature sensors, pressure sensors, and acceleration sensors); system checks (such as air conditioning systems, audio systems, navigation systems, and seat heating / ventilation systems); safety equipment checks (including airbags and seat belts); and light and signal checks (such as reading lights, ambient lighting, instrument panel lights, turn signals, and brake lights).

[0034] DOIP (Diagnostic Communication over Internet Protocol) is a diagnostic communication protocol based on the Internet Protocol (IP) that allows for remote vehicle diagnostics via a network (such as Ethernet). The DOIP standard was developed by the ISO (International Organization for Standardization) to provide a standardized method for automakers, service providers, and vehicle owners to perform efficient and secure vehicle diagnostics and communication over a network.

[0035] A TBOX (Telematics Box), also known as an in-vehicle T-BOX, is a key component of modern vehicle-to-everything (V2X) systems. It primarily connects the vehicle to a backend system and a mobile application (APP), enabling real-time information transmission and remote control. Integrating a processor, GPS module, and 2G / 3G / 4G / 5G modules (with SIM card functionality), it connects to the in-vehicle CAN bus and an external cloud platform to facilitate communication and data exchange between vehicles (V2V), between vehicles and infrastructure (V2I), and between vehicles and the internet (V2N).

[0036] The development of communication and intelligent vehicle networking technologies has spurred the emergence of various complex applications. To ensure driving safety on the road, intelligent driving has emerged, and more and more OEMs are launching vehicles with autonomous driving capabilities. Currently, vehicles equipped with intelligent driving functions need to be equipped with various sensors such as LiDAR, millimeter-wave radar, high-definition cameras, and GPS (Global Positioning System) positioning systems to obtain real-time information about the surrounding environment. Vehicle driving data, facial recognition data, AR-HUD (Augmented Reality-Head-Up Display), and intelligent vehicle networking data make wireless communication technology more complex. At the same time, automotive electronic and electrical components are becoming increasingly complex, increasing the probability of vehicle safety hazards under complex operating conditions. How to quickly predict vehicle driving risks and respond promptly after a dangerous situation occurs requires vehicle fault monitoring and diagnosis. The application of edge computing in in-vehicle remote diagnostics is based on the ever-increasing digitalization and connectivity demands of modern automobiles. With the rapid development of electronic devices and information technology in vehicles, modern automobiles have become highly complex network systems. Intelligent vehicles are equipped with various sensors, actuators, and controllers, which can generate and process a large amount of data, including but not limited to engine operating status, vehicle position, speed, fuel consumption, passenger comfort indicators, and safety-related parameters.

[0037] Currently, remote fault diagnosis primarily utilizes real-time cloud-based positioning of vehicle system operations, supporting vehicle maintenance monitoring, remote problem handling, customer service support, and user operations, achieving an end-to-end closed-loop capability from data insight to execution. Remote fault monitoring and diagnosis mainly leverages vehicle controllers and vehicle-to-cloud wireless communication. Specifically, remote diagnostic commands are issued from the cloud, enabling vehicle controllers to collect data and information in real time and promptly upload vehicle faults to the cloud, thus achieving remote fault monitoring and diagnosis. Simultaneously, technicians can use cloud-based alarm information to investigate, detect, and analyze vehicle problems in real time, proactively identifying issues and mitigating risks. However, modern vehicles are equipped with numerous sensors that continuously generate data, leading to a surge in data volume that requires rapid and effective processing. For vehicle health monitoring and fault diagnosis, real-time data processing is crucial to ensure timely detection of potential faults and avoidance of safety hazards. Furthermore, the transmission of large amounts of data poses a challenge to network bandwidth, especially in areas with poor network coverage, potentially affecting data transmission speed and quality. Edge computing, as a distributed computing paradigm, brings data processing and application services as close as possible to the data source, i.e., the "network edge." In the context of edge computing-based remote vehicle diagnostics, this means deploying computing resources inside or near the vehicle, rather than relying entirely on remote cloud servers. This approach can reduce latency, save bandwidth, improve security, and enhance autonomy.

[0038] Figure 1 This is a schematic diagram illustrating an exemplary system architecture as shown in an exemplary embodiment of this application.

[0039] Reference Figure 1As shown, the system architecture may include a data acquisition device 101 and a computer device 102. The computer device 102 may be at least one of a desktop graphics processing unit (GPU) computer, a GPU computing cluster, or a neural network computer. The data acquisition device 101 is used to collect diagnostic fault codes and vehicle operating data from the vehicle terminal. In this embodiment, after acquiring the data, the data acquisition device 101 provides it to the computer device 102 for processing. Relevant technicians can use the computer device 102 to search for diagnostic fault codes. If a first fault code is found in the diagnostic fault codes, a first fault result is determined based on the first fault code. If a second fault code is found in the diagnostic fault codes, an edge node is determined based on the vehicle terminal's location information, the edge node is connected, and the second fault code and the corresponding second operating data are sent to the edge node. The edge node is at least one of an edge computing center. If a third fault code is found in the received second fault code, the edge node performs fault diagnosis based on the third fault code and the corresponding third operating data to obtain a second diagnostic result, wherein the second operating data includes the third operating data. It should be noted that the data acquisition device 101 and computer device 102 provided in this embodiment are merely examples and should not impose any limitations on the functions and scope of use of the embodiments of this application.

[0040] It should be noted that the vehicle fault diagnosis method provided in this application embodiment is generally executed by computer device 102, and correspondingly, the vehicle fault diagnosis system is generally set in computer device 102.

[0041] Figure 2 This is a block diagram illustrating a vehicle fault diagnosis system as shown in an exemplary embodiment of this application. The system can be applied to... Figure 1 The implementation environment shown is specifically configured in computer device 102. This system can also be applied to other exemplary implementation environments and specifically configured in other devices; this embodiment does not limit the implementation environment to which the system is applicable.

[0042] In one embodiment of this application, such as Figure 2As shown, this exemplary vehicle fault diagnosis system includes a vehicle terminal 210 and an edge computing center 220. The vehicle terminal 210 is used to collect diagnostic fault codes and vehicle operating data. If a first fault code is found in the diagnostic fault codes, a first fault result is determined based on the first fault code. If a second fault code is found in the diagnostic fault codes, an edge node is determined based on the location information of the vehicle terminal 210, the edge node is connected, and the second fault code and the corresponding second operating data are sent to the edge node. The edge node is at least one of the edge computing centers 220. The edge node is used to perform fault diagnosis based on the third fault code and the corresponding third operating data if a third fault code is found in the received second fault code, thereby obtaining a second diagnostic result. The vehicle operating data includes the second operating data, and the second operating data includes the third operating data.

[0043] In this embodiment, vehicle operating data includes, but is not limited to, one or more of the following: basic operating parameters, braking and safety system parameters, vehicle driving parameters, power-related parameters, and vehicle dynamic data. Basic operating parameters include engine parameters (including engine start and stop times, engine temperature, speed, throttle opening, and continuous operating time), transmission system parameters (such as gearbox gear position, shift mode, and battery voltage), and driving parameters (such as vehicle speed, mileage, and steering angle). Braking and safety system parameters include the braking system's operating status (including master cylinder pressure and ABS (anti-lock braking system) status), and the status of forward collision warning and automatic emergency braking functions. Vehicle driving parameters include the vehicle's real-time location, driving trajectory, and operating mode. Power-related parameters include the motor's operating status (including motor speed, torque, and temperature) and battery voltage. Vehicle dynamic data refers to real-time data from sensors installed on various vehicle systems (such as the braking system, lighting system, and engine system).

[0044] In this embodiment, determining the first fault result based on the first fault code may include determining the fault information corresponding to the first fault code based on the first fault code, and determining the first fault result based on the fault information. For example, in some vehicles, if the engine's electronic control unit (ECU) detects that a specific sensor signal is out of normal range, it may generate a specific fault code. This fault code is almost always caused by a fault in the sensor itself. In this case, replacing or repairing the sensor usually solves the problem. The first fault code is a relatively simple fault code. The method for determining a diagnostic fault code as the first fault code may include: determining the fault code according to a pre-set fault code type; if the fault code type of the diagnostic fault code is a simple fault, then the diagnostic fault code is determined as the first fault code; alternatively, a first fault code may be pre-set, and the collected diagnostic fault code is matched with the pre-set first fault code. If the match is successful, the diagnostic fault code is then determined as the first fault code.

[0045] In this embodiment, the vehicle terminal acquires the diagnostic fault codes and real-time vehicle operating data from the corresponding controller, and saves the freeze frame data related to the fault. Then, it performs self-diagnosis and continuous monitoring of the vehicle's condition. Most vehicle-side sensors have built-in self-diagnostic functions, automatically checking their own operating status and reporting abnormalities to the controller. Different types of sensors and vehicles typically have different testing standards and procedures. The controller also continuously monitors the corresponding sensor signals, using a preset algorithm to determine the correctness of the signal values ​​for fault detection. The current signal value is compared with a preset signal value. If the current signal value is equal to the preset signal value, it is determined to be correct; if it is not equal, it is determined to be incorrect, and the sensor is considered faulty.

[0046] In this embodiment, if a second fault code is found in the diagnostic fault codes, an edge node is determined based on the vehicle terminal's location information and the coverage area of ​​the edge computing center. Specifically, if the vehicle terminal is determined to be within the coverage area of ​​the edge computing center based on its location information and the coverage area of ​​the edge computing center, then the corresponding edge computing center is determined as an edge node. Applying edge computing technology to the vehicle fault diagnosis system enables real-time and efficient remote fault diagnosis of vehicles.

[0047] In this embodiment, the edge node can also perform fault diagnosis on the third fault code and third operating data by receiving the fault diagnosis model sent by the server to obtain a second diagnostic result. This is to handle fault data with high timeliness requirements or data with significant safety hazards. The method for determining the third fault code includes determining it according to a preset fault code type and determining it by comparing the second fault code with the preset third fault code. The diagnostic fault codes include a first fault code and a second fault code, the second fault code includes a third fault code and a fourth fault code, and the vehicle operating data includes first operating data and second operating data, the second operating data includes third operating data and fourth operating data. Edge computing deploys data processing capabilities close to the data source, meaning that data does not need to be transmitted to a remote server for a long time. Therefore, near real-time diagnosis and response can be achieved, which is particularly important for scenarios requiring immediate feedback, such as emergency faults detected during vehicle operation. Through real-time fault detection and rapid response, vehicle downtime can be reduced, improving vehicle availability and driver satisfaction.

[0048] In one embodiment of this application, the vehicle fault diagnosis system further includes a server connected to an edge node and a vehicle terminal. The server is used for at least one of the following: if it receives a fourth fault code and the corresponding fourth operating data sent by the edge node, it performs fault diagnosis based on the fourth fault code and the fourth operating data to obtain a third diagnostic result, wherein the fourth fault code is obtained by the edge node from the second fault code, and the second operating data includes the fourth operating data; if it obtains multiple historical operating data and the fault results corresponding to each historical operating data, it uses each historical operating data as an operating data sample and labels the operating data samples according to the fault results to obtain result sample labels corresponding to each operating data sample; it trains a model on the operating data samples with result sample labels to obtain a fault diagnosis model and sends the fault diagnosis model to the edge node; if it receives a first diagnostic result and a second diagnostic result sent by the edge node, it generates a repair suggestion by combining the first diagnostic result, the second diagnostic result and the third diagnostic result, and sends the repair suggestion to the vehicle terminal, wherein the first diagnostic result is sent from the vehicle terminal to the edge node.

[0049] In this embodiment, if an edge node finds a fourth fault code from the second fault code, it sends the fourth fault code and the corresponding fourth operational data to the server. The fault data corresponding to the fourth fault code is complex, has low timeliness requirements, and is large in volume. The method for determining the fourth fault code includes determining it based on a preset fault code type and comparing the second fault code with the preset fourth fault code. The server can perform fault diagnosis on the fourth fault code and the fourth operational data sent by the edge node based on the trained fault diagnosis model to obtain a third diagnostic result, thus handling complex fault data with low timeliness requirements or large data volumes.

[0050] In this embodiment, the cloud-based, server-side diagnostic center is responsible for storing and further optimizing the diagnostic data (diagnostic results) from the vehicle and edge servers before uploading the data to the maintenance decision system center to generate specific diagnostic and repair suggestions. This makes the diagnostic data more accessible to users or maintenance personnel, visualizes the diagnostic data, and also supports processing some latency-insensitive data.

[0051] In one embodiment of this application, the edge node is further used for at least one of the following: preprocessing the received second fault code and second operating data; encrypting the preprocessed second fault code and preprocessed second operating data according to a preset encryption algorithm and sending them to the server; wherein the preprocessing operation includes at least one of data cleaning, anomaly detection, data compression, feature extraction, and data conversion; receiving a first diagnostic result sent by the vehicle terminal; determining the vehicle operating status corresponding to the vehicle terminal based on the first diagnostic result, the second fault code, and the second operating data; if an abnormal vehicle operating status is detected, generating a prompt message based on the vehicle operating status and sending the prompt message to the vehicle terminal to notify the user; receiving a fault diagnosis model sent by the server; performing fault diagnosis on the third fault code and the third operating data according to the fault diagnosis model to obtain a second diagnostic result. Sensitive vehicle data can be encrypted and preprocessed on the edge device, and only necessary information is uploaded to the cloud, which reduces the risk of data leakage and improves the overall data security.

[0052] In this embodiment, the edge computing center mainly includes acquiring diagnostic data from the vehicle (i.e., the first diagnostic result) and data sources (i.e., the first operational data), encrypting this data to ensure data security and make fault diagnosis more efficient. Edge computing centers typically incorporate various machine learning algorithms to identify abnormal data and discover potential anomalies.

[0053] In this embodiment, the edge computing center can reduce the amount of data that needs to be transmitted to the cloud, thereby reducing cloud network load and saving bandwidth. The edge computing center can also monitor the vehicle's operating status and driving behavior in real time based on data collected from vehicle sensors, such as engine temperature, oil pressure, and speed. When anomalies are detected, the system can react quickly, automatically adjusting the vehicle's driving mode or alerting the driver to potential problems. By promptly identifying and resolving potential issues, driving safety is improved. Basic fault diagnosis and processing can be performed offline; sensitive data can be processed locally without uploading to the cloud, enhancing data security and privacy protection; and data analysis and prediction can be performed using artificial intelligence and machine learning algorithms.

[0054] In this embodiment, the edge computing center is equivalent to a small cloud server. While its computing power is not as strong as a cloud center, it is closer to the terminal device and can process real-time and urgent data from the vehicle, mitigating network congestion and bandwidth consumption associated with direct uploads to the cloud, and also reducing task processing latency. The edge computing center can perform data preprocessing on diagnostic data, including but not limited to at least one of the following: data cleaning, anomaly detection, data compression, feature extraction, and data transformation. Specifically, data cleaning removes invalid or erroneous data points; for example, sensors may occasionally send out anomalies that require filtering. Anomaly detection uses statistical methods or machine learning models to identify outliers or unusual behaviors, such as by setting thresholds or using clustering algorithms to identify unusual data patterns. Data compression reduces data transmission bandwidth requirements without affecting the quality of data analysis. Feature extraction extracts useful features from the raw data, simplifying the dataset and improving the speed of subsequent processing. Data transformation converts the data into a form more suitable for further analysis as needed.

[0055] In this embodiment, edge computing centers are typically located close to terminal devices. For example, in the Internet of Vehicles (IoV), edge computing roadside units refer to edge computing devices deployed on the roadside. These devices can process data from vehicles and roadside sensors to support real-time or near-real-time applications and services.

[0056] In one embodiment of this application, the vehicle terminal enables the remote diagnostic function in the following manner: receiving a remote diagnostic enable request sent by the server and obtaining the current vehicle data; matching the current vehicle data with preset vehicle data and determining the current vehicle conditions based on the matching result; if the current vehicle conditions are the preset vehicle conditions, then enabling the remote diagnostic function and sending the enable result to the server, wherein the remote diagnostic function is to perform fault diagnosis on the fourth fault code and the fourth operating data through the server.

[0057] In this embodiment, the current vehicle data includes, but is not limited to, one or more of the following: system update status, firmware version change, network communication data, OBD diagnostic session status, diagnostic fault codes, communication interface status, self-test flag, instrument panel indicator lights, and vehicle system log. The preset vehicle conditions include that the vehicle is not in OTA flashing, not in OBD occupancy, and not in cabin self-test state.

[0058] In one embodiment of this application, the vehicle fault diagnosis system disables the remote diagnosis function by at least one of the following methods: after the server enables the remote diagnosis function, it starts a first timer; if the first time value of the first timer is greater than or equal to a first time threshold, the remote diagnosis function is disabled; after the server sends a remote diagnosis enable request, it starts a second timer; if the second time value of the second timer is greater than or equal to a second time threshold, the remote diagnosis function is disabled.

[0059] In one embodiment of this application, the vehicle terminal connects to the server in the following manner: if the opening result is successful, the server sends a connection establishment request and a route activation request to the vehicle terminal; after receiving the connection establishment request and the route activation request, the vehicle terminal establishes a connection and activates the route through the vehicle gateway, the electronic control unit connected to the vehicle gateway, and the on-board sensors, so as to connect the vehicle terminal to the server.

[0060] In one embodiment of this application, the diagnosis is jointly performed by the vehicle terminal, the roadside edge computing center, and the cloud server. Each of the three has different functions: the vehicle terminal is responsible for acquiring diagnostic data (diagnostic fault codes and vehicle operation data); the edge server is responsible for encrypting the data and uploading it to the cloud center; and the cloud is responsible for storing and further optimizing the diagnostic data. Generally, sensitive data generates encryption keys on the vehicle terminal and edge computing nodes. These keys are distributed to recipients, including the server, via a secure channel. The keys are then securely stored in the edge computing device and used for data acquisition and processing. The vehicle terminal can also match the first fault code in the diagnostic fault codes with preset fault codes to determine a first diagnostic result, thus handling simple fault data. The roadside can also receive a fault diagnosis model sent from the cloud to diagnose a third fault code and third operation data, obtaining a second diagnostic result, to handle fault data with high timeliness requirements or significant safety risks. The diagnostic fault codes include a first fault code and a second fault code, and the second fault code includes a third fault code and a fourth fault code. The cloud can also perform fault diagnosis on the fourth fault code and fourth operating data sent by the roadside based on the fault diagnosis model trained, and obtain the third diagnosis result to handle complex fault data with low timeliness requirements or large data volume.

[0061] Figure 3 This is a schematic diagram of the architecture of a vehicle fault diagnosis system illustrated in an exemplary embodiment of this application, such as... Figure 3 As shown in an exemplary embodiment, the vehicle fault diagnosis system mainly includes three ends: the vehicle end (vehicle terminal), the road end (edge ​​computing center), and the cloud end (server end), totaling six parts. The cloud end includes a maintenance decision system center, a remote diagnosis management platform, and a remote diagnosis data processing center. The vehicle end includes an in-vehicle connected terminal and a vehicle control center. The road end includes an edge processing center. The maintenance decision system center primarily generates specific vehicle maintenance suggestions based on the analysis results from the remote diagnosis data processing center and sends them to the maintenance decision system center, allowing users or maintenance personnel to view diagnostic reports and maintenance suggestions and take timely corresponding measures. The remote diagnosis management platform is mainly responsible for issuing remote diagnosis commands to the in-vehicle connected terminal and collecting and monitoring vehicle fault alarms in real time, as well as obtaining remote diagnosis commands fed back from the vehicle end. The remote diagnosis data processing center is mainly responsible for processing and optimizing the pre-processed analysis and diagnostic data uploaded by the edge processing center and promptly uploading the diagnostic results to the maintenance decision system center for user viewing. The in-vehicle connected terminal is mainly responsible for transmitting remote diagnostic data to the vehicle terminal. Commands in MQTT protocol format issued by the diagnostic management platform are converted into commands in SOME / IP protocol format and transmitted to the diagnostic task management center of the vehicle control center. At the same time, it forwards fault information and alarm messages uploaded by the vehicle domain controller. The vehicle control center includes a diagnostic task management center, a diagnostic command filtering center, and a diagnostic gateway. It is mainly responsible for coordinating the diagnostic needs of various electronic control units and controllers, and is also responsible for actively uploading alarm messages from domain controllers to the remote diagnostic data processing center. The edge processing center is mainly responsible for receiving diagnostic data uploaded by vehicle sensors and preprocessing the data to reduce cloud server load, reduce network dependence, save bandwidth and costs, and improve diagnostic real-time performance to meet low latency requirements.

[0062] In this embodiment, the main functions that the vehicle fault diagnosis system can achieve include: big data monitoring, online fault alarm monitoring, remote online vehicle fault diagnosis, remote online reading of vehicle data stream, and remote online clearing of vehicle faults. Its main functional modules include remote fault diagnosis wake-up strategy, remote fault diagnosis on / off, remote fault diagnosis execution, remote diagnosis management, and remote fault monitoring of edge servers.

[0063] In this embodiment, the remote diagnostic management platform uses the MQTT protocol to send a remote diagnostic activation request to the vehicle-mounted connected terminal. Then, it converts the activation request instruction into a SOME / IP protocol instruction and sends it to the vehicle. After receiving the remote diagnostic activation request from the cloud, the vehicle needs to perform a vehicle condition check, such as checking whether the vehicle is in OTA flashing, whether it is in OBD usage, whether it is in cockpit self-test mode, etc. If the vehicle condition check meets the preset vehicle conditions, it sends a remote diagnostic activation response to the vehicle-mounted connected terminal. The activation result is considered successful, and then the remote diagnostic activation instruction is forwarded to the cloud.

[0064] In this embodiment, the cloud port and the vehicle port use DOIP protocol instructions to establish links and activate routes. At the same time, the vehicle control center needs to establish DOIP links and activate routes with its multiple electronic control units and vehicle sensors through the diagnostic gateway.

[0065] In this embodiment, the vehicle control center receives diagnostic requests sent from the cloud and routes them to the corresponding electronic control unit nodes and vehicle sensors. The destination node executes the diagnostic request and replies with a positive or negative response. The diagnostic response is fed back to the cloud using the same routing path. Then, the remote diagnostic management platform parses and presents the remote fault diagnosis results.

[0066] In this embodiment, after the vehicle-side control center receives the relevant configuration created by the remote diagnostic management platform, the vehicle-side controller needs to log in to the cloud with its current configuration version and verify the configuration version with the cloud. After receiving the corresponding configuration and the alarm-related master control service is initialized, the vehicle-side domain controller will filter and encapsulate its own fault information and alarm messages, and upload them to the maintenance decision system center in real time. The maintenance decision system center will then parse and display the alarm information.

[0067] In this embodiment, sensors inside and outside the vehicle are used to collect various data, which is then uploaded to an edge server, or edge processing center. The edge processing center can be a small computer installed in the vehicle. The edge server is responsible for processing and analyzing the data uploaded by the vehicle in real time. The edge computing center can perform preliminary data cleaning, anomaly detection, and data identification, reducing the amount of data that needs to be transmitted to the cloud, improving response speed, and reducing network bandwidth requirements.

[0068] In this embodiment, both the cloud and the vehicle support disabling remote fault monitoring and diagnostic tasks, i.e., disabling the remote diagnostic function. Upon receiving a remote fault diagnosis enable command, the vehicle starts a local first timer. If the vehicle's conditions do not meet preset vehicle conditions, a rollback operation is performed, the link is disconnected, and a remote diagnostic disable command is sent to the vehicle-mounted connected terminal for forwarding to the cloud, thus disabling the remote diagnostic function. After the cloud sends a remote diagnostic enable request, it starts a second timer. If the cloud does not receive a remote diagnostic enable response within the second time threshold, it sends a remote fault diagnosis disable request to the vehicle-mounted connected terminal to disable the remote diagnostic function.

[0069] Figure 4 This is a schematic flowchart illustrating a vehicle fault diagnosis method according to an exemplary embodiment of this application. The vehicle fault diagnosis method can be executed by a computing processing device, which may be... Figure 1 The computer device 102 shown is illustrated. (Refer to...) Figure 4 As shown, this vehicle fault diagnosis method includes at least steps S1 to S8, which are described in detail below:

[0070] In step S1, after the vehicle is woken up and the TBOX logs into the cloud, the remote diagnostic management platform sends a remote diagnostic start request to the TBOX using the MQTT protocol. At the same time, the TBOX switches to the SOMEIP protocol to send a remote diagnostic start request to the vehicle. At this time, the vehicle starts the vehicle condition check and sends the start result back to the cloud.

[0071] In step S2, after the vehicle-side remote diagnostic function is enabled, the successful activation response is forwarded by TBOX to the remote diagnostic management platform. Then, the remote diagnostic center sends a link establishment request and a route activation request to the vehicle-side control center through the DOIP protocol on the port.

[0072] In step S3, after receiving the route activation request and the link establishment request, the vehicle control center performs route activation and link establishment processing, and sends DOIP protocol instructions to each electronic control unit and sensor to enable remote diagnostic function through the diagnostic gateway.

[0073] In step S4, after the remote diagnostic function is enabled, the corresponding sensors on the vehicle begin to perform fault detection and upload the diagnostic data to the edge computing center for preprocessing via a wireless link. The diagnostic data includes diagnostic fault codes and vehicle operating data.

[0074] In step S5, the edge computing center preprocesses the diagnostic data and then uploads the diagnostic data analysis results to the remote diagnostic data processing center.

[0075] In step S6, the remote diagnostic data processing center stores and further optimizes the diagnostic data before uploading it to the maintenance decision system center to generate specific diagnostic and maintenance suggestions for use by users or maintenance personnel.

[0076] In step S7, users and maintenance personnel can receive diagnostic reports and maintenance recommendations through the maintenance decision system center to support vehicle problem optimization.

[0077] In step S8, after enabling remote diagnostics, both the cloud and the vehicle need to start their respective timers. Once the timer conditions are met, both the cloud and the vehicle can disable remote diagnostics and disconnect the link.

[0078] This application reduces reliance on the network through edge computing. Even in the event of network instability or disconnection, preliminary diagnostics can be performed locally. Edge computing can also preprocess data locally, transmitting only critical data to the cloud, thus significantly reducing network bandwidth usage and lowering costs. Edge computing is also better suited for large-scale deployments because each edge device can process data independently, reducing the burden on the central server and making the entire system more scalable. Furthermore, it can provide personalized diagnostic and maintenance recommendations based on the specific conditions of each vehicle, such as predicting potential future failures based on vehicle usage patterns and historical records.

[0079] This application reduces the time for data to travel to and from the cloud, which is especially advantageous in situations with high network latency. This is particularly important in emergencies. It also uploads vehicle diagnostic data to an edge server for preprocessing and preliminary analysis, which can greatly improve the efficiency of system data processing. At the same time, edge computing can process and upload only critical information in real time, greatly reducing transmission and processing time. This application also combines the advantages of edge computing, placing data processing and computing power at the network edge, reducing the risk of data leakage, enhancing data privacy protection, and also reducing cloud load and improving resource utilization.

[0080] In one embodiment of this application, a vehicle fault diagnosis method is provided, applied to an edge computing center. The vehicle fault diagnosis method includes: acquiring diagnostic fault codes and vehicle operating data from a vehicle terminal, wherein the vehicle terminal is used to collect diagnostic fault codes and vehicle operating data; if a first fault code is found in the diagnostic fault codes, a first fault result is determined based on the first fault code; if a second fault code is found in the diagnostic fault codes, an edge node is determined based on the location information of the vehicle terminal, the edge node is connected, and the second fault code and the second operating data corresponding to the second fault code are sent to the edge node, wherein the edge node is at least one in the edge computing center; if a third fault code is found in the received second fault code, a fault diagnosis is performed based on the third fault code and the third operating data corresponding to the third fault code to obtain a second diagnostic result, wherein the second operating data includes the third operating data.

[0081] In one embodiment of this application, a vehicle fault diagnosis method is provided, applied to a vehicle terminal. The vehicle fault diagnosis method includes: collecting diagnostic fault codes and vehicle operating data from the vehicle terminal; if a first fault code is found in the diagnostic fault codes, a first fault result is determined based on the first fault code; if a second fault code is found in the diagnostic fault codes, an edge node is determined based on the location information of the vehicle terminal, the edge node is connected, and the second fault code and the second operating data corresponding to the second fault code are sent to the edge node. The edge node is at least one of the edge computing centers. If a third fault code is found in the received second fault code, the edge node is used to perform fault diagnosis based on the third fault code and the third operating data corresponding to the third fault code to obtain a second diagnostic result, wherein the second operating data includes the third operating data.

[0082] It should be noted that the vehicle fault diagnosis method provided in the above embodiments and the vehicle fault diagnosis system provided in the above embodiments belong to the same concept. The specific operation methods of each step have been described in detail in the system embodiments and will not be repeated here. In practical applications, the vehicle fault diagnosis system provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0083] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the vehicle fault diagnosis methods provided in the various embodiments described above. In this embodiment, the electronic device includes a vehicle terminal.

[0084] Figure 5A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 5 The computer system 500 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0085] like Figure 5 As shown, the computer system 500 includes a Central Processing Unit (CPU) 501, which can perform various appropriate actions and processes, such as executing the methods provided in the various embodiments described above, based on a program stored in Read-Only Memory (ROM) 502 or a program loaded from Storage Unit 508 into Random Access Memory (RAM) 503. The RAM 503 also stores various programs and data required for system operation. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An Input / Output (I / O) interface 505 is also connected to the bus 504.

[0086] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. Removable media 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 510 as needed so that computer programs read from them can be installed into storage section 508 as needed.

[0087] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs various functions defined in the system of this application.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] Another aspect of this application 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 fault diagnosis method provided in the various embodiments described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0092] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0093] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the vehicle fault diagnosis method provided in the various embodiments described above.

[0094] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0095] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0096] 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 fault diagnosis system, characterized in that, The vehicle fault diagnosis system includes a vehicle terminal, an edge computing center, and a server. The vehicle terminal is used to collect diagnostic fault codes and vehicle operation data. If a first fault code is found in the diagnostic fault codes, a first fault result is determined based on the first fault code. If a second fault code is found in the diagnostic fault codes, an edge node is determined based on the location information of the vehicle terminal, the edge node is connected, and the second fault code and the second operating data corresponding to the second fault code are sent to the edge node. The edge node is at least one of the edge computing centers. The edge node is used to perform fault diagnosis based on the third fault code and the third operating data corresponding to the third fault code if a third fault code is found in the received second fault code, and obtain a second diagnostic result, wherein the second operating data includes the third operating data; The server is connected to the edge node and the vehicle terminal, and the server is used for at least one of the following: If the edge node receives a fourth fault code and the fourth operating data corresponding to the fourth fault code, then the edge node performs fault diagnosis based on the fourth fault code and the fourth operating data to obtain a third diagnosis result. The fourth fault code is obtained by the edge node from the second fault code, and the second operating data includes the fourth operating data. If multiple historical operating data and the corresponding fault results for each of the historical operating data are obtained, then each of the historical operating data is used as an operating data sample, and the operating data sample is labeled according to the fault results to obtain the result sample label corresponding to each of the operating data samples; the operating data sample with the result sample label is used for model training to obtain a fault diagnosis model, and the fault diagnosis model is sent to the edge node; If the first diagnostic result and the second diagnostic result sent by the edge node are received, a maintenance suggestion is generated by combining the first diagnostic result, the second diagnostic result and the third diagnostic result, and the maintenance suggestion is sent to the vehicle terminal, wherein the first diagnostic result is sent to the edge node by the vehicle terminal.

2. The vehicle fault diagnosis system according to claim 1, characterized in that, The edge node is also used for at least one of the following: The received second fault code and second operating data are preprocessed. The preprocessed second fault code and preprocessed second operating data are encrypted according to a preset encryption algorithm and sent to the server. The preprocessing operation includes at least one of data cleaning, anomaly detection, data compression, feature extraction and data conversion. The system receives the first diagnostic result sent by the vehicle terminal, determines the vehicle operating status corresponding to the vehicle terminal based on the first diagnostic result, the second fault code, and the second operating data, and if the vehicle operating status is detected to be abnormal, generates a prompt message based on the vehicle operating status and sends the prompt message to the vehicle terminal to prompt the user. The system receives the fault diagnosis model sent by the server, performs fault diagnosis on the third fault code and the third operating data according to the fault diagnosis model, and obtains the second diagnosis result.

3. The vehicle fault diagnosis system according to claim 1, characterized in that, The vehicle terminal enables remote diagnostics in the following ways: Receive the remote diagnostics activation request sent by the server and obtain the current vehicle data; The current vehicle data is matched with preset vehicle data, and the current vehicle conditions are determined based on the matching results. If the current vehicle conditions are the preset vehicle conditions, then the remote diagnostic function is activated, and the activation result is sent to the server. The remote diagnostic function is to perform fault diagnosis on the fourth fault code and the fourth operating data through the server.

4. The vehicle fault diagnosis system according to claim 3, characterized in that, The vehicle fault diagnosis system disables the remote diagnostic function by at least one of the following methods: After the server enables the remote diagnostic function, it starts a first timer. If the first timer value is greater than or equal to a first time threshold, the remote diagnostic function is turned off. After the server sends the remote diagnostics enable request, it starts a second timer. If the second timer value is greater than or equal to the second time threshold, the remote diagnostics function is disabled.

5. The vehicle fault diagnosis system according to claim 3, characterized in that, The vehicle terminal connects to the server in the following manner: If the activation result is successful, the server sends a link establishment request and a route activation request to the vehicle terminal. After receiving the connection establishment request and the route activation request, the vehicle terminal establishes a connection and activates a route through the electronic control unit and on-board sensors connected to the vehicle gateway, so as to connect the vehicle terminal to the server.

6. A vehicle fault diagnosis method, applied to a vehicle fault diagnosis system as described in any one of claims 1 to 5, characterized in that, The vehicle fault diagnosis method, applied to edge computing centers, includes: The system acquires diagnostic fault codes and vehicle operation data from a vehicle terminal. The vehicle terminal is used to collect these data. If a first fault code is found in the diagnostic fault codes, a first fault result is determined based on the first fault code. If a second fault code is found in the diagnostic fault codes, an edge node is determined based on the location information of the vehicle terminal. The edge node is then connected, and the second fault code and corresponding second operation data are sent to the edge node. The edge node is at least one of the edge computing centers. If a third fault code is found in the received second fault code, then a fault diagnosis is performed based on the third fault code and the third operating data corresponding to the third fault code to obtain a second diagnostic result, wherein the second operating data includes the third operating data.

7. A vehicle fault diagnosis method, applied to a vehicle fault diagnosis system as described in any one of claims 1 to 5, characterized in that, The vehicle fault diagnosis method, applied to vehicle terminals, includes: The system collects diagnostic fault codes and vehicle operating data from the vehicle terminal. If a first fault code is found in the diagnostic fault codes, a first fault result is determined based on the first fault code. If a second fault code is found in the diagnostic fault codes, an edge node is determined based on the location information of the vehicle terminal, the edge node is connected, and the second fault code and the corresponding second operating data are sent to the edge node. The edge node is at least one of the edge computing centers. If a third fault code is found in the received second fault code, the edge node performs fault diagnosis based on the third fault code and the corresponding third operating data to obtain a second diagnostic result, wherein the second operating data includes the third operating data.

8. A vehicle terminal, characterized in that, The vehicle terminal includes: One or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, cause the vehicle terminal to implement the vehicle fault diagnosis method as described in claim 7.

9. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the computer's processor, causes the computer to perform the vehicle fault diagnosis method as described in claim 6 or 7.

Images