4.6. Supervisory Algorithms¶

Supervisory algorithms include:

Monitoring (including fault detection)
- Overvoltage/undervoltage detection
- Overcurrent detection
- Overtemperature detection
- Watchdog timer management
- Stall detection and recovery
Other supervisory algorithms
- Thermal management
- Saturation and antiwindup management (if not already present in the velocity and current controllers)
- Adaptive estimators (e.g. online resistance estimation)
- Field weakening
- Maximum torque per ampere (MTPA) controllers

4.6.1. Implementation Notes¶

4.6.1.1. Stall Detection¶

Stall detection consists of five methods intended to detect an overloaded or stalled motor:

Underspeed — If the motor velocity estimator remains accurate, a stalled motor can be detected if the magnitude of velocity estimate drops below a threshold.
Variance — In the event that a sensorless angle estimator loses synchronism with motor back-emf, the motor will tend to stall but the sensorless estimator may continue to estimate a nonzero electrical frequency. Under these conditions, voltages and currents exhibit oscillations at the estimated electrical frequency. Variance detection attempts to identify voltage and current oscillations.
Negative Ed — Spikes in negative d-axis estimated back-emf (\(E_d\)) can occur when a motor stalls and a sensorless angle estimator loses synchronism. This can be used as a detection method.
Torque angle — The angle between estimated back-emf and motor terminal voltage increases as the motor becomes more heavily loaded or stalls. This is equivalent mathematically to a ratio of back-emf magnitude to terminal voltage dropping below a speed-dependent threshold.
Software overcurrent — Heavily loaded motors may exceed acceptable levels of stator current.

Different motors present different symptoms of a stalled motor, which are detected by different algorithms of the ones listed above. All of the algorithms have some kind of filter or delay to avoid premature or false detection. (see errata)

More specific information is available on monitoring (including stall detection), and recovery in the corresponding documents.

4.6.1.2. Overtemperature Detection¶

MCAF provides an overtemperature detection fault for boards which provide bridge temperature measurement, added in MCAF R7.

A fault is triggered if the filtered bridge temperature exceeds a specified threshold. This provides some noise immunity from spikes in the raw temperature signal.

4.6.1.3. Other Algorithms¶

MCAF R1 – R5 do not include any of these algorithms:

Field weakening
Thermal management
Adaptive estimators
MTPA

4.6.1.4. Watchdog Timer Management¶

The watchdog module leverages the watchdog timer found in PIC^® microcontroller and dsPIC^® DSC devices. The hardware watchdog timeout is relatively simple, just a counter that automatically increments and causes a watchdog reset if it overflows; firmware prevents this by clearing the watchdog timer as a signal that it is operating normally, so that in the event that a blocking operation unexpectedly stops the firmware from being responsive, a reset will occur.

The MCAF uses the hardware watchdog timer to catch unresponsive code in both the main loop and the control ISR. It does this by requiring two simple tasks to run, one in the main loop and the other in the control ISR, in order for the watchdog timer to be reset. The function MCAF_WatchdogManageIsr() is the task that actually clears the watchdog timer from within the control ISR, but it also maintains a “software watchdog” counter isrCount which increments on each control loop update. It is the responsibility of the main loop task to call MCAF_WatchdogManageMainLoop(), which clears the software counter, often enough so that the software watchdog does not reach a timeout.

If the ISR becomes unresponsive, it will not clear the hardware watchdog timer, and upon the next watchdog timeout, a watchdog reset will occur.
If the main loop becomes unresponsive, it will not clear the software watchdog timer, and when that timer reaches a timeout threshold, the ISR will stop clearing the hardware watchdog timer. Upon the next watchdog timeout, a watchdog reset will occur. The main loop software watchdog timeout is essentially much longer than the hardware watchdog timeout, but it is also a much less critical task thread.

Cause of a watchdog reset can be determined by examining the value of the software watchdog counter; if it is above the timeout threshold then the main loop was unresponsive, whereas if the software counter is below the timeout threshold then the control ISR was unresponsive.

4.6.1.5. Fault Clearing Logic¶

The MCAPI implements fault clearing logic when the various fault handling procedures within MCAF invoke the handleFaultFlags() function. The purpose of the fault clearing logic is to maintain system stability and safety by capturing fault information, analyzing fault-specific conditions, and executing appropriate recovery actions.

4.6.1.5.1. Faults Detected in MCAF¶

Fault flags in MCAF are mapped to corresponding fault flags in the MCAPI as described in the MCAPI fault flag table in the API Description. For example, MCAF_GATE_DRIVER_FAULT_DETECT is mapped to MCAPI_FAULT_FLAG_GATE_DRIVER.

These faults are categorized based on the source of detection:

Faults detected by MCAF firmware
- MCAF_OVERVOLTAGE_FAULT_DETECT
- MCAF_UNDERVOLTAGE_FAULT_DETECT
- MCAF_OVERTEMPERATURE_FAULT_DETECT
Faults detected by external hardware
- MCAF_OVERCURRENT_HW_FAULT_DETECT
- MCAF_GATE_DRIVER_FAULT_DETECT

The MCAPI_FAULT_FLAG_MOTOR_DRIVE fault in MCAPI is defined as a general-purpose flag to represent all MCAF faults that are not explicitly mapped.

4.6.1.5.2. Clearing MCAF Firmware-level Faults¶

Most MCAF firmware-level faults are cleared within the current ISR cycle through the following sequence:

MCAPI clears the fault flags if the corresponding fault clear flag is set.
MCAPI reads active fault status from MCAF.
If no active faults remain, MCAPI requests MCAF to exit the fault state.

4.6.1.5.3. Clearing Hardware-level Faults¶

Certain hardware-level faults require multiple ISR cycles to clear and must be handled differently from firmware-level faults.

MCAPI_FAULT_FLAG_OVERCURRENT — At least two ISR cycles are required to clear this fault due to PWM fault latching. fault_handle module interacts with MCAF to clear the fault.
MCAPI_FAULT_FLAG_GATE_DRIVER — Performing a power cycle is currently the only available method to clear this fault. (see errata)

4.6.1.6. Supervisory errata¶

The torque angle detection method of stall detection is difficult to tune automatically. It works well for some motors, but can cause false detection faults in others. We have disabled this detection method by default since MCAF R3. It can be re-enabled by changing MCAF_StallDetectInit() to initialize the stall detection flag mask as follows:
```
pstallDetect->stallDetectFlagMask = MCAF_ALL_STALL_DETECT_METHODS_ENABLED;
```
MCAPI will not clear MCAPI_FAULT_FLAG_GATE_DRIVER fault due to gate driver fault latch. (DB_MC-5666; Applicability: R8)

4.6.1.7. Modules¶

Module	Files	Description	Comments
`fault_detect`	`fault_detect.c` `fault_detect.h` `fault_detect_types.h` `parameters/fault_detect_params.h`	Fault detection
`fault_handle`	`fault_handle.c` `fault_handle.h` `fault_handle_types.h`
`mcaf_watchdog`	`mcaf_watchdog.h`	Watchdog timer management	see section on Watchdog Timer Management
`monitor`	`monitor.c` `monitor.h` `monitor_types.h`	Fault-handling
`recover`	`recover.c` `recover.h`	Recovery from stall detection
`stall_detect`	`stall_detect.c` `stall_detect.h` `stall_detect_types.h`	Stall detection