SHIELD Human Factors Taxonomy and Database for Learning from Aviation and Maritime Safety Occurrences

Abstract

Human factors (HF) in aviation and maritime safety occurrences are not always systematically analysed and reported in a way that makes the extraction of trends and comparisons possible in support of effective safety management and feedback for design. As a way forward, a taxonomy and data repository were designed for the systematic collection and assessment of human factors in aviation and maritime incidents and accidents, called SHIELD (Safety Human Incident and Error Learning Database). The HF taxonomy uses four layers: The top layer addresses the sharp end where acts of human operators contribute to a safety occurrence; the next layer concerns preconditions that affect human performance; the third layer describes decisions or policies of operations leaders that affect the practices or conditions of operations; and the bottom layer concerns influences from decisions, policies or methods adopted at an organisational level. The paper presents the full details, guidance and examples for the effective use of the HF taxonomy. The taxonomy has been effectively used by maritime and aviation stakeholders, as follows from questionnaire evaluation scores and feedback. It was found to offer an intuitive and well-documented framework to classify HF in safety occurrences.

1. Introduction

Human operators play crucial roles in the safe, resilient and efficient conduct of maritime and air transport operations. Consequently, human factors (HF) are often reported as contributors to maritime and aviation incidents and accidents [1]. The importance of supporting the human actors and reducing the potential of human contributions to incidents/accidents by addressing human factors in the design and conduct of transport operations is recognised as being fundamental by researchers, regulators and the transport industry. However, there is a scarcity of suitable HF data derived from the investigation of safety occurrences in support of effective safety management and feedback for design. Details about human contributors are often not systematically analysed or reported in a way that makes the extraction of trends and comparisons possible.

In the maritime sector, guidance and structure to investigate marine accidents and incidents are provided through international organisations such as the International Maritime Organization (IMO) and the European Maritime Safety Agency (EMSA). Various databases and analysis techniques are in use for maritime occurrences, including the European Marine Casualty Information Platform (EMCIP) by EMSA [2], the Confidential Human Factors Incident Reporting Programme (CHIRP) for maritime [3], Nearmiss.dk [4], ForeSea [5], and commercial (non-public) tools. However, there is a lack of sufficiently detailed public guidance and standards for structuring HF-based investigations, and this complicates learning from occurrences. This is consistent with a comparative assessment of the Human Performance Capability Profile (HPCP) of maritime and aviation organisations, where it was found that the maturity levels for maritime were less than for the aviation domain [6].

Considering HF in safety is complex and multi-layered in nature. Similar to Heinrich’s safety iceberg [7], this may be envisioned as an HF iceberg since (i) what typically can be seen in incident reports is the tip and there is usually much more underneath, and (ii) to prevent the recurrence of a type of incident, one needs to take care with what is under the waterline, and not only focus on what is above:

• At the top of the iceberg, it may be relatively easy to see what happened in an occurrence: Who did what and what happened is usually known or at least strongly suspected. The analysis focus at this level is observable performance. The reasons why it happened are not uncovered, such that there is no change in the design or operation. Somebody (if they survived) can be blamed and re-trained, until the next occurrence. The issue is seen as dealt with, but safety learning has failed.
• The second layer considers a range of factors affecting human performance, including HF concepts such as workload, situation awareness, stress and fatigue, human system interfaces, and teamwork. Investigating incidents at this level can lead to more effective prevention strategies and countermeasures, addressing systemic and structural aspects, e.g., job design and interface design.
• The third layer considers how the operations were locally organised and led by operations leaders. There are internal and external targets placing demands on the operators. These may result in workarounds, which can support the efficiency and productivity of the work, which can sometimes also allow risks to emerge. The challenge is determining how jobs and tasks are actually performed in this context. Learning considers the local organisation of the work and leadership strategies in operations.
• The fourth and final layer considers the culture (professional, organisational, national) and socioeconomics (demands, competition) of each sector, which affect individuals, organisations and industries. The analysis focus at this layer is on norms, values and ways of seeing the world and doing things. Such understanding is key to ensuring that derived safety solutions and countermeasures are sustainable for the staff and operating conditions.

A layered structure as in the HF iceberg is well known from the Swiss Cheese Model (SCM) of James Reason [8,9], which is a conceptual model describing multiple contributors at various levels in safety occurrences, as well as the from the SCM-derived and more specific Human Factors Analysis and Classification System (HFACS) [10]. These types of models set a basis for development in this study of a more detailed data repository for gathering and assessing human factors in safety occurrences in aviation and maritime operations, which is called SHIELD: Safety Human Incident and Error Learning Database. The objective is to support designers of systems and operations, risk assessors and managers in easily retrieving and analysing sets of safety occurrences for selected human performance influencing factors, safety events and contextual conditions. This allows learning from narratives of reported occurrences to identify key contributory factors, determine statistics and set a basis for including human elements in quantitative risk models of maritime and aviation operations. Effective learning requires a proper just culture, where people are not blamed for honest mistakes, and a healthy reporting culture, where incidents are reported as a way to improve safety [11].

The objectives of this paper are to present the development of SHIELD and its HF taxonomy, as well as its evaluation and feedback from users. In particular, this paper presents in full detail the HF taxonomy, including guidance and examples for its use. A more concise conference paper on SHIELD development was presented in [12]. Section 2 presents the HF and other taxonomies of SHIELD and the methods for data collection and evaluation by stakeholders. Section 3 presents illustrative cross-domain HF statistics and the results of evaluation by stakeholders. Section 4 provides a discussion of the developments and results. The details of the HF taxonomy, guidance and examples for all its factors are provided in Appendix A.

2. Materials and Methods

2.1. Human Factors Taxonomy

The design of the SHIELD HF taxonomy began via a review of sixteen different taxonomies [13,14] that were developed for safety occurrences in various domains:

• Aviation, including ADREP/ECCAIRS (Accident/Incident Data Reporting by European Co-ordination Centre for Aviation Incident Reporting System) [15], HERA (Human Error in Air Traffic Management) [16] and RAT (Risk Analysis Tool) [17].
• Maritime, including EMCIP (European Marine Casualty Information Platform) [18] and CASMET (Casualty Analysis Methodology for Maritime Operations) [19].
• Railway, including HEIST (Human Error Investigation Software Tool) [20].
• Nuclear, including SACADA (Scenario Authoring, Characterization, and Debriefing Application) [21].
• Space, including NASA-HFACS (a detailed version of HFACS developed by NASA for analysis of occurrences in space operations) [22].

Following a gap analysis [13,14], the two dominant approaches arising from this review were HERA and NASA-HFACS. HERA applies a detailed cognitive approach for the analysis of acts at the sharp end, while NASA-HFACS uses a layered approach up to the level of organisational factors with an enhanced level of detail in comparison with the original HFACS [10]. Building on these two approaches, a number of factors influencing human performance were adapted and made domain-generic for the purpose of cross-domain analysis of occurrences. Various aviation and maritime stakeholders applied the taxonomy and provided feedback, leading to refinements in the definitions of the factors and guidance for their application.

The final SHIELD HF taxonomy consists of four layers, where each layer comprises several categories with a number of factors (Figure 1). The layers are Acts, describing what happened and did not go according to plan; Preconditions, providing factors that influenced the performance during operation; Operational Leadership, describing policies of operational leadership that may affect the working arrangement; and Organisation, describing influences of the organisation and external business environment on the operations. The elements of these layers are summarized next. The complete HF taxonomy with guidance and examples is provided in Appendix A.

2.1.1. Acts

The Acts layer describes actions, omissions or intentional deviations from agreed procedures or practices by an operator with an impact on the safety of operations. It consists of five categories including 19 factors (see details in Appendix A.1):

• Perception (4 factors): The operator does not perceive, or perceives too late or inaccurately, information necessary to formulate a proper action plan or make a correct decision. The factors distinguish between the sensory modalities (visual, auditory, kinaesthetic, and other).
• Planning and Decision Making (3 factors): The operator has no, late or an incorrect decision or plan to manage the perceived situation. This includes issues with the interpretation/integration of information streams, but it excludes intentional deviations from procedures.
• Intentional Deviation (4 factors): The operator decides to intentionally deviate from an agreed procedure or practice, including routine and specific workarounds, and sabotage.
• Response Execution (6 factors): The operator has planned to perform an action that is appropriate for the perceived situation, but executes it in a wrong manner, at an inappropriate time or does not execute it at all. It includes slips and lapses, such as switching actions in sequences, pushing a wrong button and a lack of physical coordination. It excludes communication acts.
• Communicating (2 factors): The operator has planned to take an action that is appropriate for the perceived situation but communicates incorrect or unclear information to other actors or does not communicate at all.

The Acts layer represents a sense—decide–act loop (Figure 2). Sensing issues are represented by the category Perception. It should only be used if there is evidence that information was not well perceived by an operator. Problems with the interpretation/integration of one or more information streams are part of the category Planning and Decision Making. Issues with decision-making on the basis of correctly sensed information are represented in the categories Planning and Decision Making, and Intentional Deviation, where the latter category is strictly used if the operator intentionally deviated from a procedure. Issues with acting on the basis of a correct decision/plan (slips, lapses) are represented in the categories Response Execution and Communicating, where the latter focusses on communications acts.

2.1.2. Preconditions

The Preconditions layer describes environmental factors or conditions of individual operators affecting human performance and contributing to the issues described in the Acts layer. It consists of 12 categories including 62 factors (see details in Appendix A.2):

• Physical Environment (9 factors): Conditions in the physical environment such as visibility, noise, vibration, heat, cold, acceleration and bad weather.
• Equipment and Workplace (6 factors): Conditions in the technological environment related to ergonomics, the human–machine interface (HMI), automation, working position and equipment functioning.
• Interpersonal Communication (4 factors): Conditions affecting communication in operations, such as language differences, non-standard or complex communication and the impact of differences in rank.
• Team/Group (6 factors): Conditions in the functioning of a team/group, such as working towards different goals, no cross-checking, no speaking up, no adaptation in demanding situations and groupthink.
• Misperception (4 factors): Misperception conditions leading to misinterpretation, such as motion illusion, visual illusion and the misperception of changing environments or instruments. They provide background for the reason that an operator did not aptly perceive.
• Awareness (7 factors): Lack of focused and appropriate awareness functions leading to misinterpretation of the operation by an operator, such as channelized attention, confusion, distraction, inattention, being ‘lost’, the prevalence of expectations or using an unsuitable mental model.
• Memory (3 factors): Memory issues leading to forgetting, inaccurate recall or using expired information.
• Mental Workload (4 factors): The amount or intensity of effort or information processing in a task degrades the operator’s performance, including low and high workload, information processing overload and the startle effect.
• Personal Factors (7 factors): Personal factors such as emotional state, personality style, motivation, performance pressure, psychological condition, confidence level and complacency.
• Physiological Condition (5 factors): Physiological/physical conditions such as injury, illness, fatigue, burnout, hypoxia and decompression sickness.
• Drugs and Nutrition (3 factors): Use of drugs, alcohol, medication or insufficient nutrition affecting operator performance.
• Competence, Skills and Capability (4 factors): Experience, proficiency, training, strength or biomechanical capabilities are insufficient to perform a task well.

2.1.3. Operational Leadership

The Operational Leadership layer describes the decisions or policies of an operations leader (e.g., a captain in a cockpit or ship, or air traffic control supervisor) that affect the practices, conditions or individual actions of operators, contributing to unsafe situations. It consists of three categories including 15 factors (see details in Appendix A.3):

• Personnel Leadership (4 factors): Inadequate leadership and personnel management, including no personnel measures against regular risky behaviour, a lack of feedback on safety reporting, no role model and personality conflicts.
• Operations Planning (6 factors): Issues in the operations planning, including inadequate risk assessment, inadequate team composition, inappropriate pressure to perform a task and a directed task with inadequate qualification, experience or equipment.
• Task Leadership (5 factors): Inadequate leadership of operational tasks, including a lack of correction of unsafe practices, no enforcement of existing rules, allowing unwritten policies to become standards and directed deviations from procedures.

2.1.4. Organisation

The Organisation layer describes decisions, policies or methods adopted at an organisational level that affect the operational leadership and/or individual operator performance. It consists of four categories including 17 factors (see details in Appendix A.4):

• Culture (2 factors): Safety culture problems or sociocultural barriers causing misunderstandings.
• Safety Management (5 factors): Safety management in the organisation is insufficient, including a lack of organisational structure for safety management and limitations of proactive risk management, reactive safety assurance, safety promotion and training and suitable documented procedures.
• Resources (6 factors): The organisation does not provide sufficient resources for safe operations, including personnel, budgets, equipment, training programs, operational information and support for suitable design of equipment and procedures.
• Economy and Business (4 factors): The economy and business of the organisation pose constraints that affect safety, including relations with contractors, strong competition, economic pressure to keep schedules and costs and the required tempo of operations.

2.2. Other Taxonomies in SHIELD

In addition to the HF taxonomy, SHIELD gathers other occurrence data, such as the involved actors, vehicles and additional context. All these elements enable the designer or risk assessor/manager to relate aspects of the operation and the occurrence with particular human factors. These other taxonomies are often domain-specific, using accustomed terminology from the aviation and maritime domains [23]:

• Occurrence overview: This provides general data on the occurrence, such as headline, date and time, location, number of fatalities and injuries, damage and a narrative of the occurrence.
• Occurrence type: The type of occurrence is described by domain-specific occurrence classes (e.g., accident, serious incident, very serious marine casualty, marine incident) and occurrence categories (e.g., runway incursion, controlled flight into terrain, collision in open sea, capsizing).
• Context: This gathers a range of contextual conditions, such as precipitation, visibility, wind, wake turbulence, light, terrain, sea and tidal conditions, runway conditions and traffic density. This is performed via structured lists, numbers or free texts.
• Vehicle and operation: Information on vehicles involved in a safety occurrence is gathered, such as an operation number, vehicle type (e.g., helicopter, container ship, fishing vessel) and year of build. The operation is specified by operation type (e.g., commercial air transport, recreative maritime operation), operation phase (e.g., take-off, berthing) and level of operation (e.g., normal, training, emergency).
• Actor: The backgrounds of actors involved in a safety occurrence are gathered, describing high-level groups of actor functions (e.g., flight crew, port authority), actor roles (e.g., tower controller, technician, chief officer), activity, qualification, experience, time on shift, age and nationality.
• Prevention, mitigation and learning: The collection of actions by human operators and/or technical systems that prevented the situation from developing into an accident, or that limited the consequences of an accident, is supported by free text fields. Moreover, lessons that have previously been identified following a safety occurrence, e.g., changes in designs, procedures or organisation, can be gathered. These data support the evaluation of the resilience due to operator performance and support safety learning in and between organisations.

2.3. SHIELD Backend and Frontend

The backend of SHIELD uses the modern document-oriented database technology of MongoDB. In document-oriented databases, the data are stored as collections of documents, which are readable and easy to understand. In this way, SHIELD uses a flexible schema, which can be simply changed/maintained and allow quick searches.

A user can access SHIELD via an HMI in the online HURID platform [24]. This is a collection of online tools of the SAFEMODE Human Risk Informed Design Framework (HURID). The SHIELD HMI includes the following features:

• Dashboard: Overview of statistics on HF and occurrence categories (see Figure 3).
• Search: Facility to search for occurrences with particular values.
• My reports: Overview and editing of reports created by a user.
• Create new report: Allows the user to store occurrences according to the taxonomy.
• User guidance: Documentation on the functionalities and taxonomy.

2.4. Data Collection

Partners in the SAFEMODE project collected incident and accident reports in the aviation and maritime domains [25]. Original incident and accident reports with full factual and narrative descriptions were used, rather than pre-processed analyses that employed other taxonomies, so as to avoid biases and lack of detail of the occurrences. Incident reports provide concise narratives by involved operators and may include technical data (such as flight trajectories). Accident reports provide detailed descriptions, technical data and analyses by investigators of events and conditions that contributed to the accident.

Aviation data sources used include the public Aviation Safety Reporting System (ASRS), which provides a range of US voluntary and confidentially reported incidents, deidentified non-public incident reports of European air navigation service providers and airlines and a number of public accident reports. A total of 176 aviation occurrences were analysed, consisting of 167 incidents and 9 accidents. They occurred worldwide in the period 2009 to 2021, predominantly in 2018 and 2019. Prominent types of analysed aviation occurrences are controlled flight into terrain (29%), runway incursion (17%), and in-flight turbulence encounters (30%).

The maritime data sources used in the analyses stem from public reports provided by various organisations, such as the Marine Accident Investigation Branch (MAIB) in the UK, The Bahamas Maritime Authority, the Malta Marine Safety Investigation Unit and the Australian Transport Safety Bureau (ATSB) amongst others. A total of 256 occurrences were analysed, including 246 marine accidents. They occurred worldwide in the period of 1992 to 2021. Prominent types of analysed maritime occurrences concern collisions in congested waters (19%), narrow waters (20%) and open sea (11%), as well as groundings in coastal/shallow water (36%) and when approaching berth (13%).

2.5. Data Analysis Process

The analysis of an occurrence for inclusion in SHIELD starts with studying the associated incident or accident report and extracting the factual information about the involved vehicles, operations, actors, contextual factors, narrative, etc., using the taxonomies explained in Section 2.2. This task can be completed using domain knowledge.

Table 1. Example of an aviation occurrence with main elements of the SHIELD taxonomy (see associated human factors in Table 2).

Vehicles & Operation	Aircraft A: Airbus A320neo passenger flight Aircraft B: Boeing E3 Sentry airborne warning and control system (AWACS)
Actors	Air traffic controllers: Trainee, Instructor, Supervisor Cockpit crews of aircraft A and B
Contextual factors	High traffic density
Occurrence type	Incident: Air Traffic Management; Loss of separation
Narrative	Supervisor had warned the sector that it was going to be busy and complex, but they decided it would be good for the trainee. Aircraft B was flying a ‘racetrack’ (elongated ellipse) pattern, highlighted on the trainee’s radar picture but not the coach’s. Required separation against such aircraft is 10 nautical mile (as opposed to the normal 5 nautical mile). The trainee turned aircraft A left and descended it, to maintain separation against a third aircraft, but failed to consider aircraft B that was about to turn. Radio communication was then busy with other traffic and separation was lost. The trainee conferred with the coach and then expedited descent of aircraft A until separation was restored.
Safety learning	Investigation recommended additional visual prompts for such conflict situations.

shows an example of such information for a loss of separation incident in air traffic management.

Next, an analysis is performed to identify the human factors according to the SHIELD HF taxonomy as explained in Section 2.1 and Appendix A. It means identifying appropriate factors in each of the taxonomy layers for the actors in the occurrence, using the detailed guidance material.

Table 2. Identified human factors in the example occurrence of Table 1.

Layer	Category	Factor	Actor	Reasoning
Acts	Perception	AP1: No/wrong/late visual detection	Trainee	Trainee did not detect/accurately predict racetrack turn of aircraft A
Acts	Perception	AP1: No/wrong/late visual detection	Instructor	Instructor did not detect impending loss of separation
Preconditions	Awareness	PAW1: Channelized attention	Trainee	Focused attention of trainee due to high complexity and workload
Preconditions	Awareness	PAW3: Distraction	Trainee	Trainee was busy with other calls
Preconditions	Personal factors	PPF3: Confidence level	Instructor	Instructor decided to not put racetrack on own radar screen, but relied on watching it on the trainee’s radar screen
Preconditions	Competence, skills and capability	PCS1: Inadequate experience	Trainee	Operation was handled by a trainee
Operational Leadership	Operations planning	LO5: Directed task with limited experience	Instructor	The supervisor already warned the sector would be busy/complex, so having the trainee work in the sector was known to be challenging.

shows as an example the identified human factors in the aviation incident of Table 1. Importantly, the reasoning for the choice of the human factors is included for traceability and to support learning. This analysis requires both domain and human factors expertise and is supported by the detailed definitions and examples listed in Appendix A.

Sets of occurrences were divided between partners of the SAFEMODE project, who had the appropriate domain and HF expertise and a learning culture mindset [25]. The HF analyses were performed by teams or by individual assessors in combination with reviews. Next, the prime analyses were reviewed by another project partner and discussed upon agreement on the suitable factors. The analysis of accidents takes longer and typically provides more human factors than incidents, given the more detailed knowledge of a larger number of events and conditions that typically contribute to an accident.

2.6. Evaluation by Stakeholders

The evaluation of SHIELD was performed using a questionnaire asking respondents to score statements on a Likert scale from 1 (Strongly Disagree) to 5 (Strongly Agree), and for open commenting. Questions concerned the dashboard, search functionality, report creation, own reports, user guidance and types of applications. The questionnaire was distributed to 15 maritime and 8 aviation stakeholders, including operators, manufacturers, safety agencies and researchers; 18 completed questionnaires were received (78% response rate). Furthermore, SHIELD was evaluated in a maritime case study [26].

3. Results

3.1. Cross-Domain HF Statistics

Figure 4 provides an overview of the relative frequencies of the HF categories per layer for the maritime and aviation occurrences amongst the four layers of the taxonomy. These results are based on 176 aviation occurrences and 256 maritime occurrences, which were analysed during the project. They illustrate the possibility of SHIELD for cross-domain analysis.

Figure 4 shows that for both transport domains, the most frequently occurring issues at the Acts level concern planning and decision-making, e.g., a pilot deciding to descend too early in mountainous terrain, and communicating, e.g., an air traffic controller not warning for low altitude.

In the Preconditions layer, many factors are used. The largest category in both the aviation and maritime domains is awareness, with main factors including channelized attention, confusion and distraction, e.g., a chief officer being distracted by constant VHF radio conversations. The category competence, skills and capability is considerably more prominent in maritime occurrences, which is indicative of a higher contribution of inadequate experience, training and a lack of proficiency on ships. In aviation, the category team/group occurs relatively often. In particular, no cross-checking and speaking up by team members, regarding crew resource management problems in the cockpit, is prominent.

In the Operational Leadership layer, factors that are frequently used are inadequate risk assessment (e.g., a captain who opted to fly through a bad weather zone, although other aircraft diverted), inadequate leadership or supervision (e.g., an ATC supervisor who allowed a large exceedance of the capacity of an airspace sector) and no enforcement of existing rules (e.g., masters not enforcing speed limitations of ships).

At the Organisation layer, it can be observed in Figure 4 that the categories of safety management and resources are the most prominent. A lack of guidance, e.g., how to operate in restricted visibility, and limitations of risk assessments, e.g., underestimation of the impact of an automatic flight control system, are important factors in Safety Management. Equipment not being available, e.g., the decision not to install an angle of attack indicator, is most prominent in the resources category.

3.2. Evaluation by Stakeholders

Basic statistics composed of the mean and standard deviation (SD) of the evaluation scores of the completed questionnaires (n = 18) are provided in

Table 3. Evaluation scores of aviation and maritime stakeholders.

Topic	Statement	Score (1–5)
		Mean	SD
Dashboard	1. The Dashboard on the HMI of SHIELD provides relevant and easy-to-understand information	3.9	0.9
	2. I would like to see more or different information on SHIELD’s Dashboard	3.5	1.0
Search	3. The HMI provide an easy-to-use search engine/filtering method to select occurrence reports from the database	3.8	0.7
My Reports	4. The HMI provides a clear, well ordered and easy-to-use overview of the reports that I have entered into SHIELD	4.2	0.7
	5. It is easy to modify (edit, delete) a report from the presented list of My Reports	3.8	1.1
Create New Report	6. The HMI provides an easy-to-use interface to create new occurrence reports	4.2	0.4
	7. The generic part of the SHIELD taxonomy is sufficiently complete to describe a safety occurrence	4.2	0.6
	8. The Human Factors Classification part of the SHIELD taxonomy is sufficiently complete to describe relevant human factors contributing to a safety occurrence	3.9	0.7
User Guidance	9. The SHIELD HMI provides clear and sufficient user guidance on functionalities like searching and creating reports and on using the taxonomy	3.4	1.0

. Most mean scores are close to 4, indicating that the respondents agree that the dashboard, search functionality and report creation and maintenance are useful for their purposes. Several suggestions were received for the extension of the dashboard and user guidance [23]. Users expressed that they expected that the database can be useful for various purposes in their organisations, including informing management, supporting safety promotion, improving training, improving operational procedures and supporting risk assessment and mitigation and safety assurance.

3.3. Early Application of SHIELD in the Maritime Domain

The European Maritime Safety Agency (EMSA) has developed a methodology to analyse the findings of the safety investigations reported in the European Marine Casualty Information Platform (EMCIP) [2] to detect potential safety issues. EMSA has recently published a safety analysis on navigation accidents based on EMCIP data concerning passenger, cargo and service ships [27]. The document considered a large number of safety investigations reported in the system (351) and identified nine safety issues: Work/operation methods carried out onboard the vessels; organisational factors; risk assessment; internal and external environment; individual factors; tools and hardware; competences and skills; emergency response and operation planning. The SHIELD taxonomy was used as a tool supporting the classification of contributing factors, thus supporting the subsequent analysis. The taxonomy was found to offer an intuitive and well-documented framework to classify human element data.

The Confidential Human Factors Incident Reporting Programme (CHIRP) for the maritime domain is an independent, confidential incident and near-miss reporting programme devoted to improving safety at sea [3]. CHIRP Maritime has recently begun using the SHIELD HF taxonomy in support of its analysis. CHIRP Maritime appreciates the systematic evaluation of human factors down to the levels of operational leadership and organisational aspects. This extra depth of analysis grants them more confidence in their findings due to the increased granularity and depth of the taxonomy.

In a maritime case study entitled “Implementation of a Human Factors and Risk-based Investigation suite for Maritime End Users (Organizational Level)” by CalMac Ferries Limited, three incidents were investigated [26]. It was found that SHIELD provides a consistent taxonomy for systematically identifying active and latent failures, which can be applied using existing competencies of maritime end users, without requiring additional training. The analysis identified additional factors with respect to a previous in-house HFACS-based analysis of the incidents by CalMac. In particular, in total, 54 factors were found using SHIELD, which more than doubled the 23 factors found in the earlier in-house analysis.

4. Discussion

The SHIELD taxonomy and database have been developed for the gathering and systematic assessment of human factors in safety occurrences in aviation and maritime operations. The objective is to support designers of systems and operations, risk assessors and managers in easily retrieving and analysing sets of safety occurrences for selected human performance influencing factors, safety events and contextual conditions. This allows learning from narratives of reported occurrences to identify key contributory factors and associated risk reduction measures, determine statistics and set a basis for including human elements in risk models of maritime and aviation operations.

It follows from the largely positive feedback in the questionnaire results, as well as from the appreciation expressed by EMSA, CHIRP Maritime and CalMac, that the developed SHIELD taxonomy and database have been recognized as valuable assets for systematic analysis of human factors in safety occurrences and learning from incidents and accidents as part of safety management. The uptake of SHIELD in the maritime domain is especially prominent. This may be explained by the maritime domain’s relative disadvantage in Human Performance Capability Profile (HPCP) with respect to the aviation domain. This may have caused a larger appetite within the maritime domain for the uptake of SHIELD by key stakeholders, as the aviation domain already has a number of ‘legacy’ taxonomies in use.

The most interesting finding for some of the aviation companies who tried SHIELD was the emergence of insights arising from analysing a set of accidents or incidents, i.e., learning across events. For example, analysing 30 similar incidents relating to runway incidents revealed similar problems at different airports, with problems in the tempo of operations, equipment availability, and safety risk management as prominent factors at the organisational level. Taken one by one, or even for a single airport, the contributory factors of the events looked no more important than a host of other contenders for safety attention. However, when looking across half a dozen airports, certain underlying problems rose to the surface in clarity and priority.

Similarly, during the analysis of a set of loss of separation incidents from a particular air traffic control centre, it was noticed by the two analysts that ‘Tempo of operations’ came up a number of times in the Organisation layer of the SHIELD taxonomy (underpinning ‘High workload’ in the Preconditions layer), along with several Operational Leadership categories. This raised a question in the minds of the analysts as to whether the traffic load was too high in this unit, such that there was insufficient margin when things did not go to plan, resulting in a loss of separation. This could represent a ‘drift towards danger’ scenario, where the rate of incidents is slowly increasing but goes unnoticed, as the air traffic control centre adapts to each incident individually. Since the incidents differed at the Acts layer and had other attendant preconditions, again this issue might have been missed except by looking deeply across a set of incidents.

From the maritime perspective, SHIELD not only captured all the major factors included in the original accident reports successfully but it also identified additional contributing factors that were not previously highlighted. In particular, SHIELD was able to systematically capture organisational and operational leadership issues that were not well identified in the original accident reports. For instance, one of the maritime accidents analysed was the collision between the Hampoel and Atlantic Mermaid vessels, where the main cause of the collision was the Atlantic Mermaid failing to observe the presence of Hampoel, which also failed to take avoiding action [28]. Additional contributing factors included in the accident report were related to technological environment factors, inadequate resources, weather conditions and adverse physiological conditions, amongst others. All the above-mentioned factors were also successfully captured via the application of SHIELD. In addition, SHIELD supported identifying details such as an intermittent fault of one radar for at least 12 months before the collision, a chief officer making an unanswered brief VHF call and a chief officer not following COLREG regulations and not using light and sound signals. Therefore, various organisational aspects were captured as contributing factors in this accident.

The above examples demonstrate the utility of applying a taxonomy that has depth, particularly when analysing across incident sets, looking for patterns that are otherwise not immediately obvious. This kind of learning across incidents is one of the main advantages of a database and layered taxonomy such as SHIELD.

Learning from occurrence retrieval in SHIELD can be pursued in various ways. One can search for particular types of operations and find the types of related incidents and accidents, the prominent contributing factors in the four layers of the HF taxonomy, and the prevention, mitigation and learning for the occurrences. One can obtain an overview of the human factors that contribute most to particular types of occurrences. By looking at the details of these factors and the reasoning provided in the classification, a safety analyst or an investigator can build an understanding of what may go wrong in what kinds of conditions and what kinds of operational leadership or organisational aspects may contribute. A company can track what factors affecting human performance are most prominent in incidents occurring in its operations and compare this with average numbers in the industry. As sectors, the maritime and aviation domains can compare statistics and use them for cross-domain learning of best practices. An illustrative cross-domain comparison in Section 3.1 showed several differences between the sectors, such as a higher contribution of inadequate experience, training and proficiency in the maritime domain.

For strengthening the use of SHIELD, the following further steps are advised: To include larger sets of analysed occurrences, both incidents and accidents, in order to support attaining statistically meaningful results; to apply regular validation for its use in safety management and feedback to design (can the right information be extracted or are other data features needed?); to develop and include a taxonomy for prevention, mitigation and learning, such that it will be easier for users to find and develop statistics for the types of actions that effectively prevented safety occurrences becoming worse.

The SHIELD HF taxonomy found its basis in earlier taxonomies stemming from multiple domains, namely space and aviation/ATM operations [10,16,22], and was next developed to suit aviation/ATM and maritime operations. A key contribution of this research has been the structuring of all categories and factors, their explicit definitions, and the guidance and examples for their use. This has been recognized as a clear asset, supporting its use with little training. Given the multi-domain support of the HF taxonomy, we expect that it can be used with minor adaptations in other domains. The use of the overall SHIELD taxonomy in other domains would require extensions of its domain-specific taxonomies though (e.g., type of operation, actor).