safety analysis 安全分析
**** Hidden Message ***** Using human error analysis to help to focus safety analysis in ATM simulations: ASAS Separation<BR>Paper presented at the Human Factors and Ergonomics Society 2004 Conference, Cairns, Australia, 22nd - 25th August, 2004.<BR>Rachael Gordon1, Steven T. Shorrock2, Simone Pozzi3, Alessandro Boschiero4<BR>1 EUROCONTROL Experimental Centre, Centre de Bois des Bordes, BP 15, F-91222 Bretigny sur Orge, CEDEX, France, <A href="mailto:rachael.gordon@eurocontrol.int">rachael.gordon@eurocontrol.int</A><BR>2 The University of New South Wales, Department of Aviation, Sydney, NSW, 2032, Australia, <A href="mailto:s.shorrock@unsw.edu.au">s.shorrock@unsw.edu.au</A><BR>3 University of Siena, Department of Communication Science, Via dei Termini 6, 53100 Siena, Italy, <A href="mailto:pozzi@media.unisi.it">pozzi@media.unisi.it</A><BR>4 SICTA, Circne Esterna Loc. Pontericcio, 80014 Giugliano in Campania, Napoli, Italy, <A href="mailto:aboschiero@sicta.it">aboschiero@sicta.it</A><BR>Abstract<BR>This paper describes the process used to analyse HF and safety issues in a new Air Traffic Management (ATM) procedure – the Mediterranean Free Flight (MFF) Airborne Separation Assurance System (ASAS) applications. The paper describes: 1) the overall safety assessment process in MFF; 2) the human error analysis (HEA) method called TRACEr-lite; 3) the process of developing safety scenarios for simulations; and 4) the lessons learnt from the simulations using safety scenarios. By simulating hazardous events in ground-based simulations, it was possible to gain a greater understanding of the hazards in general, how hazards are detected and possible mitigation by discussing the issues with the air traffic controllers in debriefing sessions.<BR>1. Introduction<BR>Mediterranean Free Flight (MFF) is a project initiated by ENAV (Italian Air Traffic Service provider) to study the issues regarding the implementation of free flight concepts over the Mediterranean area. The main objectives of MFF are to provide technical and operational evaluation of integration, interoperability and safe use of communications/ navigation/surveillance (CNS) / Air Traffic Management (ATM) technologies and applications suitable for future Mediterranean ATM. Airborne Separation Assurance System (ASAS) is an aircraft system based on airborne surveillance that provides assistance to the flight crew supporting the separation of their aircraft from other aircraft. One part of this project is the concept of delegating the task of separation assurance of one aircraft from another from the controller to the flight deck as a<BR>possible means of alleviating the controller workload by a more efficient distribution of tasks.<BR>To complement traditional safety analysis methods, a specific human error analysis (HEA) was undertaken using TRACEr-lite (Shorrock, 2002, 2003; FAA, 2004) to identify the pertinent hazards to be reproduced and analysed during a real-time simulation. The process of task analysis, HEA, scenario design, and the hazard analysis of is described in Figure 1.<BR>Figure 1. Process to assess the hazards in the MFF ASAS Separation procedure Task AnalysisOperationError Analysis:Pilot and ATCOerrorsScenario DesignObservationFurtherAnalysisProcedure13:09 Near EVIRA, SYR354 in-trail MSR7344 to OTREX(subject level change)13:15 RFR7400 selects MSR7344 instead of SYR354 (subjectthe chain 'bundled up') in-trail to OTREXPilot (delegated) selects ŌtargetÕ on CDTIInserted error: Pilot (delegated) selects a wrong ŌtargetÕ (pilotread-back/onboard input incorrect)Observed error: ATCO does not detect wrong ŌtargetÕ read-backATCO does not detect wrong target read-back, does not askfor the clock-position, instructs ASAS separation manoeuvre;then STCA alertDetection: System alert (STCA)Other detection means: Pilot clock-positionFactors contributing: difficult to understand SSR code (pilot &ATCO); pilot responsibility for separation; no a/c clock-positionMade situation worse: surrounding traffic densitySeverity level: (detected) 3 (not detected) 1Fallback Actions: automatic downlink of a/c data (identifiedtarget) through data-link from ac CDTI to ATCO workingpositionDescribes the information in the debriefing in more detail andwith explanationsInitiate Execution PhaseAnalysis:Debriefing<BR>The remaining sections will describe the process and findings of the HEA, simulation of safety scenarios, and the lessons learned.<BR>2. Human error analysis<BR>The objective of the HEA was to identify potential controller and pilot errors that could occur during an ASAS Procedure, the associated consequences and detections means, and measures to prevent, reduce or mitigate the critical errors. Some of the errors identified would be used to inform safety scenarios for simulations.<BR>TRACEr-lite utilises a task analysis and an error classification system to probe potential errors and their psychological and contextual origins. After scoping the tasks to be analysed, Hierarchical Task Analysis (HTA) was used. HTA represents tasks in terms of hierarchies of goals and operations, using plans to show when these need to be carried out. Tasks are redescribed into increasingly detailed sub-tasks. The initial HTA was constructed using draft procedures and discussions with procedure experts. Three phases of ASAS separation were considered: 1) initialisation of the ASAS procedure; 2) execution of the ASAS procedure; 3) completion of the ASAS procedure. The resulting HTA of controller and pilot tasks was used as a basis for the HEA.<BR>TRACEr-lite was derived from TRACEr – Technique for the Retrospective and Predictive Analysis of Cognitive Error (Shorrock, 2003; Shorrock and Kirwan, 2002). Using TRACEr-lite predictively, the analyst works through a task analysis using a series of prompts to determine what could go wrong. While the majority of the analysis was performed by two analysts, the mid-level HTA tasks were interrogated with two controllers and two pilots to ensure a more participative and holistic analysis.<BR>The first stage of the TRACEr-lite process sets the context of the tasks to be analysed by reference to a set of performance shaping factors (PSFs); factors internal to the controller or pilot, or relating to the task and operational environment, that affect performance positively or negatively. The second stage identifies observable manifestations of potential errors, called external error modes (EEMs). The EEMs were identified at each lowest-level operation in the HTA, and then applied to higher-level tasks. The third stage involves analysing the likely cognitive aspects of the errors predicted using a set of internal error modes (IEMs) structured around four ‘error domains’ (perception, memory, decision and action) and one ‘violation domain’. IEMs (e.g. mis-see, mis-hear) describe how the controller’s/pilot’s performance failed to achieve the desired result. The likely initial consequences are determined and, along with the context and type of error, used to consider how the controller or pilot might detect the errors. The analyst rates the ‘recovery success likelihood’ (RSL), a 5-point likelihood of recovering the task successfully without adverse consequences. Finally, comments or recommendations may be recorded.<BR>A total of 398 errors were identified, and 383 were rated with regard to their RSL. Approximately 17% of the errors were rated as difficult to<BR>detect (i.e. low or low-medium RSL). Errors associated with the three phases of the ASAS Separation procedure (initialisation, execution and completion) were identified. The initialisation and completion phases were primarily associated with controller errors, while the execution phase was primarily associated with pilot errors. Those errors that were considered difficult or moderately difficult to detect, diagnose or correct were considered further, and a manageable number of key issues to be addressed were derived. In this study, a meeting was held with 13 stakeholders to review recommendations and derive additional recommendations.<BR>3. Simulating air traffic controllers and pilot errors<BR>The objective of simulating potential hazards was further to investigate the characteristics of the hazards, in particular to assess the:<BR>• robustness of the procedures in preventing errors,<BR>• criticality of the consequences in case the error goes unnoticed,<BR>• hazard credibility,<BR>• hazard severity, related to its most severe possible consequences,<BR>• recovery capability of the controller, and<BR>• mitigation measures and fall-back procedures.<BR>A scenario describes an operational situation by identifying the actors, operations, tools and procedures. To create scenarios in a real-time simulation, specific ‘hazardous’ conditions are inserted into a traffic sample to observe how controllers manage the situation. Hazardous situations were recreated using some of the human errors identified in the HEA. It was only possible to simulate a small number of hazards. Thus the hazards selected included errors that had ‘low’ or ‘medium-low’ RSL ratings errors, and which could be made (deliberately) by the pseudo-pilots, as well as generic hazards such as bad weather. The scenarios were defined by simulation and operational experts on the basis of a detailed description of the hazards, then reviewed by safety experts and HF experts. Most of the scenarios required fine-tuning during the simulation. The hazards were recreated during the simulation using three methods: 1) manipulation of the traffic samples; 2) collaboration with the pseudo-pilots; and, in a few cases, 3) controllers were asked to make deliberate errors to assess how other controllers would react (e.g. Figure 1).<BR>Observation and data collection were undertaken using data recording forms and video recording. Data were also collected and analysed through: 1) meetings between safety observers and HF experts; 2) analyses of safety reports and questionnaires produced by controllers; 3) brainstorming sessions between controllers and safety observers; and 4) debriefings with controllers. For each simulation exercise, three forms were produced: 1) a scenario sheet that described the scenario, the aircraft callsigns involved, and the estimated time the event would occur; 2) an observation sheet to help safety, HF and operational expert observers take note of events that<BR>occurred; 3) a debriefing sheet which included questions regarding the scenario and event (i.e. development, detection, causes, worst credible consequences and severity, potential developments, frequency, mitigation).<BR>The hazard conditions and their evolution were observed during the simulation and analysed collaboratively by the task domain personnel and experts. In addition, the spontaneous occurrence of other safety-relevant events during the simulation was monitored and recorded. Subjective feedback provided by controllers or collected in questionnaires and debriefing sessions was analysed to identify additional hazards.<BR>The analysis was conducted in three phases. First, the events observed during the simulation were categorized into 11 groups of hazards. Second, information about the 11 hazards was compiled regarding detection possibilities, severity levels, causal factors, possible consequences and fallback actions. Third, a discussion of each hazard was conducted to analyse causes, consequences, ease and means of detection, severity, and the proposed mitigation measures. The overall safety activity consisted in a set of safety-oriented scenarios, 40 hazardous occurrence debriefing sheets filled in by safety observers, 28 debriefing sessions and one final brainstorming session with all controllers.<BR>4. Lessons learned<BR>This section details the benefits and limitations of this methodology.<BR>• The role of safety within the experimental process – a small number of dedicated safety objectives were devised to enable a more focused simulation. Some of the objectives were general (e.g. to discover possible additional hazards) and some were specific (e.g. to determine the severity of identified hazards).<BR>• Simulation fidelity – the scenarios increased the simulation. However, including too many hazards within each simulation exercise can make controllers lose confidence in the tools, abandon the tools or to lose confidence in their own ability. The simulation utilised pseudo-pilots instead of real pilots, and a limited pseudo-pilot HMI was used (e.g. no CDTI, no information about surrounding traffic) with consequent effects on pilot behaviour (e.g. acceptance of very large deviations).<BR>• Training – controllers were provided with limited safety training. This was probably not sufficient to homogenise safety perceptions due to the differences in countries, working practices and attitudes.<BR>• Simulation safety scenario design process – the hazards were taken largely from the HEA. This found a large number of potential hazards, but only a very small proportion of these were simulated or observed.<BR>• Safety indicators measured – some of the safety indicators were difficult to determine during the debriefing sessions. The controllers could easily determine whether the hazard was credible, but ‘worst probable severity’ was more difficult to envisage. However, controllers were able to<BR>predict how easily the hazards could be detected and corrected. Controllers also tended to think about hazards in combination.<BR>• Data collection methods – it was difficult to obtain all the information required about the hazards during the debriefing sessions. This could have been due to discrepancies in the observer’s and controller’s understandings. These problems could be reduced if more time was given to incident review prior to debriefing, e.g. using ‘replay’ tools.<BR>• Analysis strategies – the results from the simulation were based on the analysis of the observations, debriefs, discussions and questionnaires. Quantitative analysis of specific safety hazards was not possible. Given the described aims and approach the data collected have no statistical value but are intended to assist hazard identification and analysis.<BR>• Controller involvement – the safety scenarios provided information that was qualitative but rich in nature, tapped the controllers’ experience and involved controllers in the safety analysis. One outcome was that many scenarios did not eventuate due to the controllers’ ability to change the ‘expected’ route of the aircraft.<BR>5. Conclusion<BR>This paper demonstrates how data from an analyst-led HEA was used in simulations to assess safety issues. The safety scenarios provided information for the update of the MFF Safety Assessment, especially with regard to the description of causes, detection means, fallback procedures, context, consequences, severity and proposed mitigation means.<BR>Acknowledgments<BR>We would like to thank the controllers who participated in the simulation for their helpful feedback. We thank the MFF HF team based in Rome, and members of the MFF WA7 Safety Team who provided helpful comments on the method and results of the safety work (especially Alberto Pasquini, Deep Blue and Paloma Hidalgo, AENA).<BR>References<BR>Shorrock, S.T. 2003. The Retrospective and Predictive Analysis of Human Error in Air Traffic Control, Doctoral thesis, University of Nottingham.<BR>Shorrock, S.T. 2002. Error classification for safety management: Finding the right approach, Proceedings of a Workshop on the Investigation and Reporting of Incidents and Accidents, 17th to 20th July 2002, The Senate Room, University of Glasgow.<BR>Shorrock, S.T. and Kirwan, B. 2002. The development and application of a human error identification tool for air traffic control, Applied Ergonomics 33, 319-336. 有中文的美？回复 1# 航空 的帖子
谢谢提供！！ 好想要啊11111 看啊看，好使不 的点对点的点对点的点对点的点对点的的的
页:
[1]