M8-T15: Flight incident investigation

Learning objectives

After this lesson, you should be able to:

• Preserve evidence correctly and record chain of custody.
• Build a time-aligned timeline from logs, video and statements.
• Distinguish proximate cause, root cause and contributing factors using structured methods.
• Write corrective actions that are specific, owned, dated and verified.

Conceptual explanation

Established The process follows common accident-investigation practice (timeline, barrier analysis, causal factors, root cause). Regulatory reporting duties for incidents depend on the jurisdiction and the operation: check and comply with the rules that apply to you.

Steps:

• Make safe and preserve: make the vehicle and site safe (batteries!), photograph the scene, keep the vehicle as it is, copy the logs before powering anything else (and keep the original), record the configuration manifest, battery and parameter state, and collect statements from the pilot and observers while memory is fresh.
• Reconstruct the timeline: align events from the flight log, ground-station log, video and statements on a common time base; mark confidence in each timestamp.
• Identify the causal chain: from the outcome backward through proximate events to the conditions that allowed them. Ask “why” until you reach something that can be changed in the system, process or design.
• Barrier analysis: which defences existed (checks, monitors, failsafes, procedures, training), and which failed, were bypassed or were absent?
• Corrective actions: specific, owned, dated, and with a verification (a test or review that proves the fix works). Include the missing test that would have caught the issue earlier.

Engineering intuition

The first temptation is to stop at the proximate cause (“the VIO lost track”) or at a person (“the pilot reacted slowly”). Neither prevents the next incident. Ask why the VIO lost track without warning (no health monitor), why the monitor was missing (not in the requirements, because the FMEA did not include a featureless wall), why the FMEA missed it (no review of environment conditions). Now there are fixable things: a requirement, an FMEA update, a test, a monitor.

Timelines expose surprises. The common one: the sequence in the log is different from the one in people’s memory, or two events thought to be simultaneous were seconds apart. Align the clocks (GPS time stamps in the log, video time codes) and state the uncertainty.

Mathematical formulation

The log supplies quantitative evidence. Two analyses recur: the time to react and the margin consumed. If the first anomaly occurred at $t_{a}$, the monitor flagged at $t_{m}$ and the pilot acted at $t_{p}$, the delays tell where the barrier failed:

If the excursion exceeds the available clear distance $d_{\text{safe}}$, the barrier design was inadequate for that speed regardless of how quick the response was. For recurring events a rate estimate with uncertainty helps judge severity: with $k$ incidents in $N$ flight hours the Poisson maximum-likelihood rate is k/N, with a 95 % upper confidence bound given by the chi-square relation $\lambda _{\text{up}}=\chi ^{2}_{0.95}(2k+2)/(2N)$: zero incidents in 100 hours does not mean the rate is zero; the upper bound is 3/100 = 0.03 per hour (the “rule of three”).

$t_{a}$, $t_{m}$, $t_{p}$

times of the first anomaly, the monitor flag and the pilot action.

$k$, $N$

number of incidents and the exposure (flight hours).

$\lambda _{\text{up}}$

upper confidence bound on the rate.

Architecture and data flow

Evidence (ULog, ground-station log, companion rosbag, video, photos, statements, configuration manifest) → copied to read-only storage with hashes → timeline tool aligns sources on a time base (log boot time to UTC via GPS time messages, video offset by a visible event) → analysis scripts for the key plots and the delay numbers → causal analysis workshop → report with findings, root causes, corrective actions → actions tracked in the issue system with owners and verification → traceability matrix and FMEA/fault tree updated → lessons shared.

Real-world UAV applications

• Investigating a GNSS-denied drift incident.
• Analysing a failsafe that triggered unexpectedly.
• Learning from near misses without damage.
• Updating the FMEA and test plan from findings.

Implementation example

This runs as shown. A timeline builder: events from several sources with their own clock offsets and uncertainties are aligned to a common base, sorted, and the reaction delays and the excursion are computed. The numbers are synthetic and illustrate the method.

import math
# each source: name, offset to the common time base (s), timing uncertainty (s)
sources = {'ulog': (+1620.40, 0.01), 'groundstation': (-0.8, 0.5), 'video': (-12.30, 0.1), 'statement': (0.0, 5.0)}
events = [  # (source, local time, description)
 ('ulog', -1560.30, 'VIO health monitor: features < 30 (first anomaly)'), ('ulog', -1560.00, 'EKF2 vision position innovation test ratio > 1'),
 ('ulog', -1559.10, 'VO declared lost; EV fusion stopped'), ('ulog', -1557.20, 'pilot switched to altitude mode (takeover)'), ('ulog', -1555.60, 'vehicle contact with obstacle (accelerometer spike)'),
 ('groundstation', 61.9, 'operator message: "VIO LOST"'), ('video', 71.4, 'vehicle drifts toward the wall (visible)'), ('statement', 62.0, 'pilot: "drifted for a few seconds, I took over"')]
tl = sorted(((loc + sources[s][0], s, d, sources[s][1]) for s, loc, d in events), key=lambda e: e[0])
t0 = tl[0][0]
for t, s, d, u in tl: print(f"t = {t - t0:6.2f} s (+-{u:4.2f})  [{s:>13}]  {d}")
get = lambda key: next(t for t, s, d, u in tl if key in d)
t_a, t_m, t_p, t_c = get('first anomaly'), get('declared lost'), get('switched to altitude'), get('contact')
det, dec, total = t_m - t_a, t_p - t_m, t_p - t_a
v, ab = 3.0, 3.0; exc = v * total + v * v / (2 * ab)
print(f"detection delay {det:.2f} s, decision delay {dec:.2f} s, total {total:.2f} s; excursion estimate {exc:.1f} m; contact {t_c - t_p:.2f} s after the takeover")
assert abs(det - 1.2) < 0.01 and abs(dec - 1.9) < 0.01 and exc > 5
k, N = 0, 100.0; print(f"rule of three: zero incidents in {N:.0f} flight hours -> rate upper bound {3 / N:.3f} per hour")
# check with the chi-square relation: the 95 % upper bound for k = 0 is -ln(0.05) / N
assert abs(-math.log(0.05) / N - 3 / N) < 0.0006

Common engineering mistakes

Failure modes

Debugging approach

1. Plot all three layers (estimate, setpoint, actuators) around the event.
2. Align log time to UTC using GPS time messages and check against video.
3. Test the proposed cause by replay or by reproducing the condition in simulation.
4. Check each corrective action for an owner, a date and a verification test.

Practical exercises

1. Build the timeline of a past incident or a simulated one with at least three sources.
2. Run a 5-Whys analysis from “vehicle hit the wall” to a root cause that is a system or process condition.
3. List the barriers that existed and mark which failed or were absent.
4. Write three corrective actions with owner, due date and verification.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• ICAO Annex 13: Aircraft Accident and Incident Investigation
• FAA: Unmanned aircraft systems (reporting requirements; check the rules that apply)
• PX4: Flight log analysis

What’s next