An autonomous system failsafe detects a loss of capability or an unsafe condition and changes the system's behavior while recovery is still possible. Its job is to limit harm, preserve essential control, and reach a condition the vehicle can sustain. The appropriate response depends on what failed: a ground robot may brake, an aircraft may need continued powered flight, and an underwater vehicle may need to release ballast.
Good failsafe design therefore starts with the recovery action and its dependencies. A backup that requires the same failed sensor, computer, or power supply may be unavailable precisely when it is needed.
On This Page
- Define what must remain safe
- Separate mission control from protective control
- Make the interfaces enforce the handoff
- Match the response to the failure
- Budget time and distance for recovery
- Balance intervention against useful operation
- Verify the complete recovery sequence
Define what must remain safe
Define the system boundary before choosing monitors. Include the vehicle, payload, energy supply, communications, operator, and surroundings wherever they affect the hazard. For a warehouse robot, preventing chassis movement is incomplete if a raised load can still fall. For an aircraft, removing propulsion can create a more immediate hazard than the original navigation fault.
Distinguish three objectives in the design requirements:
- Fail-safe: move to a specified condition that limits the consequences of failure, potentially ending the mission.
- Fail-operational: retain a required function after specified failures, potentially with reduced performance.
- Degraded operation: restrict capability, such as speed or operating area, while retaining enough functionality for an allowed task.
These labels need explicit limits: which failures, which environment, and for how long? A temporary hold is a maneuver, not an indefinitely sustainable destination.
NASA's fault-detection and response guidance gives a spacecraft example: a safe state includes stable thermal and orientation conditions, commandability, and adequate power. Its spacecraft provisions illustrate why the physical condition after intervention matters.
Separate mission control from protective control
The mission controller selects actions that accomplish the task. A protective controller has a narrower responsibility, such as maintaining separation or keeping the vehicle inside a recoverable operating region.
In the Simplex form of runtime assurance, a monitor supervises an advanced controller and switches authority to a trusted recovery controller when a specified condition fails. NASA's 2024 UAS verification paper treats the controller, switching logic, sampling interval, and vehicle dynamics together. The guarantee depends on the model assumptions and on switching early enough for recovery.
The useful distinction is between the hazard boundary and the intervention boundary. If a vehicle must avoid an obstacle, waiting until separation reaches zero cannot protect it. The monitor must act while the available maneuver can still preserve clearance. Recovery-controller simplicity helps analysis, but does not itself establish that the maneuver works.
Redundancy addresses a different part of the problem. Two controllers can improve availability only to the extent that their failures are sufficiently independent. NASA's common-cause failure presentation identifies shared power, control, location, and design weaknesses as ways to defeat redundant systems.
For example, consider two computers fed by one regulator and using the same corrupted position estimate. Their number does not establish independent recovery. During design review, trace what both channels share, then determine which hazards justify separate power, sensing, execution, or physical protection. Diversity adds integration work and requires checking the interfaces between unlike components.
Make the interfaces enforce the handoff
The protective decision must reach the actuator through an unambiguous command path. An engineering interface review should answer four questions:
- What does each measurement mean? Specify units, coordinate frame, acquisition time, validity, and uncertainty where available.
- When does information expire? Specify how missing updates, delayed messages, and frozen values are detected.
- Who owns the actuator command? Define how protective control overrides mission commands and prevents queued commands from reappearing after takeover.
- What confirms the response? Check measured motion or actuator feedback as well as the requested mode.
The Nav2 Jazzy Collision Monitor documentation provides a concrete ground-robot example. The node monitors sensor data outside the normal costmap and trajectory-planning path, accepts a desired velocity, and produces an output velocity. Its source timeout can stop the robot when observations stop arriving. A stopped sensor stream therefore has a defined response rather than being treated as a clear route.
A fresh message can still carry an incorrect measurement. NASA's fault-response guidance describes complementary checks including expected ranges, disagreement between related measurements, heartbeats, and comparison of commanded versus observed state. Use these checks according to the failure being detected; a heartbeat only addresses part of the problem.
For integration, ask whether any alternate command publisher can bypass the protective output. Also define the motor controller's behavior if that output disappears. Software issuing a stop and hardware executing one are separate events.
Specify which response wins when several monitors activate. For example, a proposed hold after communication loss must be reconsidered if position control is also unavailable. Resolve those combinations in the mode logic rather than allowing independent handlers to issue conflicting commands.
Match the response to the failure
The table below is an engineering synthesis of the cited implementations. Its questions identify dependencies to verify; they are not universal mode settings.
| Failure or constraint | Documented example | Dependency that controls the response |
|---|---|---|
| Loss of external flight commands | PX4 v1.16 supports an offboard-loss response after a configured delay. | Can the onboard controller execute the selected response without the lost connection? |
| Degraded position estimate | PX4 distinguishes position-loss behavior according to available control and height information, with different aircraft handling. | Does the fallback still require the position information that has become unreliable? |
| Missing obstacle observations | Nav2 Jazzy supports stopping on an observation-source timeout. | Are the remaining command path, controller, and brakes capable of enforcing the stop? |
| Major underwater electronics failure | WHOI reports that Sentry's emergency controllers released weights during its April 2010 flooding and fire incident. | Can the recovery mechanism act despite damage to mission electronics? |
| Difficult terrain on a planetary traverse | JPL describes human-defined keep-in and keep-out zones alongside Perseverance's onboard route decisions. | Does the permitted operating area exclude hazards that onboard perception may not handle? |
Source basis: PX4 v1.16 safety configuration, Nav2 Jazzy Collision Monitor, WHOI's Sentry recovery account, and JPL's March 2022 AutoNav explanation, checked September 8, 2026. Dependency questions are editorial interpretation.
Sentry's recovery is especially instructive: surfacing after an emergency did not mean the vehicle could continue its survey. The historical account describes extensive repair before operations resumed. Recovery and mission completion are different outcomes.
Likewise, a return command is not a universal solution to navigation loss. PX4's documented distinctions show why a flight mode must be evaluated against the estimates and control inputs that remain available. Match implementation details to the installed software version and vehicle configuration.
Budget time and distance for recovery
A monitor's update rate is only one contribution to response time. The relevant interval runs from the physical change through sensor acquisition, detection, command transfer, and the onset of effective actuation. Use a justified upper bound for that complete chain in the operating conditions being assessed.
For a simplified ground robot approaching a stationary obstacle, an illustrative clearance calculation is:
Required clearance = v × T + v² / (2 × a) + M.
Here, v is initial speed in meters per second, T is total delay before effective braking in seconds, a is constant braking deceleration in meters per second squared, and M is an added distance allowance in meters. The first term is travel during delay; the second is travel while braking.
Assume, solely for this example, v = 2 m/s, T = 0.25 s, a = 1 m/s², and M = 0.5 m. The result is 0.5 + 2 + 0.5 = 3 m. Doubling the assumed delay to 0.5 s raises it to 3.5 m. Keeping the original delay but increasing speed to 3 m/s raises it to 0.75 + 4.5 + 0.5 = 5.75 m.
These are calculated scenarios, not measured robot performance or recommended protective distances. The model assumes straight motion, constant speed during the delay, immediate constant deceleration afterward, and a stationary obstacle. It omits slope, changing friction, turning geometry, brake buildup, and approaching people. The chosen allowance has no demonstrated safety significance.
The calculation explains why additional speed can consume clearance quickly. A real design needs measured response and braking behavior under relevant loads and surfaces, plus justified allowances for uncertainty and obstacle motion. NASA's runtime-assurance analysis similarly makes sampling and continuous motion part of the conditions for successful intervention.
Balance intervention against useful operation
Earlier intervention preserves more recovery room but may interrupt otherwise acceptable work. Longer persistence filters can reject brief disturbances while allowing a real failure to continue longer. NASA's fault-response guidance explicitly addresses avoiding excessively sensitive triggers; it also describes escalating responses to persistent failures.
A practical design review should compare both missed detections and unnecessary interventions. For example, record whether a nuisance stop merely delays a ground survey or leaves a vehicle obstructing a shared route. Do not adjust a threshold solely to improve mission completion without checking the resulting recovery margin.
Software capability also needs to be separated from formal assurance. Nav2 states that its CPU-based Collision Monitor does not provide hard real-time safety certifications. Its presence therefore cannot establish the safety rating of an integrated robot. When a project requires such a rating, the evidence must cover the relevant sensing, logic, actuation, and system integration.
Operational limits can complement onboard protection. JPL's AutoNav account explains that people marked terrain zones while Perseverance selected local driving actions. As an engineering implication, autonomy can operate within deliberately restricted conditions; it need not solve every hazard encountered outside them.
Verify the complete recovery sequence
Evaluate the protective function from the injected fault through physical recovery and any authorized return to service. The following review sequence combines the earlier interface and recovery considerations:
- Specify the initial conditions: speed, payload, energy, environment, and available control links.
- Exercise faults individually and in relevant combinations, including loss of a dependency shared by the normal and fallback paths.
- Record detection, authority transfer, actuation, and achieved motion on a common timeline.
- Check whether the system can sustain the resulting condition until recovery support is available.
- Define explicit restart conditions, including whether operator acknowledgement is required and how stale commands are rejected.
Passing an isolated monitor test does not demonstrate the whole sequence. A timely mode change followed by ineffective braking still fails the physical objective. Equally, resuming the mission when a signal briefly returns can undo an otherwise successful intervention.
For supplier or program review, request the specified fault coverage, fallback dependencies, bounded response times, and demonstrated recovery conditions. The decisive evidence is that the integrated vehicle can execute the protective action under the failures it claims to handle.
Sources
- NASA Software Engineering Handbook: Fault Detection and Response. Engineering guidance and center-specific examples covering detection, persistence, escalation, and spacecraft safe states.
- NASA: A Verification Framework for Runtime Assurance of Autonomous UAS. Research paper on controller switching, timing assumptions, and formal verification; not certification of an installed system.
- NASA: Common Cause Failures Dominate and Defeat Redundancy. Technical presentation record explaining why shared dependencies limit redundancy.
- Nav2 Jazzy: Collision Monitor Node. Developer documentation for command interfaces, observation timeouts, and certification limitations.
- PX4 v1.16: Safety Configuration. Version-specific documentation for offboard and position-loss responses.
- WHOI: A Robot Is Resurrected at Sea. Institutional account of Sentry's April 2010 emergency ascent and subsequent repair.
- JPL: Perseverance Rover Hightails It to Martian Delta. March 2022 explanation of onboard driving and human-defined terrain limits.
- JPL: Perseverance Looks Back at Wheel Tracks. Featured photograph's identity, capture date, and NASA/JPL-Caltech credit.
- JPL Image Use Policy. Reuse terms for the unmodified featured photograph, including credit and no implied endorsement.
Last checked: September 8, 2026.
