MAXIMISING THE ATM POSITIVE CONTRIBUTION TO SAFETY - A

Transcription

1 MAXIMISING THE ATM POSITIVE CONTRIBUTION TO SAFETY - A BROADER APPROACH TO SAFETY ASSESSMENT D Fowler*, E Perrin R Pierce * EUROCONTROL, France, derek.fowler.ext@ eurocontrol.int EUROCONTROL, France, eric.perrin@eurocontrol.int EUROCONTROL, France, ron.pierce.ext@ eurocontrol.int Keywords: safety assessment, safety case, assurance, SESAR Abstract The paper explains why a new approach, both broader and more rigorous than that traditionally followed in ATM, is needed for the safety assessment of the major operational and technology changes such as those planned for introduction into European ATM over the period up to 2020 and beyond, under the SESAR Programme. It presents the theoretical basis for what is an argument-driven systems-engineering approach. A related paper describes how that approach is being trialled on the preparatory work for the safety assessment of the SESAR Operational Concept. 1 Introduction European airspace is fragmented and will become increasingly congested as traffic is forecast to grow steadily over the next 15 years or so. ATM services and systems are not sufficiently integrated and are based on overstretched technologies. Therefore, to meet future air traffic needs, the European ATM services must undergo a massive operational change, supported by innovative technologies. SESAR - the Single European Sky ATM Research Programme - is the means of defining, designing and delivering the operational and technological changes necessary to achieve a more efficient, better integrated, more cost-effective, safer and more environmentally sustainable European ATM infrastructure by the year In support of the SESAR Definition Phase, EUROCONTROL has been developing a methodology for the a priori safety assessment of SESAR encompassing the initial Operational Concept definition, design and implementation of the end-toend ATM system, transition into operational service, and eventually the in-service phase itself. The initial work, closely related to European Commission s Episode 3 (EP3), project, is aimed at laying the foundations of the safety-assessment processes and methods, and gathering initial results from trialling those processes and methods. The specific requirements that the safety assessment has to satisfy are as follows: it must be soundly based from a theoretical perspective it should be pragmatic and of maximum benefit to SESAR Stakeholders it should make maximum use of, and contribution to, the non-safety work being undertaken on EP3 it must preserve the rigour required of the safetyassessment process itself. Reference [1] explained why the traditional, failure-based approach to safety assessment in European ATM was insufficient for the assessment of new operational concepts, and proposed a broader approach to safety assessment. Reference [2] presents an Integrated Risk Picture (IRP) of the causes of ATM-related accidents, based on analysis of accidents and incidents up to year 2005, and shows how it is being used to predict the effect on the risk of an accident of the future changes to the ATM system, under SESAR. This paper builds on, and integrates the theoretical ideas proposed in [1] and [2] and develops them into what has become an argument-driven, systems-engineering approach to safety assessment. Reference [3] describes how the approach is starting to be applied to the SESAR Operational Concept circa 2020 in line with the SESAR Safety Management Plan [4] and the systems-engineering approach, promulgated by the SESAR Joint Undertaking [5]. 2 Risk Basics We can use the simple example of a car airbag to explain why a safety assessment must consider the positive (risk-reducing) properties of a system as well as its negative (risk-inducing) properties. Clearly, we would want an airbag to have high integrity - ie to operate when it is needed and not to operate when it is not needed. However, we would also want it to be effective (in preventing death / serious injury) when it does operate; this would depend on its size, shape, construction and speed of deployment etc ie on its functional / physical and performance properties. This is illustrated in Figure 1 which shows the risk (to the driver) with and without the airbag ie R U and R A respectively. The safety case for the airbag depends on its saving far more lives / preventing serious injury, when operating as intended (the green, right-to-left arrow) than any

2 deaths / serious injury that might be caused in the event of its failure or spurious operation (the red, left-to-right arrow). 0 Minimumachievable Risk R M ~ 1 / Integrity What we don t want the system to do Risk with Airbag R A Tolerable Risk R T What we want the airbag to do ~ Functionality & Performance Airbag net contribution to driver safety Risk without Airbag R U Risk R Figure 1 Risk Graph for a Car Driver s Airbag. There are a several very important points to note about this: R U has nothing to do with the airbag for this reason, we call it pre-existing risk R M is the theoretical minimum risk that would exist in the complete absence of failure of the airbag it is not zero, because there are some accident scenarios that an airbag simply cannot mitigate against the risk increase (R A - R M ) is caused entirely by failure of the airbag - thus we call it system-generated risk the safety case must show, at least qualitatively, that R A <<R U if we now introduce R T (the maximum, tolerable level of risk) then a most interesting conclusion emerges: the tolerable failure rate of the airbag, the length of the red arrow (R T - R M ), depends on the length of the green arrow (R U -R M ) - ie on how successful the airbag is in reducing the pre-existing risk if, as we desire, (R T - R M ) << (R U - R M ) then the overall risk actually achieved (ie R A ) is much more sensitive to changes in the length of the green arrow (ie to changes in functionality and performance) than to proportionate changes in the length of the red arrow (ie to changes in integrity) 1. The above points also raise some very important questions regarding the origins and use of traditional risk-classification schemes. Indeed, although the IEC [6] concept of necessary risk reduction is captured as (R U R T ) in Figure 1, reference [7] raised some doubts about whether IEC itself makes a clear enough distinction between the positive safety contribution of functionality & performance and the negative contribution of integrity or whether it focuses too much on the latter at the expense of the former. The next section shows how, in the context of ATM at least, both sets of safety properties can be modelled. 1 For ATM, R A is typically 6 to 7 orders of magnitude less than R U! 3 Application to ATM Risk ATM is clearly somewhat wider in scope and complexity than a car airbag but the same, fundamental principle holds good ie its primary purpose is to mitigate pre-existing (aviation) risk. This can be illustrated by expressing the three layers of ATM, described in the ICAO Global ATM Concept [8], in the form of a Barrier Model 2 as shown in Figure 2. Pre-existing Hazards Strategic Conflict Mgt Separation Provision Main ATM Functions Collision Avoidance Safety Nets People, equipment and procedures Providence Accident System System - - generated Hazards Figure 2 Simple ATM Barrier Model It is self evident that aviation (like driving) is inherently risky! Even for a single aircraft, there are risks of uncontrolled and controlled flight in terrain. For multiple aircraft in the airspace, there are additional risks of mid-air collision and collision between aircraft on the ground. These risks (or hazards) are inherent in aviation and therefore can be considered as pre-existing as far as ATM is concerned thus they form the main input to the model. The barriers act in rough sequence from left to right and progressively filter out a proportion of the pre-existing hazards, as follows: Strategic Conflict Management, is the first layer ATM and is achieved through airspace organization and management, demand and capacity balancing, and traffic synchronization Separation Provision, is the tactical process of keeping aircraft away from each other, from severe weather and from ground obstacles / terrain, by at least the appropriate separation minima Collision Avoidance must activate when (and only when) Separation Provision has been compromised. The fourth barrier reflects the point that, even when all three layers of ATM have failed to remove a hazard, there is usually high a probability that an actual accident will not result. As the main barriers are provided by the elements of the ATM system, it is the ATM system functionality and performance that determines the effectiveness of the barriers in removing 2 Adapted from Prof James Reason s Swiss Cheese model see

3 the pre-existing hazards. Of course, elements of the ATM system can fail or operate spuriously / incorrectly, giving rise to system-generated hazards, as defined above these are shown in Figure 2 as inputs to the bottom of the model. To paraphrase the SESAR Concept [9], ATM must: maximize its contribution to aviation safety and minimize its contribution to the risk of an accident. In [1], these were referred to respectively as the success and failure approach. It was also emphasized therein that traditional ATM safety assessments had usually assumed the former and focussed almost entirely on the latter. This can be expressed in terms of a risk graph, as in Figure 3. Strategic Conflict Mgt Separation Provision Collision Avoidance Providence 0 Tolerable Risk R A R U Pre-existing Risk R U Figure 3 ATM Risk Graph High Level Risk R What is crucial about Figure 3 is that, in order to show that ATM achieves a tolerable level of risk overall, we need to understand the relationship between pre-existing risk (R U ), the positive and negative contribution of the three ATM Barriers, and the positive contribution of Providence 3. To demonstrate this quantitatively, we can combine the characteristics of the Barrier Model and Risk Graph as a single (unconventional!) Fault Tree, as illustrated in Figure 4. This Fault Tree allows us to compute the risk of an accident (R A ) from: the pre-existing, aviation hazards (and their frequencies F U ); the probability of success (P Sn ) of each barrier in removing those hazards; and the frequency (F Fn ) with which failure of each barrier introduces new hazards. Alternatively, of course, if we make the top-level risk our target (R T ) then, given F U and access to historical accident and incident data, we can make informed judgements about what P Sn and frequency F Fn are required to be in order to satisfy R T. This risk model lies at the heart of the integration of IRP accident model into the a priori safety assessment. 3 Providence is unique in that it cannot make a negative contribution ie it cannot introduce new risk R U Accident & OR & OR & OR & R A Pre-existing Hazards 1-P S4 F F3 1-P S3 F F2 1-P S2 F F1 1-P S1 F u Providence Collision Avoidance Separation Provision Strategic Conflict Mgt System System - - generated Hazards Figure 4 Fault Tree Version of Barrier Model In practice, IRP uses a more detailed Barrier Model than the one described above - it exists in both current-atm and post versions, as described in [2]. 4 Safety Cases Safety assessments are often done within the context of a safety case 4 which, like a legal case, comprises a set of arguments which claim that something is true (or false), together with evidence to show that the arguments are valid. Safety arguments are normally set out hierarchically such that any particular argument statement is valid only if all of the next-level arguments are themselves valid this is shown, using goal-structuring notation (GSN), in Figure 5. Cr001 <<Safe is defined by Safety Targets>> A0001 <<Assumptions to be declared and validated in the Safety Case>> Arg 1 <<Argument that <A> is true>> Arg 2 <<Argument that <B> is true>> Arg 0 <<Claim that something is safe>> <<Strategy to explain the rationale for decomposing Arg 0>> Arg 3 <<Argument that <C> is true>> C001 Applies to <<Operational Environment>> J0001 <<Justification for the subject of the Claim>> Arg 4 <<Argument that <D> is true>> Figure 5 Generic High-level Safety Argument GSN is simply a graphical representation of an argument / evidence structure. In safety work it will usually start with the claim (Arg 0) that something is (or will be) safe; this is then decomposed such that it is true if Arg 1 to 4 are all true. 4 This is consistent with the SESAR Safety Management Plan and European Operational Concept Validation Methodology, (E-OCVM) both of which take a case-based approach

4 The strategy text should explain the rationale for the decomposition. The claim is supported by vital contextual information: what is meant by safe is defined by means of safety targets, which may be quantitative and / or qualitative the context for the claim must include a description of the operational environment for which the claim is being made; section 6.1 below explains how critical this is to the validity of the claim assumptions are usually facts on which the claim depends and over which the organisation responsible for the safety case has no managerial influence - eg traffic will increase by x% per year if the claim relates to a major change to a safety-related system, it is good practice to provide a justification for that change - eg increased capacity. The arguments would then be further sub-divided until a level is reached at which a piece of documented evidence, of a manageable size, could be produced to show that the corresponding argument is valid. Further guidance on constructing ATM safety arguments is given in [10]. 5 Safety Assurance There, however, are two problems with the simple argument / evidence approach. The first is that, in itself, it gives no indication as to how the evidence should be obtained or how rigorous that evidence needs to be. As illustrated in Figure 6, this problem is addressed by bridging the lowest level of decomposition of argument and its supporting evidence with: safety assurance objectives, which state what has to be done to satisfy the related strand of the argument, and safety assurance activities which state how the safety assurance objectives will be satisfied including the tools and techniques etc to be used. we needed to show in turn that each objective has been met and eventually, therefore, that the safety argument is satisfied. In many assurance-based approaches, the objectives and activities are, to some degree and extent, determined by an assigned assurance level (AL) these ALs are usually derived by assessing the consequences of failure of the system element under consideration. There is a second, related problem that safety assurance is often used to address ie the fact that the integrity of software functions or human tasks, in particular, is very difficult to show in a direct way (eg through analysis of test results) that such safety requirements have been m in implementation. This is reflected in, for example, airborne software standard DOD 178B [11] and system / software standard IEC [5] both of which are assurance based. EUROCONTROL itself has adopted such an approach [12] in the safety assessment of the individual software, procedure and (under development) human elements of ATM systems - however, the application to the overall ATM system, as described herein, is new. The next question is how to develop a sound safety argument and introduce good systems-engineering practice, to achieve a truly argument-driven, systems-engineering approach. 6 Developing the Approach 6.1 A Requirements-engineering Model Capturing a complete and correct set of requirements is as fundamental to any system development as it is to any a priori safety assessment. For SESAR, we have adopted the simple, but rigorous, requirements-engineering (RE) model, adapted from [13], shown in Figure 7. D Real World' S Specification S P, S R User Reqts R Safety Argument To satisfy Design D I D System i/f Application Domain Objectives Assurance Level (AL) To give confidence To achieve Activities To produce Evidence Figure 6 Safety Assurance Structure The output of the assurance activities is then the evidence that Implementation I Domain Properties P Figure 7 Requirements-engineering Model In this model, systems exist in the real world. The part of the real world that influences the system, and into which the system provides a service, is known as the application domain. Users of the service exist in the application domain. The system interacts with the application domain through an interface (i/f). User requirements are what the Users want to have happen in

5 the application domain and are therefore defined in that domain - not in the system. A specification is what the system has to do across the interface in order that the user requirements can be satisfied - ie a specification takes a black-box view of the system. Design describes what the system itself is actually like and includes all those characteristics that are not directly required by the users but are implicitly necessary in order for the system to fulfil its specification and thereby satisfy the user requirements. Design is essentially an internal, or whitebox, view of the system and the next relationship that has to be satisfied, therefore, is that the design D satisfies the specification S. Implementation covers the detailed design and build of the physical system. The formal notation in the bubbles in Figure 7 above define three relationships that are crucial to the successful development of a system, as follows: the specification S satisfies the user requirements R only for a given set of properties P of the application domain; if any one of these three sets of parameters is changed then requirements-satisfaction relationship might be invalidated until one or both of the other sets is also changed, in compensation the design D satisfies the specification S the implementation I satisfies the design D. 6.2 Developing the Safety Argument The distinction, and relationship, between requirements, specifications, domain properties, design and implementation are not merely academic niceties but provide the essential foundations for developing systems that do, and can be shown to do, everything required of them. Specifically, from a safety perspective, the formal nature of the relationships makes them eminently suitable for expression as a rigorous high-level safety argument ie that: Arg 1 - the system has been specified to be safe Arg 2 - the system design satisfies the specification Arg 3 - the implementation satisfies the design By adding two further arguments: Arg 4 - the transition from current system to the new (or modified) system will be safe Arg 5 - the system will be shown to operate safely throughout its service life we have, at that level, a complete safety argument for a new or modified system. From this outline, we get a typical high-level safety argument for SESAR as shown in Figure 8, using the En-route phase of flight as an example. Cr001 Acceptably safe is defined by the Safety Targets see Arg 1.1 A0001 Assumptions as per section 8.1 of the PSC Arg 1 ATM system has been specified to be acceptably safe Figure 12 Arg 2 ATM system has been designed to be acceptably safe Figure 14 Arg 0 Operations will be acceptably safe. Argue on basis of a safe Specification and Logical Design, full Implementation of that design, safe Transition into service and Safety Monitoring for whole operational service life Arg 3 ATM system Design has been implemented completely & correctly Arg 4 Transition from current state to full SESAR Enroute ATM system will be acceptably safe C001 Applies to the Operational Environment described in Section 2 of the En-route Safety Design Document J0001 Justification as per Section 2.2 of the PSC Arg 5 ATM system will be shown to operate acceptably safely throughout its service Figure 8 - High-level Safety Argument Operations The top-level Claim (Arg 0) is that En-route operations for the specified Operational Environment (C001) will be acceptably safe, as defined by the Safety Targets (Cr001) to be derived for each phase of flight. A key Assumption at this initial stage might be that SESAR will deliver by 2020 a 1.7-fold increase in capacity and that this will be fully taken up by a corresponding increase in traffic levels 5. The Justification for SESAR stems from its benefits to the airspace users, including improvements in the capacity, costeffectiveness, efficiency, environmental sustainability, and flexibility of the overall ATM service. Specific justification for each phase of flight must be set out in the related Preliminary Safety Case Report. The claim is then decomposed into the principal Safety Arguments shown, the decomposition being the five-part argument structure derived in section 6.2 above. Arguments 3 to 5 reflect normal ATM safety practice and are the responsibility mainly of the stakeholders involved in the implementation of the SESAR Concept (Arg 3) and subsequent SESAR-based operations (Arg 4 and 5). However, it is important to note that Arguments 1 and 2 apply to the whole SESAR Concept as applicable circa 2020; therefore, because the SESAR Concept is being implemented in stages, the term transition in Argument 4 includes the safety of each stage of this phased deployment of the end system, taking account also of the fact that developments in adjacent airspace may be being deployed in a different sequence and/or to 5 This is the worst case because increasing traffic has an inherent linear or square-law negative affect on safety (depending on the type of accident being considered) for which improvements in the ATM system must compensate

6 different timescales it is part of the initial planning work to consider how to address that problem. The above is now put into the context of the development lifecycle in section Lifecycle Considerations Although argument-driven, the safety-assessment approach must include a process that is to be followed through the project development lifecycle. Arg 0 Arg 5 Arg 4 Arg 3 Arg 2 Arg 1 Lower-level Safety Arguments System Safety Assurance Activities Definition Design & Validation (High-level) Implementation & Integration Transfer into Operation Operation & Maintenance Evidence Arg 1 Arg 2 Arg 3 Arg 4 Arg 5 Figure 9 - Overall Safety Lifecycle Process This is illustrated, at the highest level, in Figure 9, which is intended to show that each of the five development-lifecycle stages comprises Safety Assurance Activities which are determined by a related Safety Argument and which produce Evidence that the Argument has been satisfied 6. The key point about this diagram is that it must be needs of the argument (ie the generation of evidence) that drive the processes and not the other way around. In other words, it is not the process that determines the argument; rather the argument must be directly about the product for which the argument is being made, and the lifecycle process contains only those activities that are necessary to support this, productbased argument. The proposed application of this model to the Definition and Design & Validation phases of the SESAR lifecycle is described in [3]. 6 The omission of safety assurance objectives from Figure 9 is deliberate we have found that when safety assurance is put into an argument / evidence framework, the objectives are best subsumed into the lowest levels of the safety argument. Arg 0 Conclusions The work that is the subject of this paper was initiated by concerns that, in the past, safety in ATM has been considered to be synonymous with integrity and that, consequently, safety assessments have often been far too narrow in their scope. This has become evident on a number of recent safety assessments by commissioned by EUROCONTROL and most vividly during the preparatory safety work on the huge SESAR ATM-development programme. EUROCONTROL has therefore developed, and is applying, a much broader, argument-driven, systems-engineering approach to safety assessment, the theoretical basis for which is described in this paper. The planned application to SESAR, as promulgated by the SESAR Joint Undertaking [5] is described in a sister paper [3] being presented at the same conference. References [1] Fowler D, Grand-Perret S, Penetrating the Fog of Safety Assessment (and vice versa), Proceedings of the 2 nd IET International Conference on System Safety, London, October 2007 [2] E Perrin, B Kirwan, Predicting the Future: The Integrated Risk Picture, Proceedings of the 4th IET International Conference on System Safety, London, October 2009 [3] Fowler D, Perrin E, Pierce R, 2020 Foresight - A systemsengineering approach to assessing the safety of the SESAR Operational Concept, Proceedings of the Eighth USA/Europe Air Traffic Management Research and Development Seminar (ATM2009), Napa (California), July 2009 [4] SESAR Definition Phase, Task Deliverable: 4.2.1/D6 Safety Management Plan - WP4.2.1 System Engineering Development & Validation Process, April 2008 [5] SESAR JU, SESAR System Engineering Management Plan Part I, April 2009 [6] IEC, Functional Safety of Electrical/electronic[etc] Safety Related Systems, IEC 61508, 2000 edition [7] Fowler D, Bennett PA, IEC a Suitable Basis for the Certification of Safety-Critical Transport- Infrastructure Systems??, Proceedings of 19 th International Conference of Computer Safety, Reliability and Security (Safecomp 2000), Rotterdam, October 2000 [8] ICAO Doc 9854, Global ATM Operational Concept, 1st edition, 2005 [9] SESAR Consortium, the ATM Deployment Sequence, D4, DLM , January 2008 [10] EUROCONTROL, Safety Case Development Manual, version 2.2, 2006 [11] RTCA, Software Considerations in Airborne Systems and Equipment Certification, DO-178B / ED-12B [12] Mana P, De Rede J-M et al, Assurance Levels for ATM System Elements: Human, Operational Procedure, and Software, proceedings of the 2 nd IET International Conference on System Safety, London, October 2007 [13] Jackson M, The World and the Machine, Proceedings of 17 th International Conference on Software Engineering, IEEE, pp , 1995

7

8