EUROCONTROL Guidelines for the Implementation of Safety ......Assessment or Safety Support Assessment and therefore the current guidelines refer to Easy Access Rules for ATM/ANS (Regulation

EUROCONTROL Guidelines on the Implementation of Safety Support Assessment for AIS/AIM

Edition number: 1.0 Edition date: 07 December 2020 Document reference: EUROCONTROL-GUID-182

AIS/M Domain

EUROCONTROL Guidelines on the Implementation of

Safety Support Assessment for AIS/AIM

DOCUMENT IDENTIFIER : EUROCONTROL-GUID-182

Edition Number : 1.0 Edition Date : 07/12/2020 Status : Released Issue Intended for : General Public Category : EUROCONTROL Guidelines


Page 2 Released Issue Edition: 1.0

DOCUMENT CHARACTERISTICS

TITLE


Publications Reference: GUID-182 ISBN Number: 978-2-87497-109-9

Document Identifier Edition Number: 1.0 EUROCONTROL-GUID-182 Edition Date: 07/12/2020

Abstract This document provides guidance to ensure a common understanding of requirements for the implementation of Safety Support Assessment applicable to AIS providers in the scope of the Commission Implementing Regulation (EU) No 2017/373.

Keywords

AIS AIM Safety management Quality management

Safety Support Assessment

Contact Person(s) E-mail [email protected] [email protected]

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



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

1.0 07/12/2020 Released version prepared by the Aeronautical Information Regulations Implementation Sub-Group (AIRI SG) and approved by the AIM/SWIM Team 19th meeting

All


Edition: 1.0 Released Issue Page 5

CONTENTS

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

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

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

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

LIST OF FIGURES ..................................................................................................... 8

LIST OF TABLES ....................................................................................................... 9

EXECUTIVE SUMMARY .......................................................................................... 11

1. Introduction .................................................................................................... 12 1.1 Purpose of the document ................................................................................... 12 1.2 Scope of the document ....................................................................................... 12 1.3 Conventions ........................................................................................................ 13 1.4 Abbreviations ...................................................................................................... 14 1.5 Definitions ............................................................................................................ 15 1.6 Reference material .............................................................................................. 18 1.7 Document structure ............................................................................................ 19

2. Regulatory Framework................................................................................... 20 2.1 Applicable CIR (EU) 2017/373 Requirements ..................................................... 20 2.2 Reg. (EU) 73/2010 Requirements ........................................................................ 21

3. Changes to an AIS Functional System ......................................................... 22 3.1 AIS Functional System Definition ...................................................................... 22 3.2 Scope and Applicable Requirements ................................................................. 22 3.3 Change Management Procedure ........................................................................ 23 3.4 Notification .......................................................................................................... 25

3.4.1 Synchronizing the SP and CA process ...................................................... 25 3.4.2 Preliminary impact assessment ................................................................. 25 3.4.3 Updating the notification information ........................................................ 26 3.4.4 Clusters of changes .................................................................................... 26 3.4.5 Multi-actors changes ................................................................................... 26

3.5 Contracted Activities ........................................................................................... 26

4. Safety Support Assessment and Safety Support Case ............................... 28 4.1 Scope and Applicable Requirements ................................................................. 28 4.2 Context of SSA and SSC ..................................................................................... 29

4.2.1 Terminology ................................................................................................. 29 4.2.2 SSA and SSC for Multiple Actor Changes ................................................. 30 4.2.3 System Change Lifecycle ............................................................................ 30



4.3 Management of Safety Support Assessment (SSA) .......................................... 34 4.3.1 Prerequisite to start SSA ............................................................................. 34 4.3.2 Safety Plan ................................................................................................... 34 4.3.3 Identification of Failure Conditions ............................................................ 35 4.3.4 Mitigations to Failure Conditions ............................................................... 35 4.3.5 Monitoring Criteria and Process ................................................................. 36

4.4 Contents and Representation of Safety Support Case (SSC) .......................... 37 4.4.1 Purpose of the Safety Support Case .......................................................... 37 4.4.2 Contents of the Safety Support Case ......................................................... 37 4.4.3 Structured Safety Support Case ................................................................. 38

4.5 Human Performance ........................................................................................... 39 4.6 Human Resources, roles and responsibilities .................................................. 39

4.6.1 Responsibility for SSA ................................................................................ 39 4.6.2 Human Resources and Roles ..................................................................... 40

4.7 Stepwise Development of the Safety Support Case ......................................... 41

5. Assurance Levels and Processes ................................................................. 44 5.1 Scope and Applicable Requirements ................................................................. 44 5.2 Software Assurance Process ............................................................................. 44 5.3 Software Assurance levels ................................................................................. 45 5.4 Data Assurance Levels ....................................................................................... 46 5.5 Contracted Software Activities ........................................................................... 46

6. Relationship with the Competent Authorities .............................................. 47 6.1 Scope and Applicable Requirements ................................................................. 47 6.2 Approval of the procedure .................................................................................. 47 6.3 Oversight of change to the Functional System ................................................. 47

Annex A – Example, Table of Contents for an AIS Service Specification .......... 50

Annex B –Example of Structure for Safety Support Case ................................... 51 B.1 Generic Contents of a SSC ......................................................................... 51 B.2 Graphical Representations ......................................................................... 52

Annex C - Generic Principles – Easy-To-Comprehend Human Machine Interface54 C.1 Introduction.................................................................................................. 54 C.2 Objective ...................................................................................................... 54 C.3 Safety............................................................................................................ 54 C.4 Typical Design Errors .................................................................................. 54 C.5 Usability Principles ...................................................................................... 55

C.5.1 Interface Design ................................................................................... 55 C.5.2 Appearance .......................................................................................... 55 C.5.3 Interaction Modes ................................................................................ 55

C.6 User Documentation .................................................................................... 56

Annex D - Example, AIS Functional System Definition ....................................... 57

Annex E - Snapshot Example, Table for AIS Functional System Preliminary Impact



Assessment .................................................................................................... 61

Annex F – Examples, Analysis of Service Behaviour and Failure Conditions .. 64 F.1 Example 1, EUROCONTROL AIS Project ........................................................... 64 F.1.1 Failure Conditions ............................................................................................... 64

F.1.1.1 Data Corruption ........................................................................................... 64 F.1.1.2 Data Unavailability ....................................................................................... 65 F.1.1.3 Data Discrepancy......................................................................................... 65 F.1.1.4 Traceability Tables ...................................................................................... 66

F.1.1.4.1 FC-01 Data Corruption Failure modes, Causal Factors and Potential Causal Mitigations ............................................................................... 66

F.1.1.4.2 FC-02 Data Unavailability Failure modes, Causal Factors and Potential Causal Mitigations ............................................................................... 68

F.2 Example 2 - AISP National Project ..................................................................... 72 F.2.1 Impact Analysis and Mitigation Measure for Non-Compliance with Service

Specifications ...................................................................................................... 72 F.2.1.1 Non-Compliance with Data timeliness Requirements ............................... 72

F.2.1.1.1 at data origination phase ............................................................. 72 F.2.1.1.2 during AIS Data process .............................................................. 72 F.2.1.1.3 during data and information provision ....................................... 73

F.2.1.2 Non-Compliance with Data accuracy requirements .................................. 73 F.2.1.2.1 Data origination process ............................................................. 73 F.2.1.2.2 AIS Data process .......................................................................... 74

F.2.1.3 Non-Compliance with Data resolution requirements ................................ 74 F.2.1.3.1 Data origination process ............................................................. 74 F.2.1.3.2 AIS Data process .......................................................................... 74

F.2.1.4 Non-Compliance with Data integrity requirements ................................... 75 F.2.1.4.1 Data origination process ............................................................. 75 F.2.1.4.2 AIS Data process .......................................................................... 75

Annex G – High level views on the Software ........................................................ 76

Annex H – Software Assurance Levels (1, 2, 3, 4) ............................................... 78

Annex I – Document Update Procedures .............................................................. 80



LIST OF FIGURES

Figure 1: scope of the services .................................................................................................. 13 Figure 2: Links between sections 4, 5 and 6 ............................................................................. 19 Figure 3: Applicable Regulatory Requirements ........................................................................ 20 Figure 4: Change Management Procedure ................................................................................ 24 Figure 5: Details of the Change Management Procedure ........................................................ 24 Figure 6: Contextual view of a change lifecycle ....................................................................... 31 Figure 7: Signatory Roles and Responsibilities ....................................................................... 43 Figure 8: Change Oversight Procedure ..................................................................................... 47



LIST OF TABLES

Table 1: A sample of an SSA Roles and Responsibilities Assignment Matrix. ...................... 42



EXECUTIVE SUMMARY

The EUROCONTROL Guidelines on the Implementation of Safety Support Assessment for AIS/AIM have been developed by the Aeronautical Information Regulations Implementation Sub-Group (AIRI SG) in the context of the AIM/SWIM Team working arrangements to provide Member States with guidance to define, to develop and to implement the Safety Support Assessment for their AIS providers, which is required by Commission Implementing Regulation (EU) No 2017/373.



1. Introduction 1.1 Purpose of the document The EUROCONTROL Guidelines on the Implementation of Safety Support Assessment for AIS/AIM have been developed by EUROCONTROL with the support of AIS experts from Member States, in order to provide guidance on Commission Implementing Regulation (EU) No 2017/373 – hereinafter called in short “CIR 2017/373” – with regard to Safety Support Assessment requirements for AIS providers, for which the applicability date is 02 January 2020. CIR 2017/373 [4] was initially published on 1 March of 2017 [4]. Commission Implementing Regulation (EU) 2020/469 of 14 February 2020 [3] has amended Regulation (EU) No 923/2012, Regulation (EU) No 139/2014 and Regulation (EU) 2017/373 as regards requirements for air traffic management/air navigation services, design of airspace structures and data quality, runway safety and repealing Regulation (EC) No 73/2010. Consequently, the current guidelines, when referring to CIR 2017/373, formally address the “CIR (EU) No 2017/373 as amended by CIR (EU) No 2020/469”. However, CIR (EU) 2020/469 does not introduce any new requirements in respect to Safety Assessment or Safety Support Assessment and therefore the current guidelines refer to Easy Access Rules for ATM/ANS (Regulation (EU) 2017/373 of 1 March 2017) – December 2019 [6]. The guidelines are aimed at providing AIS organisations with practical guidance, examples, illustrative material and best practises in order for them to meet the expected safety support management objectives and conduct a safety support assessment.

1.2 Scope of the document Commission Implementing Regulation (EU) No 2017/373 defines two different approaches on the way the Air Traffic Management/Air Navigation Services providers should consider managing changes to their functional system:

- a Safety Assessment to be performed by the Air Traffic Service (ATS) providers, - or a Safety Support Assessment to be performed by service providers other than providers

of ATS. Article 6 ‘Service providers’ of CIR 2017/373 provides an overview of the requirements applicable to Air Traffic Management/Air Navigation Service Providers. Provisions for the AIS providers are contained in the following annexes of the CIR 2017/373:

a) for all service providers, the requirements laid down in Annex III (Part-ATM/ANS.OR), Subparts A and B, and in Annex XIII (Part-PERS);

b) for service providers other than providers of air traffic services, in addition to the requirements of point (a), the requirements laid down in Annex III (Part-ATM/ANS.OR), Subpart C;

c) for providers of aeronautical information services, in addition to the requirements of points (a), (b) and (c), the requirements laid down in Annex VI (Part-AIS);

To identify how the annexes apply to the AIS provider in the context of Safety Support Assessment, it is necessary to understand how the services are defined. More specifically, CIR 2017/373 defines different approaches between the ATS providers, for which the Safety Assessment applies, and the service providers other than ATS providers, for which the Safety Support Assessment applies. Several organisational configurations between ANSP, ATSP and AISP are possible. Both ATS and AIS services or just one of them may be embedded into a single ANSP.



Several organisational configurations between ANSP, ATSP and AISP are possible. ATSP and AISP may be stand-alone entities. Both ATS and AIS services or just one of them may be embedded into a single ANSP. Figure 1 below, as defined in Easy Access Rules for ATM-ANS [6], provides a pictorial representation of the services and how they interrelate through the various definitions and it is important to note that there is no overlapping between AIS and ATS and that both are included in ANS.

Figure 1: scope of the services

From the AIS perspective, two types of generic organisations can be defined:

- The AIS is delivered by an autonomous provider, which clearly falls under the category of a ‘service provider other than ATS providers’. A Safety Support Assessment shall be carried out on the basis of the AIS service specification, which defines the Functional System applicable to the AIS provider, including the interfaces with the ATS service (delivered by an autonomous ATS provider or by an ANS provider);

- The AIS is delivered by an ANS provider that delivers ATS services as well. In this case the ANSP may implement, for the AIS, CIR 2017/373 requirements related to ‘service provider other than ATS providers’ and as a result should carry out a Safety Support Assessment on the basis of the AIS service specification. The ANSP may also consider the AIS Service in a more integrated approach and should perform a Safety Assessment including the AIS provision in accordance with CIR 2017/373 requirements related to ‘providers of Air Traffic Services’. In this configuration, the AIS Service is considered as an element of the Safety Assessment, which is not the scope of the guidelines.

As a consequence, the AIS falls into the category of service providers other than providers of air traffic services and therefore the guidelines focuses on the Safety Support Assessment.

1.3 Conventions EUROCONTROL guidelines, as defined in the EUROCONTROL Regulatory and Advisory Framework (ERAF), are advisory materials and contain: “Any information or provisions for physical characteristic, configuration, material, performance, personnel or procedure, the use of which is recognised as contributing to the establishment and



operation of safe and efficient systems and services related to ATM in the EUROCONTROL Member States.” Therefore, the application of EUROCONTROL guidelines is not mandatory. In addition, ERAF specifies that: “EUROCONTROL Guidelines may be used, inter alia, to support implementation and operation of ATM systems and services, and to:

• complement EUROCONTROL Rules and Specifications; • complement ICAO Recommended Practices and Procedures; • complement EC legislation; • indicate harmonisation targets for ATM Procedures; • encourage the application of best practice; • provide detailed procedural information.”.

Guidelines using the term “should” are recommended, whereas guidelines using the term “may” are optional. The term “shall” is used where appropriate in the context of ICAO SARPs or European regulatory references. The maintenance procedures for these guidelines are described in detail in Annex I.

1.4 Abbreviations ADQ IR Aeronautical Data Quality Implementing Rule AIRAC Aeronautical Information Regulation And Control AIRI SG Aeronautical Information Regulations Implementation Sub-Group AIP Aeronautical Information Publication AIS Aeronautical Information Services AIM Aeronautical Information Management AISP Aeronautical Information Service Providers AMC Acceptable Means of Compliance ANS Air Navigation Services ANSP Air Navigation Services Provider APT Airport ATCO Air Traffic Controller (Air Traffic Control Officer) ATM Air Traffic Management ATS Air Traffic Services ATSEP Air Traffic Safety Electronics Personnel ATSP Air Traffic Services Provider CA Competent Authority CEO Chief Executive Officer CFSP Computerised Flight Plan Service Provider CIR Commission Implementing Regulation EAD European AIS Database



EASA European Union Aviation Safety Agency EU European Union EUROCAE European Organisation for Civil Aviation Equipment FPD Flight procedure design FS Functional System GM Guidance Material GSN Goal Structured Notation HMI Human Machine Interface ICAO International Civil Aviation Organization IDB Integrated Database IR Implementing Regulation ISO International Organization for Standardisation HOD Head of Department MS Management System MTBF Mean Time Between Failure MTTR Mean Time To Repair NOTAM Notice to Airmen NSA National Supervisory Authority PAL Procedure Assurance Level PENS Pan-European Network Service QMS Quality Management System SDO Static Data Operation SP Services Provider SSA Safety Support Assessment SSC Safety Support Case SMS Safety Management System SWAL Software Assurance Level

1.5 Definitions ‘Aeronautical information services provider (AIS provider)’ as defined in CIR 2017/373 means an organisation responsible for the provision of an aeronautical information service; ‘Air Navigation Services (ANS)’ as defined in Article 2(4) of Regulation (EC) No 549/2004 means:

- air traffic services; - communication, navigation and surveillance services; - meteorological services for air navigation; - and aeronautical information services;

‘Air traffic management (ATM)’ as defined in Article 2(10) of Regulation (EC) No 549/2004 means the aggregation of the airborne and ground-based functions (air traffic services, airspace



management and air traffic flow management) required to ensure the safe and efficient movement of aircraft during all phases of operations; ‘Argument’ as defined in Easy Access Rules for ATM-ANS [6] means a claim that is supported via inferences by a body of evidence; ‘Assurance case’ as defined in EASA Notice of Proposed Amendment 2014-13 is the collective noun used for either safety cases or safety support cases. ‘Assurance case report’ as defined in EASA Notice of Proposed Amendment 2014-13 is the collective noun used for either safety case reports or safety support case reports. ‘ATM/ANS’ as defined in Article 3(5) of Regulation (EC) No 2018/139 means air traffic management and air navigation services and covers all of the following: the air traffic management functions and services as defined in point (10) of Article 2 of Regulation (EC) No 549/2004; the air navigation services as defined in point (4) of Article 2 of that Regulation, including the network management functions and services referred to in Article 6 of Regulation (EC) No 551/2004, as well as services which augment signals emitted by satellites of core constellations of GNSS for the purpose of air navigation; flight procedure design; and services consisting in the origination and processing of data and the formatting and delivering of data to general air traffic for the purpose of air navigation;

‘Audit’ as defined in Easy Access Rules for ATM-ANS [6] means a systematic, independent and documented process for obtaining evidence and evaluating it objectively to determine the extent to which requirements are complied with; ‘Configuration data’ as defined in Easy Access Rules for ATM-ANS [6] means the data that configures a generic software system to a particular instance of its use; ‘Contracted activities’ as defined in Easy Access Rules for ATM-ANS [6] means those activities within the service provision conditions attached to the service provider’s certificate that are performed by other organisations either themselves certified to carry out such an activity or if not certified, working under the service provider’s oversight; ‘Data integrity’ as defined in CIR 2017/373 means a degree of assurance that aeronautical data and its value has not been lost or altered since the data origination or authorised amendment; ‘Data item’ as defined in CIR 2017/373 means a single attribute of a complete data set, which is allocated a value that defines its current status ‘Data quality’ as defined in Easy Access Rules for ATM-ANS [6] means a degree or level of confidence that the provided data meets the user's data requirements in terms of accuracy, resolution, integrity (or equivalent assurance level), traceability, timeliness, completeness, and format; ‘Data quality requirements (DQRs)’ as defined in Easy Access Rules for ATM-ANS [6] means a specification of the characteristics of data (i.e. accuracy, resolution, integrity (or equivalent assurance level), traceability, timeliness, completeness and format) to ensure that the data is compatible with its intended use; ‘Functional system’ as defined in Easy Access Rules for ATM-ANS [6] means a combination of procedures, human resources and equipment, including hardware and software, organised to perform a function within the context of ATM/ANS and other ATM network functions;



‘Independent software components’ as defined in Easy Access Rules for ATM-ANS [6] means software components which are not rendered inoperative by the same failure condition. ‘Safety support assurance’ as defined in EASA Notice of Proposed Amendment 2014-13 argues that the service behaves only as specified (the safety support case must argue that the specification as stated is complete and correct, i.e. the service behaves only as specified in the specified context (this is not necessarily the complete statement of the way it behaves; it is limited to the ways that the user can access, i.e. that which is constrained by the context of use). ‘Safety Support Case’ means a document which clearly and comprehensively presents sufficient arguments, evidence and assumptions that system impacts have been identified and controlled for both engineering and operational areas to demonstrate that a facility, facilities or organisation is/are adequately safe in air traffic service requests. ‘Safety Support Case report for a change’ as defined in EASA Notice of Proposed Amendment 2014-13 identifies the arguments (claims, inferences and evidence) of the safety support case (although not necessarily all of them), but will probably not include the bulk of the supporting evidence due to the practicalities of providing it in the report. The service provider is obliged to facilitate access to any of this additional information that the regulator Competent Authority requires for the evaluation. ‘Safety Management System (SMS)’ means a systematic approach to managing safety, including the necessary organisational structures, accountabilities, policies, and procedures.

‘Service Provider’ as defined in Article 2 of CIR 2017/373 means any legal or natural person providing functions and/or services of ATM/ANS and/or other ATM network functions, either individually or bundled for general air traffic, ‘Software’ as defined in Easy Access Rules for ATM-ANS [6] means the computer programmes and corresponding configuration data, including non-developmental software, but excluding electronic items, namely application-specific integrated circuits, programmable gate arrays or solid-state logic controllers. ‘Software components’ as defined in Easy Access Rules for ATM-ANS [6] means a building block that can be fitted or connected together with other reusable blocks of software to combine and create a custom software application. ‘Independent software components’ as defined in Easy Access Rules for ATM-ANS [6] means software components which are not rendered inoperative by the same failure condition. ‘Software assurance level (SWAL)’ as defined in EUROCAE ED-153 [9]means the level of rigour of the software assurances throughout the software lifecycle, supporting the demonstration that the European Air Traffic Management Network (EATMN) software is acceptability safe.

In addition, AIS.OR.100 and AIS.TR.100 define what is expected from aeronautical information services providers in terms of technical and operational competence, capability, working methods and operating procedures for the provision of aeronautical information services. AIS.OR.100 Technical and operational competence and capability

a) An aeronautical information services provider shall ensure that information and data are available for operations in a form suitable for: (1) flight operating personnel, including flight crew; (2) flight planning, flight management systems and flight simulators; (3) air traffic services providers which are responsible for flight information services, aerodrome flight information services and the provision of pre-flight information.



b) Aeronautical information services providers shall ensure the integrity of data and confirm the level of accuracy of the information distributed for operations, including the source of such information, before such information is distributed.

AIS.TR.100 Working methods and operating procedures for the provision of aeronautical information services An aeronautical information services provider shall be able to demonstrate that their working methods and operating procedures are compliant with the standards in the following Annexes to the Chicago Convention as far as they are relevant to the provision of aeronautical information services in the airspace concerned:

a) Annex 4 on aeronautical charts in its 11th edition of July 2009, including all amendments up to and including No 58;

b) without prejudice to Commission Regulation (EU) No 73/2010, Annex 15 on aeronautical information services in its 14th edition of July 2013, including all amendments up to and including No 38.

1.6 Reference material [1] Regulation (EC) No 549/2004 of 10 March 2004 laying down the framework for the creation

of the single European sky (the framework Regulation);

[2] Commission Regulation (EU) No 73/2010 of 26 January 2010 laying down requirements on the quality of aeronautical data and aeronautical information for the single European sky;

[3] Commission Implementing Regulation (EU) 2020/469 of 14 February 2020 amending Regulation (EU) No 923/2012, Regulation (EU) No 139/2014 and Regulation (EU) 2017/373 as regards requirements for air traffic management/air navigation services, design of airspace structures and data quality, runway safety and repealing Regulation (EC) No 73/2010;

[4] Commission Implementing Regulation (EU) No 2017/373 of 1 March 2017 laying down common requirements for providers of air traffic management/air navigation services and other air traffic management network functions and their oversight, repealing Regulation (EC) No 482/2008, Implementing Regulations (EU) No 1034/2011, (EU) No 1035/2011 and (EU) 2016/1377 and amending Regulation (EU) No 677/2011;

[5] Regulation (EU) 2018/1139 of the European Parliament and of the Council of 4 July 2018 on common rules in the field of civil aviation and establishing a European Union Aviation Safety Agency, and amending Regulations (EC) No 2111/2005, (EC) No 1008/2008, (EU) No 996/2010, (EU) No 376/2014 and Directives 2014/30/EU and 2014/53/EU of the European Parliament and of the Council, and repealing Regulations (EC) No 552/2004 and (EC) No 216/2008 of the European Parliament and of the Council and Council Regulation (EEC) No 3922/91;

[6] Easy Access Rules for Air Traffic Management/Air Navigation Services (Regulation (EU) 2017/373 of 1 March 2017) – December 2019;

[7] EUROCONTROL Specification for Data Assurance Levels, edition 1.1, 28/03/2018, EUROCONTROL-SPEC-148;

[8] EUROCAE ED-76A/RTCA DO-200B — Standards for Processing Aeronautical Data (only for AIS providers), June 2015;

[9] EUROCAE ED-153 - Guidelines for ANS Software Safety Assurance, August 2009;

[10] EUROCAE ED-215/RTCA DO330 - Software Tool Qualification Considerations;



[11] CAP 760 Guidance on the Conduct of Hazard Identification, Risk Assessment and the Production of Safety Cases For Aerodrome Operators and Air Traffic Service Providers;

[12] EUROCONTROL Safety Case Development Manual, Edition 2.2, Edition Date 13 Nov 2006;

[13] GSN COMMUNITY STANDARD VERSION 1 © 2011 Origin Consulting (York).

1.7 Document structure This document is organized as follows:

• Section 1 introduces the guidelines and defines the scope; • Section 2 presents the regulatory framework applicable to the Safety Support Assessment; • Section 3 defines how the AIS should deal with the changes to an AIS Functional System in

terms of procedures, tools and products; • Section 4 defines how the Safety Support Assessment should be managed in support to the

change management defined at Section 3; • Section 5 defines how assurance should be managed in support to the change

management defined at Section 3; • Section 6 defines the relationship with the Competent Authority.

The links between sections 3, 4, 5 and 6 are described in figure 2 below.

Figure 2: Links between sections 4, 5 and 6

Section 3: Changes to AIS Functional System

Section 4: Safety Support Assessment and Safety Support Case

Section 5: Assurance Levels and Processes

Section 6: Relationship with the Competent Authorities



2. Regulatory Framework 2.1 Applicable CIR (EU) 2017/373 Requirements

Figure 3: Applicable Regulatory Requirements

As ‘service providers other than ATS providers’, the providers of AIS Services shall implement the relevant CIR 2017/373 requirements (figure 3) to support the Safety Support Assessment. The applicable requirements are listed below:

• ANNEX II — PART-ATM/ANS.AR Requirements for Competent Authorities — Oversight of Services and Other ATM Network Functions

SUBPART C — OVERSIGHT, CERTIFICATION AND ENFORCEMENT (ATM/ANS.AR.C)

o ATM/ANS.AR.C.010 Oversight; o ATM/ANS.AR.C.030 Approval of change management procedures for functional

systems; o ATM/ANS.AR.C.035 Decision to review a notified change to the functional system; o ATM/ANS.AR.C.040 Review of a notified change to the functional system;

• ANNEX III — PART-ATM/ANS.OR COMMON REQUIREMENTS FOR SERVICE

PROVIDERS

SUBPART A — GENERAL REQUIREMENTS (ATM/ANS.OR.A)

o ATM/ANS.OR.A.045 Changes to a functional system; o ATM/ANS.OR.A.040 Changes — general; o ATM/ANS.OR.A.050 Facilitation and cooperation;

SUBPART B — MANAGEMENT (ATM/ANS.OR.B)

o ATM/ANS.OR.B.005 Management system;



o ATM/ANS.OR.B.010 Change management procedures; o ATM/ANS.OR.B.015 Contracted activities;

SUBPART C — SPECIFIC ORGANISATION REQUIREMENTS FOR SERVICE PROVIDERS OTHER THAN ATS PROVIDERS (ATM/ANS.OR.C)

o ATM/ANS.OR.C.005 Safety Support Assessment and assurance of changes to the functional system.

As explained in section 1.2, where the AIS is considered as integrated into the ANSP, a Safety Assessment should be carried out in accordance with Annex IV “Part –ATS Specific Requirements for Providers of Air Traffic Services”, requirements ATS.OR.205 “Safety Assessment and assurance of changes to the functional system” and “ATS.OR.210 Safety criteria”, for which a short description is provided in section 3.2 The AIS provider will contribute to the Safety Assessment to be conducted by the ANSP. The Safety Assessment is not within the scope of the guidelines.

2.2 Reg. (EU) 73/2010 Requirements

CIR 2017/373 defines two approaches for managing changes to the service providers’ functional system. The ATS providers have to perform safety assessments and the non-ATS providers have to perform safety support assessments. The applicability date for CIR 2017/373 requirements referring to safety assessments and safety support assessments is 02 January 2020.

As mentioned in section 1.2 Scope of the document, AIS providers are considered as service providers other than providers of air traffic services and as a result they have to implement safety management according to the following principles:

• The AIS providers need to perform Safety Support Assessments in accordance with the requirements of CIR 2017/373;

• The AIS providers do not need to carry out Safety Assessments and as a consequence do not have to be compliant with Reg. (EU) No 73/2010 regarding safety management;

• The EUROCONTROL Guidance for the implementation of safety management objectives and safety assessments falling within the scope of EU Regulation 73/2010, Edition 2.0, Nov.2014, does not apply as from 02 January 2020.

As a consequence, the Reg. (EU) No 73/2010 requirements do not apply to AIS in the framework of the safety support assessment.



3. Changes to an AIS Functional System 3.1 AIS Functional System Definition CIR 2017/373 defines a ‘functional system’ as a combination of procedures, human resources and equipment, including hardware and software, organised to perform a function within the context of ATM/ANS and other ATM network functions.

In order to identify and understand changes to the functional system, it is important to clearly define the AIS functional system before starting the Change Management Procedure. Annex D provides an example of AIS Functional System.

3.2 Scope and Applicable Requirements Following CIR 2017/373 requirements, AMC and GM apply for the management of changes to an AIS functional system:

• ATM/ANS.OR.B.005 Management system1, which defines the obligation for all ATM/ANS providers to have a management system in place that includes a procedure for systematically identifying all its changes including its changes to the functional system. It is particularly important to take the following requirements and GM into consideration:

o ATM/ANS.OR.B.005 (a)(4), which focuses on a process to identify changes

(including changes to the functional system); o GM1 ATM/ANS.OR.B.005(a)(4) Management system, which provides guidance to

support the identification of changes; o ATM/ANS.OR.B.005 (f), which focuses on the formal interfaces to be put in place

with relevant service providers and aviation undertakings. This should ensure that adequate coordination is in place between the different stakeholders and, in the specific case of change to the F.S., the dependencies and shared assumptions are addressed;

• ATM/ANS.AR.C.035 Decision to review a notified change to the functional system, which

defines the obligation for the Competent Authority to make a decision on whether to review the change or not;

• ATM/ANS.OR.A.040 Changes – General, which defines the obligation for all ATM/ANS providers to notify and to manage all their changes, i.e. changes to the F.S. or changes that are not to the F.S. (the service provider's management system and/or safety management system). The current guidelines focus on changes to the F.S. and will here be limited to addressing the requirement in ATM/ANS.OR.A.040(a)(1);

• ATM/ANS.OR.B.010 Change management procedures, which defines the obligation for all

ATM/ANS providers to have a procedure for managing changes to its functional system approved by its Competent Authority. It refers to other requirements, GM and AMC further specifying the details of the procedure:

o ATM/ANS.OR.A.045 Changes to a functional system, which defines the obligation

for all ATM/ANS providers to notify all planned changes to the functional system to

1 Note that in the specific case where the AIS Provider is also an ATS provider, this article is complemented by the need for a Safety

Management System as described in ATS.OR.200 Safety management system.



the Competent Authorities and further details the practicalities of coordination with the Competent Authority and affected parties;

o AMC1 ATM/ANS.OR.A.045(a), which provides recommendations to ensure the

completeness of the notification of a change;

o ATM/ANS.OR.C.005 Safety Support Assessment and assurance of changes to the functional system, which defines the obligation for the service provider other than the air traffic services provider to ensure that a Safety Support Assessment is carried out and to provide assurance, with sufficient confidence, via a complete, documented and valid argument, that the service will behave and will continue to behave only as specified in the specified context;

o ATS.OR.205 Safety Assessment and assurance of changes to the functional

system2, which defines the obligation for the air traffic services provider to ensure that a Safety Assessment is carried out and to provide assurance, with sufficient confidence, via a complete, documented and valid argument that the safety criteria identified via the application of point ATS.OR.210 are valid, will be satisfied and will remain satisfied;

o ATS.OR.210 Safety criteria2, which defines the obligations for the air traffic service

providers to determine the safety acceptability of a change to a functional system;

• Additional requirements: o ATM/ANS.OR.B.015 Contracted activities, which defines the conditions and

practicalities when an ATM/ANS provider is using ‘contracted activities” to support its operations;

o ATM/ANS.OR.A.050 Facilitation and cooperation, which defines the obligation for all the ATM/ANS providers to support and facilitate the oversight of their activities by their Competent Authority.

3.3 Change Management Procedure The procedure to manage changes to the functional system is regulated through ATM/ANS.OR.B.010. It is initiated by the systematic identification of changes as described in ATM/ANS.OR.B.005(a)(4). Figures 4 and 5, below, describe a generic process to ensure compliance with those applicable requirements. This process is to be applied for all planned changes to the functional system. Note: it is understood that the application of the procedure needs to be commensurate with the change to be managed. The amount of effort to address the different steps will depend on the magnitude of the change itself.

2 For an AISP that is part of an ANSP delivering ATS services, it is considered that they can refer to their SMS and the associated safety

assessment process. Therefore, safety assessment (and management of safety criteria) is not further discussed in this document.



Figure 4: Change Management Procedure

Note: the CA may require more information than is initially provided but the loop is not represented in figure 4.

Figure 5: Details of the Change Management Procedure

As described in figures 4 and 5, the AIS provider has to perform the following tasks for managing changes to its functional system:

1. The service provider shall have in place a process to systematically identify all planned changes, including changes to the functional system as defined in ATM/ANS.OR.B.005(a)(4) and GM1 ATM/ANS.OR.B.005(a)(4);

2. The procedure to manage changes to the functional system shall comply with ATM/ANS.OR.B.010. As part of managing any change, the service provider shall ensure that:

a. the procedure used is approved by the Competent Authority (ATM/ANS.AR.C.030), b. the change is notified to the Competent Authority (ATM/ANS.OR.A.045),



c. a Safety Support Assessment is performed and formalized in a Safety Support Argument/Case (ATM/ANS.OR.C.005);

3. The Competent Authority shall: a. Approve the procedure proposed by the service provider (ATM/ANS.AR.C.030) for

managing changes to the functional system. b. For the concerned change to the functional system, perform the adequate level of

oversight i. Based on the notification of the change, the Competent Authority decides if it

wishes to have a review (or not) of the concerned change to the functional system (ATM/ANS.AR.C.035),

ii. The Service Provider (SP) shall only allow the parts of the change for which the activities required by the approved procedures have been completed (ATM/ANS.OR.A.045(c)),

iii. In the case where the Competent Authority (CA) has decided to review the concerned change, the CA will provide an approval for the validity of the safety support argument (ATM/ANS.AR.C.040). The service provider shall wait for that approval of the Competent Authority before deploying the changed functional system ATM/ANS.OR.A.045(d)),

iv. In all cases, the Competent Authority has the opportunity during its ongoing oversight activities to come back on certain changes and ask for evidence that the procedure has been followed (ATM/ANS.AR.C.010);

4. Only once the procedure has been completed (ATM/ANS.OR.A.045(c)) and depending on whether or not the Competent Authority decides to review (see above), the SP will transfer and operate the changed functional system. During the operations, the SP has to demonstrate that the service provided by the functional system behaves and will continue to behave only as specified in the specified context (ATM/ANS.OR.C.005 (a)(2) and (b)).

3.4 Notification 3.4.1 Synchronizing the SP and CA process The notification is regulated by article ATM/ANS.OR.A.045 ((a)(1), (a)(2) and (b)). Its main objective is to inform the CA about a change and initiate the synchronization between the SP and the CA for the management and oversight of the concerned change. The notification information should be used by the CA to make the decision on whether or not to review the concerned change (ATM/ANS.AR.C.035).

3.4.2 Preliminary impact assessment A minimum set of information and data to support the notification is proposed in the AMC1 ATM/ANS.OR.A.045(a). This implies that the SP has a process in place to understand the scope and the impact of the concerned change on its functional system and on its operations. This results in the SP only performing the notification when it has understood what the change is.3 On the other hand, GM1 ATM/ANS.OR.A.045(a) highlights the fact that “early and accurate” notification facilitates the interaction and synchronization between the SP and its CA. It is important to note that an agreement needs to be reached between the SP and the CA on the content and timing of the notification. A notification performed too early would not gather the adequate information and not allow the CA to adequately make the decision on whether or not to review the concerned change. A notification made very late in the change project would not allow for a valuable interaction between the SP and the CA.

3 If the SP has not understood what the change is; it cannot reasonably consider having understood the impact on its service (safety risk

or service specifications) and therefore cannot demonstrate having mitigated that impact.



Annex E provides a snapshot example of a table that could be delivered as a Preliminary Impact Assessment for the AIS Functional System.

3.4.3 Updating the notification information ATM/ANS.OR.A.045 (b) requires the SP to update the notification information when it is changed. In the dynamic coordination between the SP and the CA, this would allow information not available at the early notification to be produced at a later stage and would permit having the CA to make the decision on whether or not to review when the updated documentation set is available. ATM/ANS.AR.C.035 (a) allows the CA to seek additional information in order for it to make the decision.

3.4.4 Clusters of changes Article ATM/ANS.OR.A.045 requires that “A service provider planning a change to its functional system shall (1) notify the Competent Authority of the change”. In practice, the SP could create different clusters or types of changes that would lead to different notification to be performed. The differences could be in terms of content and timing of the notification. This would also make it possible to apply the change management procedure (described in section 3.3) in a way that is commensurate with the change, with the required effort and with the need for assurance in function of the complexity of the change itself. In order to setup a fluid and streamlined process with the CA and as this is a part of the compliance with article ATM/ANS.OR.045, it is subject to coordination with the CA (for the technicalities) and subsequent approval (as part of ATM/ANS.OR.B.010) from the CA.

3.4.5 Multi-actors changes Article ATM/ANS.OR.A.045 point (a)(3) requires other service providers and aviation undertakings affected by the change to be informed and point (e) and (f) highlight the need for coordination between the affected parties in order to ensure that the dependencies, assumptions or shared mitigations are determined and managed.

3.5 Contracted Activities The AIS provider may contract certain activities to external organisations. Contracted activities may include all the activities within the scope of the AIS provider's operations in accordance with the terms of the certificate required under CIR 2017/373. The AIS provider shall ensure that when contracting or purchasing any part of their activities to external organisations, the contracted or purchased activity, system or constituent conforms to the applicable requirements under CIR 2017/373, as defined in ATM/ANS.OR.B.015 Contracted activities (a). When an external organisation is not itself certified in accordance with CIR 2017/373, the AIS provider shall ensure that the contracted organisation works under its oversight and that the Competent Authority is given access to the contracted organisation to determine continued compliance with the applicable CIR 2017/373 requirements as defined in ATM/ANS.OR.B.015 Contracted activities (b). Ultimate responsibility for the services developed and delivered by the contracted organisations always remains with the contracting AIS providers and consequently the AIS providers should take the following measures:



• define the relevant management responsibilities within its own organisation, in particular the required resources in terms of staff, in order to enable the contracted activities (GM1 ATM/ANS.OR.B.015);

• conduct a prior audit of the contracted party to ensure that the contracted organisation is able to perform the contracted activities (GM2 ATM/ANS.OR.B.015);

• ensure that the contracted organisation has the necessary authorisation, declaration or approval when required, and commands the resources and competence to undertake the task (AMC1 ATM/ANS.OR.B.015 (c) );

• ensure a contract exist with the contracted organisation clearly defining the contracted activities and the applicable requirements (AMC1 ATM/ANS.OR.B.015 (a) );

• consider in the applicable requirements the competence of the engineering/technical personnel of the contractor (GM1 to AMC1 ATM/ANS.OR.B.015);

• ensure that all contracted activities are subject to compliance monitoring (ATM/ANS.OR.B.005(c), GM3 ATM/ANS.OR.B.015);

• undertake compliance monitoring of the contracted certified external organisation and at least check that the certificate effectively covers the contracted activities (GM4 ATM/ANS.OR.B.015);

• carry out oversights that cover the contracted activities if the external organisation is not itself certified in accordance with this Regulation (GM1, GM4 ATM/ANS.OR.B.015, AMC1 ATM/ANS.OR.B.015 (b) ).

A contract can take the form of a written agreement, letter of agreement, service letter agreement, memorandum of understanding, etc. as appropriate for the contracted activities (GM2 ATM/ANS.OR.B.015). The contract should embrace at least the following issues:

• Applicable regulatory requirements from CIR 2017/373; • Services to be delivered; • Non-functional requirements such as:

o Availability, o Quality, o Accuracy, o Integrity,

• Performance, Tracking and Reporting; • Management of incidents:

o Details of preventive maintenance, o Process on how to resolve unplanned stoppages, o Reaction time (to site), o MTTR (Mean time to repair/recovery), o Formal records & logs to be maintained of all problems, o Contingency plan,

• Legal Compliance & Resolution of Disputes; • ANSP Duties & Responsibilities; • Security; • Confidential Information; • Termination.



4. Safety Support Assessment and Safety Support Case

4.1 Scope and Applicable Requirements A Safety Support Assessment needs to be performed when a change affects a part of the functional system managed by the AIS provider (other than an air traffic services provider).

Following CIR 2017/373 requirement, AMC and GM apply: • ATM/ANS.OR.C.005 Safety Support Assessment and assurance of changes to the

functional system : (a) For any change notified in accordance with point ATM/ANS.OR.A.045(a)(1), the service provider other than the air traffic services provider shall:

(1) ensure that a Safety Support Assessment is carried out covering the scope of the change which is:

(i) the equipment, procedural and human elements being changed; (ii) interfaces and interactions between the elements being changed and the remainder of the functional system; (iii) interfaces and interactions between the elements being changed and the context in which it is intended to operate; (iv) the life cycle of the change from definition to operations including transition into service; (v) planned degraded modes.

(2) provide assurance, with sufficient confidence, via a complete, documented and valid argument that the service will behave and will continue to behave only as specified in the specified context.

(b) A service provider other than an air traffic services provider shall ensure that the Safety Support Assessment referred to in point (a) comprises:

(1) verification that:

(i) the assessment corresponds to the scope of the change as defined in point (a)(1); (ii) the service behaves only as specified in the specified context; (iii) the way the service behaves complies with and does not contradict any applicable requirements of this Regulation placed on the services provided by the changed functional system; and

(2) specification of the monitoring criteria necessary to demonstrate that the service delivered by the changed functional system will continue to behave only as specified in the specified context.

• AMC1 ATM/ANS.OR.C.005(a)(2) FORM OF ASSURANCE Service providers other than air traffic services providers should ensure that the assurance is documented in a safety support case.

• AMC2 ATM/ANS.OR.C.005(a)(2) and GM1 to AMC2 ATM/ANS.OR.C.005(a)(2) COMPLETENESS OF THE ARGUMENT, which provide the scope and the expected contents of the safety support requirements and the service specification.

• GM3 ATM/ANS.OR.C.005(a)(2) SAFETY SUPPORT REQUIREMENTS, which provides some examples of safety support requirements for equipment, for people and for procedures.



4.2 Context of SSA and SSC 4.2.1 Terminology It is important to highlight and to define the key words and concepts supporting the Safety Support Assessment (SSA) and Safety Support Case (SSC) in order to clearly understand the context. EASA Notice of Proposed Amendment 2014-13, which eventually became CIR 2017/373, had proposed (page 124) the following definitions, most of them being already provided in section 1.5. Safety support assurance Argues that the service behaves only as specified127 in the

specified context.128 127: The safety support case must argue that the specification as stated is complete and correct, i.e. the service behaves only as specified. 128: This is not necessarily the complete statement of the way it behaves; it is limited to the ways that the user can access, i.e. that which is constrained by the context of use.

Safety support case (SSC) A structured documented argument, supported by evidence, that provides a compelling, comprehensible and valid justification that the system behaves only as specified in a given context.

Safety support case report The safety support case report for a change will identify the arguments (claims, inferences and evidence) of the safety support case (although not necessarily all of them), but will probably not include the bulk of the supporting evidence due to the practicalities of providing it in the report. The service provider is obliged to facilitate access to any of this additional information that the regulator Competent Authority requires for the evaluation.

Safety Support Assessment (SSA)

All the activities required to produce a safety support case, i.e. all the activities defined in ATM/ANS.OR.C.005.

Assurance case The collective noun used for either safety cases or safety support cases.

Assurance case report The collective noun used for either safety case reports or safety support case reports.

Requirement A thing that is needed or wanted (it will be or will do); a necessary condition.

Specification A precise and detailed definition of what a thing is claimed to be and to do.

A Safety Support Assessment (SSA) can be considered as the set of activities carried out in order to study the impact on service behaviour resulting from any change in the AIS functional system (FS). A functional system consists of people, procedures and equipment operating within a specific context of operations. A change in the context of operations, including a change in the concept of operations, will require a safety support assessment. The safety support case (SSC) is a set of one or more documents that includes claims, arguments and evidence that a system meets its requirements. A SSC provides, both to the service providers themselves and to the Competent Authority (CA), all the documentation and references necessary to demonstrate that a new system or a change to an existing system will behave and will continue to behave only as specified in the specified context. During the life of a system or the development of a project there may be several iterations to the SSC as more detailed system design and performance information becomes available. The SSC is, therefore, a 'living document' and should be developed along with the lifecycle of the system. Work on the SSC should therefore begin when a project is at its initial concept phase and the content should be added to as the project progresses throughout its lifecycle.



Once the changed/new system has transitioned into everyday operation, the SSC, through the monitoring criteria, becomes the continuous demonstration that the service is provided as specified in the specified context until the removal from service (decommissioning) of the now obsolete/defunct system. The development of a SSC is not an alternative to carrying out a SSA. It is a means of structuring and documenting the results of the SSA, in a way that a reader can readily follow the logical reasoning as to why a change can be considered to behave and will continue to behave only as specified in the specified context.

4.2.2 SSA and SSC for Multiple Actor Changes A change as defined in ATM/ANS.OR.A.045(e) may involve more than one service provider changing their functional systems. This change is rendered more complicated and complex due to dependencies between the service provider(s) that planned the change and other affected service providers and/or other aviation undertakings. The SSA and the SSC together with the associated tools and approaches are aimed at supporting decision-making. Most tools and approaches assume that ultimately there is one decision-maker with clearly defined objectives, e.g. Head of Unit/Head of Division/CEO following the organisation’s policy and plans. However, in the case of multiple-actor changes, there would be multiple decision-makers with differing perspectives and activities. Consequently, the interaction between the decision makers is an additional uncertainty that needs to be addressed because action is required at multiple scales and by multiple actors. Effective multi-actor changes therefore require sufficient engagement of the stakeholders. In the case of changes involving equipment mitigation means will need to address also the maintenance of the system after it has been transferred into service and should include:

• Maintenance plan (details of maintenance activities, including details of on-site support from Manufacturer, namely support contract/agreements);

• Maintenance logs;

• Reporting and handling of faults. Such mechanisms could be used additionally for the validation of theoretical data, such as Mean Time Between Failure (MTBF) and Mean Time To Repair (MTTR), which could form part of the monitoring criteria. The effectiveness of the SSA is entirely dependent on engaging actors, who would not normally work together, into a joint approach. The multi-dimensional problems require the actors to follow good practices in the production of the SSA/SSC, while taking into consideration the possibility of unforeseen cross-organisational/cross-border efficiency, performance and/or political influences. Clearly, the primary requirement is to coordinate and then collaborate on the change and the associated SSA/SSC. AMC1 ATM/ANS.OR.A.045(e) Changes to the functional system refers to this overarching safety argument and there is extensive guidance material about multi-actor changes and their safety management in the EASA Easy Access Rules for ATM/ANS [6].

4.2.3 System Change Lifecycle It is important to understand where the SSA/SSC activities are carried out in the change life cycle of the system. Figure 6 below shows a generic view of a system change lifecycle. The SSA/SSC activities per se are described in section 4.3 Management of SSA and in section 4.4 Contents and Representation of SSC.



Figure 6: Contextual view of a change lifecycle

A new or changed system goes through various phases from initiation up to decommissioning. The tasks of the most important phases to be performed are defined below.

• Initiation: What are the needs for change? o Elaborate a business case addressing costs and benefits, taking into account,

effectiveness, efficiency, quality, security, environment, etc.

• Preliminary Impact Assessment: Is there an impact on service performance/behaviour? o Ensure that in the design phase each project or activity undertaken by the AIS provider

makes sufficient provision to foresee the effect on service behaviour; o Identify concerns as quickly as possible in the project lifecycle (different projects

require different levels of safety support activity) and use the output of this assessment to ensure that the correct level of safety support is made available. Even if the project does not need any specific safety support activities, the results of this process will, at least, ensure that it has been assessed systematically;

o Build an initial safety support argument and create a safety support plan if the project needs to consider concerns more formally;

o Provide supporting data and arguments for the notification to the Competent Authority.

• Definition (preparation activity to Migration, not represented in figure 6): what does the new/changed system need to do? What are its functions? What are the new system boundaries?

o Define the scope (Operations concept - How shall the new/changed system be operated? In what way is the proposed operational concept different from the current one?);

o Define functional requirements; o What are the caveats (assumptions, limitations, constraints, etc.)?

• Design (preparation activity to Migration, not represented in figure 6): Is the proposed solution suitably designed to address the identified concerns?



o Well-designed because: Detailed service specifications are produced by AIS provider personnel

(details of who wrote specifications); Service specifications are according to ICAO Annexes/SARPs/ industry

standards (details of Standards used); Monitoring criteria are specified; A technical evaluation of tenderers’ offers was performed by competent

personnel (details of persons who performed the evaluation to show that they were competent in these matters; these personnel might be external staff if the organisation lacks the competence in this matter);

The selected tenderer offer met the service specifications (declaration by Technical Evaluation Board that offer is according to the service specifications);

The selected tenderer is a reputable manufacturer (details of provider); o Failure conditions – What could cause the system to fail? What is the impact when

the system fails? Identification of failure modes and subsequent/ensuing/consequent degraded modes. Identifying barriers to failure and/or mitigation means to minimise the impact of failure. Modes of recovery;

• Implementation (preparation activity to Migration, not represented in figure 6): construction/building of the new/changed system.

o Functional requirements addressed? o Built according to design documents? (Although, these are activities beyond the

scope of the SSA, reference can also be made to the manufacturer’s Safety Assessment and Declaration of Conformity and AIS provider’s Declaration of Verification, if applicable);

o Specified barriers and mitigation included? o Factory acceptance tests (FAT), simulations, training. Evidence in this phase would

consist of details addressing: FAT; the competence of the persons who formulated test procedures; the persons, who performed these tests, particularly their competence; test results; corrective actions taken (if any) to ensure that the implemented system

complies with the requirements; the persons who formulated operational and technical procedures, particularly

their competence; the standards/regulations used to formulate these procedures; simulation results; the persons who formulated training procedures, particularly their

competence; the standards/regulations used to formulate the training procedures; the persons delivering the training particularly their competence; training syllabus, including objectives for trainees;



competence assessment procedures for trainees (if necessary); the persons who formulated these procedures; the persons who carried them out; the results of the competence assessment;

• Migration: Integration of new/changed system in current overall operating system. The move from the current stage to the post-change state will not endanger the on-going operational service.

o What is the impact on the other parts of the operating system? Has the impact been correctly identified?

o Had all interfaces and interdependencies been correctly identified? o Had caveats been correctly identified? o What needs to be done to achieve the desired effectiveness and service behaviour in

case that the system as designed and built still has problems? (Usually it would be very expensive to make significant modifications to the new/changed system at this stage. A well-conducted definition and design phases considerably reduces the impact of modifications at the migration phase.);

o Migration plan addressing such topics as administrative issues, notification to stakeholders, initial contingency/rollover plan;

o Site tests, training on new/changed system with system off-line, appropriate procedures available;

o Internal promulgation of operational and technical procedures with details of how these procedures were brought to the attention of the staff. (This could be part of the training procedures mentioned in ‘Implementation’.);

o External promulgation of the intention to transfer to a new/changed system;

• Switchover: Switching from the old system to the new/changed system. o Shadow mode operations possible? o What additional barriers and mitigation means are needed during the switch

identified? (Extra ops/engineering staff, restriction on traffic/workload) o Rollover (return to old system in case migration fails) possible? o Contingency measures in case switch fails and it would not be possible to return to

old system. o Notification to all stakeholders, internal and external, of the date and time of switch. o When to switch off old system?

• Operational service: new/changed system now part of overall operating system. o Are the system functions correctly and coherently? o Is the system robust and have failures been effectively mitigated? o Were caveats proven correct over time? o Have the monitoring criteria proven to be valid?

• Decommissioning (not represented in figure 6): System is now old and to be replaced. o What is its impact when it is switched off? o Are there any hidden inter-dependencies?



o When is it safe to take this old system offline?

4.3 Management of Safety Support Assessment (SSA) 4.3.1 Prerequisite to start SSA In order to perform a SSA, the people involved must have a good understanding of the proposed new system or change to the existing system, including its interfaces with the other components. The system change lifecycle is described in section 4.2.3. The first step to perform a SSA is to prepare a description of the proposed system or change and the environment in which it will operate. The change description will address elements such as:

• the system/change;

• the purpose of the system;

• how the system will be used (concept of operation);

• the system functions (operational requirements);

• the boundaries of the system, including boundaries of responsibility;

• the interface with any other systems that may be influenced by, or influence this one; and

• a description of the environment in which the system will operate. The change description should also address pre-existing contingency procedures and other non-normal operations, for example failure of AIS equipment. For many projects it will be appropriate for the change description to address the strategy for transition from the old to the new system. For example, will the existing system be decommissioned and replaced immediately with the new system, or will the two systems be operated in parallel for a period of time? The project will mature as its lifecycle progresses, possibly leading to updates to the system description. Therefore, it is essential to keep the change description updated to reflect the design decisions made and implemented. Without this, there is the possibility that any SSA activities that may take place at several stages in the life of a project may not be considering the latest system design. Thus, from the beginning of SSA, the following documents should be available:

• Change description;

• AIS service specification;

• AIS design documents. An example of a table of contents for an AIS service specification is provided in Annex A.

4.3.2 Safety Plan The success of any project depends critically upon the effort, care and skill applied in its initial planning, a preparatory step in a systematic activity which determines when, how and who is going to perform a specific job. Planning takes into consideration available and prospective human and physical resources of the organisation so as to obtain effective co-ordination, contribution and perfect adjustment.

CIR 2017/373 does not clearly mandate a project safety plan but it is good practice to have one. The activities that form part of the Safety Assessment need to be planned and integrated into the project plan. The integration of the safety plan into the project plan considerably reduces the possibility of the project being delayed and cost overruns due to safety requirements.



The safety plan, like any other management plan, consists of the following elements:

• roles and responsibilities;

• objectives, targets, actions;

• priorities;

• resources;

• budget. The safety plan shall mention that, for the AIS providers, a Safety Support Assessment is to be performed as highlighted in section 1.2.

For large projects, it is essential to establish focal points for the various (groups of) tasks, especially if external stakeholders are involved. A change as defined in ATM/ANS.OR.A.045(e) may involve more than one service provider changing their functional systems.

Thus, it is clear that it is necessary to have procedures to monitor the behaviour, record instances of failures, analyse the failures and decide whether a change is required to correct the behaviour. Such procedures, though need to have assigned the actual values of the properties of the behaviour used to demonstrate compliance with the specification. The development of such values and the associated processes would form part of the change management procedures

4.3.3 Identification of Failure Conditions In the lifecycle of a system, for which SSA/SSC activities have to be carried out, it is important to clearly define the failure conditions, particularly in the design phase as explained in section 4.2.3 System Change Lifecycle. There are various ways of identifying failure conditions but often they follow one or more generic approaches:

• Historical - Use and analysis of existing failure logs and occurrence/incident reports. Also any failure identified from the SSAs of other systems that may be similar to this system;

• Brainstorming - Planned and organised sessions aimed at encouraging a team of participants of various relevant experience and expertise to explore the system for potential failures in a creative way. Such sessions, which assess normal, abnormal and particular combinations of unrelated event scenarios, require a range of experienced operational and technical personnel and should be managed by a facilitator who is familiar with the techniques;

• Systematic - Sessions involving a thorough sequential review of a system often using system diagrams and descriptions as prompts together with keywords to help focus on the types of failure to be assessed e.g. using Failure Modes Effects and Criticality Analysis (FMECA) (to name just one of them). Some of the more complicated failures identified using such processes, especially those involving sequences of events, may benefit from further examination using Event Trees. As usual, it is important that the appropriate staff and system experts become involved in such identification processes.

Note: Systematic process are mostly used in large projects involving complicated changes.

Annex F gives examples of failure conditions identified in two different AIS projects, one from EUROCONTROL and one from a national AIS provider.

4.3.4 Mitigations to Failure Conditions The identification of appropriate mitigation measures requires a good understanding of why the failure condition is likely to happen and the factors contributing to the severity of its impact. Any effective mitigation mechanism will have to modify one or more of these factors. Thus mitigation measures may work through reducing the likelihood of occurrence, or the severity of the impact, or



both. Achieving the desired outcome may require the implementation of more than one mitigation measure.

Mitigation strategies include:

• Exposure avoidance - Risky task, practice, operation or activity is avoided;

• Loss reduction - Measures are taken to reduce the likelihood of occurrence of unacceptable events or the severity of their effects and impact on the service specifications through such means as revision of the system design; modification of operational procedures; changes to staffing arrangements; and training of personnel to deal with the failure condition;

• Control of exposure - Action is taken to ensure redundancy to protect against the failures (back-up systems to reduce the likelihood of total system failure, development of emergency and/or contingency arrangements and plans).

The earlier in the system lifecycle that failures are identified, the easier it is to change the system design if necessary or beneficial because changing the design becomes more difficult and costly as the system nears implementation. Additionally, late identification of failures and subsequent/ensuing/consequent degraded modes would reduce the available mitigation options.

The effectiveness of any proposed risk mitigation measures must be assessed by first examining closely whether the implementation of the mitigation measures might introduce any new failure conditions or whether they change the basis on which other assessments have been made.

The necessary mitigation measures must be clearly documented. The system cannot be transferred into operational service until all these mitigation measures have been implemented.

The mitigation strategies are then implemented in the functional system through the creation of safety support requirements, which are included in the AIS service specification. The scope and the expected contents of safety support requirements and service specification are defined in AMC2 ATM/ANS.OR.C.005(a)(2), GM1 to AMC2 ATM/ANS.OR.C.005(a)(2) and GM3 ATM/ANS.OR.C.005(a)(2).

Annex F gives examples of mitigation means identified in two AIS projects, one from EUROCONTROL and one from a national AIS provider.

4.3.5 Monitoring Criteria and Process The new or changed system will behave and will continue to behave only as set out in the specified context throughout its operational life and not only for the transfer to operations. Consequently, a set of monitoring criteria has to be specified during the SSA to confirm that the changed functional system is monitored after the change has been implemented to ensure the service behaves as specified. Monitoring criteria, ideally backed up by a process for collecting and analysing these data periodically, could be specifically developed as an enabling tool for validation of the safety assumptions and requirements as identified during the Safety Support Assessment and mitigation processes.

Below are some examples:

• Number of errors received from the data originator – survey errors, NOTAM errors, chart errors, AIP errors, etc. - in particular the specific data items being not in line with the expected values as defined in the service specification;

• Number of internal errors detected prior to publication;

• Number of external errors detected prior to publication;

• Number of errors detected after publication;

• Number of errors detected – routine, essential and critical data;



• Number of errors rectified prior to publication. The SSC will usually include a set of caveats that outline all assumptions, outstanding issues, and any limitations or restrictions on the operation of the system. There may be occasions where the correctness and validity of some of the caveats could only be proven after the new/changed system has transitioned into service. Thus, the monitoring criteria need to include the ways and means to ensure the correctness of all assumptions, the validity of any limitation or restrictions and that all outstanding issues have been successfully closed.

4.4 Contents and Representation of Safety Support Case (SSC)

4.4.1 Purpose of the Safety Support Case A Safety Support Case is the key document that demonstrates that a system will behave and will continue to behave only as specified in a given context. Broadly speaking, the SSC is the documented assurance (i.e. argument and supporting evidence) of the achievement and maintenance of service behaviour. It is primarily the means by which those who are accountable for service provision or projects assure themselves that those services or projects will deliver, and will continue to deliver, an acceptable level of service. In addition, the SSC is the set of documents that the Competent Authority may audit to ensure that the SSA has been carried out completely and correctly and that the AIS provider has satisfied themselves that the system has been fully analysed and demonstrated to behave and will continue to behave only as specified in the specified context. It is also a key document likely to be called up as evidence for any legal action involving a failure of operations. It is therefore important to ensure that the document clearly presents the required information and is complete.

4.4.2 Contents of the Safety Support Case A SSC would typically include, at least:

• A title page clearly stating the system under consideration and what stage in the project this SSC covers. During the development of the project there may be several iterations to the SSC as more detailed system design and performance information becomes available. The SSC is, therefore, a 'living document' and should be developed along with the lifecycle of the system;

• Document approval following the principles outlined in Section 4.6 Human Resources, roles and responsibilities;

• An amendment record that logs the history of the document e.g. the various drafts and

Documents

EUROCONTROL Guidelines for the Implementation of Safety ......Assessment or Safety Support Assessment and therefore the current guidelines refer to Easy Access Rules for ATM/ANS (Regulation