Failsafe Assumption Review

A failsafe is not a promise that the aircraft will become safe automatically.

It is a preplanned response to a specific abnormal condition.

The review question is therefore:

If this condition happens, does the configured response still make sense in the state the aircraft could actually be in?

This lesson uses a fictional mission packet and simulation results. You are reviewing logic, not operating hardware.

The mission under review

A small mapping mission has this simplified sequence:

READY
→ TAKEOFF
→ WAYPOINT_A
→ WAYPOINT_B
→ WAYPOINT_C
→ RETURN
→ LAND

Configured abnormal-condition responses are:

low energy     → RETURN
lost link      → RETURN
geofence event → HOLD
position fault → HOLD

At first glance, that looks organized.

Now inspect the assumptions behind each transition.

Every failsafe has prerequisites

Low-energy return assumes

• the return path is reachable with remaining energy;
• home/recovery point is correct;
• position estimate is usable enough;
• propulsion is healthy enough to execute the route.

Lost-link return assumes

• return behavior was configured and verified;
• recovery path is suitable;
• the system can navigate without the missing link;
• link loss did not occur because of a larger electrical or system failure.

Position-fault hold assumes

• “hold” is possible without trustworthy position information;
• attitude and altitude control remain usable;
• the environment makes remaining in place safer than another response.

That last one should make you uncomfortable.

A state name like HOLD can hide a contradiction if the state depends on the sensor that just failed.

Failure logic can have impossible branches

Suppose a fictional mission says:

if GNSS_unreliable:
    hold_position_using_GNSS

The logic defeats itself.

The response depends on the failed evidence source.

This is a general engineering pattern:

A recovery mechanism must not quietly depend on the same capability whose failure triggered recovery.

When it must depend on a degraded capability, that dependency needs to be explicit and justified.

Review the assumption table

A supplied packet contains:

Which row is the most obvious contradiction?

The position-invalid response.

If the return behavior requires the same invalid position source, the recovery logic may not have the state it needs.

That should trigger redesign or escalation to the platform’s documented alternate behavior—not an invented classroom fix.

Worked review: blocked return path

A fictional aircraft is at Waypoint C when lost link occurs.

The packet shows:

• recorded home point is correct;
• position estimate is valid;
• remaining-energy estimate is above the classroom mission threshold;
• direct return path crosses a modeled crane obstacle;
• normal mission route avoided that obstacle using a different corridor;
• configured lost-link response uses direct return.

Is the failsafe “working” if it executes exactly as configured?

Software-wise, maybe.

Mission-wise, no.

The recovery logic is incompatible with the environment model.

A strong review says:

The lost-link transition is internally consistent but operationally weak because the configured return trajectory conflicts with a modeled obstacle that the normal mission route avoids. The mission should not be accepted until recovery routing or mission geometry is revised using the approved platform capabilities.

That is systems reasoning: correct execution can still implement a bad assumption.

Failsafes can conflict

What happens if two abnormal conditions appear together?

Example:

low energy = true
position invalid = true

One rule wants return. Another may want hold or land under a platform-specific policy.

The software needs precedence, arbitration, or a higher-level emergency state.

A review should therefore ask:

• which condition has priority?
• can one failsafe interrupt another?
• what happens if state quality degrades during recovery?
• where does human authority re-enter when communication is restored?

These are design questions, even if a commercial platform answers them internally.

Human override is part of the architecture

Automation and human control are not enemies.

A well-designed system defines when the operator:

• may interrupt automation;
• must not interrupt a safety sequence without cause;
• regains control after link restoration;
• should abandon the mission objective;
• needs to escalate rather than improvise.

The exact authority model belongs to the approved platform and operating procedure. Your classroom review should identify where that authority boundary exists.

Create a failsafe assumption matrix

For the supplied mission, review at least four abnormal conditions.

Your matrix should include:

• low energy;
• lost link;
• geofence condition;
• invalid or degraded navigation state.

Then choose the weakest response and explain why.

Test the logic with counterexamples

For each failsafe, invent one fictional counterexample where the normal assumption is false.

Example:

Return-to-home is configured, but the home point is correct and the direct route still crosses an obstacle.

The point is not to make the software look bad.

The point is to test whether the safety claim survives a change in conditions.

Your final mission-logic disposition

Write one of these:

• Accept for further simulation — assumptions are explicit and supported by the packet.
• Revise mission logic — a correctable condition, priority, route, or state dependency is weak.
• Hold for platform/source review — the classroom packet does not establish actual platform behavior well enough to make the claim.

Use the third option when needed. Do not invent undocumented failsafe behavior.

Misconception: failsafe means failure-proof

No system is failure-proof.

Failsafes reduce risk for defined failure conditions. They also have sensors, software, power, geometry, and configuration dependencies of their own.

A mature mission plan does not say:

We are safe because return-to-home is enabled.

It says:

We know what condition triggers the recovery behavior, which state it depends on, which route and energy assumptions it makes, and which evidence still needs to be verified.

The Unit 3 conclusion

Weeks 7–9 moved from physics to control to mission software:

forces change motion → feedback changes forces based on error → mission logic changes control targets based on state and conditions.

That stack is what an autopilot actually sits on.

The next unit adds aviation operations and regulatory boundaries. Software can enforce a configured limit, but it does not decide what the real-world operating boundary is allowed to be.