Automobile fault detection method, device and equipment and storage medium

Abstract

The application discloses a kind of automobile fault detection method, device, equipment and storage medium, involve automobile electronic control field, including: when monitoring fault, obtain fault information;Determine the fault type corresponding to fault based on fault information, wherein fault type includes operating system fault, abnormal interrupt fault and error tracking class fault;Based on fault type, determine target analysis strategy to analyze and fault handling for fault, quickly locate the fault state information that appears, ensure the stable operation of automobile software system and driving safety.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic control, and more particularly to a method, apparatus, device, and storage medium for detecting automotive faults. Background Technology

[0002] With the significant increase in the complexity and functional integration of automotive electronic control systems, the complexity at the software level has increased dramatically. For embedded systems, this trend means that when the software encounters anomalies or malfunctions during vehicle operation, traditional debugging methods often fail to quickly and accurately pinpoint the root cause of the problem.

[0003] Therefore, building an efficient fault location mechanism and implementing timely fault handling measures have become urgent needs to ensure driving safety and improve user experience.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for detecting automotive faults, aiming to solve the technical problem of being unable to quickly and accurately locate the root cause of a fault.

[0006] To achieve the above objectives, the present invention provides a vehicle fault detection method, the vehicle fault detection method comprising the following steps:

[0007] When a fault is detected, obtain fault information;

[0008] Based on the fault information, the fault type corresponding to the fault is determined, wherein the fault type includes operating system fault, abnormal interruption fault, and error tracking type fault.

[0009] Based on the fault type, a target analysis strategy is determined to analyze and handle the fault.

[0010] In one embodiment, the step of determining a target analysis strategy based on the fault type to analyze and handle the fault includes:

[0011] When the fault is an operating system fault, the target analysis strategy is determined to be the context relationship analysis strategy, and the context relationship analysis strategy is invoked to analyze the fault and obtain the context information of the fault.

[0012] Based on the fault information and the context information, the fault range is determined, and the devices within the fault range are isolated.

[0013] After isolation is completed, a soft reset is performed on the system, the system is restarted, and the fault information and the context information are stored.

[0014] In one embodiment, after the step of invoking the context relationship analysis strategy to analyze the fault and obtain the context information of the fault, the method further includes:

[0015] An error log is generated based on the fault information and the context information, and the system is optimized using the error log.

[0016] The steps of performing a soft reset on the system, restarting the system, and storing the fault information and the context information further include:

[0017] Perform a soft reset on the system, restart the system, and store the error log.

[0018] In one embodiment, the step of determining the target analysis strategy as a context relationship analysis strategy when the fault is an operating system fault, and calling the context relationship analysis strategy to analyze the fault and obtain the context information of the fault, includes:

[0019] When the fault is an operating system fault, the target analysis strategy is determined to be the context relationship analysis strategy. The context relationship analysis strategy is called to read the depth of the traceable context and read the context pointer in the register.

[0020] When the depth is not a first preset value, the address information corresponding to the context pointer is stored;

[0021] When the depth reaches the first preset value, the context information of the fault is generated based on the stored address information.

[0022] In one embodiment, the step of determining a target analysis strategy based on the fault type to analyze and handle the fault includes:

[0023] When the fault is an abnormal interruption fault, the target analysis strategy is determined to be the abnormal interruption analysis strategy;

[0024] The exception interrupt analysis strategy is invoked to obtain the interrupt vector number, exception address, machine state, and stack frame content of the exception interrupt fault;

[0025] After isolation is completed, a soft reset operation is performed on the system to restart the system and store the fault information, interrupt vector number, exception address, machine state, and stack frame content of the abnormal interrupt fault.

[0026] In one embodiment, the step of determining a target analysis strategy based on the fault type to analyze and handle the fault includes:

[0027] When the fault is an error tracing type fault, the target analysis strategy is determined to be an error tracing analysis strategy;

[0028] The error tracing and analysis strategy is invoked to store the fault information of the error tracing type fault, and the fault handling process is terminated.

[0029] In one embodiment, after the step of determining the target analysis strategy based on the fault type to analyze and handle the fault, the method further includes:

[0030] The corresponding fault light will illuminate based on the fault type to prompt the user to perform fault detection.

[0031] Furthermore, to achieve the above objectives, the present invention also proposes an automotive fault detection device, the device comprising:

[0032] The information acquisition module is used to acquire fault information when a fault is detected.

[0033] The fault determination module is used to determine the fault type corresponding to the fault based on the fault information, wherein the fault type includes operating system fault, abnormal interruption fault and error tracking type fault.

[0034] The fault handling module is used to determine the target analysis strategy based on the fault type to analyze and handle the fault.

[0035] Furthermore, to achieve the above objectives, the present invention also proposes an automotive fault detection device, the device comprising: a memory, a processor, and an automotive fault detection program stored in the memory and executable on the processor, the automotive fault detection program being configured to implement the steps of the automotive fault detection method as described above.

[0036] In addition, to achieve the above objectives, the present invention also proposes a storage medium storing an automotive fault detection program, which, when executed by a processor, implements the steps of the automotive fault detection method as described above.

[0037] One or more technical solutions proposed in this application have at least the following technical effects:

[0038] When a fault is detected, fault information is acquired; based on the fault information, the corresponding fault type is determined, including operating system faults, abnormal interruption faults, and error tracing faults; based on the fault type, a target analysis strategy is determined to analyze and handle the fault, quickly locate the fault status information, and ensure the stable operation of the automotive software system and driving safety. Attached Figure Description

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

[0040] To more clearly illustrate the technical solutions in the embodiments of this application 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.

[0041] Figure 1 This is a flowchart illustrating an embodiment of the vehicle fault detection method of this application.

[0042] Figure 2 This is a flowchart of the fault light activation process provided in Embodiment 1 of the vehicle fault detection method of this application;

[0043] Figure 3 This is a flowchart of the processing steps provided in Embodiment 1 of the vehicle fault detection method of this application;

[0044] Figure 4 This is a flowchart illustrating Embodiment 2 of the vehicle fault detection method of this application;

[0045] Figure 5 This is a flowchart illustrating the context analysis of the second embodiment of the vehicle fault detection method of this application.

[0046] Figure 6 This is a flowchart illustrating Embodiment 3 of the vehicle fault detection method of this application;

[0047] Figure 7 This is a schematic diagram of the module structure of the vehicle fault detection device according to an embodiment of this application;

[0048] Figure 8 This is a schematic diagram of the hardware operating environment of the vehicle fault detection method in this application embodiment.

[0049] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0050] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0051] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0052] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or automotive fault detection device capable of performing the above functions. The following description uses an automotive fault detection device as an example to illustrate this embodiment and the subsequent embodiments.

[0053] Based on this, embodiments of this application provide a method for detecting automotive faults, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the vehicle fault detection method of this application.

[0054] In this embodiment, the vehicle fault detection method includes steps S10 to S30:

[0055] Step S10: When a fault is detected, obtain fault information;

[0056] It should be noted that this strategy is applied to an automotive software fault monitoring and real-time alarm system. The system monitors the software's operating status in real time. When a fault is detected, it categorizes the fault type and then transfers it to the fault handling center for processing. The fault handling center processes the faults according to their types, stores the data and on-site information after processing, and then reports the fault information to the diagnostic module. The diagnostic module then provides appropriate reminders to the user by illuminating fault lights or other means.

[0057] It should be understood that the fault information is a union, defined as shown in the table below:

[0058] Table 1

[0059] Fault type ID information Operating system fault structure (including error type, passed parameters, and context information) An exception interrupt structure (including the interrupt vector, input parameters, and context information). Other fault structures (including module ID, input parameters, and context information)

[0060] Taking operating system failure as an example, the corresponding structure definitions are shown in Table 2 below:

[0061] Table 2

[0062] Operating system fault structure Fault ID Service ID Operating system records fault parameters Fault status Context address array

[0063] When a fault occurs, the corresponding information will be written into the corresponding element of the structure. The context address is an array to store the backtracking address information.

[0064] In practice, the system monitors fault information in real time during operation. If a fault is detected, the system will read the information at the time of the fault.

[0065] Step S20: Determine the fault type corresponding to the fault based on the fault information, where the fault type includes operating system fault, abnormal interruption fault, and error tracking type fault;

[0066] It should be noted that other faults in the union table are error tracking faults.

[0067] In embedded software systems, the real-time operating system (RTOS) is crucial for the accurate execution and efficient scheduling of tasks. When the system encounters abnormal situations such as stack overflow or excessive CPU load causing frequent task re-entry, the operating system will report these operating system faults to inform the system to handle them, ensuring the stability and reliability of the system.

[0068] When embedded systems encounter abnormal situations such as non-maskable interrupts, instruction execution errors, or memory access violations, they will immediately trigger specific types of exception interrupts. Each exception interrupt is designed to have its own unique entry point, ensuring that the system can accurately jump to the corresponding interrupt service routine (ISR) to handle the exception interrupt fault when an exception is detected.

[0069] Error tracking faults refer to fault information that occurs during software operation and does not affect functionality or safety, such as error information that occurs during the operation of basic software programs. In this case, the software will not be reset, but only the data and information at the scene will be stored.

[0070] Step S30: Determine the target analysis strategy based on the fault type to analyze and handle the fault.

[0071] It should be noted that once the type of fault is determined, the next step is to select a targeted analysis strategy to collect data and information.

[0072] It should be understood that target analysis strategies may include contextual analysis strategies, exception interruption analysis strategies, and error tracing analysis strategies.

[0073] In practice, specific analysis methods are selected and implemented to diagnose problems based on different fault characteristics or categories, and corresponding measures are taken to resolve the faults.

[0074] Furthermore, after step S30, the method further includes:

[0075] The corresponding fault light is illuminated based on the fault type to prompt the user to perform fault detection.

[0076] It should be noted that the fault handling center will periodically read fault information, analyze the fault, and if the corresponding fault flag is set, the fault will be managed through diagnostic event management, and then the corresponding fault light will be lit to prompt the user to perform fault detection.

[0077] like Figure 2As shown, the software monitoring module periodically reads fault information to determine if a fault has occurred. If so, the fault is analyzed, and different fault reports are sent to the diagnostic event module. Then, the diagnostic event module illuminates the fault light according to the type of fault.

[0078] In the actual implementation, the fault information is reported to the diagnostic module, which then provides corresponding reminders to the user by illuminating fault lights or other means.

[0079] like Figure 3 As shown, Figure 3 To process the flowchart, the system first enters the running and monitoring state. When an anomaly is detected, the fault type is determined, including operating system faults, software anomalies, and other types of faults. The status and related information at the time of the fault are read, and then the stack backtracking process is entered to read the function call relationship. Then, data is assigned and the output of key devices is turned off. The data is then written to the NOINITRAM area and a soft reset is performed. After re-initialization, the fault information is read and stored, and the fault is reported to the alarm module. The fault alarm module classifies and judges the fault, issues an alarm, and performs function degradation processing.

[0080] Not only is the detection accuracy high, but it can also accurately locate the software's position when a fault occurs. Even if a fault occurs during vehicle operation, it can be saved and traced back. At the same time, there is an alarm system to remind users to check the relevant control system.

[0081] This embodiment provides a vehicle fault detection method that integrates online fault monitoring, in-depth data analysis, and intelligent processing mechanisms, supplemented by efficient data storage and flexible retrieval functions, constructing a comprehensive and systematic solution. This solution aims to monitor bottlenecks in existing software security guarantees, quickly locate fault status information, and ensure the stable operation of the vehicle software system and driving safety.

[0082] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 Step S30, the vehicle fault detection method includes steps S301 to S303:

[0083] Step S301: When the fault is an operating system fault, the target analysis strategy is determined to be the context relationship analysis strategy. The context relationship analysis strategy is called to analyze the fault and obtain the context information of the fault.

[0084] It is important to note that in embedded software systems, the real-time operating system (RTOS) is crucial for the accurate execution and efficient scheduling of tasks. When the system encounters abnormal situations such as stack overflows or excessive CPU load causing frequent task re-entry, the operating system will report these faults to inform the system to handle them, ensuring the stability and reliability of the system.

[0085] When the system detects anomalies such as stack overflow or CPU overload, the RTOS immediately triggers the fault hook function. This function is designed to respond quickly and make an initial assessment of the nature of the fault, at which point it can be determined that the fault is an operating system failure.

[0086] In the fault hook function, critical data is first read for protection, including but not limited to fault type identifiers and the CPU register state at the time of the exception (especially the program counter, used to locate the address of the exception instruction or the address of the next instruction after the interrupt). Additionally, a system state snapshot may be collected for subsequent analysis.

[0087] It should be understood that all of the above data can be stored in the fault information for subsequent analysis.

[0088] In practical implementation, the function call context analysis strategy utilizes stack backtracking principles to deeply analyze the function call context at the time of the failure, tracing the specific function call path that led to the failure. This process is crucial for locating the root cause of the problem and optimizing software design. The backtracking results are recorded in detail as part of the error log.

[0089] Further, step S301 includes:

[0090] When the fault is an operating system fault, the target analysis strategy is determined to be the context relationship analysis strategy. The context relationship analysis strategy is called to read the depth of the traceable context and read the context pointer in the register.

[0091] When the depth is not the first preset value, the address information corresponding to the context pointer is stored;

[0092] When the depth reaches the first preset value, fault context information is generated based on the stored address information.

[0093] It should be noted that if a fault occurs during vehicle operation, acquiring or saving fault information is crucial for subsequent problem analysis for embedded systems. Fault stack trace mainly records the address at the time of the fault occurrence and the address information of the preceding function call, so as to quickly find and locate the fault.

[0094] The principle of context relationship analysis is to use the rules of function calls and the mechanism of context switching. Context switching refers to the need to save some information, such as register information and system state, before the program calls a subroutine. Under normal circumstances, this information will be stored in the stack. However, in some chips of embedded systems, the chip will allocate a part of the area to store this content in order to improve memory utilization efficiency and real-time performance.

[0095] In practical implementation, context information backtracking mainly relies on the principle of stack allocation during function calls to find the hierarchical relationship of function calls when an exception occurs. When a function is called, the process of saving its context is as follows:

[0096] 1. Push the address of the next instruction onto the stack and call the function.

[0097] 2. Save the current stack bottom pointer.

[0098] 3. Preserve the scene.

[0099] In a typical chip, there is a register used to store a linked list pointer, which points to the last saved context segment, that is, the top of the call stack.

[0100] When a fault occurs, it is necessary to backtrack the context information. First, read the depth of the backtrackable context, then read the context pointer of the register, check if the depth is 0, read the corresponding address information from the pointer, and save the corresponding address information to the corresponding array. This process is repeated until the depth is 0. The corresponding flowchart is as follows. Figure 5 As shown.

[0101] Furthermore, after step S301, the method further includes:

[0102] Error logs are generated based on fault information and context information, and the system is optimized using these error logs.

[0103] The steps of performing a soft reset on the system, restarting the system, and storing fault information and context information also include:

[0104] Perform a soft reset on the system, restart the system, and store the error log.

[0105] In the implementation, the collected fault information, context information, and system state snapshots are integrated into a detailed error log. These logs are of great value for subsequent problem analysis, system maintenance, and potential software upgrades.

[0106] Step S302: Determine the fault range based on fault information and context information, and isolate the devices within the fault range;

[0107] It's important to note that analyzing fault information and contextual information helps determine the scope of system components or services that the fault may affect. This could involve a single hardware component, software module, network connection, or the entire system. Once the scope of the fault is determined, the next step is to isolate the affected devices or components from the system. This may include shutting down or disabling specific hardware devices, stopping or uninstalling the problematic software service or application, and, at the network level, blocking connections to the faulty component.

[0108] In practice, to prevent the fault from spreading further, the system will automatically shut down or isolate affected output devices, peripheral interfaces, and other critical resources. Simultaneously, it will ensure the security of core data and services, preventing data corruption or leakage.

[0109] Step S303: After isolation is completed, perform a soft reset on the system, restart the system, and store the fault information and context information.

[0110] It should be noted that developers can read the fault data at the moment the fault occurred from the saved data, parse the data, and accurately locate the location of the fault.

[0111] It should be understood that a soft reset is a reboot method that does not involve powering off the hardware; it restarts the operating system via software commands. A soft reset terminates all running processes and reinitializes system services and applications. During a soft reset, the system shuts down all services and applications, clears all data from memory, and then reloads the system's core components and drivers to begin the system boot process. Fault information and context information can be stored on non-volatile storage media, such as hard drives, solid-state drives, or dedicated log servers, to ensure that this information remains available after the system reboots.

[0112] In practice, after completing the above steps, the system performs a soft reset. A soft reset aims to restart the system using software while preserving necessary configuration and state information, allowing the system to restart in a more stable state. After the reset, the system should be able to return to a known safe or initial state and attempt to resume tasks.

[0113] This embodiment provides a method for detecting automotive faults. When an operating system malfunctions, the target analysis strategy is determined to be a contextual analysis strategy. Detailed contextual information about the fault is collected and analyzed to identify the root cause of the fault. Corresponding measures are then taken to restore the system to normal operation and prevent future faults from occurring.

[0114] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 6 Step S30, the vehicle fault detection method further includes steps S310 to S330:

[0115] Step S310: When the fault is an abnormal interruption fault, determine the target analysis strategy as the abnormal interruption analysis strategy;

[0116] It should be noted that embedded systems will immediately trigger specific types of exception interrupts when faced with abnormal situations such as non-maskable interrupts, instruction execution errors, and memory access violations. Each exception interrupt is designed to have its own unique entry point, ensuring that the system can accurately jump to the corresponding interrupt service routine (ISR) for processing when an exception interrupt fault is detected.

[0117] The interrupt handling process automatically selects and executes the appropriate interrupt handler function based on different interrupt vector numbers (a unique code that identifies a specific interrupt type). This process not only improves the efficiency of exception handling but also enhances the system's response speed and stability.

[0118] Step S320: Invoke the exception interrupt analysis strategy to obtain the interrupt vector number, exception address, machine state, and stack frame content of the exception interrupt fault;

[0119] In the actual implementation, the system records detailed information about the exception event in the interrupt handling service function, including but not limited to the interrupt vector number, the exact address where the exception occurred, the CPU machine state (such as register values), and the current stack frame content.

[0120] Step S330: After isolation is completed, perform a soft reset on the system, restart the system, and store the fault information, interrupt vector number of the abnormal interrupt fault, abnormal address, machine state, and stack frame content.

[0121] In practice, after collecting and recording anomaly information, the system typically performs a soft reset. A soft reset aims to safely restart the system using software, while preserving as much critical configuration and state information as possible, so that the system can quickly recover to a stable and predictable state after restarting. This step helps reduce system downtime and protect data integrity.

[0122] Furthermore, when the fault is an error tracing type fault, the target analysis strategy is determined to be an error tracing analysis strategy;

[0123] Invoke the error tracing and analysis strategy to store the fault information of the error tracing type fault, and then terminate the fault handling process.

[0124] It should be noted that error tracking faults refer to some fault information that does not affect functionality and safety during software operation, such as some error information that occurs during the operation of basic software programs. In this case, the software will not be reset, but only the data and information at the scene will be stored.

[0125] It should be understood that there are three types of faults involving the basic software in this system: the first is operating system faults, the second is abnormal interruption faults, and the third is error tracking faults, which are the fault information monitored by the standard AUTOSAR module DET (Diagnostic Fault Tracking Module). When each type of fault occurs, it will be processed in different functions, the fault information will be extracted, written into the corresponding structure, and then proceed to the next step of processing.

[0126] This embodiment provides a vehicle fault detection method. By judging and handling abnormal interruption faults and error tracking faults, it focuses on collecting, analyzing and storing error-related information so as to effectively identify the root cause of the fault and take corresponding repair measures, quickly locate the fault status information, and ensure the stable operation of the vehicle software system and driving safety.

[0127] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the vehicle fault detection method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0128] This application also provides an automotive fault detection device; please refer to... Figure 7 The vehicle fault detection device includes:

[0129] The information acquisition module 10 is used to acquire fault information when a fault is detected.

[0130] The fault determination module 20 is used to determine the fault type corresponding to the fault based on the fault information, including operating system faults, abnormal interruption faults, and error tracking faults.

[0131] The fault handling module 30 is used to determine the target analysis strategy based on the fault type to analyze and handle the fault.

[0132] The vehicle fault detection device provided in this application, employing the vehicle fault detection method in the above embodiments, can solve the technical problem of being unable to quickly and accurately locate the root cause of a fault. Compared with the prior art, the beneficial effects of the vehicle fault detection device provided in this application are the same as those of the vehicle fault detection method provided in the above embodiments, and other technical features in the vehicle fault detection device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0133] In one embodiment, the fault handling module 30 is further configured to, when the fault is an operating system fault, determine the target analysis strategy as a context relationship analysis strategy, call the context relationship analysis strategy to analyze the fault, and obtain the context information of the fault;

[0134] Based on the fault information and the context information, the fault range is determined, and the devices within the fault range are isolated.

[0135] After isolation is completed, a soft reset is performed on the system, the system is restarted, and the fault information and the context information are stored.

[0136] In one embodiment, the fault handling module 30 is further configured to generate an error log based on the fault information and the context information, and optimize the system using the error log;

[0137] The steps of performing a soft reset on the system, restarting the system, and storing the fault information and the context information further include:

[0138] Perform a soft reset on the system, restart the system, and store the error log.

[0139] In one embodiment, the fault handling module 30 is further configured to, when the fault is an operating system fault, determine the target analysis strategy as a context relationship analysis strategy, call the context relationship analysis strategy to read the depth of the traceable context, and read the context pointer in the register;

[0140] When the depth is not a first preset value, the address information corresponding to the context pointer is stored;

[0141] When the depth reaches the first preset value, the context information of the fault is generated based on the stored address information.

[0142] In one embodiment, the fault handling module 30 is further configured to determine the target analysis strategy as an abnormal interruption analysis strategy when the fault is an abnormal interruption fault.

[0143] The exception interrupt analysis strategy is invoked to obtain the interrupt vector number, exception address, machine state, and stack frame content of the exception interrupt fault;

[0144] After isolation is completed, a soft reset operation is performed on the system to restart the system and store the fault information, interrupt vector number, exception address, machine state, and stack frame content of the abnormal interrupt fault.

[0145] In one embodiment, the fault handling module 30 is further configured to determine the target analysis strategy as an error tracking analysis strategy when the fault is an error tracking type fault;

[0146] The error tracing and analysis strategy is invoked to store the fault information of the error tracing type fault, and the fault handling process is terminated.

[0147] In one embodiment, the fault handling module 30 is further configured to illuminate the corresponding fault light based on the fault type to prompt the user to perform fault detection.

[0148] This application provides an automotive fault detection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the automotive fault detection method in Embodiment 1 above.

[0149] The following is for reference. Figure 8 This document illustrates a structural schematic diagram of an automotive fault detection device suitable for implementing embodiments of this application. The automotive fault detection device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The illustrated vehicle fault detection device is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of this application.

[0150] like Figure 8As shown, the automotive fault detection device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the automotive fault detection device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the vehicle fault detection equipment to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a vehicle fault detection equipment with various systems, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0151] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0152] The automotive fault detection device provided in this application, employing the automotive fault detection method described in the above embodiments, can solve the technical problem of being unable to quickly and accurately locate the root cause of a fault. Compared with the prior art, the beneficial effects of the automotive fault detection device provided in this application are the same as those of the automotive fault detection method provided in the above embodiments, and other technical features of this automotive fault detection device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0153] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0154] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0155] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the vehicle fault detection method in the above embodiments.

[0156] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0157] The aforementioned computer-readable storage medium may be included in the automotive fault detection equipment; or it may exist independently and not be installed in the automotive fault detection equipment.

[0158] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the automotive fault detection device, the automotive fault detection device: when a fault is detected, acquires fault information; determines the fault type corresponding to the fault based on the fault information, wherein the fault type includes operating system faults, abnormal interruption faults, and error tracing faults; and determines a target analysis strategy based on the fault type to analyze and handle the fault.

[0159] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0161] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0162] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described vehicle fault detection method, thereby solving the technical problem of being unable to quickly and accurately locate the root cause of a fault. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the vehicle fault detection method provided in the above embodiments, and will not be repeated here.

[0163] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the automobile fault detection method described above.

[0164] The computer program product provided in this application can solve the technical problem of being unable to quickly and accurately locate the root cause of a fault. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the automobile fault detection method provided in the above embodiments, and will not be repeated here.

[0165] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for detecting automotive faults, characterized in that, The vehicle fault detection method includes the following steps: When a fault is detected, obtain fault information; Based on the fault information, the fault type corresponding to the fault is determined, wherein the fault type includes operating system fault, abnormal interruption fault, and error tracking type fault. Based on the fault type, a target analysis strategy is determined to analyze and handle the fault. When the fault is an operating system fault, the target analysis strategy is determined to be the context relationship analysis strategy, and the context relationship analysis strategy is invoked to analyze the fault and obtain the context information of the fault. Based on the fault information and the context information, the fault range is determined, and the devices within the fault range are isolated. After isolation is completed, a soft reset operation is performed on the system, the system is restarted, and the fault information and the context information are stored. When the fault is an operating system fault, the target analysis strategy is determined to be the context relationship analysis strategy. The context relationship analysis strategy is called to read the depth of the traceable context and read the context pointer in the register. When the depth is not a first preset value, the address information corresponding to the context pointer is stored; When the depth reaches the first preset value, the context information of the fault is generated based on the stored address information; When the fault is an abnormal interruption fault, the target analysis strategy is determined to be the abnormal interruption analysis strategy; The exception interrupt analysis strategy is invoked to obtain the interrupt vector number, exception address, machine state, and stack frame content of the exception interrupt fault; After isolation is completed, a soft reset operation is performed on the system, the system is restarted, and the fault information, interrupt vector number, exception address, machine state, and stack frame content of the abnormal interrupt fault are stored. When the fault is an error tracing type fault, the target analysis strategy is determined to be an error tracing analysis strategy; The error tracing and analysis strategy is invoked to store the fault information of the error tracing type fault, and the fault handling process is terminated.

2. The vehicle fault detection method as described in claim 1, characterized in that, After the step of invoking the context relationship analysis strategy to analyze the fault and obtain the context information of the fault, the method further includes: An error log is generated based on the fault information and the context information, and the system is optimized using the error log. The steps of performing a soft reset on the system, restarting the system, and storing the fault information and the context information further include: Perform a soft reset on the system, restart the system, and store the error log.

3. The vehicle fault detection method as described in any one of claims 1 to 2, characterized in that, After the step of determining the target analysis strategy based on the fault type to analyze and handle the fault, the method further includes: The corresponding fault light will illuminate based on the fault type to prompt the user to perform fault detection.

4. A vehicle fault detection device, characterized in that, The device includes: The information acquisition module is used to acquire fault information when a fault is detected. The fault determination module is used to determine the fault type corresponding to the fault based on the fault information, wherein the fault type includes operating system fault, abnormal interruption fault and error tracking type fault. The fault handling module is used to determine the target analysis strategy based on the fault type to analyze and handle the fault. The fault handling module is also used to determine the target analysis strategy as the context relationship analysis strategy when the fault is an operating system fault, and to call the context relationship analysis strategy to analyze the fault and obtain the context information of the fault. Based on the fault information and the context information, the fault range is determined, and the devices within the fault range are isolated. After isolation is completed, a soft reset operation is performed on the system, the system is restarted, and the fault information and the context information are stored. The fault handling module is also used to determine the target analysis strategy as the context relationship analysis strategy when the fault is an operating system fault, call the context relationship analysis strategy to read the depth of the traceable context, and read the context pointer in the register; When the depth is not a first preset value, the address information corresponding to the context pointer is stored; When the depth reaches the first preset value, the context information of the fault is generated based on the stored address information; The fault handling module is also used to determine the target analysis strategy as the abnormal interruption analysis strategy when the fault is an abnormal interruption fault. The exception interrupt analysis strategy is invoked to obtain the interrupt vector number, exception address, machine state, and stack frame content of the exception interrupt fault; After isolation is completed, a soft reset operation is performed on the system, the system is restarted, and the fault information, interrupt vector number, exception address, machine state, and stack frame content of the abnormal interrupt fault are stored. The fault handling module is also used to determine the target analysis strategy as an error tracking analysis strategy when the fault is an error tracking type fault; The error tracing and analysis strategy is invoked to store the fault information of the error tracing type fault, and the fault handling process is terminated.

5. A vehicle fault detection device, characterized in that, The device includes: a memory, a processor, and an automotive fault detection program stored in the memory and executable on the processor, the automotive fault detection program being configured to implement the steps of the automotive fault detection method as described in any one of claims 1 to 3.

6. A storage medium, characterized in that, The storage medium stores a vehicle fault detection program, which, when executed by a processor, implements the steps of the vehicle fault detection method as described in any one of claims 1 to 3.

Images