Cast 30

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
DOCUMENT CHARACTERISTICS
TITLE
PRELIMINARY SAFETY SYSTEM ASSESSMENT – EAIMS
Publications Reference:
ISBN Number:
Document Identifier Edition Number: 1.0
Preliminary System Safety Assessment –
Edition Date: 01/09/2016
EAIMS
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 copied 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, their use for purposes other than specified in this
notice, as well as their distribution to third parties is strictly prohibited.
Page 2 Released Issue Edition: 1.0

PSSA Report - EAIMS
DOCUMENT AUTHOR
AUTHOR NAME AND SIGNATURE DATE
Senior Safety Expert

19/08/2016
NMD/NOM/SAF
Anthony F. Seychell
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
22.09.2016
CS5
Razvan Margauan
Programme Manager 22.09.2016

Herman Baret
Director Network
Manager 22.09.2016
Joe Sultana
Edition: 1.0 Released Issue Page 3

PSSA Report - EAIMS
DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the present
document.
EDITION EDITION
REASON FOR CHANGE PAGES AFFECTED
NUMBER DATE
0.1 7/03/2016 Working draft for review ALL
Proposed issue following comments leading to

0.2 11/05/2015 Pages 11, 27
minor amendments
Second Proposed Issue following comments after
0.3 19/08/2016 ALL
additional review
Update in the light of the preparation of the launch
1.0 01/09/2016 ALL
of the CS5 Call For Tenders
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: publications@eurocontrol.int

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 ................................................................................ 9

1.1 Purpose .................................................................................................................. 9
1.2 Structure of the risk assessment ......................................................................... 9
1.3 Completeness and correctness of the PSSA process ...................................... 10
1.4 Software Assurance ............................................................................................ 10
1.5 Procedure Assurance ......................................................................................... 11
1.6 Terminology ......................................................................................................... 12
CHAPTER 2 – PSSA ACTIONS ............................................................................... 13

2.1 Objective .............................................................................................................. 13
2.2 PSSA Activities.................................................................................................... 14
2.2.1 PSSA#1 ................................................................................................................ 14
2.2.2 PSSA#2 ................................................................................................................ 15
2.2.3 PSSA#3 ................................................................................................................ 16
2.2.4 Outcome of PSSA Meetings ............................................................................... 17
CHAPTER 3 – PSSA RESULTS .............................................................................. 18

3.1 Overview .............................................................................................................. 18
3.2 Failure modes ...................................................................................................... 18
3.3 Safety Requirements ........................................................................................... 20
CHAPTER 4 – CONCLUSION ................................................................................. 26
Annex A – SAFETY REQUIREMENTS TRACEABILITY TABLES ......................... 27

FH-01 Data Corruption Failure modes, Causal Factors and Potential Causal Mitigations
and Safety Requirements ................................................................................... 27
FH-02 Data Unavailability Failure modes, Causal Factors, Potential Causal Mitigations
and Safety Requirements ................................................................................... 31
FH-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 ....................................................................................... 41

Regulations ................................................................................................................... 41
EUROCONTROL Documents ....................................................................................... 41
Figure 1 Latest EAIMS high-level architecture diagram .............................................................14
Table 1 Additional considerations in relation to FH-02 Data Unavailability ............................ 16

Table 2 Functional Hazards and Failure Modes ........................................................................ 18
Table 3 Consolidated Failure Modes ......................................................................................... 19
Table 4 Functional Level Hazards/Safety requirements traceability table .............................. 20
Table 5 Safety requirements/Consolidated Failure Modes traceability table.......................... 25
Table 6 Data Corruption Failure Modes, Causal Factors, Potential Causal Mitigations and
Safety Requirements Traceability Table ............................................................................ 30
Table 7 Data Unavailability Failure modes, Causal Factors Potential Causal Mitigations and
Table 8 Data Discrepancy Failure Modes, Causal Factors Potential Causal Mitigations and

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
services delivered via a computer to computer interface.
One system will interact with another system via services. Services are made
B2B Services
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.
services delivered via an HMI, targeted for human interaction.
B2C Services An end user can interact with the system via a client application. The client
application interacts via services with the system.
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
CS5 Contractor
outcome of the CS5 Call For Tenders process under the EUROCONTROL
procurement rules.
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
Data 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).
the complete European ATM Information Management Service managed under
EAIMS the auspices of EUROCONTROL as the Network Manager, irrespective of
outsourced/insourced components and services.
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
EAIMS/CS5 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 the existing NM CACD and other NM systems. The CACD system
adaptations to
remains in a first implementation step the reference source for the ATFCM and
NM systems
dynamic ASM Data being later integrated in EAIMS/CS5.
a combination of: physical components (hardware, equipment), procedures
System
(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 to
provide/retrieve data to the CS5 database. This system would not use the N-Conect service
layer 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, which
would 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 Access rights, authentication, proxy settings and minimal local computers
level configuration need to be defined.
i. As this equipment in central not only to CS5 it may be required to run a
common cause analysis understanding the potential impact on the
different services using this equipment.
N-Connect ii. Assumption: N-Connect is also providing support to flight planning
services. CS5 is considered less critical than flight planning services.
Therefore, the N-Connect reliability is considered to be sufficient for CS5
uses.
CS5 The DB is cached in N-Connect.
Only parts of the overall data provision; complementing the other sources (incl.
AIS Systems
B2B, external systems).
i. What is foreseen in terms of AIS library management?
ii. Is the management tool part of CS-5? Would it be COTS?
AIP/Charts (COTS) iii. Are some requirements foreseen for required minimum configuration of
local 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)
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 have
CS5-Operators incomplete or outdated data.
vi. NM systems, can be directly updated (assuming the data is available by
an 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 the
staff, capability and tools to manage this kind of situation?
i. External systems are data providers and users Interacting via B2B
External systems ii. In case they cannot prepare/send their data sets (e.g. NOTAM); they
can send (fax, email, telephone) and request (via CSO/service desk) the
data 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
FM-FH01 i. Corrupted data FM-FH02 i. Missing data FM-FH03 i. Corrupted data
FM-FH01 ii. Incorrect data FM-FH02 ii. Failure FM-FH03 ii. Wrong interpretation of data
FM-FH01 iii. Errors FM-FH03 iii. Incorrect data
FM-FH01 iv. Non removal of obsolete data FM-FH03 iv. Errors
Failure
Modes FM-FH01 v. Reverse after passing FM-FH03 v. Non removal of obsolete data
effective date (cancellation of
FM-FH03 vi. Reverse after passing
updates after publication)
effective date (cancellation of
updates after publication)
FM-FH03 vii. Missing Data
Table 2 Functional Hazards and Failure Modes

PSSA Report - EAIMS
Functional Hazard ID and Failure Modes

Consolidated Failure Modes
(CFM) 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 FM-FH01 iv Non removal of FM-FH03 v Non removal of
data obsolete data obsolete data
CFM-05 Cancellation of updates FM-FH01 v Reverse after passing FM-FH03 vi Reverse after
after publication effective date passing effective
(cancellation of date (cancellation of
updates after updates after
publication) 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 FM-FH03 ii Wrong interpretation

data 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.
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,
FH-01 Data Corruption
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
SR68, SR69, SR70, SR71, SR72, SR73, SR74, SR75.
FH-03 Data Discrepancy
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
CFM-01, CFM-02, CFM-03,
Ensure that appropriate reference manuals, guidelines and use procedures exist for Data Users and Data
SR1 CFM-04, CFM-05, CFM-06,
Providers.
CFM-07, CFM-08
CFM-01, CFM-02, CFM-03,
Validate that the appropriate reference manuals, guidelines and use procedures provide adequate support to
Data Users and Data Providers.
CFM-07, CFM-08
CFM-01, CFM-02, CFM-03,
Ensure that appropriate reference manuals, guidelines and use procedures are made available to users (e.g. by
means of dedicated meetings with the operators).
CFM-07, CFM-08
Ensure that the reference manuals, guidelines and use procedures are subject to strict document configuration
SR4 CFM-03
control.
SR5 Implement and keep current mechanisms to defeat deliberate security attacks. CFM-01, CFM-02, CFM-06
CFM-01, CFM-02, CFM-03,
SR6 Ensure a process for reporting of technical and operational problems. CFM-04, CFM-05, CFM-06,
CFM-07
Take appropriate measures (testing, monitoring, controls, data validation) to ensure that data is correct and up-to- CFM-01, CFM-02, CFM-03,
SR7
date. CFM-04, CFM-05, CFM-06
Notify EAIMS Data Users of any known deficiencies in EAIMS data, including situations where the timeliness CFM-01, CFM-02, CFM-06,
SR8
requirements cannot be achieved. CFM-07
Ensure that the incident management process provides sufficient support for the reporting and correction of
SR9 CFM-01, CFM-02, CFM-06
erroneous EAIMS data observed by Data Providers or Data Users.
Put in place a process by which the Data Users or Data Provider can report errors identified in the EAIMS data.
SR10 CFM-03
The process shall ensure that corrective actions are defined and implemented.
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
Ensure that procedure(s) exist for continuous update of the system with applicable constraints and issued to CFM-02, CFM-04, CFM-06,
SR13
users (e.g. to avoid incorrect data, errors, missing data and wrong interpretation of data). CFM-08
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

Ensure that the CS5-Contractor does not alter the Original AIS data from any Data Provider without informing the
SR16 CFM-02
Data Provider of the change and endeavouring to receive concurrence in a timely manner.
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
SR17 CFM-02
that in some extreme situations a change must be introduced in EAIMS to make the CS5-Contractor system
function correct and safe).
SR18 Keep records of all alterations and records shall be made available to Data Users upon their request. CFM-02
Ensure that AIS data from non-migrated data providers is collected, validated and entered into the EAIMS
SR19 CFM-06
database in a timely manner.
Ensure that the CS5-Contractor verification of EAIMS AIS data is independent of any EAIMS Data Provider
CFM-01, CFM-02, CFM-03,
SR20 checks and include checks against specified and agreed format rules, boundary values, completeness and other
CFM-04, CFM-05, CFM-06
sensibility checks, including those in ICAO Annex 15. Such validation should where possible be automated.
Verify data from non-B2B users before releasing the data to or making the data available through the EAIMS CFM-01, CFM-02, CFM-03,
SR21
database. CFM-04, CFM-05, CFM-06
Ensure the correct processing of NOTAMs covering dynamic changes to airspace within the timeliness
CFM-02, CFM-03, CFM-04,
SR22 requirement for the particular aspects after notification by the Data Provider responsible (only in so far the
CFM-06
NOTAMs cover data to be published through the EAIMS Service).
Conduct an independent and comprehensive check (a General Review) of all data released through EAIMS by a CFM-01, CFM-02, CFM-03,
SR23
Data Provider. CFM-04, CFM-05, CFM-06
CFM-02, CFM-03, CFM-04,
SR24 Verify all EAIMS data against defined business rules before it is released to the Data Users through EAIMS.
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
Ensure that a procedure is established for the appropriate role to verify that the EAIMS data is correct and
SR26 CFM-06, CFM-07
complete.
Ensure that Data Providers only allow suitable trained operators to update data used by the EAIMS e.g. via an
SR27 CFM-03
SLA.
Confirm that Data Providers ensure the completeness and correctness of data entered into EAIMS e.g. through CFM-02, CFM-03, CFM-04,
SR28
Data Provider requirements in SLAs. CFM-05, CFM-06

PSSA Report - EAIMS

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
SR29 CFM-07
notification shall be managed locally (lack of reply to a query) or by the EAIMS Service (notification of service
windows, technical malfunctions, etc.).
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
Confirm that CS5 Contractor staff assigned to perform data processing has the necessary skills, competencies,
SR32 CFM-03, CFM-07
and knowledge of the procedures.
Ensure that procedure(s) exist for manual data upload/download in case of loss of the corresponding automated
SR33 CFM-07
service.
SR34 Ensure that contingency procedures exist for provision of data in case of loss of data. CFM-05, CFM-06, CFM-07
Develop robust procedures for manual transfer of aeronautical information between the Data Providers and the
SR35 CFM-07
EAIMS in case of loss of the corresponding automated service.
CFM-01, CFM-02, CFM-06,
SR36 Implement procedure for suspension and resumption of EAIMS, including notification to users.
CFM-07
SR37 Ensure that the CS5-Contractor stores the backup data in a separate physical location. CFM-07
Ensure a process for the development of commands to ensure safe operation, recovery from backup in case of
SR38 CFM-07
software crash.
SR39 Define and implement contingency management and coordination procedures in the event of resource overload. CFM-06
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).
Ensure, as far as reasonably practicable, that EAIMS systems are fail safe (i.e. shall not appear to be working
SR41 CFM-07
when they are not).
Ensure alerting in the case of detected corrupted data, incorrect data, errors, non-removal of data, cancellation of CFM-01, CFM-02, CFM-03,
SR42
updates after publication or missing data. CFM-04, CFM-05, CFM-06
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
CFM-01, CFM-02, CFM-03,
SR45 Ensure that data and parameters are tuned and optimised by means of dedicated input and validation procedure.
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
CFM-01, CFM-02, CFM-04,
SR47 Assess the need of system support tools at validations.
CFM-05, CFM-06
CFM-01, CFM-02, CFM-03,
SR48 Validate the effectiveness of the available tools. 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
CFM-03, CFM-04, CFM-05,
SR50 Ensure system support for easy-to-comprehend presentation of HMI.
CFM-06, CFM-08
CFM-02, CFM-03, CFM-04,
SR51 Ensure that changes are validated before upload to the operational system.
CFM-05, CFM-06
Perform a specific EAIMS/CS5 validation session prior to operational deployment to validate that the service
works appropriately.
CFM-02, CFM-04, CFM-05,
SR53 Ensure that change notification procedures and/or SLAs are appropriate to the environment of operations.
CFM-06
Implement a process to build and maintain the Interoperability (IOP) Data to close the gap between AIS and
SR54 CFM-06
operational users.
CFM-02, CFM-04, CFM-05,
SR55 Ensure complete and consistent IOP Data.
CFM-06
CFM-03, CFM-04, CFM-05,
SR56 Implement EAIMS release management process.
CFM-06
Maintain the World Wide and non-migrated states data in EAIMS/CS5 according to the data and geo scope
SR57 CFM-06
defined in the EAIMS Data Catalogue..
SR58 Ensure continuity of the services currently provided by Group EAD to EAD clients. CFM-06
Ensure a process to prevent updating Annex 15 IOP AIRAC data set after cut-off date after the NM cut-off date
SR59 CFM-02
unless approved by the relevant Customer Authority.
Implement a procedure not to accept AIRAC updates in the Annex 15 IOP data after the NM cut-off date unless
SR60 CFM-02, CFM-04
approved by the relevant Customer Authority.
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

Confirm that Data Providers ensure that any effective dates associated with CS5 data are entered correctly or
SR63 CFM-02
that data are allocated to the correct AIRAC cycle.
Ensure that the B2B interfaces are compliant with the international data exchange models (AIXM, WXXM, and
SR64 FIXM) and with the Aeronautical Information Reference Model (AIRM) and Information Services Reference Model CFM-02, CFM-04
(ISRM).
CFM-01, CFM-02, CFM-03,
SR65 Require the CS5 Contractor to implement and maintain an SMS and QMS.
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
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
Confirm that appropriate measures are taken (testing, monitoring, controls, data validation) to ensure that the use CFM-01, CFM-02, CFM-03,
SR72
of EAIMS is not affected by external stakeholder system compatibility issues. CFM-06
Confirm that appropriate measures are taken (testing, monitoring, controls, data validation) to ensure that
supporting infrastructure protection is in place.
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.
CFM-01, CFM-02, CFM-03,
Remind EAIMS Users that any change in their functional system (people, procedures and equipment) needs to
SR75 CFM-04, CFM-05, CFM-06,
be assessed according to their safety management system.
CFM-07, CFM-08
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
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.
Page 26 Proposed Issue Edition: 1.0

PSSA Report - EAIMS
Annex A – SAFETY REQUIREMENTS TRACEABILITY

TABLES
FH-01 Data Corruption Failure modes, Causal Factors and Potential Causal Mitigations and
Safety Requirements
Potential Causal Safety
Hazard ID Hazard Description Failure Modes Causal factors
Mitigations Requirements
FH-01 Data Data corruption is the situation i. Corruption following: • Double check at data SR1, SR2,
i. Corrupted data
Corruption where individual items or sets
o at entry because input (4-eyes principle) SR3, SR4,
of data are corrupted from ii. Incorrect data
their intended value. Corrupt Human making a SR5, SR6,
• Graphical representation
data is defined as incorrect The FHA uncovered various mistake (manual SR7, SR8,
data of plausible value or types of incorrect data at data input
entry) SR9, SR10,
content. Corruption can affect
HMI/local • Checksum and CRC SR11, SR12,
one or more of the following
o incorrect PIB, processing corrupts (cyclic redundancy SR13, SR14,
data characteristics:
Briefing to the pilot is the data checks) SR15, SR16,
• Accuracy wrong, includes wrong External Systems SR17, SR18,
interpretation of by • Data verification at Data
• Resolution corrupt the data SR20, SR21,
human (B2B entry) Originator level of final
SR22, SR23,
• Integrity o incorrect airfield o at the interface draft before publication
SR24, SR25,
• Traceability information, COTS systems used • Data verification at user SR27, SR28,
o incorrect airspace in the External site (human and/or
• Timeliness SR32, SR34,
information, Systems are machine) and rejection/ SR36, SR40,

PSSA Report - EAIMS

• Completeness o time gaps, corrupted alerting by users’ system SR42,SR43,
o incoherence between Data is corrupted in SR44, SR45,
• Format • Graphical presentation at
4D static and dynamic transfer from data SR46, SR47,
user level
Corruption can be detected or data, providers/External SR48, SR49,
undetected. Mitigation is o 3D incoherence due to Systems the • Clear and unambiguous SR50, SR51,
possible only when there is performance database is coding rules SR52, SR53,
detected corruption. corrupted
capabilities, SR55, SR56,
The planned aircraft o information sent by CS5- • Correct and consistent
SR59, SR60,
trajectory is not the CFT is wrong because sources of the data
SR61, SR62,
same as the actual The database is • Common SR63, SR64,
trajectory Item vi (3D) corrupted
rules/procedures for SR65, SR66,
looks also at the The interface
vertical flight profile querying the database SR67, SR68,
(gateway) N-
while item v (4D) Connect/CS5-CFT • Coordination between SR70, SR71,
includes additionally is corrupting data SR72, SR73,
adjacent AISP or
the time parameters
External Systems definition of cross-border SR74, SR75.
o Data retrieved by user are corrupting the data ownership of a
is wrong (can be data particular State via SLAs
detected, cannot be
Software corrupts
detected). • Inconsistent data will not
the data
o Insufficient data be published and the
Data received from
validation leading to concerned providers will
NM system is
data not operational
corrupted be alerted to verify the
useable
accuracy of the data they
This was actually seen ii. Incorrect data could be due
to: have
as a failed barrier.
iii. Errors
o human error in wrongly • Correctly designed
interpreting the data
queries from Users to
since
iv. Non removal of provide the expected
obsolete data information being
output
wrongly presented
This failure mode could be to the user because
either total or partial non- of:
removal. Furthermore the
Page 28 Released Issue Edition:1.0

PSSA Report - EAIMS

partial/total may also refer to CS5-CFT
the content of the data. Thus presents the data
the possible scenarios are: in a format which
• Partial removal of the is difficult to
data from all parts of understand
the system (unclear HMI).
• partial removal of the CS5-CFT HMI is
data from some parts of different from the
the system current HMI
• total removal of the the extraction of
data but from only the data from the
some parts of the External Systems
system is wrong.
This failure mode can o wrong data received at
additionally be detected or local level because
undetected. When detected
the operator will operate the request is wrong
differently from when he is (human error in
unaware that the data is extraction)
obsolete. parameters are
v. Reverse after passing wrong
effective date wrong query made
(cancellation of query wrongly
updates after applied (software)
publication) data are originally
The scenario envisaged is wrong
where the new data has o N-conect delivers wrong
already been uploaded into data due to
EAIMS but provider cancels/
delays the implementation software bug
date without respecting the mismatched data
AIRAC cycle. Thus the network
EAIMS data is correct but
failure/delays
not actually in force when
originally intended. o information provided too
late or too early

PSSA Report - EAIMS

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 Factors, Potential Causal Mitigations and
Safety Requirements
FH-02 Data Data Unavailability is the i. Loss of data • Double check at data SR1, SR2,
i. Missing data due to
Unavailability situation where individual
o This is the situation in o corruption input (4-eyes principle) SR3, SR5,
items or sets of data are
missing, lost or otherwise which information is SR6, SR7,
destroyed by failures or
o errors • Graphical representation
delayed. The following two SR8, SR9,
scenarios can lead to data neglect in storage, o information provided too at data input
SR13, SR14,
unavailability. transmission, or late or too early
• Checksum and CRC SR15, SR19,
processing. o internal CS5 databases
• Loss of Data (cyclic redundancy SR20, SR21,
ii. Service failure not synchronised
o Partial - loss of individual checks) SR22, SR23,
o mismatched data
items of data, SR24, SR25,
o software bug • Data verification at user
o Complete loss of data - SR26, SR28,
o interface problems site (human and/or
sets of data or entire SR29, SR30,
o application, incl. overload machine) and rejection/
single publications could SR31, SR32,
o servers (the machines alerting by users’ system
be lost. SR33, SR34,
themselves) • Graphical presentation at SR35, SR36,
• Service Unavailable
ii. Failure following: user level SR37, SR38,
o Unavailability of EAIMS,
o power failure, resulting in • SR39, SR40,
either to all users or Contingency
data in volatile memory SR41, SR42,
specifically by denying management and
access to individual not being saved to SR43, SR45,
coordination procedures
authorised users. The permanent memory SR46, SR47,
effects of service o hardware failure, such as • Store backup data in a SR48, SR49,
unavailability in respect a head crash in a hard separate physical SR50, SR51,
of safety are the same as disk. location SR52, SR53,
for data loss. o software crash or freeze, SR54, SR55,
It seems infeasible in the resulting in data not SR56, SR57,
current situation (with paper being saved
SR58, SR62,
versions serving as back-up) o software bugs or poor
to have absolutely no SR65, SR67,
usability.
aeronautical information SR68, SR69,
available, but this is a o business failure (vendor

PSSA Report - EAIMS

plausible future scenario bankruptcy). SR70, SR71,
where purely electronic data o disaster such as SR72, SR73,
(i.e. no paper backup) is
earthquake, flood, SR74, SR75.
provided.
tornado, fire
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.
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 Factors, Potential Causal Mitigations and
Safety Requirements
FH03 Data Data discrepancy is the • Data verification at Data SR1, SR2,
i. Corrupted data i. Corruption following:
Discrepancy situation where individual
o incorrect manual entry Originator level of final SR3, SR4,
items or sets of data are ii. Wrong interpretation draft before publication SR5, SR6,
of data o incorrect data processing
inconsistent between key SR7, SR8,
actors in the Data Chain, the o corrupted B2B entry • Data verification at user
iii. Incorrect data SR9, SR10,
resolution of which may o COTS systems used in site (human and/or
SR11, SR12,
This failure mode was the External Systems are machine) and rejection/
increase Pilot or ATCO SR13, SR14,
considered to include not corrupted alerting by users’ system
workload. The discrepancy only when the data is totally SR15, SR16,
o transfer from data
could be between incorrect but also the
providers/External • Graphical presentation at SR17, SR18,
scenario where the data is
• individual items of one Systems user level SR19, SR20,
correct but not fit for
AIP held by each actor, purpose of the user due to o the database is corrupted • SR21, SR22,
Alternative data sources
• multiple items of one AIP various reasons such as late o N-Connect/CS5-CFT is
SR23, SR24,
held by each actor. delivery or by accessing the
corrupting data • Coordination between SR25, SR26,
wrong database and the adjacent AISP or
Therefore discrepancies o External Systems are SR27, SR28,
data is not sufficiently
between EAIMS and data definition of cross-border SR32, SR34,
accurate for the user’s corrupting the data
providers would result in data ownership of a
purposes. o software corrupts the SR39, SR40,
erroneous or missing data. On
the other hand discrepancies iv. Errors data particular State via SLAs SR41, SR42,
between EAIMS and data SR43, SR44,
o data received from NM • Inconsistent data will not
users might result in additional v. Non removal of system is corrupted SR45, SR46,
ATCO or Pilot workload to be published and the
obsolete data SR47, SR48,
resolve the difference. ii. Wrong interpretation concerned providers will
Discrepancy could also result This failure mode could be SR51, SR52,
because be alerted to verify the
from “interpretation” of data to either total or partial non- accuracy of the data they
SR53, SR54,
suit applications. removal. Furthermore the o Information being
SR56, SR57,
partial/total may also refer to wrongly presented due to have
the content of the data. Thus SR58, SR59,
unclear HMI • Correctly designed
the possible scenarios are: SR60, SR61,
because CS5-CFT
• partial removal of the queries from Users to SR62, SR63,
presents the data in
data from all parts of the provide the expected SR64, SR65,
a format which is

PSSA Report - EAIMS

system, difficult to output SR66, SR67,
• partial removal of the understand SR68, SR69,
• Use of dedicated
data from some parts of different CS5-CFT SR70, SR71,
protocols supporting
the system, HMI from the current SR72, SR73,
HMI automatic detection and
• total removal of the data SR74, SR75.
request of missing data
but from only some wrong extraction of
parts of the system, the data from the • Establish an SLA
This failure mode can External Systems.
between the provider
additionally be detected or and AISP which includes
iii. Incorrect data could be due
undetected. When detected
to: not only the verification
the operator will operate
differently from when he is o wrong data received at process but also the
unaware that the data is local level because deadlines by when the
obsolete. the request is wrong AISP has to submit the
vi. Reverse after passing (human error in draft and the originator
effective date extraction) has to reply.
(cancellation of wrong parameters
updates after wrong query made
publication)
query wrongly
The scenario envisaged is applied (software)
where the new data has data are originally
already been uploaded into
wrong
EAIMS but provider cancels/
delays the implementation o wrong data delivered by
date without respecting the N-conect delivers due to
AIRAC cycle. Thus the software bug
EAIMS data is correct but
not actually in force when mismatched data
originally intended. network
failure/delays
vii. Missing Data
o Information provided too
late or too early
o wrong information in the
data base due to

PSSA Report - EAIMS

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

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
PSSA#1 PSSA#2 PSSA#3

Name Unit Role
1/12/2015 5/01/2016 4/02/2016
MARGAUAN Razvan DG/CS-PMO CS5 Project Manager
CS5 Deputy PM and WP Leader of
AGACDIKEN Nil NMD/NS/EAIM
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
Supporting CFT on NM/CACD
SCOTT Maria NMD/NS/EAIM
aspects
Supporting CS5 on architectural
DERISSON James DG/CS-PMO
matters
Head of Technical Development
TRIBOULET Francois NMD/NTS/SUA
Section
VAN LAETHEM Guido NMD/NTS/SUA Team Leader R3/1
MENDES VIDEIRA Idalina NMD/NSD

PSSA Report - EAIMS
PSSA#1 PSSA#2 PSSA#3

Name Unit Role
1/12/2015 5/01/2016 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

Cast 30

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cast 30

Uploaded by

Copyright:

Available Formats

EAIMS

Edition Number : 1.0

PRELIMINARY SAFETY SYSTEM ASSESSMENT – EAIMS

STATUS, AUDIENCE AND ACCESSIBILITY

Page 2 Released Issue Edition: 1.0

AUTHOR NAME AND SIGNATURE DATE

Senior Safety Expert

AUTHORITY NAME AND SIGNATURE DATE

Programme Manager 22.09.2016

Edition: 1.0 Released Issue Page 3

DOCUMENT CHANGE RECORD

0.1 7/03/2016 Working draft for review ALL

Proposed issue following comments leading to

Tel: +32 (0)2 729 4715

Page 4 Released Issue Edition: 1.0

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

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

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

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

CHAPTER 1 – INTRODUCTION ................................................................................ 9

CHAPTER 2 – PSSA ACTIONS ............................................................................... 13

CHAPTER 3 – PSSA RESULTS .............................................................................. 18

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

Annex A – SAFETY REQUIREMENTS TRACEABILITY TABLES ......................... 27

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

Edition: 1.0 Released Issue Page 5

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

Annex D – REFERENCES ....................................................................................... 41

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

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

Page 6 Released Issue Edition: 1.0

Edition: 1.0 Released Issue Page 7

Page 8 Released Issue Edition: 1.0

1.2 Structure of the risk assessment

Edition: 1.0 Released Issue Page 9

1.3 Completeness and correctness of the PSSA process

1.4 Software Assurance

Page 10 Released Issue Edition: 1.0

1.5 Procedure Assurance

Edition: 1.0 Released Issue Page 11

Page 12 Released Issue Edition: 1.0

CHAPTER 2 – PSSA ACTIONS

Edition: 1.0 Released Issue Page 13

Figure 1 EAIMS high-level architecture diagram

2.2 History of PSSA Activities

Page 14 Released Issue Edition: 1.0

Edition: 1.0 Released Issue Page 15

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

Page 16 Released Issue Edition: 1.0

FH03 Data Discrepancy

2.2.4 Outcome of PSSA Meetings

Edition: 1.0 Released Issue Page 17

CHAPTER 3 – PSSA RESULTS

3.2 Failure modes

Table 2 Functional Hazards and Failure Modes

Page 18 Released Issue Edition: 1.0

Functional Hazard ID and Failure Modes

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

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

CFM-07 Failure FM-FH02 ii Failure

CFM-08 Wrong interpretation of FM-FH03 ii Wrong interpretation

Table 3 Consolidated Failure Modes

Edition: 1.0 Released Issue Page 19