Vehicle diagnosis method and device, vehicle and computer readable storage medium

Abstract

This invention proposes a vehicle diagnostic method, apparatus, vehicle, and computer-readable storage medium. The method includes the following steps: if a vehicle anomaly is detected, acquiring basic vehicle operating data; determining whether a basic anomaly has occurred based on the basic operating data; if no basic anomaly has occurred, acquiring the vehicle signal data for the current diagnostic cycle and uploading the vehicle signal data to a server, so that the server can perform anomaly diagnosis on the vehicle based on the vehicle signal data. By performing anomaly judgment on the basic operating data at the vehicle end, most vehicle anomalies caused by abnormal basic data can be diagnosed locally, avoiding uploading all of this data to the server, reducing data transmission pressure and server diagnostic pressure; when no anomaly is detected in the basic operating data, the vehicle signal data collected in the current diagnostic cycle is uploaded to the server for more accurate diagnosis by the server, thereby ensuring diagnostic accuracy.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving, and more particularly to a vehicle diagnostic method, apparatus, vehicle, and computer-readable storage medium. Background Technology

[0002] Intelligent driving technology is rapidly developing along a data-driven path, leading to a growing demand for analyzing and processing abnormal data in intelligent driving. Current technologies for diagnosing intelligent driving faults rely on real-time reporting and batch data dumping for remote analysis. This method requires uploading relevant data to a server, resulting in high transmission costs and significant server load, ultimately leading to low diagnostic efficiency. Summary of the Invention

[0003] The main objective of this invention is to provide a vehicle diagnostic method, apparatus, vehicle, and computer-readable storage medium, aiming to solve the problem of low diagnostic efficiency in existing diagnostic schemes.

[0004] To achieve the above objectives, the present invention provides a vehicle diagnostic method, the method comprising the following steps: If a vehicle anomaly is detected, the vehicle's basic operating data is obtained; Based on the aforementioned basic operational data, determine whether the vehicle has experienced any basic abnormalities; If no basic abnormality is found in the vehicle, the vehicle signal data for the current diagnostic cycle is acquired and uploaded to the server so that the server can perform abnormality diagnosis on the vehicle based on the vehicle signal data.

[0005] Optionally, determining whether a vehicle has a basic abnormality based on the basic operating data includes: Determine whether the basic operational data triggers a data anomaly condition; If the basic operating data does not trigger a data anomaly condition, then the software function status corresponding to the basic operating data is determined; Determine whether the software function status is abnormal; If the software function is abnormal, then the vehicle is determined to have a basic abnormality.

[0006] Optionally, determining whether the basic operational data triggers a data anomaly condition includes: Obtain sub-data from the basic operational data; For each of the sub-data, the current publication period of the sub-data is determined, wherein the current publication period indicates the time interval since the last publication of the sub-data; Determine whether the current release cycle is greater than the preset cycle threshold of the sub-data; If the current release cycle is greater than the preset cycle threshold of the sub-data, then the sub-data is determined to be abnormal; If there are abnormal sub-data in the basic operating data, then the basic operating data is determined to trigger a data abnormality condition.

[0007] Optionally, determining whether the basic operational data triggers a data anomaly condition includes: Obtain sub-data from the basic operating data, wherein the sub-data includes hardware operating parameters; For each of the aforementioned hardware operating parameters, determine whether the hardware operating parameter is within the corresponding operating range; If the hardware operating parameters are not within the corresponding operating range, then the hardware operating parameters are determined to be abnormal. If there are abnormal hardware operating parameters in the basic operating data, then the basic operating data is determined to trigger a data abnormality condition.

[0008] Optionally, the step of determining whether the basic operating data triggers a data anomaly condition includes: If the basic operating data triggers a data anomaly condition, the software function status corresponding to the basic operating data is determined. The software function status includes the general software status and the intelligent driving software status. Based on the general software status, determine whether the software function status is abnormal.

[0009] Optionally, the step of determining whether the vehicle has experienced a basic abnormality based on the basic operating data includes: If a basic abnormality occurs in the vehicle, the abnormality type of the basic abnormality is determined; Obtain the abnormal operation data corresponding to the abnormal type from the basic operation data; Generate an exception log containing the abnormal operation data, and upload the exception log to the server.

[0010] Optionally, acquiring the vehicle signal data for the current diagnostic cycle includes: Determine the exact moment when the vehicle anomaly was detected; Acquire the vehicle signal data generated within a preset time period before and after the abnormal moment.

[0011] To achieve the above objectives, the present invention also provides a vehicle diagnostic device, the vehicle diagnostic device comprising: The first acquisition module is used to acquire the vehicle's basic operating data if an abnormality is detected. The first judgment module is used to determine whether the vehicle has a basic abnormality based on the basic operating data. The first upload module is used to acquire the vehicle signal data for the current diagnostic cycle if no basic abnormality occurs in the vehicle, and upload the vehicle signal data to the server so that the server can perform abnormality diagnosis on the vehicle based on the vehicle signal data.

[0012] To achieve the above objectives, the present invention also provides a vehicle, the vehicle including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the vehicle diagnostic method as described above.

[0013] To achieve the above objectives, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the vehicle diagnostic method described above.

[0014] This invention proposes a vehicle diagnostic method, apparatus, vehicle, and computer-readable storage medium. If a vehicle anomaly is detected, basic vehicle operating data is acquired. Based on this basic operating data, it is determined whether a basic anomaly has occurred. If no basic anomaly has occurred, the vehicle signal data for the current diagnostic cycle is acquired and uploaded to a server, allowing the server to perform anomaly diagnosis based on this data. By performing anomaly judgment on the basic operating data at the vehicle end, most vehicle anomalies caused by abnormal basic data can be diagnosed locally, avoiding uploading all of this data to the server and reducing data transmission and server diagnostic load. When no anomalies are detected in the basic operating data, the vehicle signal data collected within the current diagnostic cycle is uploaded to the server for more accurate diagnosis, ensuring diagnostic accuracy. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the first embodiment of the vehicle diagnostic method of the present invention; Figure 2 This is a flowchart illustrating the overall system flow of the vehicle diagnostic method of the present invention. Figure 3 This is a flowchart of the first layer of diagnosis in the vehicle diagnosis method of the present invention; Figure 4 This is a flowchart of the second layer of diagnosis in the vehicle diagnosis method of the present invention; Figure 5 This is a schematic diagram of the system structure for the application of the vehicle diagnostic method of the present invention; Figure 6 This is a schematic diagram of the diagnostic hierarchy of the vehicle diagnostic method of the present invention; Figure 7 This is a flowchart of the third layer of diagnosis in the vehicle diagnosis method of the present invention; Figure 8 This is a schematic diagram of the modular structure of the vehicle of the present invention. Detailed Implementation

[0018] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0019] This invention provides a vehicle diagnostic method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the vehicle diagnostic method of the present invention, the method comprising the following steps: Step S10: If a vehicle abnormality is detected, obtain the vehicle's basic operating data; Vehicle anomaly indicates a deviation from the expected normal operating standard during vehicle operation; the type of vehicle anomaly can be set based on the actual scenario, such as hardware anomaly, software anomaly, intelligent driving function anomaly, or other anomalies.

[0020] The detection method for vehicle anomalies can be set based on actual scenarios; for example, if a function cannot be started, any alarm event occurs, or a function is abnormal; if the driver requests to activate the intelligent driving function through the lever, but the system prompts that the intelligent driving function has failed to activate or is unresponsive, then a vehicle anomaly is detected.

[0021] Basic operational data refers to the operational data that can be directly obtained through sensor collection or interface communication during vehicle operation.

[0022] The specific types of basic operating data can be set based on actual needs. For example, basic operating data includes sensor input signals, hardware status signals, etc. Sensor input signals are signals collected by various sensors on the vehicle, such as the signals collected by the steering wheel, wheel speed, camera, and radar sensors. Hardware status signals are signals that reflect the hardware status obtained through communication with specific hardware, such as fault status signals sent by chassis domain, sensors, and other hardware, the remaining capacity signal of the storage medium, and signals in system resources such as CPU (Central Processing Unit) utilization, context switching count, system memory utilization, ION (Input / Output Memory Manager) memory, CPU throttling, memory fragmentation, and interrupt frequency.

[0023] Step S20: Determine whether the vehicle has experienced a basic abnormality based on the basic operating data; Basic anomalies are anomalies in the underlying runtime data itself.

[0024] It is understandable that there are many possible reasons when a vehicle malfunctions. Taking intelligent driving as an example, when the basic operating data required for intelligent driving is abnormal, it will lead to an abnormality in intelligent driving; when the algorithm model of intelligent driving is abnormal, it will also lead to an abnormality in intelligent driving.

[0025] Anomalies in the basic operational data will be directly reflected in the basic operational data itself. Therefore, when a vehicle malfunction is caused by anomalies in the basic operational data, anomaly judgment can be made on the basic operational data first to determine whether the vehicle malfunction is caused by anomalies in the basic data, thereby initially eliminating a large number of anomalies caused by the basic operational data. When there are no anomalies in the algorithm model, vehicle diagnosis can be completed by checking for anomalies in the basic data. When there are anomalies in the algorithm model, it is also necessary to check whether there are anomalies in the basic data first. Therefore, in this embodiment, the basic anomaly judgment is made first.

[0026] The specific methods for judging basic anomalies can be set based on actual needs, such as setting up anomaly indicator detection, validity detection, and functional detection for basic operating data.

[0027] Step S30: If the vehicle does not exhibit any basic abnormalities, the vehicle signal data for the current diagnostic cycle is acquired and uploaded to the server so that the server can perform abnormality diagnosis on the vehicle based on the vehicle signal data.

[0028] If no basic anomaly is found in the vehicle, the anomaly is considered to be caused by a deeper reason, such as an anomaly in the intelligent driving algorithm model. Understandably, such anomalies are difficult to obtain directly from the operational data and usually require in-depth data analysis to determine the specific cause of the anomaly. However, the computing power of the vehicle is limited, and if this operation is set on the vehicle side, it will greatly increase the cost of the vehicle. Therefore, in this embodiment, when it is determined that no basic anomaly has occurred, the vehicle signal data is uploaded to the server so that the server can perform anomaly diagnosis on the vehicle based on the vehicle signal data.

[0029] Vehicle signal data refers to the relevant data generated by the vehicle during operation. The specific type of vehicle signal data can be set based on actual needs, or all recorded data generated during vehicle operation can be used as vehicle signal data.

[0030] It is understandable that when a vehicle anomaly is detected, the vehicle signal data will often be affected by the anomaly within a certain range at that moment. Therefore, in order to obtain the vehicle signal data related to the vehicle anomaly, this embodiment sets a current diagnostic cycle and uploads the vehicle signal data collected within the current diagnostic cycle as data related to the vehicle anomaly to the server. The specific range of the current diagnostic cycle can be set based on actual needs, such as taking the time before and after the time when the vehicle anomaly is detected as the benchmark, and taking a period of time before and after it, or before and after, as the current diagnostic cycle.

[0031] After receiving the vehicle signal data, the server performs anomaly diagnosis to determine the cause of the vehicle malfunction. The specific diagnostic method can be set according to actual needs. For example, an intelligent driving evaluation model can be deployed on the server to perform key signal analysis and feedback index evaluation on the uploaded vehicle signal data through the cloud evaluation model. Based on the model evaluation index before quantification, abnormal index items in the vehicle signal data can be identified, and then the abnormal index items can be presented to the developers for further analysis.

[0032] This embodiment performs anomaly detection on the basic operating data at the vehicle end, enabling most vehicle anomalies caused by abnormal basic data to be diagnosed locally, thereby avoiding uploading all of this data to the server and reducing data transmission and server diagnostic pressure. When no anomalies are detected in the basic operating data, the vehicle signal data collected in the current diagnostic cycle is uploaded to the server for more accurate diagnosis, thus ensuring diagnostic accuracy.

[0033] Further, see Figure 2 In the second embodiment of the vehicle diagnostic method of the present invention based on the first embodiment, step S20 includes the following steps: Step S21: Determine whether the basic operating data triggers a data anomaly condition; Step S22: If the basic operating data does not trigger a data anomaly condition, then determine the software function status corresponding to the basic operating data; Step S23: Determine whether the software function status is abnormal; Step S24: If the software function status is abnormal, it is determined that the vehicle has a basic abnormality.

[0034] Data anomaly conditions indicate data characteristics when there are anomalies in the underlying operational data itself.

[0035] Data anomaly conditions can be set for data types; it should be noted that data anomaly condition indicators can be determined directly from the characteristics obtained from the basic operating data; such as determining whether the basic operating data was received correctly, whether it is valid, and whether the value is normal.

[0036] Software functional status indicators are the state of a software process determined based on basic operational data; such as module operational stability, process resource consumption, critical link latency, and critical signal status.

[0037] It is understandable that the software function status depends on the basic operating data for determination, but it can be detected by determining the numerical and state of the basic operating data. Therefore, in this embodiment, the determination of the software function status is set at the vehicle end.

[0038] It is understandable that there is a supporting relationship between the judgment of anomalies in the basic operating data itself and the judgment of anomalies in the software functional state. That is, the normal operation of the basic operating data supports the software functional state, and when the basic operating data is abnormal, the related software functional state will often also be abnormal. After eliminating the anomaly of the basic operating data, the software functional state will return to normal in some cases. Therefore, the basic operating data has a higher judgment priority than the software functional state.

[0039] Therefore, in this embodiment, the basic operating data itself and the software functional state are set as two levels for anomaly diagnosis; the basic operating data is set as the first level, the software functional state as the second level, and anomalies caused by deeper reasons such as algorithm models are set as the third level. Anomalies are judged sequentially based on the hierarchical order: first, the anomaly diagnosis of the first level is executed. If the anomaly diagnosis result of the first level is that a data anomaly condition is triggered, then the basic operating data itself is considered abnormal, and no further anomaly diagnosis is performed on subsequent levels. If the anomaly diagnosis result of the first level is that no data anomaly condition is triggered, then the anomaly diagnosis of the second level is executed. If the anomaly diagnosis result of the second level is that a software functional state anomaly occurs, then no further anomaly diagnosis is performed on subsequent levels. If the anomaly diagnosis result of the second level is that no software functional state anomaly occurs, then the anomaly diagnosis of the third level is executed, i.e., the vehicle signal data is uploaded to the server for diagnosis. This achieves a bottom-up root cause diagnosis path. When a vehicle malfunctions, the fault location is investigated sequentially in three levels to determine the true root cause level of the fault, thereby avoiding erroneous analysis paths that explore low-level physical problems in high-level logic.

[0040] Further, see Figure 3 Step S21 includes the following steps: Step S211: Obtain sub-data from the basic operating data; Step S212: For each of the sub-data, determine the current publication period of the sub-data, wherein the current publication period indicates the time interval between the last publication time of the sub-data; Step S213: Determine whether the current release cycle is greater than the preset cycle threshold of the sub-data; Step S214: If the current release cycle is greater than the preset cycle threshold of the sub-data, then the sub-data is determined to be abnormal; Step S215: If there is abnormal sub-data in the basic operating data, then the basic operating data is determined to trigger a data abnormality condition.

[0041] Sub-data is independent data within the basic runtime data, such as CPU utilization, context switch count, system memory utilization, ION memory, CPU throttling, memory fragmentation, interrupt frequency, etc., which can each be treated as a separate sub-data.

[0042] The current release cycle is the time interval between the last release of sub-data. It can be understood that, for basic operational data, there is a corresponding data release cycle set based on the specific type of data. For example, for the detection signal input by the sensor, the signal is released based on the sampling cycle. When the signal is not released for a long time, it is considered that there may be an abnormality in the corresponding hardware. Therefore, in this embodiment, a preset cycle threshold is set to characterize the abnormal features at the release cycle level.

[0043] It should be noted that different types of sub-data require different release periods. Therefore, a corresponding preset period threshold value can be set for different sub-data. For example, for sub-data such as sensor input signals, which have high real-time requirements, the required release frequency is high. Therefore, the corresponding preset period threshold can be set to a smaller value. On the other hand, for sub-data such as in-vehicle lighting status, which have lower real-time requirements, the required release frequency is low. Therefore, the corresponding preset period threshold can be set to a larger value.

[0044] When the current publication cycle of sub-data exceeds the corresponding preset cycle threshold, the time interval between the last publication of sub-data is considered to exceed the allowed length, and therefore, the sub-data is considered abnormal.

[0045] When setting the preset period threshold, it can be combined with the preset release period of the sub-data. The preset release period is the default release period of the sub-data. In order to avoid errors caused by occasional events, the preset period threshold can be set to be larger than the preset release period, such as 150% of the preset release period, to avoid misjudgment caused by accidental factors.

[0046] If there are abnormal sub-data in the basic operating data, the basic operating data is considered to be abnormal, triggering the data abnormality condition.

[0047] Further, step S21 includes the following steps: Step S216: Obtain sub-data from the basic operating data, wherein the sub-data includes hardware operating parameters; Step S217: For each of the hardware operating parameters, determine whether the hardware operating parameter is within the corresponding operating range; Step S218: If the hardware operating parameters are not within the corresponding operating range, then the hardware operating parameters are determined to be abnormal. Step S219: If there are abnormal hardware operating parameters in the basic operating data, then the basic operating data is determined to trigger an abnormal data condition.

[0048] Hardware operating parameters are parameters that reflect the operating status of the hardware, such as CPU utilization, context switch count, system memory utilization, ION memory, CPU throttling, memory fragmentation, and interrupt frequency.

[0049] The operating range refers to the range within which the hardware operating parameters are under normal conditions; the operating range corresponding to different types of hardware operating parameters can be set based on the actual scenario; for example: When CPU utilization is too high, such as when it is close to full load, it may cause problems such as data loss and excessive link latency. Therefore, the corresponding operating range can be set to <90%.

[0050] Excessive context switching indicates that threads are frequently yielding or being preempted from the CPU. Therefore, the corresponding running range can be set to <5000.

[0051] When system memory usage is too high, it can lead to insufficient available memory. Therefore, the corresponding operating range can be set to <85%.

[0052] When ION memory usage is too high, it will lead to insufficient available memory for ION. Therefore, the corresponding operating range can be set to <90%.

[0053] When the CPU frequency is reduced to too low, it may cause problems such as overheating or undervoltage. Therefore, the corresponding operating range can be set to > the maximum frequency reduction value.

[0054] When memory fragmentation consistently reaches a High Order value of 0, it indicates that the system is unable to allocate large, contiguous blocks of physical memory. Therefore, the corresponding operating range can be set to >0. It should be noted that, to avoid accidental occurrences, a sustained High Order duration can be set for memory fragmentation. If a High Order value of 0 is consistently detected within the sustained High Order duration, then the memory fragmentation is considered abnormal.

[0055] If the interrupt frequency increases rapidly, such as exceeding 50% of the stable value or continuing to rise, there may be an interrupt storm or hardware anomaly. Therefore, the corresponding operating range can be set to >50% of the stable value.

[0056] The above hardware operating parameters and corresponding operating ranges are for illustrative purposes only. In practical applications, the corresponding operating ranges can be set based on the characteristics of the hardware operating parameters in the actual application.

[0057] When the hardware operating parameters are within the corresponding operating range, the hardware operating parameters of that type are considered normal.

[0058] If the hardware operating parameters are not within the corresponding operating range, then the hardware operating parameters of this type are determined to be abnormal. If there are abnormal sub-data in the hardware operating parameters, the basic operating data is considered to be abnormal, triggering a data abnormality condition.

[0059] In other embodiments, other methods can be combined to diagnose anomalies in the basic operating data. For example, for each sub-data, the checksum can be parsed and extracted, and the validity of the sub-data can be determined based on the value of the valid field in the sub-data. If the sub-data is invalid, it is considered to be abnormal.

[0060] Another example is checking the hardware status to diagnose anomalies in basic operating data: reading system fault status signals issued by hardware such as chassis domain and sensors, and finding no abnormalities (such as no overheating or undervoltage signals).

[0061] Another example is checking storage space to diagnose anomalies in basic operating data: monitoring the remaining capacity of each partition, all of which are greater than 5%, with no warnings.

[0062] Another example is checking input signals to diagnose anomalies in basic operating data: diagnostic software verifies the integrity, release cycle, and validity (valid bit) of key input signals from the steering wheel, wheel speed, camera, radar, etc.

[0063] Further, see Figure 4 The step following step S21 includes: Step S25: If the basic operating data triggers a data anomaly condition, determine the software function status corresponding to the basic operating data. The software function status includes the general software status and the intelligent driving software status. Step S26: Determine whether the software function status is abnormal based on the general software status.

[0064] General software status refers to the status of a vehicle's normal functions, such as the running status of processes, the allocation status of resources, and the time synchronization status.

[0065] The status of the intelligent driving software includes the status of the perception modules related to intelligent driving and the status of subsequent functional links.

[0066] Understandably, the general software status is used to reflect the normal function of the vehicle. Therefore, although the general software status needs to be obtained by analyzing basic operating data, it still represents the basic state of the vehicle. Thus, when the basic operating data triggers abnormal conditions, it is also necessary to perform anomaly diagnosis.

[0067] The status of intelligent driving software depends on the normality of basic operating data. Therefore, when the basic operating data triggers abnormal conditions, the status of intelligent driving software may be due to the abnormality of the basic operating data. In this case, there is no need to diagnose the status of intelligent driving software, thereby improving diagnostic efficiency and avoiding ineffective diagnosis.

[0068] Furthermore, in the third embodiment of the vehicle diagnostic method of the present invention based on the first embodiment of the present invention, the step S20 is followed by the following step: Step S40: If the vehicle exhibits a basic abnormality, determine the type of the basic abnormality. Step S50: Obtain the abnormal operation data corresponding to the abnormal type from the basic operation data; Step S60: Generate an exception log containing the abnormal operation data and upload the exception log to the server.

[0069] If a vehicle exhibits a basic abnormality, there is no need to perform further diagnosis at subsequent levels.

[0070] The exception type is the type of the basic exception; for example, if the CPU utilization is >90%, then a basic exception is confirmed, and the corresponding exception type is CPU utilization too high.

[0071] Abnormal operation data refers to data related to the abnormal type in the basic operation data, such as CPU utilization > 90%. Data related to CPU utilization in the basic operation data is used as abnormal operation data. The specific content can be set based on the characteristics of the actual data, such as including data name, actual value, data source, etc.

[0072] It should be noted that when a basic exception corresponds to multiple different exception types, the exception runtime data includes relevant data for all exception types.

[0073] After obtaining the abnormal operation data, an abnormal log containing the abnormal operation data is generated and packaged and uploaded to the server. The abnormal log contains relevant information about this vehicle abnormality, such as timestamp, abnormal operation data, trigger status, etc.

[0074] After receiving the packaged data, the server parses it and transfers the resulting abnormal operation data to the development team's visual server workbench, triggering a notification.

[0075] Developers can directly see the reported abnormal operation data in the visual interface and view the hardware logs associated with the abnormal operation data to quickly locate the abnormal problem without having to start a lengthy investigation from the functional level.

[0076] Furthermore, in the fourth embodiment of the vehicle diagnostic method of the present invention based on the first embodiment of the present invention, step S30 includes the following steps: Step S31: Determine the time when the vehicle abnormality was detected; Step S32: Obtain the vehicle signal data generated within a preset time period before and after the abnormal moment.

[0077] The abnormal moment is the moment when a vehicle abnormality is detected.

[0078] It is understandable that when a vehicle anomaly is detected, the vehicle signal data before and after the anomaly will change due to the cause of the anomaly. Therefore, in order to capture more accurate vehicle signal data that reflects the anomaly, in this embodiment, the time of the anomaly is used as a reference point, and the vehicle signal data generated before and after the anomaly within a preset time period is uploaded to the server.

[0079] The specific value of the preset duration can be set according to actual needs, such as 30 seconds. In this case, the vehicle signal data generated within 60 seconds, 30 seconds before and 30 seconds after the abnormal moment, will be uploaded to the server.

[0080] The overall principle of this application is explained below: See Figure 5 The system architecture of this application includes vehicle-side and cloud-side, with the cloud-side and vehicle-side in a one-to-many form, meaning that the cloud-side can establish communication with multiple vehicle-side and perform anomaly diagnosis for multiple vehicle-side.

[0081] The vehicle-side components include a smart driving domain controller, communication equipment, and storage media.

[0082] The intelligent driving domain controller runs abnormal data diagnostic software. By receiving signals from various application software such as chassis, sensors, intelligent driving, and model output, it analyzes and reports the abnormalities when it detects abnormalities in the intelligent driving function.

[0083] The communication equipment is used to communicate with the cloud, transmit domain controller diagnostic output results, and abnormal data and logs in the storage medium.

[0084] The storage medium is used to store the vehicle signal data and logs within 30 seconds of the time the vehicle reported the anomaly as a backup. The vehicle signal data is usually stored in .dat format and the data is retained for 7 days. The cloud includes intelligent driving model evaluation servers, visualization servers, storage media, and defect databases.

[0085] The intelligent driving model evaluation server is equipped with an intelligent driving evaluation model, which is used to evaluate abnormal datasets uploaded by the vehicle and calculate various indicators of the model processing to generate evaluation reports.

[0086] The visualization server is mainly used to display abnormal data and data diagnostic results uploaded by the vehicle, providing developers with the opportunity to trace back and analyze abnormal data.

[0087] The storage medium is used to store logs and data uploaded from the vehicle.

[0088] The defect database is used to store historically reported diagnostic results and vehicle-side symptoms, as well as defect items in the evaluation model output. It combines these with the analysis results of developers to form abnormal data entries and archives and statistically analyzes similar issues.

[0089] The principles of vehicle diagnostic methods include: The three-layer fault model designed based on the end-to-end intelligent driving system architecture and data flow adopts a progressive, layer-by-layer structure where lower layers support upper layers. This model extracts fault analysis from the superficial manifestations of functional anomalies and transforms them into a bottom-up root cause diagnostic path. When a functional anomaly occurs in the system, fault localization is sequentially investigated in three layers to determine the true root cause level of the fault, thereby avoiding erroneous analytical paths that seek low-level physical problems in high-level logic.

[0090] See Figure 6 The system includes a diagnostic hierarchy table. The first layer is the basic data layer, which diagnoses the fundamental input signals upon which the intelligent driving function depends for normal operation. This primarily includes diagnosing input signals from the intelligent driving domain controller, sensors, and the vehicle itself. The second layer is the logic processing layer, which addresses the software function status. This layer builds upon the stable operating environment provided by the first layer and involves the logical processing of basic data and troubleshooting faults arising during system collaboration. It primarily diagnoses faults caused by software defects. The third layer is the functional expression layer, which addresses deeper causes. Relying on the normal operation of the first and second layers, it achieves the final functional output of the algorithm model. This layer mainly analyzes the causes of unexpected behaviors during autonomous driving.

[0091] Diagnostic hierarchy table

[0092] The diagnostics for the basic data layer and the logic processing layer are implemented using a loadable dynamic library, which is loaded by the intelligent driving domain controller and runs continuously during the power-on cycle of the domain controller.

[0093] The data collection part of the functional expression layer is deployed on the vehicle, while the data analysis is deployed on the intelligent driving model evaluation server in the cloud.

[0094] When an anomaly occurs, the fault phenomenon is classified according to the fault model. The basic data layer and the logical processing layer search for the corresponding logs based on the fault cause and fault module, and report the fault in combination with the diagnostic fields. The data volume is controlled to be less than or equal to 20Mbit. Faults in the functional expression layer are only diagnosed under the condition that the basic data layer and the logic processing layer are normal. Since the analysis of functional expression anomalies often requires relatively complex analysis methods such as refeed evaluation or output signal numerical analysis, the vehicle end often does not have enough resources to deploy them. Therefore, when an anomaly occurs in this layer, the complete signal data of the 30 seconds around the time of the anomaly is packaged and uploaded. The data volume is usually no more than 3Gbit, and it is used for cloud-based anomaly assessment.

[0095] The basic data layer primarily diagnoses input signals, the system load of the domain controller, and the normality of the hardware. When a fault signal occurs in the basic data layer, the faulty module is located based on the fault signal, the abnormal module signals are compiled, and the corresponding module logs are packaged and uploaded.

[0096] The diagnostics of the intelligent driving domain controller hardware already have relatively detailed signals at the system OS and other underlying layers. In this invention, the diagnostics of the hardware system mainly involve receiving and reporting the system fault status published by the bottom software, and additionally monitoring whether there are any abnormalities in the remaining space of each partition and storage medium. If the remaining capacity is less than 5%, the corresponding partition space is reported as insufficient.

[0097] Input signal diagnosis, or anomaly diagnosis of basic operational data, is the core diagnostic mechanism of the intelligent driving system's basic data layer. It aims to ensure the reliability, integrity, and rationality of all basic signal sources upon which the intelligent driving function depends for normal operation. Input signal diagnosis includes: 1. Verify the release cycle of the input signal. Based on the system design scheme, set an alarm threshold of 50% based on the preset release cycle of the signal release, i.e., the preset cycle threshold. When the threshold is exceeded, trigger signal diagnosis and package the signal name, data source, and abnormal cycle as text and report it to the server. 2. Parse and extract the checksum from the data, and determine whether the current data is valid based on the value of fields such as "valid". If invalid data is found, package the signal name, field name, and field value as a text file and report it to the server.

[0098] 3. Resource monitoring is a prerequisite for ensuring the normal operation of application software. By verifying the diagnostic signals in the load diagnostic signal table, and after the alarm conditions are met, the diagnostic signals and actual values ​​are packaged into a text file and reported to the server.

[0099] Load diagnostic signal table

[0100] The logic processing layer diagnoses whether the software deployed in the intelligent driving domain controller is running stably and whether the software's functional logic is expressed correctly, including the following points: The module performs stability diagnostics, monitors the process PID (Process Identifier), and when a process hangs, packages the corresponding process's crash log text information and reports the name of the crashed module.

[0101] Process resource consumption diagnosis monitors the CPU and memory usage of each module through system logs. Based on the resource usage index values, when a process exceeds the resource index value by 20% or memory usage shows a continuous increase without stabilizing, a resource alarm diagnosis is triggered, and the process name, resource exceeding the index, and resource value are packaged into a text file and uploaded.

[0102] Critical link latency diagnosis involves obtaining the link latency from the sensing-control signal in the logs, verifying it against the link latency index, checking for link anomalies, and using a 30% threshold as the alarm threshold. When the link latency exceeds the index by 30%, the latency signal quantity, input source, response module, and latency value are packaged into a text file, and the module logs of the latency anomaly are also packaged and uploaded.

[0103] For critical signal diagnosis, each module of the intelligent driving application will publish its corresponding diagnostic signals. The diagnostic signals of each module are parsed according to the data protocol to find the cause of the anomaly. When an abnormal signal is obtained, the module name, diagnostic signal, and diagnostic fields are packaged into a text file and the logs of the corresponding module are retrieved and uploaded. At the same time, the model output results and the release cycle of the control signals issued to control the vehicle in the intelligent driving vehicle control link are diagnosed. When the value exceeds the design threshold by 30%, data reporting is triggered. The signal quantity, timeout time, and signal source module name fields are packaged into a text file and the logs of the corresponding module are retrieved and reported.

[0104] Time synchronization signal diagnosis retrieves the current status of the time synchronization server from the logs, obtains synchronization diagnostic signals for devices such as LiDAR, positioning equipment, and cockpit, and confirms whether the relevant devices are stably online. At the same time, it verifies the timestamp field of the input signal received by the corresponding module on the application side. Based on the signal release frequency and different acquisition links, it uses the high-frequency chassis signal or positioning signal as the benchmark to verify the difference between other signals and the high-frequency signal. When the difference exceeds the threshold, it packages the signal source module name, signal name, and the difference with the specified high-frequency signal into a text file and uploads the time synchronization and related abnormal module logs.

[0105] The functional expression layer is based on the driver's active takeover or active triggering of abnormal data recording signals under the stable and normal operation of the software and system. When the functional expression is abnormal, it is not possible to obtain specific fault information directly through logs and data. Therefore, the fault diagnosis of the functional expression layer is deployed in the cloud model evaluation server. Abnormal indicators are determined through key signal analysis, refeed index evaluation, and model evaluation indicators before quantification, and presented to the developers for further analysis.

[0106] The diagnostic system data stream proposed in this invention is as follows: Figure 8-Figure 8As shown, when the intelligent driving function malfunctions, this diagnostic system is triggered. First, it verifies the basic data layer and logic processing layer on the vehicle side to determine if the problem is caused by input anomalies or software logic defects. For such issues, the system automatically locates the faulty module and uploads the corresponding module's logs, which are then routed to the cloud for analysis by developers in various fields. This replaces the traditional, complex process of reporting all faults and starting analysis from the problem's symptoms, while also reducing useless data transmission. After ruling out input factors and software logic defects, intelligent driving function anomalies usually cannot be determined through logs or analysis of a few data fields. Complete data is generally required for element reconstruction and evaluation of various indicators to locate the anomaly. Therefore, the vehicle side does not process the data; instead, the data is transmitted completely to the cloud for analysis. Finally, all problems are archived in a defect database for recording and training defect analysis models.

[0107] Specific execution process: Following the core principles of layered diagnosis, hierarchical reporting, vehicle-cloud collaboration, and closed-loop optimization, its implementation process is a complete closed loop from vehicle-side anomaly triggering to in-depth cloud analysis, ultimately leading to knowledge accumulation. The following example, "the vehicle cannot activate intelligent driving functions after the driver pulls the lever," details the implementation method of this invention: 1. Anomaly triggering and vehicle-side layered diagnosis; The driver requests activation of the intelligent driving function by using the lever, but the system indicates activation failure or no response. At this point, the abnormal data diagnostic software in the vehicle domain controller is triggered and begins bottom-up diagnosis according to the three-layer fault model.

[0108] Basic data layer diagnostics: Check hardware status: Read system fault status signals issued by hardware such as chassis domain and sensors. No abnormalities were found (e.g., no overheating or undervoltage signals).

[0109] Check storage space: Monitor the remaining capacity of each partition, all are greater than 5%, no warnings.

[0110] Check input signals: The diagnostic software verifies the integrity, release cycle, and validity (valid bit) of key input signals from the steering wheel, wheel speed, camera, radar, etc.

[0111] Suppose that in this step, the diagnostics find that the valid bit of the "forward camera" signal remains 'invalid' and the signal is lost for more than 2 release cycles.

[0112] Logical processing layer diagnosis: When a fault is received from the basic data layer and the fault is a camera fault, the logical processing layer will no longer verify the perception module and subsequent intelligent driving links. It will only check whether there are abnormal process crashes, resource overruns, and whether the time synchronization system is abnormal. If no abnormalities are found, no additional processing will be performed.

[0113] 2. Reporting of tiered data; According to the fault model rules, faults in the basic data layer and logical processing layer only require reporting a small number of diagnostic fields and related logs.

[0114] The vehicle-side diagnostic system performs the following actions: Fault location module: Based on invalid signals, locate the fault source as the "forward-facing camera" or its data transmission link.

[0115] Packaging and reporting data: The fault information (signal name: Front_Cam_Valid, value: 0, data source: Camera_ECU) and the most recent log fragment of the camera module extracted from the system log are packaged into a data packet and reported to the cloud system through the communication device.

[0116] 3. Cloud-based reception and task flow The cloud storage medium receives and stores the data packet.

[0117] The cloud system parses the data packet and, based on the tag "Faulty Module: Camera", automatically transfers the diagnostic task to the visualization server workbench of the "Perception Hardware" or "Sensor Integration" development team and triggers a notification.

[0118] 4. Cloud-based analytics and problem-solving loop The relevant developers can directly see the reported text message in the visualization interface: "Basic data layer failure - ineffective forward camera signal", and can also view the logs of the associated camera module.

[0119] Developers quickly pinpointed the problem based on the logs: it could be a momentary power outage to the camera, a loose data interface, or a malfunction in the camera's internal software. This eliminated the need for lengthy troubleshooting starting from the functional level.

[0120] Developers input the analysis findings and solutions into the defect database, creating a searchable diagnostic entry.

[0121] 5. See Figure 7 If all diagnostic items in the basic data layer and logic processing layer are normal, and manual takeover or manual triggering of the record occurs, the system will determine that the problem may be located in the functional expression layer.

[0122] At this point, the vehicle will not perform in-depth analysis, but will directly upload all the complete raw data from 30 seconds before and after the abnormal moment to the cloud. The cloud-based intelligent driving model evaluation server will then perform feedback evaluation on the uploaded data and output various performance indicators, such as object detection confidence and trajectory planning rationality score.

[0123] Developers analyze evaluation reports and visualization tools to identify problems that arise in the model itself or during the engineering process, and then implement targeted optimization measures.

[0124] The analysis results of this case were also recorded in the defect database for use in training defect analysis models or guiding test case enhancement.

[0125] This implementation method transforms the traditional long chain of "phenomenon-manual step-by-step troubleshooting" into a short chain of "system hierarchical screening-automatic precise decomposition" through a standardized three-layer fault model.

[0126] Efficiency Improvement: Over 95% of basic and logic layer issues are quickly located at the vehicle level and only a small amount of data is reported, effectively improving issue processing efficiency. This avoids excessively long explanation times caused by uploading all data.

[0127] Analysis Focus: For issues that can be identified in a specific professional field, they can be directly transferred to developers in the relevant domain. For more complex functional expression layer issues, a preliminary indicator is first obtained through model evaluation before developers conduct further analysis, thereby achieving optimized allocation of diagnostic resources and rapid closure of the root cause of the problem.

[0128] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0129] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0130] This application also provides a vehicle diagnostic device for implementing the above-described vehicle diagnostic method, wherein vehicle diagnostics include: The first acquisition module is used to acquire the vehicle's basic operating data if an abnormality is detected. The first judgment module is used to determine whether the vehicle has a basic abnormality based on the basic operating data. The first upload module is used to acquire the vehicle signal data for the current diagnostic cycle if no basic abnormality occurs in the vehicle, and upload the vehicle signal data to the server so that the server can perform abnormality diagnosis on the vehicle based on the vehicle signal data.

[0131] This vehicle diagnostic device performs anomaly detection on the vehicle's basic operating data. This allows for local diagnosis of most vehicle anomalies caused by abnormal basic data, avoiding the need to upload all of this data to the server and reducing data transmission and server diagnostic load. When no anomalies are detected in the basic operating data, the device uploads the vehicle signal data collected during the current diagnostic cycle to the server for more accurate diagnosis, thus ensuring diagnostic accuracy.

[0132] It should be noted that the first acquisition module in this embodiment can be used to execute step S10 in this application embodiment, the first judgment module in this embodiment can be used to execute step S20 in this application embodiment, and the first upload module in this embodiment can be used to execute step S30 in this application embodiment.

[0133] Furthermore, the first determination module includes: The first judgment unit is used to determine whether the basic operating data triggers a data anomaly condition; The first determining unit is used to determine the software function status corresponding to the basic operating data if the basic operating data does not trigger a data anomaly condition. The second judgment unit is used to determine whether the software function status is abnormal. The second determining unit is used to determine that the vehicle has a basic abnormality if the software function status is abnormal.

[0134] Furthermore, the first determination unit includes: The first acquisition subunit is used to acquire sub-data from the basic operating data; The first determining subunit is configured to determine the current publication period of each of the sub-data, wherein the current publication period indicates the time interval between the last publication of the sub-data; The first judgment subunit is used to determine whether the current release cycle is greater than the preset cycle threshold of the sub-data; The second determining subunit is used to determine that the sub-data is abnormal if the current release cycle is greater than a preset cycle threshold of the sub-data. The third determining subunit is used to determine if there is abnormal sub-data in the basic operating data, and then determine that the basic operating data triggers a data abnormality condition.

[0135] Furthermore, the first determination unit includes: The second acquisition subunit is used to acquire sub-data from the basic operating data, wherein the sub-data includes hardware operating parameters; The second judgment subunit is used to determine whether each hardware operating parameter is within the corresponding operating range. The fourth determining subunit is used to determine that the hardware operating parameters are abnormal if the hardware operating parameters are not within the corresponding operating range. The fifth determining subunit is used to determine the basic operating data triggering data anomaly conditions if there are abnormal hardware operating parameters in the basic operating data.

[0136] Furthermore, the first determination module also includes: The third determining unit is used to determine whether the basic operating data triggers a data anomaly condition. If the basic operating data triggers a data anomaly condition, it determines the software function state corresponding to the basic operating data. The software function state includes the general software state and the intelligent driving software state. The fourth determining unit is used to determine whether the software functional state is abnormal based on the general software state.

[0137] Further, the device includes: The first determining module is used to determine whether the vehicle has a basic abnormality based on the basic operating data, and if the vehicle has a basic abnormality, then determine the abnormality type of the basic abnormality. The second acquisition module is used to acquire abnormal operation data corresponding to the abnormal type from the basic operation data; The first generation module is used to generate an exception log containing the abnormal operation data and upload the exception log to the server.

[0138] Furthermore, the first upload module includes: The first acquisition unit is used to determine the abnormal moment when the vehicle abnormality was detected; The first uploading unit is used to acquire the vehicle signal data generated within a preset time period before and after the abnormal moment.

[0139] Reference Figure 8In terms of hardware structure, the vehicle may include components such as a communication module 10, a memory 20, and a processor 30. In the vehicle, the processor 30 is connected to both the memory 20 and the communication module 10. The memory 20 stores a computer program, which is executed by the processor 30. When the computer program is executed, it implements the steps of the above-described method embodiments.

[0140] The communication module 10 can connect to external communication devices via a network. The communication module 10 can receive requests from the external communication devices and can also send requests, instructions, and information to the external communication devices, which can be other vehicles, servers, or IoT devices, such as televisions, etc.

[0141] The memory 20 can be used to store software programs and various data. The memory 20 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as determining whether a basic vehicle malfunction has occurred based on the basic operating data), etc.; the data storage area may include a database, and may store data or information created based on system usage. Furthermore, the memory 20 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0142] The processor 30 is the control center of the vehicle. It connects to various parts of the vehicle via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 20, and by calling data stored in the memory 20, it performs various vehicle functions and processes data, thereby providing overall vehicle monitoring. The processor 30 may include one or more processing units; optionally, the processor 30 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 30.

[0143] although Figure 8 Not shown, but the vehicle described above may also include a circuit control module for connecting to a power source to ensure the normal operation of other components. Those skilled in the art will understand that... Figure 8 The vehicle structure shown does not constitute a limitation on the vehicle and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0144] The present invention also proposes a computer-readable storage medium having a computer program stored thereon. The computer-readable storage medium may be... Figure 8The memory 20 in the vehicle may be at least one of ROM (Read-Only Memory) / RAM (Random Access Memory), magnetic disk, optical disk, etc. The computer-readable storage medium includes a number of instructions to cause a terminal device with a processor (which may be a television, automobile, mobile phone, computer, server, terminal, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0145] In this invention, the terms "first," "second," "third," "fourth," and "fifth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0146] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0147] Although embodiments of the present invention have been shown and described above, the scope of protection of the present invention is not limited thereto. It is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, and substitutions to the above embodiments within the scope of the present invention, and such changes, modifications, and substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A vehicle diagnostic method, characterized in that, The vehicle diagnostic method includes: If a vehicle anomaly is detected, the vehicle's basic operating data is obtained; Based on the aforementioned basic operational data, determine whether the vehicle has experienced any basic abnormalities; If no basic abnormality is found in the vehicle, the vehicle signal data for the current diagnostic cycle is acquired and uploaded to the server so that the server can perform abnormality diagnosis on the vehicle based on the vehicle signal data.

2. The vehicle diagnostic method as described in claim 1, characterized in that, The determination of whether a vehicle has a basic abnormality based on the basic operating data includes: Determine whether the basic operational data triggers a data anomaly condition; If the basic operating data does not trigger a data anomaly condition, then the software function status corresponding to the basic operating data is determined; Determine whether the software function status is abnormal; If the software function is abnormal, then the vehicle is determined to have a basic abnormality.

3. The vehicle diagnostic method as described in claim 2, characterized in that, The determination of whether the basic operational data triggers a data anomaly condition includes: Obtain sub-data from the basic operational data; For each of the sub-data, the current publication period of the sub-data is determined, wherein the current publication period indicates the time interval since the last publication of the sub-data; Determine whether the current release cycle is greater than the preset cycle threshold of the sub-data; If the current release cycle is greater than the preset cycle threshold of the sub-data, then the sub-data is determined to be abnormal; If there are abnormal sub-data in the basic operating data, then the basic operating data is determined to trigger a data abnormality condition.

4. The vehicle diagnostic method as described in claim 2, characterized in that, The determination of whether the basic operational data triggers a data anomaly condition includes: Obtain sub-data from the basic operating data, wherein the sub-data includes hardware operating parameters; For each of the aforementioned hardware operating parameters, determine whether the hardware operating parameter is within the corresponding operating range; If the hardware operating parameters are not within the corresponding operating range, then the hardware operating parameters are determined to be abnormal. If there are abnormal hardware operating parameters in the basic operating data, then the basic operating data is determined to trigger a data abnormality condition.

5. The vehicle diagnostic method as described in claim 2, characterized in that, The step of determining whether the basic operational data triggers a data anomaly condition includes: If the basic operating data triggers a data anomaly condition, the software function status corresponding to the basic operating data is determined. The software function status includes the general software status and the intelligent driving software status. Based on the general software status, determine whether the software function status is abnormal.

6. The vehicle diagnostic method as described in claim 1, characterized in that, The step of determining whether a vehicle has experienced a basic abnormality based on the aforementioned basic operational data includes: If a basic abnormality occurs in the vehicle, the abnormality type of the basic abnormality is determined; Obtain the abnormal operation data corresponding to the abnormal type from the basic operation data; Generate an exception log containing the abnormal operation data, and upload the exception log to the server.

7. The vehicle diagnostic method as described in claim 1, characterized in that, The acquisition of vehicle signal data for the current diagnostic cycle includes: Determine the exact moment when the vehicle anomaly was detected; Acquire the vehicle signal data generated within a preset time period before and after the abnormal moment.

8. A vehicle diagnostic device, characterized in that, The vehicle diagnostic device includes: The first acquisition module is used to acquire the vehicle's basic operating data if an abnormality is detected. The first judgment module is used to determine whether the vehicle has a basic abnormality based on the basic operating data. The first upload module is used to acquire the vehicle signal data for the current diagnostic cycle if no basic abnormality occurs in the vehicle, and upload the vehicle signal data to the server so that the server can perform abnormality diagnosis on the vehicle based on the vehicle signal data.

9. A vehicle, characterized in that, The vehicle includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the vehicle diagnostic method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the vehicle diagnostic method as described in any one of claims 1 to 7.

Images