EAD Safety Case - Eurocontrol · CONTINUED SAFE OPERATION OF EAD (ARG 3) .....45 7.1 Objective ... the Critical Data Integrity Level. The EAD Safety Case sets out to show that EAD

EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

EAD Safety Case

CFMU/EAB

Edition : 2.3 Edition Date : September 2009 Status : Released Class : Restricted

DOCUMENT IDENTIFICATION SHEET

DOCUMENT DESCRIPTION

Document Title EAD Safety Case

EWP DELIVERABLE REFERENCE NUMBER

PROGRAMME REFERENCE INDEX EDITION : 2.3

EDITION DATE : September 2009

Abstract

This document presents the Safety Case for the European Aeronautical Information System Database (EAD). The EAD Safety Case sets out the evidence to support the claim that EAD contributes to the achievement of an acceptable level of safety for Aeronautical Information Service provision.

Keywords EAD AIS Safety Case Safety Assessment Aeronautical Data ICAO Annex 15

CONTACT PERSON : Nil Agacdiken TEL : 93073 UNIT : CFMU/EAB

DOCUMENT STATUS AND TYPE

STATUS CATEGORY CLASSIFICATION Working Draft � Executive Task � General Public � Draft � Specialist Task � EATMP � Proposed Issue � Lower Layer Task � Restricted � Released Issue � INTERNAL REFERENCE NAME :

EAD Safety Case CFMU/EAB

Edition: 2.3 Released Page iii

DOCUMENT APPROVAL

The following table identifies all management authorities that have successively approved the present issue of this document.

AUTHORITY NAME AND SIGNATURE DATE

EAD Safety Case Task Manager

N. Agacdiken

EAD Data Operations Safety

Manager

M. Segovia

EUROCONTROL DAP/SAF

G. Le Galo

Head of EAB

S. Wybo

CFMU Director

J. Dopagne

CFMU/EAB EAD Safety Case

Page iv Released Edition: 2.3

DOCUMENT CHANGE RECORD

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

EDITION DATE REASON FOR CHANGE SECTIONS

PAGES AFFECTED

0.1 March 2005 Initial Draft Issue All

0.2 May 2005 Updated Draft Issue for further review All

0.3 December 2005 Proposed Issue incorporating EUROCONTROL, EAD System Provider and EAD Service Provider review comments

All

1.0 March 2006 Released Issue All

1.1 December 2008 Updated draft issue All

1.2 April 2009 Significant update to incorporate new EAD safety argument

All

1.3 August 2009 Updated issue incorporating EUROCONTROL, Maastricht UAC, EAD IT Provider and EAD Data Operations review comments

All

2.2 September 2009 Version number aligned with CMDB referencing All

2.3 September 2009 Minor update following EUROCONTROL review

50


Edition: 2.3 Released Page v

TABLE OF CONTENTS

1. INTRODUCTION ......................................................................................................4

1.1 Background......................................... ...........................................................4

1.2 EAD Today .......................................... ...........................................................4

1.3 Aim ................................................ .................................................................4

1.4 Purpose ............................................ ..............................................................5

1.5 Scope.............................................. ................................................................5

1.6 Statutory and Regulatory Context ................... .............................................6

1.7 General Approach................................... .......................................................8

1.8 Structure .......................................... ..............................................................9

1.9 Glossary of Terms and References................... .........................................10

2. OVERALL CONTEXT FOR THE EAD SAFETY CASE............ ..............................11

2.1 Aeronautical Information Service Provision......... .....................................11

2.2 The Data Chain without EAD ......................... .............................................12

2.3 The Data Chain with EAD ............................ ................................................13

3. OVERVIEW OF EAD..............................................................................................15

3.1 EAD Oversight ...................................... .......................................................15

3.2 EAD Functionality.................................. ......................................................16

3.3 EAD IT Services .................................... .......................................................17

3.4 EAD Data Operations ................................ ..................................................18

3.5 Support Functions.................................. .....................................................19

3.6 Definition of EAD for the Safety Assessments....... ...................................19

3.7 Types of Aeronautical Data......................... ................................................21

4. OVERALL SAFETY ARGUMENT ............................ ..............................................23

4.1 Objective .......................................... ............................................................23

4.2 Principal Safety Argument (Arg 0).................. ............................................23

4.3 Decomposition of Arg 0 ............................. .................................................24

5. SPECIFICATION OF EAD SAFETY REQUIREMENTS (ARG 1) ... ........................26

5.1 Objective .......................................... ............................................................26

5.2 Strategy ........................................... .............................................................26

5.3 Scope and Definition of EAD (Arg 1.1) .............. .........................................27

5.4 Risk Assessment and Safety Requirements Derivation (Arg 1.2) ...........27

5.5 Internal and External Safety Requirements Allocatio n (Arg 1.3) ..............32

5.6 Safety Requirements Process is Trustworthy (Arg 1.4 )............................32

5.7 Conclusion for Arg 1 ............................... ....................................................33

6. SATISFACTION OF EAD SAFETY REQUIREMENTS (ARG 2) .... ........................34

6.1 Objective .......................................... ............................................................34


Page vi Released Edition: 2.3

6.2 Rationale for Arg 2................................ .......................................................34

6.3 Internal EAD Safety Requirements are satisfied (Arg 2.1) ........................35

6.4 External EAD Safety Requirements are satisfied (Arg 2.2).......................39

6.5 EAD Safety Performance Monitoring (Arg 2.3) ........ ..................................41

6.6 Satisfying the Safety Criteria ..................... .................................................42

6.7 Satisfaction of Regulatory Requirements (Arg 2.4).. .................................43

6.8 Conclusion for Arg 2 ............................... ....................................................44

7. CONTINUED SAFE OPERATION OF EAD (ARG 3) ............ .................................45

7.1 Objective .......................................... ............................................................45

7.2 Rationale for Arg 3................................ .......................................................45

7.3 Continued Safety Requirement Satisfaction (Arg 3.1) ..............................46

7.4 Migration of New EAD Users (Arg 3.2) ............... ........................................48

7.5 Transition Safety (Arg 3.3) ........................ ..................................................49

7.6 Processes for assuring changes to EAD are acceptabl y safe (Arg 3.4) ..49

7.7 Change Management Improvements (Arg 3.5) ........... ...............................51

7.8 Conclusions for Arg 3 .............................. ...................................................51

8. VALIDITY OF ARG 1 IN THE ONGOING OPERATION (ARG 4). ..........................53

8.1 Objective .......................................... ............................................................53

8.2 Strategy ........................................... .............................................................53

8.3 Impact of Changes on EAD Safety Requirements (Arg 4 .1)......................54

8.4 Updated EAD Safety Requirements satisfy Safety Crit eria (Arg 4.2) .......54

8.5 Updated EAD Safety Requirements Satisfaction (Arg 4 .3) .......................54

8.6 EAD Compliance with Regulation and Standards (Arg 4 .4)......................54

8.7 Conclusions for Arg 4 .............................. ...................................................55

9. CONCLUSIONS AND RECOMMENDATIONS.................... ...................................56

9.1 Summary ............................................ ..........................................................56

9.2 Conclusions........................................ .........................................................56

9.3 Caveats............................................ .............................................................57

9.4 Recommendations.................................... ...................................................59

APPENDIX A AERONAUTICAL DATA QUALITY REGULATION............... ...................61

APPENDIX B EAD SAFETY REQUIREMENTS............................ ..................................65

APPENDIX C EAD CHANGE PROCESS................................. .......................................74

APPENDIX D EAD FUNCTIONAL MODELS .............................. ....................................75

APPENDIX E GOAL STRUCTURED NOTATION (GSN)..................... ...........................79

APPENDIX F SINGLE EUROPEAN SKY SECURITY REQUIREMENTS .......... .............80

APPENDIX G GLOSSARY OF ABBREVIATIONS.......................... ................................84

APPENDIX H REFERENCES .........................................................................................86


Edition: 2.3 Released Page 1

EXECUTIVE SUMMARY

The concept of a European Aeronautical Information System (AIS) Database (EAD) was developed by EUROCONTROL and its Member States following a study in the early ‘90s, which revealed that the AIS operational structure suffered from several limitations and drawbacks when seen from a European perspective.

EAD came into service in June 2003 with a limited set of pilot users with plans to migrate other Data Users and Data Providers to EAD over a number of years, on 6 June 2008, the EAD service celebrated five years of operations. On 30 September 2008, 130 clients were participating in the EAD comprising 51 Data Providers and 79 Data Users, including EUROCONTROL Units.

This document presents the second version of the Safety Case for EAD. The previous EAD Safety Case demonstrated adequate assurance for maintaining a level of safety equivalent to data derived from non-EAD sources. The safety case also set limits on the Data Integrity Level that could be claimed for EAD sourced data equivalent to Routine or Essential as defined in ICAO Annex 15,

This updated EAD Safety Case is based on reworked safety assessments (Functional Hazard Assessment (FHA), Preliminary System Safety Assessment (PSSA) and System Safety Assessment (SSA)), which address the latest developments1 in the regulatory context for Aeronautical data provision as well as the Critical Data Integrity Level.

The EAD Safety Case sets out to show that EAD (Release 5) contributes to the achievement of an acceptable level of safety2 for Aeronautical Information Service provision. This claim is founded on the following four principal safety arguments:

• Baseline safety requirements are set for EAD that satisfy the defined safety criteria (Arg 1 )

• Baseline EAD IT system and Data Operations services currently satisfy the safety requirements set (Arg 2 )

• Measures are in place to ensure that the EAD baseline IT system and Data Operations services continue to satisfy the defined safety criteria (Arg 3 )

• Measures are in place to ensure that Arg 1 remains valid in the ongoing operation of EAD (Arg 4 ).

The evidence presented in this safety case substantiates the four principal safety arguments subject to the following constraints and limitations:

• EAD Migrated Data Providers and Data Users must use the EAD in accordance with the agreed Service Level Agreements (see EFSR-06, EFSR-13 & EFSR-21) and in particular taking note of the specific caveats presented herein (see Table 5)

1 In particular as part of the Aeronautical Data Quality Implementing Rule under the Single European Sky mandate. 2 An acceptable level of safety is defined as: AIS related risk shall be no higher when using EAD than exists when not using EAD (non-EAD); EAD satisfies all applicable regulatory requirements and risk is reduced As Far As Reasonably Practicable (AFARP).


Page 2 Released Edition: 2.3

• EAD Migrated Data Providers and Data Users must not place greater reliance on the integrity of any committed data item than as defined in ICAO Annex 15 [1] (see EFSR-20) or amended or otherwise notified by the State Aeronautical Information Service provider responsible for the data.

• EAD Migrated Data Providers retain responsibility in accordance with ICAO Annex 15 [8] for the completeness and correctness of data committed to EAD. In particular, migrated Data Providers must not rely on EAD to check the following:

o accuracy of aeronautical data

o contents of IAIP scanned to PAMS

o content of AIP or Charts created using the EAD IAP and Charts support tools.

The following limitations have been identified from the safety assessments undertaken for EAD.

Ref Limitation

L001 Loss of NOTAM data should be detected by sequence number checks, but for loss of PAMS no additional assurance for Critical data is provided

L002 Until training needs for the Data Quality Reviews of SDO approach and departure procedures has been finalised and all EAD DOP staff have received the appropriate training; Data Quality Reviews of SDO data shall only be performed by suitably qualified and competent personnel

L003 Aeronautical Data delivered via EAD Basic over the internet is not guaranteed to satisfy the associated integrity required by ICAO Annex 15

L004 ARINC data available via the EAD is only assured to Essential levels of integrity

Table 1 — EAD Limitations

The EAD Safety Case assumes the following:

• Data Providers and Data Users are responsible for assuring their overall processes in which EAD is used to achieve an acceptable level of safety

• Data Providers and Data Users comply with identified EAD external safety requirements

• The worst case consequence for data error would be that the continued safe flight and landing of an aircraft would be severely at risk with the potential for catastrophe; this is commensurate with the integrity definition of Critical data given in ICAO Annex 15 [1]

• Flight plan filing organisations using the EAD Briefing Facilities comply with the IFPL European Commission Mandate in accordance with the associated Community Specification or suitable alternative

• CFMU IFPS will send amendments to FPL originators when changes to the conditions of a FPL are required

• Member States subscribed to the EAD BF have an alternative means of submitting flight plan messages to CFMU IFPS



The evidence in support of the overall claim for EAD makes reference to assurance that the security of EAD is acceptably robust today given the threat that lack of security poses to the safety of the publication and distribution process, although the reader should note Safety Issue SI002 presented in section 9. The EAD Safety Case does not include the details of this assurance, for obvious security reasons, and does not consider issues that are purely related to security.



1. INTRODUCTION

1.1 Background

The concept of the European Aeronautical Information Service (AIS) Database (EAD) was developed by EUROCONTROL and its Member States following a study carried out in the early 1990’s which revealed that the AIS operational structure suffered from several limitations and drawbacks when seen from a European perspective, including:

• incoherence of cross-border aeronautical information

• inconsistent quality of data throughout the European Civil Aviation Convention (ECAC) area

• lack of interoperability between systems due to different data models and exchange formats

• shortcomings in ensuring timely distribution of aeronautical information updates to all stakeholders.

These issues compromised the safety and efficiency of air navigation and the duplicated processes and investments of the current operational structure caused high maintenance costs for all involved.

It was concluded that the cost effectiveness of AIS operations, the quality of aeronautical data and the accessibility and availability of such data could be significantly improved through automation and centralisation. This resulted in the development of a European AIS Database (EAD) intended to facilitate European wide maintenance and distribution of aeronautical information.

EAD came into service in June 2003 with a limited set of pilot users with plans to migrate other Data Users and Data Providers to EAD over a number of years. As part of the introduction of EAD into operational service, EUROCONTROL required the production of a Safety Case to demonstrate that the EAD can be operated in an acceptably safe manner.

1.2 EAD Today

The Central Flow Management Unit (CFMU) is a part of the EUROCONTROL Agency; it provides air traffic flow management services over the states of western and central Europe who are members of ECAC and makes available the EAD. Within the CFMU Directorate Organisation, the EAD and Aeronautical Information Bureau (EAB) is responsible for the EUROCONTROL EAD service and overall coherence of aeronautical information aspects within the CFMU.

On 6 June 2008, the EAD celebrated five years of operations. On 30 September 2008, 130 clients were participating in the EAD comprising 51 Data Providers and 79 Data Users, including EUROCONTROL Units.

1.3 Aim

The aim of the EAD Safety Case is to substantiate the EAD top level claim, the derivation of which is justified within this report. The top level claim is:



• EAD contributes to the achievement of an acceptable level of safety for Aeronautical Information Service provision. Where an acceptable level of safety is defined as:

o the AIS related risk shall be no higher when using EAD than exists when not using EAD

o EAD satisfies all applicable regulatory requirements, and

o the risk is reduced As Far As Reasonably Practicable (AFARP).

1.4 Purpose

This EAD Safety Case presents the safety arguments and supporting evidence to show how EAD contributes to the reduction in risks to safety posed by the publication and distribution of aeronautical information. It shows that risks are identified, mitigated and managed with respect to the increasing utilisation and ongoing operation of EAD. It also states the requirements set on the EAD clients to ensure that EAD is used correctly, and demonstrates that EUROCONTROL has taken all reasonable steps to ensure providers of data to EAD comply with all relevant regulations with respect to data committed to EAD.

The Safety Case summarises and presents the arguments and evidence for EAD based on the independent EAD Functional Hazard Assessment (FHA) [2], Preliminary System Safety Assessment (PSSA) Report [3] and the System Safety Assessment Report for EAD [4]. These documents provide greater detail on the arguments and evidence supporting this Safety Case.

1.5 Scope

The EAD Safety Case presents the detailed safety arguments and evidence for the baseline (Release 5) of the ongoing EAD IT Provider (ITP) and Data Operations (DOP) services.

EAD provides a support function to Aeronautical Data Providers and a centralised storage and distribution function to Aeronautical Data Users. EAD supports Data Providers in fulfilling their obligations under ICAO Annex 15 [1] for the publication and distribution of AIP, Charts, AIP Supplements, NOTAM, etc. It provides a basic World Wide Data Maintenance function to support the processing of NOTAM from non-migrated Data Providers.

EAD also provides functionality to compile, handle, validate and submit flight plans (FPL) to CFMU via the Briefing Facility. It also, as part of Release 5, makes available the Electronic Route Availability Document (eRAD) on behalf of CFMU.

Figure 1 below depicts the bounds of EAD responsibility and thus the scope of the EAD Safety Case.



Figure 1 – Scope of EAD Safety Case

EAD does not absolve State AIS of their responsibilities under ICAO Annex 15 [1] for the publication and distribution of Aeronautical Information. As such the EAD Safety Case provides the necessary arguments and evidence to support Data Providers and Data Users in developing safety cases for their areas of responsibility.

1.6 Statutory and Regulatory Context

1.6.1 Aeronautical Data/Information Quality

There is a wealth of regulatory documentation and standards in existence which to a greater or lesser extent apply to EAD. The principle regulations and standards are issued by the following bodies:

• EUROCONTROL

• European Commission (Single European Sky)

• ICAO

• ISO

Further detail on the regulation issued by the bodies listed above is provided in Appendix A; compliance statements against the requirements of regulation applicable to EAD are documented in the EAD Regulatory Requirements Compliance document [5].



1.6.2 Safety Regulatory Requirements

The regulatory context for EAD is captured within the EUROCONTROL Safety Regulatory Requirements (ESARRs). The ESARRs are applicable to all providers of ATM services in respect of those parts of the ATM System for which they have managerial control. The following ESARRs are specifically relevant to the development of the EAD Safety Case:

• ESARR 1: Safety Oversight in ATM [6] - provides a set of regulatory requirements for the implementation of an effective ATM safety oversight function in EUROCONTROL Member States. ESARR 1 is aimed primarily at National Supervisory Authorities (NSA) and is thus not directly applicable to EAD.

• ESARR 2: Reporting and Assessment of Safety Occurrences in ATM [7] - addresses the implementation by States of an Occurrence Reporting and Assessment Scheme for Air Traffic Management (ATM) Safety. ESARR2 applies to Air Navigation Service Providers (ANSP) in support of defining appropriate incident investigation processes and procedures. Whilst ESARR2 does not directly apply to EAD, EAD maintains a record of all relevant data transactions to support such incident investigations where necessary.

• ESARR 3: Use of Safety Management Systems (SMS) by ATM Service Providers [8] – the aeronautical data chain is not currently subject to regulation and thus is not mandated to implement an SMS. The EUROCONTROL CFMU Safety Policy [9] has been adopted by EAD and consideration has been given to the way in which the process for using EAD interacts with Data User and Data Provider processes; see section 7.

• ESARR 4: Risk Assessment and Mitigation in ATM [10] – this is central to the objectives of the Safety Case in terms of demonstrating that potential risks to safety are identified and appropriately mitigated.

• ESARR 5: ATM Services Personnel [11] - sets out the safety regulatory requirements for all ATM services’ personnel responsible for safety related tasks within the provision of ATM services across the ECAC area. This includes requirements for air traffic controllers as well as for engineering and technical personnel undertaking operational safety related tasks. ESARR5 does not currently define competencies for Aeronautical Information Services (AIS) and thus is not applicable to EAD at present.

• ESARR 6: Software in ATM Systems [12] – deals with the implementation of software safety assurance systems, which ensure that the risks associated with the use of software in safety related ground-based ATM systems, are reduced to a tolerable level. It is important to note that ESARR 6 does not prescribe any type of supporting means of compliance for software, as this is seen as the role of supporting software assurance standards

Compliance matrices for this safety case against the requirements of ESARR 3 [6] and ESARR 4 [10] are provided in [5]. ESARR 6 [12] has been used to set the objectives for software safety aspects within the System Safety Assessment Report for EAD [4].



1.6.3 Security Regulatory Requirements

All Air Navigation Service Providers including Aeronautical Information Services within any State under the Single European Sky (SES) framework must meet SES requirements in order to achieve certification.

Commission Regulation (EC) No 2096/2005 identifies common requirements for the provision of Air Navigation Services. This gives details on the security requirements for all Air Navigation Service Providers. These security requirements cover security management systems and the security of personnel, facilities and data [13].

EUROCONTROL has recently published a series of guidance documents to facilitate satisfaction of the SES security requirements as documented in [14], [15] and [16].

It will be necessary within this safety case to demonstrate that adequate technical and procedural preventative measures are in place in accordance within this regulation. However due to the maturity and continuing development of the SES security regulations and the recent (May 2008) publication of EUROCONTROL guidance on security, the assessment of the compliance of EAD security arrangements with the overarching regulation is on-going.

1.7 General Approach

The approach adopted herein is consistent with the general (qualitative) requirements of ESARR 4 [10], as shown in [5]. Specifically, the approach considers EAD as an ongoing operation and thus follows a Unit Safety Case template from the EUROCONTROL Safety Case Development Manual [17], rather than a System Safety Case template. However, as EAD is primarily a tool that provides a support function the safety argument considers the current operation of EAD and the process for making changes to EAD as follows:

• Defines appropriate EAD safety requirements to ensure that EAD satisfies all relevant regulatory requirements and does not undermine, and where practicable contributes to, improving the levels of safety achieved by Aeronautical Information Service Providers (AISPs). It achieves this by specifying requirements that must be met by:

o EAD – these are termed internal safety requirements;

o External actors or stakeholders (i.e. users of EAD) – these are termed external safety requirements;

• Demonstrates that EAD meets all internal safety requirements in its current configuration and will continue to do so in ongoing operations

• Ensures that all external safety requirements are incorporated into Service Level Agreements with EAD clients and verified prior to their migration to EAD

• Establishes that adequate processes are in place to ensure that all changes made to EAD in the future will be managed and implemented safely



• Determines that appropriate measures are in place to ensure that the EAD safety requirements remain valid in the ongoing operation of EAD cognisant of regulatory changes in the AIS framework.

1.8 Structure

This Safety Case Report is structured as follows:

Section 1 Introduction – presents an overview of the EAD Safety Case itself, its background, aim, purpose and scope.

Section 2 Overall Context for the EAD Safety Case – provides the overall context for the EAD Safety Case including a list of assumptions and scoping statements.

Section 3 Overview of EAD – provides a summarised overview and description of the EAD IT and EAD Data Operations.

Section 4 Overall Safety Argument – presents the top level safety argument and sub-arguments.

Section 5 Specification of EAD Safety Requirements (Arg 1) – shows how the EAD safety requirements have been developed from the safety analyses undertaken.

Section 6 Satisfaction of EAD Safety Requirements (Arg 2) – shows how EAD satisfies its safety requirements.

Section 7 Continued Safe Operation of EAD (Arg 3) – presents the evidence to demonstrate that EAD will continue to operate safely through life.

Section 8 Validity of Arg 1 in the Ongoing Operation (Arg 4) – presents the evidence to demonstrate the safety of any changes made to EAD.

Section 9 Conclusions – brings together the conclusions from the report.

The EAD Safety Case also contains the following appendices:

Appendix A Aeronautical Data Quality Regulation – provides further detail on material developed by regulatory bodies.

Appendix B EAD Safety Requirements – presents the EAD safety requirements.

Appendix C EAD Change Process – presents a diagrammatic representation of the change process for EAD.

Appendix D EAD Functional Models – presents the detailed functional model constructed to support the safety analysis activity.

Appendix E Goal Structured Notation (GSN) – presents a guide to understanding the EAD safety argument.



Appendix F Single European Sky Security Requirements – documents the SES Security Requirements along with the degree and extent to which EAD satisfies them.

Appendix G Glossary of Abbreviations – provides a summary of the terms used throughout this document.

Appendix H References – provides a list of references

1.9 Glossary of Terms and References

The EAD Definitions and Abbreviations [18] document provides a glossary of EAD terms used throughout this safety case, and is supported by the EATM Glossary of Terms [19] and EATM Glossary of Acronyms and Abbreviations [20]. A subset of terms common to this document and a list of references are provided in Appendix G and Appendix H respectively.



2. OVERALL CONTEXT FOR THE EAD SAFETY CASE

Within the European Civil Aviation Conference (ECAC) there are some 42 Contracting States each of whom, in accordance with Article 28 of the Convention on International Civil Aviation Organisation (ICAO) (Chicago Convention) and Annex 15 to this Convention, have the responsibility for providing an Aeronautical Information Service (AIS). The formal provision of these services is performed by civil and military, state owned or privatised Aeronautical Information Service Provider (AISP) organisations. Independent of the nature of these organisations, each State remains responsible for the information or data published for and on its behalf.

2.1 Aeronautical Information Service Provision

Many ground and air based aeronautical applications and functions rely on accurate data to describe relevant features or states of the Air Traffic Management (ATM) operational environment. For example, pilots require accurate charts to navigate the terrain, identify airways and danger areas, etc. Automated flight management systems require accurate approach/departure procedures, which need accurate data e.g. obstacle locations, types, and heights to ensure safe landing and takeoff routes are defined. A large amount of data is created and maintained to cover much of the globe. Each State is responsible for publishing all aeronautical data for their airspace, although they may not necessarily be aware of all of the applications for which the data can be used.

Errors in certain aeronautical data can affect the continued safe flight, landing or manoeuvring of aircraft and in the worse case have the potential to lead to catastrophe. End-users of aeronautical data are obligated, under the European Safety and Regulatory Requirements (ESARR), Federal Aviation Regulations (FAR) or Joint Aviation Regulations (JAR), etc. as applicable, to demonstrate that an acceptable level of safety is achieved for their service provision or application. Since Aeronautical Information Service Providers (AISP) do not know all of the potential uses of data, end users must define the properties they require of the published data but AISPs must show that these requirements are met. ICAO Annexes [1], [21], [22] & [23] and associated Standards and Recommended Practices (SARP), etc. are the primary means by which end-users define their data quality requirements.

2.1.1 Aeronautical Data

Aeronautical data is published in the form of an Integrated Aeronautical Information Package (IAIP) which comprises the following elements:

• Static Data

o Aeronautical Information Publications (AIP).

• Dynamic Data

o AIP Amendments and Supplements

o Pre-flight Information Bulletin (PIB) and Notice to Airmen (NOTAM)

o Aeronautical Information Circular (AIC)

o Checklists and lists of valid NOTAM.



Air Navigation Service Providers (ANSP) and other professional users depend on the accuracy, consistency and timeliness of the data for safe route management, flight planning and flight operations. Commercial entities manipulate the various data and produce processed packages, such as loaded Electronic Programmable Read Only Memories (EPROM) for flight management systems and consolidated aeronautical information publications (PIB, Chart etc.) for sale to any and all aviation professionals, including States.

AISs have implemented or acquired systems in order to improve their efficiency in the production and maintenance of the IAIP elements. Generally these systems have:

• a NOTAM function, usually based on a database management system, for the creation, processing and browsing of NOTAMs and for the generation of PIBs

• an AIP production function, which is most often reliant on Commercial Off The Shelf (COTS) editing software applications

• a charting function, also usually based on COTS graphical software applications.

These three functions rely on the same aeronautical information. Most of these systems thus comprise one or more databases of aeronautical information accessed by the three functions.

2.2 The Data Chain without EAD

State AISPs are required to ensure the flow of aeronautical information/data necessary for the safety, regularity and efficiency of international air navigation within their area of responsibility. From the European perspective, different State AISPs exchange aeronautical information amongst themselves as well as with various different stakeholders in a de-centralised and ad-hoc fashion. An overview of the Data Chain without EAD (hereafter referred to as non-EAD) is presented in Figure 2 below depicting the flow of aeronautical data between each of the prime functions in the Data Chain. Note that the diagram does not show all of the actors involved, e.g. only shows two AIS.



Figure 2 – Overview of non-EAD Data Chain

The operational structure of the non-EAD Data Chain has several limitations and drawbacks when seen from a European perspective as outlined in section 1.1.

2.3 The Data Chain with EAD

The cost effectiveness of AIS operations, the quality of aeronautical data and the accessibility and availability of such data can be significantly improved through automation and centralisation. This was the rationale for the development of a European AIS Database (EAD) to enhance the operational safety of air navigation by ensuring the quality of aeronautical information and by facilitating its timely and efficient electronic distribution. EAD enforces the validation rules for aeronautical data and the ICAO Annex 15 [1] requirements for data resolution and data accuracy, as well as providing a secure storage and data transfer infrastructure to meet the demanding Data Integrity Levels in ICAO Annex 15.

The prime beneficiary of EAD is other ANSP organisations and the airspace user community who chose to migrate. EAD can also be used by airlines that are based outside the ECAC area and by commercial organisations that use the aeronautical information to provide value added services and products. Migration to EAD introduces automation and centralisation in the provision, storage, processing and distribution of aeronautical information for AISPs and access to electronic data for data users. The identification and removal of redundant processes and of dispersed investments by the involved stakeholders has resulted in significant operational benefits to all. An overview of the prime functions of the Data Chain including EAD (hereafter referred to as with-EAD) is provided in Figure 3 below depicting the distribution mechanism within the same prime functions of the Data Chain as in Figure 2 .



Figure 3 – Overview of with-EAD Data Chain

EAD has been introduced gradually across Europe and the ECAC States. Tentative operation of EAD started in June 2003 with a limited set of pilot data users and data providers known as ‘clients’. EAD was subsequently updated in November 2004 (Release 2) and accepted by EUROCONTROL and a further update in December 2005 (Release 3). The current situation is the progressive migration of ECAC States to EAD with the objective of all ECAC States being fully migrated (hereafter referred to as full-EAD). EAD Data Operations (DOP) enters all essential data for non-migrated users to support the overall EAD service provided by EUROCONTROL.



3. OVERVIEW OF EAD

This section provides a brief summary of EAD. A more detailed description can be found within the System Safety Assessment (SSA) Report for EAD [4].

3.1 EAD Oversight

The EUROCONTROL Agency co-ordinates and facilitates the capture of customer experiences, manages the EAD contractors and customers in a way to reflect customers’ expectations of EAD and, together with the stakeholders (both internal and external to EAD), ensures the continuous evolution and development of EAD.

To achieve this EUROCONTROL has defined the internal and external interfaces for EAD Oversight; the manager of which is responsible for the following:

• co-ordinating and obtaining approval for strategic decisions of the EUROCONTROL Member States

• accountable for the EAD Service (including the financial performance of the EAD service against budget)

• ensures the internal co-ordination in the EUROCONTROL Agency.

EUROCONTROL provides the EAD service to Data Users and Data Providers; the organisation structure of EAD is provided in Figure 4 below.

Figure 4 – EAD Service Provision

The EAD IT Provider (ITP) is responsible for delivering the EAD IT Services to EUROCONTROL with the objective being for EUROCONTROL to provide the EAD Service to its EAD clients

The EAD Data Operations (DOP) is responsible for management, performance, monitoring and coordination of EAD DOP and Training Services

The EAD Application Maintenance provider is responsible for provision of maintenance and support services for the EAD Application Software.



3.2 EAD Functionality

EAD is intended to support the data publication and distribution component of the Aeronautical Data Chain. It also provides functionality to compile, handle, validate and submit flight plans (FPL) to CFMU and makes available the Electronic Route Availability Document (eRAD) on behalf of CFMU. Fundamentally, EAD provides the following basic functions to Data Providers and Data Users:

• supporting Migrated Data Users with the creation of static and dynamic aeronautical data publications, including:

o provision of data preparation tools such as Chart and AIP production

o validation of static data against pre-defined rules or dynamic data against static data

• data entry for Non-migrated Data Providers (which is also subject to validation)

• storing and distributing static and dynamic aeronautical data

• providing facilities for Flight Plan construction, validation and submission to CFMU Initial Flight Planning System (IFPS)

• making available to CFMU customers the Route Availability Document (RAD) and Electronic Route Availability Document (eRAD)

EAD provides this functionality through a number of services as illustrated in Figure 5 below.



Figure 5 – High-level EAD Logical Model

3.3 EAD IT Services

3.3.1 Static Data Operations (SDO)

The Static Data Operation (SDO) provides facilities for the input and checking of static aeronautical data required for the safe and timely execution of flight operations, for the efficient operation of the INO, and for additional data that is of common interest to EAD Clients.

3.3.2 International NOTAM Operation (INO)

The International NOTAM Operation (INO) provides facilities for processing, checking and creating international NOTAM and other relevant message data to be handled by EAD. The INO data is checked against the SDO data and all other INO data in order to ensure coherence and prevent double publications.

3.3.3 Aeronautical Information Publications (AIP)

The AIP is responsible for the production, maintenance and storage of the AIPs, AIP Amendments, AIP Supplements and AICs. The AIP subsystem is based on the FrameMaker/FrameAPS COTS product.



3.3.4 Published AIP Management System (PAMS)

PAMS is responsible for storing the published documents, viewing services through read only access and printing the documents. This includes maps and charts that are part of any of the above types of documents. The PAMS can also manage single charts in PDF format. The PAMS subsystem uses the flash-DMS COTS product.

3.3.5 Chart Production

The Chart Production subsystem is used to generate and maintain aeronautical charts from the SDO database. Charting parameters like chart specifications, graticule definitions, ellipsoid definitions and symbolisation can be used and maintained. Chart Production also offers specific charting functionality, such as geographical calculations and map projections. The Chart Production subsystem is based on the MicroStation/SmartGlobe COTS product.

3.3.6 Message Handling System

The Message Handling System provides EAD with an interface to AFTN/CIDIN.

3.4 EAD Data Operations

The EAD provides the following Data Operations services:

• EAD Training – provides essential training to EAD Users, although there is no obligation on users to use the training (see External Safety Requirement EFSR-07 ).

• EAD Aeronautical Data Entry – the EAD Service Provider undertakes aeronautical data entry on behalf of non-migrated clients; this includes the minimum static data set, NOTAM processing and scanning/input of AIP documentation into PAMS.

The above information is derived from the documents below, which detail the functions, services and boundaries of EAD:

• Data Provider Agreement [24]

• Data User Agreement [25]

• Public User Service Level Agreement [26]

• Service Level Specification [27]

• Static Data Associated to the AIP [28]

• Minimum Static and Dynamic Data Requirements [29]

• Operational User Handbook – Data Provider [30]

• Operational User Handbook – Data User [31]

• SDO Procedures Handbook [32]

• INO Procedures Handbook [33]



• PAMS Procedures Handbook [34]

• Service Desk Procedures Handbook [35]

• Organisational Procedures Handbook [36]

• Operational User Handbook - Data Provider [37]

• Operational User Handbook - Data User [38]

3.5 Support Functions

The following support functions are provided:

• Surveillance

Surveillance provides Advanced Helpdesk, Network Management and System Management services and is based on the COTS product Jira. The product includes functionality that covers the requirements for System Management, Network Management, and Service Desk.

• Security

The security management is based on COTS products. The security management provides facilities to secure EAD.

3.6 Definition of EAD for the Safety Assessments

In addition to the EAD services outlined above, a series of models have been constructed to support the safety assessment and hence construction of the EAD Safety Case. The models constructed compare the non-EAD and with-EAD situations and are described in the following sections.

3.6.1 EAD Functional Models

Three functional models have been constructed to support the safety analysis activities as follows:

• Appendix D, D.1 (Figure 16 ) represents the functional model for the non-EAD situation.

• Appendix D, D.2 (Figure 17 ) represents the functional model for the with-EAD situation. It can be seen from these models that EAD replaces the multiple mechanisms for distribution of aeronautical data as well as providing support functions for creating aeronautical information publications.

• Appendix D, D.3 (Figure 18 ) presents the functional model for the EAD Briefing Facility. The model identifies the primary functions in the Initial Flight Planning (IFP) lifecycle and identifies those functions that EAD supports.

• Appendix D, D.4 (Figure 19 ) presents a detailed EAD functional model. No detailed functional model was produced for the non-EAD situation



since the causal analysis was developed from the initial risk model provided in the Data Chain Preliminary Safety Impact Report [39].

• Appendix D, D.5 (Figure 20 ) presents a detailed EAD Briefing Facility functional model.

The functional models show the relationship between the high-level functions performed by Data Providers, Data Users and EAD. EAD does not change the aeronautical information activities/functions of the Data Providers or the Data Users. However, EAD does change the way in which aeronautical information (e.g. NOTAM, AIP and Static Data etc.) is stored and distributed and the process of using EAD does add verification and validation checks. EAD also provides additional checking of flight planning information via cross checking with static data held in the SDO.

3.6.2 EAD Services Model

The EAD services model, provided within the Preliminary System Safety Assessment Report [3], is a logical representation of the functions and services depicted in the functional model. EAD supports different kinds of users (or ‘clients’). The access rights and availability of concrete services differ between classes of users.

EAD users access EAD services through the EAD Client Interface (ECI), which is a general term used to refer to the different available client interfaces. These are:

• ETI (EAD Terminal Interface) for terminal based clients with direct use of the services provided by EAD. Data Providers and Data Users have access to this interface via a user terminal called EAD Client Interface Terminal (ECIT).

• ESI (EAD System Interface) for System based clients; this allows EAD clients’ systems to access EAD information via a controlled system-to-system interface.

The two access mechanisms to EAD described above are more generally referred to as EAD Pro.

• AFTN Gateway for AFTN (Aeronautical Fixed Telecommunication Network) subscribers; AFTN messages can be exchanged between AFTN subscribers (EAD Participants and EAD Non-Participants) and EAD.

• EAD can also be accessed via the Internet by Public Users which are non-commercial internet users. The provided functionality is very limited in the information that is available and is read only. This interface to EAD is more commonly known as EAD Basic. This service can be accessed via https://www.ead.eurocontrol.int/publicuser/public/du/login.jsp

3.6.3 EAD Physical Models

A high level physical mode of EAD, provided within the PSSA Report [3], depicts the overall physical architecture of EAD and its interfaces. A detailed description of the physical architecture for EAD is provided within the SSA Report for EAD [4].

The EAD system is geographically divided into the following main parts:



• The server sites – there are two central server sites, which contain the servers of EAD. These are both located in Vienna between two different organisations. The two server sites are connected through a Metropolitan Area Network (MAN) to connect the Local Area Network (LAN) from Site 1 to the LAN of Site 2. For clients it is totally transparent which site they are connected to. In addition, the EAD Business Continuity Site is located at the premises of an ANSP (Nav Canada) and is completely independent of the other two server sites.

• Data Operations Centres (DOP-C) – there are two remote Data Operations Centres for the EAD staff. These centres are connected to the server sites through the EAD Network.

• The clients (or client sites) – the clients can be separated into Data Providers, Data Users, External Systems, AFTN Subscribers and Public Users. All clients are connected to the EAD server sites: Data Providers, Data Users and External Systems are connected through the EAD Network, AFTN Subscribers through the AFTN/CIDIN network and Public Users through the internet via the following URL: http://www.ead.eurocontrol.int/pubicuser/public/du/ login.jsp

• The networks – five types of network connections exist to connect the various clients with the server sites:

o LANs to connect the HW inside the server sites and inside the office sites

o MAN between the two server sites

o EAD Network (WAN, ISDN/PSTN or dial up)

o AFTN/CIDIN network (to connect to the Communication Centre)

o Internet

Additional sites are the Training Site, the Test and Development Site and the Staging Site. The test equipment is separated from the Operational EAD System in order to avoid any impact from training and test activities on the operational system. The training equipment provides facilities to train EAD Clients.

3.6.4 EAD Logical Models

A high level logical model of EAD is presented in Figure 5 above. This model was used to further develop a series of detailed logical models of each individual EAD subsystem during the System Safety Assessment [4] activity.

These models are documented within an appendix of the SSA Report [4] and were used to further develop the causal analysis activity, the results of which are summarised in section 5.4.2.

3.7 Types of Aeronautical Data

A detailed list of aeronautical data items and the associated integrity classifications are presented in ICAO Annex 15 [1]. However, for the purpose of setting safety requirements and as was validated in the independent FHA and PSSA workshop



activities documented in [40], [41] and [42], no distinction is made between types of data as EAD handles all data in the same way, although additional mechanisms are used to assure the integrity of Essential and Critical data.

However, the implementation of EAD does need to take into account the different types of aeronautical information in order to design appropriate:

• operational procedures

• database facilities to correctly store aeronautical information to the right resolution and format

• Human Machine Interfaces to represent and display data correctly

• input and output error checking mechanisms, e.g. as a basis for Static and Dynamic Data validation, user error notification, etc.

This is reflected within the safety argument when assessing the necessary and sufficient evidence for satisfaction of the safety requirements (see Arg 1 ).



4. OVERALL SAFETY ARGUMENT

4.1 Objective

The objectives of this section are to:

• Outline the overall top-level safety argument for EAD

• Define any supporting context and justifications

• Explain the decomposition of the safety argument.

The overall EAD Safety Argument is presented in Figure 6 below using Goal Structuring Notation (GSN). Appendix E presents a guide to GSN (Figure 21 ) along with the colour coding used.

Appendix E presents the GSN Safety Argument in full for reference.

Figure 6 – Overall EAD Safety Argument

4.2 Principal Safety Argument (Arg 0)

The EAD Safety Case provides assurance in the form of arguments and evidence to support the claim that EAD contributes to the achievement of an acceptable level of safety for Aeronautical Information Service (AIS) provision (Arg 0) .

ICAO Annex 15 [1] sets out the requirements for the provision of Aeronautical Information Services by individual States. The responsibility for complying3 with ICAO Annex 15 rests with the individual States. EAD provides a support function to

3 States are requested under the ICAO convention to indicate compliance with the requirements, as indicated in the supplement to ICAO Annex 15.

See section 5 (Figure 7)






AIS publication and European wide distribution. EAD can thus provide the basis for a positive contribution towards reducing the risk of errors in the published Aeronautical Data, but only as part of a coherent and robust AIS publication process. The EAD Safety Case thus provides the argument and evidence to support the claim that EAD contributes towards the provision of an acceptably safe AIS (Arg 0 ). Demonstrating that an AIS is acceptably safe is outside the scope of this safety case, so the safety criteria for EAD defines an acceptable level of safety (Cr001) as:

• AIS related risk shall be no higher when using EAD than exists when not using EAD (non-EAD)

• EAD satisfies all applicable regulatory requirements

• Risk is reduced As Far As Reasonably Practicable (AFARP).

The rationale for the decomposition of the top level argument is provided in the next section.

4.3 Decomposition of Arg 0

The aim of the Safety Case is to provide EAD clients with demonstrable evidence to support their own safety cases. The data quality requirements defined in ICAO Annex 15 are taken as a minimum requirement for AIS and are used herein as the basis for assuring the adequacy of the evidence provided. However, it is generally agreed [43] that the process for compliance with ICAO Annex 15 integrity levels is not generally understood. This and other issues are being considered as part of the European Aeronautical Data Quality Mandate and it is likely that AISPs will be expected to meet the integrity targets through an Assurance Level approach (similar to Software Assurance Levels). The potential future implications of the mandate on AIS and EAD are addressed via Arg 4 below.

As such the EAD Safety Case provides AISPs with a derivation of the safety requirements relevant to EAD operations and use and assurance that these and other relevant regulatory requirements are met (in the context of Cr001). But it is incumbent on EAD Clients to take account of; all requirements that apply to them when using EAD; and the limitations and caveats defined (C003) when developing safety cases for their areas of responsibility (Assumption A003) and safety requirement EFSR 20, see Appendix B). It should also be noted that it is necessary to demonstrate that an adequate level of security is provided as threats to security are a direct threat to safety. Thus the argument for security is intrinsic to the argument for safety (C002).

The system definition for current EAD baseline (C004) is defined within a number of documents summarised and referenced within the EAD System Architecture [44], which describes the EAD System and Services and contains system structures for IT Segments, Software Units (SWUs) and Hardware Units (HWUs) (C001), see SSA Recommendation R001 .

Given the purpose (J001 & J002) and contribution of EAD to Aeronautical Information Services (C004), the rationale (St000) for achieving Arg 0 is thus to argue that:

• Baseline safety requirements are set for EAD that satisfy the safety criteria (Cr001) (Arg 1 )



• The EAD baseline currently satisfies the safety requirements set in Arg 1 (Arg 2 )

• Measures are in place to ensure that the EAD baseline continues to satisfy Cr001 (Arg 3 )

• Measures are in place to ensure that Arg 1 remains valid in the ongoing operation of EAD (Arg 4 ).

Each of the arguments above are discussed in detail in the following sections.



5. SPECIFICATION OF EAD SAFETY REQUIREMENTS (ARG 1)

5.1 Objective

The basis for the derivation of the EAD requirements is to demonstrate that baseline safety requirements specified for EAD are defined such that for the baseline configuration the risk of errors in aeronautical data published or distributed, including flight plan data distributed via the EAD Briefing Facility, is at least the same when compared to the situation before EAD became operational (non-EAD) and further reduced as far as reasonably practicable.

The safety argument for Arg 1 is presented in Figure 7 below.

Figure 7 – EAD Safety Requirements Specification (A rg 1)

5.2 Strategy

The EAD safety requirements are derived from following an ESARR 4 compliant safety assessment process (St001) using both a quantitative assessment of data integrity and a qualitative comparison of the risk in the non-EAD and with-EAD situations. Quantitative assessment is based on the apportionment of ICAO Annex integrity levels as well as consequence analysis of the impact of delays or loss of EAD service on ANSP operations. No assessment is made of the integrity levels applicable to individual data items, which are assumed to be as defined in Appendix 7 of ICAO Annex 15 et al.

The safety analysis undertaken was performed to derive the EAD safety requirements (Arg 1.2) and is based on understanding the boundary, scope and definition of EAD (Arg 1.1) . Once the safety requirements are derived, based on understanding the boundary of EAD, the safety requirements are then allocated as either internal or external (Arg 1.3) .

See section 5.3 See section 5.4 See section 5.5 See section 5.6



Fundamental to assuring safety is finally to demonstrate that a trustworthy process has been followed by competent people (Arg 1.4 ).

5.3 Scope and Definition of EAD (Arg 1.1)

The rationale for achieving Arg 1.1 was to define and validate a series of models and scoping statements and assumptions for the non-EAD and with-EAD situations as defined in section 3.5. Fundamental to validating the EAD models was to obtain ‘buy-in’ from identified stakeholders at an appropriate forum. This was achieved by holding a number of workshops (see section 5.3.2) to obtain feedback and generate discussions to support the safety assurance process.

5.3.1 Scoping Statements and Assumptions

All scoping statements and assumptions are documented in the FHA Report [2] and are repeated in section 9.3.3 for completeness along with all EAD Safety Case assumptions.

5.3.2 Validation of the System Definition for EAD

The functional, service and physical models identified in section 3.5 were presented for validation at an EAD Safety Assessment Workshop held at NAV Portugal in Lisbon on the 16th and 17th December 2004 [41]. Validation of updated versions of the EAD models was carried out at a second EAD Safety Assessment Workshop [42] held at The Westin Dragonara Resort, Malta on the 13th and 14th November 2008.

The more detailed EAD physical models and logical models were presented for validation at a working meeting held at the EAD IT service providers offices in Vienna on 21st, 22nd and 23rd September 2005 [45]. The models were then reviewed further during a second working meeting held at the same location in Vienna on 25th and 26th November 2008.

All the models provided in Appendix D have been updated to incorporate all comments received during and following the workshops and meetings outlined above.

5.4 Risk Assessment and Safety Requirements Derivat ion (Arg 1.2)

An FHA and PSSA as described in section 5.6 were undertaken for the non-EAD and with-EAD situations, to assess any relative change in the risk, and thus to derive appropriate safety requirements based on assurance that:

• all relevant hazards are identified for non-EAD and with-EAD situations

• the consequence of those hazards are assessed and safety objectives identified where applicable:

o for data integrity the consequences are as defined in the ICAO Annex 15 integrity definitions

o for loss of or delays to EAD services the impact on ANSP operations is identified



o for all other hazards the differences between the consequences in the non-EAD and with-EAD situations are fully identified

• causes of each hazard are developed to an appropriate level of detail commensurate with the scope and purpose of the safety analysis

• the necessary risk mitigations and regulatory requirements as defined in Appendix A to achieve the safety criteria (Cr001) are identified

• safety requirements are derived based on the above.

The evidence in support of the above claims is described in the following sections.

5.4.1 Functional Hazard Assessment

Ebeni Limited undertook an independent FHA activity, documented in [2] which provided an independent assessment of the hazards and potential consequences of those hazards in relation to EAD. To identify the hazards related to the publication and distribution of aeronautical data consideration was given to the ways in which data errors, delays or losses could be hazardous to the ATM environment. It was not feasible within the FHA to consider all specific ways in which data corruption could affect ATM operations (see section 4.2) so consideration was given to the following generic ways:

• Data Corruption – where individual items or sets of data are corrupted from their intended value

• Data Unavailability – where individual items or sets of data are missing, lost or otherwise delayed

• Data Discrepancy – where individual items or sets of data are inconsistent between key actors in the Data Chain, the resolution of which may increase Pilot or ATCO workload.

As a consequence a preliminary set of hazards for AIS Publication and Distribution relating to EAD have been identified all of which are common to the non-EAD and with-EAD situations:

• HAZ001 – Distributed Integrated Aeronautical Information Package (IAIP) contains valid but corrupt4 aeronautical data.

• HAZ002 – Distributed IAIP is missing specific change(s) in Aeronautical Information.

• HAZ003 – Total or substantial loss of Aeronautical Information.

• HAZ004 – Discrepancy between Adjacent State boundary aeronautical data.

• HAZ005 – Inconsistent Aeronautical Information between actors of Downstream Data Chain.

4 Valid but corrupt is defined as data of credible value or content but is not compliant with the data quality properties of ICAO Annex 15 [1] of accuracy, resolution, completeness, timeliness and format



For the EAD Briefing Facility a detailed safety assessment has already been undertaken for Initial Flight Planning (IFP) as part of development of the IFP Implementing Rule [46] and [47]. Based on the IFP safety assessment only one hazard has been identified as being applicable to the EAD Briefing Facility

• HAZ006 – Discrepancy between FPL held by pilot and FPL held by other parties.

5.4.1.1 Severity Classification

Appendix C of the FHA Report [2] presents the qualitative severity classification scheme used in the EAD safety assessment. The scheme is based on ESARR 4 [10] for ATM and JAR25-1309 [48] for aircraft related consequences. However, since a detailed consequence analysis of aeronautical data errors is not feasible the following assumptions for the severity for AIS related hazards are defined:

• The potential end consequences for aeronautical data errors (and hence the defined Data Quality Requirements) are the same for non-EAD and with-EAD scenarios, with differences only in the potential mitigations. This assumption was verified during the EAD Functional Hazard Assessment Workshops [41] and [42].

• The worse case consequence for data error is that the continued safe flight and landing of aircraft would be severely at risk with the potential for catastrophe; this is commensurate with the definition of critical data given in ICAO Annex 15 [1].

5.4.1.2 Consequence Analysis Conclusions

The Functional Hazard Assessment Report [2] identified six hazards that fall within the defined scope of EAD all of which are common whether using EAD (with-EAD) or not (non-EAD).

The FHA Report [2] also defines Safety Objectives associated with data corruption apportioned to EAD hazards based on the three data integrity levels defined within ICAO Annex 15 rather than an apportionment of the ESARR 4 [10] Target Level of Safety. Safety objectives associated with the loss of data were derived in the consequence analysis documented in [2]. The remaining hazards have not been set safety objectives as an acceptable level of safety is judged using a relative safety criteria i.e. the risk must be no greater than exists when not using EAD but nonetheless reduced as far as reasonably practicable. Table 2 below presents the risk objectives set for each of the EAD hazards.

Hazard Description Safety Objectives

HAZ001 Distributed Integrated Aeronautical Information Package (IAIP) contains valid but corrupt aeronautical data

Based on the data integrity requirements of ICAO Annex 15 [1] for critical data, AIS must assure that data is not plausibly corrupted more often than 10-8

Given that EAD is one of several links in the Data Chain then it is necessary to apportion EAD a more stringent target of 10-9 to ensure it does not undermine the integrity of the data chain as a whole



Hazard Description Safety Objectives

HAZ002 Distributed IAIP is missing specific change(s) in Aeronautical Information

As above

HAZ003 Total or substantial loss of Aeronautical Information

For static data then a loss of AIPs for more than 24 hours would result in a Severity 4 scenario in accordance with the ESARR 4 Severity Classification Scheme and as such is set a safety objective of 5x10-6 based on a TLS for Severity 4 events

of 10-3 apportioned to 200 hazards5.

For dynamic data then a loss NOTAMS for more than 1 hour could result in the worse case in a Severity 2 scenario, which for an individual ANSP should not occur more often than 5x10-

8 per flight hour. This is based on an apportioned TLS for Severity 2 events of 10-6 between 20 hazards

HAZ004 Discrepancy between adjacent State boundary aeronautical data

HAZ005 Inconsistent Aeronautical Information between actors of Downstream Data Chain

HAZ006 Discrepancy between FPL held by pilot and FPL held by other parties

No Safety Objectives are set for these hazards as an acceptable level of safety is judged using a relative safety criteria i.e. the risk must be no greater than exists in the non-EAD situation but nonetheless reduced as far as reasonably practicable

Table 2 – EAD Safety Objectives

5.4.2 Preliminary System Safety Assessment

Full details of the Causal Analysis, for the non-EAD and with-EAD situation are presented in the Preliminary System Safety Assessment Report [3].

The causal analysis for HAZ001 shows that a number of features are offered by the design of EAD in an attempt to improve the integrity of and confidence in the correctness of distributed aeronautical data at the point of entry into EAD as outlined below:

• a set of validation rules have been defined [49] with the aim of ensuring that EAD complies with ICAO rules for aeronautical data

• all data entered into EAD is validated before being committed to the EAD database

• Data Providers can enter data directly into EAD thus removing errors and checks associated with manual or electronic transfer between publishers and distributors.

5 It is necessarily the responsibility of ANSPs to determine the safety objectives for this hazard. However, these indicative targets are based on TLS apportionment for EUROCONTROL Upper Airspace Control Centre at Maastricht and are used in the absence of any specific user requirements.



The causal analysis for HAZ002 has shown that EAD provides a single source for all notifications thus facilitating Data Users in the identification of all notifications relevant to their needs. The stated availability of the EAD database and its associated distribution mechanism and services is also an additional feature offered by the design of EAD.

HAZ003 relates to total or substantial loss of aeronautical data within EAD and was originally assessed within the CHAIN FHA/PSSA [50] as currently infeasible as paper-based systems are still the primary means of publishing information, or, where electronic systems are used, paper versions of aeronautical data must also be published (see ICAO Annex 15 [1] paragraph 6.2.1). The causes of HAZ003 relate specifically to the physical architecture and security measures for EAD.

The causal analysis for HAZ004 shows that in the non-EAD situation there is no definitive mechanism for detecting this error other than through Commercial Organisations data checking. With-EAD the boundary data for each State AIS is checked with the boundary of adjacent State AIS for consistency, thus significantly reducing the probability of this hazard.

The causal analysis for HAZ005 shows that with-EAD it becomes possible for Data Users to use a common validated source of data thus significantly reducing the likelihood of an error or discrepancy as a result of:

• manual transfer of data

• electronic transfer using non-standard or partially compatible formats

• de-centralised information available on multiple paths within the Data Chain (each new source or path for data adds to the potential for discrepancy).

The only with-EAD scenario where a discrepancy can occur is where one Data User is using PAMS sourced data and another Data User is using SDO/INO sourced data. Thus there is a requirement to ensure that PAMS data and SDO/INO data are consistent (see External Safety Requirement EFSR-10).

The causal analysis for HAZ006, as with HAZ005, shows that in the with-EAD situation it becomes possible for Data Users to use a common validated FPL thus significantly reducing the likelihood of an error or discrepancy as a result of:

• manual transfer of data


• de-centralised information available on multiple paths within the IFP process (each new source or path for data adds to the potential for discrepancy).

5.4.2.1 Risk Mitigation

The aim of the risk assessment activity was to establish EAD safety requirements, within the extent of EAD managerial control, which for HAZ001, HAZ002 and HAZ003 satisfy the EAD Safety Objectives defined in the Functional Hazard Assessment Report [2] and for HAZ004, HAZ005 and HAZ006 enable an overall reduction in risk compared with the non-EAD situation.



To achieve this, appropriate risk mitigation related to each hazard has been specified in the form of safety requirements or assumptions as follows:

• Internal Safety and Security Requirements that must be satisfied by EAD

• External Safety and Security Requirements that must be satisfied by EAD Data Providers and Data Users

• Assumptions on external elements to EAD

• Assurance Level requirements in relation to the software, hardware and procedural elements of EAD

• Where appropriate a numerical target for each safety requirement assigned based on an apportionment from the safety objective.

The safety requirements derived from the preliminary system safety assessment activity are presented in Appendix B and consider all of the hazards identified for EAD. Risk mitigation to ensure risks are reduced as far as reasonably practicable is achieved by:

• Identification and specification of external safety requirements

• Provision of on-going monitoring, issue resolution and continuous improvement e.g. resulting in Release 4 and 5 etc. of EAD.

5.4.2.2 Safety Requirements Derivation

The EAD safety requirements are presented in three levels:

• Level 1 safety requirements are set at the boundary of EAD and relate to the safety functions depicted in Appendix D, D.2 (Figure 17 ).

• Level 2 safety requirements relate to the more detailed functional model, see Appendix D, D.4 (Figure 19 ) and the physical models and services models documented within the FHA Report [2] PSSA Report [3] and SSA Report [4].

• Level 3 safety requirements have been derived using the detailed sub-system logical models documented within the SSA Report for EAD [4], and rationalised with the Technical and User Requirements for EAD. More detail on the derivation of the Level 3 safety requirements can be found within the SSA Report [4].

A complete list of EAD safety requirements is provided in Appendix B. The completeness and correctness of the safety requirements is verified as part of the SSA activities as documented in [4] specifically Arg 1.2.1.2.5 .

5.5 Internal and External Safety Requirements Alloc ation (Arg 1.3)

Internal and external safety requirements are defined to achieve an overall risk reduction in the with-EAD situation compared to the non-EAD situation. The rationale for the allocation of EAD safety requirements between internal and external stakeholders is based on the definition of responsibilities as defined in section 6.4.2 and as confirmed via the Service Level Agreements (SLAs) [24], [25], [26] and Service Level Specification (SLS) [27].



5.6 Safety Requirements Process is Trustworthy (Arg 1.4)

Fundamental to assuring safety is also to demonstrate that a trustworthy process has been followed by competent people.

The EAD safety requirements documented within this EAD Safety Case were derived from an ESARR 4 [10] compliant relative safety assessment i.e. using a qualitative comparison of the risk without EAD, non-EAD, to the situation with-EAD. The EUROCONTROL Safety Assessment Methodology [51] was used as a guide to compliance with ESARR 4 [10].

The safety assessments for EAD have been undertaken independently from EUROCONTROL by individuals experienced in the field of safety engineering with extensive knowledge in ATM safety.

5.7 Conclusion for Arg 1

This section of the EAD Safety Case has shown, through argument and supporting evidence, that internal and external safety requirements have been defined to facilitate an improvement in the provision of an acceptably safe AIS thus Arg 1 has been satisfied.



6. SATISFACTION OF EAD SAFETY REQUIREMENTS (ARG 2)

6.1 Objective

The objective of this section is to demonstrate that EAD satisfies its defined internal safety requirements, that the discharging of external safety requirements has been achieved and that it can be shown that EAD safety requirements are met in EAD operation.


Figure 8 – EAD baseline satisfies safety requiremen ts (Arg 2)

6.2 Rationale for Arg 2

Satisfaction with the EAD safety requirements is assured for both internal and external aspects of EAD. Internal safety requirements satisfaction (Arg 2.1) is assured through extensive safety and design assurance activities as discussed in section 6.3, supported by rigorous EAD monitoring activities (Arg 2.3) .

External safety requirements satisfaction is assured through definition of safety requirements within the Service Level Agreements (SLAs) and verification of compliance with the SLAs during EAD client migration (Arg 2.2 ). Whilst it is assumed that Data Providers and Data Users will continue to comply with the external safety requirements this is also monitored by EAD. However, State AIS retain responsibility for assuring the correctness of aeronautical data published and distributed by EAD.

See section 6.3 (Figure 9)


See section 6.5 See section 6.7



6.3 Internal EAD Safety Requirements are satisfied (Arg 2.1)

Detailed demonstration that EAD satisfies its internal safety requirements is documented within the System Safety Assessment Report for EAD [4] as shown in Figure 9 below.

Figure 9 – EAD satisfies its Internal Safety Requir ements (Arg 2.1)

A summary of each of the next level arguments is provided within this section of the EAD Safety Case for completeness. All recommendations and caveats made within the System Safety Assessment Report for EAD are documented within section 9.

6.3.1 EAD Safety Requirements Traceability (Arg 2.1 .1)

This argument within the SSA Report [4] covers evidence as to how the Level 1 and Level 2 safety requirements defined in the PSSA Report [3] have been decomposed further to a set of defined Level 3 safety requirements through to their point of implementation.

The EAD Level 1 safety requirements were derived from the Fault Tree Analysis (FTA) at the EAD system boundary. The EAD Level 2 safety requirements were also derived from the FTA at the EAD sub-system boundary e.g. SDO, INO, PAMS etc. The EAD Level 3 safety requirements were derived by tracing the FTA base events to the relevant Technical/User requirements (TRE/URE) via the Contract Technical Specification (CTS).

Figure 10 below shows how the EAD safety requirements have been traced to their point of implementation within EAD.

See section 6.3.1 See section 6.3.2 See section 6.3.3 See section 6.3.4 See section 6.3.5 See section 6.3.6



Figure 10 – EAD Safety Requirements Traceability

The evidence in support of this argument documented within the SSA Report [4] shows that all EAD safety requirements trace via the EAD Contract Technical Specification [52] requirements to appropriate EAD sub-system Technical/User Requirements (TRE/UREs) and thus Arg 2.1.1 is fully satisfied.

6.3.2 EAD Equipment complies with Safety Requiremen ts (Arg 2.1.2)

This covers the evidence that the software and hardware components satisfy their safety requirements. The SSA report:

• traces the EAD Level 1 safety requirements to the point where they are implemented (Level 3)

• establishes the link to the evidence that substantiates each Level 3 requirement and provides or references the evidence to support the satisfaction

• predicts the hazard frequencies for EAD based on quantified base events, the numerical aspects of which are justified in ANNEX A to the SSA report [4].

Based on the results of the quantified safety assessment documented in the SSA report [4], is has been demonstrated that for Essential data the safety objectives and targets for EAD are satisfied.

A small amount of aeronautical data available via EAD is identified by ICAO Annex 15 [1] as Critical; i.e. certain runway, Helicopter pad and approach crossing data. In order for EAD to address Critical data integrity it was necessary to set additional Functional Safety Requirements (FSRs) based on the need to meet the Critical data



safety objectives. The following causal scenarios are modelled specifically to address Critical data issues along with a summary of the mitigation for each:

• A data item value is corrupted either due to a system error or an unauthorised user mistake. EAD provides a mechanism as part of Critical/ Essential data entry for either adding/checking the CRC where provided or creating a CRC if not, as detailed in the AIXM Primer [53], see also IFSR-68 and IFSR-69.

• A change to the real world value was not propagated to the EAD storage. Although changes to Critical data are made far less frequently than changes to other types of data, this has not been used as a mitigation in the EAD safety assessment, rather the following has been considered:

o Aeronautical data publication necessarily involves equipment people and processes; however, there is currently no generally recognised mechanism for demonstrating the levels of data integrity defined in ICAO Annex 15 [1] for people and procedures , see Safety Issue SI001

o Loss of data changes once committed to SDO can only occur if the database is restored from an incorrect backup following a catastrophic failure of EAD; this error mechanism is modelled within the analysis of HAZ003

o Subsequent loss of NOTAM data should be detected by sequence number checks, but for loss of PAMS no additional assurance for Critical data is provided, see Limitation L001

• A value and its associated CRC is altered by an unauthorised person. The security of EAD is vital to the assurance that aeronautical data is not altered or lost due to unwanted (e.g. hacking) or inadvertent (e.g. wrong user credentials) access. In previous EAD assessments the likelihood of such events has been based on historical evidence and qualitative arguments for the adequacy of EAD security arrangements.

Given the previously assessed threat level, security arrangements for EAD are considered adequate for Critical data; however, urgent action is required to complete a security assessment in accordance with recent published EUROCONTROL security guidance [54], [55] and [56]. This issue must be resolved within the next 6 months to avoid becoming a safety concern, see Safety Issue SI002 , i.e. it is not reasonable to assume that the level of threat will remain the same indefinitely and therefore the issue warrants more than just a recommendation.

Additional detail on each of the scenarios above can be found within the SSA report [4].

6.3.3 EAD DOP Procedures comply with Safety Require ments (Arg 2.1.3)

The traceability of external safety requirements to EAD procedures is discussed within Appendix B. Satisfaction of the procedural safety requirements by the Data Providers and Data Users is outside the scope of the EAD Safety Case. However, it should be noted that the EAD DOP can prevent potential EAD Clients from becoming operational EAD clients during the migration process, if either the EAD



DOP or EUROCONTROL are not satisfied that the safety requirements are being met.

A Procedure Assurance Level of PAL3 was assigned by the PSSA activity documented in [3] based on the draft guidelines within the ANS Safety Assessment Methodology [51]. The SSA Report [4] documents and makes reference to the evidence for EAD procedures, which include procedures covering contingency and business continuity, operations, security and user migration. The evidence documented within the SSA Report [4] in relation to EAD procedures compliance with EAD safety requirements fully substantiates that Arg 2.1.3 is satisfied today noting Safety Issue SI002 , which needs to be addressed within the next 6 months.

6.3.4 EAD Training satisfies Safety Requirements (A rg 2.1.4)

Section 1.2 of the Training Management Plan [58] covers training for EAD Staff, specific EAD DOP staff training as detailed in the plan cover training for the following roles:

• INO Operators;

• SDO Operators;

• Service Desk Operators;

• PAMS Operators.

All EAD training is validated via internal review cycles. Training reports are fed into the performance reporting process and delivered to EUROCONTROL on a monthly basis. Satisfaction sheets are provided to training participants, both internal and external, by which feedback is provided to the EAD DOP.

The SSA Report [4] also details the requirements for external EAD training. Although the Data Provider and Data User Service Level Agreements document the requirement for all users of EAD to be adequately trained, they do not mandate that EAD training for external stakeholders should be carried out by the EAD DOP.

The evidence documented within the SSA Report [4] in relation to EAD training and satisfaction of EAD safety requirements fully substantiates that Arg 2.1.4 is satisfied.

6.3.5 Implementation of EAD was to a known and cons istent baseline ( Arg 2.1.5)

The Configuration Management Plan [59] defines the activities for the Configuration Management (CM) of EAD. The processes defined in the CMP are compliant to ISO 1007:1995. The CM is based on the EAD Lotus Notes based Database (CMDB see section 3.2 of the CMP for details) which covers all system documents, correspondence, software (subsystem level), hardware, change requests and other quality records such as review item discrepancies and action items. This evidence, supported by the evidence documented within the SSA Report [4] in relation to the implementation of EAD to a known and consistent baseline fully substantiates that Arg 2.1.5 is satisfied.



6.3.6 Operational Validation completed successfully for EAD Baseline (Arg 2.1.6)

Operational validation of the current EAD baseline was carried out in October and November 2008 in accordance with the Release 5 Plan [60]. The validation and verification formed the basis for EUROCONTROLs acceptance of the EAD DOP ability to deliver the EAD service according to the service specifications laid down in the Service Level Specifications [27], [61] & [62]. The Release 5 Plan describes the scope, responsibilities, process, methods, criteria, tools and detailed test specifications required to perform the demonstration.

The evidence above, supported by the evidence documented within the SSA Report [4] in relation to operational validation of EAD fully substantiates that Arg 2.1.6 is satisfied.

6.4 External EAD Safety Requirements are satisfied (Arg 2.2)

Whilst EAD cannot guarantee how Data Providers and Data Users use EAD, it has a responsibility to discharge all its obligations with respect to recommending how EAD is used. As such, a set of external safety requirements have been defined (see section 5.5) which Data Provider and Data Users must demonstrate compliance to prior to using EAD.

The safety argument for Arg 2.2 is presented in Figure 11 below.

Figure 11 – External Safety Requirements are satisf ied (Arg 2.2)

6.4.1 Rationale for Arg 2.2

External safety requirements have been defined from the safety requirement specification activity described in section 5. In order to demonstrate that the external safety requirements have been satisfied it must be argued that the requirements are

See section 6.4.2 See section 6.4.3 See section 6.4.4



made known to EAD data providers and users, that the safety requirements are implemented and that their implementation is verified (St006). It is also vital that service level agreements with external EAD users are agreed and signed prior to migration to EAD (C012).

6.4.2 Boundary of Responsibility (Arg 2.2.1)

For each class of EAD User there is a Service Level Agreement (SLA) or Specification (SLS), which governs the way EAD should be used, maintained or relied on and defines the responsibilities on each party. The migration process for EAD [63] assesses each new EAD User (excluding the public) and derives a migration plan. EAD Users are not considered operational until such time that they have demonstrated compliance with the safety, security and other migration requirements and processes. The definition of the boundary of responsibility (EAD User classes and associated responsibilities with respect to EAD) is defined in Table 3 below and matches that defined in the SLAs and SLS, references [24], [25], [26] and [27].

Note that the following definition of responsibilit ies is central to the allocation of safety requirements between internal (EAD respon sibility) and external (other responsibility e.g. Data Providers and Data Users).

EAD User Class

Functions Examples Bounds of managerial control

SLA

Data Provider NOTAM creation, AIP production, etc.

State AIS Responsible for entering correct aeronautical data into EAD

�

Data User NOTAM queries, Static Data or AIP retrieval, etc.

Pilots, ATSUs, Air Operators

Responsible for how Data is used and distributed subsequent to retrieval

�

Commercial Data User

As Data Users but for further processing and distribution, e/g/ for Flight Management Systems

Data Houses and Application Data Packers

Responsible for how Data is used and distributed to retrieval

�6

Flow Management

Data User and Data Provider (i.e. Route Availability Documents)

CFMU, FMUs As Data User or Provider �7

Public User Public access to aeronautical data via the internet

Anyone EAD does not warrant the supply of aeronautical data to public Users

�8

6 Commercial Data Users are the same as Data Users, but will also have a Client Agreement with EUROCONTROL. 7 CMFU are a Data Provider and a Data User, the SLA and Client Agreement were in draft at the time of completing this draft report. 8 Public User access is via the Internet. The SLA is defined in a Disclaimer agreed to as part of the registration process.



EAD User Class

Functions Examples Bounds of managerial control

SLA

EAD DOP Non-migrated AIS publication entry, EAD maintenance, Service Desk, etc.

Aeronautical data entry, IT Administration, IT Security

As Data Provider for non-migrated AIS. Responsible for ongoing satisfaction of internal safety requirements

�9

Table 3 – EAD User Responsibilities

6.4.3 Service Level Agreements (Arg 2.2.2)

External safety requirements are defined and documented within the Service Level Agreements for EAD Data Providers [24] and EAD Data Users [25]. Appendix B identifies the external safety requirements to be satisfied, all but one of which can be traced either directly into the Service Level Agreements, or into referenced documents from the Service Level Agreements.

6.4.4 Service Level Agreement Satisfaction (Arg 2.2 .3)

The EAD external safety requirements are documented within the Data Provider and Data User Service Level Agreements [24] and [25]. Demonstrating satisfaction of the EAD external safety requirements is the responsibility of EAD Data Providers and Data Users and is not within the scope of the EAD Safety Case. Data Providers and Data Users will need to undertake their own safety assurance activities in order to demonstrate compliance with the Service Level Agreements.

A migration and transition plan is produced for each Data Provider/Data User intending to migrate to EAD; this plan requires compliance with the Service Level Agreements prior to migration. Further detail regarding migration can be found within the SSA Report for EAD [4].

6.5 EAD Safety Performance Monitoring (Arg 2.3)

The EAD SLS [27] defines the performance criteria and targets for monitoring of the EAD DOP and ITP services. The EAD DOP and ITP both generate a report once a month that indicates the actual performance against these targets (e.g. reference [64] & [66]). Non-compliances with the agreed SLS [27] are highlighted and tracked to resolution by the EUROCONTROL EAD Oversight management. Safety–related incidents related to data error and unavailability of EAD services are tracked as part of the service performance KPIs in the SLS [27]. The SLS may be reviewed once per year if deemed necessary by one of the contractual partners.

Data errors found within EAD are classified according to the severity scheme shown in Table 4 below.

9 The EAD Service Provider has an agreed Service Level Specification [27] with EUROCONTROL for the provision of EAD and related services.



Severity INO (e.g.) SDO (e.g.) PAMS (e.g.) WWDM (e.g.)

A = Extremely quality relevant

INO error causes a TAM not to show up in the respective PIB or TAM content not understandable

Incorrect slot date or slot not committed

Wrong effective date

Wrong Airspace ID or Upper/Lower Limits

Obsolete Runway

B = Highly quality relevant

INO error causes a TAM to show up in a PIB unnecessarily

Private slot not reviewed

AIP - missing or wrong pages

Missing Route

C = Quality relevant

Editing/summarizing not correctly performed but TAM content understandable

Naming convention not used

AIP pages out of order

Error in route width/route area designator

Table 4 – In-Service Error Severity Classification

Based on the number of errors reported the probability of class A errors with INO are 3 x 10-4, with SDO are 2 x 10-4, with PAMS are 1 x 10-3. No system errors that lead to data loss or corruption have been reported during the 5½ years of EAD operation.

The Service Performance reports also report incidents regarding the security of EAD and its facilities. Again, no such incidents have been reported in the 5½ years of EAD operation to date.

These operational performance figures are used in the calculation of the hazard frequencies.

6.6 Satisfying the Safety Criteria

The assessment documented in the FHA report [2] identified six hazards for EAD along with associated safety objectives as presented in Table 2 above.

Based on the results of the safety assessment activity documented in the SSA report [4] the following table shows for each EAD sub-system the predicted hazard probabilities.

Hazard Risk Objectives 10

SDO INO PAMS Specific Caveats

HAZ001 Critical Data < 1 x 10-8

Essential Data < 1 x 10-5

Routine Data < 1 x 10-3

3.0 x 10-9 3.1 x 10-9 4.8 x 10-9 Data Users check the CRC for each data item used (EFSR-22). Where no CRC is present the hazard frequency for all services is limited to 2.0 x 10-6

10 All figures are per EAD operational hour assuming a 1:1 relationship with per flight hours as any error will in the worse case affect all aircraft.



Hazard Risk Objectives 10

SDO INO PAMS Specific Caveats

HAZ002 As above 3.1 x 10-9 4.3 x 10-9 2.0 x 10-6 Data Providers verify changes are committed to SDO, INO, or PAMS (EFSR-05)

Data Users verify sequence numbers for NOTAMS (EFSR-19)

HAZ003 Static data (loss of AIPs for more than 24 hours) <= 5 x 10-6

Dynamic data (loss of NOTAMS for more than 1 hour)

<= 5 x 10-8

5.2 x 10-9

5.2 x 10-9

5.2 x 10-9 Data Users maintain alternative source e.g. local SDO backup, AFTN, etc. (Note that a backup failure probability of <1 x 10-3 is taken into account in calculating these failure frequencies)

HAZ004 The introduction of boundary data checking between each State AIS for consistency, self evidently provides a reduction in the probability of this hazard

HAZ005 Data Users can use a common validated source of data thus significantly reducing the likelihood of an error or discrepancy as a result of: • manual transfer of data


• de-centralised information available on multiple paths within the Data Chain (each new source or path for data adds to the potential for discrepancy)

HAZ006

No Safety Objectives set an acceptable level of safety is judged using a relative safety criteria i.e. risk must be no greater than exists in the non-EAD situation but nonetheless reduced AFARP

See Safety and Security Assessment Report for Introduction of the EAD Briefing Facility [78]

Table 5 – EAD Hazard Probability Predictions

As can be seen from Table 5 above the risk objectives EAD can meet the targets for Essential data, but cannot for Critical data.

6.7 Satisfaction of Regulatory Requirements (Arg 2. 4)

An assessment of all safety regulatory requirements applicable to EAD along with associated compliance statements is documented in the EAD Regulatory Requirements Compliance document [5]. At the time of writing completion of compliance statements is on-going, see Recommendation R001 .



EUROCONTROL have also carried out an assessment against the Single European Sky Security Requirements identified in 1.6.3; evidence against the requirements is provided in Appendix F.

6.8 Conclusion for Arg 2

This segment of the safety argument has shown that:

• EAD satisfies its internal safety requirements, subject to the caveats stated in section9.3;

• EAD external safety requirements have been defined and compliance verified subject to A002;

• EAD Service monitoring indicates that EAD safety requirements are met in the EAD Service Provider operation, but is not available for migrated Data Providers, although this is outside the scope of the EAD Safety Case.

Consequently, Arg 2 is satisfied with respect to Essential data subject to the stated caveats in section 9.3. Arg 2 is not satisfied for Critical data.



7. CONTINUED SAFE OPERATION OF EAD (ARG 3)

7.1 Objective

Ensuring that appropriate safety measures are in place is fundamental in demonstrating the continued safe operation of the EAD baseline and its satisfaction of the safety criteria (Cr001).


Arg 3.3

Processes exist to ensure

that changes to the EAD

baseline are acceptably safe

during transition to the new

configuration

St003

Argue that any changes

to the EAD baseline will

be adequately

managed such that

Cr001 remains satisfied

Arg 3.4

Processes exist to ensure

that all changes made to

EAD will be acceptably

safe in operation

Arg 3.1

Safety measures are in

place to ensure that EAD

internal and external

safety requirements

continue to be met

Arg 3.2

EAD migration

processes are defined

to ensure safe

Migration of New users

Arg 3.5

Processes exist to assess,

and where necessary

improve, the effectiveness

of the change process

C010: Changes are categorised as follows:

changes that require a period of

transitional operation (major change)

all other changes

C011: Change process includes:

change management, safety

management and security

management

Arg 3

Measures are in place to

ensure that the EAD

baseline continues to

satisfy Cr001

Figure 12 – Continued Safe Operation of EAD (Arg 3)

7.2 Rationale for Arg 3

This branch of the EAD safety argument deals with the ongoing processes for ensuring that the EAD baseline continues to satisfy the safety criteria (Cr001) (St003). The argument for the safety of future changes to EAD is developed on the basis that the baseline EAD fully satisfies all defined safety requirements (i.e. that Arg 1 is fully satisfied) (Arg 3) . The satisfaction of Arg 3 is achieved by having processes in place to ensure that safety is adequately considered and managed when changes are made to EAD (C010 and C011), and processes are in place to assess and where possible improve the change process itself (St003).

The consideration of changes to EAD is split into the following categories (C010):


See section 7.4

See section 7.5

See section 7.6 Figure 14

See section 7.7



• Changes to EAD Systems or Services that require a period of transitional or temporary operation;

• All other changes (e.g. new Releases).

7.3 Continued Safety Requirement Satisfaction (Arg 3.1)

Figure 13 – Continued safe operation of EAD

The overall responsibility to provide the EAD service rests with EUROCONTROL. EAD Data Operations (DOP) are outsourced to an external company, GroupEAD Europe S.L that has the responsibility for the successful performance of the service provision in co-ordination with EUROCONTROL as documented in Contract No. CO7/14155CG (chapter 3.1, GroupEAD Europe S.L.). The EAD DOP comprises:

• Data operations (i.e. the processing of TAM, the provision of world-wide static data and the coordination of the resolution of static data conflicts, etc)

• Supporting services (i.e. the provision of a Service Desk, supplier management, etc)

• Training of the clients on the EAD operational aspects

• Managing the DOP operations centres in Madrid and Frankfurt

• Supporting clients in the migration process

The EAD ITP service is managed by EUROCONTROL and outsourced to Frequentis AG in accordance with Contract No. C07/14154CG. A complete definition of all ITP services along with associated performance requirements are described in [62]. IT services cover the operations and management of the following:

• Operational System

• Staging System

See section 7.3.1 See section 7.3.2 See section 7.4



• Training System

• Assessment and Verification System

• Development System

• Test System

• On a demand basis, the ITP also provides support to the EAD DOP infrastructure in accordance with the DOP SLS.

A complete definition of all EAD services and the required performances are detailed in the attachment to the Service Contract: Service Level Specification (SLS) [27].

Thus the argument for continued safe operation must show that necessary procedures are in place to ensure continued satisfaction of the safety requirements in operation by ensuring that:

• Safety monitoring is in place to cover continued correct adherence to the processes and procedures for continued operation, including Data Provider, Data User procedures, corrective and preventative maintenance, training and error monitoring (Arg 3.1.1 ), see section 7.3.1.

• Change control processes are in place to ensure that any changes to the EAD system (equipment, procedures and training) are correctly handled (Arg 3.1.2 ), see section7.3.2.

• Security monitoring is in place to ensure operational procedures and policies are in place and that the system is up to date with respect to defending vulnerabilities from internal and external threats (Arg 3.1.3) , see section 7.3.3.

7.3.1 Processes in place to prevent the recurrence of incidents (Arg 3.1.1)

The SLS [27] defines the performance criteria and targets for monitoring of the EAD DOP and ITP service provision. The EAD DOP generates a report once a month that indicates the actual performance against these targets (e.g. reference [64]). The EAD ITP also produces a monthly report indicating actual performance against the requirements documented in the SLS (e.g. [65]). Any non-compliance with the SLS is highlighted and tracked to resolution by the EUROCONTROL EAD oversight management.

7.3.2 Change processes defined to maintain safety l evels (Arg 3.1.2)

The change management process for EAD is defined in the Change Management Plan [67] and is overseen by the EAD ITP. The Change Process involves EUROCONTROL, EAD DOP and the EAD ITP and covers any temporary or permanent modification to or addition of any, respectively, existing or new element of EAD. All changes must be approved by the Change Control Board (CCB)11 before initialisation of the change and implementation of the change for operational use.

11 The members of the CCB include three from EUROCONTROL EAD oversight, two from EAD DOP and one from the EAD ITP.



The main phases in the change management process are as follows and are explained in Section 2.4.2 of the CMP [67] in detail:

• Initialisation and processing of changes (CR) and detection of deficiencies

• Approval of the content of the new release (TID’s)

• Verification and Implementation of TID’s

• CCB Process before deployment (authorisation for operational Use)

• Closing the verified TID’s, and monitoring of patches installed on the production system

• Post-implementation Assessment

The CMP requires the review of the impact of changes on safety; and the SLS [27] requires preSSAs to be performed for every change (see SLS II.2.4 Key performance Indicators). Operational incidents that occur are assessed for their potential safety impact. In some cases it may be necessary to provide an immediate mitigation or change (known as a Hot Fix) to ensure EAD safety levels are maintained.

An overview of the change process is provided in Appendix C.

7.3.3 Adequate processes in place to maintain secur ity levels (Arg 3.1.3)

The Security Policy for EAD along with a list of EAD Security Objectives is documented within the Safety and Security Management Plan [68]. The EAD Security policy is intended to support the protection, control and management of EAD assets, specifically the EAD database information as well as ensuring the secure and protected storage of all aeronautical information received, processed, maintained and delivered by EAD including IT networks and the means of transmission. The Safety and Security Management Plan [68] also details the security methodology applied to EAD.

EAD IT Security procedures are summarised in section 3.6.3.4 of the SSA report [4] and are managed by the EAD ITP. EAD building security controls are outlined in section 3.6.3.5 of the SSA report [4], however it should be noted that the security arrangements for the EAD offshore business continuity site in Canada have yet to be made available, see Safety Issue SI002 .

7.4 Migration of New EAD Users (Arg 3.2)

A generic migration plan is defined within The Migration Management Plan [63]. An individual Migration and Transition Action Plan is produced for each Data Provider (e.g. Transition and Migration Plan for Morocco [69]) and Data User as details will depend on the type of users (e.g. Data Provider or Data User), the type of interface e.g. ESI or ECIT and other issues relevant to the migration process. The status of all EAD clients are recorded and released in regular Migration Matrix [70]. Users are not allowed to migrate to EAD operational status without completion of all the relevant migration steps (including safety and security considerations) to the satisfaction of EAD DOP and EUROCONTROL Oversight Management.



7.5 Transition Safety (Arg 3.3)

The Change Management Plan [67] implicitly covers changes that require a period of transitional operation, with explicit reference to the consideration of safety. All changes are required (by the SLS) to be assessed by the EAD Service provider using the preSSA template, which is discussed under Arg 3.4.2 and Arg 3.4.3 in the following section. An overview of the change process from a safety perspective is shown in Appendix C and captured in the Change Management Plan.

7.6 Processes for assuring changes to EAD are accep tably safe (Arg 3.4)

The change procedures for safety are referenced with the Change Management Plan [67]. The argument for this process is further refined in Figure 14, with the evidence for each sub-argument discussed in the following sub-sections.

Figure 14 – Process for assuring changes to EAD ar e acceptably safe (Arg 3.4)

7.6.1 Strategy

To demonstrate Arg 3.4 it must be argued that all changes to EAD are correctly specified and documented such that the EAD safety requirements are still satisfied (St008).

7.6.2 EAD Changes completely and correctly specifie d against baseline (Arg 3.4.1)

The changes for an EAD release are captured and defined in the Release Information of Release, e.g. [71] (C012). This identifies the source Trouble Ticket

See section 7.6.2

See section 7.6.3

See section 7.6.4

See section 7.6.5

See section 7.6.6



identification, a detailed description of the problem and the proposed resolution and expected result together with the implementation date.

All changes are reviewed by the EAD DOP and EUROCONTROL, and any review comments provided using the Change Request (CR) forms. All CRs are stored in Lotus Notes on the EAD CMDB [72] and tracked to closure.

7.6.3 Non interference of EAD changes to safety req uirements (Arg 3.4.2)

Each of the changes incorporated in a new release are assessed via a Preliminary Safety and Security Assessment for System Changes or preSSA, one is constructed for each change in accordance with the template as defined in [73]. The assessment of the change identifies the trouble ticket, system elements affected and description of the problem. It also identifies what components within EAD have been changed and identifies any other dependent components. The preSSA provides guidance with a series of pre-defined questions to assess the impact on safety and security of any change. Changes are rated as having no effect, a positive effect (1 or 2) or negative effect (1 or 2) on safety and on security. The rating is affected by the criticality of the functionality changed, whether the change can be tested and whether the change affects user operations. For each release of EAD an updated System Safety/Security Assessment Report (SS/SAR) is produced. The SS/SAR for Release 4 is documented in [74], safety assessment aspects of Release 5 are incorporated into the SSA report [4].

7.6.4 EAD Changes implemented completely and correc tly (Arg 3.4.3)

The changes implemented in a release are all verified as part of the Release assessment process, for example Release 5 is documented in [75]. Any anomalies or test failures are recorded in the TestDB and tracked to resolution.

The TID [76] for each change request can only be closed by the Change Control Board as described in the change management process under Arg 2.3 in section 7.4.

The assessment verification report (e.g. for R5 [75]) documents the changes that have been implemented since the previous release and include the following:

• verification of TIDs per subsystem

• regression tests per subsystem

• test cases for new features/change requests

• free tests/reviews

The CM/QM Baseline Report for Baseline R5 [77] provides a summary of all the performed Acceptance Test activities, including Final Acceptance testing of the EAD System.

7.6.5 EAD Changes remain compliant with Safety Requ irements (Arg 3.4.4)

All changes are required (in the SLS [27]) to be assessed in accordance with the preSSA template [73]. Each release also requires an update to the SS/SARs to assess that EAD remains compliant with the safety requirements.



7.6.6 EAD Changes made to a known and consistent Ba seline (Arg 3.4.5)

The satisfaction of Arg 2.2.5 can be considered the same as that for the baseline Releases (Arg 1.2.1 section 6.3), as the same configuration management plans and processes apply. A Configuration Management/Quality Management Baseline Report for R5 is documented within [77] and summarises all configuration Items (CI) which form the product baseline Release 5. This includes the applicable status of the following:

• Documentation Configuration Items (CI type Doc);

• Hardware Configuration Items (CI type HWI);

• Software Configuration Items (CI type SWI);

• Presentation Material & Handout Configuration Items (CI type PHO);

• Test Item Discrepancies (CI type TID).

All the items mentioned above are available within the Lotus Notes Database and Test Database.

7.7 Change Management Improvements (Arg 3.5)

The EAD DOP is required to maintain an ISO 9000 Quality Management System, which is regularly audited. The Key Performance Indicator for Quality Assurance, which is checked as part of the regular monitoring activity is QUA1 - the ISO 9001:2000 certification should be continuously maintained by the DOP throughout the life of the EAD service.

Section II.3.2.4 on Document Maintenance in the SLS [27] requires the EAD Service Provider to review and, if necessary, update the document deliverables listed in Annex B of the SLS on the following basis:

• as needed, in case it is identified that the described processes and procedures are not fit for purpose; and

• at least once a year to cater for all existing comment raised against any of these deliverables and to ensure that the documentation reflects and is consistent with the actual system and operating/working practices.

Annex B of the SLS also includes all of the key documentation for EAD and all of the change management process documents identified in the preceding sub-sections of this chapter.

7.8 Conclusions for Arg 3

This segment of the safety argument has shown that:

• Safety measure are in place to ensure that EAD internal and external safety requirements continue to be met

• EAD migration processes are defined to ensure the safe migration of new users



• Processes exist to ensure that changes to the EAD baseline remain acceptably safe during transition to the new EAD configuration

• Processes exist to ensure that all changes made to EAD will be acceptably safe in operation

• EAD processes exist to assess, and where necessary improve, the effectiveness of the change process.

Consequently, Arg 3 is fully satisfied.



8. VALIDITY OF ARG 1 IN THE ONGOING OPERATION (ARG 4)

8.1 Objective

To demonstrate that processes are in place to ensure the validity of EAD safety requirements in the ongoing operation of EAD.


Figure 15 – Validity of Arg 1 in the ongoing operat ion of EAD (Arg 4)

8.2 Strategy

Most of the changes to EAD will be of a routine nature implemented to improve system functionality and user interfaces or fix identified bugs in system operation, as discussed under Arg 3 . However, it is recognised that for the following reasons baseline safety requirements for EAD may have to change in order for the overall safety criteria (Cr001) to remain satisfied.

• Extensive changes are expected in the regulation of Aeronautical Information Services as part of the Single European Sky Interoperability Regulations – this is likely to extend the regulatory obligations of AIS providers beyond those currently specified in ICAO Annex 15.

• The flexibility of EAD as a centralised high-integrity database could see it be used for many other types of data or services, which may mean new ways in which EAD could contribute to Air Traffic Service provision hazards.

Thus it is necessary for EAD to ensure that processes are in place to identify, plan for and fully assess the implications of any significant changes to EAD or the regulatory framework for AIS provision.

See section 8.3 See section 8.4 See section 8.5 See section 8.6



8.3 Impact of Changes on EAD Safety Requirements (A rg 4.1)

The change management process for EAD Service Provision is defined in the Change Management Plan [67]. An overview of the change process is provided in section 7.3.2 (under Arg 3.1.2 ) and Appendix C. As part of this process all changes are also assessed for their impact on the safety requirements baseline. In principle, there is a potential impact if the change necessitates a change to:

• The functional model of EAD, as shown in Appendix D.2, which may require an update to the Functional Hazard Assessment and if new hazards or safety objectives are identified then also the Preliminary System Safety Assessment

• The logical model for EAD, as shown in the SSA report [4] , which may require an update to the Preliminary System Safety Assessment and thus amend or create new Level 1, 2 or 3 safety requirements

8.4 Updated EAD Safety Requirements satisfy Safety Criteria (Arg 4.2)

Section 3.2.1 of the EAD Safety and Security Management Plan [68] details the change process for assessing the impact of each change to be made to EAD to determine if the FHA and PSSA require updating.

This process being via documentation of a Preliminary Safety and Security Assessment (PreSSA) in accordance with [73] followed by a Change Request Safety and Security Assessment (CR SSA). For each defined baseline of EAD a Safety and Security Assessment (SSA) is carried out; as part of each SSA the impact on the FHA and PSSA is analysed and updated if needed.

8.5 Updated EAD Safety Requirements Satisfaction (A rg 4.3)

Section 3.2.1 of the EAD Safety and Security Management Plan [68] details the change process for assessing the impact of each change to be made to EAD to determine if the SSA report requires updating.

As outlined above, for each defined baseline of EAD a Safety and Security Assessment (SSA) is carried out; as part of each SSA the impact on the System Safety Assessment (SSA) report i.e. determine if there is an impact on the fulfilment of the safety requirements.

8.6 EAD Compliance with Regulation and Standards (A rg 4.4)

As part of the reworking of the safety argument in section 4 the safety activity has identified the current regulations and standards relevant to EAD i.e. the tool support for and storage and distribution of aeronautical information (see section 1.6.1 and Appendix A). The compliance assessment (section 6.7) is complete insofar as is possible given the state of the current regulation e.g. the European Commission Mandate on Aeronautical Data Quality is still under development. There is a need therefore to track the progress of these regulations and likely enforcement dates to ensure that EAD remains compliant with good practices. It is recommended therefore that the EAD Safety Management Plan is updated to identify this need and how it will be addressed (Recommendation R002 ).



8.7 Conclusions for Arg 4

This segment of the safety argument has shown that in on-going EAD operation:

• The impact of change to EAD on the EAD safety requirements is assessed (Arg 4.1 )

• Updated EAD safety requirements satisfy the safety criteria (Arg 4.2 )

• Updated EAD safety requirements continue to be satisfied (Arg 4.3 )

• EAD continues to comply with applicable regulation and standards (Arg 4.4 )

Consequently, Arg 4 is fully satisfied subject to Recommendation R002 stated in section 9.4.



9. CONCLUSIONS AND RECOMMENDATIONS

9.1 Summary

This document presents the second version of the Safety Case for EAD. The previous EAD Safety Case demonstrated adequate assurance for maintaining a level of safety equivalent to data derived from non-EAD sources. The safety case also set limits on the Data Integrity Level that could be claimed for EAD sourced data equivalent to Routine or Essential as defined in ICAO Annex 15,

This updated EAD Safety Case is based on reworked safety assessments (Functional Hazard Assessment (FHA), Preliminary System Safety Assessment (PSSA) and System Safety Assessment (SSA)), which address the latest developments12 in the regulatory context for Aeronautical data provision as well as the Critical Data Integrity Level.

Overall, EAD provides for a potential reduction in the overall risk to safety posed by failures in the aeronautical Data Chain. It has been shown that EAD can reduce the likelihood of hazards related to aeronautical data publication preparation and distribution through:

• For migrated Data Providers:

o improved data validation and reinforcement of Data Provider verification

• For migrated Data Users:

o centralised checking and distribution of AIPs, NOTAMs and other publications

o reduced likelihood of discrepancies between publications

• In the longer term:

o potential reduction in the amount of redundant manual and electronic transfer

o improvements to data error reporting

o reduced likelihood in discrepancies between Data Users.

9.2 Conclusions

The EAD Safety Case provides substantiation for the four principal safety arguments that together demonstrate that EAD contributes towards Aeronautical Information Services achieving a reduction in the risk of errors in Integrated Aeronautical Information Packages (IAIP), subject to the caveats stated in section 9.3. These arguments are:

12 In particular as part of the Aeronautical Data Quality Implementing Rule under the Single European Sky mandate.



• Necessary and sufficient EAD safety requirements are defined for EAD to contribute to the reduction of the risk of errors in published Aeronautical Information by specifying those requirements that:

o are met by EAD – the internal safety requirements;

o must be met by external actors or stakeholders (i.e. users of EAD) – the external safety requirements;

• EAD meets its internal safety requirements in its current configuration and will continue to do so in ongoing operations;

• External safety requirements are stated and agreed by EAD clients before they are allowed to migrate to EAD operations;

• Adequate processes are in place to ensure that all changes to EAD in the future will be managed and implemented safely.

This report summarises and references the evidence that demonstrates that these arguments are substantiated subject to the stated Safety Issues, Constraints and Limitations, below. A number of recommendations are also made but they do not affect the conclusion of the EAD Safety Case.

9.3 Caveats

9.3.1 Safety Issues

The following safety issues have been identified as a result of the EAD safety assessment activity.

Ref Safety Issue Resolution & Dependencies

SI001 The ADQ Mandate and supporting Community Specifications will define assurance objectives for demonstrating data integrity for AIS.

Until such time as the Community Specifications are made available it is difficult to assure that independent Data Provider checking can achieve the level of integrity required i.e. 1 x 10-6

SI002 Given the previously assessed threat level security arrangements for EAD are considered adequate for Critical data; however, urgent action is required to complete the security assessment including a review of the security controls in place at the EAD offshore contingency site in Canada.

This issue must be resolved within the next 6 months to avoid becoming a safety concern

Table 6 – EAD Safety Issues

9.3.2 Constraints

The following constraints apply when using EAD:

• EAD Migrated Data Providers and Data Users must use the EAD in accordance with the agreed Service Level Agreements (see EFSR-06, EFSR-13 & EFSR-21) and in particular taking note of the specific caveats presented herein (see Table 5)



• EAD Migrated Data Providers and Data Users must not place greater reliance on the integrity of any committed data item than as defined in ICAO Annex 15 [1] (see EFSR-20) or amended or otherwise notified by the State Aeronautical Information Service provider responsible for the data.

• Data Users must not place any reliance on the integrity of data downloaded from EAD via the internet (see Limitation L003 )

• EAD Migrated Data Providers retain responsibility in accordance with ICAO Annex 15 [8] for the completeness and correctness of data committed to EAD. In particular, migrated Data Providers must not rely on EAD to check the following:

o accuracy of aeronautical data

o contents of IAIP scanned to PAMS

o content of AIP or Charts created using the EAD IAP and Charts support tools.

The following limitations have been identified from the safety assessments undertaken for EAD.

Ref Source Limitation

L001 EAD SSA Report [4] section 4.4.3.3.2

Loss of NOTAM data should be detected by sequence number checks, but for loss of PAMS no additional assurance for Critical data is provided

L002 EAD Release 4 Safety Assessment [86], L001

Until training needs for the Data Quality Reviews of SDO approach and departure procedures has been finalised and all EAD DOP staff have received the appropriate training; Data Quality Reviews of SDO data shall only be performed by suitably qualified and competent personnel

L003 EAD PSSA [3], L001 Aeronautical Data delivered via EAD Basic over the internet is not guaranteed to satisfy the associated integrity required by ICAO Annex 15

L004 EAD PSSA [3], L002 ARINC data available via the EAD is only assured to Essential

Table 7 — EAD Limitations

9.3.3 Assumptions

The following table lists the assumptions that have been made during the safety assessment and in construction of this EAD Safety Case along with their associated validation statements.

Ref Assumption Validation

A001 Flight plan filing organisations using the EAD Briefing Facilities comply with the IFP European Commission Mandate in accordance with the associated Community Specification or suitable alternative.

The IFPL Mandate is currently ongoing but compliance is assessed as part of user migration to the Briefing Facility

A002 CFMU IFPS will send amendments to FPL originators when changes to the conditions of a FPL are required

Requirement of the IFP Implementing Rule



Ref Assumption Validation

A003 Data Providers and Data Users are responsible for assuring their overall processes in which EAD is used achieve an acceptable level of safety

Satisfaction of EFSR-20 by Migrated Data Providers

A004 Data Providers and Data Users comply with identified EAD external safety requirements

Satisfaction of EFSR-13 by Migrated Data Providers and of EFSR-21 by Data Users

A005 The potential end consequences for aeronautical data errors are the same in the non-EAD and with-EAD scenarios.

FHA/PSSA Workshop

A006 The worst case consequence for data error would be 2. Large reduction in safety margins which is commensurate with the following definition of critical data given in ICAO Annex 15 [1]: The [critical] data, if erroneous, would prevent continued safe flight and landing or would reduce the ability to cope with adverse operating conditions to the extent that there is a large reduction in safety margins or functional capabilities. There is a high probability when trying to use corrupted critical data that an aircraft would be placed in a life threatening situation.

Based on the domain specification for AIS, ICAO Annex 15.

Table 8 – Assumptions

9.4 Recommendations

Based on the contents of this safety case the following recommendations have been made. All recommendations should be resolved as part of the safety activities for EAD Release 6.

Recommendation R001 EAD Regulatory Requirements Compliance statements should be completed as soon as possible and the results summarised in an update to the EAD Safety Case.

Recommendation R002 The EAD Safety and Security Management Plan should document the process for tracking the progress of AIS regulations and likely enforcement dates to ensure that EAD remains compliant with good practice.

All recommendations documented within the System Safety Assessment Report [4], have been repeated below for completeness.

SSA Recommendation R001 The EAD System Architecture Core Document [44] requires updating to reflect the current EAD baseline and infrastructure organisation as the latest version makes no mention of the Offshore Business Continuity Facility in Canada.

SAA Recommendation R002 The gaps in safety requirements traceability needs to be rectified

SSA Recommendation R003 All EAD safety requirements should be linked from their associated T/URE within the TestDB

SSA Recommendation R004 Changes made to the Level 2 safety requirements and the identification of new Level



3 safety requirements should be incorporated into the updated EAD PSSA report

SSA Recommendation R005 It is recommended that a response is obtained to the hardware and software questions sent to the EAD Network Provider regarding the WAN change

SSA Recommendation R006 It is recommended that the EAD DOP consider, when reviewing Critical and Essential data, larger sample sizes of data when undertaking Routine Reviews. For Critical data a reduction in the error threshold to zero should be achieved rather than the thresholds presented in Table 1 of the Data Quality Procedures Handbook (EAD/DOC-GEN6N6)

SSA Recommendation R007 The updated EAD Briefing Facility models presented in this report, along with the associated safety analyses should be incorporated into the updated EAD FHA report, PSSA report and EAD Safety Case

SSA Recommendation R008 EAD Briefing Facility Service Level Agreements (SLAs) should state that EAD Briefing Facility Data Users should take account of the defined availability of the Briefing Facility and decide based on their own safety assessments whether a backup flight plan submission mechanism is required



APPENDIX A AERONAUTICAL DATA QUALITY REGULATION

A.1 European Commission

The European Commission is the executive body of the European Union which is charged with proposing, implementing and enforcing regulations. Of most relevance to this study are those regulations that have been, or are in the process of being, introduced under the Single European Sky (SES) initiative.

The SES initiative aims to reform the architecture of European ATC to meet future capacity and safety needs. This reform is addressed through the application of a regulatory approach. The objectives of the legislation are to improve and reinforce safety, to restructure European airspace as a function of air traffic flow, rather than according to national borders, to create additional capacity and to increase the overall efficiency of the air traffic management system (ATM).

The following are considered to be in scope as they establish the legal framework for the SES and those Implementing Rules which directly relate to EAD services.

• 549/2004 SES Framework Regulation

The framework regulation creates a legal basis upon which the SES is created and the other regulations are established. Additionally, it creates the oversight management functions, lays down the role of bodies such as the Industry Consultation Board (ICB) and how consultation and review will be performed.

• 550/2004 SES Airspace Regulation

One prime objective of the SES is the desire to harmonise airspace such that ATM operates less on State borders and more as a result of logical airspace blocks. This regulation establishes the legal framework within which these changes are to be brought about.

• 551/2004 - SES Service Provision Regulation

This regulation addresses, at a high level, the needs for a common standard of service provision across the SES. It introduces requirements such as service provider certification, staff licensing and safety management.

• 552/2004 - SES Interoperability Regulation

In order to support many of the other initiatives of the SES, it is clear that the components of the ATM infrastructure (both systems and human) must be able to co-operate in a more efficient and harmonised manner. This regulation establishes the framework by which further regulations will be introduced to enhance interoperability.

• 2096/2005 SES Common Requirements

In order to provide a common core competence within Service Providers, the SES requires that they are certified against a set of Common Requirements which are laid down within this regulation. Specific requirements exist for, amongst other, providers of AIS and MET.



• ADQ Implementing Rule

The Aeronautical Data Quality Implementing Rule was developed under the Interoperability Regulation with the intent of improving and standardising the quality of aeronautical data made available within Europe. It also seeks to ensure that digital information is made available.

Currently this rule has not yet been endorsed by the Single Sky Committee (SSC).

• IFP Implementing Rule

The IFP IR lays down the requirements on procedures for flight plans in the pre-flight phase in order to ensure the consistency of flight plans, repetitive flight plans and associated update messages between operators, pilots and air traffic services units through the Integrated Initial Flight Plan Processing System. This applies either in the period preceding the first delivery of air traffic control clearance for flights taking off from within the airspace covered by this Regulation or in the period preceding entry into that airspace for other flights.

• 2008/0127 SES Phase II

The SES Phase II regulation sets out a number of changes to the SES regulations 549/2004, 550/2004, 551/2004 and 552/2004.

A.2 ICAO

The International Civil Aviation Organisation (ICAO) is a specialised agency of the United Nations and acts as a global forum for civil aviation. ICAO works to achieve its vision of safe, secure and sustainable development of civil aviation through cooperation amongst its member States.

The primary document of ICAO is the Chicago Convention to which all member States are signatories. This is supported by a number of Annexes and guidance documents.

The following annexes and documents are considered relevant to EAD services.

• Annex 2 - Rules of the Air

Annex 2 establishes the Rules of the Air, the basic framework within which the aviation industry operates. The SARPs contained within it are generally applicable to pilots and aircraft operators.

• Annex 4 - Aeronautical Charts

Much aeronautical information is provided graphically by way of charts and ICAO Annex 4 specifies both general SARPs which apply to all charts and those which are applicable to specific charts.

• Annex 11 - Air Traffic Services

The requirements for the provision of an Air Traffic Service (ATS) are provided within this Annex. The specific services covered are:



o Air Traffic Control;

o Flight Information;

o Alerting.

The specific relevance of this Annex is the inclusion of a limited number of requirements that apply to the Briefing Facility.

• Annex 15 Aeronautical Information Services

ICAO Annex 15 lays down the SARPs for the provision of AIS by a State, including the needs for provision of the Integrated Aeronautical Information Package (IAIP) and pre-flight briefing.

• Doc 4444 Procedures for Air Navigation Services: Ai r Traffic Management

The Procedures for Air Navigation Services — Air Traffic Management (PANS-ATM) are complementary to the SARPS contained in ICAO Annex 2. They are supplemented when necessary, by regional procedures contained in the Regional Supplementary Procedures (Doc 7030).

The Procedures for Air Navigation Services — Air Traffic Management (PANS-ATM) specify, in greater detail than in the SARPS, the actual procedures to be applied by ATS units in providing the various air traffic services to air traffic.

The specific relevance of this document is the inclusion of a limited number of requirements that impact the provision of the Briefing Facility.

• Doc 7030 - Regional Supplementary Procedures

The ICAO Regional Supplementary Procedures (SUPPS) form the procedural part of the Air Navigation Plans developed by Regional Air Navigation (RAN) Meetings to meet the needs of specific areas which are not covered in the worldwide provisions. They complement the statement of requirements for facilities and services contained in the Air Navigation Plan publications. Procedures of worldwide applicability are included either in the Annexes to the Chicago Convention as SARPs, or in the Procedures for Air Navigation Services (PANS).

The SUPPS do not have the same status as SARPs. PANS are approved by the President of the Council of ICAO on behalf of the Council and SUPPS are approved by the Council; the PANS are recommended to Contracting States for worldwide use, whilst the SUPPS are recommended to Contracting States for application in the groups of flight information regions to which they are relevant.



A.3 ISO

The following ISO regulation also applies:

• 9001:2008

ISO 9001:2008 specifies requirements for a Quality Management System where an organisation

o needs to demonstrate its ability to consistently provide products that meets customer and applicable statutory and regulatory requirements, and

o aims to enhance customer satisfaction through the effective application of the system, including processes for continual improvement of the system and the assurance of conformity to customer and applicable statutory and regulatory requirements.

All requirements of ISO 9001:2008 are generic and are intended to be applicable to all organisations, regardless of type, size and product provided.

Where any requirement(s) of ISO 9001:2008 cannot be applied due to the nature of an organisation and its products, this can be considered for exclusion.

Where exclusions are made, claims of conformity to ISO 9001:2008 are not acceptable unless these exclusions are limited to requirements within Clause 7, and such exclusions do not affect the organisation's ability, or responsibility, to provide products that meet customer and applicable statutory and regulatory requirements.



APPENDIX B EAD SAFETY REQUIREMENTS

ID & Level Requirement Satisfaction Status

Assurance Level Requirements (ALR)

ALR-01

(Level 1)

The demonstrable level of confidence that the EAD software is developed and integrated in the EAD system in order to manage risks due to software failure shall be as defined by Software Assurance Level 3

See Software Assurance argument within the SSA Report [4], Section 4.4.1, Arg 1.2.1.2.1.2

ALR-02

(Level 1)

The demonstrable level of confidence that the EAD procedures are developed and integrated in the EAD system in order to manage risks due to procedural failure shall be as defined by Procedure Assurance Level 3

See Procedural Assurance argument within the SSA Report [4], Section 4.5, Arg 1.2.1.3

ALR-03

(Level 1)

The demonstrable level of confidence that the EAD hardware is developed and integrated in the EAD system in order to manage risks due to hardware failure shall be as defined by Hardware Assurance

Level13 3

See Hardware Assurance argument within the SSA Report [4], Section 4.4.3, Arg 1.2.1.2.3

ALR-04

(Level 1)

The demonstrable level of confidence that the EAD COTS software is developed and integrated in the EAD system in order to manage risks due to software failure shall be as defined by Software Assurance Level 4 for COTS Software

See Software Assurance argument within the SSA Report [4], Section 4.4.1, Arg 1.2.1.2.1.2

Internal Functional Safety Requirements (IFSR)

IFSR-01

(Level 1)

EAD shall provide facilities and services for the storage of static and dynamic aeronautical data as defined in the CTS [52]

MET

• System Safety Assessment Report for EAD [4], ANNEX A

IFSR-02

(Level 1)

EAD shall provide facilities and services for the timely submission of static and dynamic aeronautical data as defined in the CTS [52]

MET


IFSR-03

(Level 1)

EAD shall ensure that all current Aeronautical Information changes are included within the IAIP

MET


IFSR-04

(Level 2)

EAD shall provide facilities and services for the creation of electronic versions of paper static and dynamic Aeronautical Information Publications as defined in the CTS [52]

MET


IFSR-05

(Level 1)

EAD shall provide facilities and services for the reliable distribution of static and dynamic aeronautical information as defined in the CTS [52]

MET


13 At this time Hardware Assurance Levels are not defined within the Safety Assessment Methodology [51] so the Hardware Assurance argument relies on evidence of non-interference, reliability and freedom from single point failure.




IFSR-06

(Level 2)

EAD shall validate INO messages against SDO data for completeness and correctness

MET


IFSR-07

(Level 2)

EAD shall prevent unauthorised update of aeronautical data in the SDO, INO or PAMS

MET


IFSR-08

(Level 2)

EAD DOP shall check that data from non-migrated data providers is correctly committed to EAD

MET

System Safety Assessment Report for EAD [4], ANNEX A

IFSR-09

(Level 2)

EAD shall validate all aeronautical data before it is committed to EAD for completeness and correctness

MET


IFSR-10

(Level 2)

The validation of aeronautical data shall be independent of any Data Provider checks and include checks against ICAO Annex 15 format rules, boundary values, completeness and other sensibility checks

MET

• System Safety Assessment Report for EAD [4], ANNEX C

IFSR-11

(Level 2)

Individual validation checks shall only be suspended on the authorisation of the Data Provider responsible for the data

MET


IFSR-12

(Level 2)

EAD DOP shall verify data from non-migrated

users before committing the data to SDO, INO14 or PAMS

MET


IFSR-13

(Level 2)

EAD shall correctly process NOTAM from non-migrated users within 1 hour of notification by the Data Provider responsible

MET


IFSR-14

(Level 1)

EAD shall check the consistency of boundary data for adjacent States

MET


IFSR-15

(Level 2)

EAD shall warn data users of any known or detected deficiencies in stored aeronautical data

MET


IFSR-16

(Level 2)

The EAD DOP shall only allow suitable trained operators to update aeronautical data stored by EAD or maintain related EAD Services

MET

• System Safety Assessment Report for EAD [4], Arg 1.2.1.4

IFSR-17

(Level 2)

The EAD DOP shall implement and keep current mechanisms to defeat deliberate security attacks

MET


14 It should be noted that INO data is reviewed after the service is provided; it cannot be verified before due to the dynamic nature of the service.




IFSR-18

(Level 2)

EAD DOP shall enter non-migrated user aeronautical data in accordance with the requirements of the Service Level Specifications

MET


IFSR-19

(Level 1)

The EAD DOP shall enter aeronautical information for all non-migrated users as defined in part III.2.3 of the Service Level Specification [27] for world-wide Static Data Maintenance.

MET


IFSR-20

(Level 2)

EAD DOP shall keep aeronautical data from non-migrated users and stored in EAD up to date

MET


IFSR-21

(Level 2)

EAD shall provide facilities for feedback of user identified errors in aeronautical data to the responsible Data Provider

MET


IFSR-22

(Level 2)

Any errors or delays to distribution of data held within EAD that are reported to the EAD DOP shall be recorded and analysed as defined in [27]

MET

• Monthly Service Performance Reports (e.g. Service Performance Report for December 2004 [64]) are constructed and delivered to EUROCONTROL in accordance with [27]

IFSR-23

(Level 2)

EAD shall provide contingency plans to recover aeronautical data in the event that data is lost, commensurate with the scale of the loss

MET

• Business Continuation Plan [79], • IT Service Continuity Management

Plan [80] • Technical Procedures Handbook [81]

IFSR-24

(Level 2)

EAD shall provide a primary and secondary means of storing aeronautical data in the INO, SDO and PAMS databases

MET

• System Architecture – Core Document [44]

• Preliminary HW and LAN Design [82]

IFSR-25

(Level 2)

EAD shall not deny access to authorised EAD Users within the context of defined access rights

MET


IFSR 26

(Level 2)

EAD DOP shall inform Data Providers in the event SDO, INO or PAMS data is recovered from backup

MET


IFSR-27

(Level 2)

EAD shall provide a HMI to support EAD Users in achieving the external safety requirements

MET

• System Safety Assessment Report for EAD [4], Arg 1.2.1.2.4

IFSR-28

(Level 2)

The physical implementation of EAD shall ensure that adequate mitigations are in place to reduce the risk from non-functional safety hazards to an acceptable level, commensurate with the regulations and legislation of the country of location

MET

• System Safety Assessment Report for EAD [4], Arg 1.2.1.2.3

IFSR-29

(Level 2)

EAD shall not corrupt data committed to SDO MET





IFSR-30

(Level 2)

EAD shall not corrupt data committed to INO MET


IFSR-31

(Level 2)

EAD shall not corrupt data committed to PAMS MET


IFSR-32

(Level 2)

EAD shall not lose or corrupt data during the transfer of IAIP to or from EAD

MET


IFSR-33

(Level 2)

EAD shall correctly display/print Aeronautical Information from SDO

MET


IFSR-34

(Level 2)

EAD shall correctly display/print Aeronautical Information from INO

MET


IFSR-35

(Level 2)

EAD shall correctly display/print Aeronautical Information from PAMS

MET


IFSR-36

(Level 2)

EAD shall correctly translate Aeronautical Information between any EAD supported data formats and provide an anomaly report for each translation

MET


IFSR-37

(Level 2)

SDO shall provide the facilities for Data Providers to submit Aeronautical Information at the right time

MET


IFSR-38

(Level 2)

SDO shall provide the facilities for Data Users to retrieve Aeronautical Information at the right time

MET


IFSR-39

(Level 2)

PAMS shall provide the facilities for Data Providers to submit Aeronautical Information at the right time

MET


IFSR-40

(Level 2)

PAMS shall provide the facilities for Data Users to retrieve Aeronautical Information at the right time

MET


IFSR-41

(Level 1)

EAD shall ensure that all committed Aeronautical Information changes are correctly distributed

MET


IFSR-42

(Level 2)

INO shall provide the facilities for Data Providers to submit Aeronautical Information at the right time

MET


IFSR-43

(Level 2)

INO shall provide the facilities for Data Users to retrieve Aeronautical Information at the right time

MET





IFSR-44

(Level 1)

The mean time to restore service of a complete system following an interruption, to the point where application-level recovery and restart is completed, should be no more than 1 hour (CTS Requirement 72)

MET


IFSR-45

(Level 2)

It shall be possible for Data Providers to make on-line updates to AIP at any time within the limits of the required system availability

MET


IFSR-46

(Level 2)

It shall be possible for Data Providers to make on-line updates to Charts at any time within the limits of the required system availability

MET


IFSR-47

(Level 1)

The mean time between failures of a complete system which results in loss of data shall be at least 20 years. The mean time between Interruption of Service should be at least 4000 hours (CTS Requirement 71)

MET


IFSR-48

(Level 1)

EAD shall prevent discrepancies arising between SDO, INO and PAMS data as a result of EAD failures

MET

• Safety and Security Assessment Report for Introduction of the EAD Briefing Facility [78]

IFSR-49

(Level 1)

The EAD Briefing Facility shall apply the specified ICAO provisions to construction and changes to key items in a flight plan

MET


IFSR-50

(Level 1)

The EAD Briefing Facility shall ensure that flight plan originators are made aware of any flight plan or updated flight plan submitted to CFMU that has not been acknowledged

MET


IFSR-51

(Level 1)

The EAD Briefing Facility shall ensure that conditions of acceptance of a flight plan and any necessary changes to these conditions as notified by CFMU are made available to the originator of the flight plan

MET


IFSR-52

(Level 1)

The EAD Briefing Facility shall provide data users the facility to create, validate and submit FPL, amended FPL and amendment messages to CFMU

MET


IFSR-53

(Level 2)

The EAD Briefing Facility shall not corrupt FPL/FPL message amendments prior to transmission to CFMU

MET


IFSR-54

(Level 2)

The EAD Briefing Facility shall notify FPL message originators of the acknowledgment of a FPL message when such an acknowledgement has been received from CFMU

MET





IFSR-55

(Level 2)

The EAD Briefing Facility shall forward all FPL/FPL amendment messages received from CFMU to the originator

MET


IFSR-56

(Level 2)

The EAD Briefing Facility shall notify FPL message originators if no response message has been received from CFMU within a specified time period following submission of a FPL message

MET


IFSR-57

(Level 2)

The EAD Briefing Facility shall notify the FPL message originator of a loss of the Aeronautical Fixed Telecommunications Network (AFTN)

MET


IFSR-58

(Level 2)

The EAD Briefing Facility Briefing Box shall forward all FPL/FPL amendment messages received from the EAD Briefing Facility database to CFMU

MET


IFSR-59

(Level 2)

EAD shall provide guidance to Data Users on how to use the EAD Briefing Facility

MET


IFSR-60

(Level 2)

The EAD Briefing Facility database shall forward all FPL/FPL amendment messages input into the EAD Briefing Facility HMI to CFMU

MET


IFSR-61

(Level 2)

The EAD DOP shall conduct an independent and comprehensive check on request (a General Review) of all data committed to EAD by a migrating Data Provider

MET


IFSR-62

(Level 2)

The EAD DOP shall routinely perform independent sample checks of all migrated Data Provider data committed to EAD

MET


IFSR-63

(Level 2)

The EAD DOP shall inform Data Providers of any identified or suspected errors in their data

MET


IFSR-64

(Level 2)

The EAD DOP shall recommend the necessity of a General Review of all data for any Data Provider in the case of consistent poor results. The General Review shall be performed by the Data Provider

MET


IFSR-65

(Level 2)

CHART shall provide the facilities for Data Providers to submit Aeronautical Information at the right time

MET


IFSR-66

(Level 2)

AIP shall provide the facilities for Data Providers to submit Aeronautical Information at the right time

MET





IFSR-67

(Level 2)

EAD shall provide an independent means other than EADpro for Data Providers to enter aeronautical information

MET


IFSR-68

(Level 2)

All Critical and Essential data (as defined by ICAO Annex 15, appendix 7, et al) shall be CRC protected as defined by ICAO Annex 15 section 3.2.10

MET


IFSR-69

(Level 2)

CRCs entered for Critical and Essential data shall be checked for correctness before being committed to the database. Where no CRC is supplied a CRC shall be created associated with each data item entered.

MET


IFSR-70

(Level 1)

The likelihood that all EAD sites shut down due to a common mode failure shall be less than or equal to 1.0E-09

MET


External Functional Safety Requirements

EFSR-01

(Level 2)

Data Providers shall ensure that aeronautical data or associated meta data entered into SDO is complete and correct

MET

• Data Provider Agreement [24] • Operational User Handbook - Data

Provider [30] • SDO Procedures Handbook [32]

EFSR-02

(Level 2)

Data Providers shall ensure that aeronautical data or associated meta data entered into INO is complete and correct

MET


Provider [30] • In accordance with the Operating

Procedures for AIS Dynamic Data (OPADD) [84]

• INO Procedures Handbook [33]

EFSR-03

(Level 2)

Data Providers shall ensure that aeronautical data or associated meta data entered into PAMS is complete and correct

MET


Provider [30] • PAMS Procedures Handbook [34]

EFSR-04

(Level 1)

Data Providers shall provide independent checking of data committed to EAD

MET


Provider [30]

EFSR-05

(Level 2)

Data Providers shall ensure the completeness and correctness of aeronautical data entered into EAD

MET


Provider [30]

EFSR-06

(Level 2)

Migrated Data Providers shall update dynamic aeronautical data in accordance with the timescales set out within the Service Level Agreements

MET


Provider [30]




EFSR-07

(Level 2)

Data Providers shall only allow suitable trained operators to update aeronautical data stored by EAD

MET


Provider [30]

EFSR-08

(Level 2)

Data Providers shall only allow authorised operators to update aeronautical data stored by EAD

MET


Provider [30]

EFSR-09

(Level 2)

Data Provides shall check SDO data in full the first time the database is populated following successful migration to EAD Operation

This requirement was re-worded during the SSA see [4] Appendix B.

MET

• Migration Management Planning [83]

EFSR-10

(Level 2)

Data Providers shall resolve any potential errors in their data identified by EAD in so far as is practicable

MET


EFSR-11

(Level 2)

Data Providers shall verify the consistency of SDO, INO and PAMS data and notify EAD of any known unresolved deficiencies

MET


EFSR-12

(Level 1)

Data Providers shall ensure that any effective dates associated with aeronautical data are entered correctly

MET


EFSR-13

(Level 1)

Migrated Data Providers shall enter aeronautical data in accordance with the timescales set out within the Service Level Agreements

MET


• Data processed in accordance with Operating Procedures for AIS Dynamic Data (OPADD) [84] and AIS Data Process [85]

EFSR-14

(Level 2)

Data Providers shall ensure that aeronautical data or associated meta data entered into or used from EAD into AIP is complete and correct

MET


EFSR-15

(Level 2)

Data Providers and Data Users shall ensure that the Client Hardware systems do not corrupt or remove items of aeronautical meta data or associated meta data during input/processing

MET


EFSR-16

(Level 2)

Data Providers shall ensure that aeronautical data or associated meta data entered into Charts is complete and correct

MET


EFSR-17

(Level 1)

Data Users shall make contingency arrangements for temporary access to static and dynamic data in the event such data is not available via EAD

MET

• System Safety Assessment Report for EAD [4], ANNEX C

• Requirement of ICAO Annex 15 [1]

EFSR- 18

(Level 2)

Migrated Data Providers shall keep aeronautical data stored in EAD up to date

MET





EFSR-19

(Level 2)

Data Users should maintain procedures for non-EAD levels of checking aeronautical data with EAD

MET


EFSR-20

(Level 2)

Data Users should not place greater reliance on the data provided by EAD than the hazard probabilities as specified in the EAD Safety Case

MET


EFSR-21

(Level 2)

Data Users should use EAD in accordance with any procedures defined within the Service Level Agreement

MET


EFSR-22

(Level 2)

Data Users shall verify data items against associated CRCs where provided

MET


EFSR-23

(Level 2)

Data Providers shall enter CRCs for all survey data items where and as provided by the data originator

MET


Table 9 – EAD Safety Requirements



APPENDIX C EAD CHANGE PROCESS



APPENDIX D EAD FUNCTIONAL MODELS

D.1 Functional Model for Publication and Distributi on non-EAD

Figure 16 – Functional Model for Publication and Di stribution non-EAD

D.2 Functional Model for Publication and Distributi on with-EAD

Figure 17 – Functional Model for Publication and Di stribution with-EAD



D.3 EAD Briefing Facility Functional Model

Figure 18 – Basic Functional Model for EAD Briefing Facility



D.4 EAD Detailed Functional Model

Figure 19 – EAD Detailed Functional Model



D.5 EAD Briefing Facility Detailed Functional Model

Figure 20 – EAD Briefing Facility Detailed Function al Model



APPENDIX E GOAL STRUCTURED NOTATION (GSN)

Safety Argument Goal (Top level argument)

Safety Argument strategy for achieving the Goal

Assumption/Context/Justification to support goal or strategy

Reference to supporting evidence

Safety Argument Goal (sub-argument)

Safety Argument Goal (sub-argument – outside scope)

Criteria to support goal

Figure 21 – GSN Guide to symbols



APPENDIX F SINGLE EUROPEAN SKY SECURITY REQUIREMENT S

SES Security Requirements

EAD Evidence in support of SES Security Requirement s

Ensure security of facilities and personnel to prevent unlawful interference with provision of services.

EAD System Safety and Security:

• Smartcards will be used for the VPN connection:

o The set of smartcards will be stored by the supervisors

o When a position has to be opened the operator requests a smartcard to the supervisor

o When a position is closed the smartcard must be given back to the supervisor

IT Service Provider provision :

• Key security aspects of premises :

o Fences surround the whole premises

o Manned guarding 24x7

o CCTV monitoring

o Alarm system

o Access control system

• Sensitive rooms are fitted with an electronic magnetic card system, requiring an individual PIN code to be entered. All movements may be evaluated at any time.

Ensure security of operational data received or produced or otherwise employed, so that access is restricted to only those authorised.

ITP-EAD Network Security and Interface Management - Specific Requirements:

• The EAD IT security architecture shall encompass the following services:

o Authentication (via X.509v3 certificates)

o Authorisation (via LDAP and CRL)

o Data integrity (via IPSec ESP)

o Confidentiality (via IPSec ESP/3DES)

o Non-repudiation (via IPSec and logging, message signing on ESI only

• The ITP shall provide the necessary architecture to encompass all security relevant components of the actual implementation whereof PKI, LDAP and VPN gateways.

• The chosen implementation shall be flexible with respect to future extensions and shall provide additional authentication and encryption standards.

• The ITP shall provide for the implementation and operational of the VPN network layer, authentication service and security perimeter at Client operation centres.

• With respect to authorisation and authentication the service shall comprise all necessary measures to finally provide the client a secure access according to the definitions of the agreed installation plan.

• The security layer shall be provided continuously which at least requires avoiding any single point of failure in between client and the EAD IT Operation Centres.

• The ITP shall comply with the EAD network security specifications.





ITP Responsibilities – Specific Requirements:

• The ITP shall establish and document the technical and management functions, activities and tasks necessary to manage users, including Client Security Officer set up, smart cards delivery and certificate requests acceptance.

Safety Integrity Requirements for EAD Operational H ardware:

• The login count of obsolete accounts in the EAD System shall be zero.

• There shall be no users that do not comply with password standards.

Ensure security clearance of personnel, if appropriate

No evidence available

Co-ordinate with civil and military authorities to ensure security of facilities, personnel and data.

Not applicable

Define procedures relating to security risk assessment and mitigation.

DOP Security Management – Specific Requirements:

• The DOP shall conduct regular Proactive Security Risk assessments.


• The ITP shall perform a preliminary Safety and Security Assessment of the impact of any change or bug fix on the EAD Operational System prior to the deployment of the change and shall document the findings. Preliminary SSAs shall be sent to DOP for verification.

• The ITP shall perform a System Safety and Security Assessment for any new release of the EAD Operational System prior to the deployment of the release to ensure compliance with the Safety and Security Objectives defined; they shall document and report results to CCB.

• The ITP shall participate in the testing of Safety and Security Concerns.

• The ITP shall establish and document the technical and management functions, activities and tasks necessary to identify potential Safety and Security Hazards with respect to EAD System and Service provision, to ensure that their impact is reduced to as low as reasonably practicable.


• 99.5% of new Safety and Security identified risks, breaches and incidents shall be addressed and mitigated according to the risk matrix associated to Safety and Security Management.

Define procedures relating to security monitoring and improvement.


• The DOP shall log and analyse all service related security occurrences, define and monitor corrective actions, and document the whole.

• The DOP shall provide in the performance report the number of logged security occurrences/ incidents with a summarised description and identification of each of them.

ITP-EAD Network Security and Interface Management – Specific Requirements:

• As part of the overall security policy, the ITP shall undertake a regular (daily) evaluation of security related logs as well as caveats issued by





software or equipment manufactures.

• Security logs as well as performance metrics shall be recorded and archived to allow for a post-analysis of threats or service interruptions.


• The ITP shall detail in the Performance Report and detailed measurement log all aspects of Safety & Security Management, and any deviation from the specified measurements or KPIs.

Define procedures relating to security reviews and lesson dissemination.


• The DOP shall perform at least one audit per year to verify the adherence to the safety and security procedures established.


• Security logs as well as performance metrics shall be recorded and archived to allow for a post-analysis of threats or service interruptions.


• The ITP shall log and analyse all system related security occurrences, define and monitor corrective actions, and document the whole.

• The ITP shall perform at least one audit per year verifying the adherence to the Safety and Security Procedures; they shall document and report the results to EUROCONTROL.


• Safety and Security Management service will be measured by compliance of ITP to specifications, verified by means of audits by EUROCONTROL (minimum 1/yr).

• Any deviation detected in any Safety and Security Audit shall be tackled within the week.

• The ITP shall include in the reporting number of logged Safety and Security Occurrences/Incidents + summarised description of each.

• The ITP shall include in the reporting number and identification of preliminary SSA performed.

• The ITP shall include in the reporting hardware integrity levels, # of system hardware faults leading to loss or corruption of data.

Define means to detect security breaches and to alert personnel with appropriate warnings.


• As part of the overall security policy, the ITP shall undertake a regular (daily) evaluation of security related logs as well as caveats issued by software or equipment manufactures.


• The ITP shall mitigate the day-to-day risks of security (intrusion detection, access control surveillance)


• The ITP shall report any immediate incidents or risks as they occur via Ad Hoc reporting toward the relevant personnel.

Define means to contain effects of security breaches







Define means to identify recovery action





Define mitigation procedures to prevent re-occurrence.





Table 10 – EAD Compliance with SES Security Require ments



APPENDIX G GLOSSARY OF ABBREVIATIONS

Abbreviation Definition

AFARP As Far As Reasonably Practicable

AFTN Aeronautical Fixed Telecommunication Network

AIC Aeronautical Information Circular

AIP Aeronautical Information Publications

AIS Aeronautical Information Services

ANSP Air Navigation Service Provider

ATM Air Traffic Management

ATSU Air Traffic Service Unit

CFMU Central Flow Management Unit

CIDIN Common ICAO Data Interchange Network

CMDB Configuration Management Database

CMP Change Management Plan

COTS Commercial Off-The-Shelf

CTS Contract Technical Specification

EAD European Aeronautical Information System Database

EATM European Air Traffic Management

ECAC European Civil Aviation Conference

ECIT EAD Client Interface Terminal

EFSR External Functional Safety Requirements

EPROM Electronic Programmable Read Only Memories

ESARR EUROCONTROL Safety Regulatory Requirements

FHA Functional Hazard Assessment

GSN Goal Structure Notation

HWU Hardware Unit

ICAO International Civil Aviation Organisation

IFSR Internal Functional Safety Requirements

INO International NOTAM Operation

ISDN Integrated Services (switched) Digital Network

ISR Inferred Safety Requirements

KPI Key Performance Indicators

LAN Local Area Network

MAN Metropolitan Area Network

NOTAM Notice to Airmen

PAMS Published AIP Management System

PIB Pre-flight Information Bulletins

PSSA Preliminary System Safety Assessment

SDO Static Data Operations

SIR Safety Integrity Requirements

SLA Service Level Agreements



Abbreviation Definition

SLS Service Level Specifications

SMS Safety Management Systems

SSA System Safety Assessment

SSAR System Safety/Security Assessment Report

SWU Software Unit

TLS Target Level of Safety

WAN Wide Area Network

Table 11 – Table of Abbreviations



APPENDIX H REFERENCES

It should be noted that the CMDB from which a number of references within the following table are derived is a living configuration management database; updated documents are added to the CMDB on a daily basis. The latest version at the time of issue of this safety case has thus been used.

1. Aeronautical Information Services, Annex 15 to the Convention on International Civil Aviation, Twelfth Edition – July 2004

2. Functional Hazard Assessment (FHA) Report for EAD, P08013.10.9 (EAD/DOC-ECR17J), v2.0, 10 March 2009

3. Preliminary System Safety Assessment (PSSA) Report for EAD, P08013.10.10, (EAD/DOC-ECR3Y9) v3.0, 07 July 2009

4. System Safety Assessment Report (SSA) for EAD, P08013.10.11, v2.0, 10 July 2009

5. EAD Regulatory Requirements Compliance Report

6. ESARR 1 Safety Oversight in ATM, Edition: 1.0, Edition Date: 05 November 2004

7. ESARR 2 Reporting and Assessment of Safety Occurrences in ATM, Edition: 2.0, Edition Date: 03 November 2000

8. ESARR 3 Use of Safety Management Systems by ATM Service Providers, Edition: 1.0, Edition Date: 17-07-2000

9. EUROCONTROL CFMU Safety Policy, STD-SEC/POL/SAFPOL

10. ESARR 4 Risk Assessment and Mitigation in ATM, ESARR4, Edition: 1.0, Edition Date: 05 April 2001,

11. ESARR 5 ATM Services Personnel, Edition: 2.0, Edition Date: 11 April 2002

12. ESARR 6 Software in ATM Systems, Edition: 1.0, Edition Date: 6 November 2003

13. Commission Regulation (EC) No 2096/2005 of 20th December 2005 laying down common requirements for the provision of air navigation services. Official Journal of the European Union, 21/12/2005

14. EUROCONTROL Security Management Handbook: A Framework, Edition: 1.0, Edition Date: May 2008, Released Issue

15. EUROCONTROL ICT Security: Guidance Material, Edition: 1.0, Edition Date: May 2008, Released Issue

16. EUROCONTROL ATM Security Risk Assessment Methodology, Edition: 1.0, Edition Date: May 2008, Released Issue

17. Safety Case Development Manual, DAP/SAF/091, v2.2, 13 November 2006

18. European AIS Database Glossary, No reference, available at: http://www.eurocontrol.int/ead/public/site_preferences/display_glossary_list.html

19. EATM Glossary of Terms, http://www.eurocontrol.int/eatm/gallery/content/public/library/terms.pdf, 9 June 2004

20. EATM Glossary of Acronyms and Abbreviations, http://www.eurocontrol.int/eatm/gallery/content/public/library/acronyms.pdf, 27 July

21. Aeronautical Charts, Annex 4 to the Convention on International Civil Aviation



22. Air Traffic Services, Annex 11 to the Convention on International Civil Aviation

23. Aeronautical Telecommunications, Annex 14 to the Convention on International Civil Aviation

24. Data Provider Agreement, EAD/DOC-GEN082

25. Data User Agreement, EAD/DOC-GEN083

26. Public User Service Level Agreement, http://www.ead.eurocontrol.int/ disclaimer.html

27. EAD Oversight Service Level Specification, DAP/NET/EAD/1000 EAD/DOC-GEK4PN

28. Static Data Associated to the category AIP, EAD/DOC-ECLGHD

29. EAD Service, Minimum Static and Dynamic Data Requirements, EAD/DOC-ECN55E

30. EAD Programme, EAD Service Development, Operational User Handbook – Data Provider, EAD/DOC-GEKB38

31. EAD Programme, EAD Service Development, Operational User Handbook – Data User, EAD/DOC-GEKJEB9

32. EAD Oversight, EAD Service Provision, Static Data Operations Procedures Handbook, EAD/DOC-GEN2RP

33. EAD Oversight, EAD Service Provision, INO Procedures Handbook, EAD/DOC-GEN2RQ

34. EAD Oversight, EAD Service Provision, PAMS Procedures Handbook, EAD/DOC-GEN2RD

35. EAD Oversight, EAD Service Provision, Service Desk Procedures Handbook, EAD/DOC-GEN236

36. Organisational Procedures Handbook, EAD/DOC-GEK0QO

37. Operational User Handbook - Data Provider, EAD/DOC-GEKB38

38. Operational User Handbook - Data User, EAD/DOC-GEKEB9

39. Preliminary Safety Impact Study of Controlled Harmonised Aeronautical Information Network, AIM/AIP, Version 1.0, October 2004

40. EAD Safety and Security Workshop: Briefing Material, P04009.10.5, v1.0, 13 December 2004

41. EAD Safety and Security Workshop Summary Report, P04009.10.6, v1.0, 14 January 2005

42. Minutes for EAD Safety Assessment Workshop, P08013.10.3, Issue 1.0, 24 November 2008

43. CHAIN Preliminary Safety Case, DAP/NET/CHAIN/ , Issue 0.1, Working Draft, 24 October 2005

44. EAD Programme: System Architecture – Core Document, EAD/DOC-FS0241

45. Minutes for the EAD SSA Working Meeting of 21-23 September 2005, P05010.10.3, Issue 1.0, 29 September 2005

46. Functional Hazard Assessment (FHA)/Preliminary System Safety Assessment (PSSA) for Initial Flight Plan (IFP), P04002.11.3, 24 January 2005

47. Safety Analysis Report for Initial Flight Planning (IFP) Implementing Rule, DAP/SAF/SES/IOP/IFP/SAR/3.0, Edition 3.0, 25 January 2005

48. Classification of Airborne Equipment Failures, JAA JAR25-1309



49. SDO Interface Control Document (Annex D), EAD/DOC-ST0038

50. CHAIN Functional Hazard Assessment/Preliminary System Safety Assessment Report, P5007.20.2, Issue 0.2, 12 October 2005

51. Air Navigation System Safety Assessment Methodology, SAF.ET1.ST03.1000-MAN-01, 30 April 2004, Edition: 2.0

52. EAD Programme Contract Technical Specifications, DSA/EAD/861, Edition 1.0, 7 July 1999

53. AIXM Primer, AIXM_Primer_4.5.xml, Issue 4.5

54. EUROCONTROL Security Management Handbook: A Framework, Edition 1.0, May 2008

55. EUROCONTROL ICT Security Guidance Material, Edition 1.0, 19 May 2008

56. EUROCONTROL ATM Security Risk Assessment Methodology, Edition 1.0, 19 May 2008

57. SLS Review 2005 – Data Operations, EAD/DOC-GEN84P

58. Training Management Plan, EAD/DOC-GEC3R3

59. Configuration Management Plan, EAD/DOC-GE0003

60. Release 5 Planning, EAD/DOC-FRN5UI

61. Service Level Specification: Network SLS, EAD/DOC-GED820

62. EAD Service IT Services Service Level Specifications, CFMU/EAB/3494

63. EAD Generic Migration Plan, EAD/DOC-GEK0W8

64. Performance Report December 2008 (SP2), EAD/DOC-GER13F

65. IT Performance Report March 2009, EAD/DOC-FRN1YA

66. EAD Service - IT Performance Report March 2009, EAD/DOC-FRN1YA

67. EAD Service, ITP Change Management Plan, EAD/DOC-FRKEA8

68. Safety and Security Management Plan, EAD/DOC-GEKDUE

69. EAD Transition and Migration Plan for Morocco, EAD/DOC-ECNDLO

70. EAD Migration Matrix, EAD/DOC-FRLG49

71. Release Information R5, EAD-DOC-FRN41R

72. GEAD Configuration Management Database (CMDB), No reference

73. EAD System preSSA Preliminary Safety and Security Assessment for System Changes, EAD/DOC-FRN3RZ

74. EAD System Safety/Security Assessment Report for R4, EAD/DOC-ECNBGL

75. EAD Service Report of the Assessment and Verification of EAD Release 5, EAD/DOC-FRR2AI

76. Test Database, TestDB, No reference

77. CM/QM Baseline Report for Baseline R5, EAD/DOC-FRR2F7

78. Safety and Security Assessment Report for Introduction of the EAD Briefing Facility, EAD-DOC/FRNDUG

79. Business Continuation Plan, EAD/DOC-GEK9SJ

80. IT Service Continuity Management Plan, EAD/DOC-FRR1KA

81. Technical Procedures Handbook, EAD/DOC-FRKA3Z



82. Preliminary HW and LAN Design, EAD/DOC-FRC0LW

83. Migration Management Plan, EAD/DOC-GEK0W8

84. Operating Procedures for AIS Dynamic Data (OPADD), AIS.ET1.ST05.1000-DEL-01, Edition 1.0, 31 January 2000

85. AIS Data Process, AIM/AEP/ADP, Edition 1.0, 16 December 2005

86. System Safety Assessment (SSA) Report for EAD Release 4, EAD/DOC-FRN5UI