Generating Design Requirements for Flight Deck Applications: Applying the Perceptual Cycle Model to Engine Failures on Take-off

ABSTRACT

Engine failure events during critical phases of flight are a rare yet very real possibility on commercial aircraft. The response of the pilots to these events is vital to minimizing possible adversity. New technologies are in development that provide enhanced information on the status of the aircraft engine after sustaining engine damage in order to guide pilot’s decision making. It is important that this enhanced information is aligned with the requirements of the user. This paper describes how user input can effectively be incorporated early on in the design process of new technologies to understand how current systems may be improved. The Perceptual Cycle Model (PCM) is applied to in-depth interview reports from commercial airline pilots on their responses to different engine failure events caused by bird-strikes to the engine. Application of the PCM demonstrates where current processes may be better supported to enhance pilot decision making from such events. From this, areas where improvements could be made using future avionic systems are presented, with user-led design recommendations.

1. Introduction

Technological advancement brings opportunities for additional information, support, and functionality within the flight deck. This can bring many benefits to the pilot and the overall safety of the aircraft (Salas et al., 2010). However, the practical integration of new technologies needs to be carefully considered. With the advancement of technology, a greater quantity of increasingly precise information can be delivered to pilots to inform them of the status of specific systems (e.g., Parnell et al., 2020, 2019). An engine condition monitoring tool is currently under development by an aerospace manufacturer which can inform pilots of the functional state of the aircrafts’ engines in a more timely manner than can currently be achieved. This will allow issues to be more readily resolved, promote preservation of the engines and enhance operational procedures. This is intended to be effective over a range of different failure scenarios where the functioning of the engine may be affected. One of the most demanding, from a pilot’s perspective, is an engine failure on take-off. Diagnosing and managing an engine failure during take-off is a highly time-critical event. It can be sudden, and the pilots’ initial response is likely to be one of startle and surprise (Landman et al., 2017) as these are abnormal events which can influence their trained behavior (Casner et al., 2013). Airline pilots undergo extensive Aeronautical Decision Making (ADM) training which provides them with a structured approach to managing situations that arise (Kaempf & Klein, 1994). For example, pilots are taught to use models that provide mnemonics with key components of the decision-making process as a guide. These vary across the airlines and have developed over time, e.g., the SHOR model (Stimulus, Hypothesis, Option, Response; Wohl, 1981), the DECIDE model (Detect, Estimate, Choose, Identify, Do, Evaluate; Benner, 1975). The current most popular mnemonic in the UK is DODAR (Diagnose, Options, Decision, Assign task, Review; Banks et al., 2020; Walters, 2002) or a variation of this such as T-DODAR with ‘T’ standing for Time to make the decision, which is considered first. Many decisions that airline pilots make, and for which they apply these mnemonics are routine in nature, however, occasionally they may be faced with safety critical events that require difficult decisions to be made under high-workload and time critical conditions. A notable engine failure on take-off event is the Hudson River incident wherein US Airways Flight 1549 took off from New York and underwent a series of bird-strikes which caused significant damage to both engines and near loss of total thrust. The response of the crew enabled the survivability of the incident when the pilots ditched the aircraft on the Hudson River.

The National Transportation Safety Board (2010) report into the Hudson incident provided new safety recommendations to the FAA, the first of which stated the need for the development of “technology capable of informing pilots about the continuing operational status of an engine” (National Transportation Safety Board, 2010, p. 124). Such technology is still under development within commercial aircraft, and it is the focus of this paper to understand what information the pilot may require in such an incident and how it may assist them in managing an engine failure on take-off.

Before such a system can be developed, it is important that the current flight deck processes that the tool is aiming to assist with on the flight deck are fully understood. The integration of new functionality can then be assessed to ensure any new information is usable, effective, and safe. Furthermore, any intended improvements to system functioning must not introduce any new opportunities for error or misuse (Kirwan, 1998). Human Factors input is essential in enabling the designers of the system to facilitate the needs of the end-user (Aurino, 2000; Harris, 2007; Parnell et al., 2020, 2019). Thus, input from the user is recommended from the start and maintained throughout the design process (Stanton & Young, 2003; Stanton et al., 2014).

1.1. User-centered design

Norman & Draper, 1986 stated that the key to successful design was in understanding both the technology itself and its intended user, as well as their mutual interaction. The application of user-centered design within aviation was highlighted by Harris (2007) as central to supporting the user within the broader complex system to enhance performance and safety. It is also essential when intended design concepts seek to change the role of the user within a system and the tasks available (Hesse et al., 2011; Kaber et al., 2002). Often the user can be overlooked within the early stages of the design process (Gould & Lewis, 1985; Stanton & Young, 2003). Yet, gaining an understanding of their needs, desires and the plethora of tasks that they are required to undertake can provide useful insights into the requirements of future systems (Banks et al., 2018; Parnell et al., 2020). Therefore, an understanding of how an engine condition monitoring tool can align with the current processes that occur during engine failure events is required. The pilots’ response and subsequent decision-making to manage the situation can be reviewed to determine how an engine monitoring tool could assist decision-making and facilitate improved awareness of the state of the engine after sustaining a bird-strike during take-off. Central to this are the interactions between the different elements that comprise the system of systems that is vital to understanding complexities in the aviation domain (Harris & Stanton, 2010). Pilot interactions and/or display indicators cannot themselves be considered in isolation, they must be considered within the broader sociotechnical system that exists in the cockpit (Plant & Stanton, 2012). One method that has been able to capture the interactional nature of aviation system in critical situations (Plant & Stanton, 2012) is the Perceptual Cycle Model (PCM; Neisser, 1976).

1.2. The perceptual cycle model

The PCM, can account for the interactional nature of the environment and wider system (Stanton et al., 2010), while also capturing the accounts of individuals and their cognitive processing (Plant & Stanton, 2012). The model is underpinned by Schema Theory (Bartlett, 1932). Schemata are knowledge clusters that are structured upon experiences that are similar in nature and capture commonalities that represent the experience. They provide mental templates that can inform future behaviors, as well as being fluid to updating upon exposure to new experiences. They can also allow abstract behavior and knowledge to be assimilated in order to determine an appropriate response. The key components of the PCM are ‘Schema’, ‘World’ and ‘Action’ (Neisser, 1976). The key premise is that an individuals’ interaction with the world and their internal thought processes are reciprocal and influence each other in a cyclical manner. As can be seen in Figure 1, the cyclic behavior within the model can be bottom-up (BU) or top-down (TD). Schema are initially triggered from the world, and information available within it, via a bottom-up process. The schema within the mind of an individual are activated that relate to expectations and/or past experiences of what they are sampling in the world. Top-down processing then occurs whereby actions are activated in line with the processing of the schemata, to respond to the event in the world.

Figure 1. Representation of the PCM adapted from .Plant and Stanton (2012)

Application of the PCM across ergonomics and safety-critical domains, has informed system theorems (e.g., Smith & Hancock, 1995; Stanton et al., 2006). Application of the PCM to the aviation domain has shown that it can account for erroneous events through providing a wider, systems viewpoint on why events may have made sense at the time (Plant & Stanton, 2012, 2013). Plant and Stanton (2012) demonstrated how the PCM showed the expectations of the pilots, based on a previous generation of aircraft, led them to shut down the wrong engine when an engine fire was discovered on a British Midland flight that was diverted to East Midlands airport in Kegworth. Had the pilots applied the same decision-making on the aircraft that they had more experience with, the aircraft would not have crashed. The PCM has also been shown to present options to prevent safety adverse events from happening again in the future (Revell et al., 2020).

By modeling the current processes involved in responding to and managing engine failure events caused by a bird strike during take-off, the PCM can be used as a starting point to then see if, and what, modifications may be useful in the development of engine monitoring technologies. The engine monitoring tool would need to fit within the wider system of the flight-deck and not compromise any other processes that may be occurring in events such as an engine bird-strike. Therefore, capturing the perceptual processing, including the interactions with the wider environment, that pilots currently perform is vitally important for future design of the system. Conducting interviews with active airline pilots to populate the PCM will allow the intended user population for the engine monitoring tool to be integrated into the design process at the early stage.

2. Method

2.1. Sample

In total eight commercial airline pilots were recruited (three females, five males) before data saturation was reached. Pilots were aged between 29 and 65 years (M = 39.42, SD = 14.01). All were qualified fixed wing ATPL or CPL pilots with an average 7085 hr flight experience (SD = 10231.72) and had held their licenses for an average of 13.60 years (SD = 14.28). Between them, the pilots had employment experience with 13 different airlines. Pilots flew a range of different aircraft including Airbus (n = 3), Embraer (n = 3) and Boeing (n = 2). Participants were recruited until no novel insights or interest were generated from the interviews, known as the point of data saturation (Saunders et al., 2018). As pilots undergo rigorous training that ensures they meet standards and apply tested methods, there was a limited amount of new information that interviewing multiple pilots would generate. Interviews took approximately 1 hr and participants were reimbursed for their time. The study was ethically approved by the Ethical Research Governance Office at the research institution (ERGO; reference ID: 55820).

2.2. Equipment

The video conferencing platform Microsoft Teams was used to conduct the interviews online and record them. Ordinarily such interviews would take place in person, however video conferencing was found to be a suitable alternative given ‘social distancing’ restrictions at the time of data collection. The participants were able to see the researchers at the same time as a PowerPoint presentation showing the questions were presented to them via the ‘shared screen’ tool.

2.3. Procedure

Semi-structured interviews were conducted with pilots individually by two Human Factors researchers. During each interview, participants were first introduced to the wider project within which the research was being conducted. They were then presented with two scenarios that detail bird-strike events, one with a single-engine failure and one with a dual engine failure. The bird-strike event was selected as it is likely to be a failure event that pilots have experience of, to some degree, or trained for and therefore would have some knowledge to refer to during the interview. The scenarios are stated in full below.

2.3.1. Single engine bird-strike scenario

You are flying a twin-engine aircraft during its initial climb (~ 2800 feet). A flock of birds strike one engine. You must:

1. Determine the criticality of the situation (e.g., state of each engine)

2. Take appropriate action

2.3.2. Dual engine bird-strike scenario

You are flying a twin-engine aircraft during its initial climb (~ 2800 feet). A flock of birds strike both engines. You must:

1. Determine the criticality of the situation (e.g., state of each engine)

2. Take appropriate action

A single and a dual engine failure scenario were presented. Although the Hudson River event led to a dual engine failure, single-engine damage due to bird-strikes has been more frequently reported (Federal Aviation Administration, 2019). The dual-engine strike scenario will likely lead to a more severe incident, yet it was important to capture how the two scenarios may differ. The development of an engine monitoring tool would likely need to function across both scenarios, it was therefore of interest to capture how pilots currently respond to single and dual engine failure events. The altitude of 2800 ft was chosen as this is similar to the altitude that the Hudson river event occurred at (National Transportation Safety Board, 2010). Further, the Federal Aviation Administration (2019) report highlighted the increased risk of damage to engines with bird-strikes above 500 ft. This height would also give some time to allow the decision processes that pilots undergo when faced with engine failures at higher altitudes on take-off, a focus of the future engine monitoring tool.

Participants were first asked to detail their initial thoughts and responses to the scenario in an open manner, with the option to ask for further clarifications from the researchers. Following this the Schema World Action Research Method (SWARM; Plant & Stanton, 2016) was used to interview the participants. The second part of the interview invited participants to comment on the recommendations they would have for a future engine condition monitoring tool.

2.3.3. SWARM interview

SWARM is an interview methodology that was specifically developed to understand aeronautical critical decision making in relation to the PCM (Plant & Stanton, 2016). The method provides a taxonomy of the three key features of the PCM framework; Schema, Action, World (SAW). Plant and Stanton (2016) utilized transcriptions from pilot discussions on critical aviation events to identify 6 Schema themes, 11 Action themes, and 11 World themes relevant to the management of critical aviation events. These comprise the SAW taxonomy (see Appendix A). Each theme has a number of interview prompts that allow interviews to be conducted with pilots to extract information for the development of a PCM. There is a total of 95 prompts, however, they are comprehensive, and not all prompts are relevant to every event, so down-selection is advised (Plant & Stanton, 2016). See Plant and Stanton (2016) for a full list of all available prompts. A selection of 42 SWARM prompts were identified for this study, these were then validated during a trial interview with a pilot. The same prompts were used for both scenarios. The method allowed the information to be captured to create a PCM of both scenarios.

2.3.4. Design recommendations interview

Following the SWARM interview, participants were informed on the development of the engine condition monitoring tool. The researchers explained the concept of the tool which could aid pilot decision making during the bird-strike scenarios. The system was purposely described so as not to fully divulge its intended full capability. Instead, the participants were asked what information (if any) they would want the assistant system to give them and how they may want this information to be presented to them. They were encouraged to think open-mindedly, without being limited to current availability of information. This was key to determining what information users may require of a new system.

2.4. Data analysis

2.4.1. SWARM interviews

The recorded interviews were transcribed and analyzed by Human Factors researchers with experience in the method. Following the approach used by Plant and Stanton (2016), the transcripts were coded to the ‘Schema’, ‘Action’, ‘World’ subtypes. All the interviews were then amalgamated to form a PCM of the single-engine bird-strike and dual-engine bird-strike (Plant & Stanton, 2016). This was done by coding each of the pilot interviews back to the SAW taxonomy (Appendix A) and then grouping this information into the higher-level Schema, Action and World segments of the model.

The segments were then reviewed across the timescale of the event to allow the PCM to present the processes in time order. The phases of the incident were coded as Pre-incident, Onset of the problem, Immediate actions, Decision making, Subsequent actions and Incident containment according to Plant and Stanton (2012, p. 2015). Once the PCMs were developed for both scenarios, they were reviewed by three different subject matter expert groups. A pilot who had 11 years of experience as a commercial airline pilot, an aviation systems engineer and two additional Human Factors experts who have 40 years of combined experience. They reviewed the interactions in the PCM and made any amendments to clarify that they were accurate and representative of airline pilots’ responses, the aviation system and the PCM.

2.4.2. Design recommendation interviews

To generate the user-led design recommendations, the participant responses to the second interview on the future engine condition monitoring tool were analyzed. The responses were transcribed and also coded to the SAW taxonomy. Due to the nature of the engine monitoring tool and the area of focus being the design of a cockpit interface the questions were targeted more at the world sub-types in the taxonomy. This is because the cockpit is a source of information in the environment (world) that the pilots use to interpret what is happening to the aircraft during critical events, such as the scenarios presented. They were also coded for the phase of the incident that they would relate to (Plant & Stanton, 2012, p. 2015). The responses to this section were used to understand how a future system, that could provide enhanced information on engine state, relates to the current PCM processes.

3. Findings

For comparison and due to size restrictions the PCM outputs from both the single and dual engine failure events are presented in table format in Table 1. The processes, which are numbered for reference, are presented in the different phases of the incident that they were coded to. The PCM SAW category coded to each process is also shown. The initial events (1–6) are the same for both scenarios and so are shown across both the single-engine and dual engine columns. Table 1 references the pilot monitoring (PM) and the pilot flying (PF) actions. Sometimes both are equally involved in the same take, other times their tasks vary. Initials in upper case indicate a primary task for that role. Initials in lower case indicate that the task is secondary to their role, suggesting the individual is aware of the task but not directly involved. For example, process 4: ‘Monitor engine indicators’ is stated PM + pf. This is the main task of the pilot monitoring, but the pilot flying will also do this to some extent while they fly the aircraft (process 3.). It should also be noted that the processes in the PCMs are those stated to occur in the majority of cases. The scenarios were hypothetical and therefore the responses of the pilots could also only be hypothetical, based on their training, knowledge, and experience.

Table 1. PCM processes for the single and dual engine failure, coded to the phases on the incident

Incident Phase	Single Engine Failure	Dual Engine Failure
Pre incident	WORLD: 0. Emergency turn procedure briefing (PF+PM) 0. Weather update on the ground (PF+PM)
Onset of incident	WORLD: 1. Bird-strike to engine (PF+PM) SCHEMA: 2. Startle/surprise effect (PF+PM) ACTION: 3. Fly the aircraft (PF)
Immediate response	ACTION: 4. Monitor engine indicators (PM+pf) WORLD: 5. Evidence of bird-strike (PM+pf) SCHEMA: 6. Assess information and generate expectations (PF+PM)
	ACTION: 7. Cross confirmation between pilots (PM+PF)	ACTION: 7. Captain takes over flying the aircraft (PF) 8. Action Emergency Turn procedure – if required, or appropriate intervention of aircraft path (PF) 9. Call ATC- May Day (PF)
Decision Making	ACTION: 8. Determine the severity of the damage and required actions (PM+PF) WORLD: 9. Information on engine failure severity (PM + pf) (Engine indicators, ECAM/EICAS, message, Visual from cabin crew) SCHEMA: 10. Knowledge of what indicator determine about engine failure severity (PF+PM) 11. Response to single engine failure on take-off is regularly trained (PF+PM)	ACTION: 10. Determine the severity of the damage and required actions (PF+PM) WORLD: 11. Information on engine failure severity (PM+pf) SCHEMA: 12. Knowledge of what indicators determine about engine failure severity (PF+PM) 13. Limited training for dual engine failure on take-off (PF+PM)
Subsequent Actions	ACTION: 12. Action Emergency Turn procedure – if required (PF) 13. Run through memory checklist items (PF+PM) 14. Call ATC- MayDay/Pan (PF) 15. (a) Run through physical checklist items (ECAM/QRH) actions (PF+PM) WORLD: 15. (b) Physical checklist (ECAM/QRH) (PF+PM) SCHEMA: 16. Use any knowledge on local environment/airports for landing (PF+PM)	ACTION: 14. (a) Run through checklist actions (PM+pf) WORLD: 14. (b) Physical checklist (ECAM/EICAS) (PM+pf)
Incident Containment	ACTION: 17. Decide to shut engine down and turn back (T-DODAR) (PF+PM) 18. Communication to ATC (PM) 19. (a) NITS briefing (PM) WORLD: 19. (b) Landing space (PF+pm) ACTION: 20. Calculate landing distance (PM+pf) 21. Review Brief and prepare for landing (PF+pm)	SCHEMA: 15. Use any knowledge on local environment/airports for landing (PF+PM) ACTION: 16. T-DODAR: Time, Diagnose, Options, Decide, Assign, Review (PF+PM) 17. Land the aircraft in best possible location (PF+pm) WORLD: 18. Landing Space -Window, Nav display, ipad (PF+pm)

3.1. Single engine bird-strike scenario

All pilots stated that they receive training for a single-engine failure event on take-off as a part of their standardized training that they undertake on a regular basis. During training, the cause of the engine failure is not noted as important as it focuses on how to manage the failure, regardless of how it is caused. Therefore, bird-strikes specifically are not commonly found within training but the single-engine failure event on take-off would assist them in responding to the bird-strike in this scenario. Three pilots said that they had experienced a bird-strike to a single engine in the real world but that it had not been big enough to cause any damage to the engine and therefore did not alter their procedures on the flight deck. Only one pilot reported experiencing a single-engine failure due to a bird-strike in the real world. At the time the pilot was flying a four-engine aircraft and they were able to shut the engine down and continue with their flight as the size of the aircraft was much larger than the one proposed in the scenario presented in this study. They were also flying a short haul flight and were confident they could make it to their intended destination. Six pilots stated that they had experienced bird-strikes to areas other than the engine (e.g., to the nose, landing gear, wing).

The pre-incident phases highlight the relevance of the pre-flight briefing and weather updates (0) that the pilots receive prior to take off. These are utilized later on in the incident. The event itself starts from the initial event occurring in the world when the flock of birds initially hit the engine (1). The pilot’s suggested that they would likely see the birds out the window just before they hit the aircraft. Other physical cues may be a bang, vibration, or feeling of impact, although these are less likely depending upon the mass of the bird(s). Pilots reported that the strike is likely to lead to some sense of surprise and/or startle initially (2), as this is deemed to be a rare event. The pilots’ primary response is to maintain the safe flight of the aircraft (3). At a height of 2800 ft, the autopilot is likely to be on and pilots reported that they would be keen to keep it active to reduce their workload for processing the event and maintaining the safe flight of the aircraft. The PM would simultaneously monitor the engine indicators in order to understand what impact the event may have had on engine performance (4). The PF would also be looking at this information, but as they are primarily flying the airplane this is a secondary task for them.

The indicators within the cockpit currently, while varying slightly across aircraft manufacturers, present some key information on the functioning of both engines including its power output, rotation of the blades, vibration, temperature, and fuel flow (5). This process is highlighted and in italics (Table 1) to reflect that pilots stated that they may not be fully supported by the system. Pilots then have to apply their knowledge of the engine outputs to diagnose what is wrong with the engine and therefore how they respond. The classification of an engine failure was broadly described by pilots from different levels of severity from ‘normal engine failure’, ‘abnormal/severe engine failure’ to ‘engine fire’. The last being the most severe. The classification of the failure into these categories can then affect what the pilots’ response will be. Despite this, pilots mentioned that often they cannot be absolutely sure what the failure is, therefore they have to make assumptions on what they think is happening (6). This is also highlighted in Table 1 to show a breakdown between the information in the world, the indicators, and a clear understanding of how they are interpreted by the pilots’ schema in order for them to make sense of the situation.

To try and diagnose the situation both pilots in the cockpit will cross-confirm to determine if they are in agreement (7). They may also contact the cabin crew to see if there is anything that they can see from the engine itself. Between the pilots, they will then try to establish the severity of the damage and their required actions (8). Referring back to engine indicators, the Electronic Centralized Aircraft Monitor (ECAM) or the Engine Indicating and Crew Alerting System (EICAS) systems (depending on the aircraft manufacturer) and any information from the cabin crew on the state of the engine (9), they again have to make assumptions on how severe the engine damage may be and how they should respond. This is not always clearly depicted by the information they have to hand. Using their knowledge (10) and regular training (11) on single-engine shut down on take-off, pilots stated this would be the most likely course of action. The processes that follow (12–21) present how pilots respond to returning the aircraft to the ground; including, the checklists that they have to carry out to secure the engine, communications with Air Traffic Control (ATC), and briefing the cabin crew with a NITS (Nature-Intentions-Time-Special instructions) brief. To land the aircraft the pilots need to be aware of their surroundings (16) and will use their knowledge of the area as well as navigation or terrain aids (19b).

The single-engine landing, while not an ideal scenario, is one that pilots train for regularly, therefore they were confident in their actions and how to proceed. They commented that they would have enough time to conduct the required actions and, if necessary, go into a hold before landing. Pilots also highlighted that as they had just taken off, could therefore be overweight for landing so would need to calculate their landing distance. As the landing procedure is out of scope of this work, the PCM was ended at this point. Appendix B presents more detail on the mapping of the SWARM subtypes to the stages of the incident, with quotes taken from the interviews.

3.2. Dual engine bird-strike scenario

None of the interviewed pilots had experienced a dual engine bird-strike or a dual engine failure in the real world. Two pilots had experienced a dual engine failure due to a bird-strike during training. This was due to their airline training on events similar to real-world aviation incidents; in this case training on the Hudson River incident. One pilot said that this training would have assisted them if they were to face this event in the real world as it would have significantly reduced the surprise and startle effect and therefore their response would be quicker. One pilot had experienced a dual engine failure during cruise at 20,000 ft in a training exercise but they stated that this would not assist them in this scenario where the event happens soon after take-off.

While many of the key processes in the two scenarios are similar, there are some important differences. Again, as shown in Table 1, the pre-flight briefing is important to later actions (0). The presence of the bird-strike in the world is the origin of the event (1). Within the dual engine strike scenario, it was believed the impact was more likely to be felt or heard; and the pilots thought it would be likely they would see the flock of birds. The startle/surprise effect (2) was reported to be much greater in this scenario as it is a much more critical event. Again, flying the aircraft is the main priority and in this scenario, pilots reported that the PF would deliver max thrust to both engines (3) to determine how much thrust they had available, as this is key to remaining airborne. If the autopilot is still on (it can deactivate and require the pilot to take over in some cases) then the pilot would keep it active to reduce workload. The PM, and to some extent the PF, would monitor the engine displays (5). This would include the same parameters as the previous scenario, yet this time they would identify that there may be potential issues with both engines. Again, the process of assessing this information to determine the exact nature of the issue was highlighted, as pilots reported that they may not be sure what the diagnosis of the engine damage was. Pilots stated that this scenario would be a lot more time critical and therefore there would be less cross-confirmation and analysis. This is where the scenario converges from the single-engine failure scenario. The captain would likely take over the flying of the aircraft (7) (note this was reported for most situations, but it is a personal preference and also heavily dependent on many contextual factors). The captain/PF would action the emergency turn procedure (8) to turn back to the departure airport, although the severity of the situation may mean that they cannot make this landing site and therefore they would have to turn to an appropriate landing site. (“ … then you’re forced into trying to return to where you just left with no engines which you may or may not make. Or worst-case scenario, putting it in a field or a river or the sea or something like that … ” p2). The call to ATC to state a Mayday (9) would occur a lot earlier on in this scenario than the previous scenario as they will have less time available. It will also always be a Mayday call due to the criticality whereas in the previous single engine scenario some pilots stated that a Pan call may suffice. They would then determine the severity of the engine failures and the required actions (10). This requires looking back to the engine parameters (11). In this scenario they would not have the time to gain extra information and visuals from the cabin crew.

Importantly here, pilots stated that they have little information on how to prioritize the two engines, that is if one engine is in better condition than the other it would make sense to keep this one running and shut the worst-performing engine down first. Instead, they are directed to manage them individually without knowing the status of the other. This can lead to a scenario of shutting down one engine that was functioning, albeit with limited power, but was in a better condition than the other engine. Therefore, the processes between 11 and 12 on Table 1 are highlighted as being areas where more assistance would be beneficial to the pilot. Furthermore, pilots also stated that they did not train for this scenario (13), or at least not regularly, and they would therefore be a lot less prepared than in the first scenario which is frequently trained in the simulator. Once the situation has been diagnosed, the PM would run through the required checklists, with assistance from the PF (14), this includes the memory checklists and physical checklist such as the ECAM or hard copy of the Quick Reference Handbook (QRH) (14b).

The dual bird-strike scenario is very time critical, and pilots reported that they would be looking to get the aircraft down on the ground as soon as possible, and that this may mean not reaching an airfield. Therefore, in this scenario, pilots were even more concerned with understanding where they were in relation to their surroundings so that they could determine a safe landing site. Many highlighted that their local knowledge of landing sites from frequently used airports would be beneficial here (15).

Pilots stated that, as with the previous scenario, they would use their company specific decision tool (e.g., T-DODAR), which would help structure what their next actions are (16). Again, this scenario finishes with the landing of the aircraft (17/18).

See Appendix C for the processes in Table 1 mapped to the SAW subtypes and incident phases in the analysis of the interviews on the dual-engine bird-strike, with quotes from the pilots.

3.3. Design Recommendations

Responses to the interview on the future engine condition monitoring tool were also categorized using the SAW taxonomy and the incident phases to determine where in the incident they may provide assistance. The frequency of the subtypes that the participants recommendations were coded and their break-down across the incident phases are shown in Table 2. The frequencies relate to the number of participants that reported the recommendations.

Table 2. Frequency of pilots that reported recommendations coded to the SAW subtypes across each of the incident phases

SAW Subtype	Incident Phase
	Pre-incident	Onset of incident	Immediate response	Decision Making	Subsequent Actions	Incident containment
Severity of problem				6	2
Display indicators				4	1
Communicated information					3
Aircraft status				1
Technological conditions					1

All of the coded subtypes related to the ‘World’ element of perceptual processing, as expected, due to the system being a future cockpit tool that provides information to the pilots on the engine state. The most frequently identified sub-type was ‘severity of the problem’ which was reported by six participants at the decision-making phase of the incident and two participants at the ‘subsequent actions’ phase. These were comments that focused on pilots’ desire for further information on the severity of the engine damage in order to inform their decision on what the next course of action would be. ‘Display indicator’ was another commonly referenced sub-type and captures the pilots desire for information that the tool may be able to provide with the other engine monitoring parameter on the flight deck (e.g., on the EICAS or ECAM system). Further detail on the design recommendations that were made by the pilots are presented in Table 3.

Table 3. Specific user design recommendations for the functionality of the engine monitoring tool

Recommendation	User Quote (participant number in brackets)	SAW subtype
Decision Making phase
Information on where the damage is and the state of damage. Assistance telling you which engine is more severely damaged in the dual engine scenario and if one can still be used. Prioritization of engine failure for the dual engine scenario Less ambiguity on state of damage.	“It’s sometimes a little bit ambiguous as to if there has been damaged, so really something to say yes, there’s been damage or no, there hasn’t been damaged and just sort of put that in a box for you” (P2) “All decisions are based on assumptions at this point because you don’t know what has happened for sure (where it has happened, what it has hit, strength of impact etc).we would want to know where it has hit and some form of severity” (P1)	Severity of problem
Present as a message on the status page or engine parameters page. A single button, on the EICAS/ECAM existing system would bring up the information on a separate page Camera view of the engine to see the extent of the damage	“I would think it would be part of the normal EICAS” (P5) “there is a little console with a few buttons you can push and you can bring up the engine parameters page and probably just presented there somewhere, somewhere on either the ECAM status page or the engine on the engine page.” (P6) I would have a little camera at the side of my plane pointing toward the engine that I can just see at my screen … then I know if I’m on fire or if part of my engine is falling off” (P3)	Display indicator
Information on deformation of the fan blade could let you determine if that was causing vibration and if it was severe damage	“If you’ve got the same amount of fan blade, but it’s deformed and that’s causing the vibration … or if you lost anything, you can probably monitor the mass of the of the fan blades. Then that will be an indicator to if you have caused any severe damage and lost anything weight wise um then you know that there was severe damage to your engine rather than just a deformation which would be causing vibration” (P5)	Aircraft status
Subsequent Actions phase
Information on safe to relight would be useful so know if you can continue.	“maybe just as a message that says … this part of the engine is damaged beyond repair. That would give you a good indication of whether it would be wise to attempt to restart … with the information we’ve got right now the key is to give you enough without overloading you” (P6)	Severity of problem
Indicators inform if engine is still usable when faced with the dual engine scenario	“give you a warning that actually turning off an engine that it’s on fire, but it’s still kind of still kind of works is not necessarily the desired result” (P2)	Display indicators
Inform on the best cause of action e.g., bring up a checklist of what to do	“it could say it is severe damage … .and then it would bring up the severe damage checklist or it could say over temp and brings out the checklist to throttle it back … all I want it to do is tell me what checklist.” (P4)	Communicated information
Status message on what the systems are processing and place it on the EICAS/ECAM	“if the system told you that: engines failed, we are attempting to do a relight of this particular engine. A status message to that effect would be quite useful, I think” (P8)	Technological conditions

The design recommendations can then be contrasted back to the PCMs that were developed. This is useful in determining how the recommendations suggested by the pilots may be applicable to current processes that they identified through the SWARM interviews. Application of the recommendations to the PCM can be seen in Figure 2.

Figure 2. PCM of an engine failure due to bird-strike showing the placement of user design recommendations.

From Figure 2 it can be seen that the recommendation to provide initial information on what the system is processing, suggesting that there may be some damage to the engine, would assist with the initial assessment of information by the pilots at the decision-making phase. Pilots suggested that this should be followed by more detailed information including an indication of severity. They wanted this information to reduce the ambiguity as to the severity of the damage to determine the actions that they would need to take (i.e. shut the engine down, return to base or even continue if the damage was not severe). One pilot suggested that the best way of facilitating this would be a camera view of the engine so that they could determine the extent of the damage themselves without the need for technology to potentially complicate the matter. This would also reduce the need to contact cabin crew for further information on what they could see (a step that pilots said they would likely do in the event of single engine strike but would not have time to perform in the dual engine scenario). Most of the other pilots stated that they would only want very simple information that they could use to determine the severity of the damage to clarify their actions. Once they had generated their expectation on the event based on the improved knowledge of the extent of the damage to the engine, they could have a more accurate cross-confirmation between the PM and the PF to assess the severity and the required actions. During the subsequent actions phase the pilots’ recommendations highlighted that they would benefit from knowing what the possible options were in relation to an engine relight or shut down. One pilot commented that they would want to receive a message that clarified the state of the damage and then the checklist that would be required to take the appropriate actions in responding to the damage. Within the single-engine scenario, the pilots were heavily trained in managing an engine failure after take-off, but they felt that a future system could benefit them in providing more detail on the severity of the damage to prevent ambiguity and confirm their intended subsequent actions were advisory.

In contrast to the single engine, the dual engine bird-strike was classified by pilots to be a lot more time critical, with the outcomes being less certain. This was therefore a scenario where the pilot’s workload would be considerably higher and their capacity to process extra information would be reduced. Therefore, the emphasis was to not provide any overloading information, as they would not be able to process it. However, pilots stated again that information on the severity of the engine damage would be useful in this scenario during the ‘Decision-making’ phase. This would allow them to determine which of the engines may be performing better; and if any thrust could be obtained from the engine to improve their chances of returning to land at the closest available airport.

More accurate information of the severity of each engine would also assist in prioritizing engine shut down during the ‘Subsequent action’ phase. Multiple users proposed a prioritization feature that could allow them to respond and manage the engines in an order that reflected the severity of their damage and would reduce the likelihood of shutting down an engine that may be able to provide some assistance despite the damage it had encountered.

It should be noted, that the dual engine scenario was deemed to be largely outside of the training that they regularly receive and therefore it was difficult for pilots to envisage the type of information that they would be able to effectively use and respond to in the time that they would have in real life.

The interviews with the pilots also identified design recommendations that were not specific design concepts within themselves, but more directive of how the pilots would like any information from an engine monitoring tool to be presented. These are listed in Table 4, with user quotes for more detail. They provide useful feedback to manufacturers when scoping the design of future flight deck applications, and may not be specific to the engine monitoring tool presented here in relation to bird-strike events.

Table 4. General design recommendations for the presentation of the information from an engine monitoring tool

General Recommendation	User Quote (participant number in brackets)
Keep it simple	“Pilots don’t want to be overwhelmed with engineering information” (P1)
Give guidance on what actions to take next	“If manufacturers were to put it in, it would have to then specify what they want [us] to do” (P1)
Has to be trustworthy	“It would have to be like EICAS a totally trustworthy thing” (P4)
Any additional information system would have to associated training, especially in these high workload scenarios	“I think if you start introducing a lot more information to the cockpit, there’s got to be a corresponding training element and by training that, it becomes something else to do in a fairly high workload scenario” (P8)
Do not overload with too much information	“I actually don’t think in this situation that more information is of any benefit … One more decision to try and make about whether or not I should keep the engine limping along or not” (P8) “too much information isn’t necessarily good thing” (P2) “remember I want to have a clear mind. I don’t want to be bamboozled with a lot of information” (P4)
Don’t tell them what to do, only guide	“you need to think, so if you get too much information … If it would say like shut down engine now … It would stop people thinking completely” (P3)
Don’t make it too technical	“The thing is the problem, if you make it too computerized, it makes it less usable” (P3)

4. Discussion

Technological advancements hold the potential to provide enhanced information to the pilot on the flight deck, to allow them to make more informed decisions. The aim of this work was to understand the current decision-making process of pilots when faced with both single and dual engine failures on take-off and identify any shortcomings that can guide the requirements of a future enhanced engine monitoring system.

Approximately 8.5 hours of interviews were conducted individually with eight commercial airline pilots with a range of different experiences. Utilizing the SWARM interview approach and the SAW taxonomy (Plant & Stanton, 2016) to construct PCMs, generated insight into the interaction between the decision-maker (the pilot) and their environment (the cockpit). Crucially, the PCM outputs presented in Table 1 show that pilots feel they could be better supported by the information available on the flight deck to make more informed decisions when faced with these scenarios. Applying the SAW taxonomy (Plant & Stanton, 2016) to classify the recommendations provided by the pilots suggested how the enhanced monitoring system may be able to mitigate the current sources of uncertainty within the processes of responding and engine failure events on take-off (Figure 2) shown through the ‘World’ themes: ‘display indicators’ and ‘severity of problem’.

Across both the single and dual engine bird-strike it was evident that there may be a gray area in the pilots’ current diagnosis of the severity of damage when a bird strikes the engine of the aircraft. The engine parameters currently available do not always give sufficient information on the severity of the damage in order for the pilot to categorically classify it. This can then affect the subsequent actions that pilots undertake, such as securing the correct engine and returning to the ground.

Within the single-engine scenario, pilots stated that they could respond to a possible engine failure from the current instruments available and decide to shut the engine down, as this is a standard training exercise. However, they stated that they are often working from assumptions on what the condition of the engine is and the extent of the damage. If they were better informed, they would be better able to diagnose the damage and respond optimally. In an error analysis of a critical inflight event regarding a possible engine failure, Parnell et al. (2019) identified that retrieval error was the most common error type to occur. Retrieval error is when an individual receives incorrect information through erroneous information or misinterpretation. This highlights the importance of providing accurate and informative data on the flight deck.

In the dual engine, failure scenario pilots highlighted that they would have very limited time and they would have a high workload that would impact the information they could use to assist their decision making. This is something that has previously been shown within pilot decision making during critical events using the PCM (Plant & Stanton, 2012). Analysis of the Kegworth incident by Plant and Stanton (2012) suggested that one of the contributory factors was that the pilots acted almost instantaneously on what they thought the issue to be, guiding action with their previous experience and automatically responding. The analysis suggested that their responses may have been premature and not in accordance with their training which required them to review their options. Within the dual engine bird-strike scenario, pilots stated that they would have limited guidance from the current information on which engine to prioritize when two engines are damaged. Taking immediate action and shutting down one engine that could have provided some thrust, despite potentially being on fire or at risk, was stated by the pilots to be an issue that the engine monitoring tool could assist with. The pilots suggested providing comparable information of the damage of each engine in order to determine if either could be usable. This would prevent them taking immediate action on one engine which may not be advisable.

With an awareness of how the current processes in the pilots’ response to the events interact, recommendations for a future avionic system that could present enhanced information on the state of the engine could be reviewed. Understanding the interaction of a future system within the broader system is key to reduce the possibility for error or new opportunities for misuse (Kirwan, 1998).

4.1. Generating design requirements for future avionic systems

A key reason for the work conducted within this study was to understand the current scope for a future system and provide recommendations for its design. The recommendations that were generated came from qualified pilots, with a range of different backgrounds. Grounding the results of this work within the recommendations of the users hopes to prevent the possibility of future errors due to poor design (Norman & Draper, 1986; Parnell et al., 2020). As the intended avionic system will introduce additional information to the pilot, adjusting their interaction with the cockpit, it is vitally important the user is integrated within the design process (Kaber et al., 2002). Previous work has suggested that the generation of design recommendations for future avionic systems should be undertaken by a combination of Human Factors professionals and end-users of a system (Parnell et al., 2020). This is because user insights may often compliment human factor approaches as well as extending them to generate unforeseen implications and areas of focus that those without expert knowledge in the domain cannot fully comprehend. This has been further demonstrated here with a significant number of design requirements generated from users that can be used to guide the initial design process for the engine monitoring tool.

Key takes away messages for the manufacturer when designing this system are that pilots would expect to see information regarding the engine status alongside their current engine parameter gauges on their EICAS/ECAM (or similar) system. As this is the area they are likely to be studying during this phase of flight, it seems sensible to present any additional information here. The type of information that they may require is related to the severity of the damage, which can currently be difficult to determine. Some pilots would also like to be informed of the relevant checklists that apply to the damage sustained, although not all want to be guided too much by a system. Furthermore, any presented information must also be accessible, simple and not overly technical. These recommendations, however, form only an initial starting point with which to scope the future design of the system and much further testing of the relevance, application, and performance of a resulting system are required.

Importantly, all pilots stated that it was not necessarily important for them to know that it was a bird that had hit the engine. Their role is not to respond to the event itself but the damage and manage the resulting effects efficiently. Therefore, their responses are not limited to bird-strike engine failures per se but engine failures on take-off.

4.2. Next steps

Implementation of new technological systems onto the flight deck is not a straightforward or quick process, and designs must undergo substantial analysis and verification to determine if they meet the required standards (De Florio, 2016). Any aviation technology must meet the criteria for certification set by the FAA before it can be introduced into the cockpit. Following recent accidents with the Boeing 737 MAX (e.g., Wendel, 2019), bipartisan legislation was recently introduced to reform the way the FAA certifies aircraft and references an increased need for Human Factors certification to assess the relation between humans and interfaces within the flight deck (Aircraft Safety and Certification Reform Act of 2020). Furthermore, the whitepaper by the CIEHF (2020) highlights the important role Human Factors plays in the development of the aviation domain going forward. However, the process of applying Human Factors into the design process is not straight forward or clearly defined. This work suggests how Human Factors principles can be included within the design process from its inception to generate user-led design requirements that should improve human-interface relationships (Norman & Draper, 1986; Harris, 2007; Stanton & Young, 2003). Yet, the sample size was small and considerable work is still required to develop the design requirements together with aviation engineers, manufacturers, human factor professionals and pilots. This was only intended to be a small-scale initial study to gain an understanding for the current decision-making processes that occur in the cockpit and how pilots feel this could be improved with enhanced information. To ensure the design process effectively accounts for the human-interface relationship it should be iterative and the user should be kept involved throughout its entirety, providing design guidance (e.g., Parnell et al., 2020), as well as in design evaluation (Stanton et al., 2013).

4.3. Evaluation

Previous applications of the PCM to assess decision-making have focused on incidents the users have personally experienced (e.g., Banks et al., 2018; Plant & Stanton, 2012; Revell et al., 2020). Yet, in this paper hypothetical decision making was used for events that not all pilots had directly experienced (especially the dual engine scenario). This meant that the processes represented in the PCMs are also hypothetical and tend to be what is advised. Research has shown that pilots do not always act in the way that they say they will act, or how they have been trained to act, when critical events occur in the real world (Casner et al., 2013). This was largely due to limited ability to recognize abnormal events outside of training where events are unpredictable (Casner et al., 2013). Therefore, caution should be heeded when interpreting the reports in this study as the trained processes described could differ to what pilots would actually do if the event was encountered in the real-world. However, this does also highlight the need for clear information presenting the extent of damage to the engine in such a scenario to enable to the pilot to recognize the situation an diagnose it appropriately.

5. Conclusions

Integration of Human Factors within the early stages of the design process of new flight-deck technologies is important to generate improved design outcomes that are usable and safe for future integration into the flight deck. This work shows how Human Factors principals can be used in the very early stages of the design process. The PCM is used to illustrate pilots reported decision-making in response to managing a single engine and dual engine bird-strike scenario (on a twin jet engine commercial aircraft) to provide recommendations for an engine condition monitoring tool. Involving pilots in the development of the PCM using a detailed interview methodology identified where the pilots feel that the information currently available could be enhanced to ensure they are better supported in their decision making. The user interviews generated user-led design requirements. These include aspects of a future avionic system that pilots would feel would be beneficial, as well as highlighting the limited processing capacity they may have during the bird-strike scenarios studied. However, it should be noted that only a small sample of pilots was used and therefore further design and evaluation processes are required to build on and evaluate these recommendations before operational testing and assessment in the development of an engine condition monitoring tool.

Acknowledgments

This project was co-funded by Innovate UK, the UK’s Innovation Agency, with support from the UK Aerospace Technology Institute. We would also like to extend thanks to the pilots who took part in our interview study for their invaluable contributions.

Additional information

Notes on contributors

Katie J. Parnell

Katie Parnell is a Chartered Ergonomist and Human Factors Specialist currently working as a Human Factors Research Fellow within the Human Factors Engineering research group at the University of Southampton. Her current role is on the Open Flight Deck project, focusing on future cockpit design in commercial aircraft.

Rachael A. Wynne

Rachael Wynne is a Senior Research Assistant with Human Factors Engineering, part of the Transportation Research Group at the University of Southampton. She has a background in psychology and is working on the Open Flight Deck project. Her PhD research was in the fields of Psychology and Human Factors.

Thomas G. C. Griffin

Tom Griffin has been flying for over 20 years in a variety of roles including instruction, air ambulance, business aviation and currently as a long-haul pilot for a legacy airline. Tom’s doctorate looked at further understanding the human factors involved in aviation accidents using non-linear methodologies.

Katherine L. Plant

Katherine Plant is a Lecturer in Human Factors Engineering in the Transportation Research Group at the University of Southampton. Her current research projects are in aviation human factors, road safety in developing countries and cycling safety in the UK.

Neville A. Stanton

Neville Stanton is a Professor of Human Factors Engineering in the Transportation Research Group at the University of Southampton. He is a Chartered Psychologist, Chartered Ergonomist and Chartered Engineer. His interests include modeling, predicting, analyzing and evaluating human performance in systems as well as designing the interfaces and human-technology interaction.

Appendix A.

SAW Taxonomy

Schema Action World Taxonomy as defined in Plant and Stanton (2017)

Table

Taxonomy subtype	Description
Schema Subtypes
Vicarious past experience	Statements relating to experiencing something in the imagination through the description by another person (e.g., hearing a colleague recall an incident they were involved with) or documentation (e.g., reading about a certain event in an industry magazine or incident/accident report)
Direct past experience	Statements relating to direct personal experience of similar events or situations in the past. This covers events experienced in live, operational contexts as opposed to those experienced through training.
Trained past experience	Statements relating to knowledge developed by direct personal experience of a specific task, event or situation, experienced within the confines of a training scenario (e.g., ground school training, simulator training or training sorties) Statements relating to a schema that manifests as a descriptive knowledge of facts, usually as a product of the world information available
Declarative schema	Statements relating to comparisons between things for the purpose of explanation and clarification. Typically these analogies will be structural analogies of physical objects or states of affairs in the world (akin to mental map or mental model)
Analogical schema	Statements relating to inadequate or lacking knowledge, i.e. a schema is not developed for a certain situation
Insufficient schema	Statements relating to experiencing something in the imagination through the description by another person (e.g., hearing a colleague recall an incident they were involved with) or documentation (e.g., reading about a certain event in an industry magazine or incident/accident report)
Action Subtypes
Aviate	Statements relating to direct manipulation (handling) of flight controls in order that the aircraft can be flown and safety is maintained
Navigate	Statements relating to the process of accurately ascertaining position and planning and following a route or desired course
Communicate	Statements relating to the sharing or exchange of information
System management	Statements relating to the processes of making an input into technological systems in order that the interaction or manipulation has an explicit output
System monitoring	Statements relating to looking at (observing, checking) displays to gain an understanding of the situation
Environment monitoring	Statements relating to observing or checking the internal or external physical environment in order to establish the current state-of-affairs
Concurrent diagnostic action	Statements relating to the process of determining, or attempting to determine, the cause or nature of a problem by examining the available information at the time the incident is occurring
Decision action	Statements relating to a conclusion or resolution that is reached after considering the available information
Situation assessment	Statements relating to actions that relate to the evaluation and interpretation of available information
Non-action	Statements relating to actions that were not performed, either because the situation didn’t warrant a particular action or because equipment faults did not allow a particular action to be performed or because the pilot made an error or omission.
Standard Operating Procedure	Statements relating to following the prescribed procedure that ought to be routinely followed in a given situation
World Subtypes
Natural environmental conditions	Statements about natural environmental conditions (e.g., weather, light, temperature, noise)
Technological conditions	Statements relating to the state of technological artifacts (e.g., with regards to appearance and working order)
Communicated information	Statements relating to information available to the pilot from other people (e.g., other crew members, ATC, coastguard etc.)
Location	Statements relating to particular places or positions
Artifacts	Statements discussing physical objects, including written information, symbols, diagrams or equipment
Display indications	Statements relating to the information elicited from the physical artifacts
Operational context	Statements relating to the routine functions or activities of the organization (e.g., Search and Rescue, Police search, military training etc.). This can include statements about the importance of being serviceable for the operational context or crew familiarity with the aircraft and how this effects decision making.
Aircraft status	Statements relating to the current status of the aircraft’s integrity or performance (e.g., how good or bad it is flying, the current configuration of the aircraft, autopilot activation etc.)
Severity of problem	Statements relating to how bad (or otherwise) the critical incident is
Physical cues	Statements relating to external cues that provide information of conditions
Absent information	Statements relating to information that was missing, not present or lacking.

Appendix B.

Single engine failure table of processes

SAW subtype and incident phase classification and interview evidence in quotes for the single-engine bird-strike

Table

Incident Phase	PCM Category	SAW Subtype	Process	Actors	Quote (participant number in brackets)
Pre-incident	World	Artifact	0. Emergency turn procedure briefing	PF+PM	“this again would have been part of our pre-departure briefing, we would need to know what our emergency turn procedure is” (P5)
Pre-incident	World	Artifact	0. Weather update on the ground	PF+PM	“Because you’ve done your preflight briefing, you’ve already seen the weather” (P6)
Onset of incident	World	Physical Cue	1. Bird-strike to engine	PF+PM	“OK um first one then … you basically cleaned up, you’re in the initial part of the plan … and bang it’s usually quite attention getting” (P4)
Onset of incident	Schema	Insufficient schema	2. Startle/surprise effect	PF+PM	“and you will have an element of startle and then surprise” (P7)
Onset of incident	Action	Aviate	3. Fly the aircraft	PF	“First thought is flying the aeroplane, so you are not interested in what has happened, but how it has affected the flight initially” (P1)
Immediate response	Action	System Monitoring	4. Monitor engine indicators	PM+pf	“So, the things that we would normally be looking at … your damage indications are determined at the moment by like high vibrations on the engine or just a lack of rotation so that is you N1, N2 numbers giving your rotation on the different spools.” (P5)
Immediate response	World	Display indications	5. Evidence of bird-strike	PM+pf	“[if] you hit a bird somewhere you think … did it hit the engine and an if it did hit the engine, if it is a small bird sometimes you don’t even get an increase in temperature or burning smell, it just goes through … I think if you hit a large bird you would get that increase in temperature … . you could smell it and you could get a little bit of vibration.” (P3)
Immediate response	Schema	Analogical Schema	6. Assess information and generate expectations	PF+PM	“For instance, if there was a large bang, you’d expect to be some sort of like structural damage to the engine.” (P2)
Immediate response	Action	Communicate	7. Cross confirmation between pilots	PM+PF	“We look at our modes on the screen. And we basically just read them out and confirm that they are what we want them to be” (P6)
Decision Making	Action	Concurrent Diagnosis	8. Determine the severity of the damage and required actions	PM+PF	“So obviously having had the engine failure, have we had to do any vital actions, and if so, which vital actions? Obviously if we had to do some of the memory drills from the vital actions, it’s probably quite a big problem” (P8)
Decision Making	World	Display indications	9. Information on engine failure severity	PM+pf	“you would probably at that point have a red ECAM which is basically in an alert from the system saying that there’s been an engine failure.” (P6)
Decision Making	Schema	Declarative Schema	10. Knowledge of what indicator determine about engine failure severity	PF+PM	“Have we lost, any hydraulics and have we got sort of severe vibrations stuff like that and have we got a really high EGT is another thing we look for, again that would imply an there’s serious damage to the core of the engine.” (P2)
Decision Making	Schema	Trained past experience	11. Response to single engine failure on take-off is regularly trained	PF+PM	“we train this like every year, you have the engine failure after take-off they called a FATO (failure after take-off … and you have to pass that so if you don’t pass it, you have to redo the whole thing.” (P3)
Subsequent Actions	Action	Navigate	12. Action Emergency Turn procedure – if required	PF	“There’s also things called emergency turn that are built in which are company specific and if you had to follow an emergency turn you would notify air traffic off that emergency turn” (P7)
Subsequent Actions	Action	SOP	13. Run through memory checklist items	PF+PM	“We agree what we think the problem is, that could lead into a vital action. Some people call it memory drill, (COMPANY) were quite unique in calling it a vital action, but it was just basically emergency procedure that you carried out from memory on the spot given a certain set of circumstances for things such as engine failure, things that were endangering the safety of the flight.” (P8)
Subsequent Actions	Action	Communicate	14. Call ATC- May Day/Pan	PF	“There is an argument to be had that you can just declare a pan. I personally wouldn’t. Because you can declaring a MayDay and actually downgrade to a Pan, so I’d be inclined to the declare the MayDay ‘cause that gets everyone aware of what’s happening.” (P6)
Subsequent Actions	Action	System management	15. (a) Run through physical checklist items (ECAM/QRH) actions	PF+PM	“If it’s all contained and everything is fine even after doing vital actions, we still might have to do a checklist that involves pulling up the QRH. The big book at the back of the cockpit which has got loaded checklists in and then following a prescribed drill for a set of events which could be secure an engine even just conducting a single engine landing that requires, it’s not so much a checklist, but it’s more a procedure that you run through to make sure you’re doing the right thing to go back.” (P8)
	World	Artifact	(b) Physical checklist (ECAM/QRH)	PF+PM
Subsequent Actions	Schema	Declarative Schema	16. Use any knowledge on local environment/airports for landing	PF+PM	“So assess the situation. I know that if I fly from Gatwick, there’s no [terrain issues] Surrey hills are as high as it goes … so if I’m at 3000 feet, I would be above minimum safe altitude in Gatwick.” (P5)
Incident Containment	Action	Decision Action	17. Decide to shut engine down and turn back (T-DODAR)	PF+PM	“So that’s the situation where you’ve got to have a conversation between yourselves and say, well, do you think there is damage? I think there is OK yeah me too so we won’t try and relight the engine. … And then we do a T-DODAR at (COMPANY)” (P2)
Incident Containment	Action	Communicate	18. Communication to ATC	PM	“Ideally, once you run out of the essential things to do, you speak to air traffic. And they would probably see something going on on the transponder … ” (P4)
Incident Containment	Action	Communicate	19. (a) NITS briefing	PM	“I’m gonna do a NITS briefing. Got a pen and paper? they say yes to take out pen and paper and you say right the nature of the issue is we had an engine problem. You try and just keep it really concise and not complicated.” (P2)
	World	Natural Environment	(b) Landing space	PF+pm
Incident Containment	Action	System management	20. Calculate landing distance	PM+pf	“you’d want to use an in flight landing distance calculation, which is in the quick reference handbook QRH and that will help you determine how much landing distance you need … Based on one engine you know there’s obviously going to be an increase in landing distance because you have half the reverse capability and you might even have further failures … ” (P6)
Incident Containment	Action	System management	21. Prepare aircraft for landing	PM+pf	“on a single engine landing you normally be using less flap. So that you have got the capability in the event of a go around, you’re not as draggy, so you have got the performance. But other than that increases your landing distance … ” (P5)

Appendix C.

Dual engine failure table of processes

SAW subtype and incident phase classification and interview evidence in quotes for the dual engine bird-strike.

Table

Incident Phase	PCM Category	SAW Subtype	Process	Actors	Quote (participant number in brackets)
Pre-incident	World	Artifact	0. Emergency turn procedure briefing	PF+PM	There’s also things called emergency turn that are built in which are company specific and if you had to follow an emergency turn you would notify air traffic off that emergency turn” (P6)
Pre-incident	World	Artifact	0. Weather update on the ground	PF+PM	“You’re aware that at times of dawn and dusk then this higher bird traffic, sometimes at different airfields … you get a report at the end of the weather like high bird activity in the area … So you include it on your take-off briefing. (P5)
Onset of incident	World	Physical Cue	1. Bird-strike to engine	PF+PM	“you use sort of an assessment of the vibration or any smells … so smells would be obviously clue that something’s gone down the engine” (P2)
Onset of incident	Schema	Insufficient schema	2. Startle/surprise effect	PF+PM	“It’s a total surprise situation, it’s happened. Now and we gotta deal with it, and you’re very near the ground” (P4)
Onset of incident	Action	Aviate	3. Fly the aircraft Activate max power in engines to determine thrust	PF	“ … if you have power in one engine or the other, the first thing would be to try and handle the aircraft – asking for maximum power and seeing what you get. If one or both engines give you enough power for to keep on going you can limp for as much as you can.”(P1)
Immediate response	Action	System Monitoring	4. Monitor engine indicators	PM+pf	“Then I would look at the engine and I would think, oh, I might want to shut it down, but I’m not gonna do that because if I’m not on fire and it’s not and it’s not massively vibrating or doing too crazy stuff … I want to maintain that power and not lose any time on you know, shutting extra things down or giving it a chance to create a fire.” (P3)
Immediate response	World	Display indications	5. Evidence of bird-strike	PM+pf	“If you see that birds have gone down the sides, you suspect they hit both engines. If you could clearly see that one engine was OK and one had taken severe damage, then you possibly think about shutting down the damaged one. It is the fact you can’t guarantee that the other one isn’t damaged you’d be looking at those indications I already said about, the rotation and vibration.” (P5)
Immediate response	Schema	Analogical Schema	6. Assess information and generate expectations	PF+PM	“suppose you probably wouldn’t want to shut either of them down, but you would keep monitoring them very closely. And assuming you’ve got some indication … You know there’s higher vibration or or probably just higher vibration indicating some damage. ‘cause obviously if the rotation drops then then you got seized engine anyway.” (P5)
Immediate response	Action	Communicate	7. Captain takes over flying the aircraft	PF	“The captain would likely take over the flying, or maybe in the short term … but he would definitely make snappy decisions” (P2)
Immediate response	Action	Navigate	8. Action Emergency Turn procedure	PF	“So the first thing you do is turn back to the airport.” (P3)
Immediate response	Action	Communicate	9. Call ATC- May Day/Pan	PF	“The communication with air traffic control in the dual engine failure would probably be a lot briefer but happen a lot sooner in the process than it would with a single engine failure.” (P8)
Decision Making	Action	Concurrent Diagnosis	10. Determine the severity of the damage and required actions	PF+PM	“One of the decisions you have gotta make has the actual engine fallen off. Key evidence there for example, was that you got blank boxes in N1 and N2 were just went blank box instead of a low reading or a red reading that again that’s an interpretation. That is knowledge of ah, I know that engine is separated if there was blank boxes.” (P4)
Decision Making	World	Display indications	11. Information on engine failure severity	PM+pf	“It (ECAM) basically prioritizes failures in what it thinks is a serious order, and it would tell you if you had engine 1 + 2 failure” (P2)
Decision Making	Schema	Declarative Schema	12. Knowledge of what indicator determine about engine failure severity	PF+PM	“You know there’s higher vibration or or probably just higher vibration indicating some damage. ‘cause obviously if the rotation drops then then you got seized engine anyway. So you are a bit stuck.” (P5)
Decision Making	Schema	Trained past experience	13. Limited training for dual engine failure on take-off	PF+PM	“there is no certification for a 2 total power losses. You’re in the whole unknown world” (P4)
Subsequent Actions	Action	System management	14. (a) Run through checklist actions	PM+pf	“ … having had the engine failure, have we had to do any vital actions, and if so, which vital actions? Obviously if we had to do some of the memory drills from the vital actions, it’s probably quite a big problem actually” (P4) “we have an emergency checklist for dual engine failure. And that is actually on the back of our normal checklist so all our emergency checklist are on the QRH … ” (P3)
	World	Artifact	(b) Physical checklist (ECAM/QRH)	PM+pf
Incident Containment	Schema	Declarative Schema	15. Use any knowledge on local environment/airports for landing	PF+PM	“Really was are making very snappy decisions then yeah, so 2800 feet. Again, you’re kind of going to use your local knowledge.” (P2)
Incident Containment	Action	Decision Action	16. Decide to shut engine down and turn back (T-DODAR)	PF+PM	“in that situation you try and workout which one is giving you something power wise and go from there because shutting both of them down doesn’t really solve … well it solves one problem but creates worse problems really. You’re powerless at 2000 feet … Yeah, so as far as taking appropriate action goes, well obviously got no power then, then you’re forced into trying to return to where you just left with no engines which you may or may not make.” (P2)
Incident Containment	Action	System management	17. Land the aircraft in best possible location	PF+pm	“I just be asking to go to something like 10 mile final as soon as possible … You be considering lots of lots of things that you wouldn’t in the first situation.” (P5)
Incident Containment	World	Natural environment	18. Landing Space	PF+pm	“If you have a dual engine fire it is completely feasible that you’ll end up landing in a field so. And that’s just a case of looking outside and picking … A nice looking field.” (P2)

Appendix D.

Perceptual Cycle Model of the single-engine failure event

The perceptual cycle model follows the event around the model. The events are numbered in order. Events in gray are those identified as areas where assistance would be useful.

Appendix E.

Perceptual Cycle Model of the dual engine failure event

The perceptual cycle model follows the event around the model. The events are numbered in order. Events in gray are those identified as areas where assistance would be useful.