EUROCONTROL Experimental Centre Safety Handbook

EUROCONTROL Experimental CentreSafety Handbook

EEC Project Safety Handbook for Project Leaders & Project Teams

EUROCONTROLSafety Research Team

EUROCONTROL

1

Safety Handbook Objective

Why Embed Safety at the Design Stage?

Who should use this Handbook?

When should you ask for further support?

EUROCONTROLEUROCONTROL

The EUROCONTROL Experimental Centre is faced with the challenge of developing and validating a new ATM Concept to cope with increasing demands for civilian air travel. In the next decade and a half major changes are foreseen. During these changes it is imperative that safety is not compromised, but rather is improved to balance risks from increased traffic. Although ATM Safety Standards have been high in the past, this cannot be assumed for the future, especially given the rate of change and the foreseen increases in capacity. Within it’s work programme, the EEC will focus a significant effort on safety and human factors assurance of the future ATM Concept.

This Safety Handbook is intended to assist Concept Element Leaders and Team Members decipher the relatively new and sometimes complex “Safety Language” and to understand how to demonstrate the safety of their Concept Elements.

As the EEC Director I have witnessed on many occasions the unnecessary constraints which are designed into a system or a process because safety has not been considered at an early enough stage. There is numerous evidence from accident analysis which points to “the design” as a contributory factor. Therefore it is essential from a safety and cost effective perspective that we go as far as is practicable to ensure that safety is given adequate consideration at the concept and design stages.

This Handbook is intended to be the first port of call for Teams and Team Leaders when establishing what is required for their concept elements. It can also be used as a “jargon buster” when face to face with your Safety Specialist! We hope that is presented in plain language at a level which is easy to digest.

This Handbook is not intended to replace the role of your Safety Coordinator or Safety Manager. It is a quick reference guide which may help you to ask and understand the right questions so that your Concept Element remains on track to contributing to a validated overall ATM Concept.

2


Notes

A - Safety Overview


3

Safety Techniques Safety Resources Case StudiesSafety Deliverables

What do we need to Deliver?

What Techniques are available?

What is available to assist me?

What has been done before?

What is our Safety Goal at the EEC? – Demonstrate “in principle” a Validated ATM ConceptHow Safe does my Concept Element need to be? - What are Hazards, Risks & Risk Targets?How much does my Concept Element contribute to ATM Risks? – the Integrated Risk Picture (IRP), Top Down and Bottom Up AnalysisWhat are my Safety Responsibilities? – Safety ResponsibilitiesWhat do I need to do to demonstrate Safety? – Demonstrating SafetyWhat are the benefits of doing Safety Activities during Design? -Added Value and TimingWhat is available to help me demonstrate Safety in my concept element? - Safety Support

PAR

T A

–10

Pag

e Sa

fety

Ove

rvie

w

Part B - More Detailed Guidance


Notes

What are we aiming for?

How will this be achieved?

What does thismean for your

Concept Element?Each of these changes will include for example ATM systems,overall ATC configurations, Airport configurations, Actorresponsibilities / ways of working etc. If the overall Future ATMConcept is to be validated, then each of the individual ConceptElements needs to be shown to be safe as well as the manyinterfaces between them.


4

ATM Concept

Individual Concept Elements & Interfaces

EUROCONTROL is charged with developing a Validated ATM Concept to cope with the predicted futurecapacity increases. This overall Concept is being developed through individual “Concept Elements” orComponents.

Validated ATM Concept

There will be many changes required to meet this goal. The keyareas of change envisaged by the Co-operative ATM are:

Layered Planning to determine, balance, refine and optimisecapacity and demand;The introduction of reconciled 4D air and ground data;A Network Operations Plan to provide an up to date overviewof European Airspace usage throughout all phases of thelayered planning process;Increased usage of existing aircraft navigation capabilities;Changes in both pilot and controllers roles and perspectivetowards an integrated managed ATM system.

Each of these changes may be contained within single conceptelements or may represent considerations which need to beadopted across a number of interfacing element.

Key Changes

Validated ATM ConceptConsisting of individual “Concept

Elements” and their interfaces


Notes

5

EEC Safety Policy

The Key messages from the EEC Safety Policy are summarised below along with a pointer to some relevant parts which address these points within this SSG

Highest Priority for Safety – R&D to increase safety.

Leadership Commitment - appropriate resources available to assess changes.

Safety Responsibility – everyone to achieve an understanding of what their safety responsibilities are.

Future ATM Safety – understand relative safety contributions of systems and achieve an increase in safety.

Safety Built in Design – integrate safety assessment efficiently within the research, development and industrialisation of future ATM systems.

Pro-active approach to Safety Benefits –pro-actively identify areas where safety benefits can be achieved.

Safety with our Stakeholders – safety promotion, lessons learnt and attaining future safety requirements all coordinated with our Stakeholders.

7 Key PointsSafety Techniques

Safety Resources

Safety Deliverables

Responsibilities

IRP

Timing

Safety Techniques


Notes

Why do we need to consider Safety

explicitly at the concept stage?

We are running simulations, won’t

they flag all the safety issues?

Benefits

Demonstration of Safety is required to:o Meet Stakeholder Expectations – Agency, EC, ANSPs,o Fulfil Regulatory Requirements (i.e. ESARR 4),o Provide a sound basis for future project development. i.e design validation & verification by EATM

DAS & DAP and implementation of concepts by ANSPs.o Achieve Industry Best Practice .

Observations made during Concept Simulations provide a valuable and practical insight to human performance, system functionality and system interfaces. However, these observations do not provide the full picture with respect to Safety – for example rare events are unlikely to be observed during Simulations).

Hazards need to be systematically and comprehensively identified, assessed and managed in a traceable manner. Explicit Safety Activities and observations made during Simulations are complementary and if planned, can achieve better value from both processes by minimising duplication and gaps.

Requirements

Explicit and Implicit Consideration

o Accident and Incident analysis shows that many accident causes are linked to the design stage of a system or process. Therefore the sooner safety starts, the better.

o Early involvement of Designers in Safety Assessment increases their safety awareness, helps them to take ownership for safety so allowing safety to be an integral part of the design rather than a “bolt-on” extra.


6

Added Value

o At the early stages of a concept, design flexibility is at it’s maximum and hence consideration of safety can lead to the discovery of “Safety Opportunities” or the most cost effective and integrated solutions to safety concerns. For example potential safety “show-stoppers” can be eliminated or controlled using protection mechanisms rather than over-reliance on the controllers to save a flawed system concept.

o Involvement of other Stakeholders in EEC Safety Activities helps to reinforce the importance of Safety Consideration throughout a concept lifecycle for all concerned .


Notes


A Hazard is a condition, event or circumstance which lowers the safety of an activity (i.e. that could induce an accident).

The Outcome (severity) of a hazard will vary depending on what Barriers function to prevent or minimise propagation. A Barrieris a preventative or mitigating feature which eliminates the hazard, reduces it’s likelihood (frequency) or mitigates it’s consequences (severity).

Causes are the principal failures, errors or configurations leading to a Hazard or Hazard Outcome. Risk is the combination of severity and frequency of a hazard or hazard outcome.

Hazards & Risks

What are Hazards, Risks, Causes &

Barriers?

Organisational Factors (Management decisions & Organisational processes)

Individual/ Team Actions Errors & Violations

Task / Environmental Conditions (Error & Violation producing conditions)

Failure TypesOrganisational Factors (Management decisions & Organisational processes)

Individual/ Team Actions Errors & Violations

Task / Environmental Conditions (Error & Violation producing conditions)

Failure TypesAccident or

Major Incident

RWY Configuration

RWY Separation

RIMCAS

Visual Avoidance

RIMCAS Not Installed

Low Visibility Ops

Intersecting RWYs

ATCO fails to prevent conflict

Pilot fails to recognise conflict

Frequent false alarms

Reduced Separation Ops

Active RWY crossingsBarriers

RWY Collision

RWY Incursion

RWY Conflict

Hazard Outcomes

Imminent Collision

Cause

s

Accident or Major Incident

RWY Configuration

RWY Separation

RIMCAS

Visual Avoidance


Low Visibility Ops

Intersecting RWYs






RWY Collision

RWY Incursion

RWY Conflict

Hazard Outcomes

Imminent Collision

Cause

s

So in this example, the Hazard is a Runway Incursion, the causes (which allow the Hazard to propagate to an Accident) are;

use of active RWY crossings,failure of ATCO to prevent the conflict, no RIMCAS installed;low visibility operations preventing pilot visual avoidance.

7


Notes

How is Risk acceptability determined?

What does this mean in practice for my Concept

Element?Overall & Component Risk TargetsAs Part of the Safety Plan Process, Risk Targets will be derived based on relevant ICAO targets, IRP values (see next page) and the relevant flight phases and accident categories that the Concept Element includes. These are often referred to as the Target Level of Safety (TLS).

At the simplest level each Concept Element must demonstrate that either it has no effect on safety, or that overall safety is improved. If this cannot be achieved, then more effort is required to determine if the Concept Element can be justified.EUROCONTROLEUROCONTROL

8

Risk Targets

Safety Criteria

EUROCONTROL Safety Policy“...to ensure that ATM-related safety risks are reduced...”ATM 2000+ accidents per year do not increase.EEC Safety Policy there is an increase in Safety along with the implementation of the Future ATM System.ICAO Targets (e.g.en-route 5x10-9

fatal accidents / flight hr/ATM dimension).AFARP – to reduce risks As Far As Reasonably Practicable. ESSAR 4 safety criteria (1.55 x 10-8

accidents with direct ATM contribution pfh)

Having identified Hazards and assessed their risks, the question of acceptability arises. The following Safety Criteria are adopted for this purpose:

Risk Targets

Ris

k pe

r Flig

ht

Years

1996

20122020 Future Risk Target

Risk Target Apportioned across Concept Components

ASAS ATCWake CDM

etc

ATM 2000+ accidents per year do not increase, means risk per flight must

decrease as capacity increases.

Ris

k pe

r Flig

ht

Years

1996

20122020 Future Risk Target

Risk Target Apportioned across Concept Components

ASAS ATCWake CDM

etc

ATM 2000+ accidents per year do not increase, means risk per flight must

decrease as capacity increases.


Notes

What are current significant overall

ATM risk contributors to

aviation accidents?

What causes contribute to these

accidents and what can my

Component do to improve these?

In runway incursions, a cause could be a stop bar failure or failure of pilot to follow an instruction. Influencing factors are those which may have contributed to these causes – e.g. fatigue and high workload, or inadequate maintenance or training.

The IRP can provide quantitative risk values for individual accident categories, their causes and influences to assist in prioritising areas for risk reduction. Alignment of Components with these primary risk areas can assist in ensuring effective risk reduction. In addition a top down approach can be used to set safety targets.

More details on use of the IRP Model is provided in the Techniques part of this Handbook.

Example – Runway Accidents

IRP input into Safety Prioritisation & Component Safety Targets


9

IRP

In order that we can determine how ATM risks are apportioned across the various ATM elements, functions and tasks, a risk model is needed. Better understanding of this risk apportionment not only allows us to focus our efforts on the current significant risk contributors, but also helps us to predict the risk impact of currently proposed ATM concepts and whether we will be able to meet our future targets.

Through accident analysis, the Integrated Risk Picture (IRP) has been developed to estimate the current ATM contribution to accidents. The direct causes as well as influencing factors have been identified and modelled.

Taxiway

collision

Mid-air

collision

Runw

ay collision

Wake

turbulence

CFIT

ATM Risks

AccidentCategories

Causes(Failed Barriers)

InfluencingFactors

Taxiway

collision

Mid-air

collision

Runw

ay collision

Wake

turbulence

CFIT

ATM RisksTaxiw

ay collision

Mid-air

collision

Runw

ay collision

Wake

turbulence

CFIT

ATM Risks

AccidentCategories

Causes(Failed Barriers)

InfluencingFactors


Notes

How do the risks for individual

Concept Components fit into the overall

ATM Risk Picture?


10

Top-Down, Bottom-Up

The EEC adopts both a ‘bottom-up’ and ‘top down’ approach to ensure that safety is considered at a detailed level at the concept component level and to determine whether, as a whole, ATM operational concepts will be acceptably safe.

The bottom-up part of the process starts with the identification of hazards and then the assessment of associated risks and interfaces for each Concept Element. These risks can then be compared with the apportioned Safety Target generated using the top down analysis.

Top-Down

Bottom-Up

In this way we hope to be able to ensure that risks and interfaces associated with individual components roll-up to meet our overall target for risk.

Meeting of the Two

.

Risks assessed for individual Concept

Components are rolled up and compared with Overall Risk Target

ASAS ATCWake CDM

etc

Rolled-up Concept Risk

Risk Target

The Risk Target for the overall ATM Concept (TLS) is generated through use of the IRP current (2005) and predicted future (2020) risk figures and taking into account other Safety Criteria (e.g. ATM 2000+).

This overall Risk Target can be used to derive Safety Targets for individual Concept Elements.


Notes

What is required throughout my

Concept Element development &

when?

Which Concept Elements need to undertake Safety Assessments?

Project Stage Safety Deliverables ObjectivesDetermine what the key Hazards & Safety Benefits might be.

?

Determine what level of Safety Assessment is required, what targets are appropriate & set Safety Responsibilities.

Initial Concept Definition Available

Functional Hazard AnalysisDetermine what can go wrong (Hazards)and how bad it can be (severity).

Functional Model Developed

Preliminary System Safety AssessmentDetermine causes and frequencies of hazards outcomes and if furtherRequirements are needed to meet Targets.


11

Demonstrating Safety

To ensure that Hazards and Risks are adequately identified and assessed throughout the evolution of an EEC concept, a series of Safety Deliverables (reports) are required. In developing these Deliverables, a variety of Safety Techniques may be utilised. The following diagram provides an overview of the key deliverables. More detailed information is provided in the Safety Deliverables and Safety Techniques parts of this handbook.

Def

initi

onD

esig

n?

FHA

Safety Plan

PSSA

PSC

Considerations

Haz

ard

Log

Preliminary Safety CaseDemonstrate in principle that Safety Criteria and Risk Targets can be met.

The Hazard Log provides the record and common link regarding the identification and management of hazards throughout the concept element evolution.


Notes

What can I do to optimise effort / time and output

from these safety activities?

Why do we consider safety

before the concept is fully developed?

The timing and type of Safety Assessment undertaken is an important factor in determining the effectiveness of the assessment and the added value for the development of the Concept Element.

During the initial development of a Concept Element, high level identification of potential safety concerns that require consideration is appropriate. In some cases Safety may be a “Show Stopper” for a concept element and therefore early identification of this is clearly advantageous. In other cases consideration of safety may be an enabler through prompting alternative ideas. As the Concept design is detailed, more comprehensive and detailed identification and assessment is required to ensure that the design and interfaces with other concept elements will achieve acceptable levels of safety.

Optimisation & Design Flexibility

Examples of Timing & Benefits


Case Studies presented at the back of this Safety Handbook provide examples of the application of safety techniques and the generation of Safety Deliverables. The specific benefits in terms of concept validation and timely identification of safety issues are presented. SRT can assist you in programming Safety Activities for your Project to maximise the benefits through timely consideration of Safety.

12

Timing

The ability to effectively and efficiently eliminate or manage safety concerns decreases as the concept element develops (see Figure). Therefore, the early identification of safety issues is key to enabling an integrated and efficient resolution to be achieved with minimal delay.

Design Effort / Cost

Des

ign

Flex

ibilit

y

Project Maturity

High level of flexibility enables elimination of hazards and efficient integration of safety requirements.

Design / Concept well defined, Integration of safety requirements possible but effectiveness & efficiency rapidly decreases.

Add on safety possible. Increased cost and delays to project likely.

Definition Design Implementation


Notes

Who is responsible for the Safety of

my Concept Element(s)?

What does this responsibility

mean in practice & where can further

guidance be found?

As the Concept Element Leader, you are ultimately responsible and accountable for the management of safety (as you are for technical, financial and program risks). This means that you need to:

Ensure appropriate processes are employed to identify, eliminate or mitigate potential safety risks,Ensure appropriate safety competency exists within the team,Delegate safety responsibilities and provide authority to team members to ensure the above is achievedProvide clear safety direction to all team members on the need for considering Safety,Encourage team members to raise safety concerns,Report Safety risks to EEC Senior Management.

Your Team Members have a responsibility to:Proactively Identify, Communicate and where possible and practical, mitigate Safety Concerns or risks within the Concept Element;Undertake necessary Safety Training – as agreed with the Concept Element Leader;Share safety knowledge / skills with other team members.


13

Responsibilities

Further guidance and support on identifying, agreeing, documenting and fulfilling these Safety Responsibilities is available from the Safety Research Team.


Notes

Assistance in developing Safety Considerations and Project Safety Plans which:identify the level of Safety Assessment Required and required resources / timing,identify a clear and practical direction,develop specific Project Safety Targets,Provide the Safety Argument Structure,Identify Key Safety Considerations & Assumptions and Implications,Identify Key Project Safety Interfaces – i.e what may already be in place to assist, what needs to be addressed.

Safety Research Team provide….

Other Projects can …..Offer practical advice and material on applying Safety techniques and managing the outcomes -i.e what worked / added value and what didn’t. SRT can provide project contact details.

Contact:Eric PerrinEEC SMS Co-ordinatorEEC Safety Research TeamTel: +33 1 69 88 74 01Fax: +33 1 69 88 73 52

Assistance in performing Safety Assessments and developing Preliminary Safety Cases:

Access and Guidance on use of Safety Techniques and Safety Data when undertaking AssessmentsIdentify appropriate Safety Resources or Experts to assist in specific Safety Activities, Access to existing relevant Safety Reports prepared for other projects within and outside EEC (Safety Information Data Exchange System SIDES being developed),Interface with EATM and other Stakeholder approaches and requirements.

Guidance on and access to relevant Safety Training (e.g Training on Safety Overview, Safety Management and specific Safety Analysis Techniques are available).

14

Safety Support

Where do I start?

How do I find my way through all

this?

Who and what is available to assist

me?


Notes

EEC aims to demonstrate through Safety Assessment that the overall ATM concept and individual components are ”Acceptably Safe In Principle”. This means that the concept (as assessed) is implemented in a complete and correct manner (i.e. Safety Requirements are met by the operator) and that resultant operations can be shown to be acceptably safe (i.e. that risk targets have been met and are AFARP).

15

Part B – Safety Assessment Deliverables, Techniques, Resources & Case Studies

What can go wrong?

What are operational

consequences?

How likely is it?

Is this acceptable?

What controls are required?

What lessons are to be learned?

In simple terms, the risk or safety assessment process seeks to answer the questions posed in the left hand margin of this page. This is achieved through the application of appropriate Safety Techniques which provide an input into the development of the required Safety Deliverables.

Embedded within the various Safety Assessments or Deliverables are Safety Fundamentals which are generic principles aimed at improving Safety. They are divided into System, Human Factor and Safety Management Fundamentals. These fundamentals are also evident in the IRP Model, since failure to apply these fundamentals often contribute as causes to accidents.

Safety Resources are existing systems, reports, people and services are available to support the Safety Assessment process.

This Safety Handbook provides brief guidance on each of the Safety Techniques, Deliverables and Resources which are frequently used, expected or available to support the demonstration of safety of EEC Projects.

Additionally, there are a few Case Studies provided at the back of this handbook which show the sequence in which these have been applied along with the various outcomes.


Safety Techniques

Safety Deliverables

Safety Resources

Case Studies

Part B Contents


Notes

During the lifecycle of an EEC Concept Element, a series of Safety Deliverables are used to plan, assess and demonstrate the safety benefits and that acceptable safety can be achieved in principle.

16

The full System Safety Assessment (SSA) is prepared to support implementation and would normally be prepared by the ANSP or Airport Operator and so is not detailed in this handbook. The Safety Requirements from the PSSA are validated and verified in the SSA as an outcome of the testing, commissioning and implementation of the concept.

Safety Deliverables

What Deliverables are required to demonstrate

safety within our Concept Element?


Des

ign

Flex

ibili

ty

Project Progression

Definition Design Implementation

Safety Considerations, Safety Plan, Concept FHA, Hazard Log

Design Level FHA, PSSA, PSC, Updated Hazard Log

SSA, Updated Hazard Log

o Safety ConsiderationsDocument,

o Safety Plan,o Functional Hazard

Assessment (FHA),o Preliminary System Safety

Assessment (PSSA),o Prelimnary Safety Case (PSC),o Hazard Log.

Information from each safety assessment stage will be integrated into the concept (e.g. hazards identified in the FHA will be carried through to the PSSA for assessment). The Hazard Log provides an ongoing record (throughout all the assessment stages) of identified hazards, recommended controls and their final close-out / acceptance.

The following pages outline the objectives, inputs, processes and outputs of the standard deliverables which are required (for an EEC Concept Element with Safety Impact):

FHA

Safety Plan

PSSA

PSC

Consider -ations

Haz

ard

Log

SSA


Notes


17

Safety Deliverables

Determine the potential safety concerns and benefits and how they should be addressed – scoping the need for and type of Safety Assessment.

Objectives

Initial Concept Descriptionwhich includes a description of the proposed changes to the ATM model in terms of Operational Improvements, Proposed Systems or modifications, Safety Benefits (intended or consequential) and potential Safety Hazards identified at a high level.

IRP Barrier Model which is used to identify the relevant accident categories, flight phases and safety fundamentals that apply.

InputsConcept Description analysed and broken down into the key ATM elements which are mapped onto the IRP barrier model to identify the safety impacts of the concept element.

Based on the list of Safety Fundamentals within the Safety Considerations Template, identify potential high level safety impacts.

Consider at a high level, the interfaces with other Concept Elements.

Safety Considerations document which identifies:

the key safety issues (and benefits) that are required to be addressed – input into Hazard Log.

The interfaces with the other elements.

Recommendations for further safety assessment – which will be carried forward into the Safety Plan.

Definition Stage – i.e. high level

When?

Process Outputs

SIDES, HARTS, Considerations Template, Project Team, SRT member to assist.Resources

Considerations

Max 2-3 Pages

Consider -ations



Notes

Determine how the safety of a Concept Element is to be demonstrated - i.e. what level of safety assessment is required, what targets are appropriate and set Safety Responsibilities.

Objectives

Initial Concept Description

Safety ConsiderationsDocument

Concept Element Risk Profile(derived using IRP Data)

Applicable Safety Criteria

Concept Element Organisation Chart

InputsDevelop initial Safety Argument which clearly represents proposed way of demonstrating the safety of the concept element – i.e. how will we meet the Safety Criteria

Identify necessary activitiesrequired to meet Safety Criteria and develop schedule.

Assign responsibilities for the development, input and review of the various safety activities and deliverables.

Agreed Safety Criteria

Initial Safety Argument

Safety Schedule outlining Safety Activities

Safety Roles and Responsibilities

Identification of Stakeholder Involvement

Safety Plan Document

Possible input into the Hazard Log

Definition StageWhen?

Process Outputs

18

Safety Deliverables

SIDES, HARTS, Safety Plan Template, SRT member to assist.Resources

Safety Plan

Max 20 pages

Safety Plan



Notes

Determine how safe the System or Concept should be – i.e. identify potential Hazards & Safety Benefits & establish the Safety Objectives.

Objectives

Concept Description which outlines the assumed Operating Context and Interfaces with other ATM systems (existing or future).

Experienced Team including an FHA Facilitator to lead the Workshop, experienced ATM users to identify possible hazards and failures during operations and project team members who can advise on concept details.

InputsDevelop Functional Model which clearly represents proposed concept functionality, assumptions and interfaces.

Use Incident and Accidentdata, FHA Workshops, Simulations to identify the potential hazards and the severity of their effects.

Identify the possible range of consequences (Hazard Outcomes) for the identified Hazards (using Event Trees).

FHA Report containing:

Safety Objectives (e.g. the maximum acceptable frequency for each Hazard Severity Class).

Assumptions and Boundaries of the Assessment.

Hazard Log which lists all identified potential hazards along with their Severity Classification and existing and proposed controls which may be formalised as Safety Requirements.

Definition Stage – i.e. high level

When?

Process Outputs

19

Safety Deliverables


SIDES, HARTS, SafLearn, Simulations, SRT member, Relevant StakeholdersResources

FHA

FHA


Notes

Identify through analysis what Safety Requirements are required to meet the Safety Objectives and Targets.

Objectives

Concept Design description

FHA Report

InputsHazards identified in the FHA are analysed to determine possible causes.

Overall Risk determined (combining causes and consequences) and compared with Safety Target.

Necessary Safety Requirements identified and confirmed as practical / acceptable.

Demonstration that risks have been minimised As Far As Reasonably Practicable.

PSSA Report containing:

Overall Risk Result –confirmation that Safety Targets and Objectives can be met.

List of Safety Requirements

Updated list of Safety Assumptions

Updated Hazard Log.

Early Design StageWhen?

Process Outputs

20

Safety Deliverables


SIDES, HARTS, SafLearn, Incident Reports, SRT Member, Relevant Stakeholders Resources

PSSA

PSSA


Notes

Provide assurance that Safety Criteria / Risk Targets can be met and Safety Benefits can be delivered in principle.

Objectives

System Definition & Design description including the intended system lifecycle (design, installation, ongoing operations, & maintenance).

FHA / PSSA Outputs

Hazard Log

Results from any tests, trials, simulations.

InputsBased on the output from the PSSA, evidence is gathered to support the safety argument and demonstrate that the Safety Requirementscan be implemented.

Any assumptions, limitations and remaining Hazards are explicitly detailed.

PSC Report including:Overall Risk Result.

Demonstration that Safety Targets and Objectives can be met including the final safety argument and supporting evidence.

Updated Safety Requirements and list of Safety Assumptions.

Updated Hazard Log.Recommendations regarding future design development / implementation or operations.

Concept HandoverWhen?

Process Outputs

21

Safety Deliverables


SIDES, HARTS, SafLearn, Incident Reports, SRT member, Relevant StakeholdersResources

PSC

PSC


Notes

Identifier (ID) Source Date of EntryFunction

or Task

CausesConsequences/

Effects

Hazard

Impact of New

System

SC 1 SC 2 SC 3 SC 4 SC 5 F P R ER EI H M L

Current

Safeguards *ew

Recommendation/

Comment

Recommendation

Status

Treatment in

Safety Assessment

Severity

FrequencyRisk

Risk Screening

Provide a continuous record of hazards which are identified, assessed and controlled throughout the lifecycle of the Concept Element.

Objectives

All Safety Scoping documents and Safety Assessmentswhere new hazards are identified or known hazards are qualified in terms of consequence, likelihood or acceptability / control.

InputsThe Hazard Log is one of the first deliverables which is populated when the initial Safety Considerations Document is developed. It is subsequently updated as further hazards or information becomes available.

Hazard Log providing an auditable trail of identified hazards, their requirements and status with respect to implementation of these requirements.

Provides evidence that all identified hazards have been recorded and managed through appropriate assessment and control. This forms part of the Safety Assurance process.

All StagesWhen?

Process Outputs

22

Safety Deliverables

IRP, SIDES, HARTS, Hazard Log Template, SRT member Resources

Hazard Log


Haz

ard

Log


Notes

Safety Techniques

23

Safety Techniques

Safety Techniques are generally aligned with:Outlining what the high level safety concerns / benefits may be (Scoping)Identifying What Can Go Wrong (Hazard Identification),Assessing How Bad the outcomes can be (Consequence Analysis),Assessing How Likely it is to happen (Frequency Analysis),Determining How Acceptable these combinations are (Risk Assessment & Control),Providing Assurance that the Safety Assessment is well founded, Safety Requirements can be implemented so that Safety Targets can be met (Risk Assurance).

There is an extensive suite of Safety Techniques available, which will vary in applicability & usefulness for each Concept Element & lifecycle stage.

What do they achieve?

Consequence Analysis

Hazard ID

Frequency Analysis

Risk Assessment

Scoping

Risk Control

Risk Assurance


Safety Toolbox

Each Safety Techniques has strengths and weaknesses in terms of:What they can deliver (Outputs);When they should be used (timing during Concept Element evolution);In what circumstances they should be used (type of process);Who or what skills are required;What Inputs (e.g. data) are required.

The following pages provide an overview of some of the key Safety Techniques that are applied to EEC Concept Elements.

Which Safety Assessment Techniques should we use?

More detailed information on each of these Safety Techniques is available through SRT and the Safety Toolbox.


Notes

25

Safety Argument

Safety Techniques

Scoping

Risk Assurance


OutputClear statement of operational assumptions, boundaries, context and evidence that must be fulfilled to provide robust demonstration that safety criteria are met. Used to provide assurance that all necessary evidence has been provided.

MethodAn overall safety claim (such as “the project is acceptably safe in principle”) is agreed. The Safety Criteria to be applied are determined and the operational context, assumptions and boundaries are stated. On the basis of this information, the supporting arguments and evidence necessary to fulfill the overall argument are developed. The argument is reviewed and revised to take account of assessment, trial and simulation results.

InputsInitial concept element description, Applicable Safety Criteria

ResourcesProject Representative, Safety Specialist,EUROCONTROL Safety Case Development Manual

A Safety Argument is initially developed as part of the Safety Plan and is used to develop the structure by which acceptable safety will be measured and demonstrated. By clearly identifying safety criteria, assumptions, boundaries and necessary evidence, the tasks required to develop the Safety Case can be planned up front.

A worked example of the top level of a Safety Argument is provided as part of the Time Based Separation Case Study at the back of this handbook.

The argument is structured in a standard format using these blocks to summarise the relevant parts.

Strategy 0Strategy being adopted to achieve the argument

Strategy 0Strategy being adopted to achieve the argument

Safety Claim we aim to prove

Argument 0Safety Claim we aim to prove

Argument 0 Context 0All relevant operatingparameters (boundaries)

Sub-argumentsArgument 1Sub-argumentsArgument 1

Criteria 0Relative or Absolute Criteria being adopted

Evidence

Any safety assumptions being made.

AssumptionAny safety assumptions being made.

Assumption


Notes

Safety Techniques

A number of techniques are used. The term “HAZID” may be used to refer to a variety of techniques including the following (or variations of):

SWIFT – Structured What-IF TechniqueHAZOP – HAZard and OPerability StudyTRACEr / HERA Predict – for predicting Human ErrorsSAFLearn – learning from historical accident & incident Data

Hazard Identification (HAZID) is the cornerstone of all safety and risk analyses. Effective Hazard Identification involves the systematic and comprehensive questioning of What Can Go Wrong within concept elements and their interfaces. It requires specialist facilitation and knowledgeable input from the design team and Stakeholders.

Hazard Identification is about finding the potential holes in the safety barriers

Role of HAZIDs Techniques & Variations

HAZID

Hazard ID

26


.

Accident or Major Incident

RWY Configuration

RWY Separation

RIMCAS

Visual Avoidance


Low Visibility Ops

Intersecting RWYs






The types of Hazard Identification techniques applied will depend on the nature, complexity and maturity of the concept element being assessed.

For example, a very early SWIFT study may be undertaken to help scope the types of hazards that may eventually require more detailed hazard analysis techniques applied to determine human error or system failure types hazards.


Notes

Safety Techniques

MethodConsider key hazards / apply guidewords in a structured team brainstorming.Guided by the facilitator.

MethodPreliminary Scoping – Establish the Objectives and Scope / Boundaries of the study and decide which technique best meets the objectives.Organisation – The structure of the study, appropriate supporting information (e.g. functional model, list of tasks or guidewords etc), and for brainstorming type studies, the study team and venue need to be organised in advance.Brainstorming – Led by a skilled facilitator, the group are asked to consider in turn (for example) specific ATM tasks within the Concept Element. Any Hazards identified by the group are recorded along with perceptions on severity, likelihood and existing or potential safeguards.

ResourcesSpecialist Facilitator;Recorder;Stakeholder Reps (e.g. Design & Operator); Recording tools; Venue.

HAZOP / SWIFT

Hazard ID

27


OutputsPotential causes of hazards / failures, their consequences and current or proposed safeguards. Hazard Log documents and prioritises recommendations (Safety Requirements) for incorporation into the design / future Safety Analysis.

Both the Structured What-If Technique (SWIFT) and HAZard and Operability (HAZOP) studies use structured brainstorming to prompt a group of participants (Designers and Stakeholders) into identifying potential hazards (or operability problems).

The Concept Element or system is broken down into key functions, elements or tasks which are considered sequentially looking for deviations from the normal or intended operations.

In HAZOP studies, specific Guidewords are used to prompt identification of these deviations:

NO or NONE, REVERSE, LESS OF / MORE OF, AS WELL AS / PART OF, SOONER THAN / LATER THAN, OTHER THAN, REPEATED, MIS-ORDERED, EARLY, LATE etc.


Notes

Safety Techniques

Human Error

OutputsPossible Human Errors associated with specific Tasks and recommended Error prevention and recovery measures.Updated Hazard Log.

MethodInitially a Task Analysis of the the new ATM Concept is performed. Each task is then analysed using the TRACEr taxonomy / classification system to identify potential errors, contributing factors (context, information available etc) and error recovery options. This analysis is usually facilitated by a Human Factors specialist.

ResourcesHuman Factors Expert experienced in using TRACEr.TRACEr Excel Worksheet.

In ATM, significant safety reliance is placed on key actors (pilots and controllers) to not only prevent hazards, but also to act in mitigating the impact of system failures. Therefore the identification of possible Human Error is often critical in ATM Safety Assessments.

TRACEr and HERA Predict are two similar techniques used to predict Human Errors that can occur in ATM systems and to develop effective error reducing measures (i.e.Hazard & Safeguard Identification). They are usually applied during the design phase of a project to help focus design effort to effectively eliminate or reduce Human Error associated with new ATM systems and tools. TRACEr uses retrospective Human Error data from incident reports to predict possible future Human Errors for new functions / designs.

Role of TRACEr / HERA Predict

InputsTask Analysis of the function / design.

28


Hazard ID


1. M1. Controller monitoring; MTCD; STCA.

1. Potential conflict with surrounding a/c.

1. Any1. Fail to remain inside manoeuvring envelope

1.2.5.2 (Flight Crew) Remain inside manoeuvring envelope as far as possible

1. L-M2. H

1. One party (controller or flight crew) detects need to abort procedure; MTCD; STCA.2. No detection required.

1. ASAS separation continued inappropriately; Potential conflict.2. Increased workload for the controller in regaining picture and responsibility for a/c.

1. No detection (visual); Inappropriate decision or plan; Late decision or plan; No decision or plan2. Mis-see; Inappropriate decision or plan

1. Fail to detect need to abort ASAS separation procedure2. Falsely detect need to abort ASAS separation procedure

1.2.5.1 (Controller or Flight Crew) Detect need to abort ASAS separation procedure due to abnormal circumstances

CommentRSLDetection MeansConsequencesInternal ErrorError ModeTask Step

1. M1. Controller monitoring; MTCD; STCA.

1. Potential conflict with surrounding a/c.

1. Any1. Fail to remain inside manoeuvring envelope

1.2.5.2 (Flight Crew) Remain inside manoeuvring envelope as far as possible

1. L-M2. H

1. One party (controller or flight crew) detects need to abort procedure; MTCD; STCA.2. No detection required.

1. ASAS separation continued inappropriately; Potential conflict.2. Increased workload for the controller in regaining picture and responsibility for a/c.

1. No detection (visual); Inappropriate decision or plan; Late decision or plan; No decision or plan2. Mis-see; Inappropriate decision or plan

1. Fail to detect need to abort ASAS separation procedure2. Falsely detect need to abort ASAS separation procedure

1.2.5.1 (Controller or Flight Crew) Detect need to abort ASAS separation procedure due to abnormal circumstances

CommentRSLDetection MeansConsequencesInternal ErrorError ModeTask StepE.g.


Notes

29

Safety Techniques



SAFLearn

OutputsReport containing accident / incident case studies which are pertinent to the Concept Element. Summary of specific hazards and findings that are to be addressed.

MethodInitially, the SAFLearn Facilitator will come up to speed with the scope, boundaries, key operating functions and high level safety issues that have been identified for the Concept Element during the Scoping phase. They will then be in a position to use SAFTool to select relevant reports for consideration by the team.

A workshop led by the SAFLearn Facilitator, consisting of internal team members and relevant External Stakeholders. Here the selected incident reports are analysed to determine what the key points of relevance / learnings are. Based on this, a series of Case Studies are developed which highlight and demonstrate (in context) these safety lessons.

ResourcesSAFLearn Facilitator; SAFtool; SRT Member, Relevant Stakeholders.

InputsSafety Considerations; Operating Concept

HAZID

Once the Concept Element has been scoped in terms of high level Safety Considerations and operational functions, the process of Hazard Identification can commence. An important part of identifying hazards and understanding some of the possible consequences that can result is to learn from previous occurrences (accidents or incidents).

SAFLearn provides lessons learned from operational experience and safety occurrences. A lesson learned is knowledge or understanding gained by experience that can be a ‘good work practice’ or a negative experience.

The SAFLearn team have undertaken Analysis, Categorisation, De-identification and Storage of a number of aviation occurrence reports within a database called SAFTool. This database of historic information is a rich resource of information, which through a facilitated process, relevant reports are extracted and analysed in order that lessons can be learnt and accounted for within the Concept Element.


Notes

Safety Techniques

SAFSIM

Role of SAFSIM


30


Hazard ID

OutputsHazard impact measurements – i.e. evidence to support assumptions on significance / effects of Hazards,Controller performance measurements, New Hazards identified,Hazard Log Updated

ResourcesHuman Factors Expert skilled in SAFSIM; Simulation Programmer; Stakeholder Reps (e.g.Controllers / Pilots);Simulation Facility; SAFSIM templates.

InputsHAZID Outputs,Previous Simulation Observations,Historical Event data.

MethodSet Objectives for the simulation – e.g. are there known significant hazards that can be simulated and measured? What other safety measurements are relevant to the simulation (e.g. reduced separation events, TCAS RA’s etc). How can these be measured (e.g. automatically logged, controller reports, independent observations)?

Plan how these hazards can be integrated into the simulation, e.g. specific events to be simulated.Prepare measurement criteria & equipment (e.g. heart rate monitors), briefing & debrief questionnaires.Brief the simulation participants and Run the Simulation. Analyse Results - update Hazard Log.

SAFSIM is a structured way of obtaining safety data and insights from real-time human-in-the-loop ATM simulations. These insights may be for example:

Controller Performance in detecting and responding to specific and known hazards, Observations regarding new Hazards which occur during the simulation.

For example a specific Hazard such as Wrong Pilot Response may be integrated into a simulation and observations made regarding how easily this is detected, responded to and what the effects are on the overall capability to maintain ATM Management.

More detailed information is available throughthe Safety Toolbox and SAFSIM Guidance links.

Safety Toolbox

SAFSIM Guidance


Notes

Safety Techniques

ETA

Overview of ProcessEvent tree Analysis will involve the following generic steps:

OutputClear and explicit representation of Barriers or Safeguards along with their effectiveness. Event Propagation. Consequence Severity Categories, Probabilities of each of these Severity Categories.

MethodThe HAZID Output is re-structured into an Event Tree by:

Identifying the barriers (i.e. functional systems);Grouping or mapping the identified consequences to the appropriate initiating event and barrier sequence (Success or failure)

Finally probabilities are assigned to each branch (based on expert judgement, historical data etc).

InputsHAZID OutputExpert judgement, historical data or Fault tree analysis on system failure probabilities.

ResourcesSpecialist Analyst;Software;

An Event Tree is used identify the need for any additional safeguards to reduce risks to acceptable levels. An Event Tree models the sequence of events that can result from a single Hazard or Initiating Event. Event trees utilise Success /failure gates to model safeguards designed to reduce the effect of the hazard. By assigning a probability to each branch of the tree, the total probability of occurrence for each accident sequence can be derived. Event trees are therefore used to structure the output from HAZIDs (i.e. group consequences, explicitly model barriers and estimate overall probabilities of identified outcomes).

Role of Event Trees


31


e.g. AIRPROX

Consequences

1

2

3

4

Yes

No

YesNo

No

YesHazard (e.g. Loss of

Separation)

Barriers / Safeguards

e.g. ATCO Detection

e.g. ACAS Alerts

e.g. STCA Alert

e.g. Visual Detection

e.g. Mid-air collision

Yes

No5

e.g. AIRPROX

Consequences

1

2

3

4

Yes

No

YesNo

No

YesHazard (e.g. Loss of

Separation)

Barriers / Safeguards

e.g. ATCO Detection

e.g. ACAS Alerts

e.g. STCA Alert

e.g. Visual Detection

e.g. Mid-air collision

Yes

No5


Notes

Safety Techniques

FTA

Fault Trees are used in a qualitative sense to gain an insight into the simplest or most likely way a hazard can occur – i.e. the minimum combinations of failures leading to the hazard. In quantitative analysis, the frequency of each hazard occurring can be calculated by assigning probabilities to each base event. In this way significant risk contributors can be easily identified.

e.g for a loss of separation hazard, a combination of failures such as ineffective strategic conflict prevention, inadequate separation instructions, inadequate pilot response etc are modelled.

Role of Fault Trees

OutputModel which clearly represents how each Hazard is generated and minimal barrier failures required to generate the Hazard.Hazard Probability calculated through the probability of contributing base events.The ability of the design to meet the safety criteria.

MethodThe HAZID Output is re-structured into an Fault Tree by:

Nominating the top-level Hazards (e.g. loss of separation);Structuring the Intermediate Failures (e.g. ineffective tactical separation ) down to the Base Events (e.g. inadequate traffic information) through the combination of AND / OR gates.

To quantify, base event probabilities are assigned either through data analysis or expert judgement.

InputsHAZID OutputExpert judgement, Historical data, failure probabilities of Base Events.


Overview of Process

Frequency Analysis

32


Hazard (e.g. Loss of Separation)

Causes

Mitigating Factors

(Top Event)

(Base Events)

e.g. Conflict Prevention e.g. Pilot

Separation

e.g. Inadequate Communication with Pilot

e.g. Inadequate traffic information


Notes

Safety Techniques

Risk Assessment

Role of Risk Assessment

OutputRisk value and comparison with criteria. Safety Requirements (controls) identified as necessary to meet the agreed Risk Targets (Safety Criteria).

MethodThe results of the frequency and consequence analyses are combined to provide an overall risk level which is compared with the Safety Criteria.

Any unacceptable risks must be reduced through the application of risk control measures (see next page). An iterative process is therefore undertaken until an acceptable level of Safety is achieved.

InputsOutputs from HAZIDs, consequence and probability analyses.


Overview of ProcessRisk Assessment

33


Risk Analysis is the process of drawing together consequence and frequencyanalysis results to determine the overall risks and whether they are:

o Tolerable – i.e. acceptable in comparison to the safety criteria;

o AFARP - i.e. reduced As Far As Reasonably Practicable.

This can be done in a number of ways ranging from qualitative through to fully quantitative (and in relative orabsolute risks).

Compare with Safety Criteria.

AFARP?

Initial Risk Analysis

- Safety Objectives/ Requirements- Risk Mitigation

Subsequent Risk Analysis

Hazards

--

3FTA ETA

Risk Control

FTA ETA2

FTA ETA1

etc

Compare with Safety Criteria.

AFARP?

Initial Risk Analysis

- Safety Objectives/ Requirements- Risk Mitigation

Subsequent Risk Analysis

Hazards

--

3FTA ETA3FTA ETA

Risk Control

FTA ETA2FTA ETA2

FTA ETA1FTA ETA1

etc


Notes

Once Hazards have been identified and analysed, any unacceptable risks will require additional risk control measures to be applied for the Safety Criteria to be met. Also the need to demonstrate that risks have been reduced As Far As Reasonably Practicable (AFARP) may require further risk control measures.

The most effective way of controlling these risks to acceptable levels needs to be identified.

When assessing proposed risk controls the following should be considered:o Effectiveness and reliability of the control – (see page on Control Hierarchy);o Interactions and possible hazards associated with the mitigations themselves;o Practicality of the controls (Stakeholder consultation required).

34

Risk Control

Safety Techniques

Risk Control


Risk Control will involve the following generic steps:

Output

InputsOutputs from HAZIDs, and risk analyses.

ResourcesSpecialist Analyst;Risk Model; Design Team; Stakeholders

Overview of Process

MethodUsing the results from the Risk Analysis, the major risk contributors are determined (i.e. what part of the risk model is contributing most risk). Initial control measures may have been suggested during the brainstorming sessions and others may have been proposed during the risk analysis process. An iterative process of consultation with the designers and adjustment of the risk model will be undertaken to identify the most effective means of achieving risk compliance and demonstrating risks are AFARP.

The agreed risk controls are recorded as Safety Requirements and tracked along with key safety assumptions made by the project.


Notes

When considering the most effective way of controlling resultant risks, the following hierarchy of controls generally applies and should be considered:

35

Control Hierarchy

Consider the identified Hazard of “Stop Bar Failure” (causing an a/c to pass into an active runway). The associated risk clearly warrants significant effort to control the hazard. The following possible controls might be considered from an effectiveness and practicality perspective.

Elimination of the hazard might include a method of ensuring that the the stop bar fails to safety – i.e. shows a red indicator even when power is lost.

An Engineered control may include increasing the reliability of the stop bar or providing a back-up system, so reducing the frequency of failure.

A Procedural control might be to implement clear and effective contingency arrangements which mean there is no need for an a/c to pass an active (but failed) stop bar.

An Alarm to warn of the failed stop bar at the Tower would reveal the failure and allowrapid resolution of the problem.

Practical Example

Safety Techniques

Risk Control


Con

trol E

ffect

iven

ess

Replacing an activity or task with a less hazardous or more reliable one. Designing the activity based on the resource & capability constraints.

Substitute

Eliminate Controlling the hazard at source. Obviously the most effective control if the hazard can be totally eliminated.

Alarm Warning Devices & Alarms which tell you that an unsafe situation has or is about to occur are an important part of risk mitigation, but they do not act to prevent the hazard occurring in the first place and their effectiveness is therefore, limited.

Engineer Engineered controls include the incorporation of fail safe devices into designs, good ergonomics, increased reliability etc.

Training Reducing human error through better skills – limited again by achievable human reliability.

Procedural Procedural controls include policies and procedures for safe work practices. Their effectiveness is limited by human performance & reliability .


Notes

OutputEvidence that the safety claims, assumptions, assessment methodology and proposed Safety Requirements within a Safety Case are well founded.

36

Risk Assurance

Safety Techniques

Risk Assurance

Risk Assurance will involve the following:

Risk assurance aims at providing adequate confidence that the risk assessment has adopted best practices, assumptions are valid and that safety is integrated within the design such that acceptable safety can be achieved. Risk Assurance activities will include a variety techniques which will be used dependant on the scope and maturity of the concept element. They may include:

o Real-time simulations to validate the assumptions, claims and data utilised within the risk analysis;

o Peer Review of Safety Assessments to ensure that appropriate risk analysis techniques have been employed;

o Operational Trials to provide assurance that safety claims can be achieved in practice and that Safety Requirements are achievable.

Role of Risk Assurance

MethodInputsSafety Plan, Risk Analyses, Safety Case.

ResourcesSimulation Facility, Peer Reviewer, Stakeholders

Overview of Process


The required Risk Assurance processes detailed in the Safety Plan will depend on the risk level, scope and type of Concept Element being developed. For example new systems such as A-SMGCS or Datalink will require validation of the hardware / software configurations (including reliability and functional performance).

Once determined, the Risk Assurance activities will be conducted in consultation with relevant concept element team members and safety specialists.


Notes

Safety Resources

Resources

In preparation for and during the process of developing the various Safety Deliverables and applying Safety Techniques to you Concept Element, a number of key Safety Resources are available to assist you and your teams. The following pages provide a brief overview of five key Safety Resources available to you.

37

Safety Training

Sharing Safety Information

Document Templates

Safety Facilitation


SMH

Level 3Safety Practitioners – 3 Days

Level 2For Concept Element Leaders, Research Area Managers – 1

Day

Safety Plan Template.doc

Safety Facilitation:

Safety Document Templates:

Safety Management Handbook:

ATM Model

Document Control

Safety Information

ATM Model

Document Control

Safety Information

Safety Training:

Safety Information and Documentation Exchange System (SIDES);

Level 1Overview of Safety for all Concept Element

Members – 1 Day


Notes

Safety Resources

Training

For EEC staff there is Generic Safety Training available on an ongoing basis at 3 Levels (see figure below)./ In addition to this training in specific safety skills or techniques is available on request.

What Safety Training is Available? Which Training do I need to do?Your safety training needs will depend on your role and involvement in Safety Activities planned for your Concept Element. A Member of the SRT or your Safety Coordinator can assist you in determining what safety training you should do.

38


Safety Training

Part I - System Reliability basics (1 day)Part II - Data Analysis and Simulation Part III - EEC Techniques

Level 3

Level 2

Level 1Concept of Risk AssessmentRisk assessment in ATMSafety at the EEC: inherently safer designSafety Management System

Ensuring Safety within Concept ElementsSafety DeliverablesRisk assessment methodsRisk Management (safety resources)

Overview of Safety for all Concept Element

Members – 1 Day

For Concept Element Leaders, Research Area Managers – 1

Day

Safety Practitioners –3 Days

Once approved with your research Area Manager, enrolment on Safety Training is currently via Eric Perrin in the SRT:

How do I enrol on this [email protected]

Ph: 33 (0) 1 69 88 74 01


Notes

Safety Resources

SIDES

The EEC Safety Information Data Exchange System (SIDES) is a centralised application and repository intended to facilitate the storage and sharing of Safety Information such as Safety Plans, FHA’s and PSSAs etc. As well as the storage & sharing of these documents, it is also intended, that Safety Expertise, Knowledge, Experience & Insights gained through the application of these techniques be shared.

SIDES is split into the 3 functional areas:

What is SIDES? How is SIDES Used?

ATM Model

Document Control

Safety Information

ATM Model

Document Control

Safety Information

SIDES is therefore the first point of call when looking to identify where for example similar techniques have been applied, or similar ATM Concepts, Functions or Resources have been analysed. Within SIDES, the basis for the demonstration of Acceptability of a concept, the evolution of Safety Arguments, application of Techniques, use of Safety Data Sources, safety interfaces between concept elements and ATM systems can be investigated.

Enter new reports into

SIDES

Other Safety Deliverables

SIDES is a resource which will be used at various stages throughout the lifecycle of a project. It is a two-way relationship in that existing safety information captured for other projects can provide a useful input when scoping a new project, and when Safety Information is generated for a new Project it is captured within SIDES for future reference by others within EUROCONTROL and in the future ANSPs and other stakeholders.

SIDES searched for existing relevant

assessments, assumptions, use of data,

safety insights etc

SIDES searched for interfacing projects with related:Concepts / Systems;Safety Objectives;Considerations / Hazards;Safety Assessments;

Safety Plan / Assessments

Safety Considerations

39


Sharing Safety Information


Notes

Safety Resources

Facilitation

The Safety Research Team are available to assist you and your teams in planning for and applying the relevant Techniques, Resources and Deliverables described in this Safety Handbook.

As well as collective expertise in all areas of Safety Assessment and Human Factors Analysis, they have extensive experience in applying these within EEC ATM Concept Elements.

SRT members are available for consultation and facilitation of safety studies.

Where further specialist support is required, (beyond the capability or availability of SRT members), they are able to assist you in gaining appropriate Contract Safety Specialist support.

Safety Research Team

40

Safety Facilitation

EEC Safety Research Team Secretariat:Tel: +33 1 69 88 76 59Fax: +33 1 69 88 73 52Eric PerrinEEC SMS Co-ordinatorTel: +33 1 69 88 74 [email protected]

Contacts


Dr. Barry KirwanHead SRTTel: +33 1 69 88 78 [email protected]


Notes

Safety Resources

Templates

Follow these links

To provide assistance in developing these Safety Deiverables, standard format templates are available which provide the key headings and some guidance on what must be included within each section. Additionally, previously developed examples are available through the SRT or your Safety Coordinator / Manager.

Adopting a consistent format helps everyone to readily find specific data or sections within these various Safety Deliverables. It will also become important in the future to allow documents to automatically have keyword identification performed when entering them in the Safety Information Data Exchange System (SIDES – see SIDES Resource page in this SSG).

The templates can be accessed via the EEC SRT publications page on the Internet or by clicking on the following links:.

41


Document Templates

HazardLog_Final_v1.0.xls

Preliminary Safety Case Template.doc

PSSA Template.doc

Safety Considerations Templ

Safety Plan Template.doc

FHA Template.doc

FHA

Safety Plan

PSSA

PSC

Consider -ations

Haz

ard

Log


Notes

Safety Resources

SMH

Provides high level Guidance on the requirements for Safety Management within EUROCONTROL as well as generic processes and the EUROCONTROL Safety Policy. The Agency SMH also outlines the structure that each Directorate will adopt for their Safety Management System as shown in the diagram below.

Agency Level SMH

42


SMH

Each Directorate is required to have their own Safety Management System and hence the EEC will develop it’s own SMH detailing the processes which are specific to the research and development and concept evolution activities which are undertaken within the EEC.

EEC SMH

POLICY

PLAN

PROMOTION

ACHIEVEMENT

ASSURANCE

Element 1 - Policy

Element 2 - PlanningElement 3 - Organisational Structure

Element 9 - Safety DocumentationElement 10 - Safety OccurrencesElement 11 - Health Management Element 12 - Emergency PreparednessElement 13 - Security

Element 14 - Safety MonitoringElement 15 - Safety Survey & Review

Element 16 - Communications & Culture

Element 4 - Safety Regulation & External StandardsElement 5 - Safety Assessment & Risk MitigationElement 6 - Operations ControlElement 7 - CompetencyElement 8 - Infrastructure & External Services


Notes

Case Studies

Case Studies


The following pages provide some real examples of how a selection of the various techniques and deliverables have been utilised within the context of individual Concept Elements.

Combining Techniques & Deliverables

FHA

Safety Plan

PSSA

PSC

Consider -ations

Haz

ard

Log Consequence

Analysis

Hazard ID

Frequency Analysis

Risk Analysis

Scoping

Risk Control

Risk Assurance

Argument

HAZOP

SAFSIM

How does all this piece together?

Key Outcomes, Benefits, Timing and Resource Allocation are summarised for the specific techniques applied within the Concept Element.

These might be for example Safety Insights regarding how the concept element interacts with others, specific Safety Requirements required to make the concept element acceptably safe or lessons learnt regarding the usage of a particular technique.

This is intended to show the variations in approach for differing concept elements. More guidance and support regarding which techniques will assist your Concept Element is available from the Safety Resource Team or your Safety Manager / Coordinator.

43


Notes

HAZOP

Case Studies

CoSpace

FHA

All HAZOP participants were experienced in CoSpace Simulations. 97 errors were identified, 9 with severity level 2, and 19 with severity level 3.Recommendations affecting the concept were made with regard to:

HMI (e.g. ADD/ASAS to select correct spacing value; datalink to help ensure correct a/c takes spacing instruction); Training (e.g. TRM to help prevent the controller giving the wrong instruction); Procedural (e.g. fallback procedures if the wrong aircraft takes an instruction or wrong instruction is given);Operational environment (e.g. prevent the wrong aircraft taking an instruction, callsign confusion measures); Organizational-manning.

ScopingIdentify the key tasks which should be considered during the HAZID.

HAZOP & SAFSIM were complementary techniques to identify Hazards and determine their significance. SAFSIM allowed controllers to discuss in detail what they had experienced.

Haz

ard

Log

Benefits Timing

Deliverables

Outcomes TechniqueAssessment

Stage / Objectives

Key tasks identified for a controller controlling 2 aircraft (target, & reference aircraft) were:

First call;Target selection;Target identification;Spacing instruction;Cancel spacing.

Hazard Identification

To identify hazards, their causes, consequences, planned safeguards & estimate severity/likelihood.Identify key Safety information & Safety Requirements for input into the operational concept Risk Analysis.

Gain insights into the “Success Case” - i.e. risks associated with normal operations.

As part of the Airborne Separation Assurance System (ASAS), CoSpace is investigating the feasibility of issuing pilots with spacing instructions. As part of the development of the Functional Hazard Analysis of Airborne Spacing / Sequencing & Merging of Aircraft in the TMA, HAZOP and SAFSIM activities were undertaken to identify potential hazards and the severity of the resultant consequences.

Project Outline

Events / Hazards were selected for SAFSIM based on their estimated severity and ability to simulate. Observations and insights were captured on a debriefing sheet for discussion with the Controllers at the end of the day e.g. notes and questions about decisions made, how events detected, how event initiated, causal factors, controller recovery and possible mitigations.Key insights included ability to detect pilot errors and requirements for new emergency arrangements.

2 independent Controller and Pilot HAZOPs + a consolidation session - 5 Days of workshops over 6 months. SAFSIM - Real-time simulation occurred over one day.??? + Planning & Results Analysis Time.

SAFSIM

Task Analysis



Notes

Boundaries and Assumptions of GBAS system and operating environment established. Interfaces and gaps with avionics certification and type approval of the GBAS ground station identified.Safety Assessment activities identified to support the Operational Safety Assessment.

Case Studies

GBAS CAT I

FHA

PSSA

Identified Tasks were considered in structured Hazard Identification sessions using a freeform (unrestricted) brainstorming approach.Historical incidents were reviewed and findings compared with hazards identified in the brainstorming sessions.Consequences and likelihoods were estimated.

The HAZIDs looked at potential risk reduction measures, which were then evaluated in more detail. The hazard log was used to document such measures which have been continuously developed during the PSSA stage.

ScopingDevelop an understanding of the GBAS system & its operational environment and determine the Scope of the GBAS Safety Assessment.Identify Tasks

A high level of stakeholder involvement has been achieved through attendance at FHA workshops.

Haz

ard

Log

Benefits Timing

Deliverables

Outcomes

Hazard Identification

To identify hazards, their causes, consequences, planned safeguards & estimate severity/likelihood.Identify Safety Objectives & Safety Requirements for input into the operational concept Risk Analysis.

Ground Based Augmentation System (GBAS) is proposed as a means of maintaining All Weather Operations (AWO) capability at CATI/II & III airports when ILS technical limitations render it unavailable. Cat I GBAS approach approval is seen as the first necessary step towards the ultimate goal of CATI/II precision approach and landing approvals. The following activities are steps in developing the Operational Safety Assessment which will complement the Type Approval being sought within ECAC States / US and be a template for member states wishing to implement GBAS based CAT I approaches.

Project Outline

FTA/ETA and Bow-Tie Modelling were used to develop a rigorous linkage between failure mode, hazard and possible effects. This then enabled safety objectives to be derived.

Risk ControlShow how risk targets can be met.

Safety Assessment has been progressing in parallel and on an iterative basis with the Concept of Operation since 2001.

Safety Plan

TechniqueAssessment

Stage / Objectives

Risk AnalysisStructure the Hazard Identification & AnalysisProvide the basis for the Risk AnalysisSet Safety Objectives based on a Bow Tie Model

Safety Objectives and Requirements identified and will be verified as met within the GBAS SSA prior to operations beginning.

Heart-

THERP

FTA-

ETA-

Bow Tie

Brainstorm Sessions

-Incident Review

Scoping HAZID

-Develop ConOps



Notes

Case Studies

TBS

FHA

PSSA

PSC

Scoping

Develop an understanding of the TBS Safety Considerations. Identify Safety Criteria. Scope the TBS scenarios and boundaries.Identify & schedule required Safety Assessments & stakeholder involvement.

Plan / argument has helped engagement of external stakeholders.Required resources highlighted early.

Haz

ard

Log

Benefits Timing

Deliverables

Outcomes TechniquesAssessment

Stage / ObjectivesSafety Criteria to be applied:o Relative risk from TBS scenarios

compared with existing Distance Based Separation (DBS).

o Risks are reduced AFARP.

Safety Assessments required for:Success Caseo wake vortex encounter (WVE) risks during

normal operations,o mid-air collision (MAC) risks due to

limitations in radar surveillance standards.Failure Caseo WVE, MAC and runway collision risks. o The potential impact of TBS on the

operation of safety nets, i.e. STCA and ACAS

The existing standard distance based radar separation minima and wake turbulence separation minima on final approach ensure a safe flow of traffic onto a runway. However, during periods of strong headwinds, an airport’s capacity can be reduced due to the reduction of aircraft ground speeds resulting in a greater time interval between aircraft at the touchdown point. The main objective of the TBS Concept Element is to investigate the recovery of this capacity whilst maintaining the required level of safety.

Project Outline

Plan has highlighted long lead time issues such as WVE modelling.

Safety Plan

SWIFT-

Modelling-

SAFSIM

IRP Profile-

Safety Argument


Future Tasks

ETA-

FTA


Notes

Case Studies

TBS Argument


Figure 1 Concept - Overall Fig 0

Strategy 1Show that success case (normal operations) Safety Requirements satisfy Criteria 0 items 1 & 2 for specific scenarios.Show that the success case specific scenario results are valid in general.Show that the failure case Safety Requirements satisfy Criteria 0Show the analysis is trustworthy.

Safety criteria are satisfied by the Safety Requirements derived by consideration of specific success case scenarios

Arg 1.1

Fig 1.1

Safety Requirements specified such that TBS is acceptably safe in principle.

Arg 1

Safety criteria are satisfied in general by the specific scenario Safety Requirements plus any further identified Safety Requirements

Arg 1.2

Fig 1.2

Fig 1.4

Safety Requirements evidence is trustworthy

Arg 1.4Safety criteria are satisfied by the Safety Requirements derived by consideration of failures in the TBS system

Arg 1.3

Fig 1.3

All success case and failure case scenarios have been identified and considered

Arg 1.5

Figure 1 Concept - Overall Fig 0Fig 0

Strategy 1Show that success case (normal operations) Safety Requirements satisfy Criteria 0 items 1 & 2 for specific scenarios.Show that the success case specific scenario results are valid in general.Show that the failure case Safety Requirements satisfy Criteria 0Show the analysis is trustworthy.

Safety criteria are satisfied by the Safety Requirements derived by consideration of specific success case scenarios

Arg 1.1Safety criteria are satisfied by the Safety Requirements derived by consideration of specific success case scenarios

Arg 1.1

Fig 1.1

Safety Requirements specified such that TBS is acceptably safe in principle.

Arg 1Safety Requirements specified such that TBS is acceptably safe in principle.

Arg 1

Safety criteria are satisfied in general by the specific scenario Safety Requirements plus any further identified Safety Requirements

Arg 1.2Safety criteria are satisfied in general by the specific scenario Safety Requirements plus any further identified Safety Requirements

Arg 1.2

Fig 1.2

Fig 1.4

Safety Requirements evidence is trustworthy

Arg 1.4Safety Requirements evidence is trustworthy



Arg 1.3

Fig 1.3

All success case and failure case scenarios have been identified and considered

Arg 1.5All success case and failure case scenarios have been identified and considered

Arg 1.5

Figure 0 Overall Relative Argument Structure

Strategy 0Show that safety criteria are satisfied in each key lifecycle phase, i.e. “Concept”, “Implementation”and “Ongoing Operation”, for all phases of flight and in all operational conditions worldwide. Any exceptions to be explicitly recorded.

Time Based Separation (TBS) will be acceptably safe.

Arg 0Context 0All relevant phases of flight (final approach, missed approach, others?)All locations worldwide (including all meteorologies, topologies etc.). All types of generating and encountering aircraft.Subject to stated assumptions, limitations and outstanding issues.

Implementation of WV Safety Requirements are complete and correct.

Arg 3Safety Requirements specified such that TBS will be acceptably safe in principle.

Arg 1

Assumption 0 Current Safety Requirements for Distance Based Separation (DBS) result in operations that are considered to be acceptably safe.

Criteria 0The risk of an accident during TBS shall be:1. no greater (and preferably lower) than currently exists with DBS;2. and further reduced as far as reasonably practicable.

On-going Operation of TBS will be shown to be acceptably safe.

Arg 4

Fig 1 Fig 4

Sufficient guidance exists and has been communicated to enable complete and correct implementation of the Safety Requirements by all parties. Responsibilities for safety are clearly defined

Arg 2

Fig 2 Fig 3

Responsibility of EUROCONTROL Responsibility of operational organisations, such as ANSPs, regulators etc

Figure 0 Overall Relative Argument Structure

Strategy 0Show that safety criteria are satisfied in each key lifecycle phase, i.e. “Concept”, “Implementation”and “Ongoing Operation”, for all phases of flight and in all operational conditions worldwide. Any exceptions to be explicitly recorded.

Time Based Separation (TBS) will be acceptably safe.

Arg 0Context 0All relevant phases of flight (final approach, missed approach, others?)All locations worldwide (including all meteorologies, topologies etc.). All types of generating and encountering aircraft.Subject to stated assumptions, limitations and outstanding issues.

Implementation of WV Safety Requirements are complete and correct.

Arg 3Safety Requirements specified such that TBS will be acceptably safe in principle.

Arg 1

Assumption 0 Current Safety Requirements for Distance Based Separation (DBS) result in operations that are considered to be acceptably safe.

Criteria 0The risk of an accident during TBS shall be:1. no greater (and preferably lower) than currently exists with DBS;2. and further reduced as far as reasonably practicable.

On-going Operation of TBS will be shown to be acceptably safe.

Arg 4

Fig 1 Fig 4

Sufficient guidance exists and has been communicated to enable complete and correct implementation of the Safety Requirements by all parties. Responsibilities for safety are clearly defined

Arg 2

Fig 2 Fig 3

Responsibility of EUROCONTROL Responsibility of operational organisations, such as ANSPs, regulators etc

Figure 1.1 Success Case Safety Requirements Satisfaction

All practicable mitigations identified and analysed

Arg 1.1.2.1

Process evidence

Risks have been reduced as far as reasonably practicable (taking account of technical and economic factors)

Arg 1.1.2

Fig 1

Success case risks are no higher than DBS levels

Arg 1.1.1

Concept WV Analysis & Radar Surveillance CRM

Safety Requirements are realistic

Arg 1.1.3

Verification evidence

Safety criteria are satisfied by the Safety Requirements derived by consideration of specific scenarios

Arg 1.1

Model 1.1.1WVE & Radar Surveillance CRM Modelling results for success case

Figure 1.1 Success Case Safety Requirements Satisfaction

All practicable mitigations identified and analysed

Arg 1.1.2.1

Process evidenceProcess evidence

Risks have been reduced as far as reasonably practicable (taking account of technical and economic factors)

Arg 1.1.2Risks have been reduced as far as reasonably practicable (taking account of technical and economic factors)

Arg 1.1.2

Fig 1

Success case risks are no higher than DBS levels

Arg 1.1.1Success case risks are no higher than DBS levels

Arg 1.1.1



Safety Requirements are realistic

Arg 1.1.3Safety Requirements are realistic

Arg 1.1.3



Safety criteria are satisfied by the Safety Requirements derived by consideration of specific scenarios

Arg 1.1Safety criteria are satisfied by the Safety Requirements derived by consideration of specific scenarios

Arg 1.1

Model 1.1.1WVE & Radar Surveillance CRM Modelling results for success case

First 3 levels of the TBS Safety Argument drafted as part of the Scoping Stage and included in the Safety Plan


Notes

Case Studies

TBS Risk Profile


Insert IRP Risk Profile

Integrated Risk Picture Influencer Map v0.6 PAGE 2Base Event

in Fault Tree

Task Performance

Performance Of Actors

Performance of Equipment

Operating Environment

Resources Competence HMI Redundancy Maintainability Integrity Terrain Traffic Weather

Reliability Procedures Teamwork Functionality Independence Transparency Other

Project Name: Date:Description:

Project Area Classification:Airspace organisation & management

K [+] [o] [-] P [+] [o] [-] Air traffic flow and capacity managementATC planning

L [+] [o] [-] Q [+] [o] [-] ATC performanceATC systems

M [+] [o] [-] R [+] [o] [-] CommunicationsSurveillance

N [+] [o] [-] S [+] [o] [-] Flight planningAeronautical information

O [+] [o] [-] T [+] [o] [-] ATM avionicsAirport infrastructure

M+ N-

Confusion if TBS & DBS procedures?Extra display complexity?More traffic - Capacity enhancementStrong Wind should reduce / equalise

WV risk

L+

K+

TBS 5/4/06Time not Distance based sep in strong headwinds


in Fault Tree

Task Performance













M+ N-


WV risk

L+

K+



in Fault Tree

Task Performance













M+ N-


WV risk

L+

K+


Integrated Risk Picture Causal Model Map v0.6 PAGE 1

Design Strategic Planning In Flight Ground Based Safety Nets Flight DeckPre - Tactical Tactical ATC Recovery Pilot Recovery

Taxiway Collision

Design Manoevering Area Configuration

Ground Movement Procedures Visual Warning

3%

Runway Collision

Design Runway Configuration

ATC Runway Instructions

ATCO - Pilot communication Pilot Actions Conflict Warning ATC Visual

Warning Visual Warning

56%

Mid-Air Collision

Design ATFCM Traffic Synchronisation

Level Bust Prevention

Airspace Penetration Prevention

ATC Separation Instructions

ATCO - Pilot communication

Pilot Separation Actions STCA Warning Other ATCO

Warning ACAS Warning Visual Warning

32%

Wake Turbulance


Wake Separation Instructions


Pilot Separation Actions Visual Warning

2%

CFIT Design Pilot Trajectory commands

FMS Trajectory Commands

ATC Trajectory Commands

On Board Monitoring (CRM) ATC Warning GPWS Warning Visual Warning

7%

Take Off / Landing

Design Traffic Synchronisation ATC Instructions ATCO - Pilot

communication Pilot Actions ATC Visual Warning Visual Warning

<1%

Accident Category Project Name: Date:

Relative importance of

accident category to ATM

Description:Project Area Classification:Airspace organisation & management

A [+] [o] [-] F [+] [o] [-] Air traffic flow and capacity managementATC planning

B [+] [o] [-] G [+] [o] [-] ATC performanceATC systems

C [+] [o] [-] H [+] [o] [-] CommunicationsSurveillance

D [+] [o] [-] I [+] [o] [-] Flight planningAeronautical information

E [+] [o] [-] J [+] [o] [-] ATM avionicsAirport infrastructure

TBS 5/4/06

B+

A+

Reduced sep in strong headwindsSeparation below MRS

Time not Distance based sep in strong headwinds

✔✔



Taxiway Collision



3%

Runway Collision





56%

Mid-Air Collision








32%

Wake Turbulance





2%





7%

Take Off / Landing



<1%










TBS 5/4/06

B+

A+





Taxiway Collision



3%

Runway Collision





56%

Mid-Air Collision








32%

Wake Turbulance





2%





7%

Take Off / Landing



<1%










TBS 5/4/06

B+

A+





Taxiway Collision



3%

Runway Collision





56%

Mid-Air Collision








32%

Wake Turbulance





2%





7%

Take Off / Landing



<1%










TBS 5/4/06

B+

A+



✔✔


Notes

A - CACAS – Airborne Collision Avoidance SystemANSP – Air Navigation Service ProvidersASAS - Airborne Separation Assurance SystemATCO – Air traffic Control OfficerBarrier – system or action which act to prevent or minimise propagation of a hazard.Boundaries – limits in terms of the scope of a safety assessment (e.g. excluding consideration of VFR traffic, low visibility operations or specific types of airports (e.g. military) would be assessment boundaries).Cause – Principal failure mechanism, error or configuration leading to a Hazard or Hazard OutcomeCDM – Collaborative Decision MakingConcept – Overall proposed mode of operatingConcept Element – specific proposed change, new system or action which contribute to the realisation of the overall Concept.

D - PEEC – EUROCONTROL Experimental CentreEvidence – Operational data, historic events, results of trials etc which support a claim made within the Safety Argument.HARTS – Hazard and Tracking SystemHazard – Condition, event or circumstance which lowers the safety of an activityIRP – Integrated Risk Picture

R - TRisk – Combination of consequence (severity) and frequency (likelihood)TLS – Target Level of SafetySAM – Safety Assessment MethodologySAND – Safety Assessment for new DesignsSafety Argument – the structure by which acceptable safety will be demonstrated.Safety Assumptions – any assumed safety related system, function or action (e.g. presence of TCAS, ability of aircraft to maintain independent navigational capability etc). Must be made explicit within the safety assessment.Safety Benefits – Any positive safety implication which may be realised through a proposed change.Safety Claims – statements which support a Safety Argument (usually in terms of risk mitigation or likelihood). They require Evidence to rove their validity.Safety Deliverables – EEC Safety Reports including Safety Plans, Functional Hazard Assessments, HAZOP Reports, Safety Cases etc.Safety Objectives - the maximum acceptable frequency for a Hazard Severity Class in order to meet the Safety Targets).Safety Requirements – measures required for the Safety Objectives to be met (e.g. additional barriers, or reliability targets).Safety Techniques – various methods applied from scoping a concept through to quantified Risk AnalysisSafety Targets – Quantitative and Qualitative risk targets (e.g. to not increase risk, 1 x 10-9

fatalities / movement). Also called Safety Criteria.SAFLearn – Technique for Safety Learning from IncidentsSIDES – Safety Information Data Exchange System. Resource providing a central database of ATM safety information.SRT – EEC Safety Research Team.TLS – Target level of Safety. Safety Target.

Glossary



Notes


EEC Safety Research Team Secretariat:Tel: +33 1 69 88 76 59Fax: +33 1 69 88 73 52

Contacts:

50

Dr. Barry KirwanHead SRTTel: +33 1 69 88 78 [email protected]

Documents

EUROCONTROL Experimental Centre Safety Handbook