Fault processing method and device, motor controller and vehicle

Abstract

The invention relates to a fault processing method and device, a motor controller and a vehicle, and relates to the technical field of computers. The method comprises the following steps: determining the fault type of an MCU (Microprogrammed Control Unit) under the condition that a control chip MCU of the motor controller is detected to have a fault; the fault type comprises a software fault and a hardware fault; determining a first fault processing strategy based on the fault type; the first fault processing strategy comprises the following steps: when the fault type is the hardware fault, reporting identification information of the faulted hardware in the MCU; and under the condition that the fault type is the software fault, resetting the MCU. Therefore, hardware faults and software faults in the motor controller are recognized, the fault recognition rate is increased, and the stability and safety of the motor controller are improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, in particular to the field of motor controller technology, and specifically to a fault handling method, device, motor controller and vehicle. Background Art

[0002] With the rapid development of electric vehicles, the development of electric vehicles is not limited to basic functions such as driving and charging, but more attention is paid to the safety of electric vehicles. As an important component of the drive motor, the motor controller has a complex working environment, such as high working voltage and many external interference sources. The main control microcontroller and the driver chip are the control core of the motor controller. When the key chip of the motor controller is damaged or interfered, the entire electric drive system of the vehicle will not operate normally and the vehicle power will be interrupted. Therefore, how to deal with the failure of the motor controller is a technical problem that needs to be solved urgently.

[0003] CN116719297A proposes to obtain the fault status information of the electric drive system; the fault status information is used to indicate the current fault type among multiple fault types; according to the fault status information, and the correlation between multiple functional safety goals and the multiple fault types, the fault score of the electric drive system is determined; according to the fault score of the electric drive system, the fault of the electric drive system is processed. CN116719297A proposes a three-layer design, the first layer is the function monitoring layer, which monitors the consistency of the motor torque output, the second layer is the power management module, which protects and monitors the signal and even cuts it off after the fault, and the microcontroller monitoring module is set in the third layer to independently realize the microcontroller function program flow monitoring. These two methods detect the fault of the motor controller through the software unit, and do not realize the fault monitoring and fault handling of the current chip level of the motor controller. Therefore, how to deal with the fault of the motor controller chip level is a technical problem that needs to be solved urgently. Summary of the invention

[0004] The present application provides a fault handling method, device, motor controller and vehicle to at least solve the technical problem that the related art cannot handle faults at the motor controller chip level. The technical solution of the present application is as follows:

[0005] According to a first aspect of the present application, a fault handling method is provided, the method comprising: when a fault is detected in a micro control unit (MCU) of a control chip of a motor controller, determining the fault type of the MCU; the fault types include: software fault and hardware fault; based on the fault type, determining a first fault handling strategy; the first fault handling strategy includes: when the fault type is a hardware fault, reporting identification information of the faulty hardware in the MCU; when the fault type is a software fault, resetting the MCU.

[0006] According to the above technical means, the chip-level faults of the control chip of the motor controller are monitored, and the faults are processed based on the fault type. Targeted measures are taken for different types of faults to keep the motor controller running efficiently and reduce maintenance costs. In addition, the hardware faults and software faults in the motor controller are identified, the fault recognition rate is improved, and thus the stability and safety of the motor controller are improved.

[0007] In a possible implementation, the method further includes: when the fault type is a software fault, counting the number of times that software faults occur in the target software in the MCU; and when the number exceeds a preset number, reporting identification information of the hardware carrying the target software.

[0008] According to the above technical means, by counting the number of faults, it is identified whether there are repetitive or periodic faults. When the number of the same fault exceeds the preset number, the fault information is reported so that preventive maintenance measures can be taken to avoid potential hardware damage or further software failures and improve the stability and reliability of the motor controller.

[0009] In another possible implementation, resetting the MCU includes: reducing the level of a fault reset pin of the MCU from a high level to a low level.

[0010] According to the above technical means, the MCU can be quickly restored to its initial state through the fault reset pin, so as to quickly handle the software failure of the motor controller, improve work efficiency, and avoid potential data damage or loss caused by software failure.

[0011] In another possible implementation, the method further includes: obtaining the power-on duration of the motor controller; when the power-on duration does not exceed a preset duration, performing parameter verification on the driver chip based on a parameter verification mechanism of the driver chip of the motor controller to obtain a verification result; based on the verification result, determining whether the driver chip fails.

[0012] According to the above technical means, by performing parameter verification at the early stage of power-on of the motor controller, possible faults can be discovered as early as possible, and corresponding measures can be taken to prevent the faults from developing into more serious problems, reduce unexpected downtime and maintenance costs. In addition, parameter verification ensures that the driver chip of the motor controller is within the normal working range, thereby improving the reliability of the motor controller.

[0013] In another possible implementation, the method further includes: in the event of a driver chip failure, obtaining an operating state of a vehicle driven by a motor controller; determining a second fault handling strategy based on the operating state; the second fault handling strategy includes: when the operating state is a non-driving mode, powering off and resetting the driver chip; and when the operating state is a driving mode, reporting fault information of a driver chip failure.

[0014] According to the above technical means, different processing strategies are adopted according to the different operating states of the vehicle to deal with faults more effectively and reduce the impact on vehicle operation. When the vehicle is in driving mode, directly powering off and resetting may pose a risk to vehicle safety. Fault information is reported so that the fault can be handled after the vehicle ends the driving mode. Powering off and resetting in non-driving mode can quickly restore the function of the driver chip and improve processing efficiency.

[0015] In another possible implementation, the hardware failure includes an analog-to-digital converter (ADC) failure and / or a built-in self test (BIST) failure; the software failure includes at least one of the following: a clock watchdog unit (CMU) failure, a register protection (RegProt) failure, and a memory protection unit (MPU) failure.

[0016] According to the above technical means, the motor controller faults are classified in detail to quickly locate the source of the fault and take more effective repair measures, avoiding improper operations caused by misdiagnosis, reducing further damage to the motor controller, and improving maintenance efficiency. In addition, by identifying and handling hardware and software faults, the reliability and stability of the motor controller are improved.

[0017] In another possible implementation, the MCU includes: an ADC component and a BIST component; determining the fault type of the MCU includes: when a self-test result of the ADC component meets a first preset condition, determining that a hardware fault occurs in the ADC component; the first preset condition is that the self-test result of the ADC component includes at least one of the following: a self-test sequence error, an ADC self-test timeout, and a self-test algorithm error; when the self-test result of the BIST component meets a second preset condition, determining that a hardware fault occurs in the BIST component; the second preset condition is that the self-test result of the BIST component includes at least one of the following: a phase-locked loop (PLL) loss of lock, a BIST self-test timeout, and an abnormal self-test configuration.

[0018] According to the above technical means, the fault type is determined by the self-test results of the components in the MCU, which improves the accuracy of fault detection, and improves the reliability and stability of the motor controller by timely identifying and repairing hardware faults.

[0019] In another possible implementation, the MCU includes: a CMU component, a RegProt component, and an MPU component; determining the fault type of the MCU includes: when a self-test result of the CMU component indicates that a clock frequency of the MCU is not within a preset clock frequency range, determining that a software fault occurs in the CMU component; when a self-test result of the RegProt component indicates that a register of the MCU has been tampered with, determining that a software fault occurs in RegProt; when a self-test result of the MPU component indicates that an unexpected access occurs to a memory address segment of the MCU, determining that a software fault occurs in the MPU.

[0020] According to the above technical means, the self-test results provide clear fault indications, which help to accurately identify the fault type and distinguish between hardware faults and software faults, so that corresponding measures can be taken quickly to reduce the impact of the fault on the performance of the motor controller and improve the stability and reliability of the motor controller.

[0021] In another possible implementation, the method further includes: reporting fault information indicating that the motor controller has failed when the power-on duration exceeds a preset duration.

[0022] According to the above technical means, when the power-on time exceeds the preset time, it means that the power-on process of the motor controller fails, and the corresponding fault information is reported so as to identify and repair the fault in time and improve the overall reliability of the motor controller.

[0023] According to the second aspect provided by the present application, a fault handling device is provided, the device comprising a determination module. The determination module is used to determine the fault type of the MCU when a fault is detected in the control chip MCU of the motor controller; the fault type includes: software fault and hardware fault; the determination module is also used to determine a first fault handling strategy based on the fault type; the first fault handling strategy includes: reporting identification information of the faulty hardware in the MCU when the fault type is a hardware fault; resetting the MCU when the fault type is a software fault.

[0024] In a possible implementation, the device further includes: a statistical module and a reporting module. The statistical module is used to count the number of times that software failures occur in the target software in the MCU when the failure type is a software failure; and the reporting module is used to report identification information of the hardware carrying the target software when the number exceeds a preset number.

[0025] In another possible implementation, resetting the MCU includes: reducing the level of a fault reset pin of the MCU from a high level to a low level.

[0026] In another possible implementation, the device further includes: an acquisition module and a verification module. The acquisition module is used to acquire the power-on duration of the motor controller; the verification module is used to perform parameter verification on the driver chip based on the parameter verification mechanism of the driver chip of the motor controller when the power-on duration does not exceed the preset duration to obtain a verification result; the determination module is also used to determine whether the driver chip fails based on the verification result.

[0027] In another possible implementation, the acquisition module is also used to acquire the operating status of the vehicle driven by the motor controller when a driver chip fails; the determination module is also used to determine a second fault handling strategy based on the operating status; the second fault handling strategy includes: when the operating status is a non-driving mode, powering off and resetting the driver chip; when the operating status is a driving mode, reporting fault information of a driver chip failure.

[0028] In yet another possible implementation, the hardware failure includes an ADC failure and / or a BIST failure; the software failure includes at least one of the following: a CMU failure, a RegProt failure, and an MPU failure.

[0029] In another possible implementation, the MCU includes: an ADC component, a BIST component; a determination module, specifically used to determine that a hardware failure occurs in the ADC component when a self-test result of the ADC component meets a first preset condition; the first preset condition is that the self-test result of the ADC component includes at least one of the following: a self-test sequence error, an ADC self-test timeout, and a self-test algorithm error; when the self-test result of the BIST component meets a second preset condition, it is determined that a hardware failure occurs in the BIST component; the second preset condition is that the self-test result of the BIST component includes at least one of the following: a phase-locked loop PLL is unlocked, a BIST self-test timeout, and a self-test configuration abnormality.

[0030] In another possible implementation, the MCU includes: a CMU component, a RegProt component and an MPU component; a determination module, specifically used to determine that a software failure has occurred in the CMU component when a self-test result of the CMU component indicates that the clock frequency of the MCU is not within a preset clock frequency range; when a self-test result of the RegProt component indicates that a register of the MCU has been tampered with, determine that a software failure has occurred in RegProt; when a self-test result of the MPU component indicates that an unexpected access has occurred to the memory address segment of the MCU, determine that a software failure has occurred in the MPU.

[0031] In another possible implementation, the reporting module is further configured to report fault information of a motor controller failure when the power-on duration exceeds a preset duration.

[0032] According to a third aspect provided by the present application, a motor controller is provided, wherein the motor controller is used to execute the method of the above-mentioned first aspect and any possible implementation manner thereof.

[0033] According to the fourth aspect provided by the present application, a vehicle 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 above-mentioned first aspect and any possible implementation manner thereof.

[0034] According to the fifth aspect provided by the present application, a computer-readable storage medium is provided. When the instructions in the computer-readable storage medium are executed by the processor of the vehicle, the vehicle is enabled to execute the method in the above-mentioned first aspect and any possible implementation method thereof.

[0035] According to the sixth aspect provided by the present application, a computer program product is provided, the computer program product comprising computer instructions, and when the computer instructions are executed on a vehicle, the vehicle executes the method of the above-mentioned first aspect and any possible implementation manner thereof.

[0036] Therefore, the above technical features of the present application have the following beneficial effects:

[0037] (1) The chip-level faults of the motor controller's control chip are monitored, and faults are processed based on the fault type. Targeted measures are taken for different types of faults to keep the motor controller running efficiently and reduce maintenance costs. In addition, hardware faults and software faults in the motor controller are identified, and the fault recognition rate is improved, thereby improving the stability and safety of the motor controller.

[0038] (2) By counting the number of faults, it is possible to identify whether there are repetitive or periodic faults. When the number of the same fault exceeds the preset number, the fault information is reported so that preventive maintenance measures can be taken to avoid potential hardware damage or further software failures and improve the stability and reliability of the motor controller.

[0039] (3) The fault reset pin can be used to quickly restore the MCU to its initial state, so as to quickly handle software failures in the motor controller, improve work efficiency, and avoid potential data damage or loss caused by software failures.

[0040] (4) By performing parameter verification at the initial stage of power-on of the motor controller, possible faults can be discovered as early as possible and corresponding measures can be taken to prevent the faults from developing into more serious problems, thereby reducing unexpected downtime and maintenance costs. In addition, parameter verification ensures that the driver chip of the motor controller is within the normal operating range, thereby improving the reliability of the motor controller.

[0041] (5) Adopt different processing strategies according to the different operating states of the vehicle to deal with faults more effectively and reduce the impact on vehicle operation. When the vehicle is in driving mode, directly powering off and resetting may pose a risk to vehicle safety. Fault information is reported so that the fault can be handled after the vehicle ends the driving mode. Powering off and resetting in non-driving mode can quickly restore the function of the driver chip and improve processing efficiency.

[0042] (6) Detailed classification of motor controller faults is carried out to quickly locate the source of the fault and take more effective repair measures, thus avoiding improper operation caused by misdiagnosis, reducing further damage to the motor controller and improving maintenance efficiency. In addition, the reliability and stability of the motor controller can be improved by identifying and handling hardware and software faults.

[0043] (7) The fault type is determined through the self-test results of the components in the MCU, which improves the accuracy of fault detection and improves the reliability and stability of the motor controller by timely identifying and repairing hardware faults.

[0044] (8) The self-test results provide clear fault indications, which help to accurately identify the fault type and distinguish between hardware faults and software faults so that appropriate measures can be taken quickly to reduce the impact of the fault on the performance of the motor controller and improve the stability and reliability of the motor controller.

[0045] (9) When the power-on time exceeds the preset time, it indicates that a fault occurs in the power-on process of the motor controller, and the corresponding fault information is reported so that the fault can be identified and repaired in time, thereby improving the overall reliability of the motor controller.

[0046] It should be noted that the technical effects brought about by any implementation method in the second to sixth aspects can refer to the technical effects brought about by the corresponding implementation method in the first aspect, and will not be repeated here.

[0047] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification are used to explain the principles of the present application, and do not constitute an improper limitation on the present application.

[0049] Figure 1 is a structural schematic diagram of a fault handling system according to an exemplary embodiment;

[0050] Figure 2 is a flow chart of a fault handling method according to an exemplary embodiment;

[0051] Figure 3 is a flow chart showing another fault handling method according to an exemplary embodiment;

[0052] Figure 4 is a flowchart of another fault handling method according to an exemplary embodiment;

[0053] Figure 5 is a flowchart of another fault handling method according to an exemplary embodiment;

[0054] Figure 6 is a flowchart of another fault handling method according to an exemplary embodiment;

[0055] Figure 7 is a flowchart of another fault handling method according to an exemplary embodiment;

[0056] Figure 8 is a flow chart showing a fault classification flow of a motor controller control chip according to an exemplary embodiment;

[0057] Fig. 9 is a flow chart of a motor controller control chip fault processing according to an exemplary embodiment;

[0058] Fig.10 is a flowchart of a fault handling process of an ADC module of a motor controller control chip according to an exemplary embodiment;

[0059] Fig.11 is a flowchart of a BIST module fault processing of a motor controller control chip according to an exemplary embodiment;

[0060] Fig.12 is a CMU module fault processing flow chart of a motor controller control chip according to an exemplary embodiment;

[0061] Fig.13 is a flowchart of a RegProt module fault processing of a motor controller control chip according to an exemplary embodiment;

[0062] Fig.14 This is a flowchart of an MPU module fault processing of a motor controller control chip according to an exemplary embodiment;

[0063] Fig.15 is a flow chart of a motor controller driver chip fault processing according to an exemplary embodiment;

[0064] Fig.16 is a block diagram of a fault processing device according to an exemplary embodiment;

[0065] Fig.17 is a block diagram of a vehicle according to an exemplary embodiment. DETAILED DESCRIPTION

[0066] In order to enable ordinary persons in the art to better understand the technical solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0067] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0068] With the rapid development of electric vehicles in recent years, the development of electric vehicles is not limited to basic functions such as driving and charging. The industry pays more attention to the safety of electric vehicles, and functional safety is a subject that needs to be studied. As an important component of the drive motor, the motor controller has a complex working environment, such as high working voltage and many external interference sources. The main control microcontroller and the driver chip are the control core of the motor controller. When the key chip is damaged or interfered, the entire electric drive system will not operate normally, which will manifest as power interruption on the vehicle. Therefore, how to ensure that chip-level faults can be monitored and the faults can be responded to correctly through software and hardware design is a technical problem that needs to be solved urgently.

[0069] A layered design method is proposed in the related art. The first layer is the function monitoring layer, which monitors the consistency of the motor torque output; the second layer is the power management module, which protects and monitors the signal and even cuts it off after a fault; the microcontroller monitoring module is set in the third layer to independently implement the microcontroller function program flow monitoring. This method only describes the architectural design of the motor control functional safety, and does not implement chip-level fault monitoring and fault handling. Another related technology proposes a method for monitoring whether the software unit is executing normally, and by controlling the IO port, the drive module selects the switch action control to enter a safe state. This method does not describe how the software unit monitors faults, nor does it implement software-level fault handling. It only explains how to turn off the pulse width modulation signal output at the hardware level. Therefore, how to deal with faults at the chip level of the motor controller is a technical problem that needs to be solved urgently.

[0070] In response to the above problems, this application proposes a fault handling method, in which the chip-level faults of the control chip of the motor controller are monitored, and the faults are handled based on the fault type, and targeted measures are taken for different types of faults to keep the motor controller running efficiently and reduce maintenance costs. In addition, the hardware faults and software faults in the motor controller are identified, the fault recognition rate is improved, and thus the stability and safety of the motor controller are improved.

[0071] For ease of understanding, the troubleshooting method provided in this application is described in detail below with reference to the accompanying drawings.

[0072] Figure 1 is a structural diagram of a fault handling system according to an exemplary embodiment. Figure 1 As shown, the fault handling system 100 includes: a single chip microcomputer 101 , a single board computer (SBC) power supply 102 , a buffer 103 , a cable 104 and a driver board 105 .

[0073] In some embodiments, the microcontroller 101 uses MCU SPC5744P as the main control chip, including pulse width modulation (PWM). The microcontroller 101 is connected to the driver board 105 through the buffer BUFFER103 and the cable 104. The SBC power supply 102 includes a power chip FS6523, and the driver board 105 uses a driver chip GD3100 as the driver chip.

[0074] In some embodiments, when the driver chip GD3100 of the driver board 105 fails, the fault level Fault_INTB is transmitted to the MCU of the single-chip microcomputer 101. The MCU realizes the output and shutdown of the PWM by controlling the PWM output enable pin Buffer_EN, thereby protecting the motor controller. In addition, further protection of the motor controller can be achieved through the SBC. When the MCU fails, the fault is transmitted to the SBC power supply 102 through the fault transmission pin Eout_EN pin, and the SBC power supply 102 realizes the reset control of the MCU through the reset signal input terminal RSTB.

[0075] It should be noted that the system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of the system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0076] Figure 2 is a flowchart of a fault handling method according to an exemplary embodiment. Figure 2 As shown, the fault handling method includes the following steps:

[0077] S201 . When it is detected that a control chip MCU of a motor controller fails, determine the failure type of the MCU.

[0078] Among them, the fault types include: software fault and hardware fault.

[0079] As a possible implementation manner, when it is detected that a control chip MCU of the motor controller fails, the processing device may determine the failure type of the MCU.

[0080] Exemplarily, the control chip MCU of the motor controller can classify the faults that need to be monitored in the motor controller into: ADC monitoring module, BIST monitoring module, CMU monitoring module, RegProt monitoring module, MPU monitoring module. The processing device can classify each monitoring module to ensure that the faults of each module of the control chip can be queried in an orderly manner. The processing device can detect whether the control chip MCU of the motor controller has a fault by obtaining the fault monitoring results of each module. When a fault is detected, the fault type of the MCU is determined so that the fault can be processed based on the fault type.

[0081] S202: Determine a first fault handling strategy based on the fault type.

[0082] The first fault handling strategy includes: when the fault type is a hardware fault, reporting identification information of the faulty hardware in the MCU; when the fault type is a software fault, resetting the MCU.

[0083] As a possible implementation manner, after the processing device determines the fault type of the MCU, it can determine a first fault processing strategy for processing the fault based on the fault type.

[0084] Exemplarily, the processing device can classify and design fault handling methods based on the fault type, which are divided into two processing methods: the first is a hardware fault handling method, which records fault information and reports it; the second is a software fault handling method, which uses a power management chip to pull the level of the SBC fault reset pin RSTB from a high level to a low level to reset the MCU, thereby preventing the MCU from being reset through the peripheral chip SBC when the MCU cannot be reset due to an abnormality, thereby ensuring that the fault can be recovered and the correct operation of the program is guaranteed.

[0085] It should be noted that resetting the MCU includes: reducing the level of the fault reset pin of the MCU from a high level to a low level. Hardware faults include ADC faults and / or BIST faults; software faults include at least one of the following: CMU faults, RegProt faults and MPU faults. The processing device classifies the faults of the motor controller in detail to quickly locate the source of the fault and take more effective repair measures, thereby avoiding improper operations caused by misdiagnosis, reducing further damage to the motor controller, and improving maintenance efficiency. In addition, by identifying and processing hardware faults and software faults, the reliability and stability of the motor controller are improved. The processing device can quickly restore the MCU to its initial state through the fault reset pin, so as to quickly process the software faults of the motor controller, improve work efficiency, and avoid potential data damage or loss caused by software faults.

[0086] It should be understood that the processing device monitors chip-level faults of the control chip of the motor controller, processes the faults based on the fault type, and takes targeted measures for different types of faults to keep the motor controller running efficiently and reduce maintenance costs. In addition, it recognizes hardware faults and software faults in the motor controller, improves the fault recognition rate, and thus improves the stability and safety of the motor controller.

[0087] In some embodiments, when the fault type is a software fault, the processing device may further count the number of times the target software in the MCU has a software fault, and based on the number, determine whether the hardware carrying the target software has a fault. Figure 3 As shown, the fault handling method provided in the embodiment of the present application also includes the following steps S203-S204:

[0088] S203: When the fault type is a software fault, count the number of times the software fault occurs in the target software in the MCU.

[0089] As a possible implementation manner, when the fault type is a software fault, the processing device may count the number of times the software fault occurs in the target software in the MCU.

[0090] Exemplarily, for any software fault in the motor controller, when the fault type occurring in the MCU is a software fault, the processing device may count the number of times the software fault occurs in the target software causing the software fault.

[0091] S204: When the number of times exceeds a preset number of times, report identification information of the hardware carrying the target software.

[0092] As a possible implementation manner, after the processing device counts the number of software failures that occur in the target software in the MCU, if the number exceeds a preset number, the identification information of the hardware that carries the target software can be reported.

[0093] For example, when the number of times exceeds the preset number, it indicates that the target software frequently fails, and the hardware carrying the target software may have potential problems that cause the target software to frequently fail. Therefore, the processing device can report the identification information of the hardware carrying the target software so as to repair the hardware carrying the target software and avoid the occurrence of failures. The preset number is determined by relevant managers or technicians according to actual conditions, and the embodiments of the present application do not limit this.

[0094] It should be understood that the processing device identifies whether there are repetitive or periodic faults by counting the number of faults. When the number of the same fault exceeds a preset number, the fault information is reported so that preventive maintenance measures can be taken to avoid potential hardware damage or further software failures and improve the stability and reliability of the motor controller.

[0095] In some embodiments, the processing device may also obtain the power-on duration of the motor controller, so as to determine whether the motor controller fails based on the power-on duration and the parameter verification mechanism. Figure 4 As shown, the fault handling method provided in the embodiment of the present application also includes the following steps S401-S403:

[0096] S401, obtaining the power-on duration of the motor controller.

[0097] As a possible implementation manner, when the motor controller starts to run, the processing device may obtain the power-on duration of the motor controller.

[0098] S402 : When the power-on time does not exceed the preset time, the driver chip is subjected to parameter verification based on the parameter verification mechanism of the driver chip of the motor controller to obtain a verification result.

[0099] As a possible implementation method, after the processing device obtains the power-on duration of the motor controller, it can perform parameter verification on the driver chip based on the parameter verification mechanism of the driver chip of the motor controller to obtain a verification result if the power-on duration does not exceed a preset duration.

[0100] Exemplarily, the driver chip GD3100 of the motor controller has a readback verification mechanism. When the motor controller is powered on and initialized, the MCU will configure the parameters of the GD3100 chip. This link may cause the register parameter configuration to fail due to interference from the external environment. Therefore, within the preset time before the motor controller is powered on, the processing device can perform parameter verification on the driver chip based on the parameter readback verification mechanism of the driver chip register to obtain the verification result. Among them, the preset time is determined by relevant management personnel or technical personnel based on actual conditions, for example: 3 seconds, and this embodiment of the present application does not limit this.

[0101] S403: Determine whether the driver chip fails based on the verification result.

[0102] As a possible implementation manner, after obtaining the verification result, the processing device can determine whether the driver chip fails based on the verification result.

[0103] Exemplarily, when the check result indicates that the read-back value of the driver chip register parameter is inconsistent with the written value, it indicates whether the driver chip has failed. When the check result indicates that the read-back value of the driver chip register parameter is consistent with the written value, it indicates that the driver chip has not failed.

[0104] It should be understood that the processing device can detect possible faults as early as possible by performing parameter verification at the initial power-on of the motor controller, and take corresponding measures to prevent the fault from developing into a more serious problem, thereby reducing unexpected downtime and maintenance costs. In addition, the parameter verification ensures that the driver chip of the motor controller is within the normal working range, thereby improving the reliability of the motor controller.

[0105] In some embodiments, when a driver chip fails, the processing device may also obtain the operating state of the vehicle driven by the motor controller to determine a second fault handling strategy. Figure 5 As shown, the fault handling method provided in the embodiment of the present application also includes the following steps S404-S405:

[0106] S404: When a driver chip fails, obtain a running state of a vehicle driven by a motor controller.

[0107] As a possible implementation, in the event of a driver chip failure, the processing device may obtain the operating status of a vehicle driven by a motor controller so as to determine a second fault handling strategy based on the vehicle operating status.

[0108] S405: Determine a second fault handling strategy based on the operating status.

[0109] The second fault handling strategy includes: when the operating state is a non-driving mode, powering off and resetting the drive chip; when the operating state is a driving mode, reporting fault information of a fault in the drive chip.

[0110] As a possible implementation manner, after the processing device determines the second fault processing strategy, it can determine the second fault processing strategy based on the operating state.

[0111] Exemplarily, when the operating state is non-driving mode, the MCU controls the driver chip power supply to power off and reset GD3100, and reconfigures the parameters of GD3100 to achieve fault recovery.

[0112] When the operating state is driving mode, in order to avoid affecting the driving of the vehicle, the processing device cannot power off and reset the drive chip, and report the fault information of the drive chip failure so that the fault can be processed after the vehicle ends the driving mode.

[0113] It should be understood that the processing device adopts different processing strategies according to the different operating states of the vehicle to deal with faults more effectively and reduce the impact on vehicle operation. When the vehicle is in driving mode, directly powering off and resetting may pose a risk to vehicle safety. Fault information is reported so that the fault can be handled after the vehicle ends the driving mode. Powering off and resetting in non-driving mode can quickly restore the function of the driver chip and improve processing efficiency.

[0114] In some embodiments, the hardware failure includes an ADC failure and / or a BIST failure. The MCU includes: an ADC component, a BIST component. Therefore, if Figure 6 As shown, the above steps determine the fault type of the MCU, which can be specifically implemented as the following steps S2011-S2012:

[0115] S2011: When a self-test result of the ADC component meets a first preset condition, determine that a hardware failure occurs in the ADC component.

[0116] The first preset condition is that the self-test result of the ADC component includes at least one of the following: a self-test sequence error, an ADC self-test timeout, or a self-test algorithm error.

[0117] As a possible implementation manner, when the self-test result of the ADC component meets the first preset condition, the processing device may determine that a hardware failure occurs in the ADC component.

[0118] Exemplarily, the ADC component of the motor controller involves the current and voltage acquisition of the motor controller. If the acquisition deviates, it will cause the torque control to deviate. Therefore, when the ADC component software is initialized, the processing device can control the ADC component to perform detection based on its own self-test mechanism, configure the ADC component parameters, set the ADC clock to 20MHz, start ADC sampling, delay 50ms to wait for ADC sampling to complete, turn off ADC sampling, and read the ADC register self-test result. When the self-test result is any of the following three self-test results: self-test sequence error, ADC self-test timeout, self-test algorithm error, it indicates that the ADC component has failed. Since the ADC component is the acquisition module of the chip, the abnormality of this module is usually a problem with the chip itself, so the fault is a hardware fault, and the processing device can determine that the ADC component has a hardware fault.

[0119] S2012: When the self-test result of the BIST component meets a second preset condition, determine that a hardware failure occurs in the BIST component.

[0120] The second preset condition is that the self-test result of the BIST component includes at least one of the following: PLL lockout, BIST self-test timeout, and self-test configuration abnormality.

[0121] As a possible implementation manner, when the self-test result of the BIST component meets the second preset condition, the processing device may determine that a hardware failure occurs in the BIST component.

[0122] Exemplarily, the BIST component of the motor controller includes a self-test fault of the control chip of the motor controller, such as: PLL lockout, BIST timeout, etc. The processing device can perform fault detection on the motor controller based on the BIST component to obtain a self-test result. When the self-test result is any one of the following three self-test results: PLL lockout, BIST self-test timeout, and self-test configuration abnormality, it indicates that the BIST component has failed. Since the BIST component is strongly related to the hardware, the failure of the BIST self-test indicates that there is a problem with the control chip of the motor controller itself, so the fault is a hardware fault, and the processing device can determine that the BIST component has a hardware fault.

[0123] It should be understood that the processing device determines the fault type through the self-test results of the components in the MCU, thereby improving the accuracy of fault detection, and improving the reliability and stability of the motor controller by timely identifying and repairing hardware faults.

[0124] In some embodiments, the software fault includes at least one of the following: CMU fault, RegProt fault and MPU fault. The MCU includes: CMU component, RegProt component and MPU component. Therefore, if Figure 7 As shown, the above steps determine the fault type of the MCU, which can be specifically implemented as the following steps S201a-S201c:

[0125] S201a: When the self-test result of the CMU component indicates that the clock frequency of the MCU is not within a preset clock frequency range, determine that a software failure occurs in the CMU component.

[0126] As a possible implementation manner, when the self-test result of the CMU component indicates that the clock frequency of the MCU is not within a preset clock frequency range, the processing device may determine that a software failure occurs in the CMU component.

[0127] Exemplarily, the CMU component of the motor controller is used for clock monitoring to monitor the system clock, CAN clock, etc. The processing device can set the upper and lower limit thresholds for clock monitoring. For example, if the system clock is 80MHz and the monitoring range is ±8%, the upper limit of monitoring is set to 87MHz and the lower limit is 74MHz. The processing device can start the measurement of the CMU component clock, delay 30ms, and wait for the clock measurement to be completed. When the clock frequency of the motor controller exceeds the upper and lower limit thresholds, it means that the CMU component has failed, and the clock may be unstable at a certain power-on, resulting in occasional errors, which is a software failure. The processing device can determine that the CMU component has a software failure. Among them, the upper and lower limit thresholds of the clock frequency are determined by relevant managers or technicians according to actual conditions. The above is only an example, and the embodiments of the present application are not limited to this.

[0128] It should be understood that when a CMU component failure occurs in the motor controller, the processing device can reset the MCU through the SBC, and pull the level of the SBC fault reset pin RSTB from a high level to a low level to reset the MCU. When the motor controller's clock frequency out-of-range error occurs three times in a row, the processing device will no longer reset the MCU and report the fault.

[0129] S201b: When the self-test result of the RegProt component indicates that the register of the MCU has been tampered with, determine that a software failure occurs in RegProt.

[0130] As a possible implementation manner, when the self-test result of the RegProt component indicates that the register of the MCU has been tampered with, the processing device may determine that a software failure occurs in RegProt.

[0131] Exemplarily, the RegProt component of the motor controller protects some key registers of the ADC component, interrupt trigger unit (CTU) module, and flexible pulse width modulator (FLEXPWM) module in the motor controller. When the protected register is tampered with, it indicates that the RegProt component has failed. The RegProt component is set to enter config mode to set the module registers that need to be protected, such as: ADC component registers, CTU module registers, and FLEXPWM module registers. The processing device can obtain the monitoring results of the protected module. If any of the above three registers is tampered with, it indicates that the RegProt component has failed. The tampering of the register may be caused by the software running incorrectly at a certain power-on, so the fault is a software fault, and the processing device can determine that RegProt has a software fault.

[0132] It should be understood that when the processing device fails to recover the software fault of RegProt by resetting the MCU for three consecutive times, it indicates that there may be a hardware fault in the motor controller, and the processing device no longer resets the MCU and reports the fault.

[0133] S201c. When the self-test result of the MPU component indicates that unexpected access occurs to the memory address segment of the MCU, it is determined that a software failure occurs in the MPU.

[0134] As a possible implementation, when the self-test result of the MPU component indicates that unexpected access occurs to the memory address segment of the MCU, the processing device may determine that a software failure occurs in the MPU.

[0135] Exemplarily, the MPU component of the motor controller sets protection permissions for each software address segment in the motor controller. When unexpected access occurs to the software address segment, it indicates that the MPU has failed. The MPU component sets protection for the following address segments: non-volatile storage address segment, random access storage address segment. The MPU component can set read and write permissions for the protected address segments. The processing device obtains the monitoring results of the address segments. When any of the above address segments is unexpectedly accessed, a software failure occurs in the MPU, and the processing device can determine that a software failure occurs in the MPU.

[0136] It should be understood that if the MCU is not restored when a software fault occurs in the MPU, subsequent programs may not run normally. If the processing device fails to restore the software fault of MCUt by resetting the MCU for three consecutive times, it indicates that there may be a hardware fault in the motor controller, and the processing device no longer resets the MCU and reports the fault.

[0137] It should be understood that the self-test results provide clear fault indications, which help to accurately identify the fault type and distinguish between hardware faults and software faults so that appropriate measures can be taken quickly to reduce the impact of the fault on the performance of the motor controller and improve the stability and reliability of the motor controller.

[0138] In some embodiments, when the power-on duration exceeds a preset duration, it indicates that the power-on mechanism of the motor controller fails, and the processing device may also report the fault information. Therefore, the fault handling method provided in the embodiment of the present application also includes: when the power-on duration exceeds a preset duration, reporting fault information that the motor controller fails.

[0139] As a possible implementation manner, when the power-on time exceeds a preset time, the processing device may report fault information indicating that a motor controller has failed.

[0140] It should be understood that when the power-on time exceeds the preset time, it means that the power-on process of the motor controller fails, and the processing device reports the corresponding fault information so as to identify and repair the fault in time and improve the overall reliability of the motor controller.

[0141] Figure 8 is a flow chart showing a motor controller control chip fault classification according to an exemplary embodiment. Figure 8 As shown, the process includes the following steps: setting a fault monitoring classification query table, monitoring whether each module has a fault, executing a fault recovery mechanism in the event of a fault, and executing a periodic task in the event of no fault.

[0142] Fig. 9 FIG. 1 is a flowchart of a motor controller control chip fault processing according to an exemplary embodiment. Fig. 9 As shown, the process includes the following steps: executing a fault recovery mechanism, determining whether software processing is required, recording the fault and reporting the fault if software processing is required, and pulling down the RSTB pin of the power management chip for reset if software processing is required.

[0143] Fig.10 FIG. 1 is a flowchart of a fault handling process of an ADC module of a motor controller control chip according to an exemplary embodiment. Fig.10As shown, the process includes the following steps: enabling ADC module fault monitoring, setting the fault recovery mechanism to software processing, setting the ADC sampling clock frequency, starting ADC sampling, waiting for 50ms for self-test to complete, turning off ADC sampling, reading the self-test sequence, self-test timeout, and self-test algorithm verification results, and determining whether the ADC self-test result is normal. If the ADC self-test result is normal, performing BIST self-test, and if the ADC self-test result is abnormal, reporting the ADC self-test failure fault.

[0144] Fig.11 FIG. 1 is a flowchart of a BIST module fault processing of a motor controller control chip according to an exemplary embodiment. Fig.11 As shown, the process includes the following steps: enabling BIST module fault monitoring, setting the fault recovery mechanism to software processing, obtaining PLL lock loss, self-test timeout, and self-test configuration abnormality verification results, judging whether the BIST self-test result is normal, executing the CMU monitoring process when the BIST self-test result is normal, and reporting the BIST self-test failure fault when the BIST self-test result is abnormal.

[0145] Fig.12 FIG. 1 is a flow chart showing a CMU module fault processing flow of a motor controller control chip according to an exemplary embodiment. Fig.12 As shown in the figure, the process includes the following steps: enable CMU module fault monitoring, set the fault recovery mechanism to SBC reset, set the clock upper and lower thresholds, start measurement, delay 30ms to wait for the measurement to complete, determine whether the CMU monitoring result is normal, and if the CMU monitoring result is normal, execute the RegProt monitoring process. If the CMU monitoring result is abnormal, SBC resets the MCU, determines whether the CMU monitoring fails for three consecutive times, and if the CMU monitoring fails for three consecutive times, reports the CMU monitoring failure fault. If the CMU monitoring does not fail for three consecutive times, execute the RegProt monitoring process.

[0146] Fig.13 FIG. 1 is a flowchart of a RegProt module fault processing of a motor controller control chip according to an exemplary embodiment. Fig.13As shown, the process includes the following steps: enable RegProt module fault monitoring, set the fault recovery mechanism to SBC reset, set to enter config mode, set the register protection module to be protected, obtain ADC, CTU, FLEXPWM monitoring results, determine whether the protected register has been tampered with, and execute the periodic task if the protected register has been tampered with. If the protected register has not been tampered with, SBC executes MCU reset, and determines whether the register value has been tampered with for three consecutive times. If the register value has been tampered with for three consecutive times, report the abnormal register value tampering fault. If the register value has not been tampered with for three consecutive times, execute the periodic task.

[0147] Fig.14 FIG. 1 is a flowchart of an MPU module fault processing of a motor controller control chip according to an exemplary embodiment. Fig.14 As shown, the process includes the following steps: enabling MPU module fault monitoring, setting the fault recovery mechanism to SBC reset, configuring the MPU protection area, configuring the read and write permissions of the MPU, obtaining the MPU, Flash, and RAM monitoring results, determining whether the program has an out-of-bounds access, executing periodic tasks when the program has an out-of-bounds access, SBC executing MCU reset, determining whether an out-of-bounds access has occurred three times in a row, reporting an out-of-bounds access fault when an out-of-bounds access has occurred three times in a row, and executing periodic tasks when an out-of-bounds access has not occurred three times in a row.

[0148] Fig.15 FIG. 1 is a flowchart of a motor controller driver chip fault processing according to an exemplary embodiment. Fig.15 As shown, the process includes the following steps: GD3100 parameter configuration, judging whether the power-on time is less than 3 seconds, judging whether the read and write values ​​of the GD3100 configuration parameters are consistent when the power-on time is less than 3 seconds, judging whether it is in driving mode when the read and write values ​​of the GD3100 configuration parameters are consistent, judging whether it is in driving mode, and in driving mode, MCU performs power-off reset on GD3100, and reports a read-back check failure when it is not in driving mode, and ends when the power-on time is not less than 3 seconds and the read and write values ​​of the GD3100 configuration parameters are inconsistent.

[0149] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to achieve the above functions, the fault handling device or vehicle includes a hardware structure and / or software module corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0150] The embodiments of the present application can divide the functional modules of the fault handling device or vehicle according to the above method. For example, the fault handling device or vehicle can include various functional modules corresponding to the various functional divisions, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiments of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.

[0151] Fig.16 is a block diagram of a fault processing device according to an exemplary embodiment. Fig.16 The fault handling device 1600 includes: a determination module 1601. The determination module 1601 is used to determine the fault type of the control chip MCU of the motor controller when a fault is detected; the fault type includes: software fault and hardware fault; the determination module 1601 is also used to determine a first fault handling strategy based on the fault type; the first fault handling strategy includes: when the fault type is a hardware fault, reporting the identification information of the faulty hardware in the MCU; when the fault type is a software fault, resetting the MCU.

[0152] In a possible implementation, the device further includes: a statistical module 1602 and a reporting module 1603. The statistical module 1602 is used to count the number of times that software failures occur in the target software in the MCU when the failure type is a software failure; and the reporting module 1603 is used to report identification information of the hardware carrying the target software when the number exceeds a preset number.

[0153] In another possible implementation, resetting the MCU includes: reducing the level of a fault reset pin of the MCU from a high level to a low level.

[0154] In another possible implementation, the device further includes: an acquisition module 1604 and a verification module 1605. The acquisition module 1604 is used to acquire the power-on duration of the motor controller; the verification module 1605 is used to perform parameter verification on the driver chip based on the parameter verification mechanism of the driver chip of the motor controller when the power-on duration does not exceed the preset duration to obtain a verification result; the determination module is also used to determine whether the driver chip fails based on the verification result.

[0155] In another possible implementation, the acquisition module 1604 is also used to obtain the operating status of the vehicle driven by the motor controller when a driver chip fails; the determination module 1601 is also used to determine a second fault handling strategy based on the operating status; the second fault handling strategy includes: when the operating status is a non-driving mode, powering off and resetting the driver chip; when the operating status is a driving mode, reporting fault information of a driver chip failure.

[0156] In yet another possible implementation, the hardware failure includes an ADC failure and / or a BIST failure; the software failure includes at least one of the following: a CMU failure, a RegProt failure, and an MPU failure.

[0157] In another possible implementation, the MCU includes: an ADC component, a BIST component; a determination module 1601, which is specifically used to determine that a hardware failure occurs in the ADC component when a self-test result of the ADC component meets a first preset condition; the first preset condition is that the self-test result of the ADC component includes at least one of the following: a self-test sequence error, an ADC self-test timeout, and a self-test algorithm error; when the self-test result of the BIST component meets a second preset condition, it is determined that a hardware failure occurs in the BIST component; the second preset condition is that the self-test result of the BIST component includes at least one of the following: a phase-locked loop PLL is unlocked, a BIST self-test timeout, and a self-test configuration abnormality.

[0158] In another possible implementation, the MCU includes: a CMU component, a RegProt component and an MPU component; a determination module 1601 is specifically used to determine that a software failure has occurred in the CMU component when a self-test result of the CMU component indicates that the clock frequency of the MCU is not within a preset clock frequency range; when a self-test result of the RegProt component indicates that a register of the MCU has been tampered with, determine that a software failure has occurred in the RegProt; when a self-test result of the MPU component indicates that an unexpected access has occurred to the memory address segment of the MCU, determine that a software failure has occurred in the MPU.

[0159] In another possible implementation, the reporting module 1603 is further configured to report fault information of a motor controller failure when the power-on duration exceeds a preset duration.

[0160] According to the above technical means, the chip-level faults of the control chip of the motor controller are monitored, and the faults are processed based on the fault type. Targeted measures are taken for different types of faults to keep the motor controller running efficiently and reduce maintenance costs. In addition, the hardware faults and software faults in the motor controller are identified, the fault recognition rate is improved, and thus the stability and safety of the motor controller are improved.

[0161] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0162] Fig.17 FIG. 1 is a block diagram of a vehicle according to an exemplary embodiment. Fig.17 As shown, vehicle 1700 includes, but is not limited to, a processor 1701 and a memory 1702 .

[0163] The memory 1702 is used to store executable instructions of the processor 1701. It can be understood that the processor 1701 is configured to execute instructions to implement the fault handling method in the above embodiment.

[0164] It should be noted that those skilled in the art can understand that Fig.17 The vehicle structure shown in the figure does not constitute a limitation on the vehicle, and the vehicle may include Fig.17 More or fewer components may be shown, or certain components may be combined, or the components may be arranged differently.

[0165] The processor 1701 is the control center of the vehicle, which uses various interfaces and lines to connect various parts of the entire vehicle, and executes various functions of the vehicle and processes data by running or executing software programs and / or modules stored in the memory 1702, and calling data stored in the memory 1702, so as to monitor the vehicle as a whole. The processor 1701 may include one or more processing units. Optionally, the processor 1701 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 1701.

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

[0167] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1702 including instructions, and the above instructions can be executed by the processor 1701 of the vehicle 1700 to implement the fault handling method in the above embodiment.

[0168] In actual implementation, Fig.16 The functions of the determination module 1601, the statistics module 1602, the reporting module 1603, the acquisition module 1604 and the verification module 1605 can all be implemented by Fig.17 The processor 1701 in the embodiment calls the computer program stored in the memory 1702 to implement. The specific execution process can refer to the description of the method part in the above embodiment, which will not be repeated here.

[0169] Optionally, the computer-readable storage medium may be a non-temporary computer-readable storage medium, for example, the non-temporary computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0170] In an exemplary embodiment, the embodiment of the present application also provides a computer program product including one or more instructions, which can be executed by the vehicle's processor 1701 to complete the fault handling method in the above embodiment.

[0171] It should be noted that when the instructions in the above-mentioned computer-readable storage medium or one or more instructions in the computer program product are executed by the vehicle's processor, the various processes of the above-mentioned method embodiment are implemented, and the same technical effect as the above-mentioned method can be achieved. To avoid repetition, they will not be repeated here.

[0172] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned 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.

[0173] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0174] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0175] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0176] If the integrated unit is implemented in the form of 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 embodiment of the present application is essentially or the part that contributes to the prior art or the full classification part or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including a number of instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute the full classification part or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, ROM, RAM, disk or CD and other media that can store program code.

[0177] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A fault handling method, It is characterized in that The method comprises: In the case where a control chip MCU of the motor controller is detected to have a fault, determining the fault type of the MCU; the fault type includes: software fault and hardware fault; Based on the fault type, determine a first fault handling strategy; the first fault handling strategy includes: when the fault type is the hardware fault, report the identification information of the faulty hardware in the MCU; when the fault type is the software fault, reset the MCU.

2. The method according to claim 1, It is characterized in that The method further comprises: When the fault type is the software fault, counting the number of times the software fault occurs in the target software in the MCU; When the number exceeds a preset number, identification information of the hardware carrying the target software is reported.

3. The method according to claim 1 or 2, It is characterized in that The resetting of the MCU includes: reducing the level of a fault reset pin of the MCU from a high level to a low level.

4. The method according to claim 1 or 2, It is characterized in that The method further comprises: Obtaining the power-on duration of the motor controller; When the power-on time does not exceed the preset time, performing parameter verification on the driver chip based on the parameter verification mechanism of the driver chip of the motor controller to obtain a verification result; Based on the verification result, it is determined whether the driver chip fails.

5. The method according to claim 4, It is characterized in that The method further comprises: In the event that the driver chip fails, obtaining the operating state of the vehicle driven by the motor controller; Based on the operating state, a second fault handling strategy is determined; the second fault handling strategy includes: when the operating state is a non-driving mode, powering off and resetting the drive chip; when the operating state is a driving mode, reporting fault information of a fault in the drive chip.

6. The method according to claim 1 or 2, It is characterized in that The hardware failure includes an analog-to-digital converter ADC failure and / or a built-in self-test BIST failure; the software failure includes at least one of the following: a clock watchdog unit CMU failure, a register protection RegProt failure, and a memory protection unit MPU failure.

7. The method according to claim 6, It is characterized in that The MCU includes: an ADC component and a BIST component; and the determining of the fault type of the MCU includes: When the self-test result of the ADC component satisfies a first preset condition, determining that a hardware failure occurs in the ADC component; the first preset condition is that the self-test result of the ADC component includes at least one of the following: a self-test sequence error, an ADC self-test timeout, or a self-test algorithm error; When the self-test result of the BIST component meets a second preset condition, it is determined that a hardware failure occurs in the BIST component; the second preset condition is that the self-test result of the BIST component includes at least one of the following: phase-locked loop PLL loss of lock, BIST self-test timeout, and self-test configuration abnormality.

8. The method according to claim 6, It is characterized in that The MCU includes: a CMU component, a RegProt component, and an MPU component; and determining the fault type of the MCU includes: When the self-test result of the CMU component indicates that the clock frequency of the MCU is not within a preset clock frequency range, determining that a software failure occurs in the CMU component; In the case where the self-test result of the RegProt component indicates that the register of the MCU has been tampered with, determining that a software failure occurs in the RegProt; When the self-test result of the MPU component indicates that unexpected access occurs to the memory address segment of the MCU, it is determined that a software failure occurs in the MPU.

9. The method according to claim 4, It is characterized in that The method further comprises: When the power-on time exceeds the preset time, fault information indicating that the motor controller has failed is reported.

10. A fault handling device, It is characterized in that The device comprises: A determination module is used to determine the fault type of the control chip MCU of the motor controller when a fault is detected; the fault type includes: software fault and hardware fault; The determination module is also used to determine a first fault handling strategy based on the fault type; the first fault handling strategy includes: when the fault type is the hardware fault, reporting the identification information of the faulty hardware in the MCU; when the fault type is the software fault, resetting the MCU.

11. A motor controller, It is characterized in that The motor controller is configured to execute the method according to any one of claims 1 to 9.

12. A vehicle, It is characterized in that include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method as claimed in any one of claims 1 to 9.

13. A computer-readable storage medium, It is characterized in that When the computer-executable instructions stored in the computer-readable storage medium are executed by a processor of a vehicle, the vehicle is capable of performing the method of any one of claims 1 to 9.

14. A computer program product, It is characterized in that The computer program product comprises computer instructions which, when executed on a vehicle, cause the vehicle to perform the method according to any one of claims 1 to 9.

Images