Method, device, electronic device, and storage medium for determining fault handling method

Abstract

This application provides a method, apparatus, electronic device, and storage medium for determining a fault handling method, relating to the field of vehicle technology. The method includes: in response to receiving an abnormal signal from a target controller, determining whether to perform fault detection on the target controller; if it is determined that fault detection of the target controller is necessary, determining fault information of the target controller; the fault information includes a fault type and a corresponding fault level; and determining a fault handling method for the target controller based on the fault information. This improves the efficiency of fault handling.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a method, apparatus, electronic device, and storage medium for determining a fault handling method. Background Technology

[0002] In recent years, with the continuous development of the vehicle industry, on the one hand, the degree of electrification and electronicization has been continuously improving, and hardware platforms have become more diversified; on the other hand, the demand for safety has also been gradually increasing.

[0003] Existing technology can determine and confirm faults by judging whether the fault signal exceeds the set threshold and whether the number of valid faults is greater than the preset threshold. Then, it determines whether to shut off the pipe. If so, the torque is directly set to zero; otherwise, the torque value after power output is processed according to the slope.

[0004] In some scenarios, vehicles may be affected by other factors, which may cause false fault alarms. As a result, once a fault signal is detected, fault detection is required, leading to frequent fault diagnosis and affecting the user experience. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and storage medium for determining fault handling methods, which reduces the frequency of fault detection and improves user experience.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] According to the first aspect of this application, a method for determining a fault handling method is provided, the method comprising:

[0008] In response to receiving an abnormal signal from the target controller, determine whether to perform fault detection on the target controller; if it is determined that fault detection on the target controller is required, determine the fault information of the target controller; the fault information includes the fault type and the fault level corresponding to the fault type; based on the fault information of the target controller, determine the fault handling method of the target controller.

[0009] Based on the above technical means, this application can determine whether to perform fault detection on the target controller based on the received abnormal signal from the target controller, which reduces the possibility of false fault alarms due to other reasons, reduces the frequency of fault diagnosis, and improves the user experience.

[0010] In one possible implementation, in response to an abnormal signal from the target controller, it is detected whether the target controller meets the detection conditions; if the target controller meets the detection conditions, it is determined that fault detection needs to be performed on the target controller; if the target controller does not meet the detection conditions, it is determined that fault detection does not need to be performed on the target controller.

[0011] Using the aforementioned technical methods, faults that do not meet the testing conditions can be eliminated, allowing inspection only for potential faults. This improves testing efficiency and reduces unnecessary testing time and resource consumption.

[0012] In one possible implementation, the detection conditions include: a reset condition and / or a detection enable condition; wherein the reset condition includes: performing a diagnostic service reset operation and / or a KL15 reset operation; and the detection enable condition is used to trigger the target controller to perform a fault detection operation.

[0013] Based on the aforementioned technical methods, the detection conditions for fault detection are enriched, the possibility of false positives and false negatives is reduced, and the accuracy of fault detection is improved. Reset operations can resolve and eliminate some simple faults, avoiding the repetition of subsequent steps and improving resource utilization. The settings for detection enable conditions can be adjusted and optimized according to actual needs to adapt to the fault detection requirements of different equipment and operating conditions, increasing flexibility and adaptability.

[0014] In one possible implementation, if the target controller meets a preset fault condition, it is determined that the target controller has failed, and the fault information of the target controller is determined.

[0015] Based on the above technical means, the determination of fault type in fault detection can be more accurate by preset fault conditions.

[0016] In one possible implementation, the preset fault conditions include at least one of the following: the target controller's hardware malfunctions; the target controller's operating state is the target control state, and the target controller's operating parameters do not match the parameters corresponding to the target control state; the target controller's operating parameters are greater than a preset threshold; the error between the target controller's operating parameters and preset parameters is greater than a preset difference; the preset parameters are the operating parameters of the target controller during normal operation; the number of times the target controller generates abnormal signals is greater than a preset number; and the fault duration of the target controller is greater than a preset duration.

[0017] Based on the above technical means, preset parameters such as preset operating parameters, preset time, and preset number of times are used to determine whether the target controller's operating status has malfunctioned, thereby improving the accuracy of fault diagnosis and enhancing system stability.

[0018] In one possible implementation, if the duration of the abnormal signal exceeds a first preset duration, the target controller is determined to be faulty.

[0019] Based on the above technical means, this application can determine whether the target controller has actually malfunctioned by using a first preset time period, and can eliminate erroneous fault judgments made due to brief anomalies.

[0020] In one possible implementation, if it is determined that the abnormal signal is not masked, fault detection is performed on the target controller in response to the abnormal signal. If the abnormal signal is masked, it is determined that fault detection of the target controller is not required.

[0021] Based on the above technical means, pre-set blocked abnormal signals can be eliminated, reducing unnecessary detection time and resource consumption.

[0022] In one possible implementation, in response to a setting operation, the value of a flag bit of an abnormal signal is determined; wherein, if the flag bit of the abnormal signal is a first identifier, the abnormal signal is masked; if the flag bit of the abnormal signal is a second identifier, the abnormal signal is not masked; the first identifier and the second identifier are different.

[0023] Based on the above technical means, this application can determine whether the abnormal signal is shielded by preset flag bits, thereby reducing the repetition of subsequent fault diagnosis processes and making the determination of fault handling methods more efficient.

[0024] In one possible implementation, when the fault type of the target controller is a hardware fault, the target controller is controlled to perform a fault latching operation; the fault latching operation includes: performing a reset operation when a fault is detected; and latching the fault if the number of reset operations exceeds a preset number.

[0025] Based on the above technical means, this application can handle hardware faults through fault latching and retry operations, reducing misdiagnosis and missed diagnosis. The latching operation can retain fault error information, providing a basis for subsequent fault analysis and processing.

[0026] According to a second aspect of this application, a determining device is provided, comprising:

[0027] The determination unit is used to determine whether to perform fault detection on the target controller in response to receiving an abnormal signal from the target controller;

[0028] The determining unit is also used to determine, when it is determined that fault detection of the target controller is required, to obtain fault information of the target controller; the fault information includes the fault type and the fault level corresponding to the fault type;

[0029] The determination unit is also used to determine the fault handling method of the target controller based on the fault information of the target controller.

[0030] In one possible implementation, the determining device further includes a checking unit. The checking unit is configured to detect whether the target controller meets the detection conditions in response to an abnormal signal from the target controller; the determining unit is further configured to determine that fault detection needs to be performed on the target controller if the target controller meets the detection conditions; and the determining unit is further configured to determine that fault detection does not need to be performed on the target controller if the target controller does not meet the detection conditions.

[0031] In one possible implementation, the reset conditions include: performing a diagnostic service reset operation and / or a KL15 reset operation; and a detection enable condition is used to trigger the target controller to perform a fault detection operation.

[0032] In one possible implementation, the determining unit is further configured to determine that the target controller has failed if the target controller meets preset fault conditions, and to determine the fault information of the target controller.

[0033] In one possible implementation, the preset fault conditions include at least one of the following: the target controller's hardware malfunctions; the target controller's operating state is the target control state, and the target controller's operating parameters do not match the parameters corresponding to the target control state; the target controller's operating parameters are greater than a preset threshold; the error between the target controller's operating parameters and preset parameters is greater than a preset difference; the preset parameters are the operating parameters of the target controller during normal operation; the number of times the target controller generates abnormal signals is greater than a preset number; and the fault duration of the target controller is greater than a preset duration.

[0034] In one possible implementation, the determining unit is further configured to determine a target controller fault if the duration of the abnormal signal exceeds a first preset duration.

[0035] In one possible implementation, the determining unit is further configured to determine, in response to an abnormal signal from the target controller, to perform fault detection on the target controller if the abnormal signal is not masked; the determining unit is further configured to determine, if the abnormal signal is masked, that fault detection on the target controller is not required.

[0036] In one possible implementation, the determining unit is further configured to determine the value of a flag bit of an abnormal signal in response to a setting operation; wherein, when the flag bit of the abnormal signal is a first identifier, the abnormal signal is masked; when the flag bit of the abnormal signal is a second identifier, the abnormal signal is not masked; the first identifier is different from the second identifier.

[0037] In one possible implementation, the determining unit is further configured to control the target controller to perform a fault latching operation when the fault type of the target controller is a hardware fault; the fault latching operation includes: performing a reset operation when a fault is detected; and latching the fault if the number of reset operations exceeds a preset number.

[0038] According to a third aspect of this application, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement the method of the first aspect described above and any possible implementation thereof.

[0039] According to a fourth aspect of this application, a computer-readable storage medium is provided, which, when executed by a processor of an electronic device, enables the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0040] According to the fifth aspect of this application, a computer program product is provided, the computer program product including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect and any possible implementation thereof.

[0041] According to the sixth aspect of this application, a vehicle has a device for determining a fault handling method.

[0042] Therefore, the above-mentioned technical features of this application have the following beneficial effects:

[0043] (1) Based on the above technical means, this application can determine whether to perform fault detection on the target controller based on the received abnormal signal from the target controller, which reduces the possibility of false fault alarms due to other reasons, reduces the frequency of fault diagnosis, and improves user experience.

[0044] (2) Based on the above technical means, fault items that do not meet the detection conditions can be eliminated, and only possible fault situations can be checked. This improves detection efficiency and reduces unnecessary detection time and resource consumption.

[0045] (3) Based on the above technical means, the detection conditions for fault detection are enriched, the possibility of false positives and false negatives is reduced, and the accuracy of fault detection is improved. A reset operation can resolve and eliminate some simple faults, avoiding the repetition of subsequent steps and improving resource utilization. The setting of detection enable conditions can be adjusted and optimized according to actual needs to adapt to the fault detection requirements of different equipment and under different operating conditions, increasing flexibility and adaptability.

[0046] (4) Based on the above technical means, the fault type can be more accurately determined by pre-setting fault conditions.

[0047] (5) Based on the above technical means, preset parameters such as preset operating parameters, preset time, and preset number of times are used to judge whether the target controller's operating status has a fault, thereby improving the accuracy of fault diagnosis and enhancing system stability.

[0048] (6) Based on the above technical means, this application can determine whether the target controller has actually malfunctioned by using the first preset time period, and can eliminate the wrong fault judgment made due to a brief abnormality.

[0049] (7) Based on the above technical means, pre-set shielded abnormal signals can be eliminated, reducing unnecessary detection time and resource consumption.

[0050] (8) Based on the above technical means, this application can determine whether the abnormal signal is shielded by setting a flag bit, thereby reducing the repetition of subsequent fault diagnosis process and making the determination of fault handling method more efficient.

[0051] (9) Based on the above technical means, this application can handle hardware faults through fault latching and retry operation, reduce misdiagnosis and missed diagnosis. The latching operation can retain fault error information and provide a basis for subsequent fault analysis and processing. Attached Figure Description

[0052] 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, and do not constitute an undue limitation of this application.

[0053] Figure 1 A schematic diagram illustrating a method for determining a fault handling mode provided in an embodiment of this application;

[0054] Figure 2 A schematic diagram illustrating a periodic fault diagnosis provided in an embodiment of this application;

[0055] Figure 3 A flowchart illustrating a method for determining a fault handling mode provided in an embodiment of this application;

[0056] Figure 4 A schematic diagram illustrating a fault diagnosis provided in an embodiment of this application;

[0057] Figure 5 A schematic diagram illustrating a fault confirmation method provided in an embodiment of this application;

[0058] Figure 6 This is a schematic diagram illustrating a fault confirmation delay provided in an embodiment of this application;

[0059] Figure 7 This is a schematic diagram illustrating a fault recovery delay provided in an embodiment of this application;

[0060] Figure 8 A schematic diagram of a fault latch retry process provided in an embodiment of this application;

[0061] Figure 9 A block diagram of a determining device provided in an embodiment of this application;

[0062] Figure 10 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0063] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0064] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0065] First, a brief introduction to the application scenarios involved in this application will be given.

[0066] In the automotive field, the motor controller, as a core component of the electric vehicle's powertrain system, directly affects vehicle performance and safety due to its stability and reliability. Therefore, the detection and handling of motor controller faults are extremely important. To ensure normal vehicle operation, improve maintenance efficiency, and enhance user experience, the requirements for motor controller fault detection and handling have also significantly increased.

[0067] Related technologies can classify all faults by time period. Fault judgment and confirmation are achieved by judging whether the fault signal exceeds a set threshold and whether the number of valid faults exceeds a preset threshold. Then, it is determined whether to shut down the pipe. If so, the torque is directly set to zero; otherwise, the torque value after power reduction is processed according to the slope. Although this method designs a protection mechanism for a single fault item and a fixed judgment process for input conditions, it ensures that it can be configured by software later.

[0068] However, the relevant technology has the following drawbacks: Fault diagnosis coverage is not comprehensive enough; this method is only applicable to threshold-based fault diagnosis and does not consider other fault types such as hardware faults. The fault judgment process is too simplistic, failing to consider other fault diagnosis-related functions such as fault clearing and reset functions, and not taking into account potential false fault alarms caused by other factors affecting the vehicle. Fault handling is too simplistic and crude, only including two methods: directly setting torque to zero and reducing power output according to the slope.

[0069] To address the aforementioned issues, this application provides a method for determining a fault handling method. The method includes: in response to receiving an abnormal signal from a target controller, determining whether to perform fault detection on the target controller; if it is determined that fault detection of the target controller is necessary, determining the fault information of the target controller; the fault information includes the fault type and the corresponding fault level; and determining the fault handling method for the target controller based on the fault information. This method offers a more comprehensive fault diagnosis approach, with corresponding handling methods for both software and hardware faults. The judgment process is rigorous, improving the efficiency of fault diagnosis and handling. It also provides a rich variety of fault handling methods, with matching fault handling methods set for different fault types.

[0070] Based on the aforementioned technical means, this method can be adapted to fault diagnosis of most different types of motor controllers. These different types refer to motors with different hardware, functional differences, or different safety requirements. The method has a clear structure and well-defined modules, facilitating maintenance and development by different developers. It allows for direct analysis and modification / addition of modules based on fault diagnosis needs, and also enables the porting of already developed modules to new controller products, saving maintenance and development costs.

[0071] In one example, the vehicle-mounted terminal may include multiple functional modules, which can be used to execute the fault handling method determination method provided in the embodiments of this application. For example, the multiple functional modules may include a periodic fault diagnosis module, a fault integration module, and a fault handling module.

[0072] Among them, such as Figure 1 As shown, the periodic fault diagnosis module can contain multiple periodic diagnosis modules with different periods, such as a 100μs periodic diagnosis module, a 1ms periodic diagnosis module, and a 10ms periodic diagnosis module. Figure 2As shown, different periodic diagnostic modules contain fault diagnosis modules for different faults, such as Fault 1 diagnostic module, Fault 2 diagnostic module, ..., Fault n diagnostic module. These different fault diagnosis modules process according to a unified periodic fault diagnosis process, outputting unified fault information, including: fault flag bit, fault alarm level, fault drive-related processing level, and fault discharge-related processing level. The fault integration module calculates the maximum value of each of the above unified output fault information: fault flag bit, fault alarm level, fault drive-related processing level, and fault discharge-related processing level. The fault processing module performs fault processing based on the four values ​​output by the fault integration module.

[0073] For ease of understanding, the method for determining the fault handling method provided in this application will be described in detail below with reference to the accompanying drawings.

[0074] It should be noted that the executing entity of this application can be a vehicle or a component of a vehicle, such as an in-vehicle terminal or application layer software. The following description will take an in-vehicle terminal as the executing entity.

[0075] Figure 3 This is a flowchart illustrating a method for determining a fault handling mode according to an exemplary embodiment. Figure 3 As shown, the exception handling method includes: S301-S303.

[0076] S301. In response to receiving an abnormal signal from the target controller, the vehicle terminal determines whether to perform fault detection on the target controller.

[0077] The target controller can be a controller configured in the vehicle, such as a motor controller, or other controllers in the vehicle, such as a battery controller, without limitation. Abnormal signals can be used to indicate abnormalities in the target controller.

[0078] In one possible implementation, in response to an abnormal signal from the target controller, the vehicle terminal detects whether the target controller meets the detection conditions. If the target controller meets the detection conditions, the vehicle terminal determines that fault detection needs to be performed on the target controller; if the target controller does not meet the detection conditions, the vehicle terminal determines that fault detection does not need to be performed on the target controller.

[0079] Among them, such as Figure 4As shown, the fault determination process includes fault detection conditions and fault detection judgment conditions for the target controller. Detection conditions may include reset conditions and / or detection enable conditions. Reset conditions may include executing a unified diagnostic services (UDS) reset operation and / or a KL15 reset operation. Detection enable conditions are used to trigger the target controller to perform fault detection operations. For example, detection enable conditions may indicate that fault detection operations are only performed under certain conditions, such as after the MCU (microcontroller unit) initialization is complete, or only when certain faults have not occurred. The fault detection judgment condition is that if the target controller meets preset fault conditions, the on-board terminal determines that the target controller has a fault and identifies the fault information of the target controller. After the fault detection conditions and fault detection judgment conditions are met, fault confirmation is performed, as described in Implementation Two, and will not be repeated here.

[0080] It should be noted that in this embodiment, different components of the vehicle can generate signals, and each signal can be configured with a corresponding flag bit. Users can disable or enable the signal by setting the value of its flag bit. Thus, for signals that are not faulty or do not affect vehicle safety, the flag bit can be used to determine whether to respond to the signal for fault detection, thereby reducing the frequency of fault detection to some extent.

[0081] In this embodiment, the detection conditions for fault detection can be set with corresponding flag bits. The value of these flag bits can be used to indicate whether the target controller meets the corresponding conditions. For example, the flag bit corresponding to the detection condition can be P. Pre When P Pre When the value of is the first identifier, it indicates that the detection condition for fault detection is met; when P Pre The value is the second identifier, indicating that the detection conditions for fault detection are not met.

[0082] For example, the detection condition P for fault detection Pre Including reset condition P Reset Diagnostic enable condition P Enable For example, the detection condition P for fault detection Pre Satisfying Formula 1, reset condition P Reset It satisfies Formula 2.

[0083] P Pre =P Reset +P Enable Formula 1

[0084] P Reset=F UDS ·C UDS +F KL15 ·C KL15 Formula 2

[0085] In this context, + represents the OR operation in a logical formula, and · represents the AND operation in a logical formula. Reset To reset the condition flag, P Enable This is a diagnostic enable conditional flag. F UDS To reset the diagnostic service flag, C UDS Enable flag for diagnostic services reset. F KL15 KL15 reset flag, C KL15 This resets the enable flag for KL15. Set C... UDS C KL15 As a standard, the method for enabling and disabling fault diagnosis reset is implemented in a configurable manner. When the C of this fault... UDS When the value is 1, a diagnostic service reset operation can be performed. UDS If the value is 0, the diagnostic service reset operation cannot be performed. KL15 Similarly. P Enable You can add the corresponding logic according to the diagnostic requirements of the fault items.

[0086] Furthermore, the reset method can be calibrated by resetting the enable flag bit. On the one hand, different parameter values ​​can be configured to meet the fault reset requirements of different faults. On the other hand, it is also convenient for later strategy maintenance. When there are other reset requirements, the reset flag bit and the reset enable flag bit can be added by referring to the formula. If a certain reset method is not needed, the enable flag bit of a certain reset only needs to be set to 0.

[0087] In one example, when the target controller meets preset fault conditions, the vehicle terminal determines that the target controller has malfunctioned and determines the fault information of the target controller.

[0088] The preset fault conditions include the following conditions 1 to 5.

[0089] Condition 1: The target controller has a hardware failure.

[0090] Among them, the hardware failure of the target controller can refer to the failure of the target controller itself, such as a hardware overcurrent failure, that is, the current of the target controller is greater than the preset threshold.

[0091] In one example, the target controller's hardware may be configured with a hardware flag. When the target controller detects a hardware fault, it can set the value of this hardware flag to 1; when the target controller detects no hardware fault, it can set the value of this hardware flag to 0. Thus, the vehicle terminal can determine whether the target controller has experienced a hardware fault based on the value of the hardware flag.

[0092] Condition 2: The target controller is in the target control state, and the operating parameters of the target controller do not match the parameters corresponding to the target control state.

[0093] The mismatch between the operating parameters of the target controller and the parameters corresponding to the target control state means that the operating parameters of the actual operating state of the target controller are different from the preset operating parameters of the corresponding target control state.

[0094] In one example, the target controller is in torque control mode, and an enumerated type variable is used as the criterion for fault detection. This enumerated type variable compares the actual operating parameters of the target controller with the preset parameters for torque control mode; if the parameters do not match, a fault is identified; if the parameters match, the system is considered normal.

[0095] Condition 3: The operating parameters of the target controller are greater than the preset threshold.

[0096] The preset threshold can be set according to the operating parameters and is not restricted. The target controller's operating parameters exceeding the preset threshold can include threshold judgment types with and without hysteresis. Threshold judgment types with no hysteresis require only one fault threshold parameter. Threshold judgment types with hysteresis require one fault threshold parameter and one recovery threshold parameter, both of which are set to calibrable values.

[0097] In one example, a threshold-based judgment without hysteresis determines a fault when the motor speed exceeds a fault threshold and considers it normal when the motor speed is less than or equal to the fault threshold. A threshold-based judgment with hysteresis, for example, determines a fault when the detected temperature sample value exceeds a fault threshold, and the fault can only be resolved when the detected temperature sample value falls below a fault recovery threshold.

[0098] Condition 4: The error between the target controller's operating parameters and the preset parameters is greater than the preset difference.

[0099] The preset parameters are the operating parameters of the target controller when it is running normally.

[0100] In one example, a reference threshold and a difference threshold are set. The absolute value of the difference between the sampled value and the reference threshold is calculated to see if it is greater than the difference threshold. If the absolute value of the difference between the sampled value and the reference threshold is greater than the difference threshold, a fault is identified. If the absolute value of the difference between the sampled value and the reference threshold is less than the difference threshold, it is identified as normal.

[0101] Condition 5: The number of times the target controller generates abnormal signals is greater than the preset number; the fault duration of the target controller is greater than the preset duration.

[0102] In one example, the vehicle terminal performs a reset operation when a fault is detected; if the number of reset operations exceeds a preset number, the fault is latched. If the duration of the abnormal signal exceeds a preset duration, the vehicle terminal determines that the target controller has failed.

[0103] In one possible implementation, the above-mentioned preset fault conditions are encapsulated into a module, and the diagnosis of different faults can be determined by selecting the type parameter to determine the judgment type.

[0104] In this embodiment, the judgment conditions for fault detection may include preset fault conditions. The flag bit corresponding to the judgment conditions for fault detection may be P. Flt If a fault is detected in the target controller, then P... Flt Set P to 1, and if it is determined that the target controller is not faulty, then... Flt Set to 0.

[0105] Based on the above technical solution, this application can perform preliminary diagnosis and processing of abnormal signal sources by controlling the target controller to perform a reset operation, thus improving the function and process of fault diagnosis. The reset operation can resolve and eliminate some simple faults, avoiding the repetitive execution of subsequent steps and improving resource utilization. Preset parameters, such as preset operating parameters, preset time, and preset number of times, are used to determine whether the target controller's operating status has malfunctioned, improving the accuracy of fault diagnosis and enhancing system stability.

[0106] S302. If it is determined that fault detection of the target controller is required, the vehicle terminal determines the fault information of the target controller.

[0107] The fault information includes fault flags and fault levels. Fault levels include: fault alarm level, fault-driven processing level, and fault discharge processing level.

[0108] In one example, if the abnormal signal is not masked, the vehicle terminal determines to perform fault detection on the target controller in response to the abnormal signal of the target controller; if the abnormal signal is masked, the vehicle terminal determines that fault detection on the target controller is not required.

[0109] In this process, the vehicle terminal responds to the setting operation and determines the value of the flag bit of the abnormal signal; when the flag bit of the abnormal signal is the first identifier, the abnormal signal is blocked; when the flag bit of the abnormal signal is the second identifier, the abnormal signal is not blocked; the first identifier and the second identifier are different.

[0110] In one possible implementation, the vehicle's signal can be equipped with a corresponding flag bit. The value of this flag bit can be used to indicate whether the signal is blocked. For example, if the flag bit for the abnormal signal is a first identifier, the abnormal signal is blocked; if the flag bit for the abnormal signal is a second identifier, the abnormal signal is not blocked. The first identifier and the second identifier are different. The first identifier and the second identifier can be letters, numbers, or a combination of letters and numbers. For example, the first identifier can be 1, and the second identifier can be 0. Subsequent identifiers will refer to the description here and will not be repeated. Subsequent identifiers will be explained using 0 and 1 as examples. For example, the flag bit for the abnormal signal is C. Sld When the fault signal is blocked, C Sld The value is 1. When the fault signal is not shielded, C... Sld is 0.

[0111] In one example, if the duration of an abnormal signal exceeds a first preset duration, the vehicle terminal determines that the target controller is faulty. If, after detecting the abnormal signal, the vehicle terminal does not detect any further abnormal signals within a second preset duration, it determines that the target controller is functioning normally. The vehicle terminal determines a fault flag based on whether the target controller has malfunctioned.

[0112] Fault confirmation refers to the number of times or the duration of the detected fault before it can be definitively identified as a fault. A brief fluctuation in a signal, possibly caused by vehicle vibration, has no impact on the vehicle. Therefore, de-vibration processing is used to prevent such fluctuations from being identified as faults. The first and second preset durations can be set as needed, for example, 1s, 1ms, 1μs, or other values. A fault flag is used to indicate whether a fault is definitively identified.

[0113] In one example, when the fault type of the target controller is a hardware fault, the target controller is controlled to perform a fault latching operation; the fault latching operation includes: performing a reset operation when a fault is detected; and latching the fault if the number of reset operations exceeds a preset number.

[0114] Based on the above technical solutions, this application can determine whether the target controller has truly malfunctioned and recovered by using a first preset duration and a second preset duration, thus eliminating erroneous fault judgments made due to brief anomalies. This application can reduce repetition in subsequent fault diagnosis processes by determining whether a preset flag bit of the abnormal signal is masked, making the determination of fault handling methods more efficient. Hardware faults can be handled through fault latching and retry operations, reducing false positives and false negatives. The latching operation can retain fault error information, providing a basis for subsequent fault analysis and handling.

[0115] S303. The vehicle terminal determines the fault handling method of the target controller based on the fault information of the target controller.

[0116] In one example, the vehicle terminal determines the fault handling method for the target controller by integrating the fault information of the target controller.

[0117] Among them, fault integration is used to statistically analyze the fault information output by all fault diagnosis, determine the highest level in each fault level, and output it.

[0118] In another example, the on-board terminal can determine the fault handling method for the target controller based on the target fault level among multiple fault levels. The target fault level is the fault level with the highest value among the multiple fault levels, and the fault handling method corresponds to the target fault level.

[0119] The fault information output by the fault diagnosis system may include: fault flag bits, fault alarm level, fault drive-related processing level, and fault discharge-related processing level. The fault alarm level is used to assess the severity of the target controller fault; a higher alarm level indicates a more severe fault. The fault drive-related processing level indicates the level of a drive-related fault and executes corresponding processing operations according to the level. The fault discharge-related processing level indicates the level of a discharge-related fault and executes corresponding processing operations according to the level.

[0120] In one possible implementation, the fault alarm levels and related handling measures can be as shown in Table 1. For example, when the alarm level is 3, it means limp 1, and the handling measure is to reduce the maximum torque to 80%. The fault drive-related handling levels and corresponding handling measures can be as shown in Table 2. For example, when the fault drive-related handling level is 1, it means speed-related ASC, and the handling measure is low-speed FW and high-speed ASC. The fault discharge-related handling levels and corresponding handling measures can be as shown in Table 3. For example, when the fault discharge-related handling level is 1, the handling measure is to disallow discharge.

[0121] Table 1

[0122] Fault alarm level value meaning Troubleshooting measures 1 Alarm Only DTC codes are stored; no torque reduction treatment is applied to the entire vehicle. 2 Reduction Reduces energy output capability (can be restored) 3 Limping 1 Maximum torque reduced to 80% 4 Limping 2 Maximum torque reduced to 50% 5 Limping 3 Maximum torque reduced to 30% 6 Limping 4 Maximum torque drops to 0 7 safe status Driver-related processing

[0123] Table 2

[0124] Fault-driven related handling level values meaning Troubleshooting measures 0 Do not execute Driver-related processing is not performed. 1 Speed-related ASCII Low-speed FW, high-speed ASC 2 ASC Execute ASC directly 3 FW Execute FW directly

[0125] Table 3

[0126] Fault discharge related handling level values meaning 0 Allowed discharge 1 Discharge is not allowed

[0127] In one example, after periodic fault diagnosis, fault information for three fault items is obtained. The fault information includes: fault flag, fault alarm level, fault drive-related processing level, and fault discharge-related processing level. The fault information contained in each fault item and the fault information output after fault integration are shown in Table 4. Based on the fault flag and fault level output by fault integration, the fault handling method is determined to be: drive-related processing, directly execute FW, and disallow discharge.

[0128] Table 4

[0129]

[0130] based on Figure 3 Compared with the technical solutions of this application, the fault diagnosis is more comprehensive, with corresponding handling methods for both software and hardware faults. The judgment process is rigorous, which improves the efficiency of fault diagnosis and handling. The fault handling methods are rich, and matching fault handling methods are set for different fault types.

[0131] In another embodiment (Embodiment 2), such as Figure 5 As shown, this application embodiment provides a fault confirmation method including S501-S503.

[0132] S501, Input preprocessing.

[0133] The input preprocessing may include: determining the fault flag and the reset flag for fault confirmation based on the detection and judgment conditions of the fault detection.

[0134] Furthermore, the fault flag for fault confirmation indicates whether the fault signal meets the detection and judgment conditions for fault detection. The reset flag for fault confirmation indicates whether the fault signal meets the detection conditions for fault detection or whether it is masked. Fault confirmation can be set with corresponding flag bits. The value of these flag bits can be used to indicate whether the target controller meets the corresponding conditions.

[0135] In one example, relevant data involved in fault confirmation can be set with corresponding flag bits. The fault flag F for fault confirmation... FltIn The reset flag F for fault confirmation satisfies Formula 3. Rst It satisfies Formula 4.

[0136] F FltIn =P Flt +P Pre +C Sld Formula 3

[0137]

[0138] in, The NOT operation is used to represent the detection condition for fault detection in a logical formula. FltIn Used to indicate whether the detection conditions or judgment conditions for fault detection are met, when F FltIn A value of 1 indicates that the condition is satisfied; when F FltIn A value of 0 indicates that the condition is not met. F Rst Used to indicate whether the reset condition is met or not masked, when F Rst A value of 1 indicates that the condition is not met; when F Rst A value of 0 indicates that the condition is met.

[0139] S502, de-shaking processing.

[0140] The debouncing process can include fault confirmation delay and fault recovery delay. Fault confirmation delay and fault recovery delay can be set with corresponding flags; the names and meanings of these flags can be found in Table 5.

[0141] Table 5

[0142]

[0143] In one example, such as Figure 6 As shown, the fault confirmation delay includes: in F Rst When F is 0, FltIn Perform a judgment. Otherwise, determine that there is no fault and set the first fault flag bit F. FltPre1 Set to 0. In F Rst F is 1. FltIn When the value is 1, the fault timer is incremented. If the fault timer exceeds the fault confirmation time C, the fault timer is incremented. FltTime At that time, the initial diagnosis was a fault, and F was... FltPre1 Set it to 1. Otherwise, it is judged as no fault, and F is set to 1. FltPre1 Set to 0. After completing the fault timer accumulation operation, check if the fault timer is greater than C. FltTime Make a judgment. When the fault timer is greater than C... FltTime In this case, it is determined to be faulty, F FltPre1 Set to 1. When the fault timer is less than C... FltTime In the case of F FltPre1 Keep the existing values.

[0144] In another example, such as Figure 7 As shown, the fault recovery delay processing includes: [fault reset flag F after fault confirmation] Rst If the value is 1, it is determined that there is no fault, and the second fault flag F is set. FltPre2 Set to 0 to clear the fault timer. (In F) Rst When F is 0, FltPre1 Check if the value is 1. In F FltPre1 When the value is 1, it is determined that there is a fault, F FltPre2 Set to 1 to reset the timer to zero. (In F) FltPre1 If the value is 0, the recovery timer is incremented. After the recovery timer increment is complete, it is checked whether the recovery timer is greater than the fault recovery time C. RstTime Make a judgment. If the recovery time is greater than C... RstTime In this case, it is determined that there is no fault, and F is set to F. FltPre2 Set to 0. When the recovery time is less than C... RstTime In the case of F FltPre2 It remains unchanged.

[0145] S503, latch retry processing.

[0146] In one example, if the fault signal received by the vehicle terminal indicates a hardware fault, a latching retry process is performed. If the abnormal signal is determined to be masked, the system is ultimately deemed fault-free. If the duration of the abnormal signal exceeds a first preset duration, a target controller fault is identified, and a reset operation is performed. If the number of reset operations exceeds a first threshold, the fault is latched. If no abnormal signal is detected within a second preset duration after the initial detection, the target controller is determined to be functioning correctly, and the number of reset operations is decremented by one.

[0147] Specifically, when the fault signal received by the vehicle terminal indicates a hardware fault, a latching retry process is performed. The first threshold can be set to a positive integer as needed, such as 1, 10, or 20, or any other value without restriction.

[0148] In another example, the latch retry process for fault confirmation can be configured with corresponding flag bits. The names and meanings of these flag bits can be found in Table 5 above. Before executing the fault latch retry process, the latch configuration flag C is set. LockEnb Make a judgment in C LockEnb If the value is 0, the second fault flag F in the fault recovery delay processing is directly set. FltPre2 As a fault flag bit F FltOut Output. In C LockEnb When the value is 1, the fault confirmation time C can be... FltTime and fault recovery time C RstTimeSetting it to 0 skips the second step of debouncing in the next diagnostic cycle and proceeds to fault latching retry.

[0149] Further, such as Figure 8 As shown, the fault latch retry process includes: first, for F... Rst Make a judgment in F Rst If F = 1, it is determined that there is no fault, and the fault latch retry process ends. Rst When F = 0, FltPre2 Make a judgment in F FltPre2 =1 and the cumulative number of fault retries is greater than the maximum number of fault resets (C). LockMaxCnt In the case of F FltOut Set to 1 to latch faults. Otherwise, only for F. FltPre2 Make a judgment in F FltPre2 When the value is 1, the fault timer is accumulated. If the fault timer is greater than the interval C of the fault reset (Retry), then... LockRetryTime In the event of a fault reset, the fault timer is cleared, and the fault retry count is incremented by 1. If the fault timer is less than C... LockRetryTime In the case where no fault is detected, the fault latch retry process ends, and F is set to... FltOut Set to 0. In F FltPre2 When the value is 0, the recovery time is incremented. If the recovery time is greater than the fault recovery interval C, the recovery time is incremented. LockRstTime If the condition is met, the number of retry attempts is decremented by 1, and the latch retry process ends. Otherwise, the latch retry process ends.

[0150] Based on the above Figure 5 This application utilizes a technical approach to determine whether to perform fault detection on the target controller based on received abnormal signals, reducing the likelihood of erroneous fault alarms due to other factors, lowering the frequency of fault diagnosis, and improving user experience.

[0151] The above primarily describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the fault handling method determination device or electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0152] This application embodiment can, based on the above method, exemplarily divide the fault handling method determination device or electronic device into functional modules. For example, the fault handling method determination device or electronic device may include functional modules corresponding to each functional division, or two or more functions may be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0153] Figure 9 This is a block diagram illustrating a fault handling method determination apparatus according to an exemplary embodiment. (Refer to...) Figure 9 The fault handling method determination device 90 may include: a determination unit 901 and an inspection unit 902.

[0154] The determining unit 901 is used to determine whether to perform fault detection on the target controller in response to receiving an abnormal signal from the target controller;

[0155] The determining unit 901 is also used to determine, when it is determined that fault detection of the target controller is required, to obtain fault information of the target controller; the fault information includes the fault type and the fault level corresponding to the fault type;

[0156] The determining unit 901 is also used to determine the fault handling method of the target controller based on the fault information of the target controller.

[0157] In one possible implementation, the checking unit 902 is further configured to determine whether to perform fault detection on the target controller in response to receiving an abnormal signal from the target controller; if it is determined that fault detection on the target controller is required, the determining unit 901 is further configured to determine the fault information of the target controller; the fault information includes the fault type and the fault level corresponding to the fault type; the determining unit 901 is further configured to determine the fault handling method of the target controller based on the fault information of the target controller.

[0158] In one possible implementation, the determining unit 901 is further configured to detect whether the target controller meets the detection conditions in response to an abnormal signal from the target controller. The determining unit 901 is further configured to determine that fault detection needs to be performed on the target controller if the target controller meets the detection conditions; and to determine that fault detection does not need to be performed on the target controller if the target controller does not meet the detection conditions.

[0159] In one possible implementation, the detection conditions include: a reset condition and / or a detection enable condition; wherein the reset condition includes: performing a diagnostic service reset operation and / or a KL15 reset operation; and the detection enable condition is used to trigger the target controller to perform a fault detection operation.

[0160] In one possible implementation, the determining unit 901 is further configured to determine that the target controller has failed when the target controller meets the preset fault conditions, and to determine the fault information of the target controller.

[0161] In one possible implementation, the preset fault conditions include at least one of the following: the target controller's hardware malfunctions; the target controller's operating state is the target control state, and the target controller's operating parameters do not match the parameters corresponding to the target control state; the target controller's operating parameters are greater than a preset threshold; the error between the target controller's operating parameters and preset parameters is greater than a preset difference; the preset parameters are the operating parameters of the target controller during normal operation; the number of times the target controller generates abnormal signals is greater than a preset number; and the fault duration of the target controller is greater than a preset duration.

[0162] In one possible implementation, the determining unit 901 is further configured to determine a target controller fault if the duration of the abnormal signal exceeds a first preset duration.

[0163] In one possible implementation, the determining unit 901 is further configured to determine, in response to an abnormal signal of the target controller, to perform fault detection on the target controller when the abnormal signal is not shielded; the determining unit 901 is further configured to determine, when the abnormal signal is shielded, that fault detection on the target controller is not required.

[0164] In one possible implementation, the determining unit 901 is further configured to determine the value of the flag bit of the abnormal signal in response to the setting operation; wherein, when the flag bit of the abnormal signal is a first identifier, the abnormal signal is masked; when the flag bit of the abnormal signal is a second identifier, the abnormal signal is not masked; the first identifier is different from the second identifier.

[0165] In one possible implementation, the determining unit 901 is further configured to control the target controller to perform a fault latching operation when the fault type of the target controller is a hardware fault; the fault latching operation includes: performing a reset operation when a fault is detected; and latching the fault if the number of reset operations exceeds a preset number.

[0166] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0167] Figure 10 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Figure 10 As shown, the electronic device 100 includes, but is not limited to, a processor 1001 and a memory 1002.

[0168] The aforementioned memory 1002 is used to store the executable instructions of the aforementioned processor 1001. It is understood that the aforementioned processor 1001 is configured to execute instructions to implement the fault handling method determination method in the above embodiments.

[0169] It should be noted that those skilled in the art will understand that Figure 10 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 10 This may indicate more or fewer components, or a combination of certain components, or a different arrangement of components.

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

[0171] The memory 1002 can be used to store software programs and various data. The memory 1002 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as a determination unit, processing unit, etc.), etc. Furthermore, the memory 1002 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0172] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1002 including instructions, which can be executed by a processor 1001 of an electronic device 100 to implement the methods in the above embodiments.

[0173] In actual implementation, Figure 9 The functions of the determining unit 901 and the checking unit 902 can both be provided by... Figure 10The processor 1001 calls the computer program stored in the memory 1002 to implement the process. The specific execution process can be found in the description of the method section in the previous embodiment, and will not be repeated here.

[0174] This application also provides a computer-readable storage medium storing instructions. When a computer executes these instructions, the computer performs each step of the vehicle control method flow shown in the above method embodiments.

[0175] This application also provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the vehicle control method described in the above method embodiments.

[0176] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0177] In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by the processor 1001 of an electronic device to perform the methods described above.

[0178] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor of an electronic device, they implement the various processes of the above method embodiments and achieve the same technical effect as the above method. To avoid repetition, they will not be described again here.

[0179] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0180] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0181] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the classified units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0182] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0183] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, essentially, or the part that contributes to the prior art, or a complete or partial classification of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0184] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope 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.

Claims

1. A method for determining a fault handling mode, characterized in that, The method includes: In response to receiving an abnormal signal from the target controller, the system detects whether the target controller meets the detection conditions to determine whether to perform fault detection on the target controller; wherein, the detection conditions include: a reset condition and / or a detection enable condition, the reset condition including: performing a diagnostic service reset operation and / or a KL15 reset operation; the detection enable condition is used to trigger the target controller to perform a fault detection operation; If it is determined that fault detection of the target controller is required, fault information of the target controller is determined; the fault information includes the fault type and the fault level corresponding to the fault type; Based on the fault information of the target controller, determine the fault handling method of the target controller.

2. The method according to claim 1, characterized in that, The step of detecting whether the target controller meets the detection conditions to determine whether to perform fault detection on the target controller includes: If the target controller meets the detection conditions, it is determined that fault detection needs to be performed on the target controller; If the target controller does not meet the detection conditions, it is determined that fault detection does not need to be performed on the target controller.

3. The method according to claim 2, characterized in that, The determination of the fault information of the target controller includes: If the target controller meets the preset fault conditions, it is determined that the target controller has failed, and the fault information of the target controller is determined.

4. The method according to claim 3, characterized in that, The preset fault condition includes at least one of the following: The target controller experienced a hardware failure; The target controller is in a target control state, and the operating parameters of the target controller do not match the parameters corresponding to the target control state. The operating parameters of the target controller are greater than a preset threshold; The error between the operating parameters of the target controller and the preset parameters is greater than the preset difference; the preset parameters are the operating parameters of the target controller when it is running normally. The number of times the target controller generates abnormal signals is greater than the preset number; The fault duration of the target controller is longer than the preset duration.

5. The method according to claim 3, characterized in that, The determination that the target controller has malfunctioned includes: If the duration of the abnormal signal exceeds a first preset duration, the target controller is determined to be faulty.

6. The method according to any one of claims 1-2, characterized in that, The step of determining whether to perform fault detection on the target controller in response to an abnormal signal from the target controller includes: If the abnormal signal is not masked, in response to the abnormal signal of the target controller, it is determined to perform fault detection on the target controller; If the abnormal signal is masked, it is determined that fault detection of the target controller is not required.

7. The method according to any one of claims 1-2, characterized in that, The abnormal signal corresponds to a flag bit, and the method further includes: In response to a setting operation, the value of the flag bit of the abnormal signal is determined; wherein, when the flag bit of the abnormal signal is a first identifier, the abnormal signal is masked; when the flag bit of the abnormal signal is a second identifier, the abnormal signal is not masked; the first identifier and the second identifier are different.

8. The method according to any one of claims 1-2, characterized in that, The method further includes: If the fault type of the target controller is a hardware fault, control the target controller to perform a fault latching operation; The fault latching operation includes: performing a reset operation when a fault is detected; and latching the fault if the number of reset operations exceeds a preset number.

9. A device for determining a fault handling method, characterized in that, The determining device includes: A determining unit is configured to, in response to receiving an abnormal signal from a target controller, detect whether the target controller meets detection conditions to determine whether to perform fault detection on the target controller; wherein, the detection conditions include: a reset condition and / or a detection enable condition, the reset condition including: performing a diagnostic service reset operation and / or a KL15 reset operation; the detection enable condition is used to trigger the target controller to perform a fault detection operation; The determining unit is configured to determine, when it is determined that fault detection of the target controller is required, to acquire fault information of the target controller; the fault information includes fault type and fault level corresponding to the fault type; The determining unit is further configured to determine the fault handling method of the target controller based on the fault information of the target controller.

10. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, When the computer-executable instructions stored in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is capable of performing the method as described in any one of claims 1 to 8.

12. A computer program product containing instructions, characterized in that, When the instructions are executed by a computer, the computer performs the method as described in any one of claims 1 to 8.

13. A vehicle, characterized in that, The device for determining the fault handling method as described in claim 9.

Images