ENRI International Workshop on ATM/CNS. Tokyo, Japan. (EIWAC 2009).

2020ForesightAsystemsengineeringapproachtoassessingthesafetyoftheSESAROperationalConcept
Derek Fowler, Eric Perrin, Ron Pierce
EUROCONTROL
Brétigny-sur-Orge, France
derek.fowler.ext@eurocontrol.int, eric.perrin@eurocontrol.int, ron.pierce.ext@eurocontrol.int
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 that are planned for
introduction into European ATM over the period up to 2020 and beyond. It presents the theoretical basis for what is a“systems-engineering approach” and describes how that is being applied to the preliminary work on the safetyassessment of the SESAR Operational Concept.
Keywords: safety, assessment, safety-case, assurance, SESAR
x it should be pragmatic and of maximum benefit to
SESAR Stakeholders

1. INTRODUCTION

x it should make maximum use of, and contribution
to, the work being undertaken on EP3

European airspace is fragmented and will become
increasingly congested as traffic is forecast to growsteadily over the next 15 years or so. ATM services
and systems are not sufficiently integrated and are
based on overstretched technologies. Therefore, tomeet future air traffic needs, the European ATM
services must undergo a massive operational change,
supported by innovative technologies.

x it must preserve the integrity required of the safetyassessment process itself.
Reference [1] explained why the traditional, failurebased approach to safety assessment in European ATM
was insufficient for the assessment of new operational
concepts, and proposed a “broader approach to safetyassessment”.

SESAR - the Single European Sky ATM Research
Programme1 - is the means of defining, designing anddelivering 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
2020.

Reference [2] presented an Integrated Risk Picture(IRP) of the causes of ATM-related accidents, basedon analysis of accidents and incidents up to year 2005,
and showed how it could be used to predict the effectof future changes to the ATM system on the risk of an
accident.
This paper builds on, and integrates the approaches
proposed in [1] and [2] and shows how what has
become the “systems-engineering approach to safetyassessment” is starting to be applied to the SESAR
Operational Concept circa 2020.

During the SESAR Definition Phase, the European
Commission initiated Episode 3 (EP3), a three-year
project to undertake a first assessment of the SESAR
Concept of Operations. Closely related to EP3 is an apriori safety assessment of the SESAR Concept, toassess as far as practicable that the Concept has been
specified to be acceptably safe - this work is based at
EUROCONTROL’s Brétigny site.

2. THEORETICAL PERSPECTIVES
2.1 Risk Basics
Reference [1] uses the simple example of a car airbag
to explain why a safety assessment must consider the
positive (risk-reducing) properties of a system as wellas its negative (risk-inducing) properties. Clearly, we
would want an airbag to be reliable - i.e. to operate
when it is needed - and to have high integrity – i.e. not
to operate when it is not needed. However, above all,we would want it to be effective (in preventing death /serious injury) when it does operate; this would dependon its size, shape, construction and speed of
deployment etc – i.e. on its functional / physical andperformance properties.

This work is a preliminary safety assessment, laying
the foundations of the process and methods, andgathering initial results, that will then feed into themain SESAR programme.
The specific requirements that the safety assessment
has to satisfy are as follows:x it must be soundly based from a theoreticalperspective

1

Equivalent to the US NextGen Programme151

D. Fowler, E. Perrin, R. Pierce

This is illustrated in Figure 1 which shows the risk (tothe driver) with and without the airbag – i.e. RU and RA
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-leftarrow) than any deaths / serious injury that might becaused in the event of its failure or spurious operation(the red, left-to-right arrow).

2.2 Application to ATM Risk
ATM is somewhat wider in scope and complexity thana car airbag but the same, fundamental principle holds
good – i.e. its primary purpose is to mitigate preexisting (aviation) risk.

There are a number of very important points to note
about this diagram:

It is self evident that aviation (like driving) isinherently risky! Even for a single aircraft, there arerisks of uncontrolled and controlled flight in terrain(UFIT and CFIT). For multiple aircraft in the airspace,
there are additional risks of mid-air collision (MAC)and collision between aircraft on the ground.

RA

RT

Risk without
AirbagRU~ Functionality &Performance~ 1/(Reliability&Integrity)
What we don’t want
the system to do
0Pre-existing
Pre-existing
Hazards
Hazards

Airbag contribution to driver safety
Risk R

Fig 1: Risk Graph for a Car Driver’s Airbag

Main ATM
Functions

x RU has nothing to do with the airbag – for thisreason we call it pre-existing risk

SafetyNets

Accident

SystemSystem-generated
generated
Hazards
Hazards

People, equipment andprocedures

x RM is the theoretical minimum risk that would exist
in the complete absence of failure of the airbag – itis not zero, because there are some accident
scenarios that an airbag cannot mitigate against

Fig 2: Simple ATM Barrier Model
These risks (or hazards) are inherent in aviation andtherefore can be considered as “pre-existing” as far as
ATM is concerned - they form the input to the model.

x the risk increase RA - RM is caused entirely by
failure of the airbag - thus we call it systemgenerated risk

The barriers act in rough sequence from left to rightand effectively filter out a proportion of the preexisting hazards. The final barrier reflects the point
that, even when all three layers of ATM have been
unable to remove a hazard, there is a (usually high)probability that an actual accident will not result.

x the safety case must show at least qualitatively that
RA<<RUx if we now introduce RT (the maximum tolerable
level of risk) then a most interesting conclusion
emerges: the maximum tolerable failure rate of the
airbag, the length of the red arrow (RT - RM),
depends on the length of the green arrow (RU-RM) i.e. on how successful the airbag is in reducing thepre-existing risk

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 ofthe barriers in removing the pre-existing hazards. Of
course, elements of the ATM system can fail or operatespuriously / incorrectly, giving rise to systemgenerated hazards, as defined above – these are shownin Figure 2 as inputs to the bottom of the model.

x if, as we desire, (RT - RM) << (RU - RM) then theoverall risk actually achieved (i.e. RA) is much
more sensitive to changes in the length of the green
arrow (i.e. to changes in functionality andperformance) than to proportionate changes in thelength of the red arrow (i.e. to changes in reliability
and integrity)2.

To paraphrase SESAR deliverable D4 [4], ATM must:x “maximize its [positive] contribution to aviation
safety”, andx “minimize its [negative] contribution to the risk ofan accident”.

The above points also raise some very importantquestions regarding the origins and use of traditionalrisk-classification schemes. It is why the above safetyassessment has adopted a more considered approach,based on IRP, as described later.

2

Providence

RM

What we want
the airbag to do

Collision AvoidanceTolerable
Risk

Separation Provision

Risk with
AirbagStrategic Conflict Mgt

Minimumachievable
Risk

This can be illustrated by expressing the three layers ofATM, described in the ICAO Global ATM Concept [3],in the form of a Barrier Model3 as shown in Figure 2.

In [1], these two aspects were referred to respectively
as the success and failure approach; it was alsoemphasized that traditional ATM safety assessments

3

For ATM, RA is typically 6 to 7 orders of magnitude lessthan RU!

152

Adapted from Prof James Reason’s “Swiss Cheese” model– see http://www.bmj.com/cgi/content/full/320/7237/768

ENRI International Workshop on ATM/CNS. Tokyo, Japan. (EIWAC 2009).

had usually assumed the former and focussed almost
entirely on the latter.

x a set of arguments - i.e. statements which claim thatsomething is true (or false), together with

What is crucial about Figure 2 for SESAR is that, inorder to show that ATM achieves a tolerable level ofrisk overall, we need to understand the relationshipbetween pre-existing risk (RU), the positive andnegative contribution of the three ATM Barriers, andthe positive contribution of Providence4 .

x supporting evidence to show that the argument isvalid.
Safety arguments are normally set out hierarchicallysuch that any particular argument statement is valid
only if all of the next-level arguments are themselves
valid - as shown, using goal-structuring notation(GSN), in Figure 4.

To demonstrate this quantitatively, we have combined
the characteristics of the Barrier Model and Risk Graph
as a single (slightly unconventional!) Fault Tree, as
illustrated in Figure 3.

GSN is simply a graphical representation of anargument / evidence structure. In safety work it willusually start with the claim (Arg 0) that something is(or will be) safe; this is then decomposed such that it istrue if argument statements Arg 1 to 4 are all true.

Accident
RA
&

1-PS4

OR

FF3

&

1-PS3

OR

FF2

&

1-PS2

OR

FF1

&

Pre-existing
Pre-existing
Hazards
Hazards

1-PS1

The strategy text should explain the rationale for that
decomposition.

Providence

Cr001<<Safe is defined by
Safety Targets>>

Collision Avoidance

Separation Provision

Arg 0<<Claim thatsomething is safe>>

SystemSystem-generated
generated
Hazards
Hazards

C001
Applies to <<Operational
Environment>>

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

J0001<<Strategy to explain therationale for decomposing
Arg 0>>

Strategic Conflict Mgt<<Justification for the
subject of the Claim>>

Fu

Fig 3: Fault Tree Version of Barrier Model
This Fault Tree allows us to compute the risk of an
accident (RA) from: the pre-existing, aviation hazards(and their frequencies FU); the probability of success(PSn) of each barrier in removing those hazards; and thefrequency (FFn) with which failure of each barrier
introduces new hazards. Alternatively, of course, if wemake the top-level risk our target (RT) then, given FU
and access to historical accident and incident data, we
can make informed judgements about what PSn andfrequency FFn are required to be in order to satisfy RT.

5This is consistent with the SESAR Safety Management Plan
andEuropean
Operational
Concept
Validation
Methodology, (E-OCVM) both of which take a “casebased” approach

Arg 3

Arg 4

<<Argument that
<B> is true>><<Argument that
<C> is true>><<Argument that
<D> is true>>

[tbd]

[tbd]

[tbd]

Fig 4: High-level Safety Argument
The claim is supported by vital contextual information:x what is meant by safe is defined by means of safetytargets, which may be quantitative and / orqualitativex the context for the claim must include a descriptionof the operational environment for which the claim
is being made; sub-section 2.5 explains how criticalthis is to the validity of the claim
x assumptions are usually facts on which the claim
depends and over which the organization
responsible for the safety case has no managerial
influence - e.g. traffic will increase by x% per year
x if the claim relates to a major change to a safetyrelated system, it is good practice to provide ajustification for that change.

2.3 Safety Cases
Safety assessments are often done within the context ofa safety case 5 which, like a legal case, comprises two
main elements:

Providence is unique in that it cannot make a negative
contribution – i.e. it cannot introduce new risk

Arg 2<<Argument that
<A> is true>>[tbd]

This risk model lies at the heart of the first stage in the
integration of IRP accident model, being developed
under EP3, into the a priori safety assessment. In
practice, IRP uses a more detailed Barrier Model thanthe one described above - it exists in both currentATM and post-2020 versions, as described in section
3.5 of the paper.

4

Arg 1

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 toshow that the corresponding argument is valid. Further
guidance on constructing safety arguments is given in[5].
2.4 Safety Assurance
There, however, are two problems with the simple
argument / evidence approach.

153

D. Fowler, E. Perrin, R. Pierce

The first is that, in itself, it gives no indication how theevidence should be obtained or how rigorous that
evidence needs to be. As illustrated in Figure 5, thisproblem is addressed by bridging the lowest level ofdecomposition of argument and its supporting evidence
with:

ATM systems but the application to the overall system,as described herein, is new.
2.5 A Requirements-engineering Model
Capturing a complete and correct set of safety
requirements is fundamental to any a priori safetyassessment.

x safety assurance objectives, which state what has tobe done to satisfy the related strand of the argument,
andFor the initial SESAR work, we have adopted thesimple, but rigorous, requirements-engineering (RE)model shown in Figure 6.

x safety assurance activities which state how thesafety assurance objectives will be satisfied –including the tools and techniques etc to be used.

In this model, systems exist in the real world. The partof the real world that influences the system, and into
which the system provides a service, is known as theapplication domain. Users of the service exist in theapplication domain. The system interacts with theapplication domain through an interface (i/f).

SafetySafety Argument
Argument
To satisfy

Assurance
Level (AL)P, S

Objectives
Objectives

R
User Reqts R

Specification S
To give confidence

To achieve

Activities
Activities
To produce

Systemi/fApplication
DomainEvidence
Evidence

Fig 5: System-level Assurance Structure
The output of the assurance activities is then theevidence that we needed to show in turn that eachobjective has been met and eventually, therefore, thatthe safety argument is satisfied.

Design D

DomainProperties P

Fig 6: Requirements-engineering Model
User requirements are what we want to make happen
in the application domain and are defined in thatdomain - not in the system.

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 theconsequences of failure of the system element underconsideration. For the initial SESAR work, we
decided to make the objectives independent of the ALs
and give only general guidance on the rigour requiredof the tools, techniques etc used in the safetyassessment6.

A specification is what the system has to do across theinterface in order that the user requirements can besatisfied - i.e. specifications take a “black-box” view ofthe system.
The formal notation in the “bubble” in Figure 6 defines
the key relationship that the specification S satisfies theuser requirements R only for a given set of properties Pof the application domain; if any one of these three setsof parameters is changed then requirementssatisfaction argument is invalidated until one of theother sets is also changed, in compensation.

There is a second, related problem that safetyassurance is often used to address - the fact that the
integrity of software functions or human tasks, inparticular, is very difficult to show in a direct way through, for example, analysis of test results - that such
safety requirements have been satisfied in
implementation.

Design describes what the system itself is actually likeand includes all those characteristics that are notdirectly required by the users but are implicitly
necessary in order for the system to fulfill its
specification and thereby satisfy the user requirements.
Design is essentially an internal, or “white-box”, viewof the system.

This is reflected in, for example, airborne software
standard DOD 178B [6] and system / software standard
IEC 61508 [7] both of which are assurance based.
EUROCONTROL itself has adopted such an approachin the safety assessment of the individual software,
procedure and (under development) human elements of
6‘Real World'

The
distinction,andrelationship,
betweenrequirements, specifications, domain properties anddesign are not merely academic niceties but provide
the essential foundations for developing systems that
do, and can be shown to do, everything required ofthem. In section 3, it is shown how this is crucial tothe construction of a safety argument for the

We did not feel that we had the competence or authority to
be prescriptive about this – therefore we left it to individual
safety assessments / safety cases to justify that the evidence
produced is trustworthy – see Arg1.4 in section III.

154

ENRI International Workshop on ATM/CNS. Tokyo, Japan. (EIWAC 2009).

completenessrequirements.

andcorrectness

of

the

important to note that Argument 1 applies to the whole
SESAR Concept as applicable circa 2020; therefore,
because the SESAR Concept is being implemented instages, the term transition in Argument 3 includes thesafety of each stage of this phased deployment of theend system, taking account also of the fact thatdevelopments in adjacent airspace may be being
deployed in a different sequence and/or to different
timescales – it is part of the current SESAR work to
consider how to address that problem.

safety3. APPLICATION TO THE SAFETYASSESSMENT OF THE SESAR OPERATIONAL
CONCEPT (CIRCA 2020)
The first point about the SESAR safety assessment isthat it is argument-driven – there is a process to befollowed but that comprises a series of activities
defined as in section 2.4 above.

The main focus of the current work, however, is Arg 1.

3.1 High-level Safety Argument
A typical high-level safety argument for SESAR isshown in Figure 7, using the En-route phase of flightas an example.

3.2 Decomposing Arg 1
In order to decide how best to decompose Arg 1, we
first needed a suitable interpretation of the RE modelof Figure 6.

The top-level claim (Arg 0) is that En-route operations
for the specified Operational Environment (C001) will
be acceptably safe, as is defined by the safety targets –see sub-section 3.5 below.
Cr001
Acceptably safe isdefined by the Safety
Targets – see Arg 1.1.1

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

A0001
Assumptions as
declared in each
Operations Safety Case

P, S

C001
Applies to the Operational
Environment described in
Section 2 of the <<name>>
Safety Design Document

Arg 2

SESAR En-routeATM system has
been designed tobe acceptably safe

SESAR En-routeATM system
Design has been
implemented
completely & correctly
[tbd]

Arg 3
Transition fromcurrent state to full
SESAR En-routeATM system will be
acceptably safe
[tbd]

Justification as per
Section 2.3 herein

SystemDesign D

Arg 4
SESAR En-routeATM system will beshown to operate
acceptably safely
throughout its service

Safety Targets T

I/f

ATM Operational
Environment‘Real World'

Operational
Environment
Properties P

Fig 8: ATM Requirements-engineering Model
Our strategy for developing the argument was asfollows:[tbd]

Fig 7: High-level Safety Argument – SESAR En-route
Operations

x firstly to ensure that the properties P of theoperational environment was properly described.
Fortunately, most of the necessary information was
readily available from detailed operationaldescriptions (DODs) produced by EP3 operational
experts – it included the statement that the ATCseparation minima would remain unchanged

The key assumption at this stage is that SESAR will
deliver by 2020 a 1.7-fold increase in capacity [8] andthat this will be fully taken up by a corresponding
increase in traffic levels7.
The justification for SESAR stems from its benefits tothe airspace users, including improvements in thecapacity, cost- effectiveness, efficiency, environmental
sustainability, and flexibility of the overall ATM
service.

x next to make an argument that the safety targets T
were appropriate and correct for that environmentx then to make an argument that the ATM service
specification S (to be produced as part of the safetyassessment) would satisfy the safety targets T given
the operational environment properties P.

The claim is then decomposed into the four arguments.
Arguments 2 to 4 reflect normal ATM safety practiceand are the responsibility mainly of the SESAR
stakeholders involved in the implementation of the
SESAR Concept (Arg 2) and subsequent SESARbased operations (Arg 3 and 4). However, it is7

T

ATM Service
Specification S

J0001
Argue on basis of a safe
Logical Design, full
Implementation of thatdesign, safe Transition
into service and Safety
Monitoring for wholeoperational service life

Arg 1

Figure 10

This interpretation is shown in Figure 8. As a(literally) logical representation, the RE model lends
itself well to being expressed as a safety argument.

Thus we could argue, at this stage, that the ATM
service had been specified to be acceptably safe. The
form of that specification is discussed in sub-section
3.5 below.
The next key step was to argue that the ATM system
had been designed to satisfy the ATM service
specification. It was clear that at this stage it would
impracticable for us to attempt a physical design sincethat would more appropriately be left toThis is the worst case because increasing traffic has aninherent 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
[9]

155

D. Fowler, E. Perrin, R. Pierce
x The design has the functionality and performance
attributes that are necessary to satisfy the ATM
service-level specification

implementation (see Arg 2 above). Thus we neededfind a more abstract representation of the system –which we called a logical design – as described in subsection 3.6 below.

x The design will deliver that functionality andperformance under all normal conditions of theoperation environment that the system is expected
to encounter in day-to-day operations

Two more issues needed to be addressed in order tocomplete a satisfactory argument:
x to show that the logical design was realistic – i.e.
would be capable of being implemented in aphysical system, comprising people, equipment andproceduresx The design is robust against (i.e. work through), orat least resilient to (i.e. recover easily from), any
abnormal conditions of the operation environmentthat the system may exceptionally encounterx to show that all the evidence under Arg 1 wastrustworthy – see the discussion on safety assurance
in section 2.4 above.

x The design has the reliability and integrity
attributes that are necessary to satisfy the ATM
service-level specification

This is all summarized in GSN form in Figure 9 below.
Fig 8

3.4 The Safety Lifecycle
Albeit very much argument-driven, the safetyassessment approach has to end up with a process thatis to be followed through the project lifecycle.

Arg 1
The SESAR En-routeATM system has been
designed to be
acceptably safe
Argue on the basis of theRequirements Engineering
Model in Figure 9

Arg 1.1.1
Safety Targets set
as appropriate to
the Operational
Environment

C003
Specification is throughSafety Objectives asapplied to Barrier ModelArg 1.1.2
Service Specification
satisfies the Safety
Targets

C004
Only in the context of thestated properties of the
Operational Environment

[tbd]

[tbd]

[tbd]

Figure 11

System Safety
Assurance Activities

Arg1.4The Evidence forthe Logical Design
is trustworthy

Arg 1.3
Logical Design
is realistic

Arg 1.2
Logical Design
satisfies the Service
Specification[tbd]

Definition

Operation &Maintenance

Arg 4

Arg 1
Arg 0

Arg 3

Transfer into
Operation

Arg 0

Integration

Arg 3

Arg 4

Implementation

Arg 2

Fig 10
Arg 1.2
Logical Design
satisfies theSpecification

Design & Validation(High-level)

Evidence

3.3 Decomposing Arg1.2
Making an argument for logical design is not simply amatter of showing traceability of the individual safety
requirements (that form part of the design) back to thespecification. This would ignore the possibility thatthe design as a whole was in someway functionally
incomplete or internally incoherent or that new failure
properties would emerge at the design level that were
not apparent at the ATM-service level.

Arg 1

Fig 9: Initial decomposition of Arg 1

Lower-level Safety Arguments

Arg 1.1
ATM Service is
specified to be
acceptably safeThis is illustrated at the highest level in Figure 11, andshows that each safety-lifecycle stage comprises safetyassurance activities which are determined by the safetyargument and which produce evidence that theargument has been satisfied – the SESAR Safety
Management Plan maps these on to the SESAR Project
and E-OCVM lifecycle stages.

Arg 2

C002
Design takes the form of a
Logical architecture. Physicaldesign is covered in Arg 2

Fig 11: Overall Safety Lifecycle Process
Arg 1.2.1
The Logical Design
exhibits all thenecessary functional& performance
properties

Arg 1.2.2
The Logical Design
functions correctly &coherently under all
normal environmental
conditions

Arg 1.2.3
The Logical Designis robust (or at leastsufficiently resilient)against external
abnormalities

Arg 1.2.4
The Logical Design
exhibits all thenecessary reliability& integrity properties

Argue on basis oftraceability from BM,
through FM to LM and
SRs. Also show all OI
Steps are addressed

Argue on basis ofThread Analysis(static behaviour)and Simulations(dynamic behaviour)

Argue on basis ofThread Analysis(static behaviour)and Simulations(dynamic behaviour)

[tbd]

[tbd]

[tbd]

Argue that All risks
from internal system
failures have been
mitigated sufficiently
to enable STs to besatisfied overall

It may be noticed that there is no reference to safetyassurance objectives in Figure 11. This is because,
when safety assurance is put into a safety argument
framework, the safety assurance objectives become
simply the lowest level of decomposition of the safetyargument.
We can now apply the same general model to theDefinition and Design & Validation phases of thelifecycle, as described in the next two sub-sections.

[tbd]

Fig 10: Decomposition of Arg 1.2
Thus we needed to show, as indicated in GSN form in
Figure 10, that:

3.5 Definition Phase
Figure 12 provides an overview of the safety assurance
process for the Definition phase of the safety lifecycle.

156

ENRI International Workshop on ATM/CNS. Tokyo, Japan. (EIWAC 2009).

#3 the risk of an ATM-related accident shall be
reduced as far as reasonably practicable

Each of the three steps consists of a number ofassurance activities necessary to satisfy the associatedsafety argument (or, in the case of C001, provide vitalcontextual information to support the argument).

The specification of the ATM service – see sub-section
3.2 above – is based on the barrier model9 shown in
Figure 13.

Providence

Separation
Infringement

Pilot Recovery

Collision
Avoidance

ATC Recovery

ATC Tactical Deconfliction

Conflicts

Pilot Tactical Deconfliction

Separation
Provision

Coordination

Trajectory Deconfliction

Strategic
ConflictManagement

Demand & Capacity Balancing

Arg 1.1.1

Arg 1.1.2

Arg 1.1

Arg 1.1.2

C001

Barrier Model &Safety Objectives

Arg 1

ATM Service
Specification

SBT
hazards

Arg 1.1

SafetyTargets

Arg 1.1.1

Arg 1

Environment
Properties

Analysis of
User
Requirements

ATM System
Boundary

C001

Description of
Operational
Environment

Airspace Design

System Safety
Assurance Activities

Fig 13: En-route / TMA Barrier Model
The inputs to the model are the pre-existing hazards ofconflicts between, what are known on SESAR as, theshared business trajectories – in effect, these are theideal trajectories that the each user would like to fly,unconstrained by any other considerations.

Fig 12: Safety Assurance in Definition Phase
It is impracticable to present the full scope of these
activities within this paper – as an example however,the description of the operational environment for
SESAR En-route operations would include:

The ATM service specification then comprises:x a functional description of the operation of eachbarrier and, qualitatively, how barrier contributes tothe removal of the pre-existing, SBT hazards

x airspace structure and boundaries
x types of airspace / ICAO classifications

x safety objectives which specify, quantitatively, boththe minimum probability of success, and the
maximum rate of failure, of each barrier such thatthe residual accident rate is within the safety targets.

x route structures (as applicable) and any restricted
airspace (temporary or otherwise)
x traffic characteristics and complexity

3.6 Design & Validation Phase
Figure 14 provides an overview of the safety assurance
process for the main part of the Design & Validation
phase of the safety lifecycle - activities related toArg1.3 and 1.4 have been omitted from the diagram forthe sake of clarity.

x aircraft ATM capabilities
x air traffic services to be provided, and associatedseparation standards
It would also need to identify those properties of theenvironment that are crucial to the safety assessment(C001).

3.6.1 Functional Design
Even though Arg 1.2 is made in the context of logicaldesign the first step in the process is development of afunctional model of the ATM system. This is because:

The needs of the airspace users are analyzed from asafety perspective. From this analysis, safety targets
are derived so as to satisfy those user needs. For
SESAR, we have (provisionally) identified three typesof safety target, for each of the four main phase offlight:x we found that to get sufficient assurance of thecompleteness of the logical design of the ATM
system, with respect to the barrier model of the
ATM service, it was necessary to bridge the two
with a functional representation of the system, and#1 the risk of an ATM-related accident (perannum) shall be no higher than for the pre-SESAR
situation

x it was considered to be good system-engineering
practice for deriving the requirements of afunctionally rich system like ATM.

#2 the risk of an ATM-related accident shall not
exceed [tbd]8 per flight hour

A functional model (FM), in this context, is a highlevel, abstract representation of the system that is8

A figure for each phase of flight is being obtained from the
IRP model described earlier in the paper. Each figure willtake account of the affect that increasing traffic will haveon risk and will be set such that targets #1 and #2 areconsistent .

9157

The version of the model shown applies to En-route andTerminal Area operations only – a slightly different Barrier
Model has been developed for Airport operations

D. Fowler, E. Perrin, R. Pierce

entirely independent of the logical design and of theeventual physical implementation of the system.

capabilities etc; be able to operate to full effectivenessfor trajectories that are based on pre-defined RNAV
routes or user-preferred routes; be able to operate tofull effectiveness in a mixed traffic environment; tosupport continuous descents and climbs in Terminal
Areas; and take account of the separation mode foreach aircraft.

SafetyObjectives••

DesignAnalysis (1)“Thread” descriptions –normal conditions•
DesignAnalysis (2)“Thread” descriptions –abnormal conditions

DesignAnalysis (3)Safety Integrity Reqts

Arg 1

Arg 1.2

Logical Model &Functional Safety Reqts

Arg 1.2

Arg 1.2.3 Arg 1.2.3 Arg 1.2.2

LogicalDesignArg 1.2.2 Arg 1.2.3 Arg 1.2.4

Arg 1

Functional Model &Safety Functions

Arg 1.2.1

Arg 1.2.1

Functional
DesignFig 14.: Safety Assurance in Design & Validation
Phase

Figure 16 shows the graphical representation of the
SESAR LM for Terminal Area operations.

The FM describes what safety-related functions are
performed and the data that is used by, and producedby, those safety functions – it does not show who or
what performs the safety functions.

TCT
TCT
1

RBT Rev& Update
.

.

.

.

Weather,
NOTAMs
etc

FPM

CLR
Next
Segmt
RBT
Revision

TOLI/
TCICL

Nav Data

PD(V)
Other
Aircraft

TCICL

Adjacent
Airspace
RBT Revisions& Updates

.

PD(H)

Nav

HandoverAircraft

Flt.
Ctl
AOC

Colln
Avoid

ACAS
ACAS
TA

1

A/F
A/F

ASAS
ASAS
Manual Inputs

Functional safety requirements (FSRs) describe indetail what each element of the LM must do from asafety perspective and, where necessary, what level of
performance is required of it. As an example, thefollowing are two of the 21 FSRs provisionallyspecified for the Arrival & Departure Manager(A&DMAN) and two of the 29 FSRs provisionallyspecified for the EXEC controller:

TCR

S&S

COTR

RA

Fig 16: Typical SESAR Logical Model
ACAS RA
data

SCR

AP/FD
AP/FD

SDP(A)SDP(A)
TAWS
TAWS

ADS
data

TCD

FMS
FMS

RBT Rev& Update

Independent Surveillance

SCD

ALTSYS
ALTSYS

Airspace Data.

SURV(G)NAVAIDSNAVAIDS
TC-SA

SRNMC

FCRW

SURV(A)ASA

Fig 15: Typical SESAR Functional Model1.

the AMAN sub-function shall compute aControlled 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

2.

the AMAN sub-function shall generate speed
advisories for Aircraft without an RTA capability3.

the EXEC shall resolve any conflicts, as follows:

Safety functions describe in detail what each element of
the FM does and, where necessary, what level of
performance is required of it.
A typical ATM safety function is strategic conflict
detection (SCD). It is effectively an abstraction of oneof the main role of the multi-sector planner controller /planning tools. It is normally triggered by flightprogress monitoring (FPM) or directly from airspace /trajectory information, and provides a warning ofconflicts between trajectories and between a trajectoryand prohibited airspace. SCD needs to: be able tohandle a mix of trajectory types, times, aircrafta). where the situation is time-critical, issue an“open-loop” clearance to one or both
Aircraft involved, orb). where possible, and the situation is lesstime-critical, issue a trajectory change to

158

ADS-B

RBTs

.

ADSECT

Mode A/C or S.

RBT Rev &Update

Prop
RBT
Rev

2

Requests, CLR& Transfer

FDP
FDP
RBT Rev& Update

ADS-B

Airspace

EXEC

MONA
MONA

RA Downlink

.

APT
data

CTO / A.

A&DA&DMAN
MAN

Non-standard COTR

CLR
and
TMR

2

.

AC2

Conflicts

PLNR

1

SNETS
SNETS

SDP(G)SDP(G)MTCD
MTCD

It is not practicable to describe a typical FM in thispaper but to illustrate the level and structure involved;
however, to give some indication of its scope andcomplexity, Figure 15 shows the graphicalrepresentation of the SESAR FM for Terminal Area
operations.
Net Mgt

3.6.2 Logical Design
A logical model (LM) is a high-level, architecturalrepresentation of the system design that it is entirely
independent of the eventual physical implementationof that design. The LM describes the main humantasks, machine-based functions and airspace structuresand explains what each of those “actors” provides interms of functionality and performance. The LM
normally does not show elements of the physicaldesign, such as hardware, software, procedures,training etc.

ENRI International Workshop on ATM/CNS. Tokyo, Japan. (EIWAC 2009).

resolve the conflict but return the Aircraft toits original route, orMuch of the static assessment employs a modified
version of UML system sequence diagrams used in use
case analysis – which we have called thread analysis –illustrated in Figure 17.

c). where proposed by the PLNR and judged
appropriate, for crossing / passing traffic,
delegate separation responsibility to the
FCRW according to the agreed andauthorized RBT
WheneverEXEC
delegates
responsibility to FCRW, he/she shall:a). request the FCRW to accept responsibility
for separation under ASAS procedures

Aircraftclimbs
FCRW
rejectsc). continue monitoring of these flights forpossible unexpected behavior, and correct
as necessary - otherwise the EXEC shall
NOT provide instructions, advice orassistance to the FCRW unless specificallyrequested to do so by the FCR

3.

3

2

4

10

9

8

15

17

18

14

Aircraftclimbs24

611

Conflict
6

13
19
21

25

Conflict free

7
12

16

SDP(G)

23

20
6

22

Fig 17: Thread Analysis (Illustrative)
It is left to the reader to work out the details (!) but the
key points regarding the technique are as follows:x the thread starts with an initiating event – “aircraft
wants to climb” and/or one or more pre-conditions e.g. the aircraft has a level-4 capable FMS (notshown)x the numbered horizontal arrows denote transactions
between the (human and equipment-based) actors
shown across the top of the diagram

3.6.3 Design Analysis
Having produced a design that appears to have all thefunctionality and performance attributes that arenecessary to satisfy the ATM service-levelspecification, the three stages of design analysis areintended to:assess the behavior of the design under any
abnormal conditions of the operation environmentthat the system may exceptionally encounter

MTCD

Repeatfrom 1e). resume separation responsibility for the
Aircraft involved in an ASAS maneuverwhen advised by the FCRW that the
maneuver is complete and the Aircraft
involved are on diverging paths.

2.

EXEC

FCRW
acceptsd). retain
responsibility
forprovidingseparation between all other aircraft andbetween those aircraft and the aircraft
involved in the ASAS maneuver

prove the correctness and coherency of the design,under all normal conditions of the operation
environment that the system is expected toencounter in day-to-day operations

1

FDP

5

b). pass the identity of the "target aircraft" to
the FCRW

1.

FMS

FCRW

separation

Aircraft wants
to climb

4.

The example scenario is that an aircraft requests achange of trajectory.

x the numbered vertical arrows denote functions /tasks performed by an actorx a dashed horizontal arrow denotes continuous flowof data – e.g. surveillance information (item 6)
x items 4 and 16 both have two possible outcomes,
leading to branching of the threadx each thread is continuous from initiation toconclusionx each numbered item has an associated written
description and a cross-reference to the related
Functional Safety Requirement(s).

assess the effects of internal failure of the ATM
system on the risk of an accident

So far, the use of thread analysis on the SESAR safetyassessment has shown the following benefits:

The only difference between the first two stages are theoperational scenarios that define the normal andabnormal environmental conditions, and therequirement that in the first case the system mustdeliver full functionality and performance whereas in
the second case the system may degrade somewhat
provided it can be shown that any associated risk isvery low because of the short duration and/or
infrequency of the abnormal conditions.

x it has led to a much better understanding of how theSESAR Operational Concept should work inpractice – this should be of benefit to the whole
EP3 validation program, not just to the safetyassessmentx it has helped correct some errors, inefficiencies andinconsistencies in the logical modelx it has proved very effective in identifying missing
or incorrect FSRs

Both stages examine the behavior of the system from astatic and dynamic perceptive.

159

D. Fowler, E. Perrin, R. Pierce

Because the threads provide an understanding of thesystem behavior that cannot be shown solely throughthe LM and individual FSRs, it follows that the threads
themselves should form part of the system design, andof the safety requirements.

Fig 19: Typical Evidence Structure
The Safety Assessment Report (SAR) records theprocess, and presents the findings, of the safetyassessment within the scope of Argument 1.
As explained above, the safety assessment is based on
three models of the ATM service / System – i.e. barrier,functional and logical. Because the information
associated with these models, and the description of
the operational environment, is quite lengthy andbecause much of the information could be ofsignificant use in non-safety areas as well, it was
decided to place it in separate Safety Design
Documents and to confine the SAR to the safety
analysis of the three models.

Of course, what thread analysis cannot assess are thedynamic aspects of the system behavior – hence thesafety assessment needs to make use also of the realtime and fast-time simulation exercises, which will
form a very important part of EP3 and SESAR
Development Phase. Nevertheless, thread analysis is avery cost-effective way of proving the correctness of
the logical design under a wide range of normal andabnormal conditions.
Furthermore, by “breaking” threads, it should bepossible to get a better understanding of the effects offailures within the system, and identify reversionarymodes of operation – i.e. it can be used to enhance theconventional,
failure-based
safetyassessment.
Otherwise, Stage 3 of Design Analysis is effectively aconventional, failure-based approach to safetyassessment and is not covered further in this paper.

4. CONCLUSIONSThe paper has explained why a broader and more
rigorous approach than that traditionally followed in
ATM, is needed for the safety assessment of the
SESAR Operational Concept.
It has shown that what has become known as the“systems-engineering approach” to safety assessment
has a sound theoretical basis.

3.7 Documenting the Results
Figure 18 shows the overall SESAR Safety Case
structure.

It has also outlined how the approach is being applied
to the major operational and technology changes thatare planned for introduction into European ATM overthe period up to 2020.

Executive
Summary

Vol 1
Apron/Taxiway
Operations
Safety Case

Vol 2
RunwayOperations
Safety Case

Vol 3
Terminal Area
Operations
Safety Case

Vol 4
En-route
Operations
Safety Case

So far, we have validated the approach for thedefinition phase and the functional and logical stagesof the design phase, of the safety lifecycle, for all fourphases of flight and are well into developing threads
for the initial design analysis for Runway and En-route
operations.

Vol 5
Network Mgt
Operations
Safety Case

Fig 18: SESAR Safety Case StructureThis structure allows the various volumes of the Safety
Case to be developed independently, provided all theinterfaces and interdependencies between the phases offlight are dealt with in the appropriate volumes – ingeneral, this proviso is taken care of by means of
Safety Requirements placed on one phase of flight byanother.

Our experience to date has shown that the approachdescribed herein is well able to meet the challenges ofwhat looks to be one of the most wide-ranging ATM
safety assessments ever undertaken. Nevertheless,provision has been made in the SESAR Development
Phase for further development and refinement of thedetailed methods, tools and techniques, within theabove framework, as the SESAR safety assessment
progresses through its lifecycle.

Figure 19 shows the main documentation structure fora typical volume of the SESAR Safety Case.

REFERENCES

Vol 3
Terminal Area
Operations
Safety Case

Argument 1[1] D Fowler, G Le Galo, E Perrin and S Thomas, So

it’s reliable but is it safe?, Proceedings of the 7th
US / Europe Seminar on ATM Research &Development, Barcelona, July 2007

Arguments 2 to 4[2] E Perrin, B Kirwan and R Stroup, A systemic

Safety Assessment
Report (Arg 1)
Terminal Area
Operations

model of ATM safety: the Integrated Risk Picture,
Proceedings of the 7th US / Europe Seminar on
ATM Research & Development, Barcelona, July
2007

Preliminary
Safety Case
Safety Design
Document (Arg 1)
Terminal Area
Operations[3] ICAO Doc 9854, Global ATM operational concept,

1st edition, 2005
Otherreferencesources160

ENRI International Workshop on ATM/CNS. Tokyo, Japan. (EIWAC 2009).

[4] SESAR

Consortium, the ATM deployment
sequence, D4, DLM-0706-001-02-00, January
2008[5] EUROCONTROL,

Safetymanual, version 2.2, 2006

case

Augmentation System (GBAS) Manager. Prior to that,
he worked as a Project Manager responsible for thedesign and development of aeronautical mobile
communication systems. As EUROCONTROL Safety
Assessment and Safety Case Manager, he currently
leads a team of safety practitioners at Brétigny, southof Paris, working on a range of short- and mediumterm ATM issues. He has made over 50 presentations
on aviation technical issues (COM, satellite navigation,
safety assessments) to international fora (GNSS,NAVSAT, ESREL, FAA Risk Conference, ATM R&D
Seminars, etc.). He currently works on the safetyvalidation of major aviation operational and technicalchanges and on safety techniques development to keep
pace with foreseen air traffic management evolutions,in particular with SESAR.

development[6] RTCA,

software considerations in airborne
systems and equipment certification, DO-178B /ED-12B,[7] IEC, functional safety of electrical/electronic[etc]safety related systems, IEC 61508, 2000 edition[8] SESAR Consortium, air transport framework – theperformance target, D2, DLM-0607-001-02-00a,
December 2006
[9] Episode 3, White paper on the SESAR safetytarget, D2.4.3-01, 29 September 2008

Ronald H Pierce was born in Glasgow, UK in 1948,
and studied at the University of Manchester where hegained his BSc and MSc degrees in computer science,
the latter by research.

AUTHOR BIOGRAPHY
Derek Fowler was born in Manchester, UK, in 1945.
He was awarded a BSc degree in aeronauticalengineering by the Royal Air Force College, Cranwell,UK, in 1968 and an MSc equivalent in aerosystems
engineering at the same college 1975.
He served as an engineer officer in the RoyalAir Force for 15 years before joining BAe Systems as aconsultant engineer, project manager and then Head of
the Laser Systems department. In 1990, he moved into
the ATM field, with the UK National Air Traffic
Services, as a senior project manager and then Deputy
Director for Oceanic Systems. His considerable
experience in systems engineering and interest in
system safety were then combined, in 1998, when hetook up successive senior technical positions with twoof the UK’s leading systems / safety consultancy
companies. For the past 5 years he has operated as anindependent safety consultant, setting up his own
company, JDF Consultancy, in 2005. Working undercontract for EUROCONTROL, he has provided safety
expertise to more than 30 ATM programmes and, since
January 2008, has been leading the initial safetyassessment of the SESAR operational concept, at their
Brétigny facility. He has many papers on ATM safetyissues to his credit, most of them on the developmentof safety engineering techniques to keep pace with theincreasingly rapid changes in ATM technology andoperations.
Mr Fowler is a Charted Engineer and a Fellowof the UK Institution of Engineering and Technology

From 1975 to 1993 he worked for a numberof the UK’s leading software houses, gaining extensive
experience in software engineering topics - compilers,
program analysis tools and software engineering
methods. Since 1993, he has worked as a Principal
Consultant for CSE International Ltd in Flixborough,UK, specializing in software and system safetyassessment for industry domains including ATM,
railway control and signalling, and automotive, and has
been responsible for the development of a number ofsafety cases for large-scale ATM projects such as new
operations rooms and their associated equipment. He
is currently working half of his time for
EUROCONTROL Brétigny on an initial safetyassessment of the SESAR operational concept. He is
the secretary of the working group responsible for the
maintenance of international functional safety standard
IEC 61508 Part 3. He has published a number of
papers in software engineering and safety topics andteaches courses in engineering safety management.
Mr Pierce is a Charted Engineer and a Fellowof the British Computer Society.
COPYRIGHT
The authors confirm that they, and/or their company or
institution, hold copyright of all original material
included in their paper. They also confirm they haveobtained permission, from the copyright holder of any
third party material included in their paper, to publish
it as part of their paper. The authors grant full
permission for the publication and distribution of theirpaper as part of the EIWAC 2009 proceedings or as
individual off-prints from the proceedings.”

Eric Perrin was born in Saint-Etienne, France in 1969.
He was awarded an Engineer degree in Aeronautics
and Computer Science from the French Civil Aviation
School (ENAC) in Toulouse in 1993.
He has more than 14 years experience of air
traffic management, 8 of which have been spent onsafety assessment and safety management. He joined
EUROCONTROL in 2002 as GPS Ground-Based161