University of Groningen Safety is no accident Kesseler, Ernstaccidents (NASA 2004), (Kebabjian...

University of Groningen

Safety is no accidentKesseler, Ernst

IMPORTANT NOTE: You are advised to consult the publisher's version (publisher's PDF) if you wish to cite fromit. Please check the document version below.

Document VersionPublisher's PDF, also known as Version of record

Publication date:2008

Link to publication in University of Groningen/UMCG research database

Citation for published version (APA):Kesseler, E. (2008). Safety is no accident: contributions to achieving certifiable safe software. [s.n.].

CopyrightOther than for strictly personal use, it is not permitted to download or to forward/distribute the text or part of it without the consent of theauthor(s) and/or copyright holder(s), unless the work is under an open content license (like Creative Commons).

Take-down policyIf you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediatelyand investigate your claim.

Downloaded from the University of Groningen/UMCG research database (Pure): http://www.rug.nl/research/portal. For technical reasons thenumber of authors shown on this cover page is limited to 10 maximum.

Download date: 16-02-2021

https://www.rug.nl/research/portal/en/publications/safety-is-no-accident(2e45e94e-1512-47f3-9a7d-90b279758c61).html

https://www.rug.nl/research/portal/en/publications/safety-is-no-accident(2e45e94e-1512-47f3-9a7d-90b279758c61).html

56 Human-centred design


Published as E. Kesseler, E.G. Knapen, Towards human-centred design, two case studies, Journal of Systems and Software (79), .March 2006, pages 301-313, (c) Elsevier Inc 2005.

Abstract

Currently much system development is done using a technology-centred approach: automating the functions the technology is able to perform. Human-centred design including a cognitive work analysis seems a promising alternative for systems combining skilled humans and automated support. Carefully selected information technology can support this innovative system development approach.

Two correlated case studies assess the merits and limitations of a human-centred approach. To improve human capacity while maintaining or preferably increasing current safety levels automated support is needed. Despite the long-term trend of increasing automated support, the human remains the major contributing factor in accidents and incidents. Combining these two observations substantiates the need for innovative system design. The described results are relevant for other domains relying on human experts supported by complex automated systems.

3.1 Introduction

Complex systems are characterised in (Vicente 1999) as many people with different perspectives working together in a dynamic environment with uncertain data, unanticipated disturbances and with computer mediated actions. Humans are retained as not all circumstances can be foreseen, preventing full automation. Historically a technology-centred approach (provide what is technically possible without paying proper attention to the remaining human’s task) is used. It is well known that humans are the most important contributing factor to aircraft accidents. Estimates for human involvement range from 60% to 80% of the total number of accidents (NASA 2004), (Kebabjian 2004). In the last two European Air Traffic Management (ATM) induced accidents, human intervention caused the accident (Swiss mid-air collision of July 2002) or human limitations caused the accident (loss of situational awareness in the Lineate accident of October 2001). Interestingly an analysis of significant incidents in the, similarly safety conscious, nuclear industry

Human-centred design 57

shows human performance issues as the largest contributor, causing 52% of the incidents. Design deficiencies, the delayed consequences of human contribution, cause another 33% (INPO 1985). Even in complex domains without safety concerns, like the fixed telephone network, human error accounts for 52% of the outages (Brown, Patterson, 2001). Surprisingly also in young industries, like Internet services with their continuous availability requirement, human error accounts for 44% of the service failures (Oppenheimer et al., 2003). From non-safety-conscious domains there are numerous examples that automation can actually reduce productivity if insufficient attention is paid to its design and the way it supports the human. For example (Vicente 1999) states the US internal revenue service experienced a 40% productivity reduction after investing in personal computers. Two other studies (Landauer 1995), (Gibbs 1997) show that investment in information technology in the US has even reduced the long-term economic growth rate. It is clear that there is a need for advanced tools to support well-trained professionals in complex and demanding environments. Attempts to reduce the reliance on human skills by increasing automation have led to the ‘‘irony of automation’’. Because in these complex environments not all failures can be foreseen, designers can reduce but not eliminate the need for human intervention. Consequently the human remains for the hard, i.e. unexpected, interventions. However as the routine operations are automated, the human has less experience and is less able to operate correctly in the rare instances that he is required (Reason 1990).

Human-centred design is an alternative design method for complex systems that addresses such problems by focusing mainly on the user. Norman (1998) defines it thus: “It’s a process of product development that starts with users and their needs rather than with technology. The goal is a technology that serves the user, where the technology fits the task and the complexity is that of the task, not of the tool.’’ The foundation of a human-centred design is a structured analysis of the users’ tasks. Based on a thorough task analysis, the design process includes activities to ensure its focus on the human, like usability engineering, iterative design and prototyping.

Two case studies have been performed to test the applicability of the innovative human-centred approach. Air Traffic Management (ATM) is chosen as it is demanding, safety conscious and the current technology-centred approach is reaching its limits. Current air transport is affordable and safe, confirming the success of the traditional approach. For busy parts of airspace, communication between controller and pilot is already highly optimised, but the controllers still


spend the majority of their time communicating. Historically airspace is divided into sectors to reduce workload, but for busy parts the added inter-sector communication of smaller sectors offsets the reduced controller-pilot communication.

The European vision 2020 (Argüeles et al., 2001) foresees a tripling of air traffic. Its goals include improving safety through a fivefold reduction of the accident rate despite the increased traffic density, while at the same time improving punctuality to 99% (i.e. flights arriving and departing within 15 minutes of schedule). Currently in busy parts of the airspace, e.g. above Frankfurt or Milan, punctuality is eight times worse at 92% (PRC 2004). For various reasons, including safety, liability and social acceptability, the common opinion is that neither fully automated air traffic management nor fully automated aircraft are feasible options, so a complex system involving humans and computers remains. Simultaneously increasing the traffic density and the number of aircraft under his control will increase the demands on the human controller. New support tools are needed to enable the controller to cope with these requirements.

Section 3.2 briefly elicits the characteristics of a human-centred design process. Section 3.3 provides the context description, the findings and the analysis of the first human-centred design case, concentrating on Human–Machine Interface (HMI) issues as the most critical component. The first case combines human-centred design with the waterfall model, common in the domain due to its well understood way to provide software complying with the domain’s safety and certification requirements.

Based on the findings of the first case, a follow-on case study has been performed, described in Section 3.4. In this case, human-centred design is combined with an evolutionary approach and object-oriented design.

The last section summarises the major findings into the conclusions.

3.2 Human-centred design

The often used ISO standard 13407 (ISO-13407 1999) describes human-centred design as a multidisciplinary activity, which incorporates human factors and ergonomics knowledge and techniques to enhance effectiveness and productivity, while improving human working conditions. It states that there are four design activities that need to start at the earliest stages of a project: understand and specify


the context of use, specify the user and organisational requirements, produce design solutions and evaluate designs against requirements.

Most of these activities are present in any design method, limiting the guidance offered by this standard. Fortunately, an improved version has been published as ISO TR 18529 (ISO-18529 2000), which contains a more detailed list of the activities and 44 base practices. An in depth presentation of all practices is outside the scope of this paper. Some of the key activities are:

Identify and document the user’s tasks;

Identify and document significant user attributes;

Allocate functions;

Produce a composite task model;

Use existing knowledge to design solutions;

Develop and evaluate (early) prototypes.

Including these activities in a design process ensures a continuous focus on the users of the system. Task analysis is the process of analysing the way humans perform their jobs: the things they do, the things they act on and the things they need to know. This process will identify and document the user’s tasks and significant user attributes. As such, a thorough analysis of the user’s tasks is the foundation of a human-centred design method. Many different task analysis techniques exist, like Hierarchical Task Analysis and Goals, Operators, Methods and Selection (GOMS) (Dix et al., 2004).

Cognitive Work Analysis (Vicente 1999) offers a method that supports the activities of allocation of functions and production of a composite task model. It describes two complementary strategies:

Centralised control. The design contains the ‘‘optimal’’ plan based on an analysis done in advance. The computer system enforces the designed plan through a fixed work flow. The human executes the designed plan, as far as it cannot be automated. This approach works well when safety limits need to be guarded;


Distributed control. The design identifies foreseeable constraints and supports human operators. The computer system shows the actual constraints and supports the human. The human solves the tasks by combining the provided information using his knowledge and expertise.

Based on a thorough task analysis, cognitive work analysis aims to find the right balance between centralised and distributed control. Similarly the human should be presented with sufficient and sufficiently challenging tasks but should not be overloaded by them.

Usability engineering (Nielsen, 1993) is an approach to use existing knowledge to develop design solutions. It introduces explicit usability requirements, based on human factors and ergonomics knowledge, into the design process. Measurement criteria, called usability metrics, are defined for example by the ISO 9241 (ISO-9241, 1998) standard to indicate effectiveness, efficiency and user satisfaction.

By definition, complex interactive systems cannot be completely specified at the beginning of the life cycle. They have to be (partially) build and tested on real users. Any observed design deficiencies can subsequently be corrected. A design process that includes these activities on purpose is called an iterative design process. Prototypes, artefacts that simulate or animate some but not all features of the intended system, are often a good means of obtaining feedback from users during the design process.

3.3 The first human-centred design case study

3.3.1 Operational context

Based on collaborative decision making concepts like Co-operative Air Traffic Services (COOPATS) (Eurocontrol, 2000) the objective was to integrate the controller’s and the pilot’s activities. Currently controllers use a flightplan consisting of a fixed route, combined with altitudes. Planning attaches a time to the end of each straight section. Once the controller and the pilot agree the aircraft’s trajectory, the pilot is responsible to comply with the resulting trajectory. The controller will independently check the aircraft’s adherence to the agreed trajectory. With the same accurate trajectory information available to both the controller and


the pilot, properly designed tools can reduce the controller’s workload and enhance situational awareness. Situational awareness is defined in (Jeannot et al., 2003) as the continuous extraction of environmental information, the integration of this information with previous knowledge to form a coherent mental picture and the use of that picture in directing further perception and anticipating future events. Hagemann and Weber (2003) distinguishes three levels of situational awareness: perception, understanding and planning. The major distinction between experts and novices is on the planning level. Further optimisation by taking other actors into account like the airport, the airline, etc., are outside the scope of this case study. More information on these improvement opportunities and supporting technologies can be found in (Kesseler 2004) or from an airline point of view (Gittel, 2001). The system enhancements relevant to this paper are:

Integrating the currently unconnected controller’s ground systems with the pilot’s airborne systems;

Using a human-centred approach, the 4D-trajectory was designed to communicate all trajectory information between controller and the supporting tools. The same 4D-trajectory is used for communication with the pilot;

Supporting the controller (and pilot) with automated tools while retaining the human in-the-loop paradigm for both roles, i.e. enhance their situational awareness.

The same integrated, human-centred approach is used for the design of the controller HMI, the subject of the first case study. Information is combined and, to improve intuitiveness, shown as much as possible in the familiar radar display. When information is shown in more than one window, this is done in a consistent way. A system designed with these enhancements is capable of dealing with predicted 2020 traffic levels.

The inherent complexity of ATM systems combined with their primary role to provide safety, necessitate validation of any new ATM concept before it can be deployed in the real world. As human controllers are involved, realistic real-time simulations involving experienced controllers are necessary to verify safety and capacity (Madson, 2004). The findings in this paper would not have been obtained in a less realistic environment, confirming the need for such simulations.


3.3.2 Human-centred system design

To enhance the controller’s situational awareness, the first case study realised an ATM system prototype to integrate the following innovative controller tools. At perception level a Flight Path Monitor automatically verifies whether the actual position updates as observed by the radar comply with the aircraft’s agreed 4D-trajectory. At the understanding level the Trajectory Predictor calculates the expected 4D-trajectory on the ground using the most accurate aircraft-provided information processed by aircraft-derived full accuracy algorithms. The controller uses the Conflict Probe to determine whether a proposed 4D-trajectory does not infringe the separation criteria. At the planning level the Problem Solver supports the controller in finding a 4D-trajectory which resolves a predicted en-route separation infringement. The Negotiation Manager supports the controller (and the pilot) to agree on a 4Dtrajectory. These innovative human-centred tools are integrated into the ground HMI. The ground HMI provides uniform interaction between the controller and all ground system functions. For the controller it is the glue of the system. Tools from five European research centres were chosen. With the exception of the ground HMI, all controller tools were developed independently using the technology-centred approach and verified in small-scale experiments prior to the case study. The case study integrated the tools on a single existing air traffic control simulator. The simulator’s client–server based architecture is designed to facilitate integration of components even when supplied by different organisations. The case study comprised of 29 different server types, with up to 15 concurrently active copies of a single server type. Figure 3-1 depicts the architecture of the completed system.

Standard usability books like (Nielsen 1993) mention several methods to determine usability, depending on the HMI’s realisation phase. During the ground HMI design, heuristic evaluation was used to determine and solve the most obvious usability problems. Having five research centres providing and evaluating tools naturally coincided with the recommended number of independent evaluators. Subsequently, operationally qualified controllers evaluated the entire system, including the HMI. During run-time an automated ‘‘instantaneous self assessment’’ module provided direct feedback of the controllers involved. The test results were complemented by questionnaires, as open interviews are hard to compare and analyse (Nielsen 1993). In total 25 controllers from 8 countries evaluated the system during the experiment, which consisted of 3 measured sectors complemented by 8 feeder sectors. Fifteen


‘‘pseudo’’ pilots controlled up to a total of 300 aircraft complemented by real pilots flying research aircraft.

Figure 3-1. Case study system architecture.

3.3.3 Human-centred ground HMI display design

In order to appreciate the functions and complexity of the ground HMI Figure 3-2 depicts the full HMI. A detailed description of all windows can be found in (Kesseler, Knapen 2000). To illustrate the human-centred design and to understand the artefacts found the main display will be described. The design of an auxiliary display further justifies the conclusions and introduces the second case study. Overall, the human-centred design is based on the premise that the controller is highly skilled, well trained, and depends on the HMI for his safety provision task. The same holds for pilots. Standards guide pilot display designs based on the allowed display symbols. These standards specify, in excruciating detail, the requirements and certification for each individual cockpit display. Despite all this effort the qualified human pilot remains the most significant single contributor to accidents. Currently (Clamann, Kaber 2004) estimates that 70% of fatal aircraft


accidents are due to human error, potentially induced by the design of cockpit HMIs. The source of the accidents is the system (design), not its components or operators. Many experts e.g. (Dekker 2003) and (Woods, Cook 2003) observe that for complex systems accidents are not caused by failures of individuals but the result of multiple contributory system factors, each necessary but only jointly causing the accident. Consequently to further reduce the human contribution to accidents recently FAR/CS 25.1302 (FAR, 2004) has been submitted. On top of the individual display certification, FAR/CS 25.1302 will require the certification of the entire flight deck. A draft advisory circular (or acceptable means of compliance in EASA terms) complements the rule. This advisory circular will provide guidance on the proposed rule’s interpretation and possible ways to demonstrate compliance. At this moment similar standards do not exist for controller displays or the entire controller work-suite.

Figure 3-2. Overview of the HMI with minimal label (A), full label (B), area discussed in Section 3.3.4 (C).

Literature, like (Karat et al., 1992), contains a number of design guidelines to ensure usability. For the flightdeck FAR/CS 25.1302 certification will enforce the following: provision of an intuitive visual layout, consistent behaviour, provision of feedback, minimisation of mode effects and reduction of clutter. Figure 3-2 shows the system’s advanced radar display as used by a controller in charge of the (upper)


airspace above the entire country of Belgium, which is one of Europe’s busiest airspaces. The grey lines represent airways, which lead from beacon (indicated by a small triangle) to beacon.

The main window is called the Plan View Display. This window provides all information available in traditional ATM systems. The major human-centred design features are:

To be intuitive, the window mimics a conventional radar display for all standard features. For these standard features this implies consistent behaviour and provision of adequate feedback. The controller’s airspace is depicted in a lighter shade of the background colour;

To avoid clutter only aircraft that satisfy filtering rules are displayed. Note that these rules are context specific, when a 4D-trajectory is modified using the problem solver tool, all unrelated aircraft are automatically made invisible;

To support the controller’s preferred way of working and to minimise mode effects only one 4D-trajectory can be modified at a time. Modification is intuitive by ‘‘picking’’ any point on the trajectory and ‘‘dragging’’ it to the desired position. This 4D-trajectory is shown in green;

To avoid clutter and information overload, labels with minimal information are provided (Figure 3-2 area A). On request, extended labels can be provided (Figure 3-2 area B). Label colours are used consistently to provide status information on the flight. Labels of aircraft in need of controller action are boxed.

3.3.4 System usage through ground HMI

Figure 3-3a shows how the conflict probe tool enhances situational awareness by automatically detecting a potential conflict based on information from the full accuracy trajectory prediction tool. For clarity only area C from Figure 3-2 is shown. Complying with the distributed control strategy, only after the controller selects the aircraft concerned, the ground HMI shows the predicted positions of aircraft that will come into close proximity. These aircraft are shown with a yellow (warning) or a red (conflict) zone and their speed vector.


Figure 3-3a: Interactive conflict probe detects a possible conflict Figure 3-3b: Controller solves conflict with problem solver, minimising trajectory interference.

The controller intuitively investigates a solution to this conflict by ‘‘picking’’ a point of the 4D-trajectory and ‘‘dragging’’ it outside infringement area (see Figure 3-3b). Every modification of the 4D-trajectory changes the possible conflicts with other aircraft. The problem solver automatically recalculates the red and yellow zones. In order to minimise disturbance of the aircraft’s preferred 4D-trajectory, the controller’s solution only just avoids the warning area of the infringing aircraft. To inform the controller, the red zones on the plan view display and the vertical profile display have disappeared (Figure 3-3b). To comply with the feedback requirement, real-time response is an essential feature for this tool. The problem solver contains a dedicated and simplified trajectory predictor to achieve this real-time response. After the controller is satisfied with the solution, it needs to be validated using the full accuracy aircraft-derived trajectory predictor before proposing the solution to the pilot.

In the real-time simulation the controllers handled the tripled 2020 traffic volumes, so from a system requirements point of view the human-centred design was successful. Also the controllers felt confident handling the expected volumes with the tool set provided, as reflected in questionnaires. The intuitive and consistent tool-set was appreciated, endorsing the human-centred design.

In the first case study the distributed control strategy is used for both the ATM system as well as for the HMI design. It works well as it allows the controller to provide solutions, supported by the system. The controller retains his situational awareness to solve unforeseen situations. The safety-net functions use a centralised control strategy, in accordance with the overall cognitive work analysis approach. The controllers involved appreciated this advanced human-centred design, whereas


current practice provides various examples of seemingly small technology-centred design changes which had to be withdrawn due to justified controller objections.

3.3.5 Human-centred design versus technology-centred design

For a complex system with safety concerns, the current technology-centred approach, which matured over decades, is reaching its capacity limits. The human-centred approach provided three times this capacity, making it a viable alternative. Note the difference with the technology-centred design. (Yost, 2004) characterises the result of technology-centred design with the creation of an additional system each time a new type of information needs to be exchanged between controller and pilot. Such a new system is added to the existing ground system and a matching new avionics system is added to the cockpit.

Prior to this case study a technology-centred design to increase controller capacity has been implemented by others. Voice communication between controller and pilot consumes a lot of controller time. Based on this observation, the standardised communication phrases (e.g. clearances) have been analysed. The top 10 most frequently used phrases and confirmations (pilot readbacks) have been selected and replaced by automated data link messages. Although this technology-centred design reduced voice communication as intended, it did not provide the required capacity increase. Additionally an aircraft can calculate its 4D-trajectory with greater accuracy then ground based systems due to proprietary aircraft performance data in its flight management system and access to the proprietary airline operating procedures. In the technology-centred approach, ground-based tools have to take larger margins into account resulting in smaller capacity increase. The data link’s unpredictable delay of up to a minute implies that a controller has to pay attention at least twice for the communication. This violates the central conclusion of (Cardosi, DiFiore 2004) that controller’s mental task scheduling must always be at the controller’s discretion.

3.3.6 Observed artefacts

In some cases validation of the conflict probe solution by the full accuracy trajectory predictor failed, i.e. the conflict remained. Although the risk of infringement is significantly reduced (as shown in Figure 3-4a) from a safety perspective the


solution of course remains unacceptable. Even when such behaviour is quite rare, it means the solution will have to be modified by proposing a second solution (Fig. 4b). Due to the time delay involved, this second problem solving action disturbs the scheduling of the controller’s mental tasks. Cognitive psychology studies show the negative effect of interruptions on memory and performance (Cutrell et al., 2001). This leads (Cardosi, DiFiore, 2004) to state that (mental) task scheduling must always be left to the controller. Controllers are trained to build their situational awareness by a routine effort distribution over their tasks like monitoring, diagnosing and problem solving (Kjaer-Hansen 1998). (Hagemann, Weber 2003) even claim all controller accidents are caused by a reduction of this situational awareness, justifying the need to take this unexpected behaviour very seriously. Of the HMI design guidelines the ‘‘be consistent’’ and ‘‘minimise the use of modes’’ have been violated in these special circumstances. In the operational evaluation the controllers agreed that these tool inconsistencies caused confusion.

Figure 3-4a: Slower, full-accuracy trajectory prediction tool rejects solution Figure 3-4b: Controller solves conflict again.

3.3.7 Analysis of the observed artefacts

The real-time problem solver and the trajectory predictor were developed independently. The case study merely harmonised and did not integrate the tools. Consequently in special circumstances they behaved inconsistently. Extending the human-centred approach to the integration of independent tools into a tool-federation solves this kind of problem. Such integration comprises:


Make input data consistent. Partly, this can be accomplished by splitting a tool into separate modules. The common input processing should become a separate module apart from the actual algorithms. Software specifications like Application Programming Interfaces help to unambiguously define the interfaces;

Improve consistent system behaviour by analysing the sensitivity of the integrated tool-federation for inaccuracies in the provided input data;

Minimise mode effects by redesigning the computationally efficient (problem solver) tool based on a conservative approximation of the results of the full accuracy (trajectory prediction) tool.

In fact the observed inconsistencies are a direct result from the system design method. When the integration of the tool’s various HMIs failed, the ground HMI was redesigned according to the human-centred approach. Although the underlying tools were selected using the same approach, they were only harmonised. This case study demonstrates that the human-centred approach needs to be enforced rigorously. This finding confirms that the source of accidents is the system, not its constituent parts. Consequently the finding supports the consistency requirement of FAR/CS § 25.1302 (2004). Recent research (Roelen et al., 2004) confirms that design is a contributing factor in 50% of recent accidents in air transport and nuclear industries. As traditional design is technology-centred, the positive results of a fully human-centred design can be considered relevant beyond the specific case studies.

As an aside, the experience confirms the merits of the non-punitive investigation practise, common in the air transport sector. Only by the open attitude of the controllers and the software developers was this infrequent inconsistency detected and explained. Also for the aircraft turn-around process, (Gittel 2001) found that best performance was obtained using a non-punitive approach. For accidents and incidents involving controllers or pilots (Dekker 2003) and (Fenwick, Huhn 2003) found the non-punitive approach is a prerequisite to keep learning from past experience. This forms the basis of the industry’s self-improving safety system and good safety record.

The observed artefacts occurred a couple of times during hundreds of (simulated) operational hours. To put this frequency into perspective a comparison is made with some relevant safety standards. For aircraft JAR/ FAR 25 provides a safety classification. For software this has been elaborated into DO-178B (1992). For air


traffic control the US has elaborated DO-178B into (DO-278, 2002) amongst others by adding requirements for Commercial Off-the-Shelf (COTS) software which is not developed in accordance with DO-178B or DO-278.

Table 3-1. overview DO-178B/ED12B, JAR/FAR 25 and DO-278/ED-109.

DO-178BLevel

System failure

Failure description Failure probabilitydescription

FAR/JARdefinitionper flighthour

DO-278assurance level

DO-278COTSserviceexperience

A Catastrophic failure

Aircraft loss and/orfatalities

Extremelyimprobable

.. < 10-9AL 1 Not allowed

B Hazardous / Severe major

Flight crew can not perform their tasks Serious or fatal injuries to some occupants

Extremely remote

10-9 < .. < 10-7

AL 2 Negotiatewithapprovalauthority

C Major failure

Workload impairs flight crew efficiency Occupant discomfort including injuries

Remote 10-7 < .. < 10-5

AL 3 One year

AL 4 Six months

D Minor failure

Workload within flightcrew capabilities Some inconvenience to occupants

Probable 10-5 < .. AL 5 Typically not needed

E No effect No effect Notapplicable

- AL 6 Notapplicable

Table 3-1 lists some definitions and attributes per level. Included are the DO-278 requirements on pre-developed COTS for the duration of its continuous, failure-free use in a representative environment. Software that proposes air traffic control directives, like the problem solver, or monitors safety, like to flight path monitor,


needs proper safety analysis to determine its software safety level. However to illustrate the allocation of these levels, air–ground communication software is classified at level C at most. The most critical part of Europe’s Galileo real-time position information (e.g. for a satellite navigation update service) is classified at level B. The repeated occurrence of the reported tool inconsistency during just hundreds of operational hours shows how far off such integrated tools are from DO-278 assurance level 4 or DO-178B level C. Experience with airborne software shows that increasing the reliability by the required orders of magnitude cannot be done using the same system development paradigm. Note that in this case, considerable effort was already paid to implement a more human-centred approach. The observed artefacts suggest that a human-centred approach needs to be enforced very rigorously and consistently. This confirms the applicability of a FAR/CS § 25.1302-like approach to air traffic management: on top of the attention paid to individual tools with their dedicated displays, effort is needed at system level.

3.3.8 Conflict and risk display design

To improve the controller’s situational awareness at perception level the specially designed conflict and risk display (Figure 3-5) provides an overview of all detected conflicts including a severity indication. The vertical axis provides the distance between two aircraft at the point of their closest approach. The horizontal axis provides the time to the first loss of separation. The squares on the horizontal and vertical axis are used to scale the corresponding axis. On the left the identification of each conflicting aircraft pair is provided. For an operational display the annotation at the axis would be omitted to reduce clutter. (More information on this display can be found in (Kesseler, Knapen (2000).)


Figure 3-5. Conflict and risk display.

The conflict and risk display received mixed reviews. The controllers appreciated the simple and intuitive graphical design, but also noted that the link with the relevant aircraft in the main display and vertical view display was not intuitive and hence the design needs to be improved. The display supports the perception level, but does not assist on the higher situational awareness levels. Instead a fully human-centred design for all situational awareness levels requires a more elaborate analysis of the controller’s needs. As a result the subsequent case study (Section 3-4) developed the resolution and conflict window based on a human-centred design to supersede this conflict and risk display design.

3.3.9 Software design

As the software consumed the major part of the effort of the first case study, some lessons learned with respect to the human-centred approach are presented. Based on the informal high level specifications of the tool-federation, the various research organisations developed their tools in parallel. Subsequently all tools were integrated at a central site into the existing simulator infrastructure. To ease the integration management, a waterfall model was used as all partners had experience with it. In addition, it is well understood how to produce software complying with the relevant safety certification requirements using this model. Management preferred it above iterative development, with which some partners lacked experience. The drawbacks of the waterfall approach are:

Controllers can only judge the system characteristics when an early prototype is available. The waterfall model does not support timely provision of prototypes. For HMIs many (e.g. Nielsen, 1993) recommend iterative design;


A lengthy and unpredictable system realisation phase. Even for our prototype, the realisation was delayed for several years and eventually took a decade. During this protracted realisation time the operational concept matured resulting in requirements evolution, which the standard waterfall model does not accommodate. This is especially true for the ground HMI, which, as the controller’s window on the system, attracted the most changes by far.

With the benefit of hindsight an iterative development model would have been more appropriate. Also for certifiable software, even up to the highest safety classification, the same conclusion has been reached (Kesseler 2000). However by producing 15 deliveries of which 2 have been certified in 26 months, (Kesseler 2000) demonstrated that an adapted waterfall model can produce safety-critical software (DO-178B level A) and be responsive. Based on the reduction in the time-to-market required by the US and European vision, evolutionary management (Gilb 2003) is a better approach as its focuses on continuous intermediate deliveries that provide user value and elicit user feedback.

Table 3-2. Overview software size components of first prototype.

Item KLOC

Ground HMI 196

Trajectory predictor 44

Flight path monitor 35

Problem solver 25

Arrival manager 20

Negotiation manager 20

Air traffic server 20

Conflict probe 16

System flightplan server 8

Standard proprietary real-time simulation middleware 220

Standard research aircraft flight management system 144

Typical real-time simulation including non-experiment dependant modules 400

Contrary to initial expectations, the ground HMI consumed significant resources. Table 3-2 provides some information on the size of the basic simulation software


and the tools added for the first case study. All module sizes are expressed in thousand lines of code (KLOC). The programming languages used are C, C++ and Ada in order of relative use. Some middleware and standard simulator components contain legacy Fortran code. The trajectory predictor is based on the flight management system of a research aircraft to produce the most accurate information. The size of this standard flight management system software is provided separately. The ground HMI software is relatively large, especially when compared with the standard simulation software. An object-oriented redesign of the HMI has been performed resulting in a set of generic modules. To comply with the evolutionary approach, with these modules new HMIs can be produced swiftly and affordably. This redesign has been implemented prior to the second case study to facilitate full human-centred solution design.

3.4 Second human-centred design case study

3.4.1 Human-centred design with object-oriented evolutionary approach

The positive operational results from the first case study initiated subsequent work. This provided an opportunity to improve the partial human-centred design approach to a more consistent and rigorous human-centred design. The waterfall model did not combine well with the human-centred approach in the first case study. As object-oriented design combines well with evolutionary approach, the second case uses it. To investigate justified safety and certification concerns, the realised service history of the object-oriented software is analysed to determine feasibility of certification.

3.4.2 Operational concept

Implementation of the first case assumed a communication infrastructure between aircraft and ground systems. Although the aeronautical telecommunication network has solved the technical part of this problem, deployment on a significant scale will take many years, quite probably until regionally mandated early next decade. Even in the competitive and consequently innovative telecommunication world, deployment of a new technology takes half a decade (Sherif, 2003). A second ATM system was developed to obtain the operational advantages of the first case study,


but taking the current realities into account by only assuming improved ground–ground data communication.

3.4.3 Human-centred HMI design and usage

To prevent the system level challenges encountered in the first case, the HMI design is based on an existing HMI. It is similar to the one described in the previous case. The simulator architecture was similar to the one presented in Figure 3-1, but without the air–ground data link related components. Recently with this system several large-scale simulations were conducted with a resolution assistant tool. This tool, further referred to as resolver, is the equivalent of the problem solver of the first case. In line with the distributed control principle, the resolver suggests solutions to predicted separation infringements. Such solutions are 4D-trajectories, as described in Section 4.3.1 and presented similarly. The controller can solve the conflict using the suggested 4D-trajectory, but has to communicate this solution via the traditional voice channel to the pilot concerned, adding workload. Also the ground system cannot take advantage of full-precision aircraft-derived trajectory data for its 4D-trajectory prediction, but has to rely on less accurate ground based estimates. The intuitive, graphical 4D-trajectory representation of the first case is retained.

In accordance with the human-centred design any predicted conflict is always displayed in combination with the information from the resolver to support the controller’s situational awareness. To enhance the controller’s situational awareness a special overview window was added displaying all currently unresolved conflicts. This Resolution and Conflict Window, depicted in Figure 3- 6, evolved from the conflict and risk display discussed in Section 3.3.8. The y-axis displays the time-to-occur, i.e. the start of the separation infringement. The x-axis displays the time-to-act, i.e. the time the controller has to issue the solution by instructing the pilot. The tool supports the controller by taking into account the time to issue the instruction, the pilot readback time and the pilot’s implementation time when calculating the time-to-act. In the rare cases no solution is available the time-to-act is set 2 minutes prior to the time-to-occur. At 2 minutes prior to the time-to-occur the safety net function provided by the short-term conflict alert takes over from the medium-term conflict tool, which has a 20-minutes look-ahead time.


Figure 3-6a. Resolution and Conflict Window. Figure 3-6b. Resolution and Conflict Window with proposed resolution for conflict.

A vertical line headed by a numbered black square represents a conflict. For good readability the number is white on a black background. For consistency with the other displays the black square has an outer border in the red conflict colour. The centre of the square corresponds with the time of first separation infringement. The end of the vertical line corresponds with the time of closest approach. The number inside the square uniquely identifies the conflict. To aid the controller in his routine tasks to maintain situational awareness, the resolution and conflict window is permanently displayed within the radar display. This minimises clutter by maximising the radar display that provides most controller information. Based on intimate knowledge of the controlled airspace, the controller can position the window optimally e.g. close to where most conflicts occur. On controller request the window is semitransparent to reduce clutter and to reduce the need to move the window should a conflict develop in the airspace it covers. When the cursor is positioned on a conflict square like in Fig. 6b, detailed information is provided about the conflict and the best-ranked solution, including a graphical representation of the proposed 4D-trajectory. To reduce mode effects only one conflict can be selected at a time.

Clicking on ‘‘OK’’ acknowledges the best-ranked solution. Acknowledgement means the controller gets a reminder at the optimal time-to-act to communicate the solution (clearance) to the pilot. The resolver assumes the controller will act correspondingly and no longer displays the conflict warning. When the controller


and the pilot comply, the predicted conflict is avoided. If, however, the controller acts later (or earlier) than calculated, the proper action may cause another conflict.

By clicking with the right mouse button, the resolver provides a window listing alternative solutions for the selected conflict, as shown in Figure 3-7. The resolver uses many controller-provided rules to select the optimal solution. For example, small trajectory changes are preferred over larger ones and a small number of changes is preferred over a larger number. For every solution shown to the controller, many more have been evaluated and ranked as less preferable according to predefined rules. The objective of the human-centred design is to reduce the controller’s workload at planning level while achieving better solutions by taking more information into account than a controller could process. However the controller can have valid reasons to prefer alternatives, which is the basic reason to retain the human controller.

Figure 3-7. Solution List Window.

In line with the distributed control principle every line shows detailed information of the best solution for each type. The available solution types are grouped in accordance with the controller’s clearance types. To minimise mode effects the solution types are listed in a fixed order from top to bottom: left turn, right turn, direct heading, descent, climb and speed instruction. To improve intuitiveness moving the cursor over a line of text provides a graphical representation of the 4D-trajectory on the main plan view display window (Figure 3-2). Using the buttons at the top of the window, solutions satisfying specific requirements can be requested i.e. only left turns or solutions not involving co-ordination with the adjacent sectors. Note that the order of the restriction buttons displayed horizontally differs from the vertical solution list, which violates the consistency requirement. This inconsistency, only discovered while preparing this paper, illustrates the difficulty of achieving a full human-centred design.


A technology-centred approach typically would have provided a conflict display only, i.e. omitting the resolution part, or provide a single resolution advice only. Typically no justification would be provided and alternative solutions would not have been presented to the controller. The human-centred design outperformed the technology-centred one.

3.4.4 Observed artefacts and their analysis

Twelve controllers and a number of pseudo-pilots were involved during the experiments. Controllers appreciated the human-centred design and intuitive HMI. However for busy parts of airspace they noted they might be unable to issue the solution at the time-to-act. Reasons include the controller already issuing other computer-generated instructions resolving a different conflict. This could be avoided by extending the tool to take already acknowledged solutions into account when solving new conflicts. Other situations, however, are by their nature unpredictable. Examples include a sudden meteorological deterioration necessitating immediate controller action. No tool can take all situations into account, which is the reason to retain human controllers. In cases where the controller is not able to issue the predefined instructions at the provided time-to-act, the controller has to find a new solution at a later moment. With less time remaining, the tool’s benefits are reduced.

Because of the unpredictable nature of the work, the busier the airspace gets the more controllers prefer to solve conflicts as soon as possible, to ensure the airspace remains safe. The experiment showed that the controllers switch their working mode at increased traffic levels. Even though in the second case the human-centred approach was applied rigorously, which the controllers appreciated, the task analysis failed to note the controller’s mode switch. Consequently human-centred design needs to be applied very thoroughly. The evolutionary approach with its swift provision of intermediate results was beneficial, as the second case study consumed much less resources and time. Note that with an air–ground data link available, as in the first case, the resolver could conform to the controller’s preferred method of work by immediately and automatically transmitting the proposed solution to the pilot. However current realities prevented the case study usage of a data link.


3.4.5 Software design

The second HMI was implemented using the redesigned object-oriented proprietary software package (see Section 3.3.9). Commonly used objects, like labels and windows, are implemented in configurable classes. New classes are easily derived from existing ones. This object-oriented approach reduces the effort required for changing existing HMI elements to such an extent that prototyping becomes feasible, complying with the evolutionary approach. The controllers appreciated this. Currently, the HMI package measures 42 KLOC including predefined radar displays like the display discussed above. About 4 KLOC (i.e. 10%) was necessary to implement the specific changes and additions of the second case study. The second prototype’s solution advisory algorithm takes 11 KLOC. This compares preferably with the 196 KLOC size of the HMI development mentioned in the previous case, supporting the conclusion that the evolutionary approach combined with object-oriented software design are preferable for human-centred system design.

The object-oriented software package is sufficiently robust. In six years of operation involving well over 1 year of continuous use, this package has never crashed, significantly outperforming the previous HMI. As simulation can be used for verification (Madson 2004) and is recognised by DO-278 for accumulating service experience, it is relevant use. The software’s use in 24 projects, each with different displays, even increases the chance of encountering problems with respect to a single operational display with standardised operational use. This reliability record exceeds the sufficiency requirements and meets the relevance requirements DO-278 imposes on service experience for assurance level 3 COTS, vindicating the use of object oriented technology for use in operational software with the intended safety classification levels.

3.5 Conclusions

This paper analysed the application of human-centred design in two large case studies in the field of air traffic management. This is an example of a domain in which complex interactive systems are used to increase capacity while maintaining high safety levels. In this and many other situations full automation is not feasible: the human operator remains essential for his or her flexibility and problem solving skills for unforeseen situations. However accident investigations in such domains show that the human operator is a contributing factor to a majority of the rare


accidents. As the operator interacts with the system, the design of this system plays a significant role. Traditionally a technology-centred design approach (i.e. to add a tool at a time) is often used. Accident investigations and capacity limitations for the case study domain reveal that current systems reach the limits of such a technology-centred approach.

The two related case studies demonstrate that the presented human-centred approach offers a viable alternative. Human experts approve the human-centred design. Simulations show that the required capacity and safety levels can be delivered. The case studies indicate that human-centred design could be beneficial for other domains where complex systems combine skilled humans and computers.

Some pitfalls of human-centred design were also encountered and analysed. As the observed artefacts show, the human-centred approach has to be implemented very rigorously to obtain full benefits. In addition, the experience from the case studies suggests that the classical waterfall model of software development does not match the needs of human-centred design. Instead the evolutionary software development model, which has the benefit of allowing early involvement of human (factors) experts, suits the needs of a human-centred design much better.

Analysis of the software development methods in the case studies also shows that object-oriented software design performs better then functional methods and can comply with COTS-based safety certification requirements.

System level certification of the HMI, as proposed for aircraft, seems beneficial in other domains as well. Future work needs to determine whether the benefits of such certification warrant the additional costs, especially for existing work suites. Also the influence of certification on responsiveness is subject to future work.

University of Groningen Safety is no accident Kesseler, Ernstaccidents (NASA 2004), (Kebabjian...

Documents

Transcript of University of Groningen Safety is no accident Kesseler, Ernstaccidents (NASA 2004), (Kebabjian...