Investment in the development of computerised tools, enhanced communication systems and improved satellite technology represents an attempt to ensure that the UK ATM infrastructure can safely deliver the required capacity improvements. The ATM system is therefore currently undergoing a period of major change, including changes to the organisation and operation of airspace, systems on board aircraft and ground-based systems used to control and advise aircraft. The vision of the future is that controllers will take on the role of airspace managers. This indicates that there will be a change in the role of the controller as computer assistance is introduced, including information displays for decision support, conflict information and tools to assist aircraft sequencing and spacing. These new possibilities clearly need to be managed to ensure that acceptable safety and usability are achieved.

The learning by experience route is less viable for the development of the new ATM system. The system is highly complex and coupled and, as the system is responsible for hundreds of aircraft, any systematic failure could endanger a greater number of people than localised failure of an aircraft. It is not possible to switch off the ATM system in the way that an aircraft can be grounded. This problem places a greater burden on the identification of risks involved in the transition to “new” ATM systems during design and development, rather than operation, of the system. Whilst it is important to take stock of what has been learned from incidents and previous findings regarding human error in ATM, it is also necessary to determine whether the pattern of potential controller errors will change, and if so how they will change.

“any action or inaction that actually or potentially leads to negative system consequences, where more than one possible action is available”.

This definition emphasises action and omission, and includes failures of perception and attention, memory, decision-making, and response execution. The issue of definition may seem more important to regulatory authorities than human factors specialists (for human factors specialists the concept of blame carries little significance). However, the definition of human error has a profound effect on the identification and classification of error.

In reality, controller error tends to be multi-causal. Error can be a function of the selection, training and experience of the controller. However, and more importantly for this paper, the quality of the equipment provided and environment in which the controller works has a major impact on the likelihood of human error in operation. It is often difficult to separate “human”, “system” and “design” errors, especially errors associated with Human-Machine Interaction (HMI). A controller may give incorrect information to an aircraft, but if the source information provided from the HMI is vague or ambiguous, then one may question whether it is appropriate to call this a human error. (The more sophisticated error classification systems do, however, capture the human, equipment, procedural and environmental factors.) Still, in the UK it is currently difficult to identify a significant proportion of Aircraft Proximity (AIRPROX) incidents that are attributable to flaws in ATM equipment. This statement is reinforced by official investigations of UK incidents involving ATM. Furthermore, the current HMIs used in ATM are simple and “direct”. The main components of the HMI have remained basically unchanged for many years, and include the following:

The paper therefore considers approaches that may help to:

In theory, it is possible to apply human error prediction and assessment methods at any stage of the SDDLC. However, there are inevitable trade-offs between the accuracy and validity of predictions and measurements on the one hand, and opportunity for design change or system modification on the other hand, as the system progresses through the SDDLC. In practice, the preliminary design stage is the earliest application stage. This is because in order to specify what can go wrong (human error), it is necessary to have a normative template of what should go right, in terms of the functions that need to be achieved, and the actions expected of the human. Such information is usually not available until at least the preliminary design phase.

Nevertheless, even at the preliminary design stage of the SDDLC, only general predictions regarding human error will be possible, and general HF and ATM expertise should achieve this end. At this stage, the major predictable error forms regarding the human functions and the human’s ability to compensate for system function failure will be identifiable. Some of these error forms will be apparent to the designers. However, predictions of error possibilities by HF analysts and operational personnel can lead to significant increases in the robustness of the system design and the human’s role within that system design architecture.

Early prototyping and user testing will often be seen as the most fruitful stage at which to apply HEA methods. This stage will provide richer information on which to assess human error potential, and will provide more opportunities to make cost-effective design changes. For the first time, human functions and behaviours are not merely seen in abstract form, but in the context of a working prototype system. Next, the detail of the interface, the human role specification, and the system outputs and response times all come together to produce realistic human and system behaviour, and the associated system disturbances and fluctuations, and human errors that will also follow. At this stage, unanticipated errors will be found. Importantly, at this stage of detailed design, prototyping and evaluation, design changes will still be feasible, albeit with more prioritisation of error reduction measures due to design change cost constraints.

After this stage, HEA may be used primarily to highlight significant human errors and to provide safety assurance. There is therefore a shift in the “mission” of HEA, from one of improving the robustness of the design in the formative phases, to one of determining whether the risk associated with the design is acceptable in the summative phases. This new mission often requires a quantitative assessment of the likelihood of these safety-significant errors (or safety significant human recoveries of system failures). These quantitative assessments must then be integrated with other hardware, software, and environmental failure and “repair” likelihood, leading to an overall “risk picture” of the main risks and safety nets in a system, such as a safety case. Although the safety case is an end in itself, during the analysis leading up to the final safety case new human errors or critical recovery functions for the controller may be determined. If the assessment of these errors reveals a significant safety impact, particularly with respect to safety targets, design changes may be required to improve or safeguard human reliability.

So, even at later stages in the SDDLC, design changes may still occur. However, these will be limited to the more consequential human impacts on the system, as uncovered by the very detailed and more integrative system analysis that occurs at the late stages in the SDDLC, prior to system operation.

Although outside the scope of this paper, it is worth briefly dwelling on the role of HEA after system operation has commenced. Fundamentally, the approach shifts from one of identification, to one of classification and prediction, to one of learning. However, learning from errors presents its own challenges. There is still much “detective” work to be done, even when all the clues are logically present (because an event has happened), in order to determine the causes of an error, how these causes interacted, and how the error could be prevented in future.

The most important property of any learning system is that lessons can be usefully applied to the future. This has two major implications for a HEA approach in the context of the whole SDDLC. The first is that a feedback and feed-forward information learning system is established, so that what is learned from any analysis at any stage of the SDDLC can usefully inform other analyses. For example, lessons learned from incident analyses during the operational phase of a system should be used in the development of the next generation or next modifications of the system. This is ultimately giving feedback to the system designers and developers. Additionally, it is impossible (and probably undesirable, see Amalberti, 2001) to eradicate all errors from a system. Hence, information about what errors may still be expected, what causes them, and what factors mitigate their occurrence or impact, should be transmitted to the future operators of the system. This is a feedforward learning system. Figure 1 illustrates these feedback and feedforward “loops”.

The second implication of the desire to have a learning system is that both the predictive and retrospective error classification systems are “isomorphic”, that is, they have the same error forms and relations within their approaches. If this is true, then there is no degradation in the transmission of learning (feedback and feedforward) between the two systems. In practice, few systems utilise or realise such a “harmonised” approach, though see Vail et al. (1994) in the nuclear power industry, and Shorrock and Kirwan (submitted) in the ATM industry. However, if this can be achieved, there will be much more power in the overall human error assessment approach, and a shift towards genuine “human error management”.

The SDDLC in ATM can be summarised in three broad phases: the conceptual and early design phases, the detailed design and prototyping phases, and evaluation phases. The purposes of HEA at both the formative and summative phases of the SDDLC are shown in Table 1.

TABLE 1 :
Summarised SDDLC phases and purposes of HEA
Phases et buts SDDLC résumés de l’évaluation de l’erreur humaine

In many cases, such documentation will be insufficient for detailed human error analyses. In such cases, the HF analyst will construct a task analysis, based on the documentation together with discussions with designers and system operators and controllers, and observation of controller interactions with prototypes when these are available. This task analysis will yield a more refined picture of not only the behaviours required, but also the other factors that will be present which may facilitate or detract from effective performance.

Therefore, documentation can partially resolve some resource problems. The main drawbacks with using documentation as a platform are that system interactions may be missed, and contextual information is usually unavailable or is insufficient. Hence, the documentation may not reflect exactly how the system is likely to operate in practice.

Whilst human factors specialists may perform much of the analytical work involved in HEA, their role needs to be more integrative in order to gain the support of stakeholders and obtain value from the work.

TABLE 2 :
Example of the Human Error Assessment in Design portfolio dealing with direct observation
Exemple d’analyse de l’erreur humaine dans la gestion du portefeuille de conception avec observation directe

TABLE 3 :
Example of the Human Error Assessment in Design portfolio dealing with Human Error Identification
Exemple d’analyse de l’erreur humaine dans la gestion du portefeuille de conception avec identification de l’erreur humaine

The intention was to use the HEA findings to feed into the design phase to ensure that the system could be made more resistant or tolerant to errors. Results from the HEA were also used to prove the validity of the findings from a Human Error Identification (HEI) technique (TRACEr) developed within the NATS. A combination of methods was used for the HEA. These are described below.

The type of errors recorded were mainly errors in selecting an object on the HMI (e.g., typing errors, menu selections, text field selection and other mouse button presses). Cognitive errors of judgement and planning were difficult to observe and verify reliably. Consequently, they were not the focus of the direct observational analysis.

Previous to the observational analysis a Hierarchical Task Analysis (HTA) for each of the tools had been developed. This enabled the observer to understand in detail how the user should correctly interact with each tool, and helped to construct observation sheets.

A number of “Performance Shaping Factors” associated with the HMI were identified:

The error probabilities were combined with controller knowledge of the potential impact on safe operation. As a result, it was possible to prioritise redesign effort in terms of safety and usability. Due to resource constraints, the team could not observe all sectors and controllers during all exercises. However, the combination of methods provided additional information that may otherwise have been omitted, and allowed verification of findings. A number of remedies were suggested to reduce or resolve the potential for error as far as practicable:

The analysis was able to conclude that most potential errors were likely to be detected by the controller team involved in using FAST. Some of the predictions made by TRACEr were confirmed independently in subsequent user trials. Evans et al. stated that TRACEr explores the potential for many types of errors and provides a systematic assessment. They further posited that user trials alone are unlikely to provide an extensive understanding of error potential because errors might not occur regularly or may be easy to detect by controllers. In addition, the process identified problems that had not been identified by the design team. Evans et al. concluded that the HEI process was able to provide a further level of assessment of FAST beyond that achieved by user trials.

A HAZOP team assessed the implications of the new interface. The team comprised three designers, one air traffic controller and two human factors specialists. A total of 16 hours, spanning three separate HAZOP sessions, were spent interrogating the prototype system. The study identified a number of vulnerabilities in the prototype and opportunities for error that needed to be addressed. A total of 87 recommendations were generated from the three HAZOP sessions, as follows:

The HAZOP group identified what factors needed to be changed in the system and how these changes could be addressed. Since the designers were present and actively involved, any design changes they thought necessary were simultaneously accepted for implementation. The HAZOP therefore had very effective impact on the design process.

In terms of the strength of the HAZOP approach, a number of problems that were identified in the design would have been difficult to detect without a multidisciplinary team present. In particular each member of the team brought a specialism to the group process. All this information was shared effectively, leading to a rich multiple-perspective on the system design and its strengths and weaknesses. Such an interrogation of the system would have been very difficult to achieve in any other way and underlines the niche for HAZOP in system design and evaluation.

This paper has suggested a number of relatively straightforward yet effective methods for studying human error in the context of Air Traffic Management. The techniques have been applied to future ATM systems, at several stages in the design and development process, leading to better solutions for future ATM systems and tools.

TABLE 4 :
Comparative evaluation of the seven HEAD portfolio techniques
Évaluation comparative des sept techniques de portefeuille HEAD

There is no single best approach for analysing error for all occasions or types of systems, and so a “portfolio” of convergent approaches has been developed. These are evaluated comparatively in Table 4. This portfolio of approaches focusing on human error, and complementing other more traditional design and human factors approaches, will make future systems more robust and less vulnerable to human error, enabling human performance to lead to safer and more efficient air travel in the future. This ability to focus on human error in a relatively transparent way, so that it is understandable by designers, controllers and human factors professionals alike, identifying errors as a function of the detailed context of the design of the system, is a critical key to future safety in our skies. Human error techniques must therefore be formally integrated into other larger design, and safety management portfolios and processes for the development and running of ATM systems in the future. Blaming an accident to “Human Error”, is no longer enough. The question is now: “Why wasn’t this error identified and prevented?”

Paper received: October 2000.

Accepted in modified form: March 2001.