When people hear the word safety, they often think of...
Read MoreThe SHELL Model: Software, Hardware, Environment, Liveware and Liveware
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/
Swiss Cheese Model Explained (With Aviation Examples)
The Swiss Cheese Model is one of the most widely...
Read MoreFrom Hazards to Risk: The Basics of Risk Understanding
If you spend any amount of time around safety engineering,...
Read MoreSafety in Design vs Operation: Where Risk Actually Lives
In aviation safety engineering, it’s easy to talk as if...
Read MoreMitigations Are Not Solutions
There is a point in most safety assessments where the...
Read MoreSoftware vs Hardware: Assurance Levels Explained
There was a time when most aviation safety discussions were...
Read MoreSafety Engineering Fundamentals: What Actually Keeps Complex Systems Safe
Safety engineering is often treated like a compliance exercise—fill out...
Read MoreHow to Do a Functional Hazard Assessment (FHA) and a Fault Tree Analysis (FTA)
Where FHA and FTA sit in safety engineering Functional Hazard...
Read MoreWhy Aviation Accidents Happen (Human Error vs System Failure)
When an aviation accident occurs, the explanation often sounds familiar:...
Read MoreFunctional Hazard Assessment (FHA): Mapping Intent to Failure States
Mapping System Intent to Failure States Functional Hazard Assessment...
Read MoreHow Risk Is Assessed in Aviation (Step-by-Step)
Risk assessment is one of the core processes in aviation...
Read More