Fault detection method and device, vehicle, storage medium and program product

Abstract

The invention discloses a fault detection method and device, a vehicle, a storage medium and a program product, and the method comprises the steps: carrying out the feature extraction of vehicle abnormal information of a target vehicle, and obtaining abnormal feature data; and performing test program matching based on a preset test program library, and determining a fault test program. And performing fault test on the target vehicle through the fault test program, and collecting fault test data. And performing fault analysis on the fault test data to obtain a fault detection result. Through the technical scheme provided by the invention, the data mining depth and accuracy during fault detection are effectively improved, a complex and difficult-to-reproduce vehicle fault problem source is efficiently and accurately positioned, the detection precision for the vehicle fault problem is effectively improved, the whole processing process is highly automatic, and the efficiency is high. The fault detection efficiency and the fault problem repair rate are remarkably improved, and the actual user experience is optimized to the maximum extent.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of fault diagnosis, and particularly relates to a fault detection method and device, a vehicle, a storage medium and a program product. BACKGROUND

[0002] With the rapid development of automobile intelligence and networking, the hardware structure of vehicles and the vehicle-mounted software system are increasingly complex, and it is important to achieve accurate and effective fault detection to ensure driving safety, vehicle function reliability and user experience.

[0003] At present, traditional vehicle fault detection mainly relies on extracting and analyzing relevant log files. However, this detection method has obvious limitations in practical application. First, the fault problem positioning is unclear, which seriously affects the detection accuracy and makes it difficult to accurately locate the fault source, making it difficult to carry out repair work. In addition, if full-quantity log analysis is enabled to improve detection accuracy, it will greatly occupy vehicle computing resources and network bandwidth, seriously affecting the normal operation of other vehicle functions and reducing user experience. This method has problems in detection accuracy, and also seriously affects detection efficiency due to reliance on manual export of logs and subsequent analysis and processing, which forces the fault detection and repair cycle to be lengthened, affecting normal use of the vehicle by users.

[0004] Therefore, how to perform more efficient and accurate fault detection on vehicles is an important problem to be solved at present. SUMMARY

[0005] The embodiments of the present application provide a fault detection method, device, vehicle, storage medium and program product, which can improve the detection accuracy and efficiency of vehicle fault problems.

[0006] In a first aspect, the embodiments of the present application provide a fault detection method, comprising: In response to vehicle abnormal information sent by a target vehicle or a user, performing feature extraction on the vehicle abnormal information to determine abnormal feature data of the target vehicle; Based on the abnormal feature data and a preset test program library, performing test program matching to determine a fault test program of the target vehicle; Transmitting the fault test program to the target vehicle, and performing a fault test corresponding to the vehicle abnormal information on the target vehicle through the fault test program to collect fault test data; Performing fault analysis on the fault test data to determine a fault detection result of the target vehicle.

[0007] In a second aspect, the embodiments of the present application provide a fault detection device, comprising: The feature extraction module is configured to perform feature extraction on the vehicle abnormal information in response to the vehicle abnormal information sent by the target vehicle or the user, and determine abnormal feature data of the target vehicle. The program matching module is configured to perform test program matching based on the abnormal feature data and a preset test program library, and determine a fault test program of the target vehicle. The fault test module is configured to transmit the fault test program to the target vehicle, and perform fault test on the target vehicle corresponding to the vehicle abnormal information through the fault test program, and collect fault test data. The fault detection module is configured to perform fault analysis on the fault test data, and determine a fault detection result of the target vehicle.

[0008] In a third aspect, an embodiment of the present application provides a vehicle, which comprises a processor and a memory storing computer program instructions. The processor executes the computer program instructions to implement the fault detection method of the first aspect.

[0009] In a fourth aspect, an embodiment of the present application provides a computer storage medium, which stores computer program instructions. When the computer program instructions are executed by a processor, the fault detection method of the first aspect is implemented.

[0010] In a fifth aspect, an embodiment of the present application provides a computer program product. When instructions in the computer program product are executed by a processor of an electronic device, the electronic device performs the fault detection method of the first aspect.

[0011] The technical scheme provided by the embodiment of the present application at least brings the following beneficial effects: The fault detection method provided by the embodiment of the present application comprises the following steps: first, the vehicle abnormal information sent by the target vehicle or the user is extracted to obtain abnormal feature data representing the abnormal problem of the target vehicle. Then, the test program matching is performed on the abnormal feature data from the preset test program library to determine the fault test program corresponding to the target vehicle. Then, the fault test program is loaded to the target vehicle, and then the fault test is performed on the target vehicle through the fault test program to collect the fault test data when the fault problem occurs. Further, the fault analysis is performed on the collected fault test data to obtain the fault detection result of the target vehicle.

[0012] The technical scheme provided in the embodiments of the present application can select a customized test program according to the actual abnormal problem fed back by the user or the vehicle, and perform targeted fault test and data collection on the vehicle through remote deployment. The technical scheme provided in the present application significantly improves the data mining depth during fault detection, efficiently locates the source of complex and difficult-to-reproduce vehicle faults, effectively improves the detection accuracy of vehicle fault problems, and the overall processing process is highly automated, greatly improving the fault detection efficiency.

[0013] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF DRAWINGS

[0014] In order to more clearly illustrate the technical scheme of the embodiments of the present application, the drawings required to be used in the embodiments of the present application will be briefly introduced. Those skilled in the art can obtain other drawings according to these drawings without creating any creative labor.

[0015] Figure 1 One of the flowcharts of a fault detection method provided by an embodiment of the present application; Figure 2 The second flowchart of a fault detection method provided by an embodiment of the present application; Figure 3 The structural schematic diagram of a fault detection device provided by another embodiment of the present application; Figure 4 The structural schematic diagram of a vehicle provided by another embodiment of the present application. DETAILED DESCRIPTION

[0016] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical scheme and advantages of the present application more clear and apparent, the present application will be further described in detail below in combination with the drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, but not to limit the present application. The present application can be implemented without some of these specific details by those skilled in the art. The following description of the embodiments is only to provide a better understanding of the present application by showing examples of the present application.

[0017] It should be noted that, in this document, the terms such as first and second, etc. are merely used to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between such entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the elements defined by the statement "include" do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0018] It should be noted that the acquisition, storage, use and processing of data in the embodiments of the present application comply with the relevant provisions of national laws and regulations.

[0019] In addition, it should be noted that in the embodiments of the present application, some software, components, models and other existing industry solutions may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the implementation of the technical solutions of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0020] With the rapid development of intelligent and networked vehicles, the composition of vehicle hardware and software is becoming increasingly complex, and accurate and effective fault detection in daily use is an important link to ensure driving safety, vehicle function reliability and user experience. Efficient and accurate fault detection process has important value in research and development testing, after-sales maintenance, over-the-air (OTA) upgrade and user experience optimization.

[0021] Currently, vehicle fault detection mainly relies on extracting and analyzing relevant log files. However, this method has obvious limitations in practical application. First, the pre-set log recording points in the log file often cannot cover the complete path of the fault occurrence, resulting in the lack or non-recording of key information related to the actual fault problem, so that the analysis process is difficult to trace the root cause of the fault problem, and the fault detection accuracy is difficult to guarantee. In addition, if full-quantity log recording is selected throughout the process to improve analysis accuracy, it will occupy too much system resource and network bandwidth overhead during vehicle use, seriously affecting the normal performance of the vehicle.

[0022] In addition, many vehicle fault problems are intermittent and scene-specific, which are difficult to reproduce stably, making it difficult to trace and locate the problem. At the same time, the existing data transmission and analysis process mostly relies on manual active export of log files and subsequent processing, which is a tedious and low-timeliness processing method, seriously affecting the processing efficiency of the overall fault detection and problem repair process.

[0023] To address the aforementioned technical problems, this application provides a fault detection method, apparatus, vehicle, storage medium, and program product. The method includes: First, feature extraction is performed on vehicle anomaly information sent by a target vehicle or user to obtain anomaly feature data representing an anomaly in the target vehicle. Then, test program matching is performed on the anomaly feature data from a preset test program library to determine the corresponding fault test program for the target vehicle. Next, the fault test program is loaded into the target vehicle, and fault testing is performed on the target vehicle using the fault test program to collect fault test data when the fault occurs. Further, fault analysis is performed on the collected fault test data to obtain the fault detection result of the target vehicle.

[0024] The technical solution provided in this application allows for customized test program selection based on actual anomalies reported by users or vehicles. It enables targeted fault testing and data collection on vehicles through remote deployment. This technical solution effectively improves the depth and accuracy of data mining during fault detection, efficiently and accurately pinpointing the source of complex and difficult-to-reproduce vehicle faults. It significantly accelerates the detection accuracy of vehicle faults, and the overall processing is highly automated, significantly improving fault detection efficiency and fault repair speed, thus maximizing the optimization of the actual user experience.

[0025] The execution subject used in the technical solutions provided in the embodiments of this application can be a terminal device capable of transmitting data with the target vehicle, such as a desktop computer or a laptop computer, or a remote device, such as a server that carries a cloud platform that applies the technical solutions provided in this application.

[0026] In addition, the execution entity used in the embodiments of this application can also be a software execution entity, such as a client or software program installed in a terminal device. The specific type of execution entity corresponding to the fault detection method, device, vehicle, storage medium, and program product provided in the embodiments of this application is not strictly limited here; it can be flexibly selected and set according to the application scenario and actual needs.

[0027] It should be noted that the specific application scenarios of the fault detection methods, devices, vehicles, storage media and program products provided in the embodiments of this application are not limited. The technical solutions provided in the embodiments of this application can be flexibly applied to various actual scenarios where vehicle fault problems need to be detected, according to actual needs.

[0028] For example, in a scenario where the vehicle's central control system experiences irregular glitches and operational delays, the technical solution provided in this application can, upon receiving abnormal vehicle information reported by the user or automatically by the vehicle's monitoring system, fully extract the abnormal feature data leading to the aforementioned malfunctions. Further feature matching is then performed to obtain a fault test program adapted to the current state of the target vehicle, which is then loaded onto the target vehicle. This fault test program allows for fault testing and data collection on the target vehicle, enabling analysis of the fault data to pinpoint the causes of the irregular glitches and operational delays in the central control system. Examples include memory leaks or thread blocking in individual service processes, or abnormal inter-service communication.

[0029] The technical solution provided in this application enables efficient and accurate analysis of abnormal problems, allowing for the selection of targeted testing programs to perform fault tests on the target vehicle. This achieves precise triggering and targeted capture of vehicle fault problems, thereby accurately locating the source of the fault and significantly improving the efficiency and effectiveness of subsequent repair work.

[0030] It should be noted that the application scenarios described in the above embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems. The fault detection method, device, vehicle, storage medium, and program product provided by the embodiments of this application can be applied to various practical scenarios requiring the detection of vehicle fault problems.

[0031] Figure 1 This is a flowchart illustrating a fault detection method provided in one embodiment of this application. Figure 1 As shown, the specific steps include S101-S103.

[0032] S101: In response to vehicle anomaly information sent by the target vehicle or user, extract features from the vehicle anomaly information to determine the anomaly feature data of the target vehicle.

[0033] In step S101, the technical solution provided in this application embodiment can monitor and receive vehicle anomaly information of the target vehicle in real time. Further feature extraction can be performed on the vehicle anomaly information to obtain anomaly feature data. The anomaly feature data can characterize the anomaly problem caused by the malfunction of the target vehicle.

[0034] Among them, vehicle anomaly information can be abnormal log events monitored and recorded by the monitoring terminal configured locally on the target vehicle during vehicle use, or it can be specific abnormal issues actively discovered by the user of the target vehicle and reported in the form of text description or voice input.

[0035] Anomaly feature data can represent important characteristics of the anomaly problem corresponding to the target vehicle. The specific data format is not strictly limited in this application. In some embodiments, key information can be extracted from vehicle anomaly information as anomaly feature data, and the appropriate format can be flexibly selected according to actual needs and application scenarios.

[0036] Regarding the specific process for determining abnormal feature data, in the embodiments provided in this application, keyword analysis can be performed on the received vehicle anomaly information to extract at least one abnormal keyword that is highly relevant to the anomaly of the target vehicle. Furthermore, based on the determined abnormal keywords, the abnormal feature data corresponding to the target vehicle can be determined; specifically, multiple abnormal keywords can be combined to form the abnormal feature data.

[0037] For example, suppose a target vehicle has an abnormal issue of intermittent torque loss. This target vehicle can transmit one or more "torque request not met" low-level anonymous log events to the implementing entity (e.g., a cloud service platform) applying the technical solution of this application. Simultaneously, the vehicle driver or user can describe and upload the observed abnormality and negative experience, ensuring safety. For example, "When the vehicle is cruising at high speed (around 100 km / h), there is an occasional brief, approximately 1-2 second power interruption, with no warning lights illuminated on the dashboard." The upload method can be flexibly selected based on the vehicle's functions. For instance, the user can report the problem by voice description to the vehicle's in-vehicle voice assistant, by text input on the vehicle's central control screen, or by a pre-installed software program on a mobile terminal.

[0038] Upon receiving vehicle anomaly information reported by vehicles and users, keyword analysis and extraction can be performed. In some embodiments, Natural Language Processing (NLP) techniques can be used to accurately identify and extract keywords representing abnormal characteristics from the vehicle anomaly information. In this example, the anomaly keywords extracted through this embodiment may include, but are not limited to: high speed, cruising, power interruption, no warning, intermittent, etc. Based on the above multiple anomaly keywords, subsequent steps can perform targeted test program matching, thereby conducting fault testing and data collection on the target vehicle through a pre-customized test sequence for such anomalies, in order to achieve accurate and efficient fault detection and analysis.

[0039] The above embodiments can perform preliminary intelligent processing on the original and non-standardized anomaly descriptions reported by users or vehicles, providing a crucial data foundation and selection basis for subsequent test program matching. This embodiment significantly improves the adaptability and parsing efficiency of the overall fault detection process to diverse fault and anomaly descriptions, enhances the automation and adaptability of detection, expands the applicability of the detection method, and strengthens the robustness of the detection system.

[0040] S102: Based on abnormal feature data and a preset test program library, perform test program matching to determine the fault test program for the target vehicle.

[0041] In step S102, the technical solution provided by this application can determine the test program with the highest degree of adaptation to the abnormal problem corresponding to the abnormal feature data based on a pre-built preset test program library, and use it as the fault test program for the target vehicle.

[0042] The fault test program can be installed on the target vehicle in subsequent steps to perform a test task that collects fault data for abnormal problems existing in the target vehicle.

[0043] The preset test program library can store test programs for various abnormal problems of vehicles. Each test program can be responsible for the fault test of one or more abnormal problems. After being loaded onto the target vehicle, it can accurately and deeply collect test data that is strongly correlated with the abnormal problem when the abnormal problem is reproduced on the target vehicle or when the abnormal problem is actively triggered, providing accurate and reliable test basis for subsequent fault analysis and detection process.

[0044] Regarding the specific matching and determination process of fault test programs, in the embodiments provided in this application, the matching degree between abnormal feature data and each test program in the preset test program library can be calculated. Then, at least one test program whose matching degree value meets the preset matching degree threshold is selected as the candidate test program for the target vehicle.

[0045] Furthermore, based on the correlation between each abnormal feature and the actual abnormal problem, the key abnormal features with higher abnormal impact weights in the abnormal feature data can be identified. Then, based on the key abnormal features, the most suitable test program for detecting faults corresponding to abnormal problems in the target vehicle can be selected from at least one candidate test program, and this program will be used as the fault test program.

[0046] Taking the target vehicle with intermittent torque loss anomaly as an example from the above embodiment, this example scenario allows us to first determine the matching degree between the abnormal feature data, including the aforementioned "high speed, cruising, power interruption, no warning, and intermittent," and each test program in the preset test program library.

[0047] Then, test programs with a matching degree greater than a preset matching degree threshold can be selected as candidate test programs for the target vehicle. Specific examples include: intermittent torque loss diagnostic program for the powertrain, CAN communication load diagnostic program under high-speed operating conditions, and high-voltage circuit stability test program for the engine ignition system.

[0048] Next, in this embodiment, key anomaly features in the abnormal feature data can be further analyzed and identified. For example, "no warning" and "intermittent" among the aforementioned keywords can be used as key anomaly features of the target vehicle. Based on these key anomaly features, the most suitable test program for testing the current target vehicle's fault problem can be determined from a number of candidate test programs. For example, the powertrain intermittent torque loss diagnostic program in the above example can be selected as the fault test program for the target vehicle in this example.

[0049] The identified fault test procedure can be encrypted and transmitted to the vehicle terminal of the target vehicle in subsequent steps to perform fault testing and collect in-depth vehicle data, providing real data for subsequent fault analysis and detection.

[0050] The coarse-grained screening based on feature and program matching in the above embodiments ensures the relevance and breadth of coverage of candidate test programs. Then, the final selection of fault test programs is based on key features, significantly improving the relevance and practicality of the fault test programs. This embodiment can efficiently and accurately identify the test program most likely to reproduce and detect the current vehicle fault from a pre-set test program library, greatly improving the accuracy and efficiency of subsequent fault detection processes.

[0051] In addition, this application takes into account that with the advancement of technology, the types of vehicle faults will gradually increase. For vehicle abnormalities caused by new types of vehicle faults, the preset test program library may not necessarily store suitable test programs as fault test programs.

[0052] Based on this, in the embodiments provided in this application, when the above-mentioned candidate test program cannot be matched from the preset test program library, that is, when there is no test program in the preset test program library that meets the preset matching degree threshold with the abnormal feature data, the test program with the highest matching degree with the abnormal feature data in the preset test program library can be used as the program to be optimized for the target vehicle.

[0053] Then, based on the abnormal feature data, the program to be optimized can be optimized so that the matching degree between the optimized program and the abnormal feature data can meet the above-mentioned preset matching degree threshold, and then the optimized program can be used as the fault detection program for the target vehicle.

[0054] The specific program optimization method is not strictly limited in the embodiments of this application. In some embodiments, a pre-trained intelligent code optimization algorithm may be used to optimize and adjust the program code of the program to be optimized, so that the optimized program can perform fault testing for vehicle anomalies corresponding to abnormal feature data. Alternatively, in other embodiments, a prompt message may be generated for the program to be optimized and sent to the relevant personnel responsible for code optimization, so that the relevant personnel can adjust the program to be optimized based on the abnormal feature data, or redesign the corresponding test program for the abnormal feature data with reference to the program to be optimized. The specific program optimization method can be flexibly selected according to actual needs and application scenarios.

[0055] In the above embodiments, when the existing program library cannot match new vehicle anomalies, adaptive adjustments and optimizations can be performed based on the closest existing test program. This embodiment fully ensures the robustness and adaptability of the entire fault detection process when facing unknown anomalies, guarantees the normal execution of the fault detection process, and substantially expands the applicability and fault detection capabilities of the detection method.

[0056] S103: Transmit the fault test program to the target vehicle, and perform fault tests on the target vehicle corresponding to the vehicle abnormality information through the fault test program, and collect fault test data.

[0057] In step S103, the technical solution provided in this application embodiment can send and load the fault detection program determined for the target vehicle to the vehicle terminal of the target vehicle. Further, through the fault testing program, fault detection is performed on the vehicle anomalies corresponding to the vehicle anomaly information in the target vehicle, and vehicle data at the time of the fault occurrence is collected as the aforementioned fault test data.

[0058] In some embodiments, the technical solution provided in this application can create a fault detection task for the target vehicle after determining the fault test program corresponding to the target vehicle. The initial state of the task is pending issuance, and the corresponding executor is the fault test program.

[0059] Meanwhile, to ensure the data security of all interactive data, including vehicle data, during the fault detection process, the fault test program can be signed and encrypted. The encrypted and packaged data is then transmitted to the target vehicle, which then decrypts and verifies the fault test program to be loaded.

[0060] Regarding the specific transmission process of the fault test program, in the embodiments provided in this application, the fault test program can be signed (e.g., by hashing) based on a preset signature private key used for data signing to obtain a digital signature of the fault test program. The digital signature allows the target vehicle to authenticate the source of the test program by using the public key corresponding to the preset signature private key after the encrypted data is transmitted to the target vehicle.

[0061] Then, the fault test program and its corresponding digital signature can be packaged, and the packaged data can be encrypted using a preset key to obtain encrypted data. Next, the preset key used in the above encryption process can be encrypted using a preset public key to obtain the encrypted key.

[0062] The preset key can be a key generated at any time, and the specific encryption algorithm can be flexibly selected according to actual needs and application scenarios. In some embodiments, Advanced Encryption Standard (AES), Triple Data Encryption Algorithm (TDEA / 3DES), Data Encryption Standard (DES), etc. can be selected. The preset encryption public key is the public key of the key pair exclusive to the target vehicle, so that only the target vehicle can decrypt the data using the corresponding private key to obtain the digital signature and fault test program.

[0063] Then, the encrypted data containing the fault test program and digital signature, along with the encrypted key, can be packaged and sent to the vehicle terminal of the target vehicle. This allows the vehicle terminal to further decrypt and verify the received encrypted data based on the preset encrypted private key corresponding to the preset encrypted public key and the preset signature public key corresponding to the preset signature private key. After successful decryption and verification, the vehicle terminal can load the fault test program and execute the subsequent fault test process through the fault test program.

[0064] In some embodiments, the data received by the vehicle terminal of the target vehicle may include: encrypted program data and security credentials. The program data may specifically include the program script or module composition (e.g., program code) of the fault test program, as well as the program execution instructions, and the specific file type may be JSON format (JavaScript Object Notation) or Extensible Markup Language (XML).

[0065] The execution instructions may include, but are not limited to: program identifier, program version, required permissions, task execution parameters (e.g., sampling frequency of 100Hz and duration of 10 minutes), and target electronic control unit (ECU) (e.g., engine control module (ECM), transmission control unit (TCU)).

[0066] The security credentials may include the encrypted signature obtained by signing and encrypting the fault test procedure, as well as the encrypted preset public key. The packaged encrypted data can be transmitted over a network (such as a cellular network) to the target vehicle's telematics box (T-Box).

[0067] The above embodiments establish a robust security barrier for the remote distribution and execution of fault testing programs. They fully guarantee the confidentiality of the testing programs during transmission, effectively preventing theft or tampering. Furthermore, signature verification rigorously ensures the authenticity and integrity of the testing programs' origin, effectively resisting malicious attacks. This embodiment fully protects user data security and effectively improves the data security and stability of the overall testing process.

[0068] Regarding the specific verification and decryption process after the target vehicle receives encrypted data, in the embodiments provided in this application, the vehicle terminal of the target vehicle can first decrypt the encrypted key in the received data based on a preset encryption private key to obtain the aforementioned preset key. Then, based on the decrypted preset key, the received encrypted data can be decrypted to obtain the original fault test program and the corresponding digital signature.

[0069] Furthermore, the vehicle terminal can verify the decrypted digital signature based on a preset signature public key. Upon successful verification, it can be confirmed that the received data source is trustworthy and has not been tampered with during transmission. In this case, the decrypted fault test program can be loaded into a pre-built secure isolation sandbox on the vehicle terminal, allowing the fault test program to run securely within the sandbox.

[0070] In some embodiments, when the above signature verification fails, it indicates that the received data source is not trustworthy or may have been tampered with during transmission. The target vehicle will directly discard the decrypted fault test program and report and re-request the fault test program.

[0071] The security isolation sandbox can be set up in the target vehicle's onboard gateway or a high-performance domain controller (such as the body domain controller, chassis domain controller, etc.). Specifically, the security isolation sandbox is used to restrict and monitor fault test programs. For example, it restricts fault test programs to access only authorized specific vehicle data buses (such as CAN FD (Controller Area Network with Flexible Data-rate), Ethernet, etc.) and electronic control units, while setting the fault test programs to a lower priority. This ensures that the program's operation does not affect the normal operation of other vehicle control functions, and it monitors the program's consumption of vehicle computing power (such as processor utilization, memory usage, etc.) in real time to prevent excessive program resource consumption from affecting the normal execution of other functions.

[0072] The above embodiments fully ensure that the test program can be correctly decrypted and verified after transmission, and is loaded and run in a secure isolation sandbox, building a security barrier for the execution of the fault detection program. This embodiment effectively isolates the potential risks of the test program to other vehicle functions, greatly improving the security and reliability of data transmission, fully protecting vehicle data security, and enhancing the reliability and stability of the overall fault detection process.

[0073] Regarding the collection of fault test data through the aforementioned fault test procedure, in the embodiments provided in this application, it can be first determined whether the target vehicle is currently in a vehicle fault state corresponding to the vehicle abnormality information. The vehicle fault state can indicate that the target vehicle is performing an action that would cause vehicle abnormality.

[0074] When it is determined that the target vehicle is not currently in a fault state that could cause vehicle abnormalities, this embodiment can proactively induce vehicle faults and monitor and collect data when the fault occurs. Specifically, in this case, the fault testing program can proactively send a fault testing request to the vehicle user, while ensuring vehicle operation and driving safety, to request the user to control the target vehicle to reproduce the vehicle abnormality corresponding to the abnormal vehicle information.

[0075] Regarding the method of sending the request, in some embodiments the fault test request can be displayed to the vehicle user through the vehicle's central control screen, in other embodiments the fault test request can be broadcast to the vehicle user through the vehicle's audio system, or in other embodiments the fault test request can be sent to the user's mobile terminal. The specific method can be flexibly selected according to actual needs and application scenarios.

[0076] Users can respond to fault test requests. After receiving the user's feedback agreeing to the fault test, the vehicle terminal notifies the fault test program that it can control the target vehicle, thereby adjusting the target vehicle from its current state to the vehicle fault state corresponding to the vehicle abnormality information.

[0077] When it is determined that the target vehicle is in a vehicle malfunction state, that is, when the vehicle happens to perform an action that would cause the vehicle to malfunction during the fault test, or when the target vehicle is put into a vehicle malfunction state through the above-mentioned proactive adjustment, the fault test program can simultaneously monitor and collect multiple data from the target vehicle in the current state to obtain fault detection data.

[0078] Specifically, this can include: collecting vehicle operation data related to vehicle anomalies in a vehicle fault state based on a preset high sampling frequency (e.g., 100Hz). Simultaneously, it can perform complete link tracing of function calls of the target vehicle in the current state, collect function link data, and monitor the target vehicle's memory usage in real time, collecting memory change data during the fault testing process.

[0079] Vehicle operation data can be used in subsequent fault analysis to determine whether the various components inside the vehicle are functioning properly or if there are any damage issues. Function link data can be used to analyze the function calculation logic or function output that caused the vehicle abnormality during software function calls. Memory change data can be used to analyze whether the vehicle abnormality is caused by problems with the vehicle's memory, such as memory rollover, stack overflow, or data overflow.

[0080] Furthermore, the fault testing program can combine the monitored vehicle operation data, function link data, and memory change data into a single fault detection data set for the target vehicle, and output this data to the implementing entity that applies the technical solution of this application, such as a cloud service platform. This allows for subsequent steps to perform fault analysis on the target vehicle based on the fault detection data, thereby determining the fault detection results.

[0081] For example, let's take the target vehicle with intermittent torque loss anomaly as described in the above embodiment. In this example, this embodiment can first determine whether the target vehicle is in an operating state with intermittent torque loss.

[0082] If not, a fault test request can be made to the user. With the user's consent, a control command can be sent to the engine controller of the target vehicle. This causes the engine controller to rapidly and repeatedly execute torque requests, cancel them, and then request them again within a very short time (e.g., microseconds). The reason for this cyclical operation is that some abnormal issues may not be reliably triggered even after the same operation is executed once. Therefore, by repeatedly executing the corresponding operation, the number of times the vehicle abnormality occurs is increased, thereby enhancing the accuracy and practicality of the fault test data.

[0083] For a target vehicle experiencing a malfunction, a fault testing program can monitor and collect the aforementioned data. In this example, the fault testing program can monitor multiple vehicle operating data related to intermittent torque loss anomalies at a preset high sampling frequency. Specifically, it can collect data from multiple electronic control units such as the engine controller, transmission controller, ignition system, and fuel system. This data can be categorized into actual execution data and planned execution data, including but not limited to: throttle opening, ignition advance angle, fuel injection pulse width, cylinder misfire counters, high-pressure fuel pump pressure, and critical CAN bus load rate. Subsequent fault analysis can compare the differences between the actual and planned execution data to determine the specific cause of the vehicle anomaly.

[0084] Furthermore, in this example, the fault testing program can, when the target vehicle's engine controller is in diagnostic mode, record the call sequence of several key functions related to vehicle anomalies, as well as the function input and return values ​​during the call process, by invoking a function tracer. Specifically, in response to the target vehicle's accelerator being depressed, it traces the execution of the entire function chain, from the CalculateRequestedTorque function to the ControlThrottleValve function, and finally to the ControlIgnition function. When a torque loss anomaly occurs, the specific source of the function error can be observed from the complete function chain.

[0085] Furthermore, for this example, the fault detection program can detect data changes in the corresponding memory area of ​​the target vehicle's engine controller during and before the fault occurs, based on a preset monitoring period. This includes things like the cache storing the fuel injection quantity MAP and the stack for real-time calculation of intermediate variables. In subsequent analysis, the changes in memory data can be used to determine if issues such as memory bit flips, stack overflows, or data overflows have occurred. Anomalies could include situations where a variable representing the target air-fuel ratio is overwritten by an abnormally large value at the moment the fault occurs.

[0086] The vehicle operation data, function link data, and memory change data collected through the above process can be packaged together, encrypted, and then fed back to the implementing entity that applies the technical solution of this application. After subsequent fault analysis, the specific fault problems and their sources within the target vehicle can be determined.

[0087] The above embodiment realizes a complete, controllable, and information-rich fault data collection process. This embodiment first verifies and actively controls the vehicle to enter a fault state, ensuring the relevance and effectiveness of subsequent test data collection. Simultaneously, a user confirmation mechanism is introduced to guarantee the compliance of the test and the user's right to know. This embodiment can accurately collect multi-dimensional data about the vehicle in a fault state, significantly improving data depth and providing a true and effective basis for subsequent fault detection, greatly enhancing the detection accuracy of the fault detection process.

[0088] S104: Perform fault analysis on the fault test data to determine the fault detection results of the target vehicle.

[0089] In step S104, the technical solution provided in this application embodiment can perform anomaly analysis on the fault test data fed back by the vehicle, determine the fault cause that leads to the vehicle abnormality information of the target vehicle, and obtain the fault detection result.

[0090] In the embodiments provided in this application, a detailed fault analysis can be performed based on the received fault test data. Combined with previously acquired vehicle anomaly information, the root cause of the vehicle's abnormal problems can be determined from the fault test data, as well as a series of impacts caused by it. A detailed test report can be generated. The report can clearly record the root cause of the target vehicle's abnormal operation. For example, in the above example, for a target vehicle with intermittent torque loss anomaly, the corresponding fault cause could be high-pressure fuel pump performance degradation, etc.

[0091] It should be noted that the embodiments of this application do not strictly limit the specific methods or approaches for determining fault detection results. In some embodiments, fault detection data can be analyzed using preset anomaly detection and pattern recognition algorithms to determine the cause of the target vehicle's fault. In other embodiments, the fault detection results of the target vehicle can also be determined using a root cause analysis model (RCA) or classification and attribution algorithms. The specific method can be flexibly selected according to actual needs and application scenarios.

[0092] In addition, the technical solution provided in this application can further perform repair tasks for fault problems in the target vehicle based on the fault detection results.

[0093] Specifically, in the embodiments provided in this application, the fault type corresponding to the fault problem on the target vehicle can be determined based on the detected fault detection results. In some embodiments, the fault type can be divided into vehicle hardware damage and software operation error. Furthermore, based on the fault type, a corresponding fault repair task can be performed on the target vehicle.

[0094] In some embodiments, when the fault type of the target vehicle is the aforementioned vehicle hardware damage, a repair appointment reminder can be sent to the user, informing them of the specific damaged components in the target vehicle.

[0095] Simultaneously, a notification can be sent to the pre-recorded maintenance center of the target vehicle regarding the hardware replacement required for the vehicle, along with a notification to develop a repair plan for the target vehicle. Upon receiving the notification, the maintenance center can prepare the replacement parts and pre-plan the repair plan for the target vehicle before the user drives the target vehicle to the maintenance center.

[0096] In other embodiments, when the fault type of the target vehicle is the aforementioned software runtime error, a corresponding software repair patch can be generated based on the specific software runtime error in the fault detection results and sent to the vehicle terminal of the target vehicle, so that the vehicle terminal can perform software update and repair based on the received software repair patch, thereby eliminating the software runtime error that previously caused the abnormal problem of the target vehicle.

[0097] Simultaneously, once it's determined that a software patch can resolve the discovered software malfunction, the patch can be sent to other vehicles with the same software system as the target vehicle for a unified software update, preventing similar issues from occurring in other vehicles. The specific transmission and update method can be over-the-air (OTA) technology.

[0098] The specific transmission process of the software patch can be flexibly selected according to actual needs and application scenarios. In some embodiments, when a software error is detected in the target vehicle, a corresponding software patch can be generated immediately and sent via over-the-air download technology to promptly eliminate the vehicle anomaly.

[0099] In other embodiments, one or more software patches generated to address software runtime errors in the target vehicle can be integrated. When the in-vehicle software undergoes a unified version update, the integrated software patch can be packaged together with the software version update data and sent to similar vehicles via over-the-air (OTA) download technology. This allows vehicles to perform normal software version updates while simultaneously fixing runtime errors based on the software patch, thereby eliminating vehicle malfunctions and safety hazards.

[0100] The above embodiments can categorize vehicle fault types into hardware damage and software errors, and execute fully automated repair processes accordingly. This embodiment greatly improves the timeliness and accuracy of fault resolution, significantly enhances the user experience, and ensures vehicle safety through efficient fault repair and handling, reducing driving or riding risks for users and protecting their lives and health.

[0101] By executing the repair tasks in the above embodiments, fault detection results are associated with specific fault types, and corresponding repair tasks are executed accordingly, thereby achieving automated fault response and processing. This effectively improves the efficiency and effectiveness of repairing vehicle faults, significantly enhances the safety and reliability of vehicle use, and further optimizes the user experience for in-vehicle users.

[0102] The following is a summary of the overall process of the fault detection method provided in this application, based on the above embodiments. For details, please refer to... Figure 2 As shown in the image.

[0103] Figure 2 This is a flowchart illustrating a fault detection method provided in one embodiment of this application. Figure 2 As shown, the specific steps include S201-S211.

[0104] S201: Receive abnormal vehicle data of the target vehicle, analyze abnormal keywords in the abnormal vehicle data, and extract abnormal feature data.

[0105] S202: Based on abnormal feature data, match the fault test program of the target vehicle from the preset test program library.

[0106] S203: Sign and encrypt the fault test program, and transmit the encrypted data to the target vehicle.

[0107] S204: The target vehicle decrypts and signs the fault test program. After successful verification, the fault test program is loaded into the security isolation sandbox and run.

[0108] S205: Determine whether the target vehicle is in a fault state corresponding to the abnormal vehicle data.

[0109] S206: Send a test request to the user through the fault test procedure to adjust the target vehicle to a fault state.

[0110] S207: Collect vehicle operation data, function link data, and memory change data of the target vehicle under fault conditions through the fault test program, and output them as fault test data.

[0111] S208: Analyze fault problems based on fault test data to determine the fault detection results of the target vehicle.

[0112] S209: Based on the fault detection results, determine the fault type of the target vehicle.

[0113] S210: Based on the fault type, perform fault repair tasks on the target vehicle.

[0114] Through steps S201 to S211 described above, the faults of the target vehicle can be accurately detected and analyzed. Based on the detection results, the faults of the target vehicle can be efficiently repaired, fully ensuring vehicle safety and optimizing user experience. Specific technical details can be found in the above embodiments, and will not be elaborated further here.

[0115] The above describes the specific implementation of the fault detection method provided in this application. The technical solution provided in this application can customize test program selection for actual abnormal problems reported by users or vehicles, and conduct targeted fault testing and data collection on vehicles through remote deployment. The technical solution provided in this application significantly improves the depth of data mining during fault detection, efficiently locates the source of complex and difficult-to-reproduce vehicle faults, effectively accelerates the detection accuracy of vehicle fault problems, and the overall processing is highly automated, greatly improving fault detection efficiency.

[0116] Based on the fault detection method provided in the above embodiments, this application also provides an embodiment of a fault detection device.

[0117] Figure 3 This is a schematic diagram of a fault detection device provided in another embodiment of this application.

[0118] like Figure 3 As shown, this application embodiment also provides a fault detection device 300, which includes: The feature extraction module 301 is used to extract features from the vehicle abnormality information sent by the target vehicle or user in response to the vehicle abnormality information, and to determine the abnormal feature data of the target vehicle. The program matching module 302 is used to match test programs based on abnormal feature data and a preset test program library to determine the fault test program for the target vehicle. The fault test module 303 is used to transmit the fault test program to the target vehicle, and to perform fault tests on the target vehicle corresponding to the vehicle abnormal information through the fault test program, and to collect fault test data. The fault detection module 304 is used to analyze fault test data and determine the fault detection results of the target vehicle.

[0119] In some embodiments, the feature extraction module 301 described above is specifically used for: Perform keyword analysis on vehicle anomaly information to identify at least one abnormal keyword in the vehicle anomaly information; Based on at least one anomalous keyword, identify anomalous feature data.

[0120] In some embodiments, the above-described program matching module 302 is specifically used for: Determine the matching degree between the abnormal feature data and each test program in the preset test program library; At least one test procedure that meets the preset matching threshold is selected as at least one candidate test procedure for the target vehicle. Based on key anomaly features in the anomaly feature data, a fault test program is determined from at least one candidate test program.

[0121] In some embodiments, the above-described program matching module 302 is specifically used for: If there is no test program in the preset test program library that meets the preset matching threshold, the test program with the highest matching degree will be selected as the program to be optimized. Based on the abnormal feature data, the program to be optimized is optimized to obtain the fault test program.

[0122] In some embodiments, the fault test module 303 described above is specifically used for: Based on the preset signature private key, the fault test program is signed to obtain the digital signature of the fault test program; Based on the preset key, the fault test program and digital signature are encrypted to obtain encrypted data. Based on the preset encryption public key, the preset key is encrypted to obtain the encrypted key. The encrypted data and encrypted key are sent to the vehicle terminal of the target vehicle, so that the vehicle terminal can decrypt and sign the encrypted data based on the preset encrypted private key corresponding to the preset encrypted public key and the preset signed public key corresponding to the preset signed private key, and then load the fault test program.

[0123] In some embodiments, the fault test module 303 described above is specifically used for: The encrypted key is decrypted using the preset encryption private key to obtain the preset key; The encrypted data is decrypted using a preset key to obtain a fault test program and a digital signature. Based on the preset signature public key, the digital signature is verified. If the verification is successful, the fault test program is loaded into the preset security isolation sandbox in the vehicle terminal.

[0124] In some embodiments, the fault test module 303 described above is specifically used for: Determine whether the target vehicle is in a vehicle malfunction state corresponding to the vehicle abnormality information; If not, a fault test request is sent to the user through the fault test procedure, and in response to the user's consent to the fault test instruction, the target vehicle is adjusted to a vehicle fault state; If so, the fault test program collects the vehicle operation data of the target vehicle based on a preset high sampling frequency, tracks the function calls of the target vehicle, collects function link data, and monitors the memory state changes of the target vehicle and collects memory change data. Based on vehicle operation data, function link data, and memory change data, fault test data is determined.

[0125] In some embodiments, the fault detection module 304 described above is specifically used for: Based on the fault detection results, determine the fault type of the target vehicle; Based on the fault type, perform fault repair tasks for the target vehicle.

[0126] In some embodiments, the fault detection module 304 described above is specifically used for: Based on the fault type, perform fault repair tasks for the target vehicle, including: In the case of vehicle hardware damage, a repair appointment reminder and the damaged parts of the target vehicle are sent to the user, and a replacement notice for the damaged parts and a repair plan formulation notice are sent to the maintenance center of the target vehicle, so that the maintenance center can prepare replacement parts for the damaged parts and formulate a repair plan for the target vehicle. In the case of a software malfunction, a software repair patch is generated based on the fault detection results and sent to the target vehicle, enabling the target vehicle to perform a software update and repair based on the software repair patch.

[0127] Figure 4 This is a structural schematic diagram of a vehicle provided in yet another embodiment of this application.

[0128] The vehicle may include a processor 401 and a memory 402 storing computer program instructions.

[0129] Specifically, the processor 401 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0130] Memory 402 may include mass storage for data or instructions. For example, and not limitingly, memory 402 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 402 may include removable or non-removable (or fixed) media. Where appropriate, memory 402 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 402 is non-volatile solid-state memory.

[0131] In a particular embodiment, memory 402 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform operations described with reference to any of the fault detection methods disclosed in this application.

[0132] The processor 401 implements any of the fault detection methods described in the above embodiments by reading and executing computer program instructions stored in the memory 402.

[0133] In one example, the vehicle may also include a communication interface 403 and a bus 410. Wherein, as... Figure 4 As shown, the processor 401, memory 402, and communication interface 403 are connected through bus 410 and complete communication with each other.

[0134] The communication interface 403 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0135] Bus 410 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 410 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0136] Furthermore, in conjunction with the fault detection methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the fault detection methods in the above embodiments.

[0137] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the fault detection methods described in the above embodiments.

[0138] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0139] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0140] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0141] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0142] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A fault detection method, characterized in that, include: In response to vehicle anomaly information sent by the target vehicle or user, feature extraction is performed on the vehicle anomaly information to determine the anomaly feature data of the target vehicle. Based on the abnormal feature data and the preset test program library, test program matching is performed to determine the fault test program for the target vehicle. The fault test program is transmitted to the target vehicle, and fault tests corresponding to the vehicle abnormality information are performed on the target vehicle through the fault test program to collect fault test data. The fault test data is analyzed to determine the fault detection results of the target vehicle.

2. The method according to claim 1, characterized in that, Feature extraction is performed on the vehicle anomaly information to determine the anomaly feature data of the target vehicle, including: Perform keyword analysis on the vehicle anomaly information to identify at least one abnormal keyword in the vehicle anomaly information; Based on the at least one abnormal keyword, the abnormal feature data is determined.

3. The method according to claim 1, characterized in that, Based on the abnormal feature data and the preset test program library, test program matching is performed to determine the fault test program for the target vehicle, including: Determine the degree of matching between the abnormal feature data and each test program in the preset test program library; At least one test program that satisfies the preset matching degree threshold is selected as at least one candidate test program for the target vehicle. Based on the key abnormal features in the abnormal feature data, the fault test program is determined from the at least one candidate test program.

4. The method according to claim 3, characterized in that, The method further includes: If there is no test program in the preset test program library that meets the preset matching degree threshold, the test program with the highest matching degree will be selected as the program to be optimized. Based on the abnormal feature data, the program to be optimized is optimized to obtain the fault test program.

5. The method according to claim 1, characterized in that, Transmitting the fault test program to the target vehicle includes: Based on a preset signature private key, the fault test program is signed to obtain the digital signature of the fault test program. Based on a preset key, the fault test program and the digital signature are encrypted to obtain encrypted data. Based on a preset encryption public key, the preset key is encrypted to obtain an encrypted key. The encrypted data and the encrypted key are sent to the vehicle terminal of the target vehicle, so that the vehicle terminal can decrypt and sign the encrypted data based on the preset encrypted private key corresponding to the preset encrypted public key and the preset signed public key corresponding to the preset signed private key, and obtain and load the fault test program.

6. The method according to claim 5, characterized in that, The encrypted data is decrypted and signed for verification to obtain and load the fault test program, including: The encrypted key is decrypted based on the preset encryption private key to obtain the preset key; The encrypted data is decrypted based on the preset key to obtain the fault test program and the digital signature; Based on the preset signature public key, the digital signature is verified. If the verification is successful, the fault test program is loaded into the preset security isolation sandbox in the vehicle terminal.

7. The method according to claim 1, characterized in that, The fault testing procedure is used to perform fault tests on the target vehicle corresponding to the vehicle's abnormal information, and to collect fault test data, including: Determine whether the target vehicle is in a vehicle malfunction state corresponding to the vehicle abnormality information; If not, a fault test request is sent to the user through the fault test procedure, and in response to the user's consent to the fault test instruction, the target vehicle is adjusted to the vehicle fault state. If so, the fault test program collects the vehicle operation data of the target vehicle based on a preset high sampling frequency, tracks the function calls of the target vehicle, collects function link data, and monitors the memory state changes of the target vehicle and collects memory change data. The fault test data is determined based on the vehicle operation data, the function link data, and the memory change data.

8. The method according to claim 1, characterized in that, The method further includes: Based on the fault detection results, the fault type of the target vehicle is determined; Based on the fault type, perform a fault repair task for the target vehicle.

9. The method according to claim 8, characterized in that, The fault types include at least vehicle hardware damage or software malfunction. Based on the fault type, perform a fault repair task for the target vehicle, including: In the case where the fault type is vehicle hardware damage, a repair appointment reminder and the damaged component of the target vehicle are sent to the user, and a component replacement notice and repair plan formulation notice for the damaged component are sent to the maintenance center of the target vehicle, so that the maintenance center can prepare the replacement component for the damaged component and formulate a repair plan for the target vehicle. In the case where the fault type is a software malfunction, a software repair patch is generated based on the fault detection results and sent to the target vehicle, so that the target vehicle can perform a software update and repair based on the software repair patch.

10. A fault detection device, characterized in that, include: The feature extraction module is used to extract features from the vehicle anomaly information sent by the target vehicle or user in response to the vehicle anomaly information, and to determine the abnormal feature data of the target vehicle. The program matching module is used to perform test program matching based on the abnormal feature data and the preset test program library to determine the fault test program for the target vehicle. The fault testing module is used to transmit the fault testing program to the target vehicle, and to perform fault tests on the target vehicle corresponding to the vehicle abnormal information through the fault testing program, and collect fault test data. The fault detection module is used to perform fault analysis on the fault test data and determine the fault detection result of the target vehicle.

11. A vehicle, characterized in that, The vehicle includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the fault detection method as described in any one of claims 1-9.

Images