A method, apparatus, computer equipment, and vehicle for controlling electric drive faults.

Abstract

This invention relates to the field of drive system control, and discloses an electric drive fault control method, device, computer equipment, and vehicle. The method includes: responding to a fault trigger signal output by the hardware layer of the electric drive system; monitoring the low-level duration of the fault trigger signal through the software layer of the electric drive system, and determining the fault type of the electric drive system based on the low-level duration; and controlling the electric drive system to perform corresponding actions based on the fault type. This invention solves the problem in the prior art where the fixed fault analysis time makes it impossible to distinguish between intermittent noise and continuous real faults, resulting in frequent false alarms and missed alarms in drive link protection.

Description

Technical Field

[0001] This invention relates to the field of drive system control, and more specifically to an electric drive fault control method, device, computer equipment, and vehicle. Background Technology

[0002] The electric drive system of new energy vehicles is centered on the motor controller, which uses power semiconductor devices such as Insulated Gate Bipolar Transistors (IGBTs) to achieve power conversion and motor control. The gate drive circuit, as a key driving unit for the IGBT, is responsible for converting control signals into drive signals adapted to the IGBT switches. In actual operation, the motor is prone to gate drive faults due to abnormal conditions such as sudden load changes, short circuits, power fluctuations, or insufficient heat dissipation. If protection is not timely, it will lead to IGBT damage, affecting the reliability of the motor controller and even the entire vehicle. Therefore, existing technologies generally adopt a collaborative protection mechanism of "hardware detection + software response." Hardware detects fault signals (such as a low level on the FLT pin) and triggers protection actions, while the software layer handles fault coding and system control.

[0003] However, this existing technology has significant shortcomings in terms of timing analysis: its fault analysis time is fixed (e.g., 4.5ms), making it unable to effectively distinguish between "intermittent noise pulses" and "persistent real faults" based on the duration of the fault signal. This makes the system susceptible to false triggering of protection due to brief interference, generating a large number of No Trouble Found (NTF) codes without actual faults, increasing the complexity of subsequent analysis and the risk to vehicle reliability. Furthermore, due to the lack of dynamic adaptability in the analysis time, the system is prone to false alarms or missed alarms when facing complex operating conditions, making it difficult to achieve accurate fault type identification and differentiated processing. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide an electric drive fault control method, device, computer equipment, and vehicle to solve the problem in the prior art that the fixed fault analysis time makes it impossible to distinguish between occasional noise and continuous real faults, resulting in frequent false alarms and missed alarms in drive link protection.

[0005] In a first aspect, embodiments of the present invention provide an electric drive fault control method, the method comprising: Responding to the fault trigger signal output by the hardware layer of the electric drive system; The low-level duration of the fault trigger signal is monitored by the software layer of the electric drive system, and the fault type of the electric drive system is determined based on the low-level duration. Based on the fault type, the electric drive system is controlled to perform the corresponding action.

[0006] Furthermore, prior to responding to a fault trigger signal output by the electric drive system hardware layer, the method further includes: The electrical parameters associated with the drive link are monitored through the hardware layer of the electric drive system; The electrical parameters are compared with electrical parameter thresholds to obtain a first comparison result; When the first comparison result is that the electrical parameter is greater than the electrical parameter threshold, the hardware layer of the electric drive system is controlled to enter a temporary protection mode. In the temporary protection mode, the automatic shutdown control logic is executed to limit the output of the gate drive circuit and output a fault trigger signal.

[0007] Furthermore, determining the fault type of the electric drive system based on the duration of the low-level signal includes: The duration of the low level is compared with a duration threshold to obtain a second comparison result; When the second comparison result is that the low-level duration is less than the duration threshold, the fault type is determined to be the first type; or, when the second comparison result is that the low-level duration is greater than or equal to the duration threshold, the fault type is determined to be the second type.

[0008] Furthermore, controlling the electric drive system to perform corresponding actions based on the fault type includes: When the fault type is the first type, the hardware layer of the electric drive system is controlled to exit the temporary protection mode and output a fault clearance signal. When the fault type is the second type, the software layer of the control electric drive system enters the protection mode. In the protection mode, the output of control signals to the gate drive circuit is stopped, the corresponding fault analysis code is generated according to the fault trigger signal, the fault prompt operation is executed, and the system status information associated with the fault trigger signal is latched.

[0009] Furthermore, after controlling the electric drive system to perform the corresponding action based on the fault type, the method further includes: Trigger a reset operation on the electric drive system and control the electric drive system to enter the reset verification window; Within the reset verification window, a first detection parameter associated with the fault trigger signal is acquired at a first frequency; Based on the first detection parameter, the electric drive system is controlled to perform the corresponding action.

[0010] Furthermore, controlling the electric drive system to perform corresponding actions based on the first detection parameter includes: Determine whether the first detection parameter is within the target parameter range within a preset number of sampling periods; If the first detection parameter is within the target parameter range for a preset number of sampling periods, a fault prevention mechanism is triggered to perform a verification operation on the electric drive system; or, if the first detection parameter is not within the target parameter range for a preset number of sampling periods, the electric drive system is re-controlled to perform a protection operation.

[0011] Furthermore, the fault prevention mechanism performs a verification operation on the electric drive system, including: During operation of the electric drive system, the second detection parameter is acquired at a second frequency; When the electric drive system is powered on again after hibernation, the trigger signal output by the hardware layer of the electric drive system is monitored; Based on the second detection parameter and the trigger signal, it is determined whether the electric drive system is in a fault recurrence state; When the fault recurrence state occurs, the electric drive system is re-controlled to perform protection operations; or, when the fault recurrence state is not occurring, the normal operation state of the electric drive system is restored.

[0012] Secondly, embodiments of the present invention provide an electric drive fault control device, the device comprising: The response module is used to respond to fault trigger signals output by the hardware layer of the electric drive system; The monitoring module is used to monitor the low-level duration of the fault trigger signal through the electric drive system software layer, and determine the fault type of the electric drive system based on the low-level duration. The control module is used to control the electric drive system to perform corresponding actions based on the fault type.

[0013] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in any of the above-mentioned embodiments.

[0014] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that cause a computer to perform the methods described in any of the preceding claims.

[0015] Fifthly, embodiments of the present invention provide a vehicle, including: a controller, the controller including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in any of the above-mentioned embodiments.

[0016] The method provided in this application has the following beneficial effects: The method provided in this application, by responding to the fault trigger signal output by the hardware layer of the electric drive system, achieves real-time capture and rapid hardware-level triggering of abnormal system conditions, providing a timely input basis for subsequent accurate analysis and protection at the software layer. By monitoring the low-level duration of the fault trigger signal at the software layer of the electric drive system and determining the fault type accordingly, it effectively distinguishes between transient interference (such as intermittent noise pulses) and real, continuous faults, overcoming the problem of false alarms or missed alarms that are easily caused by traditional fixed analysis time, and significantly reducing the occurrence rate of fault codes. Based on the fault type, the method controls the electric drive system to execute corresponding actions, realizing differentiated protection strategies for different fault types. While ensuring system safety, it avoids unnecessary protection actions and improves the reliability of the electric drive system and the robustness of the entire vehicle in complex operating environments. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an electric drive fault control method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating another electric drive fault control method according to an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the working principle of the electric drive fault control architecture according to an embodiment of the present invention; Figure 4 This is a flowchart illustrating another electric drive fault control method according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the reset and verification mechanism for electric drive fault control according to an embodiment of the present invention; Figure 6 This is a timing diagram for resetting and verifying electric drive fault control according to an embodiment of the present invention; Figure 7 This is a structural block diagram of an electric drive fault control device according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] According to embodiments of the present invention, an electric drive fault control method, apparatus, computer equipment, and vehicle are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0021] This embodiment provides an electric drive fault control method. Figure 1 This is a flowchart of an electric drive fault control method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101, responding to the fault trigger signal output by the electric drive system hardware layer.

[0022] In this embodiment, the software layer (typically referring to the analysis program in the microcontroller) captures and identifies electrical signals actively generated by the hardware layer that characterize system anomalies, and uses these signals as trigger conditions to initiate subsequent software analysis and protection processes. The fault trigger signal is generated by the hardware layer of the electric drive system (mainly referring to the gate driver chip, such as the IA51 chip) after autonomously detecting an anomaly. The hardware layer monitors electrical parameters directly related to the drive link in real time (such as motor phase current, DC bus voltage, IGBT junction temperature, or gate drive voltage). When any parameter exceeds its preset safety threshold (e.g., current > 1400A), the hardware layer immediately changes the level of its specific fault indicator pin (typically the FLT pin) as an output. In this scheme, the FLT pin changing from high to low (i.e., "Fault signal is L") represents the output of a valid fault trigger signal. This process is purely hardware-based, with extremely high response speed (microseconds), ensuring that anomalies are detected immediately.

[0023] Specifically, the software layer continuously samples or monitors the voltage level on the line connected to the FLT pin via the microcontroller unit's (MCU) general-purpose input / output (GPIO) ports or dedicated interrupt pins. If the software detects that the pin's voltage level changes from high to low (i.e., a falling edge is captured), it indicates that the condition is met, and a response action is triggered. This response in software logic manifests as: starting a timer for the fault trigger signal (the timer is used for duration monitoring) and setting the internal fault flag for the fault trigger signal, notifying the system that it has entered an abnormal, analysis-pending state triggered by hardware detection. At this point, the hardware layer itself may have already initiated its built-in primary protection mechanisms (such as automatic shutdown control, i.e., hardware ASC logic), but the software layer's response is a necessary prerequisite and entry point for the subsequent execution of intelligent and differentiated software protection strategies.

[0024] Step S102: Monitor the low-level duration of the fault trigger signal through the electric drive system software layer, and determine the fault type of the electric drive system based on the low-level duration.

[0025] In this embodiment, monitoring the low-level duration of a fault trigger signal through the software layer of the electric drive system includes: after the software layer (e.g., the analysis program in the microcontroller) responds to the fault trigger signal output by the hardware layer (e.g., the FLT pin goes low), it initiates a software timing process to measure the actual duration the signal remains in a low-level state. Specifically, the software layer immediately resets and starts an internal timer (which can be a software counter or a hardware timer) the instant it receives a valid edge (e.g., a falling edge) of the fault trigger signal. Subsequently, the software continuously reads and judges the level state of the fault trigger signal pin at a high frequency (e.g., sampling every 100 microseconds via a timer interrupt). As long as the signal remains low, the timer continues to accumulate; when the software detects that the signal returns to a high level (rising edge), it immediately stops timing. The total time accumulated by the timer from start to stop is the low-level duration to be monitored. This process, by actively measuring the actual duration of the hardware anomaly signal through software, provides a unique and crucial quantitative basis for the next step of fault classification based on time thresholds.

[0026] In this embodiment of the application, determining the fault type of the electric drive system based on the duration of the low level includes: comparing the duration of the low level with a duration threshold to obtain a second comparison result; when the second comparison result is that the duration of the low level is less than the duration threshold, determining the fault type as a first type; or, when the second comparison result is that the duration of the low level is greater than or equal to the duration threshold, determining the fault type as a second type.

[0027] Specifically, after monitoring the duration of the low-level signal, the software layer compares this time value with a preset duration threshold (e.g., 16ms) to obtain a second comparison result. This comparison result directly determines the fault classification: when the second comparison result shows that the low-level duration is less than the duration threshold, it indicates that the abnormal state is short-lived, and the software layer classifies it as a first-type fault (usually corresponding to intermittent noise or transient interference); conversely, when the second comparison result shows that the low-level duration is greater than or equal to the duration threshold, it indicates that the abnormal state is persistent, and the software layer classifies it as a second-type fault (usually corresponding to a real, persistent hardware fault). This judgment logic, by introducing a configurable time threshold as a classification standard through software, achieves accurate and automated classification based on the duration of the fault signal, providing a clear basis for subsequent execution of differentiated protection actions.

[0028] By comparing the duration of a low-level signal with a duration threshold to obtain a second comparison result, a software-configurable time window is introduced as the core criterion, achieving flexibility and adaptability in the analysis standard. When the second comparison result indicates a duration shorter than the threshold, it is classified as a first-type fault (such as intermittent noise), enabling the system to effectively filter brief pulse interference and avoid unnecessary protection actions triggered by transient noise, thereby significantly reducing the incidence of fault-free codes. When the second comparison result indicates a duration reaching or exceeding the threshold, it is classified as a second-type fault (such as a persistent fault), ensuring the identification of persistent hardware anomalies. This solves the problem that a fixed analysis time cannot distinguish between transient interference and real faults, achieving accurate fault type differentiation and improving the accuracy and reliability of the protection system.

[0029] Step S103: Control the electric drive system to perform the corresponding action based on the fault type.

[0030] In this embodiment of the application, the electric drive system is controlled to perform corresponding actions based on the fault type, including: Step A1: When the fault type is Type 1, the hardware layer of the control electric drive system exits the temporary protection mode and outputs a fault clearance signal.

[0031] Specifically, when the software layer determines the fault type to be Type 1 (corresponding to intermittent noise or transient interference) based on the duration of the low-level signal, it generates and sends a specific control command to the hardware layer. This command instructs the hardware layer to exit the temporary protection mode it autonomously entered during the initial stage of the abnormality (i.e., to stop executing the automatic shutdown control logic and remove the restriction on the output of the gate drive circuit), thereby restoring the hardware drive link to normal operation. Simultaneously, the software layer outputs a clear fault clearance signal internally or through the communication interface. This signal indicates to other management units or the log system that the triggered abnormality has been identified and processed as a transient event, requiring no further serious fault handling procedures such as fault coding or state latching, and normal operation can continue. The core function of this step is to promptly cancel the hardware protection state triggered by a brief interference based on the software's judgment, minimizing interruptions to normal system operation and avoiding functional degradation or false alarms due to misjudgment.

[0032] Step A2: When the fault type is the second type, the software layer of the control electric drive system enters the protection mode. In the protection mode, the output of control signals to the gate drive circuit is stopped, the corresponding fault analysis code is generated according to the fault trigger signal, the fault prompt operation is executed, and the system status information associated with the fault trigger signal is latched.

[0033] Specifically, when the software layer determines the fault type to be Type II (i.e., a persistent fault), it immediately switches its state to protection mode. In this mode, the core software operations include: Stopping the output of control signals to the gate drive circuit: This actively blocks the pulse width modulation (PWM) drive signal sent to the IGBT, fundamentally cutting off power output under abnormal operating conditions and preventing device damage; Generating corresponding fault analysis codes: Based on the source and characteristics of the fault trigger signal that triggered this protection, the software maps and generates a specific fault analysis code (DTC) to identify the fault; Performing fault prompting operations: Sending alarm information via the controller area network bus or directly controlling the fault indicator light on the instrument panel to inform the user; Latching system status information: The software saves key parameters (such as current, voltage, and temperature values) and related timing information at the moment the fault occurs and before and after in non-volatile memory, forming a fault snapshot for subsequent analysis. The above actions constitute the structured response process of the software layer to confirmed persistent faults.

[0034] By controlling the hardware layer to exit temporary protection mode and output a fault clearance signal when the fault type is Type 1, the system can quickly and automatically recover to normal operation after being identified as an interference, minimizing unnecessary interruptions to the driving process and system functions, and improving system availability and user experience. By controlling the software layer to enter protection mode, stop outputting drive signals, generate fault analysis code, execute fault prompts and latch status information when the fault type is Type 2, a handling process for confirmed persistent faults is formed, realizing fault isolation and accurate recording, clear alarms and status traceability, ensuring that faults are handled in a timely manner, and providing complete information for subsequent analysis. At the same time, the software latching solves the problem of hardware lacking state memory.

[0035] In this embodiment of the application, before responding to the fault trigger signal output by the electric drive system hardware layer, such as Figure 2 As shown, the method also includes: Step S201: Monitor electrical parameters associated with the drive link through the hardware layer of the electric drive system.

[0036] In this embodiment, the core function of the electric drive system hardware layer (mainly referring to the gate driver chip and its peripheral detection circuits) is to autonomously and continuously measure and acquire physical quantities related to the drive link (i.e., the power transfer and control path from the controller to the IGBT and then to the motor) using built-in or external sensors and detection circuits. Electrical parameters include, but are not limited to, key signals such as the motor phase current flowing through the IGBT, DC bus voltage, IGBT junction temperature or heatsink temperature, and gate drive voltage. The hardware layer constructs a detection loop using high-precision sampling resistors, voltage divider networks, temperature sensors, and dedicated fault detection pins (such as SCPIN), continuously converting these analog or state quantities into electrical signals that can be recognized by the chip's internal logic at microsecond-level speeds. Monitoring the electrical parameters associated with the drive link is the data source for subsequent fault diagnosis and protection, aiming to provide raw physical information for real-time monitoring of the drive link's operating status.

[0037] Step S202: Compare the electrical parameters with the electrical parameter thresholds to obtain the first comparison result.

[0038] In this embodiment, the comparison logic circuit within the gate driver chip, specifically the hardware layer of the electric drive system, performs the comparison in real time. It compares the instantaneous or sampled value of each continuously monitored electrical parameter (such as current or voltage) with its pre-set and hardware-embedded electrical parameter thresholds (e.g., overcurrent threshold of 1400A, undervoltage threshold, overtemperature threshold, etc.). This comparison process is accomplished by a hardware comparator or a dedicated detection module with threshold judgment functionality. Its output is a binary logic signal, namely the first comparison result. This result directly indicates whether the monitored parameter exceeds the safe range: if the parameter value is greater than (or less than, depending on the threshold type) the corresponding threshold, the first comparison result is true or valid (usually corresponding to a specific level state, such as a high level); conversely, if the parameter is within the normal range, the result is false or invalid. This step is the direct basis for the hardware layer to autonomously determine anomalies and decide whether to trigger subsequent protection procedures. Its response speed is extremely fast, laying the foundation for rapid hardware-level protection.

[0039] Step S203: When the first comparison result is that the electrical parameter is greater than the electrical parameter threshold, the control electric drive system hardware layer enters the temporary protection mode. In the temporary protection mode, the automatic shutdown control logic is executed to limit the output of the gate drive circuit and output a fault trigger signal.

[0040] In this embodiment, when the first comparison result indicates that any monitored electrical parameter (such as current) exceeds its corresponding electrical parameter threshold, the electric drive system hardware layer (mainly referring to the gate driver chip) autonomously performs three key operations to control damage: Entering temporary protection mode: The internal state machine of the hardware switches to protection mode; this mode is a preset fast response mechanism of the hardware. Executing automatic shutdown control logic: In this mode, the hardware immediately activates its built-in ASC (Automatic Shutdown Control) function, which forces the gate driver circuit to stop or greatly restrict its normal switching signal output, thereby quickly shutting down the IGBT and preventing damage such as overcurrent and shoot-through from escalating. Outputting a fault trigger signal: The hardware layer almost synchronously generates a fault trigger signal by changing the level of a specific fault indicator pin (such as the FLT pin) (e.g., pulling it from high to low). This signal serves as a clear indication that the hardware has detected an anomaly and is sent to the software layer to trigger subsequent collaborative analysis and processing. This high-speed, independent hardware operation constitutes the first line of defense in the protection response.

[0041] As an example, such as Figure 3As shown, the working principle of the electric drive fault control architecture includes: the SCPIN signal (containing noise or fault signals) is first processed by the filtering circuit (RAC3D+C1+C2) to obtain a clean signal, which is then transmitted to the gate driver chip (IA51); after the gate driver chip (hardware layer) detects that the electrical parameters exceed the threshold, it enters the temporary protection mode to perform automatic shutdown control, limit the gate drive output, and at the same time pulls the FLT pin level low to output a fault trigger signal and sends the gate drive level signal to the diagnostic software; the diagnostic software samples the level and times it. If the low level duration is <16ms, it is determined to be intermittent interference (first type of fault), and no protection action is performed and the control hardware layer exits the temporary protection mode; if the duration is ≥16ms, it is determined to be a persistent fault (second type of fault), and speed and torque commands are sent to the protection execution unit to perform the protection action of blocking PWM and lighting the TC fault light, while simultaneously latching the fault status information.

[0042] By monitoring electrical parameters associated with the drive link at the hardware layer of the electric drive system, real-time perception of risks such as overcurrent, overvoltage, and overheating is achieved, providing the original physical signal basis for fault identification. By comparing electrical parameters with electrical parameter thresholds and obtaining the first comparison result, the hardware layer can automatically complete the preliminary logical judgment of abnormal states, creating conditions for immediate response. When the first comparison result is abnormal, the hardware layer is controlled to enter a temporary protection mode, execute automatic shutdown control logic, and limit the output of the gate drive circuit, achieving primary rapid protection of power devices within microseconds, effectively preventing the instantaneous expansion of fault damage. At the same time, by synchronously outputting fault trigger signals, a trigger flag is provided for subsequent precise analysis and collaborative protection at the software layer, providing a collaborative basis for rapid hardware disconnection and precise software control.

[0043] In this embodiment of the application, after the electric drive system is controlled to perform the corresponding action based on the fault type, such as Figure 4 As shown, the method also includes: Step S301: Trigger a reset operation on the electric drive system and control the electric drive system to enter the reset verification window.

[0044] In this embodiment, after executing the corresponding protection actions based on the fault type (especially operations such as wave blocking and code reporting for the second type of persistent fault), the software layer (i.e., the analysis software or main control program) does not passively wait, but actively triggers a reset operation on the electric drive system control core (such as an MCU) or its fault management unit. The reset aims to clear the temporary latched state triggered by the fault, creating conditions for possible recovery. Subsequently, the software layer does not allow the system to directly resume normal operation, but controls the entire system to enter a software-defined and managed reset verification window. This window is a preset time period (e.g., in milliseconds). During this window, the system remains in a restricted, pending verification state. The software layer initiates a high-frequency detection process to actively verify whether the abnormal conditions that triggered the previous protection have been completely eliminated, thereby providing a strict basis for determining whether the system can be allowed to fully recover subsequently.

[0045] Step S302: Within the reset verification window, acquire the first detection parameter associated with the fault trigger signal at a first frequency.

[0046] In this embodiment, after entering the software-controlled reset verification window, the software layer initiates a high-frequency sampling task. This task periodically performs data acquisition at a first frequency (i.e., a preset high sampling rate, such as once every 100 microseconds). During each acquisition, the software reads and records a specific set of first detection parameters. These parameters are key variables associated with the fault trigger signal and directly reflect whether the previous fault state still exists. They mainly include: the state of the original fault trigger signal itself that triggered this protection process (such as the current real-time level of the FLT pin), and other verification parameters related to the fault logic (such as the overcurrent value and voltage value when the fault occurred). By continuously acquiring these parameters at a high frequency, the software aims to obtain a continuous and dense snapshot of the system state within the reset verification window, providing a real-time data basis for determining whether the anomaly has been completely eliminated.

[0047] Step S303: Control the electric drive system to perform the corresponding action based on the first detection parameter.

[0048] In this embodiment, an evaluation algorithm is executed based on the real-time data sequence of the first detection parameters (such as FLT pin level, current value, etc.) acquired at high frequency, and the next step of the system is determined accordingly. Specifically, the evaluation algorithm involves the software first performing a judgment, checking whether all relevant first detection parameters are within their respective custom target parameter ranges (i.e., normal threshold ranges) within a consecutive preset number of sampling periods (e.g., two consecutive periods). If the judgment is yes, a subsequent fault prevention mechanism is triggered to perform a deeper verification operation, indicating that the initial reset verification has been passed and the system can enter a more complex recovery evaluation stage. If the judgment is no, it indicates that the abnormal state has reappeared or persisted within the verification window, and the software will re-control the electric drive system to perform protection operations (i.e., return to the protection process such as wave blocking and code reporting) to prevent risky resumption of operation before the fault is eliminated.

[0049] By triggering a reset operation on the electric drive system and controlling it to enter the reset verification window, the risks that may arise from blindly resuming operation directly after fault handling are avoided, and a dedicated safe transition phase is set up for verifying the stability of the system state. By collecting the first detection parameters related to the fault at the first frequency within the reset verification window, high-frequency continuous monitoring of whether the fault has been eliminated is achieved, providing real-time data support for verification decisions. By controlling the electric drive system to execute subsequent actions based on the first detection parameters, the recovery process is transformed from a simple timing operation into an intelligent decision-making process based on real-time data feedback, thus constructing an active safety verification mechanism after fault handling and improving the safety and reliability of system recovery.

[0050] In this embodiment of the application, controlling the electric drive system to perform corresponding actions based on the first detection parameter includes: Step B1: Determine whether the first detection parameter is within the target parameter range within a preset number of sampling periods.

[0051] Specifically, the software layer processes the data stream of the first detection parameter (e.g., FLT pin level, current value, etc.) acquired at the first frequency: a maintenance counter or state machine is used to track the number of consecutive successful samplings. After each acquisition, the software compares the current parameter value with its respective target parameter range (i.e., the preset normal operating threshold range); only when all parameters in this sampling are within their corresponding normal range is it counted as a valid sampling. Then, the software performs a core judgment: checking whether the number of consecutive valid samplings has reached a preset number (e.g., two consecutive cycles). This logic requires that after the abnormal state is eliminated, the parameter must remain stable within the normal range for a continuous period of time (not just instantaneously), thereby effectively filtering out glitches or brief fluctuations during the reset process, ensuring that only the truly stable system state can pass verification, providing a reliable decision-making basis for subsequent operations.

[0052] Step B2: If the first detection parameter is within the target parameter range for a preset number of sampling periods, the fault prevention mechanism is triggered to perform a verification operation on the electric drive system; or, if the first detection parameter is not within the target parameter range for a preset number of sampling periods, the electric drive system is re-controlled to perform a protection operation.

[0053] Specifically, branching is performed based on the judgment result. If the judgment result is yes (i.e., the first detection parameter is within the target parameter range for a preset number of sampling periods), the software layer executes the first branch: triggering a long-term fault prevention mechanism. This mechanism aims to perform more continuous state verification operations on the electric drive system to further confirm that the fault has been completely eliminated and the system has the conditions for stable recovery. Alternatively, if the judgment result is no (i.e., the parameter is not within the normal range for the required time), the software layer executes the second branch: immediately terminating the reset verification process and re-controlling the electric drive system to perform protection operations, i.e., restarting the comprehensive protection process such as wave blocking and code reporting to prevent the system from being erroneously restored before the abnormal state is eliminated, thereby ensuring safety.

[0054] By determining whether the first detection parameter is within the target parameter range for a preset number of consecutive sampling periods, it distinguishes between instantaneous normality and continuous stability, filtering out signal glitches or brief fluctuations that may occur during the reset process. This ensures that only truly stable healthy states can pass verification, improving the accuracy of state determination. If verification is successful, a fault prevention mechanism is triggered to perform further verification operations, extending the protection logic from single-event processing to long-term state monitoring, achieving a deeper level of safety confirmation. If verification fails, the system is re-controlled to perform protection operations, ensuring that the system will never be incorrectly put into operation before the anomaly is completely eliminated. This solves the problem of secondary faults or safety risks that may be caused by improper reset, forming a closed-loop protection logic.

[0055] In this embodiment of the application, triggering a fault prevention mechanism to perform a verification operation on the electric drive system includes: Step B201: During the operation of the electric drive system, the second detection parameter is acquired at the second frequency.

[0056] Specifically, once the electric drive system enters normal operation after passing the previous reset verification, the software layer initiates a resident background monitoring task. This task continuously acquires data at a second frequency (i.e., a typically high periodic sampling rate, such as once every 100 microseconds). During each acquisition, the software reads and records a set of second detection parameters. These parameters are key variables that broadly reflect the real-time health status of the system and may include physical quantities closely related to the safety of the drive link, such as motor current, DC bus voltage, and power device temperature. By acquiring these parameters at a fixed high frequency to construct a continuous data stream, the aim is to capture any abnormal fluctuations or trends that may occur during operation in real time, providing comprehensive status information for subsequent fault recurrence determination, thereby achieving preventative monitoring during operation.

[0057] Step B202: When the electric drive system is powered on again after hibernation, monitor the trigger signal output by the hardware layer of the electric drive system.

[0058] Specifically, as a verification method for a specific system lifecycle within the fault prevention mechanism, when the electric drive system undergoes a hibernation period (low power or complete power-off state) and subsequently powers on again (completing power and logic initialization), the software layer activates a monitoring routine during this critical startup phase. The task of this routine is to monitor trigger signals from the electric drive system's hardware layer, specifically checking the level of a particular pin (such as the FLT pin) used to indicate hardware faults, to determine whether it output a valid fault indication (e.g., a low level) at the critical moment of system initialization. This operation aims to identify potential persistent hardware faults that might only surface during system cold starts or reset initialization, providing a secondary verification of whether the fault has been eradicated. This adds safety checks before the system restarts, ensuring the comprehensive coverage of the fault prevention mechanism.

[0059] Step B203: Determine whether the electric drive system is in a fault recurrence state based on the second detection parameter and the trigger signal.

[0060] Specifically, the software makes a comprehensive judgment based on two types of input information: first, the second detection parameters (such as real-time data streams of current and voltage during operation) continuously collected at a second frequency. The software compares these parameters with their respective normal threshold ranges in real time to check for any abnormal exceedances; second, the trigger signals that the electric drive system hardware layer may output upon power-on (such as the level state of the FLT pin). The software integrates and analyzes these two aspects of information through logical relationships: if the second detection parameter remains abnormal during operation, or if a valid trigger signal is captured immediately upon power-on, the software determines that the electric drive system is in a fault recurrence state; conversely, if both aspects of information remain normal, it is determined that there is no recurrence. This judgment result is the key basis for deciding whether the system should re-enter protection mode or maintain normal operation.

[0061] Step B204: When the fault recurrence state is in effect, the electric drive system is re-controlled to perform protection operations; or, when the fault recurrence state is not in effect, the normal operation state of the electric drive system is restored.

[0062] Specifically, when the software determines that the system is in a recurring fault state, it will re-control the electric drive system to perform protection operations, that is, interrupt the current preventive monitoring process and re-invoke the full protection process (including wave blocking, code reporting, etc.) to deal with the recurring fault. Alternatively, when the software determines that it is not in a recurring fault state, it will restore the electric drive system to its normal operating state, that is, exit or reduce the intensity of preventive monitoring, allowing the system to continue operating fully according to normal control logic, thereby maximizing the availability and continuity of the system while ensuring safety. Completing the closed-loop processing based on the verification results is the final decision and state switching point of the proactive fault protection mechanism.

[0063] As an example, the reset and verification mechanism for electric drive fault control, such as Figure 5 As shown, the specific steps include: During normal operation of the electric drive system, the hardware layer monitors parameters such as current, voltage, and temperature in real time, while the software layer synchronously samples them periodically. When a parameter exceeds a threshold and triggers a fault, the hardware layer pulls the FLT pin low and initiates temporary ASC protection. Simultaneously, the software layer performs hardware-software coordinated protection actions, including waveform blocking, code reporting, fault light illumination, and fault information latching. Subsequently, the system enters the intelligent reset verification phase: The software layer uses high-frequency parameter detection to determine whether the parameters are stably within the normal range for N consecutive cycles. If the target is not met, the protection operation is re-executed. If the target is met, a continuous diagnostic and prevention mechanism is triggered. During operation, parameters are monitored at high frequency, and the hardware trigger signal is monitored a second time when the system is powered on again from sleep mode. The system comprehensively determines whether the fault has recurred. If it has recurred, the protection is restarted; otherwise, normal operation is maintained.

[0064] The timing diagram for reset and verification of electric drive fault control is as follows: Figure 6 As shown in the timing diagram, the electric drive system initially outputs a continuous PWM signal to maintain normal operation. When a fault is triggered, the FLT pin level is pulled low from 5V to 0V, simultaneously triggering a hardware ASC temporary PWM blocking. At this time, the software layer starts timing: if the duration of the FLT low level is t < 8ms (cumulative less than 16ms), the diagnosis is determined to be noise interference, and the process of blocking, unblocking, hardware reset, and software fault elimination is executed, without generating a DTC fault code; if the duration of the FLT low level is t ≥ 8ms (cumulative 16ms), the diagnosis is determined to be a real fault, triggering a DTC code and performing a complete PWM blocking operation to complete fault latching and alarm.

[0065] By collecting second detection parameters at a second frequency during the operation of the electric drive system, preventative monitoring of the system's health status is achieved, enabling proactive acquisition of recurring abnormal trends during operation. By monitoring hardware-level trigger signals when the system is powered on again after hibernation, specialized detection for the critical node of cold start is added, enabling the detection of potential hardware faults that only surface during the power-on initialization phase. By comprehensively determining whether the system is in a fault recurrence state by combining the second detection parameters and trigger signals, multi-dimensional, full-lifecycle fault recurrence monitoring and intelligent diagnosis are achieved. By selecting to re-execute protection operations or ultimately restore the system to normal operation based on the recurrence state determination result, a complete closed loop is completed from fault handling to verification, and then to long-term monitoring and safe recovery, improving the long-term accuracy and reliability of the electric drive system in the face of intermittent faults.

[0066] This embodiment also provides an electric drive fault control device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0067] This embodiment provides an electric drive fault control device, such as... Figure 7 As shown, it includes: The response module 71 is used to respond to the fault trigger signal output by the hardware layer of the electric drive system; The monitoring module 72 is used to monitor the low-level duration of the fault trigger signal through the electric drive system software layer, and determine the fault type of the electric drive system based on the low-level duration. The control module 73 is used to control the electric drive system to perform corresponding actions based on the fault type.

[0068] In this embodiment of the application, the device further includes: an output module, used to monitor electrical parameters associated with the drive link through the hardware layer of the electric drive system; compare the electrical parameters with electrical parameter thresholds to obtain a first comparison result; when the first comparison result is that the electrical parameters are greater than the electrical parameter thresholds, control the hardware layer of the electric drive system to enter a temporary protection mode, execute automatic shutdown control logic in the temporary protection mode, limit the output of the gate drive circuit, and output a fault trigger signal.

[0069] In this embodiment of the application, the monitoring module 72 is specifically used to compare the low-level duration with a duration threshold to obtain a second comparison result; when the second comparison result is that the low-level duration is less than the duration threshold, the fault type is determined to be the first type; or, when the second comparison result is that the low-level duration is greater than or equal to the duration threshold, the fault type is determined to be the second type.

[0070] In this embodiment, the control module 73 is specifically used to control the hardware layer of the electric drive system to exit the temporary protection mode and output a fault clearance signal when the fault type is the first type; and to control the software layer of the electric drive system to enter the protection mode when the fault type is the second type. In the protection mode, the control module stops outputting control signals to the gate drive circuit, generates corresponding fault analysis code according to the fault trigger signal, performs fault prompt operation, and latches the system status information associated with the fault trigger signal.

[0071] In this embodiment of the application, the device further includes: a verification module, used to trigger a reset operation on the electric drive system and control the electric drive system to enter a reset verification window; within the reset verification window, a first detection parameter associated with the fault trigger signal is acquired at a first frequency; and the electric drive system is controlled to perform corresponding actions based on the first detection parameter.

[0072] In this embodiment, the verification module is specifically used to determine whether the first detection parameter is within the target parameter range within a preset number of sampling periods; if the first detection parameter is within the target parameter range within a preset number of sampling periods, a fault prevention mechanism is triggered to perform a verification operation on the electric drive system; or, if the first detection parameter is not within the target parameter range within a preset number of sampling periods, the electric drive system is re-controlled to perform a protection operation.

[0073] In this embodiment, the verification module is specifically used to collect second detection parameters at a second frequency when the electric drive system is running; monitor the trigger signal output by the hardware layer of the electric drive system when the electric drive system is powered on again after hibernation; determine whether the electric drive system is in a fault recurrence state based on the second detection parameters and the trigger signal; when in a fault recurrence state, re-control the electric drive system to perform protection operations, or when not in a fault recurrence state, restore the normal operation state of the electric drive system.

[0074] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 8As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0075] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GPA), or any combination thereof.

[0076] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0077] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0078] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0079] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0080] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0081] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for controlling electric drive faults, characterized in that, The method includes: Responding to the fault trigger signal output by the hardware layer of the electric drive system; The low-level duration of the fault trigger signal is monitored by the software layer of the electric drive system, and the fault type of the electric drive system is determined based on the low-level duration. Based on the fault type, the electric drive system is controlled to perform the corresponding action.

2. The method according to claim 1, characterized in that, Prior to responding to a fault trigger signal output by the electric drive system hardware layer, the method further includes: The electrical parameters associated with the drive link are monitored through the hardware layer of the electric drive system; The electrical parameters are compared with electrical parameter thresholds to obtain a first comparison result; When the first comparison result is that the electrical parameter is greater than the electrical parameter threshold, the hardware layer of the electric drive system is controlled to enter a temporary protection mode. In the temporary protection mode, the automatic shutdown control logic is executed to limit the output of the gate drive circuit and output a fault trigger signal.

3. The method according to claim 1, characterized in that, The step of determining the fault type of the electric drive system based on the duration of the low level includes: The duration of the low level is compared with a duration threshold to obtain a second comparison result; When the second comparison result is that the low-level duration is less than the duration threshold, the fault type is determined to be the first type; or, when the second comparison result is that the low-level duration is greater than or equal to the duration threshold, the fault type is determined to be the second type.

4. The method according to claim 1 or 3, characterized in that, The step of controlling the electric drive system to perform corresponding actions based on the fault type includes: When the fault type is the first type, the hardware layer of the electric drive system is controlled to exit the temporary protection mode and output a fault clearance signal. When the fault type is the second type, the software layer of the control electric drive system enters the protection mode. In the protection mode, the output of control signals to the gate drive circuit is stopped, the corresponding fault analysis code is generated according to the fault trigger signal, the fault prompt operation is executed, and the system status information associated with the fault trigger signal is latched.

5. The method according to claim 1, characterized in that, After controlling the electric drive system to perform the corresponding action based on the fault type, the method further includes: Trigger a reset operation on the electric drive system and control the electric drive system to enter the reset verification window; Within the reset verification window, a first detection parameter associated with the fault trigger signal is acquired at a first frequency; Based on the first detection parameter, the electric drive system is controlled to perform the corresponding action.

6. The method according to claim 5, characterized in that, The step of controlling the electric drive system to perform corresponding actions based on the first detection parameter includes: Determine whether the first detection parameter is within the target parameter range within a preset number of sampling periods; If the first detection parameter is within the target parameter range for a preset number of sampling periods, a fault prevention mechanism is triggered to perform a verification operation on the electric drive system; or, if the first detection parameter is not within the target parameter range for a preset number of sampling periods, the electric drive system is re-controlled to perform a protection operation.

7. The method according to claim 6, characterized in that, The fault prevention mechanism performs a verification operation on the electric drive system, including: During operation of the electric drive system, the second detection parameter is acquired at a second frequency; When the electric drive system is powered on again after hibernation, the trigger signal output by the hardware layer of the electric drive system is monitored; Based on the second detection parameter and the trigger signal, it is determined whether the electric drive system is in a fault recurrence state; When the fault recurrence state occurs, the electric drive system is re-controlled to perform protection operations; or, when the fault recurrence state is not occurring, the normal operation state of the electric drive system is restored.

8. An electric drive fault control device, characterized in that, The device includes: The response module is used to respond to fault trigger signals output by the hardware layer of the electric drive system; The monitoring module is used to monitor the low-level duration of the fault trigger signal through the electric drive system software layer, and determine the fault type of the electric drive system based on the low-level duration. The control module is used to control the electric drive system to perform corresponding actions based on the fault type.

9. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 7.

10. A vehicle, characterized in that, The vehicle includes a controller, which includes a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method of any one of claims 1 to 7.

Images