Click here to proceed.

1
Success Failure Cases

• SAMTF Meeting, Toulouse
• 4 May 2006
• Derek Fowler, EUROCONTROL DAP/SAF

2
Topics

• Why we need success and failure cases
• examples from EATM
• Risk reduction
• the role of ATM
• ATM Barrier Model
• how ATM reduces risk
• application to the EATM examples
• Effect on safety-assessment processes
• same processes, different viewpoints??

3
Why ??

• Traditionally, ATM safety assessments often
  focused on failure
• origins in SAE standard ARP 4754
• FHA considers Hazards but from what??
• Safety Requirements often thought of only in
  terms of integrity failure of XXX shall not
  occur more often than highly improbable
• Does this fully reflect the role of ATM in
  aviation safety??
• What about functionality and performance of ATM
  systems??

Danger of introducing reliably unsafe systems??
4
Current Examples of the Problem

• How do we demonstrate the safety of the
  following??
• TCAS RA Downlink (FARADS)
• safety only integrity of the Downlink??
• how do we know that the basic RA Downlink concept
  is intrinsically safe??
• ATC Tools (FASTI)
• safety only integrity of the tools (MTCD, MONA,
  TP, SYSCO)??
• does automation necessarily improve safety??
• STCA (SPIN)??
• safety only integrity of the STCA software??
• what about context of use

All of the above are required to deliver a net
safety benefit!!
5
Automation or Not ?!!

• It is often stated that, in ATM, around 90 of
  accident / serious incidents are caused by human
  error and only 10 by equipment failure
• Logically, therefore, increased automation would
  lead to a decrease in the number of accidents /
  serious incidents
• Is that true??

Clue - we also need to look from the success
viewpoint
6
A Hypothetical Example

• Let's assume, historically, that in ECAC
  airspace
• 100 accidents / serious incidents were caused a
  year by ATC
• 10,000 accidents / serious incidents were
  prevented a year by ATC (a very conservative
  estimate)
• Lets also assume that, of these, 5,000 were
  prevented tactically
• STCA can detect, in a timely way, a maximum of
  about 65 of the conflicts that it is presented
  with
• This means that 94 must have been detected by
  Tactical Controller
• Given such performance, the accident / incident
  rate would increase from the current 100 (with
  STCA) to
• 376 if we removed STCA
• 1760 if we removed the Tactical Controller!!

7
The Argument for Automation

• Must take account of the relative performance of
  the human and machine in both
• causing / not preventing accidents
• and
• preventing accidents
• Is dependent on
• the tolerable accident rate
• compared with
• the number of accident-prevention opportunities

The higher the opportunity / accident ratio, the
weaker the argument for the lesser functionality
performance option
8
Risk Reduction - General
Unmitigated Risk
RU
Functionality Performance

1/Integrity
0
Risk R
We dont necessarily need to know RU
9
ATM Barrier Model General
Strategic Conflict Management
Separation Provision
ATM System Boundary
Collision Avoidance
Demand - traffic volume / pattern
Potential Conflicts
Procedural De-confliction
Flow Capacity Management
Conflict Avoidance
ATC Tactical De-confliction
Airspace Design
Pilot Recovery
Providence
ATC Recovery
Conflict Prevention
Recovery
Conflict Resolution
Overload Protection
10
ATM Barrier Model FARADS
Strategic Conflict Management
Separation Provision
ATM System Boundary
Collision Avoidance
Demand - traffic volume / pattern
Potential Conflicts
Procedural De-confliction
Flow Capacity Management
Conflict Avoidance
ATC Tactical De-confliction
Airspace Design
Pilot Recovery
Providence
ATC Recovery
?
Conflict Resolution
Conflict Prevention
Recovery
Overload Protection
?
11
ATM Barrier Model STCA
Strategic Conflict Management
Separation Provision
ATM System Boundary
Collision Avoidance
Demand - traffic volume / pattern
Potential Conflicts
Procedural De-confliction
Flow Capacity Management
Conflict Avoidance
ATC Tactical De-confliction
Airspace Design
Pilot Recovery
Providence
ATC Recovery
Conflict Prevention
Recovery
Conflict Resolution
Overload Protection
or
12
ATM Barrier Model FASTI
Strategic Conflict Management
Separation Provision
ATM System Boundary
Collision Avoidance
Demand - traffic volume / pattern
Potential Conflicts
Procedural De-confliction
Flow Capacity Management
Conflict Avoidance
ATC Tactical De-confliction
Airspace Design
Pilot Recovery
Providence
ATC Recovery
Conflict Prevention
Recovery
Conflict Resolution
Overload Protection
13
ATM Barrier Model FASTI (Safety Benefit)
Strategic Conflict Management
Separation Provision
ATM System Boundary
Collision Avoidance
Demand - traffic volume / pattern
Potential Conflicts
Procedural De-confliction
Flow Capacity Management
Conflict Avoidance
ATC Tactical De-confliction
Airspace Design
Pilot Recovery
Providence
ATC Recovery
Conflict Prevention
Recovery
Conflict Resolution
Overload Protection
14
ATM Barrier Model FASTI (Capacity Benefit)
15
Success Failure Cases

• Process

16
Success and Failure - Considerations
17
Safety Requirements Specification - Process
Operational Concept
Change Assessment
FHA/PSSA
Risk-reduction Assessment
Fault-condition Assessment
Specification / Design Critique
Hazard Mitigations
Functional Safety Requirements
Safety Integrity Requirements
Hazard Mitigations
Technology review
Equipment Functions
Validation
Human Tasks
Task Analysis
Validation
HRA
ALs
Expansion and Validation
18
Success Case

• What we need in terms of, for example
• Functionality what has to be done to reduce risk
• Data what is needed (input)
• Sensitivity eg probability of detection v false
  alarm rate
• Accuracy of output
• Timeliness of response to external events
• Capacity eg traffic throughput, instantaneous
  load
• Identified by
• Expert operational input Concept of Operations
• Validated by
• Independent review
• Simulation
• Trials and previous operational experience

19
Failure Case HAZID

• Consider deficiencies in Specification / Design,
  eg
• Functionality missing or wrong
• Timing problems input and output
• Robustness response to / effect of external
  failures
• Overload temporary and prolonged
• Coherency possible dysfunctional interactions
  between elements of the system
• Consider internal Fault Conditions
• omission (eg detected loss) reduces
  risk-reduction effectiveness
• commission (eg credible corruption) introduces
  new risk
• Asses how the above manifest themselves at the
  system boundary ie as Hazards)

20
Safety Requirements - Overview

• Functional Safety Requirements
• provide the risk-reduction potential of the ATM
  System
• derived initially from hazards risks external
  to the ATM system (ie from Success Case)
• additionally, provide mitigation of failures of
  the ATM system (ie from Failure Case)
• Safety Integrity Requirements
• limit the risk increase caused by failure of the
  ATM System
• derived from hazards risks internal to the ATM
  system (ie from Failure Case)
• control the frequency with which ATM system
  faults / errors occur