Safety Case Development Manual V2.2_RI_13Nov06 EUROCONTROL

EUROCONTROL%20Safety-case-development-manual

User Manual:

Open the PDF directly: View PDF .
Page Count: 66

EUROPEAN ORGANISATION FOR THE SAFETY OF

AIR NAVIGATION

EUROPEAN AIR TRAFFIC MANAGEMENT

Safety Case Development Manual

DAP/SSH/091

Edition : 2.2

Edition Date : 13 Nov 2006

Status : Released Issue

Class : EATM Stakeholders

Safety Case Development Manual

Page ii Released Issue Edition: 2.2

DOCUMENT CHARACTERISTICS

TITLE

Safety Case Development Manual

EATMP Infocentre Reference:

Document Identifier Edition Number:

2.2

DAP/SSH/091

Edition Date:

13 Nov 2006

Abstract

This Safety Case Development Manual provides the reader with an overview of the methodology

being proposed for the construction and development of Safety Cases. Version 2.2 is a complete

rewrite of Version 1.3 which was published in 2003, taking into consideration user needs and recent

experience with Safety Case developments.

This Manual includes the concept of a Safety Case as presenting the entirety of argument and

evidence needed to satisfy oneself and the regulator with respect to safety. It does not provide

guidance on the generation or documentation of the evidence itself. Where separate guidance is

available, such as the ANS Safety Assessment Methodology (SAM) then this is referenced

accordingly. For further guidance on Safety Assessment see the SAM, or contact DAP/SSH.

Keywords

ESARR 3 Safety Argument Safety Case Lifecycle Safety Objectives

Goal Structuring Notation Safety Case Safety Management Safety Requirements

Contact Person(s)

Tel

Unit

Dr. Bernd TIEMEYER 95038 DAP/SSH

STATUS, AUDIENCE AND ACCESSIBILITY

Status Intended for Accessible via

Working Draft  General Public 

Intranet 

Draft  EATM

Stakeholders 

Extranet 

Proposed Issue  Restricted

Audience 

Internet (www.eurocontrol.int) 

Released Issue 

ELECTRONIC SOURCE

Path:

Host System Software Size

Windows_XP Microsoft Word 2002 1127 Kb

Edition: 2.2 Released Issue Page iii

DOCUMENT APPROVAL

The following table identifies all management authorities who have successively approved

the present issue of this document.

AUTHORITY NAME AND SIGNATURE DATE

Co-ordinator

Agency & EATM SMS

DAP/SSH

Bernd TIEMEYER

Chairman of the

SAMTF

Patrick MANA

Chairman of

Safety Team

Erik MERCKX

Director

DAS

Bo REDEBORN

Director

DAP

Guido KERKHOFS

Safety Case Development Manual

Page iv Released Issue Edition: 2.2

DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the present

document.

EDITION

NUMBER EDITION

DATE REASON FOR CHANGE PAGES

AFFECTED

1.3 07.07.03 Proposed Issue – Including editorial corrections All

1.41 29.11.04 Initial Draft of Revised Version All

1.42 13.12.04 Working Draft of Revised Version All

1.43 23.12.04 Further Draft of Revised Version All

1.44 01.02.05 Update following DAP/SAF internal review All

1.45

11.02.05

Chapter 5 and Appendix updated following DAP/SAF

internal review

Chap 5

and

Appdx C

1.5 25.02.05 Minor changes following final DAP/SAF internal review All

2.0 28.09.05 Proposed Issue following external stakeholder review All

2.1

03.09.06

Proposed Issue, incorporating further stakeholder

comments 4, 6, 8,

2.2 13.11.06 Released Issue, incorporating final stakeholder

comments 8, 17, 25

Safety Case Development Manual

Edition: 2.2 Released Issue Page v

CONTENTS

PREFACE..............................................................................................................................1

CHAPTER 1 – INTRODUCTION............................................................................................3

Purpose of the Manual ..................................................................................3

Structure of the Manual.................................................................................4

CHAPTER 2 – ESSENTIALS – GETTING STARTED...........................................................5

What is a Safety Case for?............................................................................5

Which Kind of Safety Case? .........................................................................6

Safety Cases and the Project Safety Lifecycle............................................7

Contents of a Safety Case.............................................................................9

Defining the Scope and Boundaries for the Safety Case..........................10

Setting the Context......................................................................................10

CHAPTER 3 – ESSENTIALS – ARGUMENT AND EVIDENCE..........................................13

Introduction..................................................................................................13

Safety Argument..........................................................................................13

Safety Evidence...........................................................................................14

CHAPTER 4 – GUIDANCE – PROCESS AND TECHNIQUES ..........................................17

Overview ......................................................................................................17

Determining the Safety Criteria ..................................................................18

Constructing a Safety Argument................................................................19

Gathering, Assessing and Presenting Safety Evidence ...........................23

Evidence – Safety Requirements Determination.......................................24

Evidence – Safety Requirements Satisfaction...........................................26

Developing a Safety Plan ............................................................................29

Format, Structure and Layout of the Safety Case .....................................30

Verifying the Safety Case............................................................................32

10.

ESARR Compliance.....................................................................................33

CHAPTER 5 GUIDANCE - GSN SAFETY ARGUMENT EXAMPLES.................................35

Safety Case Development Manual

Page vi Released Issue Edition: 2.2

Example Application of GSN – A “Project” Safety Case...........................35

Example Application of GSN – Unit Safety Cases.....................................45

Example Application of GSN – Preliminary Safety Cases ........................48

APPENDIX A

REFERENCES .........................................................................................51

APPENDIX B

GLOSSARY AND ABBREVIATIONS.......................................................53

GLOSSARY ....................................................................................................................53

ABBREVIATIONS...........................................................................................................55

APPENDIX C

SAFETY CASE DEVELOPERS AND REVIEWERS CHECKLIST............57

Safety Case Development Manual Preface

Edition: 2.2 Released Issue Page 1

PREFACE

Background

Related Documents

EATM SMS Context

User Community

Feedback

“Health Warning” !!

Version 2.2 of the Safety Case Development Manual has been

developed based on recent experience, user feedback and

lessons learned since Version 1.3 was published in July 2003.

The new Manual tries to explain in simple terms the ‘Essentials’

of how to construct a Safety Case and then provides supporting

‘Guidance’ and ‘Examples’. It is intended primarily for use within

the EUROCONTROL Agency but may also be used (where

appropriate

) by the Member States.

The provisions of the Manual are intended to be consistent with

ESARRs and the EUROCONTROL ANS Safety Assessment

Methodology (SAM), to which numerous references are made

herein. In particular, the Manual as a whole is intended to

satisfy the requirements of paragraph 5.3 of ESARR 4

concerning the documentation of the arguments and evidence

associated with the risk assessment and mitigation processes.

The Manual provides a product description for the Safety Case

described in Element 5 (Risk Assessment and Mitigation) of the

EATM Safety Management Handbook. Organisational issues

are dealt with in Element 3 (Organisation and Structure).

The Manual is intended primarily for safety professionals who

have received training in SMS and the EUROCONTROL SAM.

We believe that it will be of most immediate use to the willing

developer but accept that it could present some difficulties for

the uncertain starter; we also believe that it has something to

offer to the confident adopter

Therefore, the contents of the Manual will be supported by

related training, and readers (particularly, but not exclusively

willing developers and uncertain starters) are urged to

undertake this training and the related EUROCONTROL SAM

training before embarking on the development of a Safety Case

for an operational application.

The users of this Manual are invited to provide any feedback

and suggestions for improvement on this current version to me,

which will be taken into consideration when a future updated

Version is produced.

Finally, this Manual cannot give a complete insight into all

aspects of Safety Assessment and Safety Case development

nor provide ready made solutions to fit every situation.

“Where appropriate” is inserted here because there is no explicit requirement in ESARRs for ANSPs

to produce Safety Cases. EUROCONTROL has chosen the Safety Case approach for EATM

Programmes and Domain Activities because experience has shown this approach to be effective for

these applications.

See EUROCONTROL SAM [5] for explanation of these terms

Preface Safety Case Development Manual

Page 2 Released Issue Edition: 2.2

PAGE INTENTIONALLY LEFT BLANK

Safety Case Development Manual Introduction

Edition: 2.2 Released Issue Page 3

CHAPTER 1

– Introduction

1. Purpose of the Manual

What does it do?

Who is it for?

What is it for?

What does it not do?

This Safety Case Development Manual provides guidance on

the development of Safety Cases as a means of structuring and

documenting the demonstration of the safety of an ATM service

or new / modified System

The Manual is intended for use by those, employed on projects

or in service-provider organisations, who have to:

• Produce Safety Cases – eg safety practitioners;

• Approve Safety Cases – eg programme managers and

heads of ATSUs;

• Review Safety Cases – eg safety department staff.

The aim is to achieve sound, well-presented Safety Cases

through the adoption of a logical, rigorous, consistent and

accurate approach that is based on good safety practice.

Whereas this Manual should aid the process of developing and

presenting a Safety Case, it cannot give assurance of the

validity of the end product, and it does not, therefore, relieve its

users of their responsibility to provide such assurance.

The Manual does not provide guidance on how to carry out a

safety assessment – see the EUROCONTROL SAM [5] for that

– rather it describes how to present the results of a safety

assessment, in the context of a Safety Case.

Chapter 1 Safety Case Development Manual

Page 4 Released Issue Edition: 2.2

As the Manual is intended to be used within the framework of a

Safety Management System (SMS), it does not address

questions, such as what is a change and when should a Safety

Case be produced – these are assumed to be addressed by the

SMS

. Rather, the starting point for the Manual is the point at

which it has been decided to produce a Safety Case for a

particular ATM service or change (a so-called “substantial

change” in this document).

2. Structure of the Manual

Essentials - Getting

Started

Essentials – Argument

and Evidence

Guidance – Process

and Techniques

Guidance - Examples

References

Glossary

Checklists

The remainder of this Manual is presented in a further 4

Chapters, covering the Essentials of Safety Case Development

and supporting Guidance, as follows.

Chapter 2 explains the background to Safety Cases and

provides the key points in planning the development of a Safety

Case.

Chapter 3 presents the essentials of the Safety Case itself.

Chapter 4 provides guidance in support of Chapters 2 and 3,

including the use of Goal-structuring Notation (GSN). The

Guidance may be accessed directly or via links embedded in

the relevant parts of those Chapters.

Chapter 5 provides generic examples of structured Safety

Arguments using GSN. The main example is the introduction of

a substantial change to an ATM service / system. Variations of

that Safety Argument for an on-going ATM service and for a

typical limited-scope Safety Case are also explained.

Appendix A provides a list of the references called up in the

Manual.

The EATMP Glossary document [4] facilitates the search and

use of acronyms, abbreviations, terms and definitions most

frequently used within the EATM Programme. As the EATMP

Glossary document includes more than 5,800 acronyms and

2,000 definitions, a summary of the terms commonly used in

Safety Case development is provided at Appendix B.

Appendix C contains checklists for use by Safety Case

developers, reviewers and approvers in assessing the quality of

the argument structure and presentation of the Safety Case.

The term ‘System’ is used throughout this manual to include airspace, equipment, people and

procedures.

For guidance on “what is a change” please see the SAM [5] Guidance Material, Part IV, Appendix H.

Safety Case Development Manual Getting Started

Edition: 2.2 Released Issue Page 5

CHAPTER 2

– Essentials –

Getting Started

1. What is a Safety Case for?

A Lesson from History

ICAO Obligation

The Burden of Proof

In the investigation into the Piper Alpha accident [14] Lord

Cullen wrote:

“Primarily the Safety Case is a matter of ensuring that every

company produces a formal safety assessment to assure

itself that its operations are safe.

Only secondarily is it a matter of demonstrating this to a

regulatory body. That said such a demonstration both meets a

legitimate expectation of the workforce and the public and

provides a sound basis for regulatory control.”

ICAO Annex 11 places an obligation on the providers of Air

Traffic Management services to ensure the safety of air traffic,

in respect of those parts of the ATM System and supporting

services within their managerial control.

Implicit to this obligation is the requirement on those with

managerial control to demonstrate positively that the relevant

Safety Regulations are satisfied. In essence there is a “burden

of proof” on Air Navigation Service Providers to show that

acceptable levels of safety

are, and continue to be, achieved.

As defined by the Safety Criteria – see Chapter 4, section 2

Chapter 2 Safety Case Development Manual

Page 6 Released Issue Edition: 2.2

Primary Purpose

Relationship with

Regulatory Approval

Relation to Safety

Management System

Relation to Safety

Assessment

Broadly, the Safety Case is the documented assurance (ie

argument and supporting evidence) of the achievement

and maintenance of safety. It is primarily the means by

which those who are accountable for service provision or

projects

assure themselves that those services or

projects are delivering (or will deliver), and will continue to

deliver, an acceptable level of safety.

As the main objective of safety regulation is to ensure that

those who are accountable for safety discharge their

responsibilities properly, then it follows that a Safety Case

which serves the above primary purpose should also

provide an adequate means of obtaining regulatory

approval for the service or project concerned.

In the context of a Safety Management System, the Safety

Case can be a means of documenting and recording the

safety of a service or system. Conversely, the

implementation of a Safety Management System would

provide evidence to support a Safety Case.

The development of a Safety Case is not an alternative to

carrying out a Safety Assessment, in accordance with, for

example, the EUROCONTROL SAM [5]; rather, it is a

means of structuring and documenting a summary of the

results of a Safety Assessment, and other activities (eg

simulations, surveys etc), in a way that a reader can readily

follow the logical reasoning as to why a change (or on-

going service) can be considered safe.

2. Which Kind of Safety Case?

Types

Safety Cases may come in many forms but most, if not all, can

be thought of as falling into one of two categories, as follows:

• those which are used to demonstrate the safety of an on-

going service – these are known herein as Unit Safety

Cases; and

• those which are used to demonstrate the safety of a

substantial change to that service (and/or underlying

system) – these are known herein as Project Safety Cases.

Unit Safety Case

The two categories are interrelated, as explained below.

An ATSU (or other major, safety-related service / facility) may

decide to produce, and maintain, a (Unit) Safety Case in order

to show that the on-going, day-to-day operations are safe and

that they will remain so indefinitely.

Safety Case Development Manual Getting Started

Edition: 2.2 Released Issue Page 7

Project Safety Case

A Unit Safety Case would include typically an a priori safety

assessment (to show that service / system is predicted to be

safe), together with the results of safety audits, surveys and

operational monitoring (to show that, up that point in time, it

actually has been safe). It should also demonstrate that

processes are in place to ensure that all future changes to the

ATSU’s system will be managed safely through, inter alia,

Project Safety Cases.

An ATSU (or other responsible organisation) may also decide to

produce a Project Safety Case when a particular substantial

change to an existing safety-related service / system (including

the introduction of a new service / system) is to be undertaken.

A Project Safety Case would normally consider only those risks

created or modified by the change and rely on an assumption

(or evidence from the corresponding Unit Safety Case) that the

pre-change situation is at least tolerably safe.

Project Safety Cases are used to update, and are usually

subsumed into, Unit Safety Cases

Further details of both Unit Safety Cases and Project Safety

Cases are given in section 3 below and in Chapter 5.

3. Safety Cases and the Project Safety Lifecycle

A simplified view of a typical project lifecycle is shown in the

diagram overleaf.

Safety Considerations

This is an EATM SMS process to identify the main safety issues

associated with a project as soon as possible after an

Operational Concept has been developed and to help in

deciding whether a full Safety Plan and Safety Case are

required. It provides an initial assessment of the safety

implications of the project, as the basis for developing a Safety

Plan in which the detailed safety activities will be specified. It

should address, inter alia, what the project is seeking to achieve

(eg to deliver benefits in capacity, efficiency and/or safety), the

possible impact on safety (in general terms only, since a safety

assessment would not have been started at this stage), the

criteria for deciding what is “safe” in the context of the Project

and, in broad terms, the strategy for demonstrating safety.

The distinction between services and projects / systems is to emphasise the difference between Unit

and Project (or System) Safety Cases – see section 2. The generic term “project” should be taken to

include EATM Programmes and Domain Activities.

However, this is not meant to imply that a Unit Safety Case is merely a collection of project Safety

Cases!

Chapter 2 Safety Case Development Manual

Page 8 Released Issue Edition: 2.2

Safety

Considerations Operational

Concept

Initial

Safety

Argument

FHA

PSSA

Implementation

Transfer into

Operation

Safety

Plan

Project

Safety

Case

Unit

Safety

Case

Evidence

Approval

Evidence

Update, if required

Safety

Monitoring

Reports

Update

Evidence

SSA

Integration

Operation &

Maintenance

Safety

Considerations Operational

Concept

Initial

Safety

Argument

FHA

PSSA

Implementation

Transfer into

Operation

Safety

Plan

Project

Safety

Case

Unit

Safety

Case

Evidence

Approval

Evidence

Update, if required

Safety

Monitoring

Reports

Update

Evidence

SSA

Integration

Operation &

Maintenance

Initial Safety Argument

Safety Plan

Safety Assessment:

FHA

PSSA

Building on the Safety Considerations, the initial Safety

Argument should be as complete as possible and at least

sufficient to provide a set of goals for the Safety Plan to

address. It also provides the starting point, and framework, for

the development of the Project Safety Case, although it needs

to be recognised that the initial view of what the Safety

Argument should look like may need to change, depending on

the results of the subsequent safety assessment.

Specifies the safety activities to be conducted throughout the

project lifecycle and the responsibilities for their execution.

The three main phases of safety assessment (FHA, PSSA and

SSA) provide much of the Evidence needed for the Project

Safety Case, as follows:

o FHA produces Safety Objectives to limit the frequency of

occurrence of hazards, such that the associated risk would

be acceptable, and the external means of mitigating the

effects of the hazards

o PSSA produces Safety Requirements and Assurance Levels

for the system elements.

o SSA produces the assurance that the Safety Requirements

See further discussion on “external mitigation means” in the Note at end of this Chapter

Safety Case Development Manual Getting Started

Edition: 2.2 Released Issue Page 9

SSA

Implementation &

Integration

Transfer into Operation

Operational Service

Unit Safety Case

and Safety Objectives are met in the implemented system

and that risk is acceptable.

For further information on safety assessment, see the SAM [5].

This phase covers all the preparation needed in order to bring

the new / modified system – the subject of the Safety Case –

into operational service.

Transfer into Operation of the new/modified system would

normally be subject to a risk assessment and mitigation for this

phase itself (part of the Project Safety Case) and be concluded

by finalisation and regulatory approval of the Project Safety

Case.

Because most, if not all, of the preceding safety assessment

work is predictive in nature, it is important that further assurance

of the safety is obtained from what is actually achieved in

operational service. If the operational experience differs

significantly from the results of the predictive safety

assessment, it may be necessary to review and update the

Project Safety Case.

Once a satisfactory steady state has been achieved, it would be

appropriate to update the Unit Safety Case (if one exists) with

the information from the Project Safety Case thus establishing a

new safety baseline for the on-going operational service.

4. Contents of a Safety Case

Aim

Purpose

Scope

System Description

Justification

Argument

Evidence

Caveats

A good Safety Case (of whichever type) should include, at least:

• what the Safety Case is trying to show - this should be

directly related to the Claim that the subject of the Safety

Case is acceptably safe;

• why is the Safety Case being written and for whom;

• what is, and is not, covered - see section 5 below;

• a description of the system / change and its operational /

physical environment, sufficient only to explain what the

Safety Case addresses and for the reader to understand the

remainder of the Safety Case – see section 6 below;

• for project Safety Cases, the justification for introducing the

change (and therefore potentially for incurring some risk);

• a reasoned and well-structured Safety Argument showing

how the Aim is satisfied – see Chapter 3, section 2 below;

• supporting Safety Evidence to substantiate the Safety

Argument – see Chapter 3, section 3 below;

• all Assumptions, outstanding safety Issues, and any

Limitations or restrictions on the operation of the system;

Chapter 2 Safety Case Development Manual

Page 10 Released Issue Edition: 2.2

Conclusions

• a simple statement to the effect that the Aim has been

satisfied, subject to the stated Caveats.

Chapter 4, section 8 provides further guidance on the content,

structure and layout of a Safety Case

5. Defining the Scope and Boundaries for the Safety Case

Scope Definition

Lifecycle Limitations

Defining the scope and boundaries of the Safety Case is an

essential first step in the development of the Safety Case. It

should explain clearly:

• what the Safety Case covers (and does not cover);

• boundaries of responsibility with respect to managerial

control and other stakeholders;

• relationship with other Safety Cases, if applicable;

• applicability and compliance with safety regulations and

standards;

• any assumptions made in defining the scope, boundaries or

safety criteria.

A Safety Case may be (temporarily) restricted to the safety of a

new concept, and therefore be conditional on the subsequent

complete and correct implementation of that concept by the

responsible organisation. This is the situation on those EATM

Programmes (and similar activities) for which EUROCONTROL

is not responsible for implementation; the output would then be

a validated set of Safety Requirements (from the PSSA).

The term Preliminary Safety Case is used herein to cover such

situations, and it should be supported by guidance material for

the subsequent implementation of the Safety Requirements and

for the development of a full Safety Case. An example of a

Preliminary Safety Case, and the sort of guidance that should

accompany it, are given in Chapter 5, section 3.

6. Setting the Context

Rationale

Content

It is vital to fully describe the operational environment to which

the Safety Case applies and the system configuration on which

the Safety Case (and underlying Safety Analysis) is based.

The description of the Context should include:

Safety Case Development Manual Getting Started

Edition: 2.2 Released Issue Page 11

• the purpose of the system from a safety perspective;

• the interfaces with other systems including people,

procedures and equipment;

• the operational environment – including all characteristics

that may be affected and elements that are relied upon,

when assessing acceptable levels of safety;

• A reference to (together with a summary of) Concept of

Operations that explain how the system, and the service that

it supports, are intended to operate

Note on External Mitigation Means (§3 of this chapter):

External Mitigation Means are those mitigations of the consequences of a hazard that lie outside of the

scope of the service / system covered by the FHA. They are often recorded as "assumptions"

concerning, for example, the Operational Environment (levels, type and patterns of traffic etc), other

elements of the system (aircraft equipage, airline compliance to some operation requirements, aircraft

equipment certification etc) and other service providers (adjacent ATSUs, CFMU, Military etc). They

may be either pre-existing or newly identified because of the nature of the "change" covered by the

FHA.

Two matters are crucial to the safety assessment: firstly, as the Assumptions have an impact on the

way the Safety Objectives were set, then the latter are valid only if the former are met; and secondly,

therefore, these Assumptions must be properly recorded, demonstrated as being valid / satisfied prior

to operations, and then continuously monitored and confirmed in operational service, along with the

Safety Requirements that emerge from the PSSA.

Chapter 2 Safety Case Development Manual

Page 12 Released Issue Edition: 2.2

PAGE INTENTIONALLY LEFT BLANK

Safety Case Development Manual Argument and Evidence

Edition: 2.2 Released Issue Page 13

CHAPTER 3

– Essentials –

Argument and Evidence

1. Introduction

Overview

Non-prescriptive

This Chapter presents the essential points of:

• the construction of Safety Arguments;

• the collation, review and presentation of Safety Evidence.

The information presented draws on current good practice

without prescribing a particular methodology, and is supported

by references to the Guidance in Chapter 4.

2. Safety Argument

What is a Safety

Argument?

Making the Claim

Supporting the Claim

A Safety Argument is a statement (or a set of statements) that is

used to assert that the service or system concerned is safe, and

should be developed as follows.

The Safety Argument must start with a top-level statement

(Claim) about what the Safety Case is trying to demonstrate in

relation to the safety of the service or system.

The Claim must be supported by:

• Safety Criteria, which define what is safe in the context of

the Claim;

• for Project Safety Cases, the Justification for introducing

Chapter 3 Safety Case Development Manual

Page 14 Released Issue Edition: 2.2

Structuring the

Argument

Guidance

the change to the service or system concerned;

• the Operational Context for the Claim;

• any fundamental Assumptions on which the Claim relies.

The decomposition of the Claim into lower-level Arguments

provides the essential links between the Claim and the wealth of

Evidence needed to show that the Claim is valid.

In performing this decomposition, it is important that:

• each Argument in the structure is expressed as a simple

predicate – ie a statement that can be only true or false;

• the Argument structure does not contain any negative or

inconclusive Arguments

;

• the set of Arguments at each level of decomposition is

necessary and sufficient to show that the parent Argument is

true;

• a valid counter-Argument, which would negate the parent

Argument, does not exist

;

• where the rationale for decomposition of an Argument into

lower-level Arguments is not self evident, it is explained by

supporting text;

• the number of levels of decomposition is appropriate to the

complexity of the Safety Case and/or supporting Evidence;

• each branch of the Safety Argument structure is terminated

in supporting Evidence;

• there is a clear distinction between, and correct use of,

Direct (product-based) and Backing (process-based)

Arguments and related Evidence.

Further guidance on the structuring of Safety Arguments is

given in Chapter 4, section 3, and generic ATM examples are

presented in Chapter 5.

3. Safety Evidence

What is Safety

Evidence?

Safety Evidence is information, based on established fact or

expert judgement, which is presented to show that the Safety

Argument to which it relates is valid (ie true).

The essential rules of Evidence are as follows:

Necessity

• Evidence must be presented only to the degree and extent

Safety Case Development Manual Argument and Evidence

Edition: 2.2 Released Issue Page 15

Sufficiency

Appropriateness

Rigour

Relevance

Guidance

necessary to support the related Argument;

• Evidence must show that the related Argument is true in a

way that is clear, unequivocal, conclusive and, wherever

possible, objective;

• the type of Evidence – from safety analysis, design,

simulation, test, previous usage, compliance with standards

etc – must be appropriate to the Argument;

• the rigour of the Evidence must be appropriate to the

associated risk;

• Evidence must actually relate to the correct configuration of

the system under consideration.

Further guidance on the gathering, assessing and presenting

Evidence is given in Chapter 4, section 4.

The main point here is that lack of Evidence of risk is not Evidence of lack of risk!

This point is concerned only with the sufficiency of the Argument – sufficiency of the Evidence is

covered in section 3.

The point here concerns only irrelevant Evidence. Clearly any Evidence which actually counters the

Argument must not be ignored; on the contrary, the validity (or at the very least the phrasing) of an

Argument must be reconsidered in the light of such Evidence

Chapter 3 Safety Case Development Manual

Page 16 Released Issue Edition: 2.2

PAGE INTENTIONALLY LEFT BLANK

Safety Case Development Manual Process and Techniques

Edition: 2.2 Released Issue Page 17

CHAPTER 4

– Guidance –

Process and Techniques

1. Overview

Context

Scope

This Chapter provides guidance in support of the requirements

stated in Chapters 2 and 3 above. Whereas this guidance is

based on experience gained on the development of Safety

Cases by EUROCONTROL on a wide range of EATM

Programmes, it is intended to be applicable also to other

environments – eg service provision.

The guidance covers the following areas:

• determining the Safety Criteria - section 2;

• constructing a Safety Argument, using a recognised

notation that is considered to be good practice – ie Goal-

structuring Notation (GSN) - section 3;

• general issues concerning gathering, collating,

assessing and presenting Safety Evidence - section 4;

• specific issues concerning Evidence of Safety

Requirements determination - section 5;

• general issues concerning Safety Requirements

satisfaction - section 6;

• developing a Safety Plan - section 7;

• deciding the format, structure and layout of a Safety

Case - section 8;

Chapter 4 Safety Case Development Manual

Page 18 Released Issue Edition: 2.2

• verifying the Safety Case - section 9;

• ESARR compliance - section 10.

2. Determining the Safety Criteria

Absolute

Relative

Reductive

Selecting Criteria

Safety Criteria are essential to the definition of what is safe in

the context of the top-level Safety Claim

Basically, they fall into three categories as follows:

• Compliance with a defined target – eg the ESARR 4 Risk

Classification Scheme (RCS) or ICAO Target Level of Safety

(TLS) – or portion thereof. Such criteria are usually

quantitative;

• Relative to an existing (or previous) level of safety. Such

criteria may be quantitative or qualitative;

• Where the risk is required to be reduced as far as

reasonably practicable. Such criteria are usually qualitative.

In general, absolute criteria are preferred since satisfaction of

them does not depend on proof of past safety achievement and

such proof may be difficult if a suitable baseline does not exist

or sufficient historical data is not available.

However, in some cases, there may be a problem in

establishing what would be a suitable target on which to base

the criterion because either:

• a regulatory target has not been set for the operational

environment concerned

; or

• for Project Safety Cases, it may not be feasible to determine

what portion of the overall target it would be reasonable to

allocate to the system concerned.

As an alternative to the absolute approach, a relative Safety

Argument (ie based on a relative criterion) could be use for a

Project Safety Case

if:

• a well-defined baseline, prior to the introduction of (or

change to) a ‘system’, could be established; and

• it can be shown, or at least reasonably be assumed, that the

baseline situation was safe.

The justification for a relative approach is the ATM 2000+ [1]

Safety Objective which requires that risk shall not increase and

preferably decrease, relative to historical achievement. The

This is being addressed by the current (2005) EUROCONTROL TLS study

For Unit Safety Cases an absolute approach should always be the primary criterion.

Safety Case Development Manual Process and Techniques

Edition: 2.2 Released Issue Page 19

Multiple Criteria

ESARR 4 RCS, although normally considered to be an absolute

measure, is actually a quantified interpretation of the ATM

2000+ Safety Objective

A reductive approach is called for by ESARR 3 (paragraph

5.1.4), which requires ANSPs to reduce risk as far as

reasonably practicable. It is an important criterion for in-service

safety monitoring – especially regarding incident investigation

and corrective action.

It is usual to specify more than one type of criterion, and

sometimes all three. In ATM, reducing risk as far as reasonably

practicable is rarely adequate on its own

but it is often useful in

support of one (or both) of the other two criteria.

Use of Risk

Classification Schemes Risk classification schemes (RCS)

are often used as criteria

on which to base absolute Arguments. However, experience

has shown that a lack of understanding by the user as to how

the RCS was originally derived can lead to inappropriate use. If

RCS are used, it is important that the user understands:

• at what level in the system hierarchy the values are intended

to be applied;

• where the probability/frequency values used in the scheme

came from and whether they are (still) valid;

• to what operational environment the values apply – eg type

of airspace, traffic patterns, traffic density, spatial dimension,

phase of flight etc;

• how the aggregate risk, as specified in ESARR 4 for

example, can be deduced from analysis of individual

hazards, in restricted segments of the total system.

These issues should not be a problem for the user in an

organisation that has a single, well-founded RCS, applicable to

all operational environments.

All other RCS users should be aware of, and address, the

issues raised in each of the above bullets.

For further guidance on RCS, please see SAM FHA Chapter 3

GM E, based on ED-125 [15].

3. Constructing a Safety Argument

Requirements Since the Safety Argument forms the framework of a Safety

See ESARR 4 [9], Appendix A, Endnote (2)

Both ATM 2000+ and ESARR 4 require, as a minimum, that risk must not increase – reducing risk

as far as reasonably practicable on its own does not ensure that this minimum requirement is met.

The comments here are aimed at the use of Risk Classification Schemes to determine what is a

tolerable level of risk, not at the use of Severity Classification / Categorisation Schemes proposed in,

inter alia, ESARR 2, ESARR 4 and the EUROCONTROL ANS Safety Assessment Methodology.

Chapter 4 Safety Case Development Manual

Page 20 Released Issue Edition: 2.2

Case, it is important that the Argument is set out in a rigorous,

GSN Solution

hierarchical and well-structured and easily-understood way.

Goal-structuring Notation (GSN), developed by the University of

York, provides a graphical means of setting out hierarchical

Safety Arguments, with textural annotations and references to

supporting Evidence.

The logical approach of GSN, if correctly applied, brings some

rigour into the process of deriving Safety Arguments and

provides the means for capturing essential explanatory material,

including assumptions, context and justifications, within the

argument framework.

The diagram below shows, in an adapted form of GSN, a

specimen Argument and Evidence structure to illustrate the

GSN symbology most commonly used in EUROCONTROL ATM

Safety Cases.

Argument

Arg 1

Fig n

Overall

Argument /

Claim

Arg 0

Argument

Arg 2

Argument

Arg n

Continuation

page

A0001

Assumption

J0001

Justification

C0001

Context

St0001

Strategy

Argument

Arg 1.2

Argument

Arg 1.1

Ref

Evidence

Ref

Evidence

Cr001

Criteria

Argument

Arg 1

Fig nFig n

Overall

Argument /

Claim

Arg 0

Overall

Argument /

Claim

Arg 0

Argument

Arg 2

Argument

Arg n

Continuation

page

A0001

Assumption

J0001

Justification

C0001

Context

St0001

Strategy

Argument

Arg 1.2

Argument

Arg 1.1

Ref

Evidence

Ref

Evidence

Cr001

Criteria

An Argument should take the form of a simple predicate - ie a

statement which can be shown to be only true or false.

GSN provides for the structured, logical decomposition of

Arguments into lower-level Arguments. For an Argument

structure to be sufficient, it is essential to ensure that, at each

level of decomposition:

Argument

Arg 1.1

Argument

Arg 1.1

Safety Case Development Manual Process and Techniques

Edition: 2.2 Released Issue Page 21

• the set of Arguments covers everything that is needed in

order to show that the parent Argument is true;

• there is no valid (counter) Argument that could undermine

the parent Argument.

In the above diagram, for example, if it can be shown that Arg 1

is satisfied by the combination of Arg 1.1 and Arg 1.2, then we

need to show that Arg 1.1 and Arg 1.2 are true in order to show

that Arg 1 is true.

If this principle is applied rigorously all the way down through

and across a GSN structure, then it is necessary to show only

that each Argument at the very bottom of the structure is

satisfied (ie shown to be true) in order to assert that the top-

level Claim has been satisfied. Satisfaction of the lowest-level

Arguments is the purpose of Evidence.

Unnecessary (or misplaced) Arguments do not in themselves

invalidate an Argument structure; however, they can seriously

detract from a clear understanding of the essential Arguments

and should be avoided. The cover-up method illustrated in the

three GSN diagrams below can be used to determine identify

unnecessary and misplaced Arguments.

A=True

B=True C=True

E=TrueD=True

A=True

B=True C=True

E=True

D=True

A=True

B=True C=True

E=True

F=True

If this is complete

and correct …

…then D is incorrectly

positioned … …and F is

unnecessary…

D=True

A=True

B=True C=True

E=TrueD=True

A=True

B=True C=True

E=True

D=True

A=True

B=True C=True

E=True

F=True

If this is complete

and correct …

…then D is incorrectly

positioned … …and F is

unnecessary…

D=True

It follows from the above that, for an Argument structure to be

considered to be complete, every branch must be terminated in

a reference to the item of Evidence that supports the Argument

to which it is attached.

Evidence therefore must be:

• appropriate to, and necessary to support, the related

Argument - spurious Evidence (ie information which is not

relevant to an Argument) must be avoided since it would

serve only to confuse the “picture”;

• sufficient to support the related Argument - inadequate

Ref

Evidence

Chapter 4 Safety Case Development Manual

Page 22 Released Issue Edition: 2.2

evidence undermines the related Argument and

consequently all the connected

higher levels of the structure.

Strategies are a useful means of adding “comment” to the

structure to explain, for example, how the decomposition will

develop. They are not predicates and do not form part of the

logical decomposition of the Argument; rather, they are there

purely for explanation of the decomposition.

An Assumption is a statement whose validity has to be relied

upon in order to make an Argument.

Assumptions may also be attached to other GSN elements

including Strategies and Evidence.

Context provides information necessary for an Argument (or

other GSN element) to be understood or amplified.

Context may include a statement which limits the scope of an

Argument in some way.

A Justification is used to give a rationale for the use or

satisfaction of a particular Argument or Strategy. More

generally it can be used to justify the change that is the subject

of the Safety Case.

Criteria are the means by which the satisfaction of an Argument

can be checked.

Numbering It is recommended that Arguments be numbered hierarchically

(eg, Arg 1.1) to reflect their logical structure.

Strategies, Assumptions, Context, and Criteria should be

numbered sequentially (eg, St0001) since they elaborate, but do

NOT form part of, the logic of the structure.

It is recommended that Evidence be numbered according to its

source reference and that the Evidence ‘bubble’ contains a brief

indication of the form that the Evidence takes.

Other Symbology

A Choice can be used while a Safety Argument is being

developed to show a decision point between alternative

Strategies. However, they must be removed before a Safety

Argument is finalised.

A Model is some representation of the system, sub-system or

environment – eg Simulations, Data Flow Diagrams, Circuit

Layouts, State Transition Diagrams etc.

A Stakeholder is the person or role responsible for ensuring

satisfaction of an Argument, Strategy, or Choice.

Constraints are used to restrict the way in which an Argument

can be solved; they are restrictions imposed on the

interpretation of the parent Argument.

St0001

Strategy

A0001

Assumption

C0001

Context

J0001

Justification

Cr001

Criteria

Cr001

Criteria

Safety Case Development Manual Process and Techniques

Edition: 2.2 Released Issue Page 23

A Problem is attached to an Argument to indicate that there is a

possible obstacle to showing that it is true. Problems can also

be attached to other GSN elements.

Examples of the application of GSN to generic Safety

Arguments are presented in Chapter 5.

4. Gathering, Assessing and Presenting Safety Evidence

Importance

Direct and Backing

General Attributes

Necessity

Evidence is the heart of every case and ultimately it is on the

quality and completeness of the Evidence that the validity of a

Safety Case depends. Of course, a well-structured Safety

Argument is very important but only insofar as it provides the

context for, and thus facilitates interpretation of, the Evidence.

In decomposing the Safety Arguments, the following two main

types of Argument (and related Evidence) are used:

• that which shows that a particular objective has been

achieved (ie that a higher level Argument or Claim has been

satisfied) – this is referred to as Direct Argument and

Evidence;

• that which shows that the Direct evidence is trustworthy (ie

that it can be relied upon) – this is referred to as Backing

Argument and Evidence.

Direct Evidence may be thought of as being that which relies

directly on the observable properties of a product (ie the output

of a process), supporting a logical Argument as to how the

product satisfies its safety objectives or requirements, as

appropriate.

Backing Evidence is obtained from the properties of the

processes by which Direct Evidence was obtained, and shows

that those processes, tools and techniques, human resources

etc were appropriate, adequate and properly deployed.

The points below expand upon the “essential rules” outlined in

Chapter 3, section 3 above.

Evidence must be presented only to the degree and extent

necessary to support the related Argument.

The issue here is that, in the context of an Argument-based

approach, any “Evidence” which is unrelated to a part of that

Argument is not only of no value but could also serve as a

distraction from those aspects of the Safety Case that are

relevant. On the other hand, any Evidence which actually

undermines the validity of an Argument must not be ignored –

the existence of such Evidence must be acknowledged and

explained fully in the Safety Case.

Chapter 4 Safety Case Development Manual

Page 24 Released Issue Edition: 2.2

Sufficiency:

o Clarity, and

Conclusiveness

o Objectivity

Appropriateness

Rigour

Relevance

Evidence must be sufficient, as follows.

It is bad (but unfortunately not uncommon!) practice to present

an element of a structured Argument and then refer to a mass of

information as “Evidence” to substantiate the Argument.

It is vital to the integrity of the Safety Case that the Evidence be

presented in such a way that is clear to the reader that the

Evidence does actually show the related Argument to be true,

“beyond all reasonable doubt”.

Where Evidence is contained in appendices or external

documents, a summary justifying the adequacy of the Evidence

should be presented (in the Safety Case) along with the

associated Argument. It is not sufficient to merely reference the

Evidence with statements such as “Evidence to support the

Argument is presented in ….”

Wherever possible, Evidence should consist of proven facts –

eg, the results of a well-established process such as simulations

and testing. Only where such objective Evidence is not

available should Evidence based on expert opinion be used,

and then only when the credentials of the expert(s) and the

means of eliciting the opinion are adequate and have been

presented as Backing Evidence.

The type of Evidence, from safety analysis, design, simulation,

test, previous usage etc, must be appropriate to the Argument –

see sections 5 and 6 below.

The rigour of the Evidence must be appropriate to the

associated risk. This is the principle behind the Assurance

Level concept in ESARR 6 [11] (for software) and the

EUROCONTROL ANS Safety Assessment Methodology [5] for

software, procedures and human aspects.

Evidence must relate to the configuration of the system and

operational environment under consideration - eg a correct and

known:

• version of the equipment, procedures, training, etc.;

•

documentation used in the production of that version;

• range of configuration data.

Application How the above should be applied specifically to the two main

stages of the safety development lifecycle – requirements

determination and requirements satisfaction - is discussed

below, in sections 5 and 6 respectively.

5. Evidence – Safety Requirements Determination

What are Safety

Requirements To paraphrase ESARR 4 [9], Safety Requirements are means

by which the necessary risk reduction measures identified in the

hazard and risk analysis are formally

specified. Necessary in

In the normal English meaning of the word.

Safety Case Development Manual Process and Techniques

Edition: 2.2 Released Issue Page 25

this context means necessary in order to achieve the required

safety levels, as defined by the Safety Criteria (see section 2

above) and translated into specific Safety Objectives during the

Functional Hazard Assessment [5]

Role of Safety

Requirements in ATM

Types of Safety

Requirement

Direct Evidence of

Safety Requirements

Determination

Backing Evidence of

Safety Requirements

Determination

The primary purpose of ATM is to reduce the risk of accident to

air traffic that would otherwise exist. The amount of risk

reduction is determined primarily by the functionality and

performance of the ATM systems elements, including

equipment, people and procedures. However, failure within the

ATM system can cause risk to increase again, either by

reduction in functionality or performance, or by the introduction

of new risk caused by corruption of the outputs of ATM

functions.

Therefore, in order to achieve a net safety benefit from ATM, the

reduction in risk afforded by the desired functional and

performance properties of ATM needs to be substantially greater

that any increase due to failure

. It follows therefore that Safety

Cases are critically dependent on the determination and

satisfaction of a complete and correct set of Safety

Requirements in which system functionality and performance

are appropriately considered alongside system integrity.

Direct Evidence of Safety Requirements Determination is

concerned with the requirements themselves and should show,

inter alia, that:

• all relevant Hazards have been identified;

• the potential outcomes of the Hazards have been

categorised correctly;

• Safety Objectives have been specified to control the

frequency of occurrence of the Hazards such that an

acceptable level of risk (as defined by the Safety Criteria) is

achieved;

• Safety Requirements have been specified to control the

causes of the Hazards such that the Safety Objectives are

satisfied, and to capture the external means of mitigation of

the Hazard effects.

The key issue here is to ensure that the Safety Requirements

are complete – ie that all risks are taken into account. It would

not be sufficient to show that the Safety Requirements satisfy

the Safety Criteria if those Safety Requirements were based on

an incomplete / incorrect Hazard assessment.

Backing Evidence of Safety Requirements Determination is

concerned with the process of deriving the requirements and

should show, inter alia, that:

• the Safety Requirements were determined using an

established and appropriate process;

SAM [5] expresses the distinction in terms of the “success approach” and the “failure approach”

This point is emphasised here because of a popular misconception that safety is dependent mainly

on integrity. Neglect of functionality and performance can lead to systems that are “reliably unsafe”.

Chapter 4 Safety Case Development Manual

Page 26 Released Issue Edition: 2.2

Relationship to

EUROCONTROL Safety

Assessment

Methodology

• the techniques and tools used to support the Safety

Requirements Determination were verified and validated;

• the Safety Requirements Determination process was

executed by suitably competent and experienced personnel.

The Functional Hazard Assessment (FHA) and Preliminary

System Safety Assessment (PSSA) stages of the

EUROCONTROL, Air Navigation System Safety Assessment

Methodology [5] provides an appropriate and sound process for

the determination of ATM Safety Requirements – demonstration

of adherence to the FHA and PSSA processes could therefore

be used as Backing Evidence as in the first bullet point above.

6. Evidence – Safety Requirements Satisfaction

Sources of Evidence

Service Experience

2020

Direct Evidence from-

Service Experience

Evidence of Safety Requirements satisfaction may be used from

three main sources, as follows:

• Service Experience of previous usage

• Verification and Validation

• Compliance with Standards

Service Experience is data from previous operational use of the

product concerned. Direct Evidence is concerned with analysis

of data from Service Experience and what the results of that

analysis showed in terms of satisfaction of the safety

requirements. Backing Evidence is concerned with showing

that the environment from which the data was obtained is

sufficiently similar to that to which the re-used product will be

subjected, that adequate performance-assessment and fault-

recording processes were in place when the product was

originally deployed, and that the analysis of the outputs of those

processes was adequate and properly carried out.

In assessing and presenting Direct Evidence from Service

Experience, it is important to ensure that:

• an analysis process, with pass/fail criteria, was specified for

each aspect of the product safety requirement whose

satisfaction is being justified using service experience;

• analysis of the service records shows that the criteria for

each product safety requirement, whose satisfaction is being

justified using service experience, have been met;

• all of the details relevant to the argument being made (eg of

length of service, history of modifications, list of users) are

included in the Evidence;

Further guidance on Service Experience, specific to CNS/ATM software, may be found in ED-109

[13]. Note, however, that ED-109 makes no distinction between Direct and Backing evidence.

Safety Case Development Manual Process and Techniques

Edition: 2.2 Released Issue Page 27

Backing Evidence from

Service Experience

• any product capabilities that are not necessary to satisfy the

Safety Requirements cannot have an adverse effect on the

safe operation of the system.

In assessing and presenting Backing Evidence from Service

Experience, it is important to ensure, inter alia, that:

Verification and

Validation

• the subject of the Safety Case and the product for which the

Service Experience Evidence is available are identical or

sufficiently similar;

• the conditions of use of the product for which the Service

Experience is available is taken into account in the analysis;

• the proposed operational environment and the operational

environment for which the Service Experience Evidence is

available are identical or sufficiently similar;

• any changes made to the operational environment,

conditions of use, or product during the period of the Service

Experience are analysed to determine whether those

changes alter the applicability of the data obtained from

Service Experience for the period preceding the changes;

• all aspects of those product functions whose safety

requirements that are being justified from Service

Experience have been exercised in the (previously)

deployed product;

• the extent of the Service Experience is sufficient to

demonstrate that each aspect of the product safety

requirement has been met;

• a Defect Reporting, Analysis and Corrective Action System

(DRACAS) is in place for the deployed product, and is

operated in a reliable manner, and is adequate to support

the Service Experience Evidence;

• the procedures and tools used to support the creation and

analysis of Service Experience Evidence were verified and

validated;

• for all reported failures of an aspect in the product

component, the underlying fault has been corrected, or it

has been shown that the fault is not relevant because it has

no safety impact;

• the collection and analysis of Service Experience Evidence

was done by suitably competent and experienced personnel.

Evidence from system Verification and Validation (V&V) may be

based on, inter alia, analysis and/or testing.

Analysis, in this context, covers any proof of requirements

satisfaction that is obtained from the design or other

representation of the product, including models, prototypes,

software source code etc. It includes, for example, simulation

formal proof, hardware reliability prediction, inspection, and

software static and dynamic code analysis.

Chapter 4 Safety Case Development Manual

Page 28 Released Issue Edition: 2.2

Direct Evidence -

V&V

Backing Evidence -

V&V

Testing is restricted largely to tests of the final product in an

environment which is as close as possible to the operational

environment. Its purpose, broadly, is to demonstrate that what

has been built satisfies the requirements, and it is used to

supplement (sometimes replace) Analysis.

It is beyond the scope of this Manual to discuss the relative

merits of analysis and testing, or of the various techniques

within those two broad categories. Suffice it to say that a Safety

Case should set out clear justifications of the selected

techniques according to the nature and integrity required of the

system to which the Safety Case applies. The following

guidance is however given concerning the principal

requirements of Direct and Backing V&V Evidence.

However obtained, Direct evidence is concerned with the output

of the V&V processes, and should include, as a minimum:

• specifications of what V&V activities were carried out;

• evidence that the V&V activities and pass/fail criteria were

sufficient to demonstrate that the related requirements were

satisfied;

• the results of the V&V activities;

• analysis of the results to shows that all the specified

pass/fail criteria were met;

• explanation and justification of any discrepancies in the

results.

Whether obtained from analysis or testing, Backing evidence is

concerned with the V&V processes themselves, and should

include, as a minimum Evidence that:

• the processes were specified and performed independently

from design;

• the methods and techniques used are appropriate and

adequate, for the properties of the product under

consideration;

• the tools used to support the processes were verified and

validated to a level appropriate for the assigned assurance

level and were properly used;

• the V&V processes were properly and completely executed,

and the guidance, procedures, and standards were adhered

to;

• for previously existing V&V evidence, obtained for COTS or

re-used products, the evidence is entirely valid for the new

system application;

• any differences between the operational and V&V

The list is intended to provide only an overview of the main issues. Further detail on V&V, specific

to CNS/ATM software, may be found in section 3 of ED-109 [13].

Safety Case Development Manual Process and Techniques

Edition: 2.2 Released Issue Page 29

Compliance with

Standards

Product Standards

Process Standards

Relationship to

EUROCONTROL Safety

Assessment

Methodology

environments were identified, and the impact on the results

was assessed and justified.

Evidence of compliance with standards can be a significant

contribution to the safety case. However, the way in which

adherence to a particular standard can be used to demonstrate

compliance with Safety Requirements will depend on the nature

of the standard itself.

Product standards specify precisely what is required of a

specific item of equipment in terms of function, performance,

integrity and, in some cases, form and fit. A good example is

the Arinc 700 series of standards, which define digital avionics

systems and equipment installed on civil aircraft. Currently,

product standards are not common in ATM.

Compliance with product standards could be used as Direct

Evidence of system safety, subject to it being shown that the

standard was appropriate to the particular application and to the

provision of sufficient Backing Evidence concerning the

adequacy of the process by which compliance was

demonstrated.

At the other end of the spectrum, are standards which address

the processes of development and manufacture – examples

range from the very broadly based ISO 9000 series to the more

specific ED-78A (Guidelines for the Approval of the Provision

and Use of ATS Supported by Data Communications) and ED-

109 ( Guidelines for CNS/ATM System Software Integrity

Assurance). In none of these cases would it appropriate to

certify a product against them, from a safety viewpoint;

however, compliance with such standards, especially the more

specific ones, could provide excellent Backing Evidence for

safety requirements determination and/or satisfaction.

The distinction between product- and process-based safety

assurance is clearly fundamental since the former is concerned

with getting the right product and the latter with getting the

product right.

The System Safety Assessment (SSA) stage of the

EUROCONTROL, Air Navigation System Safety Assessment

Methodology [5] provides further guidance on the application of

the above approaches to requirements-satisfaction.

7. Developing a Safety Plan

Introduction

Basic Requirements

Safety Activities

A Safety Plan specifies, inter alia, the safety assurance activities

that are to be carried out in order to create necessary and

sufficient Evidence for the production of a Safety Case.

The SRC-EATM Interface process [6] specifies the following

contents for a Safety Plan:

• the Safety Activities needed to meet the (high-level) safety

objectives, as well as the links and relationships between

Chapter 4 Safety Case Development Manual

Page 30 Released Issue Edition: 2.2

Resources

Roles and

Responsibilities

Safety Deliverables

The Safety / Programme

Lifecycle

Safety Activity /

Deliverables Mapping

Schedule

Specific

Recommendations

Safety Argument

Safety Case

Development

Reviews and Approvals

Handover

Safety Regulation

Safety Case

Maintenance

safety activities and safety objectives;

• the means and resources to carry out safety activities within

the Programme;

• responsibilities and accountabilities for Safety Activities;

• the safety deliverables associated with the Safety Activities;

• the allocation of Safety Activities and Safety Deliverables in

the progression of the Programme;

• the relationships and dependencies between successive

Safety Activities and associated Safety Deliverables;

• the detailed schedule and milestones for conducting Safety

Activities and releasing associated Safety Deliverables.

It is recommended that the following items, specific to the

creation of a Safety Case, also be included in the Safety Plan:

• an initial version of the Safety Argument. The rationale for

this is that most of the Safety Activities (see above) should

be directed at the collection and assessment of Evidence to

support the Safety Argument;

• planned development stages of the Safety Case and their

relationship to the overall Programme milestones;

• requirements for review and approval of the Safety Case;

• arrangements for the proper handover of Safety Case

activities or obligations;

• arrangements for the approval of the Safety Case by the

regulatory authorities;

• arrangements for the maintenance of the Safety Case during

operations.

8. Format, Structure and Layout of the Safety Case

Executive Summary

Introduction:

Background

This section presents guidance on Safety Case layout.

Examples, relating to EATM can be found in the

EUROCONTROL Pre- and Post-Implementation Safety Cases

for RVSM, [2] and [3] respectively. More-recent examples can

be provided on request.

This should provide the reader with an overview of what the

Safety Case is about, what it is trying to show and for whom, a

summary of the conclusions and caveats (see below) and

recommendations (if any).

The Introduction should include:

• an outline of, for example, the circumstances which led to

Safety Case Development Manual Process and Techniques

Edition: 2.2 Released Issue Page 31

Aim

Purpose

Scope

Layout

Service / System

Description

Overall Safety

Argument

Claim

Criteria

Context

Justification

Principal Safety

Arguments

High-level Assumptions

Safety Argument and

Evidence sections

the need for, and development of, the Safety Case;

• a simple statement of the aim – ie what the Safety Case

seeks to demonstrate. It should be related directly to the

top-level Claim (see below);

• the purpose of the Safety Case – ie why, and for whom, it

has been produced;

• the scope and boundary of the Safety Case. It is important

to explain what is included and what is not included;

• the purpose of each of the sections of the document. In

general, the main part of the document should be structured

along the lines of the Safety Argument.

Provide a description of the system to which the Safety Case

applies, including its operational environment, interfaces and

boundaries of responsibility.

This section should describe and explain the highest levels of

the Safety Argument structure, including:

• the Claim – ie the top-level statement which asserts that the

service / system (etc) is safe;

• the Safety Criteria which define what is meant by safe in the

context of the Claim;

• a description of the operational context to which the Safety

Case applies;

• the justification for the change, where the Safety Case

addresses a change to a service and/or system that is not

being made mainly for reasons of improving safety, and

therefore potentially for incurring some risk;

• the principal Safety Arguments – ie the first level of

decomposition of the top-level Claim – these should be

reasoned and well structured, showing how the Safety

Criteria are satisfied and the rationale for the approach

taken in the decomposition;

• the key Assumptions on which the highest levels of the

Safety Argument critically depend – for example, the level of

risk prior to the introduction of a change is acceptable.

Other Assumptions, applicable to the lower levels of the

Safety Argument structure should be included in the

Assumptions section – see below.

These sections should present each of the principal Safety

Arguments (see above) in turn, together with the supporting

Evidence which shows that each of the Arguments is valid. It is

recommend that, where applicable, each section be structured

as follows:

• Objective (of the section) – related directly to the principal

Safety Argument;

• Strategy (breakdown of the principal Safety Argument into

Chapter 4 Safety Case Development Manual

Page 32 Released Issue Edition: 2.2

Assumptions

Issues

Limitations

Conclusions

Recommendations

lower-level arguments);

• Rationale (for the Strategy);

• Lower-level Arguments / Evidence;

• Conclusions (of section).

Present directly, and/or by reference, all the Assumptions on

which the Safety Case depends, including the high-level

Assumptions mentioned above. Assumptions usually relate to

matters outside of the direct control of the organisation

responsible for the Safety Case but which are essential to the

completeness and/or correctness of the Safety Case. Each

Assumption must be shown to be valid or at least reasonable

according to the circumstances.

List any outstanding safety issues that must be resolved before

the Claim can be considered to be valid, together with the

responsibilities and timescales for clearing them.

State and explain any Limitations or restrictions that need to be

placed on the deployment and/or operation of the system.

Do not merely repeat the conclusions from each section here.

The main conclusion should refer to the original Claim and, if

applicable, reassert its validity, subject to the following caveats:

• the Scope – especially what the Safety Case does not

cover;

• the operational Context to which the Safety Case applies;

• the Assumptions that have had to be made;

• the outstanding Issues;

• any Limitations placed on the deployment and/or operation

of the service / system.

Recommendations are not mandatory and any that are made

should not be temporary in nature. For example, it might be

appropriate to make recommendations on the use of the Safety

Case by its recipients, but not concerning its approval.

Recommendations must not contain any statements that would

undermine, or add further caveats to, the Conclusions.

9. Verifying the Safety Case

Further guidance on what to look for in developing and

reviewing a Safety Case can be found in the detailed checklists

in Appendix C.

Safety Case Development Manual Process and Techniques

Edition: 2.2 Released Issue Page 33

10. ESARR Compliance

Overview

ESARR 2

ESARR 3

Compliance with ESARRs may be used in support of a Safety

Case. However, as indicated below, ESARRs are largely

concerned with processes and, therefore, compliance with

ESARRs should normally be used as Backing Evidence, not as

Direct Evidence

Reporting and Assessment of Safety Occurrences in ATM

The rationale for ESARR 2 is that the achievement of consistent

high levels of aviation safety and the management of safety in

ATM require, as a priority, the successful implementation of

harmonised occurrence reporting and assessment schemes.

Such schemes will lead to more systematic visibility of safety

occurrences and their causes, and will allow identification of

appropriate corrective actions as well as areas where flight safety

could be improved by changes to the ATM system.

Compliance with ESARR 2 can be used as (Backing) Evidence

of having an adequate in-service safety monitoring process in

support of:

• a Project Safety Case – see for example Arg4 / St005 in

Figure 11 of Chapter 5;

• a Unit Safety Case – see for example Arg2.5 in Figure 12 of

Chapter 5.

Use of Safety Management Systems by Service Providers

The rationale for ESARR 3 is that an ATM service provider has a

responsibility to ensure that all relevant safety issues have been

satisfactorily dealt with, and to provide assurance that this has

been done. Safety management is that function of service

provision, which ensures that all safety risks have been identified,

assessed and satisfactorily mitigated. A formal and systematic

approach to safety management will maximise safety benefits in a

visible and traceable way.

Because a typical SMS includes a very wide range of safety

processes in support of ATM operations, compliance with ESARR

3 can be used in many areas of a Safety Case - for example:

• in a Project Safety Case, SMS processes could be used as

Backing Evidence under Arg2.1 and Arg2.2, in Chapter 5,

Figure 8 and Figure 9 respectively;

• in a Unit Safety Case, SMS processes could be used as

Direct Evidence under Arg2.2 / St003, in Figure 14 of

Chapter 5.

In both cases, the SMS-process Evidence would be strengthened

if it could be shown that the SMS was compliant with ESARR 3 –

ie ESARR 3 compliance would provide Backing Evidence.

A possible exception to this statement could be a Safety Case which is based mainly on the

satisfaction of the requirements of the ESARR 4 Risk Classification Scheme.

Chapter 4 Safety Case Development Manual

Page 34 Released Issue Edition: 2.2

ESARR 4

Risk Assessment and Mitigation in ATM

ESARR 4 concerns the use of Risk Assessment and Mitigation,

including hazard identification, in Air Traffic Management when

introducing and/or planning changes to the ATM System. In this

ESARR 5

ESARR 6

requirement, Risk Assessment and Mitigation are addressed via a

total–aviation-system approach.

There are two aspects of ESARR 4 which can be used in a Safety

Case, as follows:

• subjective to the provisos of Chapter 4, section 2 above, the

Risk Classification Scheme in Appendix A to ESARR 4 could

be used as the basis of quantitative Safety Criteria – see, for

example, Cr001 / #1 in Chapter 5, Figure 1;

• compliance with the qualitative (process) requirements of

section 5 of ESARR 4 could be used as Backing Evidence as,

for example, in Arg 1.10 in Chapter 5, Figure 6.

ATM Services’ Personnel

ESARR 5 documents general safety regulatory requirements for

all ATM services’ personnel responsible for safety related tasks

within the provision of ATM services across the ECAC area,

including the specific safety regulatory requirements for air traffic

controllers and engineering/technical personnel.

Compliance with ESARR 5 could be used in a Unit Safety Case

to show that the human aspects of the on-going operation are

based on, inter alia, competent personnel. This would appear, for

example in the lower levels of decomposition of Arg2.1 and

Arg2.2 in Chapter 5, Figure 14.

Software in ATM Systems

ESARR 6 deals with the implementation of software safety

assurance systems to ensure that the risks associated with the

use of software in safety-related ground-based ATM systems are

reduced to a tolerable level.

Compliance with ESARR 6 could be used, for example, in:

• a Project Safety Case - software processes could be used as

Backing Evidence under Arg2.1 / St011 and Arg2.2 / St015,

in Figure 8 and Figure 9 respectively of Chapter 5

2323

;

• a Unit Safety Case - software processes could be used as

Direct Evidence under Arg2.2 / St003, in Figure 14 of

Chapter 5.

Direct Evidence would be the outputs of those processes

Safety Case Development Manual GSN Safety Argument Examples

Edition: 2.2 Released Issue Page 35

CHAPTER 5

Guidance -

GSN Safety Argument Examples

1. Example Application of GSN – A “Project” Safety Case

Relationship to the

EUROCONTROL SAM

Figure 1 to Figure 11 overleaf show a structured Safety

Argument for a hypothetical substantial

change (“SGxy”) to an

ATM service which could form the basis of what is known herein

as a Project Safety Case.

The structure is intentionally not complete in all areas of the

decomposition; however, it is intended to be sufficient, in

breadth and depth, to illustrate the use of the GSN notation. A

commentary on the development of the Safety Argument is also

provided below. This commentary is also not exhaustive but is

intended to bring out all the main points concerning the

application of GSN.

Where applicable references are given to those process(es) in

the SAM [5] that would generate the required Evidence.

Claim

Justification

Context

The Safety Argument starts, in Figure 1, with the top-level

Claim (Arg 0) that the ATM service, following the change, will

be acceptably safe.

J001 indicates that the change is justified operationally and this

justification would need to be elaborated in the Safety Case.

C001 provides an essential marker that the change itself needs

to be defined in terms of the ATM service / system and

accompanying operational concept – such descriptions would

need to be provided in the related Safety Case.

Chapter 5 Safety Case Development Manual

Page 36 Released Issue Edition: 2.2

Change_SGxy will

be acceptably safe

in operational

service

Arg 0

St 001

Specify safety criteria for each of the

4 main life-cycle stages and show that

each stage is / will be acceptably safe

– ie the safety criteria are sufficient to

achieve the required level of safety,

and are satisfied

C001

Operational concept

(SAM-FHA ch1-GM A)

Change_SGxy

Implementation

is acceptably safe

Arg 2

Change_SGxy

Concept is

acceptably safe,

in principle

Arg 1

A001

Current ATM service

is accepted as being safe

J001

Change_SGxy is being

introduced to meet a

legitimate operational need

Cr001

The risk of an accident following

Change_SGxy shall be:

1.Within the regulatory requirements – eg:

a. such that the whole ATM service

meets ESARR 4 Design Safety

Targets (SAM-FHA ch3 GM E); OR

b. no greater (and preferably lower)

than currently exists.

AND

2. reduced as far as reasonably

practicable.

Migration to

Change_SGxy

will be

acceptably safe

Arg 3

On-going Operation

of Change_SGxy will

be shown to be

acceptably safe

Arg 4

Fig 2 Fig 7

St004

Show that risk during

(and immediately

following) Migration will

satisfy Cr001 item 2 Fig 11

St005

Safety Monitoring

will satisfy Cr001

items 1 and 2

Fig 10

St002

Show that Safety

Requirements satisfy Cr001:

•item 1 (Args 1.1 & 1.2);

•Item 2 (Arg 1.3)

St003

Show that the Safety

Requirements are satisfied:

1. Initially in system design

2. Subsequently in the

realisation of that design

C002

Subject to declared

Assumptions, Limitations

and outstanding Issues

Change_SGxy will

be acceptably safe

in operational

service

Arg 0

Change_SGxy will

be acceptably safe

in operational

service

Arg 0

St 001

Specify safety criteria for each of the

4 main life-cycle stages and show that

each stage is / will be acceptably safe

– ie the safety criteria are sufficient to

achieve the required level of safety,

and are satisfied

St 001

Specify safety criteria for each of the

4 main life-cycle stages and show that

each stage is / will be acceptably safe

– ie the safety criteria are sufficient to

achieve the required level of safety,

and are satisfied

C001

Operational concept

(SAM-FHA ch1-GM A)

Change_SGxy

Implementation

is acceptably safe

Arg 2

Change_SGxy

Implementation

is acceptably safe

Arg 2

Change_SGxy

Concept is

acceptably safe,

in principle

Arg 1

Change_SGxy

Concept is

acceptably safe,

in principle

Arg 1

A001

Current ATM service

is accepted as being safe

J001

Change_SGxy is being

introduced to meet a

legitimate operational need

Cr001

The risk of an accident following

Change_SGxy shall be:

1.Within the regulatory requirements – eg:

a. such that the whole ATM service

meets ESARR 4 Design Safety

Targets (SAM-FHA ch3 GM E); OR

b. no greater (and preferably lower)

than currently exists.

AND

2. reduced as far as reasonably

practicable.

Cr001

The risk of an accident following

Change_SGxy shall be:

1.Within the regulatory requirements – eg:

a. such that the whole ATM service

meets ESARR 4 Design Safety

Targets (SAM-FHA ch3 GM E); OR

b. no greater (and preferably lower)

than currently exists.

AND

2. reduced as far as reasonably

practicable.

Migration to

Change_SGxy

will be

acceptably safe

Arg 3

Migration to

Change_SGxy

will be

acceptably safe

Arg 3

On-going Operation

of Change_SGxy will

be shown to be

acceptably safe

Arg 4

On-going Operation

of Change_SGxy will

be shown to be

acceptably safe

Arg 4

Fig 2Fig 2 Fig 7Fig 7

St004

Show that risk during

(and immediately

following) Migration will

satisfy Cr001 item 2

St004

Show that risk during

(and immediately

following) Migration will

satisfy Cr001 item 2

St004

Show that risk during

(and immediately

following) Migration will

satisfy Cr001 item 2 Fig 11Fig 11

St005

Safety Monitoring

will satisfy Cr001

items 1 and 2

St005

Safety Monitoring

will satisfy Cr001

items 1 and 2

St005

Safety Monitoring

will satisfy Cr001

items 1 and 2

Fig 10Fig 10

St002

Show that Safety

Requirements satisfy Cr001:

•item 1 (Args 1.1 & 1.2);

•Item 2 (Arg 1.3)

St002

Show that Safety

Requirements satisfy Cr001:

•item 1 (Args 1.1 & 1.2);

•Item 2 (Arg 1.3)

St003

Show that the Safety

Requirements are satisfied:

1. Initially in system design

2. Subsequently in the

realisation of that design

St003

Show that the Safety

Requirements are satisfied:

1. Initially in system design

2. Subsequently in the

realisation of that design

St003

Show that the Safety

Requirements are satisfied:

1. Initially in system design

2. Subsequently in the

realisation of that design

C002

Subject to declared

Assumptions, Limitations

and outstanding Issues

Figure 1 – Arg 0: Safety Argument

Safety Criteria

Choice of Criteria

Assumption

Arg1 to 4

Acceptably safe is defined in terms of the three criteria

summarised in Cr001. These criteria reflect the three main

ways of expressing a Safety Argument – ie:

• Absolutely: as compliance with a (numerical) target level of

safety – eg ESARR 4 (or local regulatory interpretation

thereof), OCP, ICAO, JAR 25 etc;

• Relatively: in relation to a current / previous (usually

qualitative) level of safety;

• Reductively: showing risk to be further reduced as far as

reasonably practicable;

The first two bullets are alternative ways of expressing a typical

regulatory minimum safety level

and specify what is

sometimes known as tolerable risk. In the further development

of the Safety Argument for Change SGxy, only the absolute

criterion is actually used

, and is supported by the reductive

criterion in order to specify what is sometimes known as an

acceptable level of risk.

If a relative Argument, were to be used it would be necessary to

establish that the pre-change baseline is safe. This is addressed

in A001 which is shown on Figure 1 for illustration only.

As indicated in Strategy St001, Claim Arg 0 is decomposed into

It would not normally be necessary to comply with both.

For examples of developing Safety Arguments using relative criteria, please contact DAP/SAF

Safety Case Development Manual GSN Safety Argument Examples

Edition: 2.2 Released Issue Page 37

four principal Arguments which, in this case, relate to the four

main, contiguous stages of the lifecycle of the Change. The

outcome of each stage is argued to be acceptably safe and

St002 to St005 are used to indicate, by reference to Cr001 what

is defined as acceptably safe for each stage:

• Arg 1 (through St002) asserts that the Change is acceptably

safe in principle – ie subject to subsequent complete and

correct implementation of the Safety Requirements;

• Arg 2 (through St003) asserts that the Implementation of

the Change is acceptably safe, through satisfaction of the

Safety Requirements, and that the rigour of the Assurance

(ie lower-level Arguments and Evidence) to support this is

appropriate to the risk associated with the Change;

• Arg 3 (through St004) asserts, in effect, that the Migration

from the current state to the post-Change state will not

endanger the on-going operational service. The change in

tense in Arg3 is deliberate since the Safety Argument would

be expected to be finalised once all the Implementation and

Migration steps, except the final “switchover” to the new

state, had been completed satisfactorily. Note that, because

of the short time for which the service is at risk, during

Migration, only Criterion Cr001, item 2 can be applied to this

Argument;

• Arg 4 (through St005) asserts that the monitoring of the on-

going operational service, post Migration, will be sufficient to

show the Change to be acceptably safe

Fig 3

Safety Functions &

Safety Objectives

specify what is

sufficient at functional

level to meet Safety

Criteria Cr001

Arg 1.1

Fig 1

Safety Requirements

specify what is

sufficient at

architectural level to

meet Safety Objectives

Arg 1.2

Fig 4

Risks have been

minimised in the

process of deriving

the Safety

Requirements

Arg 1.3

Fig 5

Change_SGxy

Concept is

acceptably safe,

in principle

Arg 1

St006

Show that Safety

Requirements

evidence is

trustworthy

Fig 6

St002

Show that Safety

Requirements satisfy Cr001:

•item 1 (Args 1.1 & 1.2);

•Item 2 (Arg 1.3)

Fig 3Fig 3

Safety Functions &

Safety Objectives

specify what is

sufficient at functional

level to meet Safety

Criteria Cr001

Arg 1.1

Safety Functions &

Safety Objectives

specify what is

sufficient at functional

level to meet Safety

Criteria Cr001

Arg 1.1

Fig 1Fig 1

Safety Requirements

specify what is

sufficient at

architectural level to

meet Safety Objectives

Arg 1.2

Fig 4

Safety Requirements

specify what is

sufficient at

architectural level to

meet Safety Objectives

Arg 1.2

Fig 4Fig 4

Risks have been

minimised in the

process of deriving

the Safety

Requirements

Arg 1.3

Fig 5

Risks have been

minimised in the

process of deriving

the Safety

Requirements

Arg 1.3

Risks have been

minimised in the

process of deriving

the Safety

Requirements

Arg 1.3

Fig 5Fig 5

Change_SGxy

Concept is

acceptably safe,

in principle

Arg 1

Change_SGxy

Concept is

acceptably safe,

in principle

Arg 1

St006

Show that Safety

Requirements

evidence is

trustworthy

Fig 6

St006

Show that Safety

Requirements

evidence is

trustworthy

St006

Show that Safety

Requirements

evidence is

trustworthy

St006

Show that Safety

Requirements

evidence is

trustworthy

Fig 6Fig 6

St002

Show that Safety

Requirements satisfy Cr001:

•item 1 (Args 1.1 & 1.2);

•Item 2 (Arg 1.3)

St002

Show that Safety

Requirements satisfy Cr001:

•item 1 (Args 1.1 & 1.2);

•Item 2 (Arg 1.3)

Figure 2 – Arg 1: Safety of the “Change SGxy” Concept

Chapter 5 Safety Case Development Manual

Page 38 Released Issue Edition: 2.2

Arg 1

Arg 1 focuses on the output of the Concept stage of the

lifecycle – ie a set of Safety Requirements for the Change that

ultimately satisfy the three safety criteria which define an

acceptable level of safety.

Arg 1 is achieved through a two-fold Strategy, which uses the

principle of Direct Evidence and Backing Evidence, as follows:

• St002 shows, through a sequential set of Arguments (Arg

1.1 to Arg 1.5), that the eventual outputs of the Concept

phase – the Safety Requirements – satisfy the three safety

Criteria. This is clearly a Direct approach since it is

concerned with the outputs of each stage in the sequence,

rather than with the processes that produce those outputs;

• St006 shows that the Direct Evidence is trustworthy – ie can

be relied upon. The Arguments to achieve St006 are

shown in Figure 6 below, and are considered to be of the

Backing type since they are concerned with the processes

that produce the above outputs, rather than with the outputs

themselves (ie they are complementary to St002).

Arg 1.1, Arg 1.2 and Arg 1.3 are decomposed below in

Figure 3, Figure 4 and Figure 5 respectively.

In Figure 3, the Context for Arg 1.1 is an FHA (C004)

associated with the Change. C005 is simply a reminder that the

FHA must encompass all aspects of the Change.

Arg 1.1.1 to Arg 1.1.6 relate to the outputs of the main stages

of a typical FHA. Safety Functions are concerned with

specifying the desired (correct) operation of a system in order

to provide safe ATM services (what the SAM

[5]

describes as

the “success approach”) whereas Safety Objectives limit the

frequency of failure.

The type of Evidence expected to be provided to support each

strand of the Argument is also shown on Figure 3, together with

the relevant references to the SAM

[5]

The use of the term “adequately” in Arg 1.1.2 and Arg 1.1.4

illustrates what is sometimes a fine distinction between Direct

and Backing Evidence. In general:

Safety Case Development Manual GSN Safety Argument Examples

Edition: 2.2 Released Issue Page 39

C005

Scope encompasses airspace,

equipment, procedures and human

aspects of Change_SGxy

Safety

Functions are

adequately

specified

Arg 1.1.2

Safety

Objectives are

adequately

specified

Arg 1.1.4

Safety Functions

and Safety

Objectives satisfy

Criteria Cr001

Arg 1.1.6

Change_SGxy

Concept has been

documented and

validated

Arg 1.1.1

C004

FHA

Functional

model &

Safety

Functions

SAM FHA,

Ch 1, 2.1

Safety

Objectives &

Traceability

SAM FHA

Ch 3, 3.2 & Ch 4,

3.2 GMA

Validation

evidence

SAM FHA

Ch 4, 3.1

Concept of

Operations

SAM FHA,

Ch 1, 2.1 &

2.2

Simulation

(etc)

results

SAM FHA,

Ch 1, 2.5

All hazards

correctly

identified and

analysed

Arg 1.1.3

HAZID

results

SAM FHA

Ch 3, 3.1

Event

Trees etc

SAM FHA

Ch 3, 3.2

& 3.3

Mitigations &

Assumptions

SAM FHA

Ch 3, 4, Ch 4,

3.2

All mitigations

captured as

SFs / SObjs or

Assumptions

Arg 1.1.5

Fig 2

Safety Functions &

Safety Objectives

specify what is sufficient

at functional level to

meet the Safety Criteria

Cr001

Arg 1.1

C005

Scope encompasses airspace,

equipment, procedures and human

aspects of Change_SGxy

Safety

Functions are

adequately

specified

Arg 1.1.2

Safety

Objectives are

adequately

specified

Arg 1.1.4

Safety Functions

and Safety

Objectives satisfy

Criteria Cr001

Arg 1.1.6

Safety Functions

and Safety

Objectives satisfy

Criteria Cr001

Arg 1.1.6

Change_SGxy

Concept has been

documented and

validated

Arg 1.1.1

C004

FHA

Functional

model &

Safety

Functions

SAM FHA,

Ch 1, 2.1

Functional

model &

Safety

Functions

SAM FHA,

Ch 1, 2.1

Safety

Objectives &

Traceability

SAM FHA

Ch 3, 3.2 & Ch 4,

3.2 GMA

Validation

evidence

SAM FHA

Ch 4, 3.1

Validation

evidence

SAM FHA

Ch 4, 3.1

Concept of

Operations

SAM FHA,

Ch 1, 2.1 &

2.2

Simulation

(etc)

results

SAM FHA,

Ch 1, 2.5

All hazards

correctly

identified and

analysed

Arg 1.1.3

HAZID

results

SAM FHA

Ch 3, 3.1

Event

Trees etc

SAM FHA

Ch 3, 3.2

& 3.3

Mitigations &

Assumptions

SAM FHA

Ch 3, 4, Ch 4,

3.2

All mitigations

captured as

SFs / SObjs or

Assumptions

Arg 1.1.5

All mitigations

captured as

SFs / SObjs or

Assumptions

Arg 1.1.5

Fig 2

Safety Functions &

Safety Objectives

specify what is sufficient

at functional level to

meet the Safety Criteria

Cr001

Arg 1.1

Fig 2Fig 2

Safety Functions &

Safety Objectives

specify what is sufficient

at functional level to

meet the Safety Criteria

Cr001

Arg 1.1

Safety Functions &

Safety Objectives

specify what is sufficient

at functional level to

meet the Safety Criteria

Cr001

Arg 1.1

Figure 3 – Arg 1.1: Safety Functions and Safety Objectives

• If the Argument / Evidence is concerned with observable

attributes of an output (product) then it should be considered

to be Direct – for example, traceability of Safety Objectives

back to Safety Functions and Safety Criteria would be Direct

since it would be observable (with the assistance of cross-

referencing) from the Safety Objectives, Safety Functions

and Safety Criteria themselves.

• On the other hand, if the Argument / Evidence cannot be

deduced from observable attributes of an output itself, but is

related only to the process, then it should be considered to

be Backing – for example it would be impossible to deduce

from a set of Safety Objectives that they had been

developed by a team with Appropriate expertise – see

Figure 6 below.

The decomposition of Arg 1.2 (see

Figure 4 below)

is similar in

principle to that for Arg 1.1 above. The Context (C004) is the

PSSA – ie the derivation of Safety Requirements – and in this

case is the first stage of PSSA, expressed at the recommended,

Logical-architecture level.

St007 emphasises the importance of considering the safety of

the system when it is working (what the SAM

[5]

calls the

“success approach”, expressed in terms of Safety Requirements

for function and performance) as well as when it fails

(expressed in terms of Safety Requirements for reliability and

integrity).

This mirrors the distinction between Safety Functions and Safety Objectives, which needs to be

made at the FHA stage.

Chapter 5 Safety Case Development Manual

Page 40 Released Issue Edition: 2.2

The type of Evidence expected to be provided to support each

strand of the Argument is also shown in Figure 4.

Safety

Requirements for

function &

performance are

adequately specified

Arg 1.2.2

Logical

Architecture

described

completely and

correctly

Arg 1.2.1

Architectural

Model

SAM PSSA

Ch 1, 2.1 &

2.2

FSRs &

Traceability

SAM PSSA

Ch 3, 3.1,

Ch 5, 3.2

Simulations

etc

Safety Requirements

for integrity are

adequately specified

Arg 1.2.3

Fig 2

Safety Requirements

specify what is

sufficient at

architectural level to

meet Safety Objectives

Arg 1.2

C005

Scope encompasses

airspace, equipment, people,

procedures and training

C004

PSSA

Hazard causes

identified &

modelled

adequately

Arg 1.2.3.1

Fault Trees

SAM PSSA

Ch 3, 3.2, Part

IV GMK

Safety Integrity

Requirements

set to satisfy

Safety Objectives

Arg 1.2.3.2

SRs

SAM PSSA

Ch 3, 3.4,

Ch 4, 3.1

All causal mitigations

captured as Safety

Requirements or

Assumptions

Arg 1.2.3.3

Mitigations

and

Assumptions

SAM PSSA

Ch 3, 3.3 & 4

St007

Derive Safety Requirements

For “success” and “failure”

approaches

Safety

Requirements for

function &

performance are

adequately specified

Arg 1.2.2

Logical

Architecture

described

completely and

correctly

Arg 1.2.1

Architectural

Model

SAM PSSA

Ch 1, 2.1 &

2.2

FSRs &

Traceability

SAM PSSA

Ch 3, 3.1,

Ch 5, 3.2

FSRs &

Traceability

SAM PSSA

Ch 3, 3.1,

Ch 5, 3.2

Simulations

etc

Simulations

etc

Safety Requirements

for integrity are

adequately specified

Arg 1.2.3

Safety Requirements

for integrity are

adequately specified

Arg 1.2.3

Fig 2

Safety Requirements

specify what is

sufficient at

architectural level to

meet Safety Objectives

Arg 1.2

Fig 2Fig 2

Safety Requirements

specify what is

sufficient at

architectural level to

meet Safety Objectives

Arg 1.2

C005

Scope encompasses

airspace, equipment, people,

procedures and training

C004

PSSA

Hazard causes

identified &

modelled

adequately

Arg 1.2.3.1

Hazard causes

identified &

modelled

adequately

Arg 1.2.3.1

Fault Trees

SAM PSSA

Ch 3, 3.2, Part

IV GMK

Safety Integrity

Requirements

set to satisfy

Safety Objectives

Arg 1.2.3.2

Safety Integrity

Requirements

set to satisfy

Safety Objectives

Arg 1.2.3.2

SRs

SAM PSSA

Ch 3, 3.4,

Ch 4, 3.1

All causal mitigations

captured as Safety

Requirements or

Assumptions

Arg 1.2.3.3

Mitigations

and

Assumptions

SAM PSSA

Ch 3, 3.3 & 4

St007

Derive Safety Requirements

For “success” and “failure”

approaches

Figure 4 – Arg 1.2: Safety Requirements

Arg 1.3 (see Figure 5 below) presents the Argument and

Evidence that the qualitative Safety Criteria have been satisfied

via the processes that led to the Safety Requirements for

Change SGxy.

The difficulty with Arg 1.3.1 is that most changes in ATM involve

some inherent risk because the service in general needs to

respond to an ever increasing demand on its capacity to deliver.

Therefore, it is necessary to find safety benefits – in the form of

removal or mitigation of areas of risk – to offset the inherent risk

of change. In most cases the relative Argument involved has to

be made on the basis of qualitative Evidence.

Safety Case Development Manual GSN Safety Argument Examples

Edition: 2.2 Released Issue Page 41

All practicable

mitigations of

cause identified

in PSSA

Arg 1.3.2

All practicable

mitigations of

consequence

identified in FHA

Arg 1.3.1 Safety Requirements

specified to reduce

risk as far as

reasonably practicable

Arg 1.3.3

Process

evidence

SAM PSSA

Ch 3, 3.3

Risks have been

minimised in the

process of deriving the

Safety Requirements

Arg 1.3

Fig 2

Process

evidence

SAM PSSA

Ch 3, 3.3

Process

evidence

SAM FHA Ch 3,

PSSA Ch 3

All practicable

mitigations of

cause identified

in PSSA

Arg 1.3.2

All practicable

mitigations of

consequence

identified in FHA

Arg 1.3.1 Safety Requirements

specified to reduce

risk as far as

reasonably practicable

Arg 1.3.3

Safety Requirements

specified to reduce

risk as far as

reasonably practicable

Arg 1.3.3

Process

evidence

SAM PSSA

Ch 3, 3.3

Risks have been

minimised in the

process of deriving the

Safety Requirements

Arg 1.3

Risks have been

minimised in the

process of deriving the

Safety Requirements

Arg 1.3

Fig 2Fig 2

Process

evidence

SAM PSSA

Ch 3, 3.3

Process

evidence

SAM FHA Ch 3,

PSSA Ch 3

Figure 5 – Arg 1.3: Satisfaction of Qualitative Safety Criteria

The Arguments and Evidence for Arg 1.3.3 are intended to

show that a (properly conducted) FHA and PSSA Stage 1 will

yield safety requirements that, when implemented, will result in

a risk that has been reduced as far as reasonably practicable, at

that stage

Concept of Ops

and simulations

done by

competent staff

Arg 1.4 FHA & PSSA

processes

were executed

by competent staff

Arg 1.6

Competence

evidence

FHA & PSSA

processes

were adequate

Arg 1.5

Process

evidence

SAM FHA, Ch 4

GMA-B-C, 3.3

PSSA, Ch 4 GM A-

B-C, 3.3

Competence

evidence

SAM FHA, Ch2,

PSSA, Ch 4

St006

Show that Safety

Requirements

evidence is

trustworthy

Fig 2

Architectural

model was

done by

competent staff

Arg 1.7

FHA and PSSA

processes comply with

qualitative requirements

of ESARR 4

Arg 1.8

Competence

evidence

SAM PSSA

Ch2

Competence

evidence Process

evidence

GM for SAM,

Annex B

Concept of Ops

and simulations

done by

competent staff

Arg 1.4 FHA & PSSA

processes

were executed

by competent staff

Arg 1.6

Competence

evidence

Competence

evidence

FHA & PSSA

processes

were adequate

Arg 1.5

Process

evidence

SAM FHA, Ch 4

GMA-B-C, 3.3

PSSA, Ch 4 GM A-

B-C, 3.3

Competence

evidence

SAM FHA, Ch2,

PSSA, Ch 4

St006

Show that Safety

Requirements

evidence is

trustworthy

Fig 2

St006

Show that Safety

Requirements

evidence is

trustworthy

St006

Show that Safety

Requirements

evidence is

trustworthy

St006

Show that Safety

Requirements

evidence is

trustworthy

Fig 2Fig 2

Architectural

model was

done by

competent staff

Arg 1.7

FHA and PSSA

processes comply with

qualitative requirements

of ESARR 4

Arg 1.8

Competence

evidence

SAM PSSA

Ch2

Competence

evidence

SAM PSSA

Ch2

Competence

evidence

Competence

evidence Process

evidence

GM for SAM,

Annex B

Process

evidence

GM for SAM,

Annex B

Figure 6 – St0006: Safety of the Concept (Backing)

The reduction of risk as far as reasonably practicable is further covered in

Arg 3

below

Chapter 5 Safety Case Development Manual

Page 42 Released Issue Edition: 2.2

Arg 2

As with most Backing Evidence, St0006, in Figure 6 above, is

based on arguing the adequacy of the processes (including

techniques and tools) involved and on the competence of the

personnel who executed those processes. In practice, some of

the Arguments may need to be decomposed to a lower level of

detail than shown in this example.

Figure 7 below addresses the Implementation of Change SGxy,

in two stages: physical-level design and realisation of the design

in the physical system – these are further decomposed below in

Figure 8 and Figure 9 respectively.

St004

Show that the Safety

Requirements are satisfied:

1. Initially in system design

2. Subsequently in the

realisation of that design

Fig 1

Change_SGxy

Implementation

is acceptably safe

Arg 2

C008

SSA

Physical-level

design satisfies

the related Safety

Requirements

Arg 2.1

Fig 8

Realisation of the

physical-level

design satisfies

the related Safety

Requirements

Arg 2.2

Fig 9

C009

May include further level(s)

of Safety Requirement

derivation

St004

Show that the Safety

Requirements are satisfied:

1. Initially in system design

2. Subsequently in the

realisation of that design

St004

Show that the Safety

Requirements are satisfied:

1. Initially in system design

2. Subsequently in the

realisation of that design

St004

Show that the Safety

Requirements are satisfied:

1. Initially in system design

2. Subsequently in the

realisation of that design

Fig 1

Change_SGxy

Implementation

is acceptably safe

Arg 2

Fig 1Fig 1

Change_SGxy

Implementation

is acceptably safe

Arg 2

Change_SGxy

Implementation

is acceptably safe

Arg 2

C008

SSA

Physical-level

design satisfies

the related Safety

Requirements

Arg 2.1

Fig 8

Physical-level

design satisfies

the related Safety

Requirements

Arg 2.1

Fig 8Fig 8

Realisation of the

physical-level

design satisfies

the related Safety

Requirements

Arg 2.2

Fig 9

Realisation of the

physical-level

design satisfies

the related Safety

Requirements

Arg 2.2

Fig 9Fig 9

C009

May include further level(s)

of Safety Requirement

derivation

Figure 7 – Arg 2: Safety of Implementation

In this example, Arg2 is decomposed only far enough to show

the elements of the ATM system that might be involved.

For the Implementation of Airspace Design, ATC Procedures

and Operational Training, most of the Evidence of compliance

with the Safety Requirements comes at the Design stage – ie

under Arg 2.1.

For the Implementation of the Equipment aspects, the Evidence

of compliance with the Safety Requirements should also come

from the Design stage – ie under Arg 2.1 – but should be further

substantially supported by testing in the subsequent Realisation

stage – ie under Arg 2.2.

The decomposition of Arg 2.1 would need to include Backing

assurance covering the adequacy of the processes, tools and

techniques employed in the design and realisation, and of the

Safety Case Development Manual GSN Safety Argument Examples

Edition: 2.2 Released Issue Page 43

competence of the personnel involved. Full use should be

made of existing operational and engineering procedures in the

organisation’s quality and safety management systems.

Physical-level

design satisfies

the related Safety

Requirements

Arg 2.1

Fig 7

C010

Changes to

hardware and

software

Provide direct

and backing that

Airspace

design satisfies

the related Safety

Requirements

St008

Fig [....]

Provide direct

and backing that

ATC Procedure

design satisfies

the related Safety

Requirements

St009

Fig [....]

Provide direct

and backing that

ATC Training

design satisfies

the related Safety

Requirements

St010

Fig [....]

Provide direct

and backing that

ATC Equipment

design satisfies

the related Safety

Requirements

St011

Fig [....]

Physical-level

design satisfies

the related Safety

Requirements

Arg 2.1

Fig 7Fig 7

C010

Changes to

hardware and

software

Provide direct

and backing that

Airspace

design satisfies

the related Safety

Requirements

St008

Fig [....]

Provide direct

and backing that

Airspace

design satisfies

the related Safety

Requirements

St008

Fig [....]Fig [....]

Provide direct

and backing that

ATC Procedure

design satisfies

the related Safety

Requirements

St009

Fig [....]

Provide direct

and backing that

ATC Procedure

design satisfies

the related Safety

Requirements

St009

Fig [....]Fig [....]

Provide direct

and backing that

ATC Training

design satisfies

the related Safety

Requirements

St010

Fig [....]

Provide direct

and backing that

ATC Training

design satisfies

the related Safety

Requirements

St010

Fig [....]Fig [....]

Provide direct

and backing that

ATC Equipment

design satisfies

the related Safety

Requirements

St011

Fig [....]

Provide direct

and backing that

ATC Equipment

design satisfies

the related Safety

Requirements

St011

Fig [....]Fig [....]

Figure 8 – Arg 2.1: Safety of Design

The decomposition of Arg 2.2 mirrors that for Arg 2.1 above

and is shown in Figure 9.

Realisation of the

physical-level

design satisfies

the related Safety

Requirements

Arg 2.2

Fig 7

C011

Changes to

hardware and

software

Fig [....]

Provide direct

and backing that

the promulgation

of Airspace

changes satisfies

the related Safety

Requirements

St012

Fig [....]

Provide direct

and backing that

ATC Procedure

publication

satisfies the

related Safety

Requirements

St013

Fig [....]

Provide direct

and backing that

ATC Equipment

changes satisfy

the related Safety

Requirements

St015

Fig [....]

Provide direct

and backing that

ATC Training

delivery satisfies

the related Safety

Requirements

St014

Realisation of the

physical-level

design satisfies

the related Safety

Requirements

Arg 2.2

Fig 7

Realisation of the

physical-level

design satisfies

the related Safety

Requirements

Arg 2.2

Realisation of the

physical-level

design satisfies

the related Safety

Requirements

Arg 2.2

Fig 7Fig 7

C011

Changes to

hardware and

software

Fig [....]

Provide direct

and backing that

the promulgation

of Airspace

changes satisfies

the related Safety

Requirements

St012

Fig [....]Fig [....]

Provide direct

and backing that

the promulgation

of Airspace

changes satisfies

the related Safety

Requirements

St012

Provide direct

and backing that

the promulgation

of Airspace

changes satisfies

the related Safety

Requirements

St012

Fig [....]Fig [....]

Provide direct

and backing that

ATC Procedure

publication

satisfies the

related Safety

Requirements

St013

Provide direct

and backing that

ATC Procedure

publication

satisfies the

related Safety

Requirements

St013

Fig [....]

Provide direct

and backing that

ATC Equipment

changes satisfy

the related Safety

Requirements

St015

Fig [....]Fig [....]

Provide direct

and backing that

ATC Equipment

changes satisfy

the related Safety

Requirements

St015

Provide direct

and backing that

ATC Equipment

changes satisfy

the related Safety

Requirements

St015

Fig [....]

Provide direct

and backing that

ATC Training

delivery satisfies

the related Safety

Requirements

St014

Fig [....]Fig [....]

Provide direct

and backing that

ATC Training

delivery satisfies

the related Safety

Requirements

St014

Provide direct

and backing that

ATC Training

delivery satisfies

the related Safety

Requirements

St014

Figure 9 – Arg 2.2: Safety of Realisation

In the case of equipment aspects of Realisation, most of the

Evidence will come from analysis and testing. The Backing for

this is not decomposed herein but should address the V&V

requirements covered in Chapter 4, section 6 above.

Chapter 5 Safety Case Development Manual

Page 44 Released Issue Edition: 2.2

St004

Show that risk during

(and immediately

following) Migration will

satisfy Cr001 item 2

Detailed plan

for Migration

produced

Arg 3.1

H&RA

results

SAM SSA

Ch 3, 3.2.1

Migration

Plan

Fig 1

Migration to

Change_SGxy

will be

acceptably safe

Arg 3

Hazards and

Risks for

Switchover

identified and

analysed

Arg 3.2

Measures put in

place to control

/ mitigate risks

Arg 3.3

Contingency

plan prepared,

for reversion to

safe state

Arg 3.4

St016

Show that

Migration

evidence is

trustworthy

Risk-

reduction

measures

SAM SSA

Ch 3, 3.2.2

Contingency

Plan

SAM SSA

Ch 3, 3.2.1

H&R

process

adequate

for the task

Arg 3.5

Plans and risk-

reduction measures

independently

validated

Arg 3.6

Contingency

Plan

SAM SSA

Ch 4 GM A-B-C

Planning and

analysis staff

were

competent

Arg 3.7

Competence

evidence

SAM SSA

Ch2

Risk-

reduction

measures

SAM SSA

Ch 4 GM A-B-C

St004

Show that risk during

(and immediately

following) Migration will

satisfy Cr001 item 2

St004

Show that risk during

(and immediately

following) Migration will

satisfy Cr001 item 2

St004

Show that risk during

(and immediately

following) Migration will

satisfy Cr001 item 2

Detailed plan

for Migration

produced

Arg 3.1

Detailed plan

for Migration

produced

Arg 3.1

H&RA

results

SAM SSA

Ch 3, 3.2.1

H&RA

results

SAM SSA

Ch 3, 3.2.1

Migration

Plan

Migration

Plan

Fig 1

Migration to

Change_SGxy

will be

acceptably safe

Arg 3

Fig 1Fig 1

Migration to

Change_SGxy

will be

acceptably safe

Arg 3

Migration to

Change_SGxy

will be

acceptably safe

Arg 3

Hazards and

Risks for

Switchover

identified and

analysed

Arg 3.2

Hazards and

Risks for

Switchover

identified and

analysed

Arg 3.2

Measures put in

place to control

/ mitigate risks

Arg 3.3

Measures put in

place to control

/ mitigate risks

Arg 3.3

Contingency

plan prepared,

for reversion to

safe state

Arg 3.4

Contingency

plan prepared,

for reversion to

safe state

Arg 3.4

St016

Show that

Migration

evidence is

trustworthy

St016

Show that

Migration

evidence is

trustworthy

St016

Show that

Migration

evidence is

trustworthy

Risk-

reduction

measures

SAM SSA

Ch 3, 3.2.2

Risk-

reduction

measures

SAM SSA

Ch 3, 3.2.2

Contingency

Plan

SAM SSA

Ch 3, 3.2.1

Contingency

Plan

SAM SSA

Ch 3, 3.2.1

H&R

process

adequate

for the task

Arg 3.5

H&R

process

adequate

for the task

Arg 3.5

Plans and risk-

reduction measures

independently

validated

Arg 3.6

Plans and risk-

reduction measures

independently

validated

Arg 3.6

Contingency

Plan

SAM SSA

Ch 4 GM A-B-C

Planning and

analysis staff

were

competent

Arg 3.7

Planning and

analysis staff

were

competent

Arg 3.7

Competence

evidence

SAM SSA

Ch2

Competence

evidence

SAM SSA

Ch2

Risk-

reduction

measures

SAM SSA

Ch 4 GM A-B-C

Figure 10 – Arg 3: Safety during Migration

Arg 3

Clearly, in introducing a substantial change (or new system) the

safety of the existing ATM service must be preserved during the

period of Migration form the pre-change to post-change state.

Figure 10 shows a typical decomposition of the Argument, with

supporting Evidence, covering both the Direct and Backing

aspects.

Arg 4

Arg 4 in effect recognises that Evidence provided under Arg 1

to Arg 3 is necessarily predictive in nature and needs to be

confirmed by Evidence of what is actually achieved in practice,

from a safety perspective.

This is illustrated in the decomposition of Arg 4, in Figure 11.

Safety Case Development Manual GSN Safety Argument Examples

Edition: 2.2 Released Issue Page 45

On-going Operation

of Change_SGxy will

be shown to be

acceptably safe

Arg 4

Fig 1

St005

Safety Monitoring

will satisfy Cr001

items 1 and 2

Arg 4.1

Frequency of (service-

level) incidents will be

measured against pre-

defined indicators

Arg 4.2

Corrective actions

will be taken to

prevent recurrence

of incidents

Arg 4.2.2

All reported

incidents will be

investigated

Arg 4.2.3

Corrective actions

will be taken based

on the results of an

incident

investigation

Investigation

process

SAM SSA

Ch 3, 3.3.1

Arg 4.2.1

There is a process

for encouraging

the reporting of

safety incidents

Reporting

process

SAM SSA

Ch 3, 3.3.1

C012

Required for compliance

with Cr001, item 2

St008

Develop Backing

Argument and Evidence

regarding the

effectiveness of the

reporting, investigation

and C/A processes

Fig [….]

Monitoring

process

SAM SSA

Ch 3, 3.3.1 C/A

process

SAM SSA

Ch 3, 3.3.2

On-going Operation

of Change_SGxy will

be shown to be

acceptably safe

Arg 4

Fig 1Fig 1

St005

Safety Monitoring

will satisfy Cr001

items 1 and 2

St005

Safety Monitoring

will satisfy Cr001

items 1 and 2

St005

Safety Monitoring

will satisfy Cr001

items 1 and 2

Arg 4.1

Frequency of (service-

level) incidents will be

measured against pre-

defined indicators

Arg 4.2

Corrective actions

will be taken to

prevent recurrence

of incidents

Arg 4.2.2

All reported

incidents will be

investigated

Arg 4.2.3

Corrective actions

will be taken based

on the results of an

incident

investigation

Investigation

process

SAM SSA

Ch 3, 3.3.1

Arg 4.2.1

There is a process

for encouraging

the reporting of

safety incidents

Reporting

process

SAM SSA

Ch 3, 3.3.1

C012

Required for compliance

with Cr001, item 2

St008

Develop Backing

Argument and Evidence

regarding the

effectiveness of the

reporting, investigation

and C/A processes

St008

Develop Backing

Argument and Evidence

regarding the

effectiveness of the

reporting, investigation

and C/A processes

Fig [….]Fig [….]

Monitoring

process

SAM SSA

Ch 3, 3.3.1 C/A

process

SAM SSA

Ch 3, 3.3.2

Figure 11 – Arg 4: Safety Monitoring

2. Example Application of GSN – Unit Safety Cases

Claim

Unit Safety Case is a commonly used term for the Safety Case

for an on-going operational service. Figure 12 below shows the

high-level Safety Argument for this example application of GSN,

for a hypothetical ATSU.

Arg 0 is the overall Claim, equivalent to that for Change “SGxy”

in Figure 1 above. C001 defines the type(s) of service provided

and C002 is a reminder that the full operational environment –

eg airspace boundaries, structure, classification, rules,

separation minima etc – needs to be fully described in order to

define the Context in which the Claim is being made.

Chapter 5 Safety Case Development Manual

Page 46 Released Issue Edition: 2.2

Arg 0

ATM services

provided by

<<ATSU>> are,

and will remain,

acceptably safe

Arg 2

Any changes to the

ATM System are made

such that the ATM

services will remain

acceptably safe

Arg 1.1

Safety Assessment

shows that the

ATM Services are

acceptably safe

Arg 1

The on-going ATM

Services are

acceptably safe

J001

ATM services are provided by

the ATM system

C001

ATM services comprise eg:

Airspace Management;

ATC Service;

Alerting; and Advisory Service

C002

Operational Environment

Cr001

Acceptably Safe defined as:

The risks of an accident or safety-related

incident:

1 achieve a tolerable level and

2 have been reduced As Far As

Reasonably Practicable (AFARP)

C003

Subject to declared Assumptions,

Limitations and outstanding Issues

Fig 13

Arg 1.2

Safety Monitoring &

Improvement shows

that the ATM Services

are acceptably safe

Fig 14 C005

System includes: airspace,

equipment, people and procedures

and the organisation

C004

For the extant configuration of

the ATM services and system

St001

Decomposition based on two dissimilar

approaches:

1 A proactive, analytical approach based on

inductive Safety Assessment techniques

2 A reactive, empirical approach based on

direct measurement of safety achievement

through in-service Safety Incident

Monitoring and Safety Improvement

Cr003

Tolerable level of risk defined

by Safety Indicators for ESARR

2-defined incidents, based on

historical achievement /

accepted tolerability

Cr002

Tolerable level of risk

defined by ESARR

4-compliant Safety

Targets

Fig [….]

Arg 0

ATM services

provided by

<<ATSU>> are,

and will remain,

acceptably safe

Arg 2

Any changes to the

ATM System are made

such that the ATM

services will remain

acceptably safe

Arg 1.1

Safety Assessment

shows that the

ATM Services are

acceptably safe

Arg 1

The on-going ATM

Services are

acceptably safe

J001

ATM services are provided by

the ATM system

C001

ATM services comprise eg:

Airspace Management;

ATC Service;

Alerting; and Advisory Service

C002

Operational Environment

Cr001

Acceptably Safe defined as:

The risks of an accident or safety-related

incident:

1 achieve a tolerable level and

2 have been reduced As Far As

Reasonably Practicable (AFARP)

C003

Subject to declared Assumptions,

Limitations and outstanding Issues

Fig 13Fig 13

Arg 1.2

Safety Monitoring &

Improvement shows

that the ATM Services

are acceptably safe

Fig 14Fig 14 C005

System includes: airspace,

equipment, people and procedures

and the organisation

C004

For the extant configuration of

the ATM services and system

St001

Decomposition based on two dissimilar

approaches:

1 A proactive, analytical approach based on

inductive Safety Assessment techniques

2 A reactive, empirical approach based on

direct measurement of safety achievement

through in-service Safety Incident

Monitoring and Safety Improvement

St001

Decomposition based on two dissimilar

approaches:

1 A proactive, analytical approach based on

inductive Safety Assessment techniques

2 A reactive, empirical approach based on

direct measurement of safety achievement

through in-service Safety Incident

Monitoring and Safety Improvement

Cr003

Tolerable level of risk defined

by Safety Indicators for ESARR

2-defined incidents, based on

historical achievement /

accepted tolerability

Cr003

Tolerable level of risk defined

by Safety Indicators for ESARR

2-defined incidents, based on

historical achievement /

accepted tolerability

Cr002

Tolerable level of risk

defined by ESARR

4-compliant Safety

Targets

Cr002

Tolerable level of risk

defined by ESARR

4-compliant Safety

Targets

Fig [….]Fig [….]

Figure 12 –: Overall Safety Argument for a Unit Safety Case

Arg 1

Arg 1.1

C003 is a reminder that the eventual conclusion of the Safety

Case will probably be subject to certain Assumptions and

outstanding Issues that need to be addressed and possibly to

some Limitations on the ATM service(s).

The definition of what is acceptably safe is captured in Cr001,–

note that item 1 (as elaborated in Cr002 and Cr003) is an

absolute measure, as is appropriate to an on-going service.

The Claim (Arg 0) is decomposed into two principal Safety

Arguments (Arg 1 and Arg 2) that, in effect, the services are

safe “today” (ie for the current system baseline – C004 refers)

and will remain so because any changes to the baseline will be

managed so as to maintain the safety of the services.

The decomposition of Arg 1 is very similar to that for “Change

SGxy” but, generally, on a much larger scale; in other words,

this part of the Unit Safety Case (although not related to

change) treats the Unit as a large ATM system for which:

• Safety Requirements (for the system) are derived and

satisfied in a predictive Safety Assessment (Arg 1.1);

• actual safety achievement is monitored and improved

through empirical Safety Monitoring (Arg 1.2).

Arg 1.1 is not decomposed further herein but should follow a

similar pattern to the equivalent Argument for Change “SGxy”

except that the underlying FHA, PSSA and SSA activities

should be carried out for the ATSU as a whole.

Safety Case Development Manual GSN Safety Argument Examples

Edition: 2.2 Released Issue Page 47

Arg 1.2 The decomposition of Arg 1.2 , shown in Figure 13 below, is

the equivalent to that for Arg 4 for “Change SGxy” shown in

Figure 11 above, except that the context for the former is the

“present” time, rather than the future.

Arg 1.2.1

ATM Services achieve

tolerable frequencies

of (service-level)

incidents

Arg 1.2.2

Corrective actions

are effective in

preventing

recurrence of

incidents

Fig 12

C006

Based on what is actually

achieved in operational

service

Arg 1.2.2.2

All reported

safety incidents

are investigated

effectively

Arg 1.2.2.3

Recommendations for

corrective actions

from incident

investigations are

implemented

throughout the ATSU

Ref

Incident

Investiga

tion

Reports Ref

C/A

reports

Ref

Safety

Monitoring

Reports

Arg 1.2.2.1

There is a process

and culture for

encouraging the

reporting of safety

incidents

Ref

Reporting

process

C007

Required for compliance

with Cr001, item #2

St002

Develop Backing

Argument and Evidence

regarding the

effectiveness of the

reporting, investigation

and C/A processes and

competence of the staff

involved

Fig [….]

Arg 1.2

Safety Monitoring &

Improvement shows

that the ATM Services

are acceptably safe

Arg 1.2.1

ATM Services achieve

tolerable frequencies

of (service-level)

incidents

Arg 1.2.2

Corrective actions

are effective in

preventing

recurrence of

incidents

Fig 12Fig 12

C006

Based on what is actually

achieved in operational

service

Arg 1.2.2.2

All reported

safety incidents

are investigated

effectively

Arg 1.2.2.3

Recommendations for

corrective actions

from incident

investigations are

implemented

throughout the ATSU

Ref

Incident

Investiga

tion

Reports Ref

C/A

reports

Ref

Safety

Monitoring

Reports

Arg 1.2.2.1

There is a process

and culture for

encouraging the

reporting of safety

incidents

Ref

Reporting

process

C007

Required for compliance

with Cr001, item #2

St002

Develop Backing

Argument and Evidence

regarding the

effectiveness of the

reporting, investigation

and C/A processes and

competence of the staff

involved

St002

Develop Backing

Argument and Evidence

regarding the

effectiveness of the

reporting, investigation

and C/A processes and

competence of the staff

involved

Fig [….]Fig [….]

Arg 1.2

Safety Monitoring &

Improvement shows

that the ATM Services

are acceptably safe

Figure 13 – Safety Monitoring and Improvement

Arg 2 For most Unit Safety Cases the system baseline is not fixed but

is updated periodically by Project Safety Cases produced for

significant changes – eg Change SGxy above.

Arg 2, decomposed in part in Figure 14 below is concerned

with showing that all the necessary processes are in place (and

are properly executed) to ensure that such changes are

managed safely in terms of the on-going service – both during

the period of introducing the change (”Migration”) and in the

subsequent in-service period.

Note that this is one of the few situations that processes are

used as Direct Evidence. Adherence to those same processes

would be used as Backing Evidence in the related Project

Safety Cases.

Chapter 5 Safety Case Development Manual

Page 48 Released Issue Edition: 2.2

Arg 2

Any changes to the

ATM System are made

such that the ATM

services will remain

acceptably safe

Fig 12

Arg 2.1

Processes exist to ensure

that changes are made

such that the ATM services

will remain acceptably safe

during migration to the

new system configuration

Cr004

Acceptably safe during

migration defined as:

Risks from migration

have been reduced

AFARP

Arg 2.2

Processes exist to ensure

that changes are made

such that the ATM services

will remain acceptably safe

following migration to the

new system configuration

Ref

Process

Evidence

Arg 2.3

Changes to system

baseline

configuration have

been implemented

correctly

Ref

Other

Change-

acceptance

records

Ref

Project

Safety

Cases

Ref

Safety-audit

records

St003

Decompose to levels

necessary to demonstrate

the effectiveness all SMS

Operational, Engineering

and Mgt processes that are

relevant to the execution of

change

Fig [….]

Arg 2

Any changes to the

ATM System are made

such that the ATM

services will remain

acceptably safe

Fig 12Fig 12

Arg 2.1

Processes exist to ensure

that changes are made

such that the ATM services

will remain acceptably safe

during migration to the

new system configuration

Cr004

Acceptably safe during

migration defined as:

Risks from migration

have been reduced

AFARP

Cr004

Acceptably safe during

migration defined as:

Risks from migration

have been reduced

AFARP

Arg 2.2

Processes exist to ensure

that changes are made

such that the ATM services

will remain acceptably safe

following migration to the

new system configuration

Ref

Process

Evidence

Arg 2.3

Changes to system

baseline

configuration have

been implemented

correctly

Ref

Other

Change-

acceptance

records

Ref

Project

Safety

Cases

Ref

Safety-audit

records

St003

Decompose to levels

necessary to demonstrate

the effectiveness all SMS

Operational, Engineering

and Mgt processes that are

relevant to the execution of

change

St003

Decompose to levels

necessary to demonstrate

the effectiveness all SMS

Operational, Engineering

and Mgt processes that are

relevant to the execution of

change

Fig [….]Fig [….]

Figure 14 – Change Management

3. Example Application of GSN – Preliminary Safety Cases

Preliminary (or Outline) Safety Case is a term used in

EUROCONTROL for the Safety Case that it restricted in both

scope and responsibility. It is particularly applicable to EATM

programmes since EUROCONTROL’s responsibility is usually

restricted to proving the concept behind a change (or new

system) – ie to proving that the service / system will be safe in

principle.

Figure 15 below shows the high-level Safety Argument for this

example application of GSN. The further decomposition and

accompanying commentary is limited to illustrating the main

differences between a full Project Safety Case (eg Change

“SGxy” above) and the equivalent Preliminary Safety Cases.

Figure 15 is the same as Figure 1 above, except as follows:

• A new Argument (Arg 2) has been introduced, and forms an

important bridge between the Preliminary Safety Case (of

which it is a part) and the subsequent Implementation safety

case / safety approval.

Safety Case Development Manual GSN Safety Argument Examples

Edition: 2.2 Released Issue Page 49

Change_SGxy will

be acceptably safe

in operational

service

Arg 0

St 001

Specify safety criteria for each of the

4 main life-cycle stages and show that

each stage is / will be acceptably safe

– ie the safety criteria are sufficient to

achieve the required level of safety,

and are satisfied

C001

Operational concept

(SAM-FHA ch1-GM A)

Change_SGxy

Implementation

is acceptably safe

Arg 3

Change_SGxy

Concept is

acceptably safe,

in principle

Arg 1

A001

Current ATM service

is accepted as being safe

J001

Change_SGxy is being

introduced to meet a

legitimate operational need

Cr001

The risk of an accident following

Change_SGxy shall be:

1.Within the regulatory requirements – eg:

a. such that the whole ATM service

meets ESARR 4 Design Safety

Targets (SAM-FHA ch3 GM E); OR

b. no greater (and preferably lower)

than currently exists.

AND

2. reduced as far as reasonably

practicable.

Migration to

Change_SGxy

will be

acceptably safe

Arg 4 On-going Operation

of Change_SGxy will

be shown to be

acceptably safe

Arg 5

Fig [….]

C002

Subject to declared

Assumptions, Limitations

and outstanding Issues

Sufficient Guidance

exists to enable

complete and correct

Implementation of the

Safety Requirements

Arg 2

Fig [….]

Fig [….] Fig [….] Fig [….]

Change_SGxy will

be acceptably safe

in operational

service

Arg 0

Change_SGxy will

be acceptably safe

in operational

service

Arg 0

St 001

Specify safety criteria for each of the

4 main life-cycle stages and show that

each stage is / will be acceptably safe

– ie the safety criteria are sufficient to

achieve the required level of safety,

and are satisfied

St 001

Specify safety criteria for each of the

4 main life-cycle stages and show that

each stage is / will be acceptably safe

– ie the safety criteria are sufficient to

achieve the required level of safety,

and are satisfied

C001

Operational concept

(SAM-FHA ch1-GM A)

Change_SGxy

Implementation

is acceptably safe

Arg 3

Change_SGxy

Implementation

is acceptably safe

Arg 3

Change_SGxy

Concept is

acceptably safe,

in principle

Arg 1

Change_SGxy

Concept is

acceptably safe,

in principle

Arg 1

A001

Current ATM service

is accepted as being safe

J001

Change_SGxy is being

introduced to meet a

legitimate operational need

Cr001

The risk of an accident following

Change_SGxy shall be:

1.Within the regulatory requirements – eg:

a. such that the whole ATM service

meets ESARR 4 Design Safety

Targets (SAM-FHA ch3 GM E); OR

b. no greater (and preferably lower)

than currently exists.

AND

2. reduced as far as reasonably

practicable.

Cr001

The risk of an accident following

Change_SGxy shall be:

1.Within the regulatory requirements – eg:

a. such that the whole ATM service

meets ESARR 4 Design Safety

Targets (SAM-FHA ch3 GM E); OR

b. no greater (and preferably lower)

than currently exists.

AND

2. reduced as far as reasonably

practicable.

Migration to

Change_SGxy

will be

acceptably safe

Arg 4

Migration to

Change_SGxy

will be

acceptably safe

Arg 4 On-going Operation

of Change_SGxy will

be shown to be

acceptably safe

Arg 5

On-going Operation

of Change_SGxy will

be shown to be

acceptably safe

Arg 5

Fig [….]Fig [….]

C002

Subject to declared

Assumptions, Limitations

and outstanding Issues

Sufficient Guidance

exists to enable

complete and correct

Implementation of the

Safety Requirements

Arg 2

Sufficient Guidance

exists to enable

complete and correct

Implementation of the

Safety Requirements

Arg 2

Fig [….]Fig [….]

Fig [….]Fig [….] Fig [….]Fig [….] Fig [….]Fig [….]

Figure 15 – Overall Safety Argument for Preliminary Safety Case

• The Guidance referred to in Arg 2 should include, but not be

limited to, the following:

o an amplification of the scope of the Preliminary Safety

Case – ie what is, and what is not included;

o a clear delineation of the responsibilities between

EUROCONTROL and the organisation(s) responsible for

Implementation;

o clear instructions for the Implementers concerning the

re-use / re-working of the safety assessment results

included in (or accompanying) the Preliminary Safety

Case – these should include a warning that the some of

the parameters on which the original safety assessment

were based may not be directly applicable to the context

in which the implementation is being done because of:

other changes that might have occurred during the time

elapsed between the Preliminary Safety Case and the

implementation, or differences between operational

context / environment assumed in the Preliminary Safety

Case and the local situation;

o clear instructions for the Implementers concerning the

re-use of any other information in the Preliminary Safety

Case; particular attention should be drawn to the Scope,

Operational Context, Assumptions, Issues and

Limitations and to the importance of these being

validated by the Implementer and the analysis reworked

as necessary;

o guidance on the additional safety assessment work

needed to cover the Implementation, Migration and

Chapter 5 Safety Case Development Manual

Page 50 Released Issue Edition: 2.2

Operational phases;

o guidance on how to develop the Preliminary Safety

Case into a full (Project) Safety Case.

• The responsibility for Arg 3 to Arg 5 (equivalent to Arg 2 to

Arg 4 in Figure 1) rests with the Implementer, although

some aspects of responsibility for Migration and on-going

Safety Monitoring (eg specification of requirements) may

rest with EUROCONTROL.

Safety Case Development Manual References

Edition: 2.2 Released Issue Page 51

APPENDIX A REFERENCES

EATM References

[1]

Air Traffic Management Strategy for the Years 2000+, EUROCONTROL

[2]

The EUR RVSM Pre-Implementation Safety Case, Edition 2.0, 14 August 2001

[3]

The EUR RVSM Post-Implementation Safety Case, Edition 2.0, 28 July 2004

[4]

EATMP Glossary, European Organisation for the Safety of Air Navigation (EATMP),

Edition 1.0, 1 August 2000

[5]

EUROCONTROL Air Navigation System Safety Assessment Methodology,

SAF.ET1.ST03.1000-MAN-01, Nov 2006, Edition: 2.1

SRC References

[6]

SRC-EATMP Interface Process, SRC DOC 6, Edition 2.0, Released Issue, 7th

November 2002

[7]

ESARR 2: Reporting and Assessment of Safety Occurrences in ATM, Edition 2.0,

Released Issue, 3rd November 2000.

[8]

ESARR 3: Use of Safety Management Systems by ATM Service Providers, Edition

1.0, Released Issue, 17th July 2000

[9]

ESARR 4: Risk Assessment and Mitigation in ATM, Edition 1.0, Released Issue, 5th

April 2001

[10]

ESARR 5: ATM Services’ Personnel, Edition 2.0, Released Issue, 11 April 2002

[11]

ESARR 6: Software in ATM Systems, Edition 1.0, Released Issue, 06 November

2003

ICAO References

[12]

Annex 11 to the Convention on International Civil Aviation, Air Traffic Control Service

Flight Information Service Alerting Service, Thirteenth Edition, July 2001

External References

[13]

Guidelines for CNS/ATM Systems Software Integrity Assurance, March 2002.

[14]

The Public Inquiry into the Piper Alpha Disaster, Volumes 1 & 2, November 1990,

HMSO Publications Centre ISBN 0-10-113102-X.

[15]

EUROCAE, ED-125, Process for Deriving Risk Classification Scheme and Specifying

Safety Objectives in ATM “in compliance” with ESARR 4, Version 6 (proposed issue).

Appendix A Safety Case Development Manual

Page 52 Released Issue Edition: 2.2

PAGE INTENTIONALLY LEFT BLANK

Safety Case Development Manual Glossary and Abbreviations

Edition: 2.2 Released Issue Page 53

APPENDIX B GLOSSARY AND ABBREVIATIONS

GLOSSARY

Accident An occurrence associated with the operation of an aircraft

which takes place between the time any person boards the

aircraft with the intention of flight until such time as all persons

have disembarked, in which a person is fatally or seriously

injured, the aircraft sustains damage or structural failure, or the

aircraft is missing or is completely inaccessible (ICAO, 1994).

Adequate In the context of the Safety Case Development Manual

adequacy is interpreted to mean necessary and sufficient.

Aircraft Accident An occurrence associated with the operation of an aircraft

which takes place between the time any person boards the

aircraft with the intention of flight until such time as all such

persons have disembarked, in which: a) a person is fatally or

seriously injured as a result of being in the aircraft, or in direct

contact with any part of the aircraft,; or b) the aircraft sustains

damage or structural failure which adversely affect the

structural strength, performance or flight characteristics of the

aircraft, and would normally require major repair or

replacement of the affected component; or c) the aircraft is

missing or is completely inaccessible.

Argument A statement asserting a fact that can be shown to be true or

false.

Backing <entity> arguments, strategies or evidence that help support and

validate Direct (qv) evidence of the satisfaction of a goal. For

example, competence, methodology, following a process, etc.

Causes Actions, omissions, events, conditions, or a combination

thereof, which led to the accident or incident. (ICAO).

Direct <entity> Arguments, strategies or evidence that directly support the

satisfaction of the Claim. For example, test results, FHA

results, etc.

Functional Requirements Operational requirements that determine what functions a

system [including person] should perform; they can usually be

expressed by a verb applying to a type of data, (eg display

aircraft position).

Good Practice A practice that is sufficiently recognised by various

people/organisations to allow it to be used as an informal

standard. The concept of Good Practice is derived from our

responsibilities as professional operators, engineers and

managers. We set ourselves a duty of care for all the people

who use, operate, maintain and come into contact with the Air

Traffic Service domain. Our objective is to ensure that we only

See ESARR 4 for full definition

Appendix B Safety Case Development Manual

Page 54 Released Issue Edition: 2.2

make claims relating to safety that are supportable by the use

of within current good practice.

Incident An occurrence, other than an accident, associated with the

operation of an aircraft that affects or could affect the safety of

the operation of the aircraft. (ICAO, 1994).

Integrity The assurance that all functions of a system perform within

operational performance limits.

Migration The processes involved in transitioning from the current system

state to the new / modified system state.

Necessary In the context of a Safety Argument, that which must be

included in order to satisfy the Argument – cf sufficient (qv).

Preliminary Safety Case The term used in EATM to describe a Safety Case which

covers of part of the full project lifecycle – typically a

Preliminary Safety Case would demonstrate the safety of a

Concept subject to the subsequent Implementation being

executed completely and correctly.

Product Used herein to denote the output of a process as opposed to

the process itself – the distinction between product and process

is very important in structuring a Safety Argument.

Project In the context of this Manual, “project” is used generically to

denote any temporary endeavour undertaken to introduce a

substantial change to an ATM system or service. It should be

interpreted as including EATM Programmes.

Project Safety Case A Safety Case which addresses the safety of a (proposed)

change to the on-going operation of an ATSU – a Project

Safety Case would normally result in an update of the

corresponding Unit Safety Case (qv).

Reliability The probability of performing a specified function without a

failure under given conditions for a specific period of time.

Risk Analysis A technique used to evaluate risks and to analyse how far

forecasts might go wrong – and at what cost.

Safety Criterion A specification of what is acceptable and/or tolerable in terms

of risk.

Shall, Should 1 – Shall: denotes a mandatory requirement; 2 – Should:

denotes a preferred requirement.

Sufficient In the context of a Safety Argument, (at least) enough to

entirely satisfy the Argument – cf necessary (qv).

System A set of interconnected, interdependent parts, forming an

identifiable, organised complex and dynamic whole. In the

context of this Manual, it includes airspace, equipment, people

and procedures.

Target Level of Safety A level of how far safety is to be achieved in a given context,

assessed with reference to an acceptable or tolerable risk.

Safety Case Development Manual Glossary and Abbreviations

Edition: 2.2 Released Issue Page 55

Unit Safety Case A Safety Case which addresses the safety of the on-going

operation of an ATSU – cf Project Safety Case (qv).

ABBREVIATIONS

ANS Air Navigation Service

ATC Air Traffic Control

ATM Air Traffic Management

ATS Air Traffic Service

ATSU Air Traffic Services Unit

DRACAS Defect Reporting, Analysis and Corrective Action System

EATM European Air Traffic Management [Programme]

ECAC European Civil Aviation Conference

ESARR EUROCONTROL Safety Regulatory Requirements

FHA Functional Hazard Assessment

FTA Fault Tree Analysis

GSN Goal Structuring Notation

ICAO International Civil Aviation Organisation

PSC Preliminary Safety Case

PSSA Preliminary System Safety Assessment

RCS Risk Classification Scheme

RVSM Reduced Vertical Separation Minima

SMS Safety Management System

SRC Safety Regulation Commission

SRU Safety Regulation Unit

SSA System Safety Assessment

TLS Target Level of Safety

USC Unit Safety Case

Appendix B Safety Case Development Manual

Page 56 Released Issue Edition: 2.2

PAGE INTENTIONALLY LEFT BLANK

Safety Case Development Manual Safety Case Checklist

Edition: 2.2 Released Issue Page 57

APPENDIX C SAFETY CASE DEVELOPERS AND REVIEWERS CHECKLIST

Safety Case Checklist

Ch/S

2929

Yes

No N/A

Safety Case Presentation: General 2/-

1. Is the aim of the Safety Case explained and clear? 2/3

2. Is the purpose of the Safety Case explained and clear? 2/3

3. Is the scope of the Safety Case explained and clear? 2/3,4

4. Is a justification given as to why the introduction of the

change(s) - ie the subject of the Safety Case - is

necessary?

2/1,2

5. Is the ‘system’ and its environment completely and correctly

described and bounded? 2/3,4

6. Is the operational concept described? 2/3,6

7. Is the regulatory context described? 2/5

8. Is the Safety Case structured along the lines of the

Argument?

9. Is the Argument structure apparent in the layout of each of

the core sections?

Argument Structure 4/3

10. Is the overall Claim a single, clear and unambiguous

statement of what the Safety Case is trying to

demonstrate?

3/2

11. Is the Claim expressed in a positive way – ie does it accept

the “burden of proof”? 2/1

12. Is the context clear?

13. Are the criteria for being ‘acceptably safe’ appropriate and

adequately specified? 4/2

14. Are the initial assumptions explicitly stated?

Reference to Chapter/Section(s) in the Safety Case Development Manual for more information

Appendix C Safety Case Development Manual

Page 58 Released Issue Edition: 2.2

Ch/S

2929

Yes

No N/A

15. Is the decomposition of the Argument structure adequately

explained by “Strategies”?

16. Is the level of decomposition appropriate to the complexity

of the Safety Case and/or Evidence?

17. Is each level of decomposition necessary and sufficient to

show that the parent Argument is true?

18. Is each Argument set out as a simple predicate?

19. Is the Argument structure free of negative and inconclusive

Arguments? [Lack of evidence of risk ≠ Evidence of lack of

risk]

20. Does the Argument structure appear to be immune to

possible counter Arguments which could undermine the

top-level Claim?

21. Is the distinction between product- and process-based

Arguments clear?

22. Are Arguments supposedly related to the observable

properties of the related product (ie Direct Arguments)

actually addressing the outputs of a process?

23. Are Arguments supposedly related to the observable

properties of the related processes which generated that

product (ie Backing Arguments) actually addressing the

process?

24. Are Direct Arguments and Evidence supported by enough

Backing Arguments and Evidence to give sufficient

confidence in the former?

25. Where process-based Arguments are used as Direct

Arguments, is this appropriate?

26. Is each branch of the Safety Argument structure terminated

in Evidence?

Evidence 4/4

27. Is all the presented Evidence necessary to support the

Argument to which it relates?

28. Is all the presented Evidence clear, objective, relevant and

conclusive in showing the related Argument to be true?

29. Is the rigour of the Evidence appropriate to the associated

risk – ie is it to the required level of assurance?

30. Has the Evidence been produced from following an

Safety Case Development Manual Safety Case Checklist

Edition: 2.2 Released Issue Page 59

Ch/S

2929

Yes

No N/A

accepted and recognised methodology?

31. Is the underlying safety analysis sound?

32. Does the safety analysis address both the desired and

undesired behaviour of the ‘system’?

33. Are the various possible types of Evidence – design, test,

previous usage etc – used appropriately?

34. Where Evidence is contained in appendices or external

documents, is an adequate summary presented in the body

of the Safety Case alongside the related Argument?

35. Where Evidence is based on compliance with standards, is

its usage appropriate and justified?

36. Does the Evidence actually relate to the system /

configuration under consideration?

Caveats 2/3

37. Have all the Assumptions been clearly stated and

validated, or responsibilities for validation been stated?

38. Have all the outstanding Issues been cleared, or

responsibilities for clearing them been stated?

39. Have Limitations on the scope of the analysis been clearly

stated?

40. Have Limitations on the deployment / operation of the

‘system’ been clearly stated?

Conclusions 2/3

41. Is there a clear statement of what the Safety Case

concludes, which relates to the initial, overall Claim?

42. Is it made clear that the conclusions are subject to the

stated Caveats (see above)?

Comments

Appendix C Safety Case Development Manual

Page 60 Released Issue Edition: 2.2

Final Page (Blank)

Safety Case Development Manual V2.2_RI_13Nov06 EUROCONTROL

EUROCONTROL%20Safety-case-development-manual

Navigation menu

Versions of this User Manual:

Views

Navigation