nefab safety plan v3 -...

North European Functional Airspace Block Avinor, Norway | EANS, Estonia | Finavia, Finland | LGS, Latvia

of 44

NEFAB Project

SAFETY PLAN

Version 3.01


of 44

Revision history

Version Date Description Approved

3.01 14/12/2011


of 44

Contents 1. INTRODUCTION ................................................................................................. 5

1.1 Purpose ......................................................................................................... 6

1.2 Scope of the plan ........................................................................................... 6

1.3 Roles and Responsibilities............................................................................. 6

1.3.1 Project ..................................................................................................... 6

1.3.2 Safety plan and Safety Case................................................................... 7

2. Context of the assessment – Scope of system being changed .................... 8

2.1 Description of current situation ...................................................................... 8

2.1.1 Operational environment ......................................................................... 8

2.1.2 People/Human resources........................................................................ 8

2.1.3 Procedures.............................................................................................. 9

2.1.4 Equipment ............................................................................................... 9

2.1.5 Documentation ........................................................................................ 9

2.1.6 Detailed information .............................................................................. 10

2.2 Overview of changes ................................................................................... 10

2.3 Functional breakdown of the planned changes ........................................... 11

2.4 Transitions of the planned changes ............................................................. 20

2.5 System Description ...................................................................................... 21

2.5.1 People Elements ................................................................................... 21

2.5.2 Procedure element ................................................................................ 22

2.5.3 Equipment elements ............................................................................. 22

2.5.4 System Operational Environment ......................................................... 22

3. Regulatory and Safety Management framework ........................................... 23

3.1 Regulatory requirements ............................................................................. 23

3.2 ANSP Safety Management System requirements ....................................... 23

3.3 Risk acceptance criteria .............................................................................. 23

3.3.1 Severity Classification Scheme ............................................................. 23

3.3.2 Risk Classification Scheme ................................................................... 25

3.3.3 Safety Objective Classification Scheme ................................................ 26

4. Safety Assessment Approach ........................................................................ 26

4.1 Overall safety assurance process description ............................................. 28

4.2 Safety case .................................................................................................. 30

4.2.1 Purpose................................................................................................. 30

4.2.2 Method .................................................................................................. 30

4.2.3 Safety Case Lifecycle ........................................................................... 31

5. Safety assessment processes - Inputs, Activities, Methods and Outputs . 31

5.1 System lifecycle processes and safety assessment processes ................... 32

5.2 feasibility study phase ................................................................................. 32

5.2.1 Input ...................................................................................................... 32

5.2.2 Hazard identification ............................................................................. 33

5.2.3 Analysis of hazard – causes, consequences and barriers .................... 33

5.2.4 Determining the severity of the effect and severity classification .......... 34

5.2.5 Creation of safety objectives ................................................................. 34

5.2.6 Output ................................................................................................... 34

5.2.7 Validation .............................................................................................. 34

5.3 Hazard analysis for establishing the NEFAB ............................................... 35

5.4 design phase ............................................................................................... 35


of 44

5.4.1 Input ...................................................................................................... 35

5.4.2 Derivation of safety requirements ......................................................... 36

5.4.3 Output ................................................................................................... 36

5.4.4 Validation .............................................................................................. 36

5.5 implementation phase ................................................................................. 37

5.5.1 Input ...................................................................................................... 37

5.5.2 Verification ............................................................................................ 37

5.5.3 Output ................................................................................................... 37

5.5.4 Validation .............................................................................................. 38

6. Assessments, Resource and Schedule Allocation....................................... 38

6.1 risk assessment and responsibility .............................................................. 38

6.2 Document plan ............................................................................................ 38

7. Document references ...................................................................................... 39

7.1 Applicable Standards ................................................................................... 39

8. APPENDICES ................................................................................................... 40

Appendix A Abbreviations & Acronyms ......................................................... 40

Appendix B Definitions ..................................................................................... 41


of 44

1. INTRODUCTION

The objective for the North European FAB project, is to deliver services tailored to customer requirements, contribute to increased flight efficiency, higher safety levels, a greener environment and cost reductions through an optimised use of air navigation infrastructure and harmonised services in Norway, Finland, Estonia, and Latvia.

This overall objective will be achieved through the establishment of a Functional Airspace Block (FAB) in combination with extended cooperation between the participating Air Navigation Service Providers (ANSP) on all levels.

NEFAB Safety team will deliver a safety assurance process for the NEFAB project by producing documentation containing sufficient evidence and arguments to demonstrate the safe operation of the all ANSPs within NEFAB from the date of declaration (2012), enabling the States to declare the FAB in accordance with the requirements laid down in SES regulations.

The NEFAB Safety Plan contains the minimum requirements for risk management of NEFAB and serves as reference for the detailed safety work that is needed for safety assurance of NEFAB. The NEFAB Safety documentation consists of:

• Safety Plan for the establishment and implementation of NEFAB (this document)

• Safety Case for the implementation of NEFAB (based on the safety plan)

• Safety Assessment – identified safety objectives, defined safety requirements

• Safety Assurance - arguments, evidence and assumptions to support the objectives and requirements

Definitions for safety documentation

Safety Plan - is a detailed way to show the activities which are necessary to provide safety assurance and how they are to be discharged. Safety plan identifies who undertakes these activities, the output from the activities, the criteria for success and the tools, techniques, methods or standards to be used. Safety Case - a structured argument, supported by a body of evidence that provides a compelling, comprehensible and valid case that a system is safe for a given application in a given operating environment. Safety Assessment - an evaluation based on engineering, operational judgement and/or analyses methods. Safety Assurance - all planned and systematic actions necessary to provide

adequate confidence that a product, a service, an organisation or a system achieves acceptable or tolerable safety.


of 44

The development and content of this Safety Plan is dependent on input from different project tracks and NEFAB CEO decisions.

Safety Plan will be reviewed and updated on regular basis.

1.1 PURPOSE

The purpose of this Safety Plan is to detail the activities which are necessary to provide a safety assurance process and support for the NEFAB project. The Safety Plan identifies the individuals that will be responsible to undertake these activities, the outputs from the activities and the criteria for the tools, techniques, methods or standards to be used.

1.2 SCOPE OF THE PLAN

This Safety Plan covers all life cycle phases from evaluation and safety assessment of different scenarios to the implementation of a North European FAB and its corresponding Air Navigation Services. The plan covers activities to be jointly performed by the involved ANSPs and includes both human, procedure and equipment elements. The safety plan is limited to activities within the NEFAB project. Local changes are to be performed according to local Safety Management Systems.

1.3 ROLES AND RESPONSIBILITIES

This section describes the different roles and responsibilities in the NEFAB project. The purpose of the description is to clarify the link between different responsibilities in the project organisation and the responsibility to carry out and document tasks described in this safety plan. The exemption is tasks identified as being the responsibility of line managers in one or more ANS provider organisations in accordance with the NEFAB safety assurance process.

1.3.1 Project

The figure below illustrates the governance of the NEFAB project:


of 44

Figure 1-1 NEFAB Project

NEFAB ANSP CEO Board - Project Governance, HL and Project scope governance; NEFAB Programme Management board - Project governance and guidance, ANSP and Project support, support in mobilisation of activities, coordinate activities between NEFAB and ANSPs, support the project with resources; NEFAB Programme Management Office - managing the project, mobilising and executing activities, Transversal activities (finances, resources, Safety, Communication, Reporting); Support function committees - Communication activity planning, Communication coordination, Newsletters, Financial instructions, Budget and cost statements coordination and follow-up, Safety Case and Safety plan; Projects - Detailed planning of activities (initiatives), detailed development of initiatives for implementation and benefit realisation. The scope of the NEFAB project in terms of safety assessment activities is described through the NEFAB safety assurance process description.

1.3.2 Safety plan and Safety Case

The NEFAB Safety team is responsible for creating and updating the safety plan and the safety case, including the argument structure.


of 44

However, for the updating of the safety case, input is needed from all the other project tracks, and possibly the individual ANSP, as those are the ones who can provide the documentation needed to support safety claims and requirements.

2. CONTEXT OF THE ASSESSMENT – SCOPE OF SYSTEM BEING CHANGED

This section gives general overview of a change, including short description of current situation and description of the planned changes/scenarios.

2.1 DESCRIPTION OF CURRENT SITUATION

This sub-section gives short overview of current situation taking account: operational environment, people, procedures, equipment, and documentation.

2.1.1 Operational environment

Operational environment is managed by individual ANS providers in each state. The environment consists of:

- 5 individual FIR:s.(Finland, Tallinn, Norway, Bodo Oceanic and Riga FIR:s) - 6 individual ACC:s.(Tampere, Tallinn, Oslo, Bodo, Stavanger, and Riga)

More details can be found in Appendix 01 to the Feasibility Study Report: Operational Concept. [ref Error! Reference source not found.].

2.1.2 People/Human resources

Human resources are managed by individual ANS providers. EC Regulation Nr.805/2011 and ICAO Annex 1 determine the requirements for the ATCO licensing for all NEAP providers. Requirements concerning language skills are presented in ICAO Doc 9385 AN/453/2004. ESARR 5 determines the safety regulatory requirements for ATM services personnel. However there are no harmonised, explicit or precise regulatory mandatory requirements concerning ATS manpower planning or ATS personnel working hours between the NEAP states. There is no centralized or combined manpower planning between the providers. ANS technical personnel and competence issues are managed at local level by each provider. There are currently no harmonised or precise mandatory requirements concerning the ANS technical personnel competence or licensing. There is no centralized or combined manpower planning between the providers.


of 44

2.1.3 Procedures

ATM- procedures, capacity enhancement as well as the planning is generally managed by the individual ANS providers. However a close cooperation is done between the states regularly. The procedural issues are generally in line with the ICAO and Eurocontrol regulations and there are no essential differences in this area concerning issues such as separation standards or communicational issues. However some operational differences may appear due to technical differences such as radar separation minima. Co-operational procedures between the providers are usually published as bilateral agreements between two or more ATS-units.

2.1.4 Equipment

ANS-equipment is generally managed by individual ANS providers. Some harmonisation is seen but there are differences between the different providers related to NAV, COM as well as the SUR equipment. The main functional features and characteristics remain quite similar even if there are different system manufacturers. The primary ATM systems are:

• Thales/Eurocat: Finland, Estonia

• ATRAC+: Latvia

• NATCON System, based on Raytheon Autotrac: Norway Regulation (EC) 552/2004 (on the Interoperability of the European Air Traffic Management Network) aims to1

1. achieve interoperability between the different systems, constituents and associated procedures in the European ATM network by establishing a harmonised system for certification of components and systems and;

2. ensure the introduction of new agreed and validated concepts of operations and technology in air traffic management.

Compliance with the interoperability requirements shall allow systems from different manufacturers to operate together in a seamless manner. More details can be found in the Initiative Working Papers no. 8, 9, 10, 11 and 12 in the NEFAB Feasibility Study.

2.1.5 Documentation

Documentation is managed by individual providers depending on the legislative and company internal requirements. Therefore there are differences between the providers even though the SMS requirements concerning documentation among the providers are quite similar in general.

1 This is explanatory text from EC 552/2004.


of 44

2.1.6 Detailed information

In order to find more detailed information of the current situation see, Initiative Working Papers 1 – 13 attached to the NEFAB Feasibility Study.

2.2 OVERVIEW OF CHANGES

The NEFAB project is expected to result in changes to most areas of the business of the NEFAB member ANSP´s. In this sense the delivery of operational services is considered as the core business. In addition there is a whole range of supporting services and activities that are expected to undergo changes in order to enable the benefits to be delivered to the ANSP´s and their customers. Changes in business model and financial arrangements are considered likely and changes in company structures could also be possible. All changes do however have in common that they will be implemented in an evolutionary manner and in logical steps towards a common long term strategic vision for the entire FAB. Within the domain of ATS provision, it is foreseen that the initial changes will consist of realignment of routes and subsequent reorganisation of airspace volumes. The main focus for this initial stage will be areas where changes are considered to be most beneficial in terms of efficient service provision and/or flight efficiency. Changes in routes, sectorisation and subsequent areas of responsibility for ATS-units will require system changes, changes to operational procedures and require training activities for the involved staff to take place. The European ATM Master Plan Implementation Package 1 will result in changes in service provision together with technological and procedural changes to support this. New communication, navigation and surveillance services will be introduced based on technologies like datalink, satellite navigation, DME-DME, ADS-B and Wide Area Multilateration. Within the ATM systems domain more advanced system coordination functions are expected as well as enhanced safety nets and improved decision support tools for controllers. ATS service provision is expected to move towards more advanced concepts of operation towards 2020 involving dynamic and flexible allocation of airspace volumes between different ATS units depending on the traffic demand and the time of day and day of the week. Such concepts will require substantial changes in the existing ATM systems, operational procedures and training programmes for staff. Changes in business model and financial arrangements within NEFAB are difficult to describe in detail at this stage. Reorganisation of the business is expected to take place either for parts of the ANS-organisation like specific support functions or for entire ANS-organisation in scenarios where joint ventures or mergers may be discussed in the longer term.


of 44

2.3 FUNCTIONAL BREAKDOWN OF THE PLANNED CHANGES2

Initiative -01 – ATS ROUTES AND SECTORISATION

Change ID3 High-level description of change Initiative

201/2.0/110201/6.7.1 Changes in ATC sectorisation – 2015 vision ATS routes and sectorisation

201/2.0/110201/9.1.1 Enhance the fixed ATS – route network where required

ATS routes and sectorisation

201/2.0/110201/9.1.2 Migrate from fixed ATS – route network to free route application where possible


201/2.0/110201/9.2.1 Establish NEFAB Free Route Airspace ATS routes and sectorisation

201/2.0/110201/9.3.1 Reducing airspace classifications to two classes ATS routes and sectorisation

201/2.0/110201/9.3.2 Removal of Division Flight Level between Upper and Lower airspace


201/2.0/110201/9.5.1 Establish FUA structures allowing for increased flexibility in ASM


Change ID High-level description of change Initiative

201/2.0/110201/9.6.1 Establish FUA structures allowing for ASM in Free Route Airspace


Initiative 03 – Optimisation of ATS


203/2.0/110201/ 9.1.1.1 ATS provision in static cross-border sector scenario Optimisation of ATS

203/2.0/110201/ 9.1.1.2 ATS through data link Optimisation of ATS

203/2.0/110201/9.1.1.3 ATS in common FUA-environment Optimisation of ATS

203/2.0/110201/9.1.1.4 Implementation of CDM processes Optimisation of ATS

203/2.0/110201/9.1.1.5 AMAN/DMAN enhancements Optimisation of ATS

Initiative 04 – Optimisation of ASM and ATFCM


204/2.0/110201/9.1.1.1 Establish FAB – wide ASM/ATFCM CDM – processes on strategic level

Optimisation of ASM and ATFCM

204/2.0/110201/9.1.1.2 NEFAB – wide coordinating function established to incorporate national plans into NEFAB network plan


2 Changes where implementation is planned after 2015 are not considered at this stage

3 Contains Initiative -no, Initiative version no. and date of issue.+ change no. in the Initiative according to table.


of 44

204/2.0/110201/9.1.1.3 Cross border area implementation principles adopted Optimisation of ASM and ATFCM

204/2.0/110201/9.1.1.4 Modular training area management Optimisation of ASM and ATFCM

204/2.0/110201/9.1.1.5 Operational AMC units managing pre-tactical and tactical ASM nationally on all ASM levels.


204/2.0/110201/9.1.1.6 Harmonized management of danger and restricted areas


204/2.0/110201/9.1.1.7 ASM/ATFCM procedures in Free Route airspace developed


204/2.0/110201/9.1.1.8 Common Key Performance Indicators applied: Optimisation of ASM and ATFCM

204/2.0/110102/9.1.1.9 Uniform application of cross-border CDR routes outside the Free Route airspace in NEFAB airspace


204/2.0/110102/9.1.1.10 Common ASM tools implemented Optimisation of ASM and ATFCM


of 44

Initiative 05 – Optimisation of ancillary services


205/2.0/110201/9.1.1 A detailed, agreed design of the common briefing functions including a business case.

Optimisation of ancillary services

205/2.0/110201/9.1.2 National adjustments as a consequence of the common briefing are designed, and necessary national decisions are taken


205/2.0/110201/9.1.3 Adaptations for systems, facilities and so on agreed. Optimisation of ancillary services

205/2.0/110201/9.1.4 Systems and facilities accepted and ready for going operational


205/2.0/110201/9.1.5 Plans for staff and retrenchment negotiated and agreed.


205/2.0/110201/9.1.6 Safety case approved (starts with systems adaptations, approved for implementation).


205/2.0/110201/9.1.7 Staff trained and in place for operation. Optimisation of ancillary services

205/2.0/110201/9.1.8 Common Briefing office implemented and operational Optimisation of ancillary services

205/2.0/110201/9.2.1 A detailed, agreed design for the common transition to AIM and consolidated AIS/AIM service provision, including a detailed business case.


205/2.0/110201/9.2.2 National adjustments as a consequence for the common transition to AIM and consolidated AIS/AIM service provision


205/2.0/110201/9.2.3 A detailed, agreed design for AIS/AIM systems and facilities adaptation to provide consolidated AIS/AIM service.


205/2.0/110201/9.2.4 Systems and facilities adaptation and improvement approval


205/2.0/110201/9.2.5 Systems and facilities modernisation. Optimisation of ancillary services

205/2.0/110201/9.2.6 Plans for staff and retrenchment negotiated and agreed.


205/2.0/110201/9.2.7 Staff trained and in place for operation. Optimisation of ancillary services

205/2.0/110201/9.2.8 NSA Approval (as the ANSPs do not own the question)



of 44

205/2.0/110201/9.2.9 Common AIS/AIM service provision Optimisation of ancillary services


of 44


205/2.0/110201/9.3.1 A detailed, agreed specification for the procurement of MET products from one MET provider including a business case.


205/2.0/110201/9.3.2 National adjustments as a consequence of the common MET provider and necessary national decisions are taken.


205/2.0/110201/9.3.3 Adaptations for systems, facilities and so on agreed. Optimisation of ancillary services

205/2.0/110201/9.3.4 The contractor prepared, systems and facilities accepted and ready for going operational.


205/2.0/110201/9.3.5 The new common MET service is operational. Optimisation of ancillary services

Initiative 06 – Harmonisation of operational rules and procedures


206/2.0/110201/9.2.1 All handbooks, manuals etc. written in English Harmonisation of operational rules and procedures

206/2.0/110201/9.2.2 Coordinated operational rules and procedures at the interface of different units, taking into account any requirements set forth by the implementation of cross border sectors

Harmonisation of operational rules and procedures

206/2.0/110201/9.2.3 Coordination and other operational interface procedures are uniform and transparent above Flight Level 195, whether working sector to sector within a unit or in cooperation with an adjacent unit


206/2.0/110201/9.2.4 Harmonised operational rules and procedures at the interface of different units, taking into account any requirements set forth by the implementation of cross-border sectors.


206/2.0/110201/9.2.5 Harmonised operational procedures for handling OAT and GAT. OAT and GAT flight plans in continental NEFAB airspace are harmonised


206/2.0/110201/9.2.6 Publication of the operational rules and procedures in AIPs, AICs and other public documents are harmonised and supplemented by local adaptations where required


206/2.0/110201/9.2.7 Operational rules, procedures and handbooks are common for the whole area, and supplemented with local adaptations where required


206/2.0/110201/9.2.8 Rules and procedures are produced by a common physically centralised unit. This unit is responsible for inter-FAB LoAs (harmonisation of rules and procedures).



of 44

Initiative 07 – Optimisation of training services


207/2.0/110201/9.1.1.1 Common ab initio training based on Eurocontrol Common Core Content and ESARR5.

Optimisation of training services

207/2.0/110201/9.1.1.2 Coordination of ANSP specific basic training Optimisation of training services

207/2.0/110201/9.1.1.3 Coordination of NEFAB-wide development training for operational staff


207/2.0/110201/9.1.1.4 Common procurement procedures to support procurement of ab initio training are set


207/2.0/110201/9.1.1.5 Joint procurement of ab initio training based on coordinated training schedules


207/2.0/110201/9.1.1.6 Initial training is performed in English Optimisation of training services

207/2.0/110201/9.1.1.7 Teachers / instructors are increasingly shared across NEFAB for improvement of training quality


207/2.0/110201/9.1.1.8 Common function for developing NEFAB training requirements and procedures


207/2.0/110201/9.1.1.9 Coordinated training requirements Optimisation of training services

207/2.0/110201/9.1.2.5 Common (virtual) unit for developing NEFAB training procedures and requirements is established and “operational”.


Initiative 08 – Supervision and monitoring of CNS infrastructure


208/2.0/110201/9.1 Common Incident Management procedures Supervision and monitoring of CNS infrastructure

208/2.0/110201/9.2 Cross border VNC/remote Desktop Supervision and monitoring of CNS infrastructure

208/2.0/110201/9.3 SNMP Planning and implementation activities on central system level

Supervision and monitoring of CNS infrastructure

208/2.0/110201/9.5 Geographical location selected Supervision and monitoring of CNS infrastructure


of 44

208/2.0/110201/9.6 Procurement of central Service Desk System Supervision and monitoring of CNS infrastructure


of 44


208/2.0/110201/9.7 Installation work on new location Supervision and monitoring of CNS infrastructure

208/2.0/110201/9.8 8. Implementation and Transition of VNC/Remote desktop applications

Supervision and monitoring of CNS infrastructure

Initiative 09 – Commonality of CNS and ATM systems


209/2.0/110201/9.1 NEFAB guidelines for use of common CNS infrastructure (Part of above mentioned plan)

Commonality of CNS and ATM systems

209/2.0/110201/9.2 GAP analysis: Operational requirements compared to existing infrastructure


209/2.0/110201/9.3 Identify potential areas for common use of existing CNS infrastructure


209/2.0/110201/9.4 Identify and prioritise potential areas for commonality of future CNS/ATM systems


209/2.0/110201/9.5 Establishment of TECH Group Commonality of CNS and ATM systems

209/2.0/110201/9.6 Maintenance Project established to support new airspace design and static re-sectorisation, using current system functionality.


209/2.0/110201/9.7 Project established to support Dynamic Cross-border Design focusing on central system procurement and advanced CDM and Safety-net support


Initiative 10 – Joint evaluation of technology within CNS and ATM


210/2.0/110201/9.1 Plan for cooperation on evaluation of technology Joint evaluation of technology within CNS and ATM

210/2.0/110201/9.2 Evaluation of technology to support operational changes related to the NEFAB 2015 scenario

Joint evaluation of technology within CNS and ATM

210/2.0/110201/9.3 NETECH quick wins progress aligned with NEFAB



of 44

210/2.0/110201/9.4 Sharing of existing and new evaluation reports made by individual ANSP’s



of 44

Initiative 11 – Common System Maintenance


211/2.0/110201/9.1 List showing which systems within NEFAB already are commonly used

Common System Maintenance

211/2.0/110201/9.2 A standard set of requirements regarding training and certification to be able to work with safety related equipment within NEFAB. Needs NSA coordination.


211/2.0/110201/9.3 Common spare part depot for each common system Common System Maintenance

211/2.0/110201/9.4 Coordination of common modifications Common System Maintenance

211/2.0/110201/9.5 Harmonisation of maintenance processes according to Best Practice.


211/2.0/110201/9.5 Specialist teams establishment Common System Maintenance

Initiative 12 – Joint Procurement


212/2.0/110201/9.1 Working out initiative details, promotion to senior management.

Joint Procurement

212/2.0/110201/9.2 Approval of the initiative , Go decision and guidelines from management

Joint Procurement

212/2.0/110201/9.3 Setting up Common Procurement Steering Group or dedicated task force

Joint Procurement

212/2.0/110201/9.4 Issuing NEAP common procurement guideline and procedures

Joint Procurement

212/2.0/110201/9.5 Inventory of systems/services, finding quick and short term candidates

Joint Procurement

2.4 TRANSITIONS OF THE PLANNED CHANGES

After the feasibility study is completed (2011), the project will move into a design and implementation phase where actions are prioritised and carefully planned. Implementation activities will take place after the planned declaration of NEFAB after end of 2012, although the establishment of governance structures and steering mechanisms must be completed before the declaration.


of 44

A further development of NEFAB will take place as the FAB will work according to a determined development plan. Through this development plan, further implementation activities will be described and prioritised within the areas of interest that are pointed out in the feasibility study. Other areas of change may also be identified through the work with the development plan, leading to a complete roadmap for the development of NEFAB. This section of the NEFAB Safety Plan will subsequently be updated as the changes are ready for implementation, either in accordance with the descriptions in the Initiative Working Paper or as amended through the NEFAB Development Plan.

2.5 SYSTEM DESCRIPTION

The NEFAB Air Navigation System is the combination of various people, procedures and equipment elements as illustrated in the figure below.

2.5.1 People Elements

The people element generally addresses:

• training process, e.g. manuals, simulations, competency and performance checking,

• licensing process

• staffing levels, rostering, call-out arrangements and specific skills/qualifications.

AIR NAVIGATION SYSTEM(CNS/ATM FUNCTION)

SYSTEM

OPERATIONAL

ENVIRONMENTPeople

Elements

Maintenance Personnel

Engineering Personnel

Operational Personnel

Maintenance Procedures

Operational Procedures

Procedure

Elements

Airspace Sectorisation

Equipment

Elements

Man Machine Interface

Hardware

Software

Figure 2-1 Generic System Description


of 44

Included in the people element are operational, maintenance and engineering personnel. Also HMI issues belong to this element although requirements concern the equipment element. In this section the specific conditions for NEFAB and selected scenarios will be described with regard to the human element.

2.5.2 Procedure element

The procedure element generally addresses:

• procedure design with constraints and recommendations, e.g. recovery actions and fall-back procedures

• procedure development and verification and validation. Included in the procedure element are operational and maintenance procedures as well as airspace sectorisation. In this section the specific conditions for NEFAB and selected scenarios will be described with regard to the procedure element.

2.5.3 Equipment elements

The equipment element generally addresses

• system or component architecture with constraints and recommendations, e.g. protection, detection, recovery, degraded modes,

• operational contingencies, e.g. operational limitations, preventive and corrective maintenance.

This section will also include:

• A short description of the technical equipment of NEFAB, • A comprehensive description of the system solution together with its

constituent parts,

• interfaces to other systems,

• necessary hardware and software.

2.5.4 System Operational Environment

This section will describe the system operational environment within which NEFAB will operate. The system operational environment includes all characteristics which may be relevant when assessing the safety impact of the system change. The description will include characteristics such as:

• Current ATM/CNS capabilities

• Airspace Characteristics

• Traffic Characteristics

• Aircraft Performance and Equipment

• Adjacent Centre Capabilities

• Airport Infrastructure


of 44

• Weather

• Topography

• Environmental Constraints

3. REGULATORY AND SAFETY MANAGEMENT FRAMEWORK

This chapter describes the Regulatory and Safety Management framework. The framework is based on the following references:

— ICAO regulations — EC regulations — Local regulation

3.1 REGULATORY REQUIREMENTS

All the regulatory requirements aspects are covered by NEFAB Foundation report, App D, “ICAO legal and regulatory report”. Besides ICAO and EC regulatory requirements, there may be local regulations, which can affect development of safety arguments for the provision of an acceptable level of safety.

3.2 ANSP SAFETY MANAGEMENT SYSTEM REQUIREMENTS

As a result of the mapping of SMS´s against Common Requirements, it was concluded that the existing SMS´s have differences. All the CR elements were divided into 3 different categories (not relevant, might be relevant, relevant) in order to evaluate if the difference of a certain element is relevant for the safety assessment track at this stage or not. It is also stressed that compliance with common requirements is essential for the planning and for the feasibility study stage of the project safety assessment track. To enable this, we agree upon common processes and criteria to use. If the project moves to the implementation phase, common requirements will be complied with at the local level.

3.3 RISK ACCEPTANCE CRITERIA

There are differences detected concerning Risk Acceptance Criteria. There will be an agreement in place on common Risk Acceptance Criteria before the NEFAB project move from the feasibility study phase to design and implementation phase.

3.3.1 Severity Classification Scheme

Severity Classification Scheme from EC-1035/2011.


of 44

Table 3-1 Severity Classification Scheme

Note: The Severity Classification of effects is common to that in ESARR4, but the examples chosen in ESARR4 relate to a priori assessment. The lists of examples are by no means exhaustive.


of 44

3.3.2 Risk Classification Scheme

There are differences in the Risk classification schemes used by the different ANSPs in the NEFAB, therefore it has been agreed to use as a base, the RCS recommended in ED-125 for the scope of the NEFAB.

Safety Target

NEFAB Safety Target

NEFAB Ambition Factor

Max Safety Target

(/ flight hour)

ST1 10 1 E -09

ST2 10 1 E -06

ST3 10 1 E -05

ST4 10 1 E -03

ST5 n/a n/a Tabell 3-1 Risk Classification Scheme

Note that an additional ambition factor can be added to the current scheme, i.e. to support the SESAR goal of improving safety by a factor of 10. Any increase in ambition factor will however be subject to a managerial decision.


of 44

3.3.3 Safety Objective Classification Scheme

The NEFAB Safety Objective Classification Scheme will be derived according to ED-125 Fixed Prescriptive model. As 2006 is used as baseline for the NEFAB, the total volume of flight hours in 2006 for each ANSP will also be used as the baseline for deriving the SOCS. The most stringent airspace complexity amongst the ANSPs will be used for the entire FAB so that the more pessimistic safety objectives will be set. ANSP Airspace

complexity Rationale for complexity Traffic Volume

(flight hours in 2006)

EANS 3 medium traffic but lot of flight level

changes- around 75% of traffic

change the flight level

50000

LGS 2-3 60000

NAVIAIR 2? 210000 LFV 3-4 430000

ISAVIA 3-4 170000 FINAVIA 2 120000 AVINOR 2-3 Medium to high level of traffic

with a moderately complex mix of traffic and some flight level changes

310000

NEFAB 2 1.350.000

Table 3-2 - SOCS Input

As an example, based on the airspace complexity decided for the NEFAB and the total volume of traffic, the following SOCS has been derived, expressed as years between each hazard occurrence;

ACC Complexity

C1 C2 C3 C4

SO1 1481 741 148 74

SO2 4 2 0,37 0,07

SO3 0,19 0,11 0,07 0,02

SO4 0,02 0,01 0,004 0,002

Table 3-3 NEFAB SOCS

4. SAFETY ASSESSMENT APPROACH

Safety assessment approach is based of EUROCONTROL methodology and will cover all stages of NEFAB project. As soon as the actual scenarios are proposed, exact methodology will be selected for proper assessment to be made. A proposed safety assessment approach is outlined in section 5 to this document.


of 44

SAM is common acceptable means of compliance.

NEFAB induced change Safety Assessment

Process

FHA

SSA

PSSA

Safety AssuranceProject Lifecycle

Change Implementation

Operation / Maintenance

Harmonisation

Change Design

Change DefinitionHow safe does the

change need to be to achieve acceptable risk?

Is the proposed designfor the change able to

achieve acceptable risk?

Does the change achieve acceptable

risk?

Figure 4-1 - High level description of the link between project phases and safety assessment

activities.


of 44

4.1 OVERALL SAFETY ASSURANCE PROCESS DESCRIPTION

Figure 4-2 NEFAB Safety Assurance Process

The safety assurance process is a three stage approach to ensure that all essential parts of safety issues are assessed and handled in a proper time and content.


of 44

In order to achieve a realistic and feasible result it is necessary to identify that the work is proposed to be done in two main levels:

a) The project/concept level b) The local SMS level

The safety assurance process has three sequential phases:

1) Feasibility 2) Planning 3) Implementation

The most essential stages in the process description are: SMS mapping Identifying possible showstoppers and limitations and clarifying the assumptions the work will be based on. Identify the most essential SMS harmonisation needs for future (after 2012). Safety objectives

Determine the safety objectives to match common requirements. The objectives shall be defined by the NEFAB project. Scenarios

The scenarios stage will determine the amount of absolute (functional) changes to be assessed. (Note. 2012 may not include any). Local changes Local changes will be assessed by each providers own SMS safety assessment methodology. This is essential to ensure that the safety assurance process is able to reach the required depth and wideness for each provider.


of 44

4.2 SAFETY CASE

This section will give an overall description of the safety case to be developed. The safety case itself will be documented in separate documents. The Project safety case will be developed in accordance to the Eurocontrol Safety Case Development Manual (SCDM).

4.2.1 Purpose

The Safety Case is the documented assurance on the achievement and maintenance of safety within the NEFAB. The Safety Case is based on the means (set of safety arguments, associated rationales and evidences) by which those who are accountable for service provision or projects assure themselves that those services or projects are delivering and will continue to deliver, an acceptable level of safety. The Safety Case is not an alternative to carrying out a Safety Assessment; rather, it is a means of structuring and documenting a summary of the results of a Safety Assessment, and other activities (e.g. 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.

4.2.2 Method

The technical core of the GSC will be a structured Safety Argument. A Safety Argument is a hierarchical set of arguments and evidence supporting a claim that the proposed system is acceptably safe, as shown in outline below.

.

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

C001Operational concept

(SAM-FHA ch1-GM A)

Change_SGxy Implementationis acceptably safe

Arg 2Change_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 alegitimate 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

C002Subject to declared

Assumptions, Limitationsand 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


St 001


C001Operational concept

(SAM-FHA ch1-GM A)


Arg 2


Arg 2Change_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 alegitimate operational need

Cr001





AND


Cr001





AND



Arg 3


Arg 3

On-going Operation of Change_SGxy will be shown to be acceptably safe

Arg 4On-going Operation of Change_SGxy will be shown to be acceptably safe

Arg 4

Fig 2Fig 2 Fig 7Fig 7

St004


St004


St004


Fig 11Fig 11

St005


items 1 and 2

St005


items 1 and 2

St005


items 1 and 2

Fig 10Fig 10

St002


•item 1 (Args 1.1 & 1.2);

•Item 2 (Arg 1.3)

St002


•item 1 (Args 1.1 & 1.2);

•Item 2 (Arg 1.3)

St003





St003





St003





C002Subject to declared

Assumptions, Limitationsand outstanding Issues

Figure 4-3 – Generic safety argument structure


of 44

The Criteria define what is meant by ‘acceptably safe’ in the Claim, i.e. how safe is safe enough. The Justification explains why the change is being made – for example in terms of

safety, capacity, efficiency or environmental benefits. Assumptions set out high level, overarching dependencies on other systems that are outside the control of those proposing the change. More detailed assumptions, for example about data such as the range of temperatures and pressures encountered, or the validity of certain mathematical models, are often more conveniently shown within the specific Arguments to which they apply. Systems are only safe within certain contexts. The Argument therefore includes definition of the Context: The current operational environment in which the new system will be implemented. The Arguments supporting the Claim are developed (i.e. expanded into sub-arguments) to a point at which Evidence to substantiate them is available, or could

realistically be gathered, or where a gap is apparent.

4.2.3 Safety Case Lifecycle

The safety case will be a living document, also after the completion of the NEFAB project. This is to ensure the provision of sufficient evidence for the argument that the on-going services will be acceptably safe. The argument structure will be developed during the feasibility study phase of the project, along with parts of the evidence claiming for a acceptably safe concept and design. The criteria, justification, context and assumptions needs to be decided on in this phase. The evidence for safe implementation will continue into the implementation phase of the project along with the evidence for a safe migration into operations.

5. SAFETY ASSESSMENT PROCESSES - INPUTS, ACTIVITIES, METHODS AND OUTPUTS

This chapter describes the work processes of the safety assessment to be performed for the system elements subject to a change. These process descriptions are based on the following references:

— EC 1035/2011 — Eurocontrol Safety Assessment Methodology (SAM)

The following sections give a description of the safety assessment activities or processes to be conducted in each of the major project phases.


of 44

5.1 SYSTEM LIFECYCLE PROCESSES AND SAFETY ASSESSMENT PROCESSES

A system safety assessment process should follow the system [lifecycle] processes defined for the system development. One such staged development process is to divide into (up to operations):

— System definition/feasibility study phase — System design phase — System implementation & integration phase

To match such a system development model, the system safety assessment processes can be divided into the following stages (or processes):

— Determination of the safety objectives to be placed on the constituent part — The derivation of a risk mitigation strategy — Verification that all the identified safety objective and requirements have

been met In such a model, the outcomes from the system development processes form the basis for the safety assessment processes, and the outcome from the safety assessment processes will be used in the system processes.

5.2 FEASIBILITY STUDY PHASE

The determination of the safety objectives to be placed on the constituent parts of the system will be done in this project phase. From EC 1035/2011: The hazard identification, risk assessment and mitigation processes shall include: (a) a determination of the scope, boundaries and interfaces of the constituent part being considered, as well as the identification of the functions that the constituent part is to perform and the environment of operations in which it is intended to operate; (b) a determination of the safety objectives to be placed on the constituent part, incorporating:

— an identification of ATM-related credible hazards and failure conditions, together with their combined effects;

— an assessment of the effects they may have on the safety of aircraft, as well as an assessment of the severity of those effects;

— a determination of their tolerability, in terms of the hazard’s maximum probability of occurrence, derived from the severity and the maximum probability of the hazard’s effects.

The following steps will be performed on NEFAB level to ensure a common set of safety objectives for all member ANSPs:

5.2.1 Input

— System description, incl. scope, boundaries and interfaces and

identification of system function(s) (foundation report, initiative working papers)


of 44

— The operational concept (foundation reports) — The environment description (initiative working papers, section 4) — Work or Project description (initiative working papers)

5.2.2 Hazard identification

Hazards exist at several levels in the ATM service. In the context of Safety Objectives, only hazards at the ATM Service Provision level of an Air Traffic Service Unit (ATSU) are formally a hazard. Hazards at lower levels are causes of these Service Provision level hazards, and often identified as failures. However, identification of failures leading to the hazards is anyway necessary to record. During hazard identification, this clear distinction between causes and hazards is not important, and the term hazard may be used in a wider scope than “at the ATM Service Provision level”.

5.2.3 Analysis of hazard – causes, consequences and barriers

During, or after the identification of hazards, the individual hazards will be analysed with respect to causes, consequences and barriers. (fault tree analysis and event tree analysis) The objective of this activity is to gain an understanding, and document:

— how the hazard can be caused from lower level failures — What barriers are in place, or can be made in order to prevent the hazard

from occurring (barriers should be recorded as safety requirements) — What are the possible consequences of the hazard, what are the barriers in

place or that can be made in order to prevent the consequence occurring. (barriers should be recorded as safety requirements)

— How effective the barriers are, and what is the probability of the consequences occurring as a result of the hazard occurring.

S

F

S

F

S

FS

F

S

F

“FTA” “ETA”

“Pivotal”Event

S

F

S

FS

F

S

F

S

F

S

FS

F

S

F

Causes Consequences

HAZARD Effect A

Effect B

Effect C

Effect D

Pe4Pe4

Pe2Pe2Pe3Pe3

Pe1Pe1

Pe

SC4

SC2

SC3

SC1

ST2

ST3

ST1

ST4

RCS

SO = min (STm / Pen ), n = (1,….x) , x = different hazard effects m = (1,….5) 1, …5 are different severity classes

FTA: Fault Tree AnalysisETA: Event Tree AnalysisPe: Probability of EffectSC: Severity CategoryST: Safety TargetRCS: Risk Classification SchemeSO: Safety Objective

Safety Target:

Maximumacceptable

frequency of occurrence of

Effects

Figure 5-1 Bow-tie model


of 44

5.2.4 Determining the severity of the effect and severity classification

For each single hazard being identified at the boundary of the system under assessment, all effects of hazards should be identified, taking into account the effectiveness of possible defences (barriers) outside the system under assessment that could either prevent or not prevent the hazard to generate certain effect on operations, including aircraft operations. The severity classification shall rely on a specific argument demonstrating the most probable effect of hazards, under the worst case scenario. Classification will be based in the severity classification scheme of EC 1035/2011 shown in section 3.3.1.

5.2.5 Creation of safety objectives

The Worst Credible effect in the given environment of operation should determine the severity class leading to setting of the Safety Objective, based on a mix of historical data (if existing), expert judgement and quantitative analysis. It means that the probability of the hazard leading to certain effect (Pei,j) has been taken into account when deciding the Worst Credible severity of the hazard effect. (e.g. SAM-FHA GM D or other ESARR4 compliant schemes). The Safety Objective of a hazard is given by the Safety Objective Classification Scheme. Safety Objectives will be specified as follows: The frequency of [Hazard_Desc] (in [Operational_Environment_Desc]) shall be no greater than [Value]. The [Operational_Environment_Desc] is given to be the NEFAB and can be omitted from the SO specification. The [Value] will be taken from the SOCS as defined in 3.3.3. The Safety Objectives will be uniquely identified (SO-NEFAB-X) and traceable to its hazard.

5.2.6 Output

— A set of safety objectives — Documented analysis of the hazards — A set of assumptions

5.2.7 Validation

Validation of the report and its content, by applying the following steps:

- meeting minutes to be reviewed by the meeting participants and those from ANSPs not represented at the meeting;

- all comments and feedback will be answered and documented, and the meeting minutes updated accordingly.


of 44

This will ensure that the discussions and conclusions of the meeting are correct, and thus the foundation for the report itself is correct. The report will undergo a similar review by all ANSPs and any comments or feedback will be answered and documented, and the report updated accordingly. This will ensure that the content of the report document is correct.

5.3 HAZARD ANALYSIS FOR ESTABLISHING THE NEFAB

The process described over applies to specific changes to the ANS, but is deemed less suitable for an organisational change. Therefore a slightly different hazard assessment approach has been applied in order to derive safety objectives for creation of the NEFAB. It follows the same principles as described above, but with the following changes;

- hazards effects not determined - no severity classification is done - purely qualitative safety objectives

This is due to the fact that establishing the NEFAB in itself does not necessarily mean that there will be changes to operations. This will lead to the identifcation of high level hazards and safety objectives on organisational level, rather than operational hazards.

5.4 DESIGN PHASE

The derivation of a risk mitigation strategy will be done in this project phase. From EC1035/2011: (c) the derivation, as appropriate, of a risk mitigation strategy which:

— specifies the defences to be implemented to protect against the risk-bearing hazards,

— includes, as necessary, the development of safety requirements potentially bearing on the constituent part under consideration, or other parts of the ATM functional system, or environment of operations, and presents an assurance of its feasibility and effectiveness;

The derivation of safety requirements will be performed individually by each ANSP or by two or more ANSPs in co-operation where appropriate.

5.4.1 Input

— Design documentation — A set of safety objectives and assumptions — High level function of the system

(EUROCONTROL SAM – PSSA: “The essential pre-requisite for conducting a PSSA is a description of the high level functions of the system, with a list of assumptions, hazards and their associated safety objectives.”)


of 44

5.4.2 Derivation of safety requirements

Derivation of safety requirements depend on the object being assessed, and the design methodology and thus also utilise different analysis tools and techniques like i.e. Fault Tree Analysis, Event Tree Analysis, FMEA. Which tools and techniques to be used for deriving safety requirements will be decided by the respective ANSP SMS. Safety requirements will be in the form of:

— Basic Safety requirements; safety related requirements to be met by the system as a "product" and;

— Assurance Safety requirements; those safety related actions to be performed through the processes associated to that product.

Basic Safety requirements can be a variety of requirements on people, procedure or technical elements. Examples are equipment MTBF requirements from fault tree analysis of the system functional architecture. Assurance Safety requirements are in the form of development assurance levels such as SWAL (software), PAL (procedure), or HAL (human). For software based equipment the SWAL allocation specifies the minimum requirement for the software engineering processes. Assurance Safety requirements may also be requirements to perform specific activities, especially if no Quality of Safety Assurance system are in place. All safety requirements shall be clear, unambiguous statements which are possible to verify to be met or not.

5.4.3 Output

— A set of safety requirements

5.4.4 Validation



- all comments and feedback will be answered and documented, and the meeting minutes updated accordingly.



of 44

5.5 IMPLEMENTATION PHASE

Verification that all the identified safety objective and requirements have been met will start in this project phase. From EC1035/2011: (d) verification that all identified safety objectives and safety requirements have been met:

— prior to its implementation of the change, — during any transition phase into operational service, — during its operational life and — during any transition phase until decommissioning.

The following steps will be performed by each ANSP individually and gathered in the overall safety case for consistency and to provide assurance that all ANSPs are able to achieve acceptable level of safety for the changes affecting them. Verification of the safety objectives and safety requirements during the system operational life will be done by the respective ANSPs locally.

5.5.1 Input

A set of:

— safety objectives — safety requirements — complete design documentation

5.5.2 Verification

Verification of all identified safety objectives and safety requirements will be performed at appropriate time and by using a method suitable for the element it relates to. This verification process can be performed integrated with the verification activities for that element. Often it will be appropriate to divide the verification into several verification activities and documentation according to the safety requirement type. Prior to declaration of readiness to transition operational service from one system state to a new system state, it shall be verified that all SO and SR have been verified. When the system is in operational use, incident reporting shall be traced to the safety objectives or safety requirement established for the NEFAB. As all verification activities will be performed by each ANSP locally, the methodology described in their respective SMSs will be used, and thus not described in detail in this section.

5.5.3 Output

— Verification records


of 44

5.5.4 Validation



- all comments and feedback will be answered and documented, and the meeting minutes updated accordingly


6. ASSESSMENTS, RESOURCE AND SCHEDULE ALLOCATION

This section gives an overview of the planned safety activities in terms of which specific assessments are to be done, what amount of resources are need for them, the time schedule and the resulting report document.

6.1 RISK ASSESSMENT AND RESPONSIBILITY

The table and document plan below will be developed as the exact content of planned changes materialise. Each change will require separate risk assessments and such assessments will be included in the safety case document.

6.2 DOCUMENT PLAN

This section gives an overview of the different documents that will be produced based on the activities outlined in this Safety Plan. Doc ID Doc name Release date Responsibility Approval Hazard Identification

Report TBD NEFAB Safety team PM

NEFAB Safety Case Report

TBD NEFAB Safety team PM

Safety Requirements Report

TBD NEFAB Safety team PM

Table 6-1 Document plan


of 44

7. DOCUMENT REFERENCES

This section contains references to documents referred to and used as input in this safety plan.

7.1 APPLICABLE STANDARDS

1. ED-125 “Process for Specifying Risk Classification Scheme and Deriving Safety Objectives in ATM “in compliance” with ESARR4,”

2. COMMISSION REGULATION (EC) No 1035/2011 of 20 December 2005 laying down common requirements for the provision of air navigation services


of 44

8. APPENDICES

Appendix A Abbreviations & Acronyms

Abbreviation Definition ADS-B Automatic Dependant Surveillance, Mode B

ANS Air Navigation Service

ANSP Air Navigation Service Provider

ATCO Air Traffic Controller

ATM Air Traffic Managment

ATS Air Traffic Service

ATSU Air Traffic Service Unit

COM Communication

COOPANS COOPeration between ANS providers

CR Common Requirements (from EC 1035/2011)

CAA Civil Aviation Authority

DME Distance measuring equipment

EC European Comission

ESARR European Safety Regulatory Requirements

FAB Functional Airspace Block

FDPS Flight Data Processing System

FIR Flight Information Region

FMEA Failure Mode and Effect Analysis

HMI Human Machine Interface

ICAO International Civil Aviation Organization

LFV Luftfartsverket (Swedish ANSP)

NAV Navigation

NEAP North European ANS Providers

NECC North European Coordination Committee

NEFAB North European FAB

NESC North European Strategy Committee

NSA National Supervisory Authority

NUAC Nordic Upper Area Control Centre Project

RCS Risk Classification Scheme

RDPPS Radar Data Processing and Presentation System

SAM Safety Assessment Methodology

SES Single European Sky

SMS Safety Managment System

SO Safety Objective

SOCS Safety Objective Classification Scheme

SR Safety Requirement

SUR Surveillance


of 44

Appendix B Definitions

Term Definitions Source Ref Air Navigation Service A generic term describing the totality of

services provided in order to ensure the safety, regularity and efficiency of international air navigation and the appropriate functioning of the air navigation system.

Eurocontrol

Air Traffic Management (ATM) The aggregation of ground based (comprising variously ATS, ASM, ATFM) and airborne functions required to ensure the safe and efficient movement of aircraft during all appropriate phases of operations.

SRC Doc. 4

Air Traffic Services (ATS) A generic term meaning variously, flight information service, alerting service, air traffic advisory service, air traffic control service (area control service, approach control service or aerodrome control service).

SRC Doc. 4

Air Traffic Control (ATC) Service A service provided for the purpose of: preventing collisions: between aircraft and on the manoeuvring area between aircraft and obstructions and expediting and maintaining an orderly flow of air traffic.

SRC Doc. 4

ATM Service-Provider An organisation responsible and authorised to provide ATM service(s).

SRC Doc. 4

ATM System The human, procedural and equipment (hardware, software) elements of the ATM System as well as its environment of operations

ESARR 4

Hazard Any condition, event or circumstances which could induce an accident.

SRC Doc. 4

Hazard Any condition, event or circumstance happening at the ATM Service Provision level that can induce an incident or an accident. Note: This differs from ESARR4 because: - In the framework of this document,

hazards are defined only at the ATM Service Provision level;

A hazard may induce incident as well as accident.

ED-125

Hazard Identification The process of determining what can happen, why and how.

SRC Doc. 4

Incident An occurrence, other than an accident, associated with the operation of an aircraft, which affects or could affect the safety of operation.

SRC Doc. 4


of 44

Term Definitions Source Ref Occurrences Accidents, serious incidents and incidents

as well as other defects or malfunctioning of an aircraft, its equipment and any element of the Air Navigation System which is used or intended to be used for the purpose or in connection with the operation of an aircraft or with the provision of an air traffic management service or navigational aid to an aircraft.

SRC Doc. 4

Target Level of Safety (or safety level or safety minima)

A level of how far safety is to be pursued in a given context, assessed with reference to an acceptable or tolerable risk.

ESARR 4

Mitigation or Risk Mitigation Steps taken to control or prevent a hazard from causing harm and reduce risk to a tolerable or acceptable level.

SRC Doc. 4

Risk The combination of the probability, or frequency of occurrence of a defined hazard and the magnitude of the consequences of the occurrence.

SRC Doc. 4

Risk Assessment Assessment to establish that the achieved or perceived risk is acceptable or tolerable.

SRC Doc. 4

Safety Assessment An evaluation based on engineering, operational judgement and/or analysis methods.

SRC Doc. 4

Safety Freedom from unacceptable risk of harm. SRC Doc. 4

Safety Achievement The result of processes and/or methods applied to attain acceptable or tolerable safety.

SRC Doc. 4

Safety Assurance All planned and systematic actions necessary to provide adequate confidence that a product, a service, an organisation or a system achieves acceptable or tolerable safety.

SRC Doc. 4

Safety Case a structured argument, supported by a body of evidence that provides a compelling, comprehensible and valid case that a system is safe for a given application in a given operating environment

Safety Objective A safety objective is a planned safety goal. The achievement of an objective may be demonstrated by appropriate means to be determined in agreement with the safety regulator. Note: a more specific application is to be found in ESARR 4 and is as follows: More specifically for this ESARR 4, a safety objective is a qualitative or quantitative statement that defines the maximum frequency or probability at which a hazard can be expected to occur.

SRC Doc. 4


of 44

Term Definitions Source Ref Safety Objective Quantitative statement that defines the

maximum frequency at which a hazard can be accepted to occur. Note: This differs from ESARR4 because: - In the framework of this document,

only “frequency” is used; - Guidance is provided only for

“quantitative” SO; An acceptable level risk has to be achieved as this document aims at setting SO for ATM Service Providers.

ED-125

Safety Plan A detailed way to show the activities which are necessary to provide safety assurance and how they are to be discharged. Safety plan identifies who undertakes these activities, the outputs from activities, the criteria for success and the tools, techniques, methods or standards to be used.

Safety Requirement A risk mitigation means, defined from the risk mitigation strategy that achieves a particular Safety Objective. Safety requirements may take various forms, including organisational, operational, procedural, functional, performance, and interoperability requirements or environment characteristics.

SRC Doc. 4

Severity Level of effect/consequences of hazards on the safety of flight operations (I.e., combining level of loss of separation and degree of ability to recover from the hazardous situation).

ESARR 4

System element A member of a set of elements that constitutes a system. NOTE A system element is a discrete part of a system that can be implemented to fulfill specified requirements.

ISO/IEC 15288:2002 Systems engineering, Systems lifecycle processes

Worst Credible Effect ‘Worst’ means the most unfavourable conditions – e.g. extremely high levels of traffic or extreme weather disruption. ‘Credible’ implies that it is not unreasonable to expect to experience this combination of extreme conditions within the operational lifetime of the system so that such scenario leading to generate such an effect has to be considered. The Worst Credible Effect aims at identifying the highest contribution of a hazard to the highest risk due to this hazard. See SAM FHA Chapter 3 GM D & G.

ED-125

Table 8-1 Definitions


of 44

LAST PAGE

nefab safety plan v3 -...

Documents