6-8 October 2003 1ASAS TN 2nd Workshop

ADS-B Safety Analysis ADS-B Safety Analysis (ASA & GSA)(ASA & GSA)

Bob DarbyEUROCONTROL ADS Programme

ASAS Thematic NetworkSecond Workshop 6-8 October 2003

6-8 October 2003 2ASAS TN 2nd Workshop

OUTLINEOUTLINE Background Current work

analysis processes comments on the methods, not the results

Wider context & Conclusions Safety is only part of SPR / IA Requirements Focus Group Longer term

Points of Contact

6-8 October 2003 3ASAS TN 2nd Workshop

BACKGROUNDBACKGROUND

6-8 October 2003 4ASAS TN 2nd Workshop

Safety Work HistorySafety Work History

1999-2000: Stage 0 Initial Safety Study - brief look high level workshops

2000-2001: Stage 1 Operational Hazard Analysis (OHA) based on “Case Studies”

Difficulty - not detailed enough definition of the applications

6-8 October 2003 5ASAS TN 2nd Workshop

Safety Work HistorySafety Work History 2002:

Package I proposed at Rome CARE-ASAS / EUROCONTROL development of Package I EUROCAE WG51 & RTCA SC-186

Common applications review & proposal Common methodology proposal - ED78A / DO-264 Guidelines for Approval of the Provision and Use of Air Traffic Services supported by Data Communications

In parallel: Stage 2A Safety Contract launched

At the time (Jan 2002) the aim was to Use EUROCONTROL Safety Assessment Methods (SAM) Use ED78A as a means of compliance with the SAM

Aim has changed as ESARR4 developed and use of ED78A has proceeded, to establish an effective methodology. Differences/complementarity handled as an outcome.

6-8 October 2003 6ASAS TN 2nd Workshop

CURRENT WORKCURRENT WORK

6-8 October 2003 7ASAS TN 2nd Workshop

Stage 2A Safety ContractStage 2A Safety Contract Coordinated with CBA and Architecture work Assessment of some ADS-enabled ASA and GSA

applications defined in the Package I OSED - including ADS-B in a mixed surveillance environment

For each Package I application OHA: building on the results of the ADS Programme Stage 1 OHA ASOR: allocation to elements / domains within the architecture from ASOR options: safety requirements for the ADS-B element based

on the specific enabling infrastructure. PSSA for one application, using a specific architecture

Issues: Methodology and Software tools equally important as the results

6-8 October 2003 8ASAS TN 2nd Workshop

Logical FlowLogical Flow

Case Studies OHA STAGE 1

(Draft) OSEDs OHA

FunctionalArchitecture

ASOR

Specific Implementation

PSSA

STAGE 2A

ASFA

GroundSurveillanceArchitecture

Methods & Tools

inc database

Assessments

- architectureguidance

RESULTS

CBA

6-8 October 2003 9ASAS TN 2nd Workshop

Applications assessedApplications assessedGround Surveillance Applications (GSA)ATC surveillance in en-route airspaceATC surveillance in terminal areasATC Surveillance in non-radar areaAirport Surface Surveillance

Surface Traffic Awareness applicationRunway Incursion application

Airborne Surveillance Applications (ASA)Enhanced traffic situational awareness on the airport surface

Surface Traffic Awareness applicationRunway Incursion application

Enhanced successive visual approachesSequencing and merging applications

6-8 October 2003 10ASAS TN 2nd Workshop

OHA processOHA processApplication descriptionand modell ing

Operational Hazard identification

Mitigation means Identification

Severity assignment

Safetyrecommendationidentification

Operational effects

Existing detection Means ?

Fall-back Means ?

(e.g. loss or erroneous action)

Operational fa ilure scenario

Yes

No

Severity withmitigation means

+Candidate Safety

Requirements

Operational effects

No Severity withoutmitigation means

OrInduced operational

hazards

Operational effects

Severity with Rec.Safety Rec.

Severity (with or without

mitigations) sufficient ?

Recommendationproposal

No

Yes

Environmentcharacteristics

Risk Classificat ionMatrix

OutputInputLegend:

&

Phase i

Operation i

Operation i

Operation i.

Phase n

Operation n.i

Operation n.j

Operation n.k.

Application Modelling

6-8 October 2003 11ASAS TN 2nd Workshop

OHA output (example)OHA output (example)Target identification phase Instruction phaseInitialisation phase

REQ/ENV 1,REQ/PROC 7, 11, 12,

REQ/TECH 2

OH1.2 Erroneous identification

REQ/ENV 5,REQ/PROC 2, 6, 13, 16,

REQ/TECH 2

Success

Severity 5

OH2.2Erroneous intruction

OH0.1Lack of ESVA initialisation

OH0.1�Lack of ESVA initialisation forSeveral aircraft

REQ/ENV 1REQ/PROC 1, 2, 3, 4,

5, 6, 7, 10, REQ/TECH 1

OH0.2ErroneousESVA initialisation

Severity 5

Severity 5

REQ/ENV 1REQ/PROC 5, 7 REQ/TECH 1

Severity 4

Severity 5

OH1.1No identification

REQ/ENV 4, 5, REQ/PROC 2, 3, 6,

13, 14, 15

OH1.3Delayed identification

REQ/PROC 14,REQ/TECH 5

Severity 4

Severity 4

OH2.1No intruction

Failure of one orseveral mitigation means

Severity 4

Environmental evente.g Unfavorable air traffic configuration…

From “Enhanced Successive Visual Approach”

OHA is summarised in a diagram.

Details in several tables:OH summary table, that refers toCandidate safety requirements lists

• environmental• procedural• technical

Recommendations listCauses list

Supported by detailed OH tables

6-8 October 2003 12ASAS TN 2nd Workshop

OHA - comments on processOHA - comments on process

Exhaustive & detailed ... … time-consuming to develop and to review Mature process, used (with slight variations) by

many European projects, NUP, MFF, …

Needs tool support to ensure consistency between diagrams and tables traceability and accurate cross-referencing between all tables database is being developed

Derived from application model in OSED Changes to OSED may mean complete rework of OHA

6-8 October 2003 13ASAS TN 2nd Workshop

ASOR processASOR process Follows on from OHA

traceability essential Objective: identify

responsible domains/elements (ATC, aircraft, crew,…)

system failure relationships mitigation means strategy

Key processes: Building the fault tree

stop when the safety requirement can be exclusively met in a domain

Allocation of safety requirements several options

OHAresults

CandidateSafety

Requi rements(from OSEDand OHA)

Safety Objectives Assignation

Step AIdentification

of the elementsto be further

analysed

SO allocation at OH and MM level

Elements Selection CriteriaSO

Remote, Extremel y Remote,

E xt remely Improbable

SO

None, Probable

CandidateSafety

Requirements

OHs SOMMs SO

Step BIdentifiedelementsanalysis

Fault Tree Decomposition

SO allocation over the Fault Tree

ASOR Requirements

ASOR discussion(Requirements allocation)

Step CSafety

RequirementsAllocation

SafetyRequirements

per domain

OHp.y

Severity

MitigationMeans

OHp.x

Severity

MitigationMeans

……… ………………Elementary Causes SO

6-8 October 2003 14ASAS TN 2nd Workshop

ASOR - comments on processASOR - comments on process

Relatively new process - learning as we proceed

More complex for surveillance than for communications

No single correct answer - tradeoffs will occur Trees give the understanding - tables give the

detail Tools for traceability and consistency essential

6-8 October 2003 15ASAS TN 2nd Workshop

PSSAPSSA Specific to a particular implementation Assess if the proposed architecture is safe for its

intended purpose ASOR has already mapped safety requirements to the domain Now look at the architecture within the domain: i.e. main functional

(and physical) components

EUROCONTROL study example: Toulouse airport Package I applications:

Airport Surface Surveillance Enhanced traffic situational awareness on the airport surface

Surface Traffic Awareness application Runway Incursion application

Just starting this phase of the study

6-8 October 2003 16ASAS TN 2nd Workshop

Overall CommentsOverall Comments Learning about the processes as we use them

going from the generic to the specific Status

OHA: mature but effort intensive ASOR: developing well PSSA: just started but relatively straightforward

Overall: large effort Tool support essential, especially when iterating and

reworking Complementary approach to identify critical areas would

pay dividends OSED is critical - clarity and accuracy of application

modelling is vital

6-8 October 2003 17ASAS TN 2nd Workshop

WIDER CONTEXTWIDER CONTEXT& &

CONCLUSIONSCONCLUSIONS

6-8 October 2003 18ASAS TN 2nd Workshop

Safety is only part of the processSafety is only part of the process

OSEDOperational Service &Environment Definition

OSAOperational Safety

AssessmentOHA & ASOR

OPAOperational Performance

AssessmentIdentify & allocate

performance requirements

IAInteroperabilityAssessment

SPRSafety & Performance

Requirements

Interop Document

6-8 October 2003 19ASAS TN 2nd Workshop

Preparation for RFG/3Preparation for RFG/3 Joint EUROCONTROL, FAA, EUROCAE, RTCA

“Requirements Focus Group” 1st-4th December 2003, Washington DC

OSEDs: OSED Harmonisation Group First complete PI OSED due out soon

Safety: EUROCONTROL, NUP, MFF, … Convergence on the methods More coordination and consensus needed - EC can help?

SPR & IA as a whole ad-hoc SPR/IA group working since July aiming at common approach for Europe and USA;

extend world-wide?

6-8 October 2003 20ASAS TN 2nd Workshop

Longer term considerationsLonger term considerations

Operational expertise to validate the analysis conclusions

Complementary methods could be of value for greater efficiency overall for confirming results

Coordination with Safety Unit, SRC and EASA

6-8 October 2003 21ASAS TN 2nd Workshop

POINTS OF CONTACTPOINTS OF CONTACT

EUROCONTROL ADS Programme visit the ADS Programme website:

http://www.eurocontrol.int/ads

STNA & Sofréavia who have carried out the detailed work and developed in

a practical form the processes described today

RFG colleagues discussions in preparation of material for RFG/3