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

: 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.


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 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.

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:
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 crossdomain 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.

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.

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.

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.

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., takeoff, 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.

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.

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%).

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 shows an example of such information for a loss of separation incident in air traffic management. 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  The supervisor already warned the sector would be busy/complex, so having the trainee work in the sector was known to be challenging.
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 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.

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]. 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 crossdomain 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.

Cross-Domain HF Statistics
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.

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. 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.

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 Riskbased 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.

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).

Institutional Review Board Statement:
The study was conducted in accordance with the Declaration of Helsinki, following the procedures documented in report D1.4 "Social, Ethical, Legal, Privacy issues identification and monitoring (final)" (7/10/2022) of the SAFEMODE project. This includes the publication of (anonymised) survey results and statistics of human factors in safety occurrences.
Informed Consent Statement: Informed consent was obtained from all subjects involved in the study.
Data Availability Statement: Access to SHIELD can be attained via the SAFEMODE website https://safemodeproject.eu, 20 February 2023.

Conflicts of Interest:
The authors declare no conflict of interest.

Appendix A. SHIELD HF Taxonomy
The SHIELD HF taxonomy consists of four layers (Acts, Preconditions, Operational Leadership and Organisation), where each layer comprises several categories with a number of factors. A high-level description of the HF taxonomy is provided in Section 2.1 and illustrated in Figure 1. This appendix provides all details, including the codes, titles and definitions of all layers, categories and factors. Furthermore, it provides guidance and examples (in italics) on their use. Many examples are based on actual occurrences that were analysed and stored in SHIELD.

Appendix A.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 Table A1).


The chief engineer did not timely smell the overheated engine.

Making
The operator has no, late or an incorrect decision or plan to manage the perceived situation.

AD1
Incorrect decision or plan  It is apparent that at no stage did the officer of watch consider reducing speed.

AI Intentional Deviation
The operator decides to intentionally deviate from an agreed procedure or practice, including workarounds and sabotage.

AI1
Workaround in normal conditions The operator decides to intentionally deviate from an agreed procedure or practice in a normal operating condition.
If it is known that the workaround is used on a regular basis, AI2 "Routine workaround" should be used.


In this particular case the master did not post a lookout during the bridge watch.

Routine workaround
The operator habitually and intentionally deviates from an agreed procedure or practice on a regular basis.
This factor should only be used if it can be shown that the workaround is used on a regular basis; otherwise use AI1 "Workaround in normal conditions".

Response Execution
The operator has planned to take 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.

Timing error
The operator has planned to take an action that is appropriate for the perceived situation but executes it either too early or too late.
This considers timing errors in the response execution only.

Lack of physical coordination
The operator takes an action which is appropriate for the perceived situation, but executes it in a wrong manner, due to a lack of physical coordination.


The operator did not timely manage to move the heavy obstacle.

No action executed
The operator has planned to take an action that is appropriate for the perceived situation but does not execute it.
This lack of action should be distinguished from no actions due to problems in the category Planning And Decision Making, such as AD3 (No decision or plan). AR6 should be used if an operator had planned to act, but then did not, for instance because the operator forgot to do so (precondition: PME1).


The crew forgot to turn on the heating of the pitot probes before take-off.

AC Communicating
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.

AC1
Incorrect/unclear transmission of information The operator transmits to other actors information that is incorrect or unclear, e.g., use of wrong callsign.

Poor pilot readback of instructions.
 Second officer fails to specifically inform commanding officer about the overtaking situation.

No transmission of information
The operator does not transmit information that is necessary for other actors to operate safely/effectively.


The controller did not issue a low altitude alert.


The master did not leave night orders.

Appendix A.2. Preconditions
Preconditions describe 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 Table A2).  Landing gear not down alert was not correctly interpreted.


The pilot was reading the electronic bearing line for the course incorrectly, forgetting that the radar origin was off-centred rather than centred.

PAW Awareness
Lack of focussed and appropriate awareness functions lead to misinterpretation of the operation by an operator, such as channelized attention, confusion, distraction, inattention, being lost, prevalence of expectations, or using an unsuitable mental model.

PAW3 Distraction
Interruption and/or inappropriate redirection of operator's attention.


The pilot was distracted by the presence of his passenger.


The chief officer was distracted by the constant VHF radio conversations.

PAW4 Inattention
Operator is not alert/ready to process immediately available information.  The master relaxed his vigilance when the pilot was on board.

PAW5 Geographically lost
The operator perceives to be at a different location compared to the one where s/he actually is.


Pilot was attempting to land on a road he perceived to be the runway. It was raining, cloud base was low, and it was dark.

PAW6 Unsuitable mental model
Operator uses an unsuitable mental model to integrate information and arrives at a wrong understanding of the situation (e.g., wrong understanding of automation behaviour).

PME Memory
Memory issues leading to forgetting, inaccurate recall, or using expired information.

PME1 Forget actions/intentions
The operator has a temporary memory lapse and forgets planned actions or intentions.

Appendix A.3. Operational Leadership
The Operational Leadership layer in the taxonomy concerns decisions or policies of the operations leader that affect the practices, conditions or individual actions of operators, contributing to unsafe situations. It consists of three categories including 15 factors (see Table A3). Appendix A. 4

. Organisation
The Organisation layer concerns decisions, policies or methods adopted at an organisational level that may affect both the supervisory and individual operator performance. It consists of four categories including 17 factors (see Table A4).  Poor teamwork, exacerbated by cultural differences, was a significant factor in the accident.

Management
Safety management in the organisation is insufficient, including lack of organisation structure for safety management, and limitations of proactive risk management, reactive safety assurance, safety promotion and training, and of suitable procedures. within which they are expected to be applied (work as imagined versus work as done).

OR Resources
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.

OR1 Personnel
The organisation provides insufficient personnel who are suitably qualified and experienced to perform the tasks safely.


The availability of tidal stream date for the port was insufficient to plan the safe passage of the vessel using the ports narrow approach channel.

Business
The economy and business of the organisation pose constraints that affect safety, including relations with contractors, strong competition, pressure to keep schedules and costs, and required tempo of operations.

OE1 Contractors
Relationships, communications, or interoperability between the organisation and contractors are not optimal and this creates an unsafe working relationship.