Competence, TEM and SHELL

Two models organise almost everything this subject will say about pilots. Threat and error management (TEM) describes a flight from the crew's side: outside circumstances press in, people make mistakes, the aircraft drifts toward trouble, and the crew's job is to manage all three. The SHELL model takes a system designer's view: a human in the middle of procedures, machines, environment and other people, with error breeding wherever the fit between the human and a neighbouring block is poor. The exam quotes both models almost word for word, so this lesson keeps close to the ICAO text.

Becoming a competent pilot

ICAO's answer to what makes a pilot good is deliberately three-sided: competence is based on the knowledge, skills and attitudes of the individual pilot. Knowing the numbers is not enough without the handling to use them, and both together are not enough without the attitudes that decide whether they get used at all. On top of this base ICAO defines eight core competencies that competency-based training and checking are built around:

Application of procedures — flying the aircraft by the book that was written for it.
Communication — with the other pilot, the cabin, ATC and everyone else in the operation.
Aircraft flight path management, automation — commanding the flight path through the autoflight system.
Aircraft flight path management, manual control — commanding it by hand.
Leadership and teamwork — making a crew more than two individuals.
Problem-solving and decision-making — recognising what is wrong and choosing what to do.
Situation awareness — knowing where the aircraft is, what it is doing and what comes next.
Workload management — keeping demands and capacity in balance.

Notice that only two of the eight are about physically steering the aircraft. The other six are the subject matter of this course, which is exactly the point the list is making.

The TEM model: three components

The TEM model, set out in ICAO Doc 9683 (Human Factors Training Manual), is a conceptual framework for understanding how safety and human performance interact in real operations. From the flight crew's perspective it has three basic components: threats, errors and undesired aircraft states. Threats and errors are part of everyday operations and must be managed, because both carry the potential to generate undesired aircraft states. Those states must then be managed in turn, because they carry the potential for an unsafe outcome. Undesired aircraft state management is as important as the other two: it is largely the last opportunity to avoid an unsafe outcome.

Threats

A threat is defined as an event or error that occurs beyond the influence of the flight crew, increases operational complexity, and must be managed to maintain the margins of safety. A thunderstorm, a congested terminal area, high terrain around the airport, an aircraft malfunction, an error by a controller or a ground crew: none of these is the crew's doing, and all of them make the day harder. Some threats are anticipated, expected or known in advance, so the crew can brief a response before it arrives. Some are unexpected, like a malfunction that announces itself in flight, and must be met with trained skill on the spot.

A third kind is not directly visible to the crew at all. Latent threats lie hidden in the system and may need a safety analysis to uncover: an equipment design issue, an optical illusion, a shortened turn-around schedule. The model also sorts threats by where they come from, and the two categories divide the work of removing them:

Environmental threats arise from the environment the operation moves through and must be managed by the crew in real time: weather (thunderstorms, icing, wind shear, crosswind), ATC (congestion, language difficulty, non-standard phraseology, a late runway change), airport conditions (contaminated or short runways, confusing signage, birds), terrain and similar call signs on frequency.
Organisational threats originate inside aviation organisations, which is where they can be controlled at source: operational pressure such as delays and late equipment changes, aircraft malfunctions and MEL items, cabin events and distractions, maintenance and ground handling errors, dispatch paperwork errors, chart and manual errors, crew scheduling events. Organisational threats are usually latent in nature; the crew remains the last line of defence, but the organisation had the earlier opportunity.

Threat management is the building block for everything downstream. The linkage is not one-to-one, but audit data shows that mismanaged threats are normally linked to crew errors, and those errors in turn are often linked to undesired aircraft states. Managing the threat is the most proactive option on the table: it removes the safety-compromising situation at its root.

Errors

The TEM model of ICAO Doc 9683 (Part II, Chapter 2) defines an error as an action or inaction by the flight crew that leads to deviations from organisational or flight crew intentions or expectations. The subject of the sentence matters: where a threat comes from outside the crew, an error is the crew's own. Errors can be spontaneous, linked to threats, or part of an error chain, and what decides their effect on safety is not that they happened but whether they are detected and responded to before they lead further. A well-managed error becomes operationally inconsequential; a mismanaged error is one that is linked to or induces an additional error or an undesired aircraft state.

The model classifies errors by the primary interaction the crew was engaged in at the moment the error was committed, which keeps every category observable:

Aircraft handling errors — the crew was interacting with the aircraft: vertical, lateral or speed deviations in manual flight, an incorrect flap or power setting, a wrong automation mode or entry, an incorrect altimeter or fuel switch setting, a wrong radio frequency dialled, or taxiing errors such as turning down the wrong taxiway.
Procedural errors — the crew was interacting with a procedure: a checklist flown with the wrong challenge and response or performed late, a missed or incorrect callout, an omitted briefing, wrong weight-and-balance or clearance information recorded, incorrect application of MEL procedures.
Communication errors — the crew was interacting with people: a missed call, a misinterpreted instruction, an incorrect read-back to ATC, a wrong taxiway or gate communicated, or plain miscommunication between the two pilots.

Intentional non-compliance and proficiency shortfalls are not separate categories: the model treats them as subsets that may underlie any of the three. A deliberately skipped checklist item is still a procedural error; a rough landing rooted in a training gap is still a handling error.

Undesired aircraft states

An undesired aircraft state is defined as a flight crew-induced aircraft position or speed deviation, misapplication of flight controls, or incorrect systems configuration, associated with a reduction in margins of safety. The phrase flight-crew-induced is the discriminator the exam tests: an equipment malfunction or an ATC error also reduces margins, but those come from outside the crew and are therefore threats. Three categories cover the states:

Aircraft handling states — vertical, lateral or speed deviations, unnecessary weather penetration, unauthorised airspace penetration, operation outside aircraft limitations, an unstable approach, a continued landing after an unstable approach, a long or floated or off-centreline landing.
Ground navigation states — proceeding towards the wrong taxiway or runway, ending up at the wrong ramp, gate or hold spot.
Incorrect aircraft configurations — systems, flight controls, automation, engine or weight-and-balance configuration wrong for the situation.

An undesired aircraft state is a transitional state, sitting between a normal operational state and an outcome. An outcome, an incident or accident, is an end state: while the aircraft is merely in an undesired state the crew can still recover it and restore the margins, but once the state becomes an outcome no recovery is possible. That is why training stresses the switch from error management to state management. A crew that discovers the wrong approach in the flight management computer close to the final approach fix, and heads down into reprogramming it instead of flying a basic mode, is locked into managing the error while the aircraft stitches through the localiser into an unstable approach. When the aircraft is in an undesired state, flying the aircraft comes before fixing the error that caused it.

Countermeasures

Everything the crew does about threats, errors and undesired states happens through countermeasures, and by observation as much as 70 per cent of crew activity is countermeasure-related. All countermeasures are crew actions, but the model splits them by what they build on. Systemic-based countermeasures employ hard resources the aviation system put in place before the crew ever reported for duty: the airborne collision avoidance system, the ground proximity warning system, SOPs, checklists, briefings and training itself.

The rest are individual and team countermeasures: personal strategies and tactics, the skills, knowledge and attitudes that human performance training, most notably CRM, develops. They come in three categories:

Planning countermeasures — essential for managing anticipated and unexpected threats: a concise interactive SOP briefing with bottom lines established, plans stated and acknowledged so everybody is on the same page, workload assigned for normal and non-normal situations, contingencies managed in advance.

Execution countermeasures — essential for error detection and error response: active monitoring and cross-checking of systems and of each other, workload managed so primary flight duties stay on top, automation managed and its setup briefed.

Review countermeasures — essential for managing the changing conditions of a flight: plans evaluated and modified when needed, inquiry that takes nothing for granted, assertiveness that states critical information with appropriate persistence.

The SHELL model

The second model looks at the same human from the outside. The SHEL concept was first developed by Edwards in 1972, and the block diagram used today was modified by Hawkins in 1975. The name spells its components: Software, the non-physical parts of the system such as procedures, manuals, checklist layout and symbology; Hardware, the machine; Environment, the situation in which the rest must function; and Liveware, the human. A second liveware block gives the model its double L: in the centre sits the person, the most critical and most flexible component in the system, surrounded by the other four blocks.

The drawing makes a deliberately physical point: the central block's edges are not straight, so the surrounding blocks must be shaped to fit it, never the other way round. The match or mismatch at each interface matters as much as the blocks themselves, because a mismatch is a source of human error. Read around the centre:

Liveware-Hardware — the classic human-machine interface: seats shaped to bodies, displays matched to the senses, controls with sensible movement, coding and location. Dangerous because humans adapt to a poor fit and mask the deficiency without removing it.

Liveware-Software — the human against procedures, manuals, checklists and symbology; a misinterpreted checklist is the standing example. Less tangible than hardware problems, and so harder to resolve.

Liveware-Environment — the earliest interface aviation noticed: first the human was adapted to the environment (helmets, oxygen masks), then the environment to the human (pressurisation, air conditioning). Today it covers illusions and disorientation, ozone and radiation at altitude, and disturbed biological rhythms from time-zone flying.

Liveware-Liveware — the interface between people: leadership, crew cooperation, teamwork and personality interactions. Crews were long trained and checked as individuals; this interface is where a crew of proficient individuals can still fail as a team, and it is the home ground of CRM.

The model's relevance to cockpit work is exactly this map. Every mismatch this course will discuss lives on one of the four interfaces, from a badly placed switch to a captain nobody dares correct, and the SHELL model gives the crew and the investigator a shared way of locating error at an interface rather than blaming the person in the middle.