11.6 Threat and Error Management

The TEM Model

Threat and Error Management (TEM) is the safety framework most of modern aviation training is built on, and Schedule 4 codes it priority B for RPA. It uses three terms precisely.

The chain runs left to right: an unmanaged threat invites an error, and an unmanaged error produces an undesired aircraft state. Every link is an opportunity to intervene, and intervening early is cheaper than intervening late.

Managing threats

Threats are managed by anticipation, which is why they belong in planning rather than in flight. The site survey, the weather brief, the NOTAM check and the job safety assessment are all threat-identification exercises. For each identified threat, the question is: what will I do when this happens?

• Threat: gusty afternoon wind. Management: fly in the morning, or set an abort wind figure and brief it.
• Threat: powerlines crossing the site. Management: trace them during the walk, mark the crossing points, plan a route that avoids them, and brief the observer.
• Threat: client wants the shot regardless. Management: state the go/no-go criteria before starting, with the client present.

Managing errors

Errors are managed by trapping them before they have consequences. Three mechanisms do most of the work:

1. Checklists. A written checklist moves memory items onto paper. Schedule 4 names checklists explicitly as an error-prevention tool. The value is in using it as a check — reading and confirming — not reciting it from memory while doing something else.
2. Standard operating procedures. Doing the same thing the same way every time makes a deviation visible. An operator whose pilots each have their own launch routine has no baseline against which anything looks wrong.
3. Crew cross-check. A second person who is expected to speak up catches what one person misses. This only works if the crew has been briefed that speaking up is required, and if the pilot demonstrably accepts it.

Recovering an Undesired Aircraft State

If a threat and an error both get through, the pilot is left managing the state itself — the last line of defence, with the least margin. The priorities are:

1. Stabilise. Stop the aircraft. Hover if safe, or climb clear of obstacles.
2. Assess. Height, position, battery, link quality, what is beneath the aircraft.
3. Decide. The safest recovery is usually the shortest path to a safe landing, not the one that saves the mission.
4. Act, then report. Recover the aircraft, then record what happened in the log and — if it is reportable — to the ATSB.

The most common error at this point is trying to save the job. An undesired aircraft state is where mission goals and safety diverge, and the pilot's job is to abandon the mission.

Risk Perception When Remote from the Aircraft

Schedule 4 topic 5(e) names something specific to remote piloting: risk perception when remote from the location of the RPA operation.

A crewed pilot shares the aircraft's fate. A remote pilot does not, and that changes risk perception in measurable ways. Research and accident experience both show that people accept greater risk when they are not personally exposed to the consequences. A pilot standing safely on the ground watching a $30,000 aircraft over a busy road is making a decision whose worst outcome falls entirely on other people.

Three defences:

• Make the consequence concrete. Ask explicitly: if the aircraft failed right now, what would it hit and who would be hurt? The question converts an abstract risk into a specific one.
• Use the hierarchy of controls. Eliminating the overflight is always better than mitigating it, and the hierarchy forces the question of whether the exposure was necessary at all.
• Fly it as though you were in it. A useful discipline: if you would not be comfortable being underneath the aircraft, do not fly it over anyone else.

The effect is stronger still when the pilot is physically distant from the operating area — an EVLOS or BVLOS operation, or a large site where the aircraft is working several hundred metres away. The further the pilot is from the risk, the more deliberately it must be assessed.

Strategic Versus Tactical Risk Management

Schedule 4 topic 5(f) draws a distinction worth being precise about.

Both are required. Strategic risk management without tactical management produces a beautifully documented flight that flies into an unforecast squall. Tactical without strategic produces a pilot improvising continuously, who will eventually be surprised by something that a five-minute walk of the site would have revealed.

The relationship between them is that good strategic work reduces the tactical load. Every hazard identified and controlled before launch is one less thing competing for attention in flight — which matters enormously, because attention in flight is the scarcest resource a remote pilot has.

Crew Resource Management

CRM is TEM's practical delivery mechanism when more than one person is involved. Schedule 4 names it under threat and error management as well as under crew coordination. The core elements for an RPA crew:

• Brief roles before launch — who flies, who maintains VLOS, who manages bystanders, who handles the payload.
• Define the callouts — the exact words for "aircraft approaching", "person entering the area", "battery at 30 per cent", "abort".
• Make assertion explicit. The observer must be told that raising a concern is required, and the pilot must visibly act on it. A crew that only speaks when spoken to provides no error trapping at all.
• Debrief afterwards. What was the threat we did not anticipate? What error did we trap, and how? What will we change? A two-minute debrief after each job is the mechanism by which an operation actually improves.