AIRSPACE / KNOWLEDGE & DESIGN
Monitoring & Failure Response | Preparing for the moment you lose the picture
Lost links, stale positions, plan deviations. Flight support has to be designed not just for the healthy screen, but for the moments when information goes missing.
Read this page in order
Keep two timestamps and three states
Separate the time an observation was made from the time the server received it. Alongside "normal" and "abnormal", keep a third state: "unknown". An aircraft that has stopped at its last known position and a display that has simply stopped updating are not the same thing. This is a design proposal for a general-purpose flight support system.
| State | How to handle it |
|---|---|
| Fresh data available | Keep monitoring within the applicable conditions |
| Anomaly detected | State what, which aircraft, when it was detected, and who owns it |
| Data stale or unknown | Do not draw it as a current position; show the last observation |
Design alerts around whose action they change
More warnings do not automatically mean more safety. Deliver the subject, the reason and the next action to someone who can actually respond. Build in acknowledgement, escalation of unanswered alerts, and the grounds for clearing them. Any safety-related message should state the concrete condition first, with no wording that blurs its meaning.
| Example event | Example screen response | What to record |
|---|---|---|
| Observation updates stop | Last received time; current state unknown | Onset, recovery, owner's acknowledgement |
| Possible deviation from the plan | Show the aircraft and the difference | Decision criteria, plan version, observed values |
| External service outage | Affected scope and alternative places to check | Failed connections, retries |
| Owner does not respond | Escalate along the agreed contact order | Recipients, acknowledgement, outcome |
Emergency procedures follow the aircraft and the operation
What to do on a lost link depends on the aircraft's specifications, the site, the flight conditions, the operations manual and more. A general-purpose site should not be designed to issue blanket "climb", "return" or "land" commands. The app shows the confirmed plan and how to reach the person in charge, and draws a clear line of responsibility between itself and the aircraft's own safety features.
Scenarios to walk through on paper
- When an observation arrives with a timestamp earlier than the last one, does it overwrite newer data?
- When the same alert is delivered repeatedly, does it look like a separate anomaly?
- Can someone without authority clear an alert?
- When a link recovers and a backlog of old data floods in, does it get mixed up with the current position?
- When the person on duty changes, are unresolved anomalies and their grounds handed over?
Start verification with log replay and simulation. Testing with real aircraft needs its own safety plan and a proper team, so take it in stages.
DEFINITION OF DONE
When you build it, check these.
- An unknown state is never shown in the "normal" colour.
- Acknowledging an alert and resolving the problem are recorded separately.
- Old observations are never replayed as new ones.
Design checkpoints for use in spec reviews and functional testing.
How to read this page
This page is an original design proposal. Implementation and numerical examples are not evidence of real-world results or certification. Verify them against the conditions of the work you apply them to.
Read how this was made and our editorial policy