EAIMS - Eurocontrol · NMOC NM EAD FHA Hazard Objectives ... NMD SQS; iMS/POL/SMS-SMC; version 2 ... EAIMS will certainly bring about changes which modify the way people interact

EAIMS

PRELIMINARY SYSTEM SAFETY ASSESSMENT OF THE

EUROPEAN ATM INFORMATION MANAGEMENT

SERVICE (EAIMS)

Edition Number : 1.0

Edition Date : 01/09/2016

Status : Released Issue

Intended for : EUROCONTROL

PSSA Report - EAIMS

Page 2 Released Issue Edition: 1.0

DOCUMENT CHARACTERISTICS

TITLE

PRELIMINARY SAFETY SYSTEM ASSESSMENT – EAIMS

Publications Reference:

ISBN Number:

Document Identifier Edition Number: 1.0

Preliminary System Safety Assessment – EAIMS

Edition Date: 01/09/2016

Abstract

This document presents the results of the high-level Preliminary System Safety Assessment for EAIMS:

Eight Consolidated Failure Modes were identified

Seventy-five Safety Recommendations were made to address the failure modes.

Keywords

Centralised Service CS5 EAIMS Safety Case

Requirement Assessment AIM AIS

NMOC NM EAD FHA

Hazard Objectives PSSA

Contact Person(s) Tel Unit

Anthony F. Seychell +32 2 729 3721 NMD/NOM/SAF

STATUS, AUDIENCE AND ACCESSIBILITY Status Intended for Accessible via

Working Draft � General Public � Intranet �

Draft � EUROCONTROL � Extranet �

Proposed Issue � Restricted � Internet (www.eurocontrol.int) �

Released Issue � This document is copyright protected. It may be cop ied in whole or in part by the recipients for their own purposes strictly related to the support of the development of Centralised Services by EUROCONTROL. All copies shall display the following notice "© EUROCONTROL 2016". Any commercial use of the document or its contents, the ir use for purposes other than specified in this notice, as well as their distribution to third part ies is strictly prohibited.

PSSA Report - EAIMS

Edition: 1.0 Released Issue Page 3

DOCUMENT AUTHOR

AUTHOR NAME AND SIGNATURE DATE

Senior Safety Expert

NMD/NOM/SAF

Anthony F. Seychell

19/08/2016

DOCUMENT APPROVAL

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

AUTHORITY NAME AND SIGNATURE DATE

Project Manager

CS5 Razvan Margauan

Programme Manager

Herman Baret

Director Network Manager

Joe Sultana

22.09.2016

22.09.2016

22.09.2016

PSSA Report - EAIMS


DOCUMENT CHANGE RECORD

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

EDITION NUMBER

EDITION DATE REASON FOR CHANGE PAGES AFFECTED

0.1 7/03/2016 Working draft for review ALL

0.2 11/05/2015 Proposed issue following comments leading to minor amendments Pages 11, 27

0.3 19/08/2016 Second Proposed Issue following comments after additional review ALL

1.0 01/09/2016 Update in the light of the preparation of the launch of the CS5 Call For Tenders ALL

Publications

EUROCONTROL Headquarters

96 Rue de la Fusée

B-1130 BRUSSELS

Tel: +32 (0)2 729 4715

Fax: +32 (0)2 729 5149

E-mail: [email protected]

PSSA Report - EAIMS


CONTENTS

DOCUMENT CHARACTERISTICS ............................................................................ 2

DOCUMENT AUTHOR ............................................................................................... 3

DOCUMENT APPROVAL .................................. ........................................................ 3

DOCUMENT CHANGE RECORD .............................................................................. 4

CONTENTS ................................................................................................................ 5

EXECUTIVE SUMMARY ............................................................................................ 7

CHAPTER 1 – INTRODUCTION ................................................................................ 91.1 Purpose .................................................................................................................. 91.2 Structure of the risk assessment ......................................................................... 91.3 Completeness and correctness of the PSSA process ...................................... 101.4 Software Assurance ............................................................................................ 101.5 Procedure Assurance ......................................................................................... 111.6 Terminology ......................................................................................................... 12

CHAPTER 2 – PSSA ACTIONS ............................................................................... 132.1 Objective .............................................................................................................. 132.2 PSSA Activities .................................................................................................... 142.2.1 PSSA#1 ................................................................................................................ 142.2.2 PSSA#2 ................................................................................................................ 152.2.3 PSSA#3 ................................................................................................................ 162.2.4 Outcome of PSSA Meetings ............................................................................... 17

CHAPTER 3 – PSSA RESULTS .............................................................................. 183.1 Overview .............................................................................................................. 183.2 Failure modes ...................................................................................................... 183.3 Safety Requirements ........................................................................................... 20

CHAPTER 4 – CONCLUSION ................................................................................. 26

Annex A – SAFETY REQUIREMENTS TRACEABILITY TABLES .. ....................... 27FH-01 Data Corruption Failure modes, Causal Factors and Potential Causal Mitigations

and Safety Requirements ................................................................................... 27FH-02 Data Unavailability Failure modes, Causal Factors, Potential Causal Mitigations

and Safety Requirements ................................................................................... 31FH-03 Data Discrepancy Failure modes, Causal Factors, Potential Causal Mitigations and

Safety Requirements ........................................................................................... 33

Annex B - MEETINGS AND PARTICIPATION ........................................................ 37

PSSA Report - EAIMS


Annex C – ABBREVIATIONS AND ACRONYMS ................................................... 39

Annex D – REFERENCES ....................................................................................... 41Regulations ................................................................................................................... 41EUROCONTROL Documents ....................................................................................... 41

Figure 1 Latest EAIMS high-level architecture diagram .................... .........................................14

Table 1 Additional considerations in relation to FH-02 Data Unavailability ............................ 16Table 2 Functional Hazards and Failure Modes ........................................................................ 18Table 3 Consolidated Failure Modes ......................................................................................... 19Table 4 Functional Level Hazards/Safety requirements traceability table .............................. 20Table 5 Safety requirements/Consolidated Failure Modes traceability table.......................... 25Table 6 Data Corruption Failure Modes, Causal Factors, Potential Causal Mitigations and

Safety Requirements Traceability Table ............................................................................ 30Table 7 Data Unavailability Failure modes, Causal Factors Potential Causal Mitigations and

Safety Requirements Traceability Table ............................................................................ 32Table 8 Data Discrepancy Failure Modes, Causal Factors Potential Causal Mitigations and

Safety Requirements Traceability Table ............................................................................ 36

PSSA Report - EAIMS


EXECUTIVE SUMMARY

The aim of this safety activity was to determine the safety requirements for European ATM Information Management System (EAIMS) needed to meet the safety objectives specified in the Functional Hazard Assessment Report. Fourteen failure modes were found which could lead to the three functional level hazards identified in the FHA. Some of these failure modes were common to two hazards and were eventually consolidated into eight consolidated failure modes.

At present there are only very high-level descriptions of the system architecture mainly because it will be up to the successful bidder of the CS5 Call For Tenders (CFT) to design in detail the EAIMS/CS5 system, taking into account the technical and architectural requirements set in the CFT. Thus the current lack of detail is a severe constraint when it comes to specifying the safety requirements. Therefore at this phase of the project it is not feasible to establish detailed safety requirements since the knowledge/information about the system architecture is limited.

Despite this constraint it was still possible to draw up seventy five generic/high-level safety recommendations to address the failure modes identified. These safety requirements, although generic/high-level, should assure adequate initial mitigation of the safety risk associated with the CS5 operations prior to the comprehensive system design since these safety requirements shall be part of the CFT documentation.

PSSA Report - EAIMS


Intentionally blank

PSSA Report - EAIMS


CHAPTER 1 – INTRODUCTION

1.1 Purpose This report presents the results of the Preliminary System Safety Assessment (PSSA) activities carried out in the period December 2015 – March 2016. The report was updated in August 2016 to align it with the final version of the EAIMS CONOPS and CFT documentation.

The information contained in this report presents the main output of the EAIMS safety assessment activities and provides the main safety related input to the subsequent EAIMS/CS5 CFT, validation activities and implementation safety assessments.

The report should eventually serve as a reference to the Network Manager, the ANSPs and AISPs regarding the potential means to control the risk associated to the introduction of EAIMS in terms of mitigation of severity of hazard effects and/or reduction of frequency of their occurrence. The information contained in this report shall be reviewed and validated (optimised) for use by the NM/ANSPs/AISPs according to the particular operational environments, i.e. taking into account local systems and their functional capabilities, procedures, units staffing levels and traffic complexity.

1.2 Structure of the risk assessment Chapter 1 provides an introduction to the PSSA by defining its purpose.

Chapter 2 details the safety activities performed and the outcome of the various safety workshops.

Chapter 3 presents the main findings and lists the derived safety requirements.

Chapter 4 presents the conclusions of the PSSA.

Annex A contains tables providing forward and backward traceability between hazards, failure modes, causal and consequential mitigations, and derived safety requirements.

Annex B provides a list of participants in the various PSSA workshops.

Annex C provides a list of abbreviations and acronyms.

Annex D provides a list of referenced documents.

PSSA Report - EAIMS


1.3 Completeness and correctness of the PSSA process This PSSA process follows to the prescriptions of the NM change management procedure1 and the mandated requirements of the “Common Requirements”2..

In addition to the project team, in-house subject matter experts attended the PSSA sessions and provided their inputs. A full list of participants to these meetings is shown as Annex B.

The PSSA report has been subject to sanity checks and reviews based on results of safety assessment conducted for similar functions and projects (CHAIN, EAD, ADR) ensuring the completeness and correctness of the failures modes and hazards identified.

It is to be noted that this document will be subject to update as needed during the subsequent stages of the safety assessment and the overall project.

1.4 Software Assurance ICAO Annex 15 defines data quality as a degree or level of confidence that the data provided meet the requirements of the data user in terms of accuracy, resolution and integrity. One of the aims of the EAIMS safety assessment is to ensure that EAIMS does not degrade the data quality since this degradation would adversely affect the safety of flight.

Integrity of data must be assured throughout the whole data chain, but accuracy and resolution requirements may only be met at the point of origination of the data. Subsequent to this, a loss of integrity would result in the accuracy and resolution requirements no longer being complied with.

EAIMS will certainly lead to more automated AIS/AIM processes which will bring about an increased reliance on software. Whilst this will assist in increased consistency of data currently used in different systems, in the reduction of human errors and, hence, aid an overall reduction in concerns regarding data quality, it could result in a transfer of risk from humans to the software used. Therefore it is evident that there is a need to closely control the use of this software, to ensure that the risk posed to a loss of data quality is reduced to as low as reasonably practicable.

Software systems offer huge flexibility but a complex system of complex systems such as EAIMS will have different software categories based on the functionality of the software being used. In ATM safety assessments, as a rule, the requirement is to have the ATM software assured at SWAL 4 at least.

At this stage of the safety assessment of EAIMS the boundaries of the system and the use cases have been defined whereas the system architecture is known only at a high level while the internal architecture of the EAIMS/CS5 is unknown. It will be hard to define the required SWAL for the various software categories that will eventually be part of EAIMS because verifiability depends on the decomposition of the system into verifiable elements. Still safeguards must be put in place to ensure that the risk posed by these software systems is controlled. Thus the successful tenderer must perform all the steps necessary to demonstrate that any software used for the support or automation of aeronautical data and information processing is adequately qualified as fit for purpose. The need to ensure robust software is particularly applicable to the support and processing software used for critical and essential data items. Thus the software assurance level (SWAL) shall be commensurate with the required data quality, but certainly not less than SWAL 4.

1 Safety Management of Changes to Functional Systems; NMD SQS; iMS/POL/SMS-SMC; version 2.0; 2013-12-09

2 EU 1035/2011 “Commission Implementing Regulation (EU) No 1035/2011 of 17 October 2011 laying down common requirements for the provision of air navigation services and amending Regulations (EC) No 482/2008 and (EU) No 691/2010”

PSSA Report - EAIMS


1.5 Procedure Assurance EAIMS will certainly bring about changes which modify the way people interact with the rest of the functional system. Consequently they will require training before the change becomes operational. People may also need refresher training periodically in order to ensure that their performance does not degrade over time. The training needed before operation forms part of the design of the change, while the refresher training is part of the maintenance of the functional system after the change is in operation.

The introduction of EAIMS will thus lead to the development of new procedures which also need to be assessed to ensure that the risk of failure is controlled. It has to be pointed out that a procedure does not fail per se. In this case “failure” is to be understood in a wider sense where roles or tasks are not adequately captured, procedure is misapplied, unclear or ambiguous, etc.

The use of procedure assurance levels (PAL) will be helpful in generating an appropriate and sufficient body of evidence, which in turn may help to establish the required confidence in the argument that the EAIMS procedures are safe. For ATM procedures, a minimum of PAL 4 is normally specified. An equivalent PAL for the EAIMS procedures will certainly need to be attained.

At this stage of the project, EAIMS procedures still do not exist and their development will begin only once the system has been fully designed and the transition plan developed. All the same the successful EAIMS contractor has to ensure that the EAIMS procedures are defined, designed, written, validated, implemented, transferred and operated effectively to demonstrate that these procedures achieve the level of assurance required to meet the necessary levels of risk in AIS/AIM. Thus the procedure assurance level (PAL) shall be commensurate with the required data quality. Some of the safety requirements already address indirectly the PAL requirements e.g. SR4, SR27, SR32 and SR35. Additionally the Functional Technical Specifications have included other requirements which imply that the successful tenderer has to ensure:

� Involvement of the relevant subject matter experts,

� A minimum set of quality assurance activities,

� Establishment of a proven and well-documented starting point for the definition phase,

� Assessment of the HMI,

� Suitable design validation at different levels.

Consequently, such requirements indirectly guarantee a level of assurance with respect to procedure design and use equivalent to PAL 4 or better.

PSSA Report - EAIMS


1.6 Terminology

B2B Services

services delivered via a computer to computer interface.

One system will interact with another system via services. Services are made available via a set of APIs (Application Programming Interface) that a software developer has to use to make his own system inter-operate with the other system.

B2C Services

services delivered via an HMI, targeted for human interaction.

An end user can interact with the system via a client application. The client application interacts via services with the system.

CS5 Contractor

a consortium composed of ANSPs and other industrial partners which will be entrusted with the development of the EAIMS/CS5 system and its operations as outcome of the CS5 Call For Tenders process under the EUROCONTROL procurement rules.

Data

for the purpose of the safety assessment, ‘data’ is considered to encompass not only AIS data or any other representation of facts, concepts or instructions in a formalised manner suitable for communication, interpretation or processing by the EAIMS/CS5 but also products such as AIS products (e.g. aeronautical charts and AIPs).

EAIMS the complete European ATM Information Management Service managed under the auspices of EUROCONTROL as the Network Manager, irrespective of outsourced/insourced components and services.

EAIMS/CS5

the system which will be contracted (subject of the CS5 Call For Tenders (CS5/CFT)) for development and operation and will be the reference source for the AIS and ATFCM/ASM data (e.g. managing the reference source) and a central access point for aircraft type characteristics and performance data and MET and natural hazards data in support of flight operations.

adaptations to NM systems

adaptations to the existing NM CACD and other NM systems. The CACD system remains in a first implementation step the reference source for the ATFCM and dynamic ASM Data being later integrated in EAIMS/CS5.

System a combination of: physical components (hardware, equipment), procedures (manuals, guidelines, software) and human resources

PSSA Report - EAIMS


CHAPTER 2 – PSSA ACTIONS

2.1 Objective The EUROCONTROL Air Navigation System Safety Assessment Methodology defines the objectives of a Preliminary System Safety Assessment (PSSA) as:

Preliminary System Safety Assessment (PSSA) is a mainly top-down iterative process, initiated at the beginning of a new design or modification to an existing design of an Air Navigation System. The objective of performing a PSSA is to demonstrate whether the assessed system architecture can reasonably be expected to achieve the Safety Objectives specified in the FHA.

The PSSA process apportions Safety Objectives into Safety Requirements allocated to the system elements, i.e. specifies the risk level to be achieved by the system elements. PSSA also identifies an Assurance Level per system element.

The system architecture can only achieve the Safety Objectives established during the FHA, provided the architecture elements meet their Safety Requirements.”

The aim of the PSSA is thus to determine the safety requirements for EAIMS needed to meet the safety objectives specified in the Functional Hazard Assessment Report. At this stage only a high-level PSSA can be performed because the detailed system architecture would be available only after a contractor had been chosen.

Several workshops were held to analyse the functional level hazards identified in the PSSA and elaborate an initial Failure Mode and Cause Analysis. The objectives of these workshops were:

� Ensure correctness and completeness of FHA Results –

• Are the failure modes correct and complete?

• Are the barriers correct and all applicable barriers identified?

• Are the mitigation means correct and what other mitigation means can be put in place?

� Are there links between the Functional Level Hazards?

� Are the Failure Modes linked?

� Identify split between the contracted system elements subject of the CFT and the adaptations to NM systems in order to be able to specify the high-level requirements applicable to the CFT scope of work.

As requirements were being developed in parallel with PSSA the EAIMS high-level architecture diagram was reviewed after each subsequent PSSA workshop. The final version is shown in the following figure (Figure 1).

PSSA Report - EAIMS


Figure 1 EAIMS high-level architecture diagram

2.2 History of PSSA Activities Three internal PSSA workshops were organised to analyse and assess the Functional Level Hazards identified in the FHA. Additional ad-hoc meetings were also held either to prepare for the workshops or to analyse the output from such workshops to be able to eventually draw up the safety requirements.

2.2.1 PSSA#1

The first version of the EAIMS high-level architecture diagram was used during PSSA#1 to analyse the relationships between the various actors.

During the meeting there were two clarifications regarding the diagram used:

a. AIMSL is the current EAD B2B technology which some AISPs may opt to continue using toprovide/retrieve data to the CS5 database. This system would not use the N-Conect servicelayer and it would not be able to access all the EAIMS services.

b. External Systems could be COTS systems e.g. Charting Tool, AIP Production Tool, whichwould need data from CS5 to operate.

Another clarification made during the meeting concerned the use of the term ‘data’. For the purpose of the PSSA, ‘data’ is considered to encompass not only AIS data or any other representation of facts, concepts or instructions in a formalised manner suitable for communication, interpretation or processing by the CS5 system but also products such as AIS products (e.g. aeronautical charts and AIPs).

PSSA Report - EAIMS


During the FHA brainstorming session there were many issues which were identified as ‘hazards’ but which were actually ‘failure modes’. These failure models were compiled in an exercise before the meeting and presented to the meeting participants.

Using the available architecture diagram the group then analysed the failure modes following the data paths back to the CS5 system. During this analysis it was realised that data flow between CS5 and NM systems will be only via N-Conect Service Layer. Consequently the direct link between CS5-CFT and NM systems is incorrect because this data path will not exist.

Another consideration that arose from this analysis was if CS5 would provide a service similar to the current EAD Basic, which is EAD's free Public Access Service application for the general public. The solution allows the general public to browse the European AIS Database for a limited set of aeronautical information via a Web Browser. This service will be part of the CFT and is part of the use cases. During the meeting it was not possible to check if such a service would be out of scope of the safety assessment or if a simple disclaimer regarding the use of the data from CS5 would be sufficient mitigation. This matter regarding the provision of such a service would need to be considered at a project management level and the legal consequences subsequently analysed.

The first activity of the PSSA was to go through the failure modes associated with the first functional hazard, data corruption, and identify causes. This first workshop established several causes which could lead to Data Corruption. This exercise was repeated for the other two functional level hazards.

2.2.2 PSSA#2

“FH-02 Data Unavailability” was assessed during PSSA#2 based on a new version of the EAIMS high-level architecture which had been amended following the observations made during PSSA#1.The assessment was run in a systematic way, following the path of the information, starting from the end-users/CS5-customers.

During the analysis the following additional considerations were raised.

Function Consideration/Comment

Users/Customers’ Local level

Access rights, authentication, proxy settings and minimal local computers configuration need to be defined.

N-Connect

i. As this equipment in central not only to CS5 it may be required to run acommon cause analysis understanding the potential impact on thedifferent services using this equipment.

ii. Assumption: N-Connect is also providing support to flight planningservices. CS5 is considered less critical than flight planning services.Therefore, the N-Connect reliability is considered to be sufficient for CS5uses.

CS5 The DB is cached in N-Connect.

AIS Systems Only parts of the overall data provision; complementing the other sources (incl. B2B, external systems).

AIP/Charts (COTS)

i. What is foreseen in terms of AIS library management?

ii. Is the management tool part of CS-5? Would it be COTS?

iii. Are some requirements foreseen for required minimum configuration oflocal computers? Minimum number of computer equipped on site?(more over if a dedicated tool/SW needs to be installed, incl.

PSSA Report - EAIMS


Function Consideration/Comment

authentication/licence)

CS5-Operators

i. Each working position can handle any task.

ii. Shifts ensuring 24/7.

iii. Sufficient number of working positions.

iv. Different sites.

v. In case no operator can update the data, the customers will haveincomplete or outdated data.

vi. NM systems, can be directly updated (assuming the data is available byan alternative mean) by NM/ADS operators.

vii. Need for mitigations for the customers, contingency planning?

viii. How will NM-CSO/Service desk be used in the future? Does it have thestaff, capability and tools to manage this kind of situation?

External systems

i. External systems are data providers and users Interacting via B2B

ii. In case they cannot prepare/send their data sets (e.g. NOTAM); theycan send (fax, email, telephone) and request (via CSO/service desk) thedata set to be published by CS5 operators.

Table 1 Additional considerations in relation to FH-02 Data Unavailability

The second PSSA workshop established several causes which could lead to Data Unavailability. It is still necessary to identify fully the barriers and mitigation means already in place in order to draw up effective safety requirements.

2.2.3 PSSA#3

The agenda of the third PSSA workshop was:

� Introduce the EAD-CS5 migration plan,

� Analyse FH03 ‘data discrepancy’,

� Review FH01 and FH02 in the light of the migration,

� Examine the barriers and mitigations to ensure their completeness and correctness.

Migration

The PSSA looks into the operational requirements but the design of the system needs to take into consideration specific requirements for migration. This is not considered during the FHA because the functionality is not affected by migration. Although the hazards might be the same, the causes could be different during the migration phase.

A draft migration plan was presented during the meeting and in the CFT there will be a requirement for the contractor to develop the migration plan. The draft plan will be included in the CFT documentation.

The discussion of the migration plan became quite detailed. Eventually it was felt that the discussion was going beyond the scope of the PSSA. Dedicated safety meetings were deemed necessary to look into the migration issues.

PSSA Report - EAIMS


FH03 Data Discrepancy

The meeting participants started to analyse FH03 ‘data discrepancy’. This functional hazard was assessed based on the proposed architecture diagram used previously during PSSA #2,. After the initial analysis this data-users diagram was considered not to be ideal for the assessment of data discrepancy, a situation which was recognised in the preparation of the meeting and actually debated in an ad hoc meeting held on 14th January 2016. The assessment proceeded by examining the possible causes as identified during the FHA that could lead to data discrepancy. The assessment was refined in post-workshop analysis.

2.2.4 Outcome of PSSA Meetings

The outcome of all three PSSA meetings was similar since all of them resulted in the identification of various failure modes. A subsequent review of the results of these meetings led to a consolidation of the common modes since many were the same for two functional hazards. The failure modes and subsequent safety requirements are presented in the following chapter.

PSSA Report - EAIMS


CHAPTER 3 – PSSA RESULTS

3.1 Overview Fourteen failure modes were identified as a result of the PSSA workshops. However there was duplication since a particular failure mode can lead to more than one functional level hazard. Subsequently the failure modes were consolidated into a group of eight.

3.2 Failure modes The following table lists the failure modes that could lead to particular functional level hazards.

Hazard ID FH-01 Data Corruption FH-02 Data Unavailability FH-03 Data discrepancy

Failure Modes

FM-FH01 i. Corrupted data

FM-FH01 ii. Incorrect data

FM-FH01 iii. Errors

FM-FH01 iv. Non removal of obsolete data

FM-FH01 v. Reverse after passing effective date (cancellation of updates after publication)

FM-FH02 i. Missing data

FM-FH02 ii. Failure

FM-FH03 i. Corrupted data

FM-FH03 ii. Wrong interpretation of data

FM-FH03 iii. Incorrect data

FM-FH03 iv. Errors

FM-FH03 v. Non removal of obsolete data

FM-FH03 vi. Reverse after passing effective date (cancellation of updates after publication)

FM-FH03 vii. Missing Data

Table 2 Functional Hazards and Failure Modes

PSSA Report - EAIMS


Consolidated Failure Modes (CFM)

Functional Hazard ID and Failure Modes

FH-01 Data Corruption FH-02 Data Unavailability FH-03 Data discrepancy

CFM-01 Corrupted data FM-FH01 i Corrupted data FM-FH03 i Corrupted data

CFM-02 Incorrect data FM-FH01 ii Incorrect data FM-FH03 iii Incorrect data

CFM-03 Errors FM-FH01 iii Errors FM-FH03 iv Errors

CFM-04 Non removal of obsolete data

FM-FH01 iv Non removal of obsolete data

FM-FH03 v Non removal of obsolete data

CFM-05 Cancellation of updates after publication

FM-FH01 v Reverse after passing effective date (cancellation of updates after publication)

FM-FH03 vi Reverse after passing effective date (cancellation of updates after publication)

CFM-06 Missing data FM-FH02 i Missing data FM-FH03 vii Missing Data

CFM-07 Failure FM-FH02 ii Failure

CFM-08 Wrong interpretation of data

FM-FH03 ii Wrong interpretation of data

Table 3 Consolidated Failure Modes

PSSA Report - EAIMS


3.3 Safety Requirements The EAIMS safety assessment addresses the whole of the EAIMS because for the user the source of EAIMS information is transparent. Most of the safety requirements apply to all EAIMS data. However, a number of them address only AIS data (subject to ADQ). In such cases this is clearly stated to distinguish between the AIS data and EAIMS data which cover all types, including AIS data, aircraft type characteristics and performance data, MET and natural hazards data in support of flight operations, ATFCM and dynamic ASM Data. Additionally a few of the safety requirements actually address the Data Users/Data Providers because an SLA with the DU/DP where there would be DU/DP requirements is still part of the EAIMS/CS5 system.

At this phase of the EAIMS project it is not feasible to establish detailed safety requirements since the knowledge/information about the system architecture is limited. This consideration is of particular importance when it comes to specifying software safety requirements and integrity safety requirements. Such requirements can only be established at a later stage when information is available about the particular EAIMS system architecture and needed potential hardware and/or software changes can be established.

A review of the proposed safety requirements indicates that a good proportion of the proposed Safety Requirements address all three identified Functional Level Hazards (see Table 4). For greater transparency, Table 5 links the safety requirements with the consolidated failure modes.

The table below maps the Functional Level Hazards against the Safety Requirements.

Functional Hazard ID SR No.

FH-01 Data Corruption

SR1, SR2, SR3, SR4, SR5, SR6, SR7, SR8, SR9, SR10, SR11, SR12, SR13, SR14, SR15, SR16, SR17, SR18, SR20, SR21, SR22, SR23, SR24, SR25, SR27, SR28, SR32, SR34, SR36, SR40, SR42,SR43, SR44, SR45, SR46, SR47, SR48, SR49, SR50, SR51, SR52, SR53, SR55, SR56, SR59, SR60, SR61, SR62, SR63, SR64, SR65, SR66, SR67, SR68, SR70, SR71, SR72, SR73, SR74, SR75.

FH-02 Data Unavailability

SR1, SR2, SR3, SR5, SR6, SR7, SR8, SR9, SR13, SR14, SR15, SR19, SR20, SR21, SR22, SR23, SR24, SR25, SR26, SR28, SR29, SR30, SR31, SR32, SR33, SR34, SR35, SR36, SR37, SR38, SR39, SR40, SR41, SR42, SR43, SR45, SR46, SR47, SR48, SR49, SR50, SR51, SR52, SR53, SR54, SR55, SR56, SR57, SR58, SR62, SR65, SR67, SR68, SR69, SR70, SR71, SR72, SR73, SR74, SR75.

FH-03 Data Discrepancy

SR1, SR2, SR3, SR4, SR5, SR6, SR7, SR8, SR9, SR10, SR11, SR12, SR13, SR14, SR15, SR16, SR17, SR18, SR19, SR20, SR21, SR22, SR23, SR24, SR25, SR26, SR27, SR28, SR32, SR34, SR39, SR40, SR41, SR42, SR43, SR44, SR45, SR46, SR47, SR48, SR51, SR52, SR53, SR54, SR56, SR57, SR58, SR59, SR60, SR61, SR62, SR63, SR64, SR65, SR66, SR67, SR68, SR69, SR70, SR71, SR72, SR73, SR74, SR75.

Table 4 Functional Level Hazards/Safety requirements traceability table

PSSA Report - EAIMS


The following table details the Safety Requirements and maps them against the relevant Consolidated Failure Modes.

SR No. Safety Requirements Consolidated Failure Mode

SR1 Ensure that appropriate reference manuals, guidelines and use procedures exist for Data Users and Data Providers.

CFM-01, CFM-02, CFM-03, CFM-04, CFM-05, CFM-06, CFM-07, CFM-08

SR2 Validate that the appropriate reference manuals, guidelines and use procedures provide adequate support to Data Users and Data Providers.


SR3 Ensure that appropriate reference manuals, guidelines and use procedures are made available to users (e.g. by means of dedicated meetings with the operators).


SR4 Ensure that the reference manuals, guidelines and use procedures are subject to strict document configuration control.

CFM-03

SR5 Implement and keep current mechanisms to defeat deliberate security attacks. CFM-01, CFM-02, CFM-06

SR6 Ensure a process for reporting of technical and operational problems. CFM-01, CFM-02, CFM-03, CFM-04, CFM-05, CFM-06, CFM-07

SR7 Take appropriate measures (testing, monitoring, controls, data validation) to ensure that data is correct and up-to-date.

CFM-01, CFM-02, CFM-03, CFM-04, CFM-05, CFM-06

SR8 Notify EAIMS Data Users of any known deficiencies in EAIMS data, including situations where the timeliness requirements cannot be achieved.

CFM-01, CFM-02, CFM-06, CFM-07

SR9 Ensure that the incident management process provides sufficient support for the reporting and correction of erroneous EAIMS data observed by Data Providers or Data Users.

CFM-01, CFM-02, CFM-06

SR10 Put in place a process by which the Data Users or Data Provider can report errors identified in the EAIMS data. The process shall ensure that corrective actions are defined and implemented.

CFM-03

SR11 Provide facilities for feedback of user-identified errors in EAIMS data to the responsible Data Provider. CFM-03

SR12 Inform Data Providers of any identified or suspected errors in their data. CFM-03

SR13 Ensure that procedure(s) exist for continuous update of the system with applicable constraints and issued to users (e.g. to avoid incorrect data, errors, missing data and wrong interpretation of data).


SR14 Ensure that procedure(s) exist for timely update distribution. CFM-02, CFM-04, CFM-06

SR15 Ensure that a procedure or mechanism exists for consistent database update upon any change of data. CFM-02, CFM-04, CFM-06

PSSA Report - EAIMS



SR16 Ensure that the CS5-Contractor does not alter the Original AIS data from any Data Provider without informing the Data Provider of the change and endeavouring to receive concurrence in a timely manner.

CFM-02

SR17

Ensure that the CS5-Contractor does not transmit altered Original AIS data to Data Users if the Data Provider has rejected the alteration, unless it is clearly noted that the Data Provider does not concur with the alteration (noting that in some extreme situations a change must be introduced in EAIMS to make the CS5-Contractor system function correct and safe).

CFM-02

SR18 Keep records of all alterations and records shall be made available to Data Users upon their request. CFM-02

SR19 Ensure that AIS data from non-migrated data providers is collected, validated and entered into the EAIMS database in a timely manner.

CFM-06

SR20 Ensure that the CS5-Contractor verification of EAIMS AIS data is independent of any EAIMS Data Provider checks and include checks against specified and agreed format rules, boundary values, completeness and other sensibility checks, including those in ICAO Annex 15. Such validation should where possible be automated.


SR21 Verify data from non-B2B users before releasing the data to or making the data available through the EAIMS database.


SR22 Ensure the correct processing of NOTAMs covering dynamic changes to airspace within the timeliness requirement for the particular aspects after notification by the Data Provider responsible (only in so far the NOTAMs cover data to be published through the EAIMS Service).


SR23 Conduct an independent and comprehensive check (a General Review) of all data released through EAIMS by a Data Provider.


SR24 Verify all EAIMS data against defined business rules before it is released to the Data Users through EAIMS. CFM-02, CFM-03, CFM-04, CFM-05, CFM-06

SR25 Check the consistency of boundary data for adjacent States (States not included in the EAIMS/CS5 data). CFM-02, CFM-06

SR26 Ensure that a procedure is established for the appropriate role to verify that the EAIMS data is correct and complete.

CFM-06, CFM-07

SR27 Ensure that Data Providers only allow suitable trained operators to update data used by the EAIMS e.g. via an SLA.

CFM-03

SR28 Confirm that Data Providers ensure the completeness and correctness of data entered into EAIMS e.g. through Data Provider requirements in SLAs.

CFM-02, CFM-03, CFM-04, CFM-05, CFM-06

PSSA Report - EAIMS



SR29

Put in place a strategy to notify end-users in cases where local user systems cannot be updated with EAIMS Data due to malfunctions of the EAIMS (loss of service or delayed response). The strategy shall define which notification shall be managed locally (lack of reply to a query) or by the EAIMS Service (notification of service windows, technical malfunctions, etc.).

CFM-07

SR30 Ensure a process for failure detection and recovery. CFM-07

SR31 Ensure that sufficient and appropriate contractor staff is available to support EAIMS/CS5 service. CFM-07

SR32 Confirm that CS5 Contractor staff assigned to perform data processing has the necessary skills, competencies, and knowledge of the procedures.

CFM-03, CFM-07

SR33 Ensure that procedure(s) exist for manual data upload/download in case of loss of the corresponding automated service.

CFM-07

SR34 Ensure that contingency procedures exist for provision of data in case of loss of data. CFM-05, CFM-06, CFM-07

SR35 Develop robust procedures for manual transfer of aeronautical information between the Data Providers and the EAIMS in case of loss of the corresponding automated service.

CFM-07

SR36 Implement procedure for suspension and resumption of EAIMS, including notification to users. CFM-01, CFM-02, CFM-06, CFM-07

SR37 Ensure that the CS5-Contractor stores the backup data in a separate physical location. CFM-07

SR38 Ensure a process for the development of commands to ensure safe operation, recovery from backup in case of software crash.

CFM-07

SR39 Define and implement contingency management and coordination procedures in the event of resource overload. CFM-06

SR40 Ensure that the CS5-Contractor provides facilities and services for the storage of EAIMS/CS5 data for tracing and archiving purposes (note regulatory requirements specify data shall be stored for 5 years).


SR41 Ensure, as far as reasonably practicable, that EAIMS systems are fail safe (i.e. shall not appear to be working when they are not).

CFM-07

SR42 Ensure alerting in the case of detected corrupted data, incorrect data, errors, non-removal of data, cancellation of updates after publication or missing data.


SR43 Ensure system support for graphical presentation at user HMI. CFM-03, CFM-06, CFM-08

SR44 Ensure system support for generation of correct user-request messages. CFM-03, CFM-05, CFM-08

SR45 Ensure that data and parameters are tuned and optimised by means of dedicated input and validation procedure. CFM-01, CFM-02, CFM-03, CFM-06

SR46 Ensure system support for monitoring and update, and alerting of detected corrupted data, incorrect data, CFM-01, CFM-02, CFM-04,

PSSA Report - EAIMS



obsolete data and cancellation of data after publication or missing data. CFM-05, CFM-06

SR47 Assess the need of system support tools at validations. CFM-01, CFM-02, CFM-04, CFM-05, CFM-06

SR48 Validate the effectiveness of the available tools. CFM-01, CFM-02, CFM-03, CFM-04, CFM-05, CFM-06, CFM-08

SR49 Ensure that tools are appropriate to the environment of operations and available to users. CFM-03, CFM-06, CFM-08

SR50 Ensure system support for easy-to-comprehend presentation of HMI. CFM-03, CFM-04, CFM-05, CFM-06, CFM-08

SR51 Ensure that changes are validated before upload to the operational system. CFM-02, CFM-03, CFM-04, CFM-05, CFM-06

SR52 Perform a specific EAIMS/CS5 validation session prior to operational deployment to validate that the service works appropriately.


SR53 Ensure that change notification procedures and/or SLAs are appropriate to the environment of operations. CFM-02, CFM-04, CFM-05, CFM-06

SR54 Implement a process to build and maintain the Interoperability (IOP) Data to close the gap between AIS and operational users.

CFM-06

SR55 Ensure complete and consistent IOP Data. CFM-02, CFM-04, CFM-05, CFM-06

SR56 Implement EAIMS release management process. CFM-03, CFM-04, CFM-05, CFM-06

SR57 Maintain the World Wide and non-migrated states data in EAIMS/CS5 according to the data and geo scope defined in the EAIMS Data Catalogue..

CFM-06

SR58 Ensure continuity of the services currently provided by Group EAD to EAD clients. CFM-06

SR59 Ensure a process to prevent updating Annex 15 IOP AIRAC data set after cut-off date after the NM cut-off date unless approved by the relevant Customer Authority.

CFM-02

SR60 Implement a procedure not to accept AIRAC updates in the Annex 15 IOP data after the NM cut-off date unless approved by the relevant Customer Authority.

CFM-02, CFM-04

SR61 Prevent unauthorised update of data from external sources. CFM-02, CFM-05

SR62 Allow Data Providers to update only data which they are responsible to provide. CFM-02, CFM-05, CFM-06

PSSA Report - EAIMS



SR63 Confirm that Data Providers ensure that any effective dates associated with CS5 data are entered correctly or that data are allocated to the correct AIRAC cycle.

CFM-02

SR64 Ensure that the B2B interfaces are compliant with the international data exchange models (AIXM, WXXM, and FIXM) and with the Aeronautical Information Reference Model (AIRM) and Information Services Reference Model (ISRM).

CFM-02, CFM-04

SR65 Require the CS5 Contractor to implement and maintain an SMS and QMS. CFM-01, CFM-02, CFM-03, CFM-04, CFM-05, CFM-06

SR66 Ensure that EAIMS software is at least SWAL 4 CFM-01

SR67 Ensure the EAIMS system is designed in such way as to ensure the data integrity requirements. CFM-01, CFM-02, CFM-06

SR68 Ensure that only COTS which provide built-in mechanisms ensuring data integrity are used in EAIMS/CS5 CFM-01, CFM-02, CFM-06

SR69 Ensure that appropriate measures are taken to protect against loss of web portal/internet connections. CFM-06, CFM-07

SR70 Confirm that appropriate measures are taken (testing, monitoring, controls, data validation) to ensure that data is not lost/corrupted in transit between stakeholders’ HMI browser and EAIMS.


SR71 Ensure that external systems or maintenance do not inadvertently prevent use of the EAIMS. CFM-01, CFM-02, CFM-06

SR72 Confirm that appropriate measures are taken (testing, monitoring, controls, data validation) to ensure that the use of EAIMS is not affected by external stakeholder system compatibility issues.


SR73 Confirm that appropriate measures are taken (testing, monitoring, controls, data validation) to ensure that supporting infrastructure protection is in place.


SR74 Ensure that each stage of the data transfer process is coded visually so that the both the sender and the receiver are immediately aware of the transaction status.


SR75 Remind EAIMS Users that any change in their functional system (people, procedures and equipment) needs to be assessed according to their safety management system.


Table 5 Safety requirements/Consolidated Failure Modes traceability table

More detailed information about potential risk mitigation means and measures is provided in the Safety Requirements traceability table shown in Annex A. In addition, the Safety Requirements traceability tables provide forward and backward traceability between hazards, failure modes, related causal and consequential mitigations and derived safety requirements.

PSSA Report - EAIMS

Page 26 Proposed Issue Edition: 1.0

CHAPTER 4 – CONCLUSION

Three functional level hazards had been identified in the FHA, namely Data Corruption, Data Unavailability and Data Discrepancy. It was recognised that these hazards do have a safety impact but the severity of consequences is directly linked to the nature of the data affected. Further analysis during the FHA had identified that the overall data handling system, particularly for the handling of AIS data, is already robust enough to reduce significantly the consequences of these hazards.

The PSSA work had shown that fourteen failure modes could lead to the hazards mentioned above. Further analysis had shown that some of these failure modes were common to two hazards, and thus the fourteen failure modes were eventually consolidated into eight consolidated failure modes.

At present there are only very high-level descriptions of the system architecture mainly because it will be up to the successful bidder for EAIMS/CS5 to design in detail EAIMS/CS5 system, taking into account the technical and architectural requirements set in the CFT. Thus the current lack of detail is a severe constraint when it comes to specifying the safety requirements. Therefore at this phase of the project it is not feasible to establish detailed safety requirements since the knowledge/information about the system architecture is limited.

Despite this constraint it was still possible to draw up seventy-five generic/high-level safety recommendations to address the failure modes identified. These safety requirements, although generic/high-level, should assure adequate initial mitigation of the safety risk associated with the EAIMS operations prior to the comprehensive system design since these safety requirements shall be part of the CFT documentation.

The process used for this PSSA, assuring that the relevant staff was involved (ref Annex B), ensured that all human, procedure and equipment components within the scope of EAIMS have been addressed. Still the process will be made more rigorous since further reviews are planned to be undertaken by external stakeholders. These reviews may lead to amendments to the analysis thus necessitating a revision of the safety requirements.

All safety activities so far have used CONOPS Edition Number 2.0, Edition Date 24 October 2013. The report has been updated prior to the publication of the CFT to align it with the revised CONOPS Edition Number 2.1, Edition Date 1st September 2016. The update was merely to align terminology and had no impact on the substance of the safety assessment.

This document will certainly need further refinement as more clarification will be required as the proposed architecture is refined after the contractor is selected.

PSSA Report - EAIMS


Annex A – SAFETY REQUIREMENT S TRACEABILITY TABLES

FH-01 Data Corruption Failure modes, Causal Factors and Potential Causal Mitigations and Safety Requirements

Hazard ID Hazard Description Failure Modes Causal factors Potential Causal Mitigations

Safety Requirements

FH-01 Data Corruption

Data corruption is the situation where individual items or sets of data are corrupted from their intended value. Corrupt data is defined as incorrect data of plausible value or content. Corruption can affect one or more of the following data characteristics:

• Accuracy

• Resolution

• Integrity

• Traceability

• Timeliness

i. Corrupted data

ii. Incorrect data

The FHA uncovered various types of incorrect data

o incorrect PIB,

Briefing to the pilot is wrong, includes wrong interpretation of by human

o incorrect airfield information,

o incorrect airspace information,

i. Corruption following:

o at entry because

� Human making a mistake (manual entry)

� HMI/local processing corrupts the data

� External Systems corrupt the data (B2B entry)

o at the interface

� COTS systems used in the External Systems are

• Double check at data input (4-eyes principle)

• Graphical representation at data input

• Checksum and CRC

(cyclic redundancy checks)

• Data verification at Data

Originator level of final draft before publication

• Data verification at user site (human and/or

machine) and rejection/

SR1, SR2,

SR3, SR4, SR5, SR6,

SR7, SR8,

SR9, SR10,

SR11, SR12,

SR13, SR14, SR15, SR16,

SR17, SR18,

SR20, SR21,

SR22, SR23, SR24, SR25,

SR27, SR28,

SR32, SR34,

SR36, SR40,

PSSA Report - EAIMS

Page 28 Released Issue Edition:1.0


Safety Requirements

• Completeness

• Format

Corruption can be detected or undetected. Mitigation is possible only when there is detected corruption.

o time gaps,

o incoherence between 4D static and dynamic data,

o 3D incoherence due to performance capabilities,

The planned aircraft trajectory is not the same as the actual trajectory Item vi (3D) looks also at the vertical flight profile while item v (4D) includes additionally the time parameters

o Data retrieved by user is wrong (can be detected, cannot be detected).

o Insufficient data validation leading to data not operational useable

This was actually seen as a failed barrier.

iii. Errors

iv. Non removal of obsolete data

This failure mode could be either total or partial non-removal. Furthermore the

corrupted

� Data is corrupted in transfer from data providers/External Systems the database is corrupted

o information sent by CS5-CFT is wrong because

� The database is corrupted

� The interface (gateway) N-Connect/CS5-CFT is corrupting data

� External Systems are corrupting the data

� Software corrupts the data

� Data received from NM system is corrupted

ii. Incorrect data could be due to:

o human error in wrongly interpreting the data since

� information being wrongly presented to the user because of:

alerting by users’ system

• Graphical presentation at

user level

• Clear and unambiguous

coding rules

• Correct and consistent sources of the data

• Common rules/procedures for

querying the database

• Coordination between adjacent AISP or

definition of cross-border

data ownership of a

particular State via SLAs

• Inconsistent data will not

be published and the concerned providers will

be alerted to verify the

accuracy of the data they

have

• Correctly designed queries from Users to

provide the expected output

SR42,SR43,

SR44, SR45,

SR46, SR47,

SR48, SR49,

SR50, SR51, SR52, SR53,

SR55, SR56,

SR59, SR60,

SR61, SR62,

SR63, SR64, SR65, SR66,

SR67, SR68,

SR70, SR71,

SR72, SR73, SR74, SR75.

PSSA Report - EAIMS



Safety Requirements

partial/total may also refer to the content of the data. Thus the possible scenarios are:

• Partial removal of the data from all parts of the system

• partial removal of the data from some parts of the system

• total removal of the data but from only some parts of the system

This failure mode can additionally be detected or undetected. When detected the operator will operate differently from when he is unaware that the data is obsolete.

v. Reverse after passing effective date (cancellation of updates after publication)

The scenario envisaged is where the new data has already been uploaded into EAIMS but provider cancels/ delays the implementation date without respecting the AIRAC cycle. Thus the EAIMS data is correct but not actually in force when originally intended.

� CS5-CFT presents the data in a format which is difficult to understand (unclear HMI).

� CS5-CFT HMI is different from the current HMI

� the extraction of the data from the External Systems is wrong.

o wrong data received at local level because

� the request is wrong (human error in extraction)

� parameters are wrong

� wrong query made

� query wrongly applied (software)

� data are originally wrong

o N-conect delivers wrong data due to

� software bug

� mismatched data

� network failure/delays

o information provided too late or too early

PSSA Report - EAIMS



Safety Requirements

o original data used by Human Provider or External Systems is wrong because

� it is corrupted data input in the database is wrong (Annex 15, AIMSL, other data e.g. BADA)

� data in the NM system are incorrect

o data are corrupted in transfer from data providers/External Systems

iii. Errors due to

o human error in inserting the data

o software – changing the data format

o interface problem

o error at local processing due to software

iv. Obsolete data due to

o rollback problem

v. Cancellation of updates after publication

o rollback problem

Table 6 Data Corruption Failure Modes, Causal Factors, Potential Causal Mitigations and Safety Requirements Traceability Table

PSSA Report - EAIMS


FH-02 Data Unavailability Failure modes, Causal Fac tors, Potential Causal Mitigations and Safety Requirements


Safety Requirements

FH-02 Data Unavailability

Data Unavailability is the situation where individual items or sets of data are missing, lost or otherwise delayed. The following two scenarios can lead to data unavailability.

• Loss of Data

o Partial - loss of individual items of data,

o Complete loss of data - sets of data or entire single publications could be lost.

• Service Unavailable

o Unavailability of EAIMS, either to all users or specifically by denying access to individual authorised users. The effects of service unavailability in respect of safety are the same as for data loss.

It seems infeasible in the current situation (with paper versions serving as back-up) to have absolutely no aeronautical information available, but this is a

i. Loss of data

o This is the situation in which information is destroyed by failures or neglect in storage, transmission, or processing.

ii. Service failure

i. Missing data due to

o corruption

o errors

o information provided too late or too early

o internal CS5 databases not synchronised

o mismatched data

o software bug

o interface problems

o application, incl. overload

o servers (the machines themselves)

ii. Failure following:

o power failure, resulting in data in volatile memory not being saved to permanent memory

o hardware failure, such as a head crash in a hard disk.

o software crash or freeze, resulting in data not being saved

o software bugs or poor usability.

o business failure (vendor

• Double check at data

input (4-eyes principle)

• Graphical representation

at data input

• Checksum and CRC (cyclic redundancy

checks)

• Data verification at user

site (human and/or

machine) and rejection/ alerting by users’ system

• Graphical presentation at

user level

• Contingency

management and

coordination procedures

• Store backup data in a

separate physical location

SR1, SR2,

SR3, SR5,

SR6, SR7, SR8, SR9,

SR13, SR14,

SR15, SR19,

SR20, SR21,

SR22, SR23, SR24, SR25,

SR26, SR28,

SR29, SR30,

SR31, SR32,

SR33, SR34, SR35, SR36,

SR37, SR38,

SR39, SR40,

SR41, SR42, SR43, SR45,

SR46, SR47,

SR48, SR49,

SR50, SR51,

SR52, SR53, SR54, SR55,

SR56, SR57,

SR58, SR62,

SR65, SR67, SR68, SR69,

PSSA Report - EAIMS



Safety Requirements

plausible future scenario where purely electronic data (i.e. no paper backup) is provided.

The loss of a system/data could either be detected or undetected. The severity of the consequences could be higher when there is an undetected system loss. If the displays show incomprehensible data then the failure mode becomes detected. On the other hand severe problems might arise if the displayed data looks viable. Also the undetected loss of system might lead to the distribution of incorrect information to all parties thereby further decreasing the likelihood of detection because there would be reduced opportunity for cross-checking.

bankruptcy).

o disaster such as earthquake, flood, tornado, fire

SR70, SR71,

SR72, SR73,

SR74, SR75.

Table 7 Data Unavailability Failure modes, Causal Factors Potential Causal Mitigations and Safety Requirements Traceability Table

PSSA Report - EAIMS


FH-03 Data Discrepancy Failure modes, Causal Factor s, Potential Causal Mitigations and Safety Requirements


Safety Requirements

FH03 Data Discrepancy

Data discrepancy is the

situation 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. The discrepancy could be between

• individual items of one AIP held by each actor,

• multiple items of one AIP held by each actor.

Therefore discrepancies between EAIMS and data providers would result in erroneous or missing data. On the other hand discrepancies between EAIMS and data users might result in additional ATCO or Pilot workload to resolve the difference. Discrepancy could also result from “interpretation” of data to suit applications.

i. Corrupted data

ii. Wrong interpretation of data

iii. Incorrect data

This failure mode was considered to include not only when the data is totally incorrect but also the scenario where the data is correct but not fit for purpose of the user due to various reasons such as late delivery or by accessing the wrong database and the data is not sufficiently accurate for the user’s purposes.

iv. Errors

v. Non removal of obsolete data

This failure mode could be either total or partial non-removal. Furthermore the partial/total may also refer to the content of the data. Thus the possible scenarios are:

• partial removal of the data from all parts of the

i. Corruption following:

o incorrect manual entry

o incorrect data processing

o corrupted B2B entry

o COTS systems used in the External Systems are corrupted

o transfer from data providers/External Systems

o the database is corrupted

o N-Connect/CS5-CFT is corrupting data

o External Systems are corrupting the data

o software corrupts the data

o data received from NM system is corrupted

ii. Wrong interpretation because

o Information being wrongly presented due to

� unclear HMI because CS5-CFT presents the data in a format which is

• Data verification at Data

Originator level of final draft before publication

• Data verification at user

site (human and/or machine) and rejection/

alerting by users’ system

• Graphical presentation at user level

• Alternative data sources

• Coordination between

adjacent AISP or

definition of cross-border data ownership of a

particular State via SLAs

• Inconsistent data will not be published and the

concerned providers will

be alerted to verify the

accuracy of the data they have

• Correctly designed

queries from Users to provide the expected

SR1, SR2,

SR3, SR4,

SR5, SR6, SR7, SR8,

SR9, SR10,

SR11, SR12,

SR13, SR14,

SR15, SR16, SR17, SR18,

SR19, SR20,

SR21, SR22,

SR23, SR24,

SR25, SR26, SR27, SR28,

SR32, SR34,

SR39, SR40,

SR41, SR42, SR43, SR44,

SR45, SR46,

SR47, SR48,

SR51, SR52,

SR53, SR54, SR56, SR57,

SR58, SR59,

SR60, SR61,

SR62, SR63, SR64, SR65,

PSSA Report - EAIMS



Safety Requirements

system,

• partial removal of the data from some parts of the system,

• total removal of the data but from only some parts of the system,

This failure mode can additionally be detected or undetected. When detected the operator will operate differently from when he is unaware that the data is obsolete.

vi. Reverse after passing effective date (cancellation of updates after publication)

The scenario envisaged is where the new data has already been uploaded into EAIMS but provider cancels/ delays the implementation date without respecting the AIRAC cycle. Thus the EAIMS data is correct but not actually in force when originally intended.

vii. Missing Data

difficult to understand

� different CS5-CFT HMI from the current HMI

� wrong extraction of the data from the External Systems.

iii. Incorrect data could be due to:

o wrong data received at local level because

� the request is wrong (human error in extraction)

� wrong parameters

� wrong query made

� query wrongly applied (software)

� data are originally wrong

o wrong data delivered by N-conect delivers due to

� software bug

� mismatched data

� network failure/delays

o Information provided too late or too early

o wrong information in the data base due to

output

• Use of dedicated

protocols supporting automatic detection and

request of missing data

• Establish an SLA between the provider

and AISP which includes

not only the verification

process but also the

deadlines by when the AISP has to submit the

draft and the originator

has to reply.

SR66, SR67,

SR68, SR69,

SR70, SR71,

SR72, SR73,

SR74, SR75.

PSSA Report - EAIMS



Safety Requirements

� corruption (see FM-FH03 i)

� wrong data input in the database (Annex 15, AIMSL, other data e.g. BADA)

� incorrect data in the NM system

iv. Errors due to

o human error in inserting the data

o software – changing the data format

o interface problem

o error at local processing due to software

o request is wrong (human error in extraction)

o wrong parameters

v. Obsolete data due to

o rollback problem

vi. Cancellation of updates after publication

o rollback problem

vii. Missing data due to

o corruption (see FM-FH03 i)

o errors (FM-FH03 iii)

o information provided too

PSSA Report - EAIMS



Safety Requirements

late or too early

o internal CS5 databases not synchronised

� mismatched data

� software bug

� interface problems

� application, incl. overload

� servers (the machines themselves)

Table 8 Data Discrepancy Failure Modes, Causal Factors Potential Causal Mitigations and Safety Requirements Traceability Table

PSSA Report - EAIMS


Annex B - MEETINGS AND PARTICIPATION

Name Unit Role PSSA#1

1/12/2015

PSSA#2

5/01/2016

PSSA#3

4/02/2016

MARGAUAN Razvan DG/CS-PMO CS5 Project Manager � � �

AGACDIKEN Nil NMD/NS/EAIM CS5 Deputy PM and WP Leader of OPS requirements

� � �

MANA Patrick DG/CS-PMO CS Safety & Quality Manager � � �

BORGOLTZ Etienne Piero Emile CS-PMO �

SWENNEN Johnny NMD/NOM/NOS/DOM Airspace Data Domain Manager � � �

SHUTOV Alex NMD/NS/EAIM AIS expert � �

SCOTT Maria NMD/NS/EAIM Supporting CFT on NM/CACD aspects

�

DERISSON James DG/CS-PMO Supporting CS5 on architectural matters

�

TRIBOULET Francois NMD/NTS/SUA Head of Technical Development Section

� �

VAN LAETHEM Guido NMD/NTS/SUA Team Leader R3/1 � �

MENDES VIDEIRA Idalina NMD/NSD � �

PSSA Report - EAIMS


Name Unit Role PSSA#1

1/12/2015

PSSA#2

5/01/2016

PSSA#3

4/02/2016

GURBUZ Mesut NMD/NS/EAIM �

OLIVER Mervyn NMD/SQS Head of NMD/SQS � �

DE REDE Jean-Michel NMD/NOM/SAF Senior Safety Expert � �

SEYCHELL Anthony F. NMD/NOM/SAF Safety Support to CS5 � �

PSSA Report - EAIMS


Annex C – ABBREVIATIONS AND ACRONYMS

ADQ Aeronautical Data Quality (Regulation (EU) No 73/2010)

ADR Airspace Data Repository

AIM Aeronautical Information Management

AIMSL AIM Service Level (EAD)

AIP Aeronautical Information Publication

AIRAC Aeronautical Information Regulation and Control

AIS Aeronautical Information Services

AISP Aeronautical Information Service Provider

AIXM Aeronautical Information Exchange Model

ANSP Air Navigation Service Provider

ASM Airspace Management

ATCO Air Traffic Controller

ATFCM Air Traffic Flow and Capacity Management

ATIS Automatic Terminal Information Service

ATM Air Traffic Management

BADA Base of Aircraft Data

CACD Central Airspace and Capacity Database

CFM Consolidated Failure Mode

CFT Call for Tenders

CHAIN Controlled Harmonised Aeronautical Information Network

CHMI Collaboration Human Machine Interface (formerly CFMU Human-Machine Interface)

COTS Commercial Off-The-Shelf

CRC Cyclic Redundancy Check

CS5 Centralised Service 5

DP Data Provider

DU Data User

PSSA Report - EAIMS


EAD European AIS Database

EAIMS European ATM Information Management System

EUROCAE European Organisation for Civil Aviation Equipment

FH Functional Level Hazard

FHA Functional Hazard Assessment

FIXM Flight Information Exchange Model

FM Failure Mode

HMI Human-Machine Interface

Hz Hazard

IOP Interoperability Data

LoA Letter of Agreement

NM (EUROCONTROL Directorate) Network Manager

NM/CSO (Network Manager) Customer technical Service desk and Operations

NOP Network Operations Portal

NOTAM Notice to Air Men (Mariners)

PIB Pre-flight Information Bulletin (EAD)

PSSA Preliminary System Safety Assessment

SID Standard Instrument Departure

SLA Service Level Agreement

SNET Safety Net

SR Safety Requirement

STAR Standard Arrival Route

TWR Tower (Aerodrome Air Traffic Control Service)

VOLMET Routine voice broadcasts of MET information for aircraft in flight

WXXM Weather Information Exchange Model

PSSA Report - EAIMS


Annex D – REFERENCES

Regulations

REGULATION (EU) No 1035/2011 “Commission Implementing Regulation (EU) No 1035/2011 of 17 October 2011 laying down common requirements for the provision of air navigation services and amending Regulations (EC) No 482/2008 and (EU) No 691/2010”

EUROCONTROL Documents

Safety Management of Changes to Functional Systems; NMD SQS; iMS/POL/SMS-SMC; version 2.0; 2013-12-09

CHAIN Preliminary Safety Case - Minutes of the FHA/PSSA Workshop (31/08/05 – 1/09/2005), 18th October 2005, Issue 1.1

Preliminary System Safety Assessment (PSSA) Report for EAD, 29 September 2014, v6.2

Preliminary System Safety Assessment Report Airspace Data Repository Service – Static Data, July 2013, Version 0.10

Centralised Service on European ATM Information Management (EAIMS) Concept of Operations (CONOPS) Edition Number 2.0, Edition Date 24 October 2013

European ATM Information Management (EAIMS) Pre-Requisites, Requirements and Assumptions Version 2

PSSA Report - EAIMS


Intentionally blank