The SHELL Model: Software, Hardware, Environment, Liveware and Liveware

The framework that maps every human-system interaction in aviation — and identifies where the mismatches that produce errors actually live.

What Is the SHELL Model?

The SHELL model was developed by Professor Elwyn Edwards in 1972 and refined by Frank Hawkins in 1984. It provides a conceptual framework for analysing the interactions between a human operator and the components of the system they operate in. In aviation, it maps the relationships between the crew member (Liveware, at the centre) and the four surrounding system components: Software, Hardware, Environment, and the other Liveware around them.

Software (L-S): The non-physical components of the system — procedures, checklists, regulations, documentation, training materials. Mismatches here produce procedural errors: the checklist that is ambiguously worded, the procedure that is inconsistent with aircraft behaviour, the regulation that does not address the scenario encountered.

Hardware (L-H): The physical components of the system — aircraft, cockpit design, instruments, controls, tools. Mismatches here produce interface errors: the V/S and FPA mode sharing the same display (Air Inter 148), the adjacent lever positions that allow throttle confusion (TAM 3054), the single-chime autopilot disconnect alert (Eastern 401).

Environment (L-E): The physical and organisational environment in which the operator works — weather, lighting, noise, time pressure, organisational culture, commercial pressure. Mismatches here produce performance degradation: the pre-dawn maintenance shift, the final approach in a severe thunderstorm, the commercial pressure that makes delay feel professionally risky.

Liveware-Liveware (L-L): The interactions between the central liveware and other people — crew members, controllers, dispatchers, supervisors. Mismatches here produce team failures: authority gradient, communication breakdown, role confusion.

The SHELL model’s value is in identifying where the mismatch lives. A hardware mismatch requires a design change. A software mismatch requires a procedure change. An environment mismatch requires an operational change. An L-L mismatch requires a CRM or cultural change. The solution must match the location of the problem.

Applying SHELL to Accident Analysis

The SHELL model is most useful as an analysis tool — mapping which component of the system was mismatched with the human operator in each contributing factor of an accident. In Tenerife: L-L (authority gradient), L-S (non-standard phraseology), L-E (fog, congestion, commercial pressure). In Eastern 401: L-H (autopilot disconnect alert design), L-S (no altitude monitoring procedure), L-L (unowned task). In Lion Air 610: L-H (single-sensor MCAS), L-S (MCAS not disclosed in procedures), L-E (previous flight event not investigated).

This mapping helps safety investigators ensure that their corrective action recommendations address the right system component. A corrective action in the wrong component will not prevent recurrence.

 

Key Takeaway

The SHELL model maps the human operator at the centre of a web of system interactions. Every aviation accident involves at least one mismatch between the human and one of the surrounding components. Identifying the mismatch specifically — not just ‘human error’ — is the prerequisite for designing the right corrective action.

 

Related Content on Aviation Risk Lab

Human Factors: https://aviationrisklab.com/human-factors/

Systems Engineering: https://aviationrisklab.com/systems-engineering/

Automation and Technology: https://aviationrisklab.com/automation-and-technology/