Fault Tolerant
Control

The response after the diagnosis.

Fault detection asks is something wrong? Fault-tolerant control asks the harder question that follows: now what? A driver has noticed no warning. The plane is still over the Atlantic. The line is still running. The job is not to restore perfection — the machine is, by premise, broken. The job is to keep the mission alive.

FTC is the discipline of designing controllers that continue to operate, safely and usefully, when some part of the system they are commanding has failed. “Safely and usefully” is doing a lot of work in that sentence. Post-fault performance is almost always worse than nominal. The engineering question is how much worse, for how long, and whether the degradation is graceful or catastrophic.

Two broad philosophies divide the field. A passive scheme is designed, once, to absorb a pre-specified class of faults without ever knowing one has occurred. An active scheme relies on an FDI module (see Monograph No. 1) to detect and classify a fault, then reconfigures the controller in response. The first is simpler and more conservative; the second is more powerful and more dangerous.

Passive FTC — designed to absorb.

A passive fault-tolerant controller knows nothing and needs nothing. It is a single fixed controller, designed upfront to remain stable and reasonably performant across a set of plant behaviors — the nominal plant plus a pre-specified family of faults modeled as parametric uncertainty.

The conceptual tools are the robust control toolkit: H_∞ synthesis, μ-synthesis, sliding mode control, and Lyapunov-based robust designs. Each produces a controller that trades nominal performance for a performance floor that holds across all plants in the uncertainty set.

What passive buys you

• SimplicityOne controller, no mode logic, no FDI dependency. Certifiable.
• Zero transientNothing switches. The fault is absorbed smoothly into the existing loop.
• Predictable worst caseGuarantees are formal and hold over the full uncertainty set.

What it costs you

• ConservatismYou pay for the worst case on every nominal flight, every healthy day. The system is never operating at its best because it is always armored against its worst.
• Limited fault coverageOnly the faults included in the uncertainty set are tolerated. A fault outside that envelope is not absorbed — it is merely not prepared for.
• Can require over-designOn some plants, no fixed controller can stabilize the whole uncertainty set. Then passive FTC is not an option.

Active FTC — detect, then reconfigure.

Active schemes pair an FDI module with a reconfiguration logic. When the diagnostic says “actuator three has lost 50% of its authority,” the control law updates. This removes the conservatism of the passive approach at the cost of depending on an FDI module that might be wrong, late, or both.

3.1Controller switching

The simplest active reconfiguration: hold a library of pre-designed controllers, one per fault scenario. When FDI fires, the supervisor picks the matching one. Elegant in principle; the practical problem is switching itself (§6).

A more sophisticated version is gain scheduling with fault-awareness: controller gains are interpolated continuously as a function of estimated fault severity, avoiding discrete jumps. This works when the fault can be parameterized on a continuum — actuator effectiveness, sensor bias magnitude, parameter drift.

3.2Control allocation & redistribution

In over-actuated systems — aircraft with multiple control surfaces, quadrotors, four-wheel EVs with independent drive units — the number of physical actuators exceeds the number of virtual commands (three body-axis moments, two longitudinal/lateral forces, etc.). This redundancy is FTC’s greatest gift.

A control allocator sits between the high-level controller and the physical actuators. The high-level controller produces a virtual command — say, “apply 800 N·m yaw torque and 4000 N longitudinal force.” The allocator solves a constrained optimization to decide how to split that command across actuators. When an actuator fails, its column in the allocation matrix is removed and the optimization simply redistributes across what is left.

3.3Model Predictive Control (MPC) with online updates

MPC is a natural home for FTC because it already solves a constrained optimization at every control cycle. When a fault changes either the model or the constraints, you simply update the optimization and keep solving. The reconfiguration is implicit in the problem statement.

3.4Adaptive & learning-based reconfiguration

Adaptive controllers change their own parameters online based on tracking error, without needing explicit FDI. The control gains become states of a second dynamical system, driven to keep the primary tracking loop closed. Classical MRAC (Model Reference Adaptive Control) and modern L₁ adaptive control live here.

Learning-based schemes are the frontier. Reinforcement learning, Gaussian-process-augmented MPC, and meta-learning policies try to infer fault effects from interaction data and update the control law accordingly. Powerful and dangerous: they must be prevented, by architecture, from exploring their way into instability.

The reference governor — reshape what you’re asked to do.

Sometimes the controller is fine and the plant is fine; what is no longer feasible is the reference being demanded. A fault may have reduced actuator authority, tightened a constraint, or degraded sensor bandwidth. Asking the controller to track the original aggressive reference is now a recipe for saturation or violation.

A reference governor sits between the operator and the controller. It watches the commanded reference, predicts whether the closed-loop system can follow it safely, and — if not — attenuates or reshapes the command until the predicted response stays within all constraints. When the fault clears or operating conditions improve, the governor gracefully releases the attenuation.

Graceful degradation — the practical face of FTC.

Outside textbooks, FTC rarely hides a fault. It manages the consequences. The system declares a degraded mode, announces it to the operator, and reduces capability in a way that is safe, predictable, and reversible if the fault clears.

The industrial pattern is a ladder of discrete operating modes, ordered by capability. A fault promotes the system from the top rung (nominal) downward as severity rises. Each rung is designed with its own controller, its own constraint set, and its own driver feedback.

Stability & performance during the transition.

This is the hardest theoretical problem in the field. Each controller — nominal and reconfigured — is individually stable. The controlled plant is stable under each. What is not guaranteed is that the system remains stable during the switch.

A switching event is a discontinuity in the control law. The plant state does not reset; it is whatever it was at the instant of switching, and it is now being driven by a different feedback law. Classical problems:

• Bumpless transferThe control signal has two different values an instant before and after the switch. The step discontinuity in u kicks the plant. Naively, the output jolts.
• Integrator windupThe outgoing controller’s integrator state holds history from the old loop. Handing that to the new controller produces a persistent transient.
• Switching-induced instabilityMost insidious: two individually stable controllers can, when switched between frequently, drive the system unstable. Dwell-time conditions and multiple-Lyapunov-function theory address this.

How practitioners handle it

• Bumpless transfer architecturesThe offline controller runs in tracking mode against the online one. At switch time, its internal state matches and no step occurs.
• Dwell-time constraintsFormal minimum time the system must remain in one mode before another switch is allowed. Prevents chattering-induced instability.
• Common / multiple Lyapunov functionsThe theoretical tool for proving stability under switching. You exhibit a Lyapunov function (or family of them) that decreases at or across switches.
• Soft blendingInstead of an instantaneous switch, the control signal is a time-varying convex combination of old and new, u = (1−α(t)) u_old + α(t) u_new over a short blend window.