MAXIMISING THE ATM POSITIVE CONTRIBUTION TO SAFETY - A BROADER - - PowerPoint PPT Presentation

MAXIMISING THE ATM POSITIVE CONTRIBUTION TO SAFETY - A BROADER APPROACH TO SAFETY ASSESSMENT

Eric PERRIN (speaker) Derek FOWLER Ron PIERCE EUROCONTROL Safety R&D Seminar

München, Germany 21-22 October 2009

even if it were 100% so, would that answer… ADS-B end-to-end system needs to be reliable Separation down to “radar” levels i.e. 5 nm or 3 nm

ADS ADS-

• B IN NON

B IN NON-

• RADAR AREAS

RADAR AREAS – – HOW TO APPROACH SAFETY? HOW TO APPROACH SAFETY?

Radar-like services in NRA using ADS-B whether ADS-B would be safe enough to support 3-5 nm separation…? No! Risk of implementing a perfectly reliable but unsafe ADS-B system

Operational Environment Radar System

Separation Provision Service

Hazards Hazards Hazards Hazards

What we WANT system to do – Functions and Performance What we DON’T want system to do - Integrity Pre- existing System- Generated

ADS ADS-

• B IN NON

B IN NON-

• RADAR AREAS

RADAR AREAS – – HOW TO APPROACH SAFETY? HOW TO APPROACH SAFETY?

“radar” separation minima: accuracy, resolution, refresh rate etc of the surveillance information presented to the ATCO. ADS-B in NRA Good basis for a case: ADS-B can provide the same functionality (i.e. data presented to the Controller / support tools) and performance (data accuracy, resolution, latency, refresh rate, coverage etc) CANNOT CONTINUE TO FOCUS MAINLY ON FAILURE…!!

• Success approach:

– to show that an ATM system will be acceptably safe in the absence

• f failure

– addresses the ATM contribution to aviation safety – defined by Functional Safety Requirements

• Failure approach:

– to show that an ATM system will still be acceptably safe, taking account of the possibility of (infrequent) failure – addresses the ATM contribution to aviation risk – defined by Safety Integrity Requirements

A BROADER APPROACH TO RISK ASSESSMENT AND MITIGATION A BROADER APPROACH TO RISK ASSESSMENT AND MITIGATION

Strategic Conflict Mgt Strategic Conflict Mgt

Pre-existing Hazards Pre Pre-

• existing

existing Hazards Hazards Accident Accident

Collision Avoidance Collision Avoidance Separation Provision Separation Provision Providence Providence

Safety Nets Main ATM Functions People, Equipment, and procedures

System - Generated Hazards System System -

• Generated

Generated Hazards Hazards

ICAO GLOBAL ATM OPERATIONAL CONCEPT 2005 ICAO GLOBAL ATM OPERATIONAL CONCEPT 2005

Risk R Pre-existing Risk RU’ Acceptable Risk RA Separation Provision Collision Avoidance Strategic Conflict Mgt RU’ ‘ RU Providence

ICAO GLOBAL ATM OPERATIONAL CONCEPT ICAO GLOBAL ATM OPERATIONAL CONCEPT – – RISK GRAPH RISK GRAPH

Strategic Conflict Mgt Strategic Conflict Mgt

Pre-existing Hazards Pre-existing Hazards Accident Accident

Collision Avoidance Collision Avoidance Separation Provision Separation Provision Providence Providence

OR

&

OR

&

OR

& &

1-PS1 1-PS2 1-PS3 1-PS4 RA FF2 FF1 System - generated Hazards System - generated Hazards FF3 Fu

FAULT TREE VIEW FAULT TREE VIEW

Enables us to specify success (Pnn) as well as failure (Fnn) attributes

• Safety requirements are specified for ATM to:

– maximize its contribution to aviation safety and – minimize its contribution to the risk of an accident

• Safety Requirements cover, respectively:

– functionality & performance – integrity (plus some additional f&p)

Broader approach = success plus failure cases

SAFETY REQUIREMENTS SAFETY REQUIREMENTS

Arg 0 <<Claim that something is safe>> Arg 1

<<Argument that <A> is true>>

Arg 4

<<Argument that <D> is true>>

Arg 2

<<Argument that <B> is true>>

Arg 3

<<Argument that <C> is true>> C001 Applies to <<Operational Environment>>

A0001

<<Assumptions to be declared and validated in the Safety Case>>

J0001

<<Justification for the subject of the Claim>> [tbd] [tbd] [tbd] <<Strategy to explain the rationale for decomposing Arg 0>> [tbd] Cr001 <<Safe is defined by Safety Targets>>

GENERIC ARGUMENT STRUCTURE GENERIC ARGUMENT STRUCTURE

• How much?
• How obtained?
• How good?

Simple answer is Safety Assurance

EVIDENCE EVIDENCE

Objectives Objectives Activities Activities Evidence Evidence

To produce To achieve To give confidence

Assurance Level (AL)

SAFETY ASSURANCE SAFETY ASSURANCE -

• GENERAL

GENERAL

Safety Argument Safety Argument Safety Activities Safety Activities

To satisfy

Evidence Evidence

To produce To give confidence

Assurance Level (AL)

ARGUMENT-DRIVEN SAFETY ASSURANCE

To achieve

But how do we develop a satisfactory Safety Argument?

Application Domain System i/f

User Reqts R Design D Specification S Domain Properties P

P, S R

Implementation I

Real World

D S I D

WE USE A REQUIREMENTS WE USE A REQUIREMENTS-

• ENGINEERING MODEL!

ENGINEERING MODEL!

ATM System i/f

Design D

P, S T

Implementation I

Aviation World

D S I D

Safety Targets T ATM Service-level Specification S ATM User Domain Properties P

ATM User Domain

This leads initially to ………….

AN ATM SAFETY VERSION AN ATM SAFETY VERSION

Arg 0 SESAR En-route Operations will be acceptably safe.

Cr001 Acceptably safe is defined by the Safety Targets – see Arg 1.1 Arg 1 SESAR En-route ATM system has been specified to be acceptably safe Arg 5 SESAR En-route ATM system will be shown to

• perate acceptably

safely throughout its service life

Arg 3

SESAR En-route ATM system Design has been implemented completely & correctly Arg 4 Transition from current state to full SESAR En- route ATM system will be acceptably safe C001 Applies to the Operational Environment described in Section 2 of the En-route Safety Design Document

A001

Assumptions as per section 8.1 of the PSC

J001

Justification as per Section 2.2 of the PSC [tbd] [tbd] [tbd] Figure 20 Argue on basis of a safe Specification and Logical Design, full Implementation

• f that design, safe

Transition into service and Safety Monitoring for whole

• perational service life

Arg 2 SESAR En-route ATM system has been designed to be acceptably safe Figure 21

… …TOP LEVEL ARGUMENT TOP LEVEL ARGUMENT

LIFECYCLE VIEW LIFECYCLE VIEW -

• OVERALL

OVERALL

Definition Transfer into Operation Operation & Maintenance Lower-level Safety Arguments Evidence System Safety Assurance Activities Arg 0 Arg 0 Design & Validation (High-level) Arg 1 Arg 2 Arg 4 Arg 3 Arg 5 Arg 1 Arg 2 Arg 4 Arg 3 Arg 5 Implementation & Integration

V1 V2 V3 V4 V5 V6 V7 V0

Application Domain System i/f

User Reqts R Design D Specification S Domain Properties P

P, S R

Implementation I

‘Real World'

D S I D

Application Domain System i/f

User Reqts R Design D Specification S Domain Properties P

P, S R P, S R P, S R

Implementation I

‘Real World'

D S D S D S I D I D I D

RE Model

Definition Transfer into Operation Operation & Maintenance Lower-level Safety Arguments Evidence System Safety Assurance Activities Arg 0 Arg 0 Design & Validation (High-level) Arg 1 Arg 2 Arg 4 Arg 3 Arg 5 Arg 1 Arg 2 Arg 4 Arg 3 Arg 5 Implementation & Integration Definition Transfer into Operation Operation & Maintenance Lower-level Safety Arguments Evidence System Safety Assurance Activities Arg 0 Arg 0 Design & Validation (High-level) Arg 1 Arg 2 Arg 4 Arg 3 Arg 5 Arg 1 Arg 2 Arg 4 Arg 3 Arg 5 Arg 1 Arg 2 Arg 4 Arg 3 Arg 5 Arg 1 Arg 2 Arg 4 Arg 3 Arg 5 Implementation & Integration

Assurance Process Safety Case

Arg 0 SESAR En-route Operations will be acceptably safe.

Cr001 Acceptably safe is defined by the Safety Targets – see Arg 1.1 Arg 1 SESAR En-route ATM system has been specified to be acceptably safe Arg 5 SESAR En-route ATM system will be shown to

• perate acceptably

safely throughout its service life

Arg 3

SESAR En-route ATM system Design has been implemented completely & correctly Arg 4 Transition from current state to full SESAR En- route ATM system will be acceptably safe C001 Applies to the Operational Environment described in Section 2 of the En-route Safety Design Document

A001

Assumptions as per section 8.1 of the PSC

J001

Justification as per Section 2.2 of the PSC [tbd] [tbd] [tbd] Figure 20 Argue on basis of a safe Specification and Logical Design, full Implementation

• f that design, safe

Transition into service and Safety Monitoring for whole

• perational service life

Arg 2 SESAR En-route ATM system has been designed to be acceptably safe Figure 21

Arg 0 SESAR En-route Operations will be acceptably safe.

Cr001 Acceptably safe is defined by the Safety Targets – see Arg 1.1 Arg 1 SESAR En-route ATM system has been specified to be acceptably safe Arg 5 SESAR En-route ATM system will be shown to

• perate acceptably

safely throughout its service life

Arg 3

SESAR En-route ATM system Design has been implemented completely & correctly Arg 4 Transition from current state to full SESAR En- route ATM system will be acceptably safe C001 Applies to the Operational Environment described in Section 2 of the En-route Safety Design Document

A001

Assumptions as per section 8.1 of the PSC

J001

Justification as per Section 2.2 of the PSC [tbd] [tbd] [tbd] [tbd] [tbd] [tbd] Figure 20 Figure 20 Argue on basis of a safe Specification and Logical Design, full Implementation

• f that design, safe

Transition into service and Safety Monitoring for whole

• perational service life

Arg 2 SESAR En-route ATM system has been designed to be acceptably safe Figure 21 Figure 21

PROCESS SUMMARY PROCESS SUMMARY

SCD TCD TCR SCR FPM SURV(G) RBTs Airspace ACA PD(V) Nav Data SURV(A) Aircraft COTR Adjacent Airspace

. . . . .

TOLI/ TCICL

.

ADS data Other Aircraft Handover CLR

. .

Net Mgt ASA RBT Revision ACAS RA data

.

. .

.

Weather, NOTAMs, etc. RBT Revisions & Updates TCICL Nav AOC S&S GCA 1 1 Flt Ctl PD(H)

FMS FMS AP/FD AP/FD A/F A/F FCRW NAVAIDS NAVAIDS PLNR FDP FDP SDP(G) SDP(G) ADSECT ALTSYS ALTSYS MTCD MTCD MONA MONA EXEC SRNMC SDP(A) SDP(A) ACAS ACAS TCT TCT ASAS ASAS SNETS SNETS

TA RA

AC2

Independent Surveillance ADS-B ADS-B Mode A/C or S Non-standard COTR RBT Rev & Update RBT Rev & Update RBT Rev & Update Conflicts RA Downlink RBT Rev & Update Requests, CLR, & Transfer Airspace Data Manual Inputs

TAWS TAWS

Prop RBT Rev TC-SA

1 1

A&D- MAN A&D- MAN

2 2 1

CTO / A

APT data

• The AMAN sub-function shall compute a Controlled

Time of Overfly (CTO) for waypoints extending out well into En-route Airspace (typically as far as 200 nm) and down to a CTA at the Final Approach Fix or at a final merge point

• The AMAN sub-function shall generate speed

advisories for Aircraft without an RTA capability

• The EXEC shall resolve any conflicts, as follows:

– where the situation is time-critical, issue an “openloop” clearance to one or both Aircraft involved, or – where possible, and the situation is less time-critical, issue a trajectory change to resolve the conflict but return the Aircraft to its original route, or – where proposed by the PLNR and judged appropriate, for crossing / passing traffic, delegate separation responsibility to the FCRW according to the agreed and authorized RBT

A FEW FUNCTIONAL SAFETY REQUIREMENTS A FEW FUNCTIONAL SAFETY REQUIREMENTS

• !

"# $%& "#'#& $%

• (
• (

(( ( ( ( (!

• "#

$%& )# $

• (
• *&
• #)&