European Aviation Safety Agency Notice of Proposed Amendment 2014 … · 2014-06-24 · European...

European Aviation Safety Agency — Rulemaking Directorate

Notice of Proposed Amendment 2014-13

Applicability Process map

Affected

regulations and decisions:

Regulations (EU) Nos 1034/2011 and 1035/2011

Regulation (EC) No 482/2008

Concept Paper:

Terms of Reference:

Rulemaking group:

RIA type:

Technical consultation during NPA drafting:

Duration of NPA consultation:

Review group:

Focussed consultation:

Publication date of the Opinion: RMT.0469

Publication date of the Decision: RMT.0470

No

19.6.2012

Yes

Full

No

3 months

No

TBD

2014/Q4

2015/Q3

Affected stakeholders:

Member States, competent authorities/National Supervisory Authorities, ATM/ANS providers, Network Manager, and EASA

Driver/origin: Legal obligation (Regulation (EC)

No 216/2008) and feedback from the implementation of the existing requirements

Reference: N/A

TE.RPRO.00034-003 © European Aviation Safety Agency. All rights reserved.

Proprietary document. Copies are not controlled. Confirm revision status through the EASA intranet/Internet. Page 1 of 230

Assessment of changes to functional systems by service

providers in ATM/ANS and the oversight of these changes by

competent authorities

RMT.0469 & RMT.0470 — 24.6.2014

EXECUTIVE SUMMARY

This Notice of Proposed Amendment (NPA) addresses a regulatory issue related to the assessment of changes to functional systems performed by certified service providers in the field of ATM/ANS and the oversight of these changes by competent authorities.

The specific objective is to provide a harmonised set of rules (by clarifying and enhancing the existing

ones) for certified service providers to perform the assessment of changes to functional systems, and

enhance the rules for competent authorities for the oversight of these changes. The objective is, therefore, to improve harmonisation and to facilitate the maintenance of a high level of safety by providing a clear set of implementing provisions, Acceptable Means of Compliance (AMC) and Guidance Material (GM).

This NPA proposes:

— more explicit requirements for the oversight of changes to functional systems after their

implementation during the ongoing oversight by the competent authorities;

— more explicit requirements for the approval of the change management procedures by competent authorities;

— enhancement of the requirements for the review decision and review of the changes to functional systems by competent authorities;

— more explicit requirements to introduce processes into the management system of certified service providers to actively search for the need to change the functional system;

— more explicit requirements for the change management procedures and for the changes affecting more than one certified service provider and aviation undertakings; and

— requirements for the assessment and the assurance of changes to the functional systems applicable to all certified service providers.

The proposed changes are expected to improve understanding of the concepts associated with the assessment of changes to the functional systems by certified service providers and the relationship

between the service providers and the competent authorities during the oversight activities of the latter. By improving the understanding of these concepts, it is expected that harmonisation across Europe will also improve.

European Aviation Safety Agency NPA 2014-13

Table of contents



Table of contents

1. Procedural information ............................................................................................. 8 1.1. The rule development procedure ............................................................................. 8 1.2. The structure of this NPA and related documents ...................................................... 8 1.3. How to comment on this NPA .................................................................................. 9 1.4. The next steps in the procedure .............................................................................. 9

2. Explanatory Note .................................................................................................... 10 2.1. Overview of the issues to be addressed ................................................................... 10 2.2. Objectives ........................................................................................................... 13 2.3. Summary of the Regulatory Impact Assessment (RIA) .............................................. 14 2.4. Overview of the proposed amendments .................................................................. 17

3. Proposed amendments ........................................................................................... 32 3.1. Draft Regulation (Draft EASA Opinion) .................................................................... 32

ANNEX I ................................................................................................................. 32 ANNEX II ................................................................................................................ 33 SUBPART A — GENERAL REQUIREMENTS .................................................................... 33 SUBPART B — MANAGEMENT (ATM/ANS.AR.B) ............................................................ 33 SUBPART C — OVERSIGHT, CERTIFICATION, AND ENFORCEMENT (ATM/ANS.AR.C) ......... 33

ATM/ANS.AR.C.010 Oversight ............................................................................... 33

ATM/ANS.AR.C.030 Approval of change management procedures for ATM/ANS functional systems................................................................................................................ 33

ATM/ANS.AR.C.035 Decision to review the notified change ....................................... 34

ATM/ANS.AR.C.040 Risk-based review of the notified change .................................... 34

ANNEX III ............................................................................................................... 35 SUBPART A — GENERAL COMMON REQUIREMENTS (ATM/ANS.OR.A) ............................. 35 SUBPART B — MANAGEMENT (ATM/ANS.OR.B) ............................................................ 36

ATM/ANS.OR.B.005 Management system ................................................................ 36

ATM/ANS.OR.B.010 Change management procedures .............................................. 36

SUBPART C — SPECIFIC ORGANISATIONAL REQUIREMENTS FOR SERVICE PROVIDERS

OTHER THAN ATS PROVIDERS .................................................................................. 37 ATM/ANS.OR.C.001 Scope .................................................................................... 37

ATM/ANS.OR.C.005 Safety support assessment and assurance of changes to the

functional system .................................................................................................. 37

SUBPART D — SPECIFIC ORGANISATIONAL REQUIREMENTS FOR ANS AND ATFM

PROVIDERS AND THE NETWORK MANAGER (ATM/ANS.OR.C) ........................................ 37 ANNEX IV ............................................................................................................... 38 SUBPART A — ADDITIONAL ORGANISATION REQUIREMENTS FOR THE PROVISION OF AIR

TRAFFIC SERVICES (ATS.OR) .................................................................................... 38 ATS.OR.201 Safety management system ................................................................ 38

ATS.OR.205 Safety assessment and assurance of changes to the functional system ..... 38

ATS.OR.210 Safety criteria ................................................................................... 39

SUBPART B — TECHNICAL REQUIREMENTS FOR THE PROVISION OF AIR TRAFFIC SERVICES

(ATS.TR) ................................................................................................................ 39 3.2. Draft Acceptable Means of Compliance and Guidance Material (Draft EASA Decision) ... 40

AMC/GM to Cover Regulation .................................................................................... 40 GM2 Article 2 (2) Definitions ................................................................................... 40

AMC/GM to ANNEX I — Definitions of terms used in ANNEXES II to XIII ......................... 45 GM1 Annex I Definitions(35) ................................................................................... 45

GM2 Annex I Definitions(35) ................................................................................... 47

GM1 Annex I Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General ................. 50


Table of contents



GM2 Annex I Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General ................. 55

GM1 Annex I Definitions (35) & ATM/ANS.OR.A.045 & ATM/ANS.OR.C.005 & ATS.OR.205 General ................................................................................................................ 58

AMC/GM to ANNEX II — Requirements for competent authorities — Service provision and network

functions (Part-ATM/ANS.AR) 82 SUBPART A — GENERAL REQUIREMENTS .................................................................... 82 SUBPART B — MANAGEMENT (ATM/ANS.AR.B) ............................................................ 82 SUBPART C — OVERSIGHT, CERTIFICATION, AND ENFORCEMENT (ATM/ANS.AR.C) ......... 82

GM1 ATM/ANS.AR.C.035 & ATM/ANS.OR.A.045 General ........................................... 82

AMC1 ATM/ANS.AR.030 Approval of change management procedures for ATM/ANS

functional systems ................................................................................................. 91

GM1 ATM/ANS.AR.030 Approval of change management procedures for ATM/ANS

functional systems ................................................................................................. 92

GM1 ATM/ANS.AR.C.035(b)(1) Decision to review the notified change ........................ 92

GM2 ATM/ANS.AR.C.035(b)(1) Decision to review the notified change ........................ 99

AMC/GM to ANNEX III — Common requirements for service providers (Part-ATM/ANS.OR)

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

GM1 ATM/ANS.AR.C.035 & ATM/ANS.OR.A.045 General .......................................... 101

GM1 Annex I Definitions (35) & ATM/ANS.OR.A.045 & ATM/ANS.OR.C.005 &

ATS.OR.205 General ........................................................................................... 101

AMC1 ATM/ANS.OR.A.045(a) Changes to the functional system ................................ 101


GM1 ATM/ANS.OR.A.045(a) Changes to the functional system ................................. 102




GM4 ATM/ANS.OR.A.045(a) Management of change to a functional system ............... 106

GM5 ATM/ANS.OR.A.045(a) Management of change to a functional system ............... 106

AMC1 ATM/ANS.OR.A.045(a)(3) Changes to the functional system ........................... 107

GM1 ATM/ANS.OR.A.045(a)(3) Changes to the functional system ............................. 108

AMC1 ATM/ANS.OR.A.045(b) Changes to the functional system ................................ 108

AMC1 ATM/ANS.OR.A.045(d) Changes to the functional system ................................ 108

GM1 ATM/ANS.OR.A.045(c); (d) Changes to the functional system ........................... 108

GM2 ATM/ANS.OR.A.045(c); (d) Changes to the functional system ........................... 108

GM1 ATM/ANS.OR.A.045(e) Changes to the functional system ................................. 109

GM2 ATM/ANS.OR.A.045(e) Changes to the functional system ................................. 110

GM1 ATM/ANS.OR.A.045(e)(1) Changes to the functional system ............................. 111

AMC1 ATM/ANS.OR.A.045(e)(3) Changes to the functional system ........................... 114




GM1 ATM/ANS.OR.A.045(f)(2) Changes to the functional system .............................. 117

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


Table of contents



GM1 ATM/ANS.OR.B005(a)(5) ................................................................................ 118

AMC1 ATM/ANS.OR.B.010(a) Change management procedures ................................ 119

GM1 ATM/ANS.OR.B.010(a) Change management procedures .................................. 119



AMC2 ATM/ANS.OR.B.010(a);(b) Change management procedures ........................... 122

SUBPART C — SPECIFIC ORGANISATIONAL REQUIREMENTS FOR SERVICE PROVIDERS

OTHER THAN ATS PROVIDERS (ATM/ANS.OR.C) ......................................................... 122 GM1 Annex I Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General ................ 122

GM2 Annex I Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General ................ 122

GM1 Annex I Definitions (35) & ATM/ANS.OR.A.045 & ATM/ANS.OR.C.005 & ATS.OR.205 General ........................................................................................... 122

GM1 ATM/ANS.OR.C.005(a)(2) & ATS.OR.205(a)(2) General .................................... 122

AMC1 ATM/ANS.OR.C.005 Safety support assessment and assurance of changes to the functional system ................................................................................................. 126

GM1 ATM/ANS.OR.C.005 Safety support assessment and assurance of changes to the

functional system ................................................................................................. 127

GM2 ATM/ANS.OR.C.005(a) Safety support assessment and assurance of changes to the


GM3 ATM/ANS.OR.C.005(a)(1) Safety support assessment and assurance of changes to the functional system ............................................................................................ 135

AMC1 ATM/ANS.OR.C.005(a)(2) Safety support assessment and assurance of changes to the functional system ............................................................................................ 138


GM2 ATM/ANS.OR.C.005(a)(2) Safety support assessment and assurance of changes to

the functional system ............................................................................................ 138






GM1 ATM/ANS.OR.C.005(b) Safety support assessment and assurance of changes to the


AMC1 ATM/ANS.OR.C.005(b)(1) Safety support assessment and assurance of changes to the functional system ............................................................................................ 143

GM1 ATM/ANS.OR.C.005(b)(1) Safety support assessment and assurance of changes to the functional system ............................................................................................ 143

GM1 ATM/ANS.OR.C.005(b)(1)(i) Safety support assessment and assurance of changes to the functional system ........................................................................................ 144

GM1 ATM/ANS.OR.C.005(b)(1)(iii) Safety support assessment and assurance of changes

to the functional system ........................................................................................ 145

GM1 ATM/ANS.OR.C.005(b)(1)(iv) & ATS.OR.205 (b)(1)(iv) General ........................... 145


Table of contents



GM1 ATM/ANS.OR.C.005(b)(1) & (2) Safety support assessment and assurance of changes to the functional system ............................................................................ 146







GM1 ATM/ANS.OR.C.005(b) Safety support assessment and assurance of changes to the functional system ................................................................................................. 151

GM1 ATM/ANS.OR.C.005(b)(2) Safety support assessment and assurance of changes to


GM1 ATM/ANS.OR.C.005(b)(3) Safety support assessment and assurance of changes to the functional system ............................................................................................ 153

AMC/GM to ANNEX IV — Specific requirements for the provision of Air Traffic Services (Part-

ATS) ..................................................................................................................... 154 SUBPART A — ADDITIONAL ORGANISATION REQUIREMENTS FOR THE PROVISION OF AIR

TRAFFIC SERVICES (ATS.OR) ................................................................................... 154 GM1 Annex I Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General ................ 154

GM2 Annex I Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General ................ 154

GM1 Annex I Definitions (35) & ATM/ANS.OR.A.045 & ATM/ANS.OR.C.005 & ATS.OR.205 General ........................................................................................... 154

GM1 ATM/ANS.OR.C.005(a)(2) & ATS.OR.205(a)(2) General .................................... 154

GM1 ATS.OR.205(a)(1) Safety assessment and assurance of changes to the functional system ................................................................................................................ 154

AMC1 ATS.OR.205(a)(2) Safety assessment and assurance of changes to the functional system ................................................................................................................ 155

GM1 ATS.OR.205(a)(2) Safety assessment and assurance of changes to the functional

system ................................................................................................................ 155


AMC2 ATS.OR.205(a)(2) Safety assessment and assurance of changes to the functional system ................................................................................................................ 155


GM4 ATS.OR.205(a)(2) Safety assessment and assurance of changes to functional

systems............................................................................................................... 158


systems............................................................................................................... 158

AMC1 ATS.OR.205(b) Safety assessment and assurance of changes to the functional system ................................................................................................................ 159

GM1 ATS.OR.205(b) Safety assessment and assurance of changes to the functional system ................................................................................................................ 162


Table of contents






GM1 ATS.OR.205(b)(1) Safety assessment and assurance of changes to the functional

system ................................................................................................................ 164

GM2 ATS.OR.205(b)(1) Safety assessment and assurance of changes to the functional system ................................................................................................................ 165

GM1 ATS.OR.205(b)(1), (2) & (4) Safety assessment and assurance of changes to the functional system ................................................................................................. 165



system ................................................................................................................ 170

GM1 ATS.OR.205.(b)4 Safety assessment and assurance of changes to the functional system ................................................................................................................ 171





system ................................................................................................................ 193



GM1 ATS.OR.205(b)(6)(ii) Safety assessment and assurance of changes to the functional system ................................................................................................................ 195


system ................................................................................................................ 195

GM1 ATS.OR.205(b)(1)(i) Safety assessment and assurance of changes to the functional system ................................................................................................................ 195

GM1 ATS.OR.205(b)(1)(iii) Safety assessment and assurance of changes to the functional system ................................................................................................................ 196

GM1 ATS.OR.210(b)(1) Safety criteria ................................................................... 196

4. Regulatory Impact Assessment (RIA) ................................................................... 197 4.1. Issues to be addressed — General overview .......................................................... 197 4.2. Structure of the RIA ........................................................................................... 197 4.3. Risk-based review decision by the competent authorities ........................................ 197 4.4. Risk-based review by the competent authorities ..................................................... 201 4.5. CNS providers performing safety support assessment instead of safety assessment ... 206 4.6. Removal of Severity classification scheme from IR ................................................. 210 4.7. Changes affecting software and Regulation (EC) No 482/2008 ................................. 213

5. References ............................................................................................................ 217


Table of contents



5.1. Affected regulations ............................................................................................ 217 5.2. Affected CS, AMC and GM .................................................................................... 217 5.3. Reference documents ......................................................................................... 217

6. Appendices ........................................................................................................... 218 6.1. Appendix I — Cross reference table of Regulations (EU) Nos 1034/2011 and 1035/2011

to the proposed requirements in this NPA ...................................................................... 218 6.2. Appendix II — Cross reference table of the requirements of Commission Regulation (EC)

No 482/2008 ............................................................................................................. 221 6.3. Appendix III — List of items to be covered in the second NPA .................................. 230


1. Procedural information




1.1. The rule development procedure

The European Aviation Safety Agency (hereinafter referred to as the ‘Agency’) developed

this Notice of Proposed Amendment (NPA) in line with Regulation (EC) No 216/20081

(hereinafter referred to as the ‘Basic Regulation’) and the Rulemaking Procedure2.

This rulemaking activity is included in the Agency’s 4-year Rulemaking Programme under

RMT.0469.

The text of this NPA has been developed by the Agency based on the input of the

Rulemaking Group for RMT.0469 and RMT.04703. It is hereby submitted for consultation of

all interested parties4.

The process map on the title page contains the major milestones of this rulemaking

activity to date and provides an outlook of the timescale of the next steps.

1.2. The structure of this NPA and related documents

Chapter 1 of this NPA contains the procedural information related to this task.

Chapter 2 (Explanatory Note) explains the core technical content. It contains relevant

information about the meaning of the proposed provisions and questions addressed to the

stakeholders on items for which the Agency seeks specific advice. It also explains and

provides justification, complementing the Regulatory Impact Assessment (RIA) contained

in Chapter 4, on the proposed amendments to the existing provisions in Regulations (EU)

Nos 1034/20115 and 1035/20116.

Chapter 3 contains the proposed text for the new requirements. The new requirements are

presented as additions to the proposed provisions replacing Regulations (EU)

Nos 1034/2011 and 1035/2011 as included the CRD to NPA 2013-08.

Chapter 4 contains the RIA showing which options were considered and what impacts were

identified, thereby providing a more detailed justification for this NPA.

1 Regulation (EC) No 216/2008 of the European Parliament and the Council of 20 February 2008 on common rules in the

field of civil aviation and establishing a European Aviation Safety Agency, and repealing Council Directive 91/670/EEC, Regulation (EC) No 1592/2002 and Directive 2004/36/EC (OJ L 79, 19.3.2008, p. 1), as last amended by Commission Regulation (EU) No 6/2013 of 8 January 2013 (OJ L 4, 9.1.2013, p. 34).

2 The Agency is bound to follow a structured rulemaking process as required by Article 52(1) of the Basic Regulation. Such process has been adopted by the Agency’s Management Board and is referred to as the ‘Rulemaking Procedure’. See Management Board Decision concerning the procedure to be applied by the Agency for the issuing of Opinions, Certification Specifications and Guidance Material (Rulemaking Procedure), EASA MB Decision No 01-2012 of 13 March 2012.

3 More information about the rulemaking group set-up and background can be found in the second chapter of the Terms of Reference of RMT.0469 and RMT.0470 and in the third chapter of the Explanatory Note to NPA 2013-08 (A) to be found under: http://easa.europa.eu/rulemaking/r-archives.php#npa)

4 In accordance with Article 52 of the Basic Regulation and Articles 5(3) and 6 of the Rulemaking Procedure. 5 Commission Implementing Regulation (EU) No 1034/2011 of 17 October 2011 on safety oversight in air traffic

management and air navigation services and amending Regulation (EU) No 691/2010 (OJ L 271, 18.10.2011, p. 15) 6 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 (OJ L 271, 18.10.2011, p. 23).

http://easa.europa.eu/rulemaking/annual-programme-and-planning.php

http://easa.europa.eu/rulemaking/r-archives.php#npa





1.3. How to comment on this NPA

Please submit your comments using the automated Comment-Response Tool (CRT)

available at http://hub.easa.europa.eu/crt/7.

The deadline for submission of comments is 24 September 2014.

1.4. The next steps in the procedure

Following the closing of the NPA public consultation period, the Agency will review all

comments and depending on the outcome of the consultation will decide whether or not it

will perform a focussed consultation or will arrange for thematic meetings with the relevant

parties or whether it will review the comments internally.

The outcome of the NPA public consultation as well as the focussed consultation, if it were

to be needed, will be reflected in the related Comment-Response Document (CRD).

The Agency will publish the CRD together with the Opinion to the European Commission,

after addressing the comments received during the consultation.

The Opinion will contain the proposed changes to Commission Implementing Regulations

(EU) Nos 1034/2011 and 1035/2011. It is anticipated that the Opinion will be combined

with the Opinion resulting from RMT.0148 (ATM.001(A))/RMT.0149 (ATM.001(B)) and

RMT.0157 (ATM.004(A))/RMT.0158 (ATM.004(B)) into one single Opinion after the CRD to

NPA 2013-08 reaction period. The resulting Opinion is addressed to the European

Commission, which will use it as a technical basis to prepare a legislative proposal.

The Decision containing Acceptable Means of Compliance (AMC) and Guidance Material

(GM) will be published by the Agency when the related Implementing Rule(s) are adopted

by the Commission. The present NPA does not contain all the envisaged AMC and GM to

support and facilitate the implementation of the proposed Rule. Another NPA is foreseen,

which could be published during the last quarter of 2014, that would contain the additional

AMC and GM material. A non-exhaustive list of the items that are envisaged to be

addressed in the other NPA is included in Appendix III (point 6.3) of this Explanatory Note.

However, it is the Agency’s intention to include all the resulting AMC and GM material as a

single Agency Decision following the adoption of the said Rule.

7 In case of technical problems, please contact the CRT webmaster ([email protected]).

http://hub.easa.europa.eu/crt/

mailto:[email protected]


2. Explanatory Note



2. Explanatory Note

2.1. Overview of the issues to be addressed

As it was foreseen in recital (16) of Regulation (EU) No 1035/2011 and recital (10) of

Regulation (EU) No 1034/2011, as well as in Opinion No 02/2010, the Agency needed to

further evaluate the existing provisions, i.e. those in Regulations (EU) Nos 1034/2011 and

1035/2011, dealing with the safety assessment of changes to functional systems and their

safety oversight. The objective was to complement the existing regulations and to amend

them as necessary.

When the former Regulation (EC) No 2096/20058 was adopted, the proposed Risk

Classification Scheme (RCS) was incomplete. Regulation (EC) No 2096/2005 identified the

need to complete the RCS and, therefore, the European Commission gave EUROCONTROL

a mandate to further develop the regulatory material governing the safety assessment of

changes and to complement the severity classification table already in the Regulation. The

outcome of this mandate was a recommendation by EUROCONTROL to make a more

comprehensive study about the safety assessment of changes.

In 2009, the Agency established rulemaking tasks ATM.001 and ATM.004 in order to

review and complement Regulations (EC) No 2096/2005 and 1315/20079 (which have now

been repealed by Regulations (EU) Nos 1035/2011 and 1034/2011 respectively). At that

time, the Safety Assessment Task Force (SATF) was set up as a specific ad hoc subgroup.

It was tasked with reviewing the provisions dealing with the safety assessment of

ATM/ANS functional systems and their safety oversight and with making recommendations

jointly to ATM.001 and ATM.004 rulemaking tasks. SATF work was to be completed at the

same time as the outcome of the ATM.001 and ATM.004 rulemaking groups .

Need for a broad-based approach to the safety assessment

The SATF subgroup identified that a solution to the difficulties in completing the existing

regulatory framework did not so much lie in completing the RCS, but rather in the need for

a broad-based approach to the safety assessment of changes that is not specifically

method-oriented. As a consequence of this, SATF suggested that additional provisions

were needed in other areas of the Regulations, such as the oversight of the safety

assessment process and its outputs, and the relationship between the Safety Management

System and the safety assessment of change. Such a relationship is necessary to establish

the goals for the safety of a change and to identify when changes should be performed.

These additional provisions would not replace current practices but rather support and

extend them.

In addition, SATF also found that risk assessments can have limitations when used for

certain types of change, e.g. the available data and/or models may be inappropriate for a

specific quantitative risk assessment, therefore, making other approaches that also lead to

valid results, more efficient (in time and/or costs). Moreover, there is some evidence that

safety assessments that are based only upon an explicit risk assessment are not always

well understood by key stakeholders like operational staff.

8 Commission Regulation (EC) No 2096/2005 of 20 December 2005 laying down common requirements for the provision

of air navigation services ((OJ L 335, 21.12.2005, p.13). 9 Commission Regulation (EC) No 1315/2007 of 8 November 2007 on safety oversight in air traffic management and

amending Regulation (EC) No 2096/2005 (OJ L 291, 9.11.2007, p. 16).


2. Explanatory Note



Lack of understanding of the concepts underpinning the management of changes

Another identified problem with the existing Regulations concerned the understanding of

the concepts underpinning the management of changes. There was no common

understanding of these concepts nor was there a set of AMC and GM to support the

harmonised implementation of the Regulations. In conclusion, SATF recognised the need

for an improved regulatory framework.

Most of the work carried out by the Agency together with the SATF and subsequently with

the experts of the rulemaking group RMG.0469 and RMG.0670 has been to develop the

concepts behind the proposed provisions so that a common understanding is achieved

before developing the draft regulations, AMC and GM.

Issues identified with the implementation of the existing Regulations

During this exercise, the following issues were identified in the implementation of the

existing Regulations and for which improvements were needed:

— Existing provisions are not fully consistent

For example, the scope of the requirements is different between the Regulations.

Regulation (EU) No 1035/2011 contains specific requirements10 only for the Air

Traffic Service (ATS)11 and Communication, Navigation and Surveillance (CNS)

providers, while Regulation (EU) No 1034/2011 implies that all the certified service

providers are required to make an assessment of the changes to their functional

systems. In addition, Article 9(2) of Regulation (EU) No 1034/2011 requires

organisations (meaning all services providers) to notify the relevant competent

authority of all planned safety-related changes, while Article 6 of Regulation (EU)

No 1035/2011 requires a certified organisation to notify the competent authority of

planned changes to its provision of air navigation services which may affect its

compliance with the applicable common requirements or with the conditions attached

to the certificate, where applicable, without limiting it to safety-related changes. This

could lead to a confusion of the roles and responsibilities for the different Air

Navigation Service Providers (ANSP).

— Existing provisions are not always clear

For example, it is not clearly stated which service provider needs to develop a safety

case and which provider does not need to develop a safety case but does need to do

something else as a result of the assessment of the changes to their functional

system. In addition, Article 9(2) of Regulation (EU) No 1034/2011 states that

‘Reviews shall be conducted in a manner commensurate with the level of risk posed

by the new functional systems or by the proposed changes to existing functional

systems’, it does not, however, define what it is meant by the level of risk posed by

the change. Equally, the procedures for the management of the change are

mentioned, but there are no specific requirements on how to manage them. The

interactions between the competent authority (CA) and the service provider during

and after the change is not clearly indicated in the existing provisions.

10 See Point 3.2 of Annex I and Article 3 of Annex V, respectively, to Regulation (EU) No 1035/2011. 11 The explanation about the different type of service providers can be found on pages 21 and 22 of the Explanatory Note

to NPA 2013-08 (A) to be found under: http://easa.europa.eu/rulemaking/r-archives.php#npa.



2. Explanatory Note



— Existing provisions are not always correct

For example, Article 9(1) of Regulation (EU) No 1034/2011 contains criteria for the

selection of those safety arguments for a change that are to be reviewed by the CA.

A strict interpretation of the provision would require that all or almost all changes are

selected for review. This would mean that the selection is not risk-based as it was

initially intended. Regulation (EC) No 1035/2011 requires CNS providers to perform a

hazard identification and safety risk assessment of their changes to the functional

systems. While today CNS providers are seen to try to comply with these

requirements, they cannot always do so. This is because CNS providers, as other

non-ATS providers, do not have a dynamic view of the use of the service and,

therefore, cannot intervene in order to alter a developing situation. Furthermore, the

non-ATS provider may not know how the service it offers is being used by the ATS

provider, either in normal circumstances or in circumstances where immediate

intervention is necessary in order to maintain safety. In fact, a CNS provider

performs what is called, in this NPA, a safety support assessment of a change and,

from it, provides safety support assurance.

— Existing provisions are not always complete

For example, the current provisions do not contain requirements that clarify the

responsibilities of the service providers when they perform changes that may affect

other service providers or other entities (referred to in this NPA as ‘aviation

undertakings’). Another example worthy of mention is that, at present, requirements

seem to request ATS and CNS providers to use an explicit risk calculation method in

their safety assessment; however, while there is a table with a severity classification

scheme, the safety objectives for these severities are not provided. Furthermore,

experience shows that other measures related to risk can be used in lieu of risk itself

e.g. proxies for risk may be used — this term will be explained below.

— Existing provisions do not always support the concept of ‘better regulation’ or

‘performance-based regulation’

Point 3.2 of Annex II to Regulation (EU) No 1035/2011 seems to require ATS and

CNS to use specific methods when performing safety assessments. Experience shows

that it is also feasible to use other methods, not mentioned in the Regulation, to

perform safety assessments.

— Existing provisions do not include sufficient AMC/GM

The provision of AMC and GM for the implementation of the requirements by the

service providers is particularly necessary as there is not always a common

understanding of the concepts associated with the proposed requirements nor with

the definitions of terms such as ‘change’, ‘functional system’, ‘safety of the change’,

‘safety versus other performance’, ‘risk-based selection’, ‘risk-based review’, ‘multi-

actor change’, etc. More AMC and GM also seems to be needed for the CA to:

decide whether to review the changes or not;

decide the level of the review of the changes;

identify the interactions with the service providers during the change; and

to identify the oversight activities once the change has been implemented.


2. Explanatory Note



Feedback from standardisation inspections12

It is also important to highlight that the results of EASA Standardisation Inspections of the

Member States’ competent authorities on the implementation of Regulations (EU) Nos

1035/2011 and 1034/2011 show that one of the main findings is related to the assessment

of changes to functional systems and its oversight by competent authorities. The issues

identified by inspections are mainly related to:

— the notification of the changes in general;

— the late notification of changes, generally after the assessment is done, which

hinders the competent authorities’ decision to review; and

— the approval of the change management procedures.

This NPA addresses these issues and tries to provide ways of resolving them by proposing

new and amended requirements and associated AMC and GM.

2.2. Objectives

The overall objectives of the EASA system are defined in Article 2 of the Basic Regulation.

This proposal will contribute to the achievement of these objectives by addressing the

issues outlined in Chapter 2.1 of this NPA.

The general objective of this proposal is to enhance, complete and complement the

existing requirements for the management of changes to functional systems.

The specific objectives of this proposal are to address issues related to:

— the changes that involve more than one organisation (including organisations in other

fields of air transport and unregulated bodies);

— the procedures used during a change and their outputs;

— the safety oversight of these procedures and their outputs (including the risk-based

proportionate review of the output of the change assurance procedures);

— the safety oversight of the change once implemented;

— the relationship between the safety of the change and the safety policy of the

organisation;

— the safety assessment of the change and how this may lead to the need for

mitigation;

— the assurance that the change is safe enough; and

— the roles and responsibilities of the different types of ATM/ANS service providers.

In order to facilitate, as far as is feasible, the total system approach for civil aviation

safety, the terms, logic (inferences) and semantics used are to be potentially suitable for

use in all other aviation domains.

With the provisions proposed in this NPA, the issues identified in 2.1 can be resolved.

12 While the standardisation inspections conducted by the Agency for Regulations (EU) Nos 1034/2011 and 1035/2011

only started in 2012, these regulations replaced verbatim the former SES Regulations (EC) Nos 2096/2005 and 1315/2007 and, therefore, in addition, the feedback from the implementations of these regulations can be considered in order to make such conclusions.


2. Explanatory Note



2.3. Summary of the Regulatory Impact Assessment (RIA)

The Agency has performed a Regulatory Impact Assessment (RIA) for a number of key

regulatory developments that aim at addressing the issues identified above and that are

proposed in this NPA. The list of key regulatory developments that have been analysed

following the result of a RIA are as follows:

— Risk-based review decision by the competent authority;

— Risk-based review by the competent authority;

— CNS providers performing safety support assessment instead of safety assessment;

— Removal of Severity classification scheme from IR; and

— Changes affecting software and Regulation (EC) No 482/2008.

The following paragraphs provide a summary of the options analysed and the conclusions

of the analysis.

Risk-based review decision by the competent authority

The following options have been analysed:

— Option 1: do nothing.

— Option 2: propose a coherent risk based rule but delay implementation until sufficient

experience exists to use it

Option 1 and Option 2 were identified but not further considered because they were not

compatible with the Agency/EC’s policy for continuously improving the implementation of a

risk-based oversight.

From the options being analysed, the preferred option is Option 3 and it is the one

proposed in this NPA.

Some material explaining the risk-based selection model already exists. The model was

shown to be feasible in a study conducted by the UK CAA, which has been reviewed by

both the Rulemaking group for RMTs.0469 & 0470 members and the Agency. This study

argues that the principles and criteria needed to build a feasible risk-based selection model

that can achieve its intended purpose do exist. However, it recognises that before

mandating the model, it should be validated, i.e. the model should be implemented by

several CAs, and shown to be effective and lead to harmonisation. The proposed GM in this

NPA reflects the content of this study, outlines the model and describes the steps to

implement it. Consequently, it is felt that ample guidance material is provided in order to

prevent disharmony due to competent authorities wasting effort in developing short-lived

processes. Option 3, therefore, includes the risk-based selection clause in the IR and

guidance on its meaning and the intended method for enumerating the risk. However, the

validity of the model needs to be confirmed in practice and, consequently, implementation

will be delayed until the work foreseen in the feasibility study has been completed and

adequate AMC material has been written. In this way, competent authorities and service

providers are aware of the intentions and have guidance material explaining how the

proposed system is supposed to work and can, therefore, plan their own efforts to

accommodate the regulatory change when it happens.

The drawback of this approach is that since there will be no harmonised approach for some

time, the competent authorities and service providers may still go in different directions

and it would be difficult to realign them when the IR together with the AMC material is


2. Explanatory Note



applicable. However, in mitigation, the guidance material should give a relatively clear

steer to those establishing their own procedures and the Agency should closely monitor

and help to harmonise these developments.

Risk-based review by the competent authority


— Option 0: Do nothing.

— Option 2: Delay the development of the requirements until sufficient experience

exists to write it

— Option 3: Propose a risk based review rule but delay implementation until sufficient

experience exists to use it.

Option 1 was identified but not further considered because it was not compatible with the

Agency/EC’s policy for continuously improving the implementation of a risk-based

oversight.

From the options analysed, the preferred option is Option 3 and it is the one proposed in

the NPA.

The results of the study that is being conducted by the Ministry of Transport of the

Netherlands are not yet available and, therefore, the AMC and GM cannot be presented in

this NPA.

The drawback of this approach is that there will be no AMC or GM to support the

implementation and, therefore, the application of the rule will need to be postponed until

this material is developed. However, the current situation will be unchanged as the

competent authorities will continue to do as they are doing today. Indeed, the competent

authorities are trying to implement the existing requirement on risk-based review by

developing a concept of ‘level of involvement’ based on some criteria that they can apply

on a case by case basis. The study being carried out by the Ministry of Transport of the

Netherlands includes an assessment of this method.

CNS providers performing safety support assessment instead of safety

assessment


— Option 0: Do nothing

— Option 2: Require the CNS providers to perform a safety support assessment and

align it with the assessment that other non-ATS providers need to perform

Option 1, do not specify the type of analysis the CNS providers need to conduct when

assessing the changes to the functional systems, was also identified but not further

analysed .


the NPA.

The disadvantage with this option is that some CNS providers may expend considerable

effort in adapting to the new regulatory framework during the transition period. In other

cases, it might only require a change of mindset and a change in the way things are

named, rather than a large-scale change in working methods. It might also require ATS

providers and entities and organisations outside the scope of this Regulation to adapt to

the new situation because the assurance provided by the CNS provider will alter. Rather


2. Explanatory Note



than a pseudo safety assurance, they will, in future, provide assurance that their service

will behave as described in the specified context.

Removal of Severity classification scheme from IR


— Option 0: Do nothing; and

— Option 2: provide the rules for creating severity schemes for safety (into AMC and

provide examples of such severity schemes in GM)

Option 1: Provide a universal severity scheme for safety risk. However, after the proposal

of a considerable number of schemes, which are recorded in the GM on ‘Risk analysis in

terms of safety risk’, the group came to the conclusion that a universally acceptable

severity scheme was not feasible at the moment. Nor were they able to agree on a set of

schemes for use in different circumstances. Consequently, Option 1 is not considered

further here.

From the options analysed, the preferred option is Option 2, and it is the one proposed in

the NPA

The creation of multi-valued severity schemes should have the benefit of allowing more

appropriate and cost-effective risk analysis to be performed. It should also improve safety

by allowing ATS providers to maximise safety gains through focussing on scenarios with

the highest level of risk. The problem is that, initially, there may be a wide range of

different severity schemes proposed. However, with appropriate management and

oversight, these ought to be reduced to an acceptable number of schemes, which could

then be harmonised.

Changes affecting software and Regulation (EC) No 482/2008

Apart from Option 0 ‘do nothing’, two additional options have been proposed.

— Option 1: Include the assurance criteria of Regulation (EC) No 482/2008 within the

NPA and make it applicable to all parts of the functional system. Keep the redundant

Regulation (EC) No 482/2008. This increases the likelihood that the regulations

become inconsistent and is likely to impose unnecessary additional work for industry

and competent authorities. Furthermore the EC will have to approve two sets of

redundant legislations and maintain their translations. There are no safety benefits

with this option due to the risk of inconsistency, which will still exist due to redundant

regulations.

Therefore, Option 1 is discarded and not analysed further.

— Option 2: The provisions proposed in this NPA are to extract the assurance means

described in Regulation (EC) No 482/2008 and make them applicable to any of the

parts of the functional system (people, procedures or equipment) of the service

providers. As all the concepts of Regulation (EC) No 482/2008 are in this proposal,

which is also applicable to software because it is one of the parts that gives the

functional system its behaviour, there is no need to keep Regulation (EC)

No 482/2008.

The proposal is to repeal Regulation (EC) No 482/2008 because having two

regulations with requirements for the same thing is neither good regulation practice

nor ‘better regulation’. Firstly because different language is used in the different

regulations and this can cause confusion, and secondly, because either regulation can

evolve in different directions if not updated together.


2. Explanatory Note




the NPA.

While there are no negative safety or implementation impacts foreseen for Option 0

because nothing changes, there are no gains either. Option 0 has a negative impact on

better regulation and the cost effectiveness for the service provider and the competent

authority due to the fact that two regulations covering the same thing would be in force at

the same time. On the other hand, Option 2, which takes the opportunity to simplify the

existing rules and introduce ‘smart regulation in line with EU requirements’ has a positive

impact in all three categories.

2.4. Overview of the proposed amendments

The proposed amendments are presented following the structure of the rule being

proposed in the CRD to NPA 2013-0813. The proposals are presented highlighting the

differences with regard to the existing regulatory framework (Regulations (EU)

Nos 1034/2011 and 1035/2011) and briefly justifying these differences. Appendix I to this

Explanatory Note contains the cross references tables between the proposed provisions

and the requirements in the existing Regulations (EU) Nos 1034/2011 and 1035/2011.

2.4.1. Proposed amendments to Annex I ‘Definitions for terms used in Annex II to XIII’

A new definition of ‘aviation undertaking’ is added in order to address the organisations

that may be affected by a change carried out by a service provider, but are not regulated

under the same regulation as service providers, for example, if they are users of modified

services. These are organisations such as aerodrome operators, aircraft operators and

other airspace users such as military airspace users. This definition is new. GM has also

been developed to provide guidance on who may be covered by this term as it is not

possible to provide an exhaustive list of these organisations. This definition is needed as it

will be used in the proposed provisions related to the changes to the functional systems

that may affect the service provided by the provider to them.

It is proposed to amend the definition of ‘functional system’ in Regulations (EU)

Nos 1034/2011 and 1035/2011 so as to read as follows:

‘combination of procedures, human resources and equipment, including hardware and

software, organised to perform a function within the context of ATM/ANS’.

The word ‘systems’ from the previous definition has been replaced by ‘equipment’ in order

to avoid the difficulty that systems are generally thought of as comprising people,

procedures, equipment and architecture and so the term ‘system’ is overloaded in the

functional system definition. Furthermore, ‘system’ may be confused with the same term

used in Regulation (EC) No 549/200414 where it is inappropriate to cover the concept that

we are trying to regulate since it does not include people or procedures and whose scope is

limited to ANS. ATM has been complemented with ANS so as to cover the entire scope of

the services and be consistent with the scope of the Basic Regulation.

In order to complement the definition of functional system and to better understand the

scope of the requirements, the definition of equipment has been added in GM:

13 The structure of the rule is described in pages 16 to 20 of the Explanatory Note to NPA 2013-08 (A) and presented

graphically in Appendix I to the Explanatory Note. 14 Regulation (EC) No 549/2004 of the European Parliament and of the Council of 10 March 2004 laying down the

framework for the creation of the single European sky (the framework Regulation) (OJ L 096, 31.3.2004, p.1).


2. Explanatory Note



‘Equipment’ means an assembly of the framework for locating hardware, the hardware

itself and possibly a cover to act as a barrier between the internal and external

environments.

The GM also explains how software is linked to hardware, and hardware to equipment.

Therefore, when the regulation places requirements on functional systems, it does that on

equipment, which covers software and hardware. In other words, when a requirement

concerns equipment, then that requirement applies to all the constituent parts of the

equipment i.e. the framework, the hardware (including its contained software), that are

within the scope of the requirement.

It worth to mention that the definition of ‘hazard’ was changed in the CRD to NPA 2013-

08. The word ‘accident’ in the former definition has been replaced by ‘harmful effect’. The

reason for this change is to make it consistent with the definition of ‘risk’ which reads as

follows:

‘Risk’ means the combination of the overall probability, or frequency of occurrence of a

harmful effect induced by a hazard and the severity of that effect.’’

As risk is associated with hazards, both definitions need to have the same scope.

The definitions of ‘safety assurance’, ‘safety objective’ and ‘safety requirement’ are

no longer used in the provisions. Therefore, they have not been transposed. The reasons

for this will be explained in detail in Section 2.4.5 of this Explanatory Note.

The terms were used in point 3.2 of Annex II to the former rule, in the context of a

particular method of performing risk assessment and mitigation. The proposed provision

replacing this requirement is not method-oriented so the definitions are no longer relevant.

‘Safety assurance’, ‘safety objective’ and ‘safety requirements’ may still be used in the

regulation (e.g. as part of the safety management system requirements), however, in this

context they are meant in their normal English sense and not as specific technical terms.

Consequently, their meanings are not intended to be the same as the definitions contained

in Regulation (EU) No 1035/2011, and so, in order not to mislead, the definitions have

been removed.

2.4.2. Proposed amendments to Article 8 ‘Transitional provision’, Article 9 ‘Repeal’ and

Article 10 ‘Entry into force’ in the Cover Regulation

It is foreseen that Articles 8, 9 and 10 of the resulting text included in the CRD to NPA

2013-08 are amended by the provisions of this NPA as part of the same Opinion.

Regarding Article 8 ‘Transitional provisions’, it is proposed to provide a 2-year

transition for:

— the existing service providers regulated by Regulations (EU) Nos 1034/2011 and

1035/2011 to comply with the new proposed requirements;

— the competent authorities (CAs) to ensure that procedures for the oversight of

changes to the functional systems comply with the new proposed requirements.

Question 1: The Agency would like to know the stakeholders’ views about the

proposed 2-year transition period. If it is not considered sufficient, please

provide a justification.

Article 9 ‘Repeal’: As proposed in the CRD to NPA 2013-08, Article 10 already repeals

Regulations (EU) Nos 1034/2011 and 1035/2011. The cross reference table between these

requirements and the proposals in this NPA can be found in Appendix I to this Explanatory


2. Explanatory Note



Note. The proposed provisions aim at replacing the existing requirements for the assurance

of software where it is affected by change, and, therefore, the requirements in Regulation

(EC) No 482/200815 can be repealed. This would also serve to simplify the applicable

regulatory framework. A cross reference table comparing the requirements of

Regulation (EC) No 482/2008 with the proposed provisions can be found in Appendix II

(point 6.2) to this Explanatory Note. The impact of this proposal is analysed in Chapter 4.6

of the RIA. However, the Agency would like to have specific feedback from the

stakeholders on the following:

Question 2: Based on the cross reference table and on the justifications and

options analysed in the RIA, the Agency would like to seek the stakeholders’

views as to whether this proposal sufficiently covers the requirements in

Regulation (EC) No 482/2008, which, therefore, could be repealed. If the

answer is negative, please provide a rationale and identify those aspects that,

according to your analysis, are not covered.

Article 10 ‘Entry into force’:

As explained in Sections 4.2 and 4.3 of the RIA, the proposal is that the entry into force of

two requirements for the CA is delayed by 2 years in order to facilitate the harmonised

implementation of these requirements. The Agency believes that harmonisation can only

be facilitated by the development of AMC material; however, further experience and

evidence is needed before this can take place. Therefore, the proposal is that the Agency,

together with stakeholders experts, develop these AMCs following the rulemaking

procedures. This is explained further in 2.4.3 below.

2.4.3. Proposed amendments to Annex II ‘REQUIREMENTS FOR COMPETENT

AUTHORITIES IN ATM/ANS AND OTHER NETWORK FUNCTIONS (Part-

ATM/ANS.AR)’

In order to complete the requirements already proposed in the CRD to NPA 2013-08 for

the oversight of service providers by CAs, the relevant provisions associated with the

oversight of changes to functional systems have been added to Annex II:

— The provision added to ATM/ANS.AR.C.010 Oversight in (b)(5) and (b)(6)

addresses the oversight of changes to functional systems once implemented.

Although already covered by point (d)(ii) of Article 6 of Regulation (EU)

No 1034/2011, the addition is more comprehensive. It covers all aspects of the

oversight of the service providers’ management of changes to functional systems, i.e.

that changes are managed in accordance with approved change management

procedures, that monitoring of the operation of the changed functional systems is

performed and that there is an appropriate reaction if the monitoring shows that the

change is not behaving as anticipated.

— The provision ATM/ANS.AR.C.030 Approval of change management

procedures for ATM/ANS functional Systems has been added. This provision is

suggested by Article 9 of Regulation (EU) No 1034/2011, but there the requirement

is made from the perspective of the service provider and seems to imply that the CA

is bound to accept the change management procedures without review or the ability

to reject them. Furthermore, it does not make clear how modifications to and

15 Commission Regulation (EC) No 482/2008 of 30 May 2008 establishing a software safety assurance system to be

implemented by air navigation service providers and amending Annex II to Regulation (EC) No 2096/2005 (OJ L 141, 31.5.2008, p. 5)


2. Explanatory Note



deviations from such procedures are to be addressed by the CA. The proposed

provision does not introduce any new requirements on the CA but clarifies the

existing ones.

— ATM/ANS.AR.C.035 Decision to review the notified change. This provision is

proposed as a replacement to point 1 of Article 10 of the existing Regulation (EU)

No 1034/2011. As already explained in Section 2.1 of this Explanatory Note, the

existing requirements in point 1 of Article 10 could be misleading if applied strictly. It

is understood that the decision to review should be risk-based, but the existing

requirements only make the review subject to the severity of the effects of the

identified hazards without considering the likelihood dimension of the risk. Moreover,

in practice, the decision to review can only be made once the service provider has

done the severity assessment. The problem with this approach is that the severity

assessment occurs quite late in the development of a change. This might take place

after the service provider has notified the CA of the change. Since a decision will be

expected soon after the notification, the CA may neither have sufficient time nor all

the information needed in order to make their decision.

In addition, in the existing Regulation, a review is required if the implementation of

the change to the functional system requires the introduction of new aviation

standards. This also seems to support the notion that the decision is to be risk-

based. The criteria themselves do not clarify what circumstances would lead to the

creation of a new aviation standard and, therefore, its implementation is subjective.

For this reason, this criterion has been removed, and the provision now requires CAs

to use specific, valid, and documented criteria.

Anyway, this last point provides the CA with the authority to decide to review a

change in almost any circumstance and this possibility has been kept in the proposed

provision.

The new proposal requires the decision to review to be ’risk-based’. This basis for risk

is expressed as: the combination of the likelihood of the assurance case being

unsound and the severity of the possible consequences of the change. The proposed

requirement is based on the assumption that there exists a model that can provide

objective values for both variables: the likelihood of the assurance case being

unsound and the severity of the possible consequences of the change. So far the

Agency has only developed guidance material on how to build this model and what

properties should be considered based on the result of a study conducted by UK-CAA.

The guidance material is made available for consultation in this NPA. However, the

guidance material per se might not be sufficient to guarantee uniform

implementation.

While the rulemaking group members agreed with the concept behind the proposal to

make a ‘risk-based’ review decision, some of the members did not agree with the

expression used to define this ‘risk-based’. In particular, the expression that an

assurance case can be unsound (or invalid) was not agreed. The Agency did not find

another suitable expression to correctly reflect the intent of the provision. However,

the Agency recognises the different views of these members of the RMG and,

therefore, would like to seek the stakeholders’ views as follows:


2. Explanatory Note



Question 3: The Agency would like to seek the stakeholders’ opinion about

the expression ‘risk-based’ review decision, i.e. the risk upon which the

decision to review is based, which is proposed to be a combination of the

likelihood of the argument being unsound and the severity of the possible

consequences of the change. Furthermore, the stakeholders are kindly

asked to propose an alternative expression, in case of disagreement, that

correctly reflects the intent.

In the proposal, the criteria against which an assurance case can be judged to be

unsound is provided in the GM.

Based on this, it is proposed to delay the implementation of this provision by

2 years after the date of entry into force of the Regulation.

The Agency envisages that, within this 2-year delay, there will be a need to develop

specific AMC to ensure a sufficiently uniform implementation of the decision to review

a notified change.

In the meantime, nothing prevents the CAs from starting to apply the provision

based on the guidance material available. If they do, the Agency would appreciate

their feedback on its implementation. This information would help the Agency to

further develop the necessary AMC. This subject is further analysed in the RIA.

In addition, GM will be developed to support the CA’s decision to review safety

support assurance cases, which are produced by non-ATS providers, as part of the

2nd NPA.

— ATM/ANS.AR.C.040 Risk-based review of the notified change. This provision

replaces point 2 of Article 10 of Regulation (EU) No 1034/2011. The proposal

simplifies the existing requirements by making a direct reference to the requirements

applicable to the service provider, rather than repeating them. In this way, there is

no risk that any requirement will be missed. Neither is there a risk that some

requirements will be given more prominence than others and, therefore, give the

impression they are more important than others.

As already foreseen in Article 10 of Regulation (EU) No 1035/2011, the review of the

notified change is to be risk-based, but as identified above, it is ambiguous without

GM and AMC to explain what risk the review should be subject to. As in the case of

the decision to review, there exists insufficient material available today to clearly and

objectively define this risk. The GM provided for the risk-based decision in this

provision is not thought to be suitable for evaluating the risk on which the review

should be based. There is, also, no guidance available for the CA to justify the

breadth and depth of its review based on risk.

The Agency is waiting for the results of a study carried out by the Ministry of

Transport of the Netherlands in order to develop the GM and AMC necessary to

facilitate a harmonised implementation of this provision. Therefore, as in the case

of risk-based review decision, the Agency believes it is appropriate to delay

the implementation of this provision by 2 years after the date of entry into

force of the Regulation.

There is a collection of guidance material developed within the NSA coordination

platform (NCP) and by EUROCONTROL on the review of changes to functional

systems by competent authorities. The Agency intends to see if this guidance


2. Explanatory Note



material is suitable as a basis for the development of further GM to the CAs for the

review of notified changes.

The Agency is prepared to issue, as necessary, further AMC/GM for the CA included in

the 2nd NPA package.

— A change affecting more than one service provider and/or aviation undertaking is

called a ‘multi-actor change’ in this NPA. In multi-actor changes, the service

providers may come from different Member States and so the regulatory review of

different parts of the change could be performed by different CAs. Therefore, it may

be necessary, in some cases, for these CAs to coordinate with each other in order to

ensure a proper review of the overall change. Such coordination will be needed in

order to reach agreement on those parts of the change (those particular assurance

cases) to be reviewed and also to ensure that the service providers implement the

individual changes in a coordinated manner, i.e. one that the service providers have

agreed, by providing an argument in an overarching safety case, will be safe.

Depending on the change, they may also need to ensure that no part of the change

will be implemented until all the reviews have been completed successfully.

It would be understandable to query whether it is feasible or proportionate to

regulate the coordination arrangements of the CAs, i.e. the roles and responsibilities

of each CA before, during and after the review and also during and after the

implementation of the change. Therefore, the Agency wishes to introduce a specific

question in this respect.

Question 4: The Agency would appreciate receiving feedback from

stakeholders on the following: would it be appropriate to regulate the

coordination arrangements between the competent authorities in order to

guarantee a proper oversight of multi-actor changes in addition to the

general coordination requirements contained in ATM/ANS.AR.B.001(d),

which are included in the resulting text of the CRD to NPA 2013-08? If the

answer to the above is positive, what should be the criteria for such a

coordination? Moreover, how should disagreements between CAs be

regulated?

In order to help the stakeholders with their reply, there follows some proposals for

requirements for the coordination arrangements between the CAs:

— when overseeing multi-actor changes (based on the requirements in

ATM/ANS.AR.B.001(d)):

‘…The competent authority shall establish formal interfaces and coordination

arrangements with other competent authorities to ensure effective selection

and review of changes that involve more than one service provider, under the

oversight of different competent authorities, changing their functional

systems…’

— when deciding to review or not the changes performed by the different service

providers involved in a multi-actor change:

‘…When a change notified according to ATM/ANS.OR.A.050 045(a)(1) involves

more than one service provider changing their functional systems and they are

under the oversight of different competent authorities, these competent

authorities shall, based on their established coordination arrangements, inform

each other about the decision on whether to review the changes or not…’


2. Explanatory Note



— when reviewing the changes performed by the different service providers

involved in a multi-actor change:

‘…When a change involving more than one service provider changing their

functional systems under the oversight of different competent authorities has

been selected for review by the competent authorities concerned, these

competent authorities shall, based on their established coordination

arrangements, plan and coordinate the review of the change…’

2.4.4. Proposed amendments to Annex III ‘COMMON REQUIREMENTS FOR SERVICE

PROVIDERS (Part-ATM/ANS.OR)’

This NPA proposes that the following provisions be included in Annex III of the resulting

text of the CRD to NPA 2013-08 in order to complete the requirements for service

providers for the assessment of changes to functional systems:

— A new provision ATM/ANS.OR.A.045 Changes to the functional system has

been included as a replacement for Article 9.2 of Regulation (EU) No 1034/2011. The

requirement proposes that more detailed information be provided when notifying the

CA of a change. It also states what has to be done when the information provided

with the notification changes. The minimum information that accompanies the

notification is described in AMC/GM. Examples of the different ways notification may

be performed have been provided in GM.

This provision is a clarification of Article 9.3 of Regulation (EU) No 1034/2011. It

requires the service provider to follow the applicable, and approved procedures for

managing the change and, where the CA has decided to review the change, wait until

the change has been approved before putting it into operation. Flexibility is provided

in that the service provider does not need to wait until the complete change has been

approved before putting parts of it into operation. The CA can approve parts of the

change individually. This allows, in the case of a change that affects many parts of

the functional system, e.g. training of ATCOs, changes to the equipment and changes

to operational procedures, the service provider to start to train the ATCOs, after the

CA has approved the assurance case, even though the equipment has not yet been

changed and neither have the operational procedures.

This requirement also includes new provisions to deal with the case of multi-actor

change. As defined in 2.4.3, a multi-actor change is a change involving more than

one service provider and an aviation undertaking16. The purpose of these provisions

is to ensure that all risks are correctly identified and mitigated. In order to do this,

coordination between the service provider making the change and the affected

service providers and aviation undertakings is required. This new requirement tries to

resolve one of the issues identified in 2.1 related to the completeness of the existing

Regulation. It regulates the way the service providers act when they are making a

change that affects other stakeholders, i.e. service providers and aviation

undertakings, either because the other stakeholders use their services (directly or

indirectly) or because the change has the potential to alter the operational

environment in which the other stakeholders operate. It requires the service provider

to inform the stakeholders about the planned change, which may or may not, in turn,

16 Aviation undertakings are organisations that are not regulated by this IR but are involved in ATM/ANS. For instance,

airspace users (e.g. aircraft operator), aerodrome operators and military users are all aviation undertakings. They are defined in Annex I to the proposed regulation and a list of examples is given in GM.


2. Explanatory Note



have an impact on their services and require a reactive change to their functional

systems. Coordination between the affected service providers is needed in order to

identify all possible affected parties and determine the dependencies between them.

The proposal also requires the service providers to coordinate the assessment

amongst themselves and with the affected aviation undertakings. The aim here is to

completely identify all shared assumptions and, if necessary, allocate risk mitigations

that will ensure the total change is safe enough. This is especially relevant when the

other providers have to change their functional systems as well. GM has been

provided to help in the implementation of this requirement. In particular, it might

happen that other service providers or aviation undertakings are not willing to

cooperate in the implementation of the change. In that case, the GM proposes ways

of dealing with the situation, e.g. the service provider would refer to its CA, who

could try to resolve the issue so as to achieve cooperation.

In an extreme case where, even with support from CAs, there is no cooperation, the

service provider may need to:

find additional supporting evidence for their assumptions and mitigations;

propose a modification to the scope of the initially planned change;

propose different mitigation means; or

even decide to abandon the change.

— Two new provisions have been added to ATM/ANS.OR.B.005 Management

system: (a)(5) and (a)(6), to introduce processes into the management system of

service providers that actively search for the need to change the functional system.

This process is called ‘change drivers’.

The provisions were not explicitly required in the existing Regulations, but implicitly

required in Sections 3.1.1(d), 3.1.3(b), 3.2.4 and 4 of Annex II to Regulation (EU)

No 1035/2011.

The ATM/ANS.OR.B.005(a)(5) provision requires having a process that ensures

that the service provider is aware of the context in which he provides services and

takes appropriate action e.g. plans a change to the functional system, when the

context is due to change. This is to avoid the behaviour of the service changing due

to unnoticed changes in the operational environment. The reasons for this are given

in GM and the drivers include awareness of changes: in the environment of

operation, in the services he uses, in the environment of operation of the services he

uses and in his functional system that have not caused the service to degrade but

may do so in the near future.

The ATM/ANS.OR.B.005(a)(6) provision is a requirement for continuous

improvement of the performance of the services and is equivalent to the requirement

in Section 4 of point 3.2.4 of Annex II to Regulation (EU) No 1035/2011. It is a

change driver that seeks continuous improvement of performance, which for an air

traffic service provider includes improving safety performance. Consequently, it has

been relocated so that its relationship with the other change drivers is clear. The text

has also been clarified and broadened to include all performance attributes rather

than just safety. The Agency is also proposing this requirement to align with the

ICAO and ISO 9001 concepts of continuous improvement.


2. Explanatory Note



While in today’s regulation these two aspects were implicitly required only for ATS

and CNS providers, the proposal in this NPA is to expand this concept to cover all

other certified service providers. This is because proactive performance management

and continuous improvement are objectives required by the Basic Regulation and

ICAO SARPs for the management system for all certified service providers.

The rulemaking group was not unanimous in the inclusion of ‘change drivers’ in

general in the Implementing Rule. They did not find it necessary as it was considered

to be happening today without the need of regulation. The Agency considers that the

proposal provides ground for harmonisation of the concept and for requesting the

service providers to actively identify and make changes whenever feasible in a

systematic manner. The Agency also considers that this implements the objectives of

the Basic Regulation, in particular when it comes to maintaining a high level of

safety. However, the Agency fully recognises the importance of the opinion of the

experts in the rulemaking group and, therefore, would like to seek for the broad

opinion of the stakeholders on the following:

Question 5: The Agency would like to know whether the stakeholders agree

or disagree with the proposal made in this NPA for proactive performance

management and for continuous improvement as foreseen by the Basic

Regulation and ICAO SARPs. Please provide the supporting rationale with

your answer.

— A new provision has been added, ATM/ANS.OR.B.005 Management system (d),

which complements the change driver provisions. It makes the requirement of point

3.1.3(b) of Annex II to Regulation (EU) No 1035/2011 explicit, and in addition

expands it to cover the case when, during operation, the change is found to

contradict the assurance argument provided for it.

The requirement is for the service provider to monitor the behaviour of the service it

provides and if it is not performing as intended then to establish why it is not doing

so and plan and implement a change to eliminate the causes of the substandard

performance or to mitigate them. This provision, which was present in Regulation

(EU) No 1035/2011 has been extended to cover changes that have been

implemented and become operational. In these cases, the assurance argument

predicts the behaviour of the change. This is done by establishing monitoring

requirements as part of the change design. If, during operation, these monitoring

requirements are not satisfied, then the assurance argument does not match the

behaviour of the change. This indicates that either the change is not as predicted

and, therefore, substandard, or that the argument, although apparently sound during

its review, is in fact unsound. In the former case, the service provider needs to

initiate a change to the functional system, while in the latter case he merely needs to

correct the assurance argument.

These requirements are also part of the proactive performance management, which

should be included as part of the management system.

The inclusion of this requirement in the Implementing Rule was not shared by the

rulemaking group as a whole; in particular some experts felt that the provision of the

requirements to monitor changes would, after so many changes, lead to too many

requirements to monitor. The Agency is of the view that new changes should review

previous monitoring arrangements and could well modify and replace existing

monitoring requirements from previous changes. The requirement should not be


2. Explanatory Note



understood as an accumulation of monitoring requirements, change after change, but

more as a way to improve the monitoring of the whole service, as changes

accumulate, and ultimately to provide grounds for clarification and harmonisation of

the means for establishing the adequacy of the service providers safety provisions

and which could, in the long run, lead back to the concept of appropriate safety levels

for service providers (see also the argument in 2.4.5 – Safety of the change). The

Agency also considers that this implements the objective of the Basic Regulation in

relation to continuous improvement and overall safety management. However, the

Agency fully recognises the importance of the opinion of the rulemaking group as a

whole and would like to seek the views of the stakeholders specifically on the

following:

Question 6: The Agency would like to know whether the stakeholders

agree or disagree with the proposal made to clarify and close the loop (i.e.

check the effectiveness) in relation to the monitoring requirements

resulting from the assessment of the changes to functional systems.

Please provide the supporting rationale with your answer.

— A new provision, ATM/ANS.OR.B.010 Change management procedures, has

been included in the proposal. This provision incorporates Article 9(1) of Regulation

(EU) No 1034/2011 and point 3.1 of Annex I to Regulation (EU) No 1035/2011.

However, the proposed provision provides more detail about the management of the

change management procedures by the service provider and their approval by the

CA. It also includes the possibility to deviate from these approved procedures if the

service provider has found that they are not suitable for a particular change. The

proposed provision gives service providers the flexibility to include these procedures

as part of the management systems or to be reviewed and approved separately from

it. These procedures can be approved after the certification of the service provider,

provided that they are approved by the CA before the service provider uses them to

perform any change to its functional system.

— A new subpart is proposed to be added to Annex I: ‘SUBPART C — SPECIFIC

ORGANISATIONAL REQUIREMENTS FOR SERVICE PROVIDERS OTHER THAN

ATS PROVIDERS’. So far, no distinction has been made in the applicable

requirements between the different service providers. This new Subpart proposes a

set of requirements for the assessment and assurance of the changes to functional

systems by service providers other than ATS providers. The reason a different set of

requirements for ATS providers and for service providers other than ATS providers is

seen as necessary is that they have different responsibilities related to safety and

that they may not know the safety impact of the use of their services by others. First

of all, it is important to highlight that all service providers provide safety-related

services in the sense that they all provide services needed for the safe conduct of a

flight. The difference is whether the service provider can or cannot dynamically

intervene in order to control the safe use of the service it provides, when it sees an

unsafe situation developing. The provider of a service other than ATS does not have

this dynamic view of the use of the service and, therefore, cannot intervene in order

to alter the situation. Furthermore, the non-ATS provider may not know how its

services are being used, either in normal circumstances or in circumstances where

immediate intervention is necessary in order to maintain safety. Consequently, it will

not be able to judge whether the service provided will be used safely. Therefore, it

would be disproportionate to impose the same assessment responsibilities for these


2. Explanatory Note



two different type of services. While an ATS provider cannot be said to have absolute

control over the use of any service directly supplied to an aircraft, those services are

provided within the framework of a plan for controlling separation for all aircraft

receiving ATS. Within that plan, the ATS provider has to be aware and take care of

the fact that the initial plan may not be adhered to and so it will have to modify the

plan in order that all aircraft remain safe.

For these reasons, it is necessary to differentiate between the types of assessment

the different type of service providers are able to conduct. ATS providers will need

to conduct a safety assessment of the changes to the functional systems

because they will be able to manage the safety of the services they provide.

Therefore, ATS providers will be able to provide a safety argument to

present the result of the safety assessments. Service providers other than

ATS providers shall conduct what has been called, in this NPA, a ‘safety

support assessment’. The result of the ‘safety support assessment’ is

presented in a safety support argument. More explanations can be found in the

GM1 Annex I Definitions(36) & ATM/ANS.OR.C.005 & ATS.OR.205 General SERVICES,

INFORMATION AND THE RESPONSIBILITY FOR SAFETY. The goal of a safety support

assessment is to ensure that the changed service will behave only as specified (it

does what it is said to do and nothing more) in the specified environment

(operational environment) and the way the service behaves complies with and does

not contradict any applicable requirements placed on the changed service by this or

other regulations. These requirements are included in the safety support assessment

provision. Other provisions included in this Subpart are: the determination of the

scope of the change, the determination of the monitoring requirements that will

demonstrate that the change is behaving as predicted by the assurance argument

during operation, and the provision of the assurance argument itself. The assurance

argument is a complete, valid and documented argument that provides sufficient

confidence that the service will behave and will continue to behave only as specified

in the specified environment. This argument is a collection of claims, evidence and

inferences that link the evidence to the claims. It is provided in an assurance case. In

this case, it is called a ‘safety support case’, whereas the equivalent argument

provided by an ATS provider is called a ‘safety case’. GM and AMC are provided to

explain the concept of ‘assurance case’, ‘safety support case’ and ‘safety case’ and

what the safety support assessment should address. The notion of service

specification is also provided in AMC and GM. The service specification is a complete

description of the behaviour of the service after the change, given the context in

which it is intended to operate.

It is important to highlight that the existing provisions do not describe the way air

navigation service providers other than ATS and CNS providers should assess the

changes to their functional systems. The Agency does not see the rationale for this,

in particular when it comes to maintaining a high level of safety. In this respect, the

proposed provision complements the existing Regulation by detailing the

requirements for the assessment of changes these providers make to their functional

systems.

It is also important to highlight that the proposed provision constitutes a change for

CNS providers with regard to what is required by the existing Regulation. Since this is

considered to be a significant change to the existing Regulation, it is analysed in

more detail in Section 4.4 of the RIA.


2. Explanatory Note



— The proposed provisions replace and extend the existing requirements in Regulation

(EC) No 482/2008. All the concepts of the said Regulation are included in various

parts of the proposed provisions, but are now applicable to all the parts of functional

systems (people, procedures and equipment) rather than to software alone.

Consequently, all requirements from Regulation (EC) No 482/2008 are mapped to

requirements in the current proposal. The mapping can be found in Appendix II

(Section 6.2) to this Explanatory Note. Taking into account that this is considered to

be a significant change to the existing Regulation, it is analysed in more detail in the

Section 4.6 of the RIA. In addition, a question on the subject has been made in

Section 2.4.2 of this Explanatory Note.

2.4.5. Proposed amendments to Annex IV ‘SPECIFIC REQUIREMENTS FOR THE

PROVISION OF AIR TRAFFIC SERVICES (Part-ATS)’

Annex IV applies to ATS providers only, therefore, as explained in 2.4.4, the relevant

requirements for the assessment of changes to functional systems are part of the safety

management requirements. The following requirements have been added to the resulting

text of the CRD to NPA 2013-08 to complete the requirements for ATS providers for the

assessment of changes to functional systems:

— Safety of the change This requirement has been added to complement the SMS

framework (ATS.OR.200 Safety management system, new points (b) and

(c)). It builds on ICAO Annex 19 policy with certain clearer and more specific

provisions.

It was the intention of the European Commission to include a quantitative safety risk

objective for the change as part of the former Regulation (EC) No 2096/2005. At that

time, the European Commission issued a mandate to EUROCONTROL to complete the

Regulation in this regard. The mandate was not concluded because of the technical

difficulties related to the lack of specific and convincing data about the actual safety

risk level currently being experienced. Whilst it was felt that the safety of air

transport was generally regarded as being adequate, the actual safety levels being

achieved by a particular service provider for a particular service were undetermined

and many believed undeterminable in the near future. Consequently, setting targets

other than to maintain safety at its current level and where feasible improve it were

felt to be unattainable in the current circumstances.

This requirement was, therefore, not explicitly included in the existing Regulations

(EU) Nos 1034/2011 and 1035/2011.

For each change, an ‘objective for safety’17 should be established, and it is the

responsibility of the safety management system to provide this ‘objective for safety’.

In general, this ’objective for safety’ as proposed in this NPA, shall be that the safety

of the service provided by the changed functional systems is at least the same as the

safety of the service provided by the functional system before introducing the

change. Equally, by taking account of the ATM/ANS.OR.B.005(a)(6) requirement,

there may be instances where the safety can be improved and these instances should

be reflected in the ‘objective for safety’ related to the change. It is, however,

understood that in some cases, the service provider may not be able to guarantee

that maintaining or improving safety can be achieved by the proposed change.

Therefore, the proposal made is that the ATS provider agrees with its CA on a course

17 This ‘objective for safety’ is different from the term ‘safety objective’ found in former Regulation (EU) No 1035/2011.


2. Explanatory Note



of action. For instance, the change may become part of a transition to a larger

change. This is fully explained in GM1 ATM/ANS.AR.C.035 & ATM/ANS.OR.A.045

General. Another possibility would be that the service provider makes a case to the

CA that the situation may exist for some time, but that there is a plan to bring the

safety risk of the service back to an acceptable level (meaning achieve the ‘objective

for safety’) at some point in the future, via, for instance, another change.

Therefore, while this can be considered to be a new requirement, the intention has

always been to complete the existing requirements.

Some members of the rulemaking group did not agree with the inclusion of this

requirement in the Implementing Rule. They indicated that it might not be possible to

meet this requirement in all cases and, therefore, the role of the safety criteria for

the change without a regulation on the overall safety of the change or safety goal

would be sufficient. The Agency considers that if the ‘the objective for safety’ is not

specifically mentioned, safety could degrade over time as there would be no clear

statement of what is considered to be acceptable. However, the Agency recognises

the difficulties the service providers may face, in some cases and would, therefore,

like to seek the views of the stakeholders specifically on the following:

Question 7: The Agency would like to know whether the stakeholders

agree or disagree with the proposal for an overall objective for safety for

the change as part of the SMS. Please provide the supporting rationale

with your answer.

— A new provision is included in ATS.OR.205 Safety assessment and assurance

of changes to the functional system. This provision replaces point 3.2 of Annex II

to Regulation (EU) No 1035/2011. However, it is more generic and does not impose

the use of any particular method on the service provider. Indeed, the proposed

requirements allow different methods and techniques to be used to perform the

safety assessment of changes to the functional system.

Moreover, the safety assessment could be carried out using explicit safety risk as a

safety criterion or could be carried out using other measures related to safety risk.

One of these measures is called a ‘proxy’ to safety risk and is described in AMC and

GM. The requirements have been complemented with a set of GM and AMC to help

the ATS providers to comply with them. The severity table which is included in

Section 4 of point 3.2 (point 3.2.4) of Annex II to Regulation (EU) No 1035/2011 is

now in GM. Additionally, rules for the construction of a severity table are provided in

AMC. This is because it has been found that there can be other types of severity

schemes that can be more appropriate for different operational environments.

Therefore, a severity classification limited to only one possibility would have been too

restrictive and without any added value to the assessment. This is in line with the

approach taken to ensure that the requirements are generic and not method-

oriented, and is a significant change to the existing Regulation. This is the reason

why this issue is analysed in more detail in the RIA Section 4.5.

The proposed provisions do not provide a severity classification scheme for the

reasons given above. However, guidance is given on the creation and use of severity

classification schemes. This guidance could, in the fullness of time, become AMC,

once there is sufficient experience to harmonise the approach to such a scheme and

sufficient data to justify its existence.


2. Explanatory Note



In addition, the proposed provisions follow the approach of the safety support

assurance requirements, but instead of providing assurance that the service will

behave only as specified in the specified environment, in the case of an ATS provider,

the safety argument contains the assurance that the safety criteria, which are linked

to the ‘objective for safety’, are valid, satisfied and will remain satisfied during the

operation of the changed service.

This requirement includes: the determination of the scope of the change; the

identification of hazards; risk assessment and, if necessary, mitigation; verification;

and the identification of monitoring criteria.

As is done in the case of a safety support assessment, the requirements describe the

scope of the change in terms of: the elements of the functional systems being

changed; the interfaces and interactions between the elements being changed and

the remainder of the functional system; the interfaces and interactions between the

elements being changed and the environment in which it is intended to operate; and

the lifecycle of the change from definition to operations including any planned

degraded modes. These details can also be found in the existing requirements.

— A new provision ATS.OR.210 Safety Criteria has been included. It describes the

criteria that are used to decide the safety acceptability of a change to a functional

system. Such criteria shall be specific, observable and verifiable. They can be

expressed in terms of safety risk or other measures that relate to safety, e.g.

proxies.

The set of safety criteria, when taken as a whole, shall satisfy the ‘objective for

safety’. As part of the assurance argument, this claim needs to be justified.

The AMC/GM provide information on several possibilities for establishing the safety

criteria. In addition, the requirements constraining the selection of a property that

may be used as a proxy are also provided.

The notion of safety criteria was implied in Regulation (EU) No 1035/2011 but not

explicitly mentioned. This is likely to be because the assessment foreseen by the

existing requirements is bottom-up: the risk assessed is based on established

objectives for safety or safety goals. When these are found to be unacceptable, the

risk is mitigated. Therefore, the existing requirements did not mention that this was

needed to be done based on safety acceptance criteria, but the assumption was that

they were necessary.

The proposed provisions foresee, although they do not demand, a top-down process.

The safety acceptance criteria are established and then the risk associated with the

initial design of the change is assessed. If this design does not lead to satisfying the

safety criteria, then the design is altered i.e. mitigation measures are established so

as to meet the safety criteria. Consequently, while in the existing requirements the

assessment criteria are implied, in this proposal they are explicit and the

requirements are, therefore, clearer in this respect.

2.4.6. Guidance material of general nature

The provisions include, in separate sections, requirements for different stakeholders. In

particular, the requirements for service providers are separated from the requirements for

CAs. However, in many cases the stakeholders interact, e.g. CAs review and approve

change procedures that are created by service providers and different types of service

providers interact during multi-actor changes. It was felt more appropriate to write


2. Explanatory Note



common GM for these interactions than to try to respect the normal constraints of

associating and placing GM with the requirement to which it relates. Thus, this type of GM

is presented the first time it pertains to a requirement, and then it is simply referred to

each time it is needed (that is, when it pertains to another requirement).

The following GMs are included:

— GM1 Annex I Definitions (36) & ATM/ANS.OR.A.045 & ATM/ANS.OR.C.005 &

ATS.OR.205 General

CHANGE TO FUNCTIONAL SYSTEM AND ITS ASSESSMENT

The purpose of this GM is to describe the circumstances that may result in a need to

change the functional system and to describe the relationship between the nature of

the change and its cause. Furthermore, this GM gives a general description of the

assessment of changes. It provides examples of changes subject to the requirements

described in this NPA as well as examples of changes that are to be managed outside

these requirements.

— GM1 Annex I Definitions(36)

FUNCTIONAL SYSTEM

The purpose of this GM is to provide a reference model that describes the structure of

the functional system, the relationships between it and the environment in which it is

used and the way change propagates throughout the wider system.

— GM2 Article 2 (2) Definitions

SERVICE PROVIDERS

The purpose of this GM is to show, using the general description of the functional

system contained in GM1 Annex I Definitions(36) FUNCTIONAL SYSTEM and the

legal basis for the definition of an ATM/ANS provider, how ATM/ANS providers may

be organised.

— GM1 Annex I Definitions(36) & ATM/ANS.OR.C.005 & ATS.OR.205 General

SERVICES, INFORMATION AND THE RESPONSIBILITY FOR SAFETY

The purpose of this GM is to explain the difference in responsibilities for safety

between an ATS provider and other types of service providers. In addition, it describe

the rational for the differences in the type of assessment each has to make i.e. safety

assessments are required of ATS providers while safety support assessments are

required of other ATM/ANS providers

— GM1 ATM/ANS.AR.C.035 & ATM/ANS.OR.A.045 General

INTERACTIONS BETWEEN SERVICE PROVIDERS & COMPETENT AUTHORITIES

DURING THE CHANGE PROCESS

The purpose of this GM is to describe the interactions that take place between the

service provider making a change to its functional system and the CA in deciding

whether to review the change or not and in reviewing the change. It also explains the

use of some of the technical terms provided in the Implementing Rule.


3. Proposed amendments — Draft EASA Opinion



3. Proposed amendments

The text of the amendment is arranged to show deleted text, new or amended text as

shown below:

(a) deleted text is marked with strike through;

(b) new or amended text is highlighted in grey;

(c) an ellipsis (…) indicates that the remaining text is unchanged in front of or

following the reflected amendment.

3.1. Draft Regulation (Draft EASA Opinion)

ANNEX I

Definitions of terms used in Annexes II to XIII

For the purposes of this Regulation, the following definitions shall apply:

…

20 ‘Aviation undertaking’ means an entity, person or organisation, other than the

organisation regulated by this Regulation that is affected by or affects a service delivered

by a service provider;

…

35 ‘Functional system’ means a combination of procedures, human resources and

equipment, including hardware and software, organised to perform a function within the

context of ATM/ANS;

…





ANNEX II

REQUIREMENTS FOR COMPETENT AUTHORITIES — SERVICE PROVISION AND

NETWORK FUNCTIONS (Part-ATM/ANS.AR)

SUBPART A — GENERAL REQUIREMENTS

…

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

…

SUBPART C — OVERSIGHT, CERTIFICATION, AND ENFORCEMENT

(ATM/ANS.AR.C)

…

ATM/ANS.AR.C.010 Oversight

…

(b) The audits referred to in paragraph (a) shall:

…

(5) verify that changes made to the functional system:

(i) comply with ATM/ANS.OR.A.045;

(ii) have been managed in accordance with ATM/ANS.OR.B.010; and

(iii) are being verified against the monitoring requirements that were identified in

the assurance argument as a result of complying with

ATM/ANS.OR.C.005(b)(3) or ATS.OR.205(b)(7), as appropriate.

(6) verify that if, as a result of the monitoring referred to in (5)(iii), the

argument, referred to in ATS.OR.205(a)(2) and ATM/ANS.OR.C.005(a)(2), is

found to be unsound, then the service provider shall initiate a change or

provide a valid argument.

...

ATM/ANS.AR.C.030 Approval of change management procedures for ATM/ANS

functional systems

(a) The competent authority shall review:

(1) those procedures submitted by a service provider in accordance with

ATM/ANS.OR.B.010(a);

(2) all modifications to the procedures referred to in (1); and

(3) any deviation to the procedures referred to in (1) for a particular change, when

requested by a service provider in accordance with ATM/ANS.OR.B.010(b)(1).

(b) The competent authority shall approve the procedures, modifications and deviations

referred to in (a) when it has determined that they are necessary and sufficient for the





service provider to demonstrate compliance with ATM/ANS.OR.A.045, ATS.OR.205,

ATS.OR.210 or ATM/ANS.OR.C.005, as applicable.

ATM/ANS.AR.C.035 Decision to review the notified change

(a) Upon receipt of a notification in accordance with ATM/ANS.OR.A.045(a)(1), or upon

receipt of modified information in accordance with ATM/ANS.OR.A.045(b), the competent

authority shall make a decision on whether to review the change or not. The competent

authority shall request any additional information needed from the service provider to

support this decision.

(b) The competent authority shall determine the need for a review based on specific, valid

and documented criteria that shall:

(1) as a minimum ensure that the notified change is reviewed if the combination of the

likelihood of the argument being unsound and the severity of the possible

consequences of the change is significant.

(2) be used in addition to (1), when the competent authority decides the need for a

review based on other criteria.

(c) The competent authority shall inform the service provider of its decision and shall

provide the associated rationale to the service provider on request.

ATM/ANS.AR.C.040 Risk-based review of the notified change

(a) When the competent authority reviews the argument for a notified change, it shall:

(1) verify that the procedures used by the service provider, as defined in

ATM/ANS.OR.B.010, were approved;

(2) use documented procedures and guidance to perform their review;

(3) assess the validity of the argument presented with respect to ATS.OR.205(a)(2)

and/or ATM/ANS.OR.C.005(a)(2); and

(4) coordinate its activities with other competent authorities whenever necessary.

(b) The competent authority shall conduct the review in a manner which is proportionate to

the risk associated with the change.

(c) The competent authority shall:

(1) approve the argument referred to in ATS.OR.205(a)(2) and

ATM/ANS.OR.C.005(a)(2), with conditions where applicable, and so inform the

service provider of their acceptability, or

(2) reject the argument referred to in ATS.OR.205(a)(2) and ATM/ANS.OR.C.005(a)(2)

and inform the service provider of their unacceptability with supporting rationale.





ANNEX III

COMMON REQUIREMENTS FOR SERVICE PROVIDERS

(Part-ATM/ANS.OR)

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

…

ATM/ANS.OR.A.045 Changes to the functional system

(a) A service provider planning a change to its functional system shall:

(1) notify their competent authority of the change;

(2) provide the competent authority, if requested, with any additional information that

allows the competent authority to decide whether or not to review the change; and

(3) inform service providers and, where feasible, aviation undertakings affected by the

planned change.

(b) Having notified a change, the service provider shall inform the competent authority

whenever the information provided under (a)(1) and (2) is materially modified, and the

relevant service providers and aviation undertakings whenever the information provided

under (a)(3) is materially modified.

(c) The service provider shall only allow the parts of the change, for which the activities

required by the procedures referred to in ATM/ANS.OR.B.010 have been completed, to enter

into operational service.

(d) If the change is subject to competent authority review in accordance with

ATM/ANS.AR.C.035, the service provider shall only allow the parts of the change for which

the competent authority has approved the argument to enter into operational service.

(e) When a change affects other service providers and/or aviation undertakings, as identified in

(a)(3), the service providers affected shall:

(1) determine all the dependencies with each other and with the affected aviation

undertakings;

(2) include in their notifications to their competent authorities, in accordance with (a)(1),

a list of the service providers and other aviation undertakings that are affected;

(3) plan and conduct a coordinated assessment considering the dependencies as

determined in (1); and

(4) determine the assumptions and risk mitigations that relate to more than one service

provider or aviation undertaking.

(f) Those service providers affected by the assumptions and mitigations in (e)(4) shall:

(1) mutually agree and align these assumptions and risk mitigations; and

(2) where feasible, mutually agree and align these assumptions and risk mitigations with

the aviation undertakings affected by them.

…





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

…

ATM/ANS.OR.B.005 Management system

(a) A service provider shall implement and maintain a management system that includes:

…

(5) a formal process to identify circumstances within the service provider’s organisation

and the environment in which it operates that may affect the provision of ATM/ANS

and, where necessary, to plan changes to their functional system to accommodate

these circumstances;

(6) a formal process to consider changing their functional system if it is technically and

economically feasible to improve performance by doing so.

…

(d) The service provider shall monitor the behaviour of the functional system and where:

(1) substandard performance is identified, establish its causes, determine the

implications of such substandard performance, and shall initiate a change to

eliminate or mitigate such causes; and

(2) it is found that an argument associated with a change to that functional system

is unsound, the service provider shall initiate a change or provide a valid

argument.

…

ATM/ANS.OR.B.010 Change management procedures

(a) Procedures that will be used by a service provider to manage, assess, and, if necessary,

mitigate the impact of changes to their functional systems in accordance with

ATM/ANS.OR.A.045, ATS.OR.205, ATS.OR.210, ATM/ANS.OR.C.005 or any material

modifications to those procedures shall:

(1) be submitted, for approval, by the service provider to the competent authority; and

(2) not be used until approved by the competent authority.

(b) When the approved procedures referred to in (a) are not suitable for a particular change,

the service provider shall:

(1) make a request to the competent authority to deviate from the approved procedures;

(2) provide the details of the deviation and the justification for its use to the competent

authority; and

(3) not use the deviation before being approved by the competent authority.

…





SUBPART C — SPECIFIC ORGANISATIONAL REQUIREMENTS FOR SERVICE

PROVIDERS OTHER THAN ATS PROVIDERS

ATM/ANS.OR.C.001 Scope

This Subpart establishes the requirements to be met by service providers other than ATS

providers with respect to additional responsibilities to those established in Subparts A and B.

ATM/ANS.OR.C.005 Safety support assessment and assurance of changes to the

functional system

(a) A service provider other than an ATS provider shall:

(1) ensure that a safety support assessment is carried out; and

(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,

for any change they have notified in accordance with ATM/ANS.OR.A.045(a)(1).

(b) A service provider other than an ATS provider shall ensure that the safety support

assessment referred to in (a) comprises:

(1) the definition of the scope of the change, which consists of:

(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; and

(iv) the life cycle of the change from definition to operations including transition into

service and planned degraded modes;

(2) verification that:

(i) the change conforms to the scope that was subject to safety support

assessment; and

(ii) the service behaves only as specified in the specified context; and

(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;

(3) the specification of the monitoring requirements necessary to demonstrate that the

service delivered by the changed functional system will continue to behave only as

specified in the specified context.

SUBPART D — SPECIFIC ORGANISATIONAL REQUIREMENTS FOR ANS AND ATFM

PROVIDERS AND THE NETWORK MANAGER (ATM/ANS.OR.C)

…





ANNEX IV

SPECIFIC REQUIREMENTS FOR THE PROVISION OF AIR TRAFFIC SERVICES

(Part-ATS)

SUBPART A — ADDITIONAL ORGANISATION REQUIREMENTS FOR THE

PROVISION OF AIR TRAFFIC SERVICES (ATS.OR)

Section 1 — General requirements

…

Section 2 — Safety of services

ATS.OR.201 Safety management system

…

(b) The air traffic service provider shall ensure as part of its SMS that the objective for the

safety of a planned change to a functional system that has been notified in accordance with

ATM/ANS.OR.A.045(a)(1), shall be that the service will be at least as safe after the change

as it was before the change.

(c) Where (b) cannot be achieved, the ATS provider shall reach agreement with the competent

authority on a subsequent course of action.

ATS.OR.205 Safety assessment and assurance of changes to the functional system

(a) An ATS provider providing air traffic services shall:

(1) ensure that a safety assessment is carried out; and

(2) provide assurance, with sufficient confidence, via a complete, documented and valid

argument that the safety criteria are valid, will be satisfied and will remain satisfied

for any change they have notified in accordance with ATM/ANS.OR.A.045(a)(1).

(b) An ATS provider providing air traffic services shall ensure that the safety assessment

referred to in (a) comprises:

(1) the definition of the scope of the change, which consists of:

(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; and

(iv) the life cycle of the change from definition to operations including transition into

service and planned degraded modes;

(2) identification of hazards;

(3) determination of the safety criteria applicable to the change in accordance with

ATS.OR.210;

(4) risk analysis of the effects related to the change;





(5) risk evaluation and, if required, risk mitigation for the change such that it can meet

the applicable safety criteria;

(6) verification that the change:

(i) conforms to the scope that was subject to safety assessment; and

(ii) meets the safety criteria; and

(7) the specification of the monitoring requirements necessary to demonstrate that the

service delivered by the changed functional system will continue to meet the safety

criteria.

ATS.OR.210 Safety criteria

(a) The ATS provider shall determine the safety acceptability of a change to a functional system

using specific and verifiable safety criteria, where each criterion is expressed in terms of

safety risk or other measures that relate to safety.

(b) The ATS provider shall specify the safety criteria with reference to one or more of the

following:

(1) explicit quantitative acceptable levels of safety risk or other measures related to safety

risk;

(2) recognised standards and/or codes of practice; and

(3) the safety performance of the existing system or a similar system elsewhere.

(c) The ATS provider shall ensure that the safety criteria:

(1) are justified for the specific change, taking into account the type of change; and

(2) support the improvement of safety whenever reasonably practicable.

….

SUBPART B — TECHNICAL REQUIREMENTS FOR THE PROVISION OF AIR

TRAFFIC SERVICES (ATS.TR)

Section 1 — General requirements

…


3. Proposed amendments — Draft EASA Decision



3.2. Draft Acceptable Means of Compliance and Guidance Material

(Draft EASA Decision)

The following new AMC and GM are introduced:

AMC/GM to Cover Regulation

GM2 Article 2 (2) Definitions

SERVICE PROVIDERS

The purpose of this guidance material is to show, using the functional system model described in

GM1 Annex I Definitions(35) — Functional system, and the legal basis for the definition of a

service provider, how service providers may be organised.

(a) For the purposes of safety management of changes, services18 are produced by a functional

system19. The description of that functional system and the way a change propagates

through a network of functional systems is described in GM1 Annex I Definitions(35) —

Functional system.

(b) For an aircraft (a/c) to travel safely, effectively and efficiently from its point of departure to

its destination, many ATM/ANS services are needed. The range and scope of these services

can be found in GM1 Article 2(2) Definitions.

(c) A service provider delivers ATM/ANS services using its functional system. In providing such

services it may use the services of other service providers, the services provided by other

parts of itself or the services of an unregulated body.

(d) A complete representation20 of a functional system is shown below:

Text

TextOperational(functional)

System

Rules & Procedures

Service

Organisation

Serv

ice

Text

OperationalContext

OperationalContext

Service

Regulated service

Unregulated service

OperationalContext

18 In Regulation (EC) No 549/2004, both services and functions are mentioned. However, this GM uses the notion that a

function performs a service if the results of the function are delivered to another body. Consequently, only the term ‘service’ is used here.

19 This can be thought of as the operational system as opposed to the management system. 20 The diagram is not actually complete as for any particular functional system there may be one or many services

provided to it.





(e) An individual organisation may provide one or more ATM/ANS services, e.g. an ATS provider

may use its own surveillance and communications services as well as performing local ATFM

in addition to providing separation. It is also the case that the ATS provider, while providing

surveillance services supporting the provision of separation, may also provide a surveillance

service to other service providers.

(f) A few examples21 of possible internal structures of and connections between service

providers and other bodies are shown below:

(1) A service provider delivering the same type of service22 to other service providers.

Text

Operational

Context

Service

Service

provider

Functional

SystemText

Operational

Context

ServiceService provider

BService provider

A

(2) A service provider delivering23 different types of services to other service providers.

21 These are just a few examples that illustrate the connection rules. The actual range of possible structures is probably

endless. 22 Although the type may be the same (e.g. surveillance service), the services to both users may be different, hence they

have different specifications (e.g. the data format, the information data or the technology used to gather information may be different).

23 It also receives a service from an aviation undertaking and delivers a service to an aviation undertaking.





Functional

System #1Text

Operational

Context

Service

Text

Operational

Context

Functional

System #3Text

Operational

Context

Service

Service provider A

Serviceprovider C

ServiceService

provider B

Service provider

Aviation undertaking

Text

Operational

Context

Text

Operational

Context

ServiceAviation

undertakingFunctional

System #2

Service

(3) A service provider provides different types of services24, then combines them into

another type of service and delivers it to another service provider.

Text

Operational

Context

Service

Text

Text

Operational

Context

ServiceService

provider C

Service

Functional

System #3

Functional

System #2

Functional

System #1

Service Provider A

Service provider B

Text

Operational

Context

Service

(4) A service provider combines internal services and delivers air traffic service to aircraft.

24 One of the services (that from FS#3) uses the services of an external organisation (Provider B) in order to create its

own service.





Text

Operational

Context

Navigation Service

Text

Text

Operational

Context

ATS

Surveillance Service

Surveillance

Functional

System

Navigation

Functional

System

Air Traffic

Functional

System

Service

Provider

(g) The service provider is free to choose its management structure, provided it can show,

during certification, that its management system complies with this Regulation. It is only

the management system and the ATM/ANS services it delivers that are certified.

Consequently, a certificate should indicate, amongst other things, the ATM/ANS services

provided by the organisation or person and the scope of those services, as the service

provider may only provide partial services.

(h) An organisation may deliver services other than ATM/ANS services. In these cases, the

internal structure does matter. Certification against Annex Vb(2) to Regulation (EC)

No 216/2008 can only relate to those parts of the organisation that deliver ATM/ANS

services, of which there may be more than one in an organisation and these may function

independently of each other. Consequently, these parts should be identified by the

organisation and separated in such a way that they can be managed independently of the

other non-ATM/ANS parts of the organisation. A general structure for such organisations is

shown below:





Operational

System

Management

System

Organisation

Service

provider

Entity not regulated by EASA

Serv

ices

Overall Management

SystemS

erv

ice

s

Services

ServicesServices

Serv

ices

Management

System

Operational

System

Operational

System

Functional

System

Functional

System

Regulated services

Unregulated services

Services regulated in one direction but not in the other or services that are regulated by different parts of the regulation

Management

System

Entity regulated by EASA other than a service provider

Operational

System

(i) It should be noted that if the organisation chooses to have several management systems,

they need to be coordinated by the overall management system. The relationship between

this overall management system and the management systems of the service providers

should be such that it can be shown that the service providers’ management systems

comply with the applicable regulations stemming from Regulation (EC)

No 216/2008.

(j) In an organisation that also delivers other services apart from ATM/ANS services, there still

may be some services that are delivered by non-ATM/ANS parts of the organisation to

service providers and vice versa. In these cases, the services delivered by the non-service

providers to the ATM/ANS parts of the organisation are out of the scope of Annex Vb(2) to

Regulation (EC) No 216/2008, whereas the services delivered by the service provider to

non-ATM/ANS parts of the organisation do fall within the scope of Annex Vb(2) to

Regulation No (EC) 216/2008. Clearly, services interchanged by service providers and other

non-ATM/ANS parts of the organisation that fall within the scope of Regulation (EC)

216/2008 (shown on the diagram as an ‘entity other than a service provider regulated by

EASA’) have to comply with that Regulation.





AMC/GM to ANNEX I — Definitions of terms used in ANNEXES II to XIII

GM1 Annex I Definitions(35)

FUNCTIONAL SYSTEM

(a) The following definitions are related to a functional system:

(1) ‘Equipment’ is an assembly of the framework for locating hardware, the hardware

itself and possibly a cover to act as a barrier between the internal and external

environments.

(2) ‘Hardware’ is the physical constituents within the equipment or the means of

connecting them. All of them are used to provide the behaviour of the equipment.

(3) A ‘computer’ is a hardware constituent that provides the operational environment for

the software and contains the software itself.

(4) ‘Software’ is a constituent part of a computer25, which is used to provide the behaviour

emerging from that computer. Software includes computer programs and

configuration data. Software is not hardware, but is contained in hardware. Neither

can ‘behave’ on their own, but only when acting cooperatively, i.e. the hardware

supports and enables the operation implied by the software — the behaviour .

(5) ‘Computer programmes’ are sequences of instructions written to perform specified

tasks within a computer.

(6) ‘Context’ is the interactions and the circumstances, which includes the surroundings,

environment, background and setting, that determine, specify or clarify the meaning

of an event or other occurrence. It is intended to be a wider concept than that implied

by environment, which may be taken to mean just the physical environment.

These definitions are depicted in the figure below showing graphically the relationship of the

elements of a functional system

25 It demonstrates that while hardware can be verified in isolation, software cannot.





FunctionalSystem

a combination of equipment, procedures and human resources organised to perform a function within the context of ATM/ANS

Equipment

Procedures

Human Resources

Architecture

ATM/ANS Function

an assembly of the framework for locating hardware, the hardware itself and possibly a cover to act as a barrier between the internal and external environments

Framework

Cover

Hardware

Locates the hardware

the physical constituents within the equipment or the means of connecting them. All of which are used to provide the behaviour of the equipment

Connections

Computer

a hardware constituent that provides the operational environment for the software and contains the software itself

Software

a constituent part of a computer, which is used to provide the behaviour emerging from that computer. Software includes computer programs and configuration data

PhysicalConstituents

Acts as a barrier between the internal and external environments

‘Organised’ - the form and function of the connections between the components

Element of an ATM/ANS functional system





(b) Hardware and software are not used in the regulation because it is written in terms of the

behaviour of the equipment and not of the physical attributes of its constituent parts

(framework, hardware, cover). However, a rule that sets criteria for the behaviour of

equipment applies to that part, or those parts of the equipment involved in producing the

behaviour e.g. a criterion that is applicable to a service delivered by a piece of equipment

would, if provided by a computer, apply equally to the operation of the software within

the computational environment. Consequently, the requirements for the assurance of

safety and safety support, when relevant to the behaviour of a computer, are

requirements for the assurance of the software within the computational environment

because that software together with the computational environment determines how the

service delivered by the computer behaves.

(c) When a requirement concerns equipment, then that requirement applies to all the

constituent parts of the equipment i.e. the framework, the hardware (including its

contained software) that are within the scope of the requirement.

GM2 Annex I Definitions(35)

FUNCTIONAL SYSTEM

(a) The purpose of this guidance material is to provide a reference model that describes the

structure of the functional system, the relationships between it and the context in which

it is used, and the way change propagates throughout the wider system.

(b) Where reference is made to the functional system, the model described here may be

used as the basis for understanding how the provisions of this regulation should be

applied.

(c) An ATM/ANS functional system comprises its components (people, procedures and

equipment (hardware (HW) and software (SW)) and the way they are organised (the

architecture — the form and function of the connections between the components). The

functionality and performance26 of the functional system depends on the transfer

functions of the components and the relationships between the components.

(d) An ATM/ANS service will normally be used in another system; for example, the service

delivered by an ATS provider is used in the air transport system by the a/c. The way the

part of the air transport system shown in Figure 1 (labelled ‘System’) behaves27 depends

upon the interactions of the outputs delivered by the functional systems28 (their service,

i.e. their functionality and performance) and the physical environment in which it is

delivered.

(e) The context in which the system operates can be thought of as consisting of two parts:

(1) the environment in which the functional system operates (functional system context

(FS context)) e.g. the ‘people’ environment in the control tower and the local

equipment environment; and

(2) the context in which services operate (operational context), which can be thought

of as the physical environment, e.g. the topology enclosed by the serviced airspace,

26 Usually the performance comprises the constraints on the functionality e.g. accuracy, timeliness, reliability, which

are imposed on the functional system by the choice of components and the context in which they operate. 27 The way a system behaves is an emergent property of that system. it is not a property of any particular

component, but of the system as a whole. Similarly, safety is an emergent property of a system and cannot be said to be a property belonging to any individual component.

28 Which depend upon the inputs provided to the functional system from the environment or from services delivered to the functional system.





the volume of serviced traffic, other traffic, the dimensions and structure of the

airspace and weather, and the context provided by all the services being delivered

in the same airspace.

(f) In addition, the service provider may use services, provided by another service provider

or some other unregulated service provider, in generating the service provided by its

functional system. For example, the service delivered by a communication service

provider will normally be used by an ATS provider in its functional system as part of an

air traffic service29.Some of these other service providers are within the scope of EASA

Basic Regulation e.g. an aerodrome, while others are not e.g. an electrical power

supplier. A complete representation30 of the system in which services are provided and in

which they may be created is shown in Figure 1.

Service

(S3)

Text

Operational(functional)

System

Rules & Procedures

Service (S2)

Service Provider

Serv

ice

Text

OperationalContext

OperationalContext

Service

Regulated service

Unregulated service

OperationalContext

FS Context

The System


System

Rules & Procedures

Service Provider

Figure 1: The functional system model

29 While the information may be provided by the communication service provider directly to an a/c, the service is

usually provided as part of air traffic service, which is the responsibility of an ATS provider, and so in this model the communications service provider is said to be providing a service to the ATS provider — for more information

on the reasons for this interpretation see GM1 Annex I Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General.

30 The diagram provides a graphical representation but it is not actually complete, as for any particular functional system there may be one or many services provided to it by one or many other organisations or unregulated bodies.





(g) In order to examine how change31 is propagated i.e. how change in any part of the

system32 can affect the way the system behaves, a modification to Figure 1 that will

simplify the analysis, is shown in Figure 2 below.

TextFunctional

SystemFS

Service - S2Text

OperationalContext

OC1

OperationalContext

OC2

Service - S1 A B

FS ContextFC2

Figure 2: Simplified functional system model

(h) The way the service delivered to the functional system (FS) at point A behaves is a

function of the properties of the service33,34 delivered (S1) and the operational context

(OC1) in which it is delivered. Similarly, the way the system behaves at point B is a

function of the service (S2) delivered by the functional system (FS) and its operational

context (OC2).

(i) In Figure 1, two services are shown being delivered directly to a single a/c. The way the

system behaves in these circumstances is, therefore, the conjunction of the two services

within a single physical operational context. If the way one of the services behaves needs

to be analysed e.g. when a change is proposed, then the simplification of Figure 2 may

still be used, but with the additional constraint that the operational context (OC2) must

now include the contextual impact of the other service. Consequently, in this case, the

operational context (OC2) is a function of the physical environment (the topology

enclosed by the serviced airspace, the volume of serviced traffic, other traffic, the

dimensions and structure of the airspace, and weather) and the effects on the physical

operational context due to the output of the other functional system, the service (S3).

(j) The output of the functional system, the service (S2), depends upon the set of laws35

governing the relationships between the inputs to the functional system and its outputs,

the value of the inputs and the environment in which the functional system operates (FS

Context: FC2). These laws are dependent on the components of the functional system

and its architecture i.e. they are a function of the people, procedures, equipment and

architecture of the functional system. Similarly, since at least some of the inputs come

from the service delivered to the functional system (S1), then the output of the

functional system (S2) is also dependent on the way (S1) behaves at point A.

31 Note that in this Regulation, the word ‘change’ is used to describe changes to the functional system or to the

context in which it operates (operational context) of an ATM/ANS provider. 32 When ‘system’ is used in this guidance it means the functional systems of the service providers (A & B), the

services delivered to A by any unregulated bodies and the context in which the whole operates (FC1, OC1, FC2, OC2). This model is intended to be valid for any system no matter how large or small.

33 If this service was produced by another service provider, then it was produced by another functional system. 34 This could be one or many services. 35 The term ‘laws’ is used here in its normal mathematical sense, and does not imply anything of a legal nature.





(k) Consequently, should:

(1) the service delivered to the provider (S1) change,

(2) the operational context (OC1) in which the service (S1) is delivered change,

(3) any part of the functional system change,

(4) the environment in which the functional system operates (FC2) change,

(5) or the environment in which the system operates (OC2) change36,

then the way the system behaves is likely to change.

(l) In some cases, the change will be initiated by someone other than the service provider37

and may also be undesired e.g. a change to the operational context initiated by some

other body. In this case, other parts of the functional system may be changed38 in order

to compensate for the different way the system would behave as a result. For example, if

the operational context changes and we wish to keep the system behaving as it did

before (the current performance), then one or more components of the functional system

or its architecture needs (need) to be changed.

(m) Even if a change, initiated by someone other than the service provider, does alter the

way the system behaves, the change may still be acceptable to the user. Consequently,

there is a need to distinguish between a change that has an acceptable impact on the

way the system behaves and one that does not.

(n) Equally, a change may be made to a service (S1) used by the service provider that does

not impact the service it delivers at all. This will be true when there is no relationship

between the service used by the provider (S1)39 and the service delivered by the

provider (S2) e.g. altering the range or type of data in a message field that is not used

by the functional system40.

GM1 Annex I Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General


(a) This guidance material explains the difference in responsibilities for safety between an

ATS provider and other types of service providers. It also describes the rationale behind

the differences in the type of assessment each has to make i.e. safety assessments are

required from ATS providers while safety support assessments are required from other

service providers.

(b) In some circumstances, services provided directly to an a/c are provided by a service

provider, other than an ATS provider, e.g. a navigation service. It has been argued that

this makes the provider responsible for safety and would necessitate the production of a

safety case for the service being delivered, rather than the safety support case required

36 Including a change to S3. 37 Or be a change to the operational context initiated by the ATM/ANS provider e.g. a desire to increase traffic

throughput. 38 This is a responsive change i.e. the functional system is changed in order to respond to (back off) a change by

someone else. The change could also be part of a cooperative multi actor change, where the ATM/ANS provider changes the functional system not only because the context of operation has changed, but also because the provider is seeking to change the context of operation.

39 This is not the only possibility. For example, it would also be true if the functional system delivering a service to the ATM/ANS provider is changed, but neither the service (S1) nor its operational context (OC1) is changed.

40 This may be an oversimplification. The way the system behaves under faulty conditions might be altered because of the range change. Also, any data checking performed by the provider using the changed service, may be affected by the range change.





by the IR. This general guidance material explains why this is not the case by comparing

the responsibilities and capabilities of a navigational service provider with those of an

ATS provider. It then goes on to show why this example is generally applicable to all

service providers other than ATS providers.

(c) The diagram below illustrates a common scenario: A signal is provided in a manner that

cannot easily be restricted to a particular volume of airspace and so there can be many

users and these users may be unknown to the signal provider. The signal provides

information that can be used for navigational purposes. Clearly accurate information,

which is consistently available, is necessary for safety. However, accurate navigation and

avoidance of other a/c and obstacles do not rely solely on the signal providing the

navigational information. Consequently, even if the signal provider did know who was

using the navigational information and could prevent unauthorised use, it would still not

be able to say that all users would use the information safely. Furthermore, it certainly

could not in any way assure that all a/c using the information would be safe. As a

consequence, the signal provider could not write a safety case, however, it could write a

safety support case. This is because be the safety support case demonstrates41 that the

signal in space meets its specification42 and that the specification (and the context in

which it is valid) is available to all users.

(d) The provision of this signal in space, transmitting navigational information, is usually

called a navigational service. To call the provision of the signal in space a service seems

rational as there is a system (the functional system) involved in encoding navigational

information and transmitting it. The information is transferred from one entity to another

and so the information transfer falls within the broad definition of a service. Even if the

definition of a service is restricted so that it also requires some contract governing both

the provision and the receipt of the signal to exist, then the transfer of navigational

information described could still be considered a service. This is because it can be argued

that such a contract exists. The provider makes the availability of the signal known to

those it believes will wish to use the service. In doing so, the provider will probably

indicate the range of uses foreseen, the availability of the signal and any constraints

users should bear in mind. This would normally be seen as one half of the contract. The

other half involves the user, who would be deemed to have accepted the conditions

under which the service is offered, simply by using it.

(e) There is a difference between the navigation service used by a/c in uncontrolled airspace

(airspace classes F and G) and the use of this navigation service within the context of the

provision of an ATS43. In both cases, the navigation service provider has only a limited

knowledge of who is the end user of the service, where they are using it, what they are

using it for and what other services are being provided to the user at the same time. In

both cases, the navigation service provider is neither responsible for how the service is

used nor the separation of a/c that may be using the service.

41 This should not be taken to mean that producing a safety support case is in any way inferior to producing a safety

case. Nor should it be taken to mean that there should be any lower degree of confidence needed in a safety support case that that needed in a safety case. Demonstrating that something behaves only in accordance with its specification can be extremely challenging, but is nonetheless required.

42 And that the specification is complete i.e. it does nothing else. 43 Strictly this relates to the provision of an ATCS, however it is sometimes the case that information oriented

services are treated as control services by pilots, simply because the ATS provider has a more complete picture of the airspace and its users. The ATS service being provided will depend on the airspace classes. Therefore, the scenario described below is a general one without going into the details of the services being provided to IFR or VFR traffic in each airspace class.





(f) The difference is in the use of the service. The ATS provider may be responsible for

separating a/c, depending on the airspace class, in receipt of its services within a defined

airspace and ‘uses’ the navigational service within that context. Other air transport users

are simply responsible for using the service in order to navigate their own a/c. This

difference is not the responsibility of the navigation service provider, even though there

may be different charging schemes for different uses.

(g) The ATS provider knows what any particular a/c is using the navigation service for

(because it is directing its use) and what other services are being provided to the a/c. In

airspace class A, B, C, and to a lesser extent class D and E airspaces, the ATS provider

also knows the location and intent of other a/c in the vicinity44. This allows the ATS

provider to form a safe navigational plan for the a/c45 receiving its service (for a more

detailed explanation of the service provided by an ATS provider see GM2 Annex 1

Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205). Even though the pilot can take

independent action and so it can be said that the ATS provider is not in total control of

the situation, the ATS provider is obliged to attempt to keep all a/c in the airspace under

its control separated46. This is done by requiring one or more other a/c to alter their

trajectories. Consequently, the ATS provider does have a view of what it takes to make

the airspace safe for all users and is coordinating the use of all the services, whether the

information delivered by these services is delivered directly to the service provider, or

directly to the a/c or generally available within the airspace47. Certainly, the pilot does

not have such a view and neither do the other service providers. Consequently, the ATS

provider, due to its ability to coordinate all the services and its responsibility for the

separation of some a/c, can produce a safety case even though there are circumstances,

within the airspace it controls but not within its control, that could lead to an accident.

(h) This then begs the question of who is the user of the navigational service. In the case of

the pilot who uses navigational information without receiving an ATS, then clearly the

user is the pilot. However, in the case where a pilot is using the navigation information as

part of an ATS, then it is less clear. Certainly, in both cases the pilot receives the same

information. However, in the latter case it is only a part of the information he receives

and, indeed, where it is the only navigational information he received, it would not allow

him to participate in the ATS being provided48. So it is probably more useful to think of

the relationship as follows: the ATS provider is using its knowledge of the navigational

service provided to the a/c and other information available to him, in creating and

communicating its own navigational plan for the whole airspace. Consequently, in this

view of the world, it is the ATS provider who can be said to ‘use’ the service, the pilot

merely receives the information. Another way of describing the situation is that the pilot

receives the information as part of a much broader service i.e. that of separation. The

diagram below illustrates this difference.

(i) Summarising the above, the provider of a service may not ‘control’ the use of the service

and, therefore, will not be able to judge whether it will be used safely. This has been

44 In class E, F and G airspaces, the ATS provider may know the location of most, if not all, a/c (depending on the

effectiveness of his surveillance techniques) and may also be the one best placed to make assumptions about the intent of the a/c. So to a lesser extent the argument also holds for service provision in these classes of airspace.

45 In doing so, he may need to make assumptions about the plans of some users; however, these assumptions will be based on standard practices.

46 And by doing so the airspace remains safe. 47 ‘Information generally available within the airspace’ is used here in a very broad way – it includes maps, AIP, etc. 48 Because, in this case, he would only know where he was not, where the air traffic control service wanted him or

was expecting him to go.





argued for the case of a navigation service provider. It is equally true for all service

providers. However, while an ATS provider cannot be said to have absolute control over

the use of any service directly supplied to an a/c, those services are provided within the

framework of a navigational plan (a plan controlling separation) for all a/c receiving an

ATS. Within that plan, the ATS provider has to be aware and take care of the fact that

the initial plan may not be adhered to and so will have to modify the plan in order that all

a/c remain safe. Consequently, it is only the ATS provider that can perform a safety

assessment and provide a safety case. All other service providers can only perform safety

support assessments and provide safety support cases.





Used by

Separation ServiceATSPN

avig

atio

n S

ervi

ce

Navigation Service

Services, Information and Responsibility

for Safety(for controlled and uncontrolled flight)

Controlled flightUncontrolled flight

Safety

Case

Safety

Support

Case

The Service is delivered into

an airspace. It may not be

delivered to a particular user

The service is accessed and

used by a particular a/c without

the knowledge of the service

provider

Individual a/c that are not receiving an ATCS may also use the service in controlled

airspace. The Nav service provider still would not be able to control who they are and

may not know who they are. The service provider will not know how a particular a/c will

use the service and cannot control the provision of other services to the same aircraft..

While the service provider may attempt to write a generic safety case, It is unlikely that it

would have any direct relevance to the system since each a/c can be using many or few

services at the same time and can be equipped to vastly different levels.

Note: If the service delivered to an

a/c not using an ATCS is different to

that delivered to a/c receiving an

ATCS, then there would need to be

two safety support cases, one for

each service. However there may

be many common elements in each

case

The service is accessed and

used by a conforming a/c as

part of an ATS

Sevice Provider

Navigation






AIR TRAFFIC SERVICE — VIEW OF SAFETY

(a) Air traffic information/data is created or used by the air traffic controller in order to

derive a safe, effective and efficient plan, which takes all of the circumstances of the

service into account e.g. the regulatory environment as well as the physical environment;

and to provide instructions to the a/c. Primarily this data is surveillance data (so that the

air traffic controller knows where all a/c), communications data (so that the air traffic

controller can establish the intent of the a/c and issue instructions to them), and

navigational data (so that the instructions can relate global reference points, that all are

aware of, to the local position of the a/c). This data is dynamic — it changes due to the

circumstances prevailing within the airspace at the time. Other semi-static and static

data is used. For instance, the design of the airspace, the rules of the air and other

regulations are static data. These are rather like navigational data in that everyone is

aware of them and, therefore, instructions can refer to them rather than spelling out

every individual detail. The data relating to the local management of air traffic flow in the

airspace is semi-static and so is the range of airspace configurations. This semi static

data provides the air traffic controller with information about the long-term plans of a/c

entering the airspace and the options available to the air traffic controller for the local

management of the airspace.

(b) The instructions, provided by the air traffic controller, are intended to ensure that all the

a/c within the airspace, in which the ATS is provided, perform safe, effective and efficient

manoeuvres i.e. they all implement the plan that the air traffic controller has derived.

(c) The safety of each a/c depends on the plan49 being safe and the instructions being

carried out correctly.

(d) Clearly, an a/c may manoeuvre in a manner not planned and unforeseen by the air traffic

controller, whether by the direct command of the pilot, an incorrect instruction by the air

traffic controller or via some flaw in the controllability of the a/c or in the plan itself.

Equally, a/c may enter the airspace, even though they have not informed the air traffic

controller and so are not part of the plan. If the air traffic controller were powerless to do

anything, an accident might result and all the air traffic controller could do is observe it

happening. However, this is not the case. It is expected that the air traffic controller will

‘see’ all the a/c and sense if they are not conforming to the plan. The air traffic controller

is then expected to re-formulate the plan and issue corrective instructions to one or more

of the a/c receiving the control service in the airspace.

(e) It is this observe, re-plan, instruct cycle that ensures safety, not the individual services

offered by the CNS providers or the static or semi-static data. Both the plan and the

instructions are created and maintained in the mind of the air traffic controller and this is

the primary reason why it is the air traffic controller that is responsible for assessing and

assuring50 the safety of the Air Traffic Service he is providing.

(f) Other service providers, i.e. Surveillance, Communications, Navigation, MET, ATFM, AIS,

DAT and ASM service providers, enable the air traffic controller’s plans to be formulated

and implemented. In the airspace where ATS is provided, the only impact they have on

safety is that they perform in a manner anticipated by the ATS provider e.g. they behave

49 Which includes assumptions made by the ATCO about uncontrolled a/c. 50 Assessing and assuring the safety of the ATS does not make the ATS provider responsible for the safety of the

airspace users or third parties.





as is required by their contract51 with the ATS provider even though that contract may be

abstract, as in the case of satellite navigation services.

(g) Consequently, these service providers are not responsible for the safety of the ATS, but

are responsible for the ‘trustworthiness’ of the services they provide to the ATS provider.

A diagrammatic representation of the relationship between these service providers is

given below.

51 Note that loss of information and all forms of corruption of information is expected to form part of the contracted

service definition.





Air Traffic

Service Provider

Surveilance

Service Provider

Communications

Service Provider

Air Traffic

Service

Transmission

Service Provider

(unregulated)

Transmission

Service Provider(unreglated)

Navigation

Service

Provider

MET Service

Provider

Managed Airspace

‘Organisations’ possibly "outside the

managerial control" of the the ATSP

Note:Transmission

Service Providers are

not ‘Organisations’.

Notes:

1) Service providers use

sytems to deliver services.

2) Some Systems are owned/

manged by the service

provider

3) Service providers also use

services provided by sytems

owned/managed by other

service providers.

AirSpace

(Route/Sector)

Design

Air Traffic Flow

Management

Static or semi-static service

Dynamic service

ILS

Air Traffic

Service

Information/data

Note: The ILS may be owned by the airport

AirSpace

(Approach/

Departure)

Design






ATS.OR.205 General


(a) The purpose of this guidance material is to describe the circumstances that may result in

a need to change the functional system and to describe the relationship between the

nature of the change and its cause. Furthermore, this guidance gives a general

description of the assessment of changes.

(b) The nature of change.

Changes proposed within the ATM/ANS environment come in two forms:

(1) The service provider e.g. service provider B52, wishes:

(i) to change its functional system; or

(ii) to propose a change to the context in which its own services are delivered

e.g. airspace structure change, increase in traffic.

(2) Somebody else wishes to modify something that may or may not require a

responsive change to service provider B’s functional system, i.e.:

(i) Another service provider e.g. service provider A, proposes a change to a

service53 delivered to, and used by service provider B, e.g. a communication

service provider that delivers communication services to an ATS provider.

(ii) An organisation that is not regulated by EASA54 but which delivers services to

service provider B, proposes a change to one or more of these services, e.g.

an electrical power supplier that provides electricity to a surveillance provider.

(iii) An external entity not regulated by EASA and not a service provider e.g. a

government agency, proposes a change to the context in which the services

delivered by the service provider B’s functional system operate55, e.g. the

State decides to change the airspace structure.

(c) These changes may be due to foreseeable trends and technological or economic

developments. This includes changes such as installation of new equipment, modification

of software, introduction of new services, reduction of separation minima, airspace

reclassification or redesign, introduction of new flight procedures, redesign of sectors,

reorganisation of the ATS route structure, design of new runway configurations, physical

changes to the layout of the runways and taxiways and changes to operational

procedures.

(d) Planned changes.

ATM/ANS.OR.A.045 (a) states that planned changes to a service provider’s functional

system need to be notified to their CA. They are called ‘planned changes’ because at the

point they are ‘notified’ they have not been implemented. Indeed, ATM/ANS.OR.A.045 (c)

52 Here ‘service provider B’ means the provider delivering Service B as described in GM1 Annex I Definitions (35).

Similarly for service provider A. 53 Or a change to its context of operation. 54 Namely, not within the scope of the EASA Basic Regulation (Regulation (EC) No 216/2008). 55 Changes in the operational environment, whether instigated by the service provider or not, may potentially impact

the way services delivered by the service provider behave. If they do, the functional system will need to be changed in response to the ‘externally induced alteration’ in order to ‘back off’ any risk introduced by the way the altered environment will behave after the change. Such changes are called environmentally-driven changes.





does not allow the transition from a proposal to an implementation until an assessment

has been conducted and an assurance case56 exists that shows that the proposed change

will be acceptable57. Where the CA decides to review the safety case, the proposed

change cannot be implemented until the assurance case has been approved58. Thus, at

the time they are approved, changes to functional systems are planned changes rather

than implemented changes.

(e) ATM/ANS.OR.A.045(a)(3) requires that a service provider, whose ATM/ANS services are

used by another service provider e.g. a communication provider providing services to an

ATS provider, informs the user59 if it proposes to make a change to its functional system.

This acts as a driver for the user of its service to assess the impact of the change on the

services the user provides. As a result, the user may need to change its own functional

system.

(f) Drivers for changes.

The following are some examples of reasons that may result in a need for the service

provider to make changes to the functional system:

(1) Business-driven change — Improvements in:

(i) Working conditions/working environment;

(ii) ‘Profitability’;

(iii) Effectiveness;

(iv) Efficiency.

(2) Environmentally-driven change:

(i) Market share/growth;

(ii) Change in airspace use;

(iii) Introduction of environmental features e.g. wind farms;

(iv) Regulatory-driven changes.

(3) Management System (MS)-driven change:

(i) Reverse a deficiency that affects safety/trustworthiness60;

(ii) Reverse a degradation in safety/trustworthiness;

(iii) Improve safety/trustworthiness, i.e. reduce the safety risk as low as is

reasonably practicable or improve trustworthiness.

Any resulting changes to the functional system require a safety (support) assessment.

(g) Examples of changes that may or may not need assessment.

56 ‘Assurance case’ is used here to describe either a safety case or a safety support case. For a full definition of them,

see GM1 ATM/ANS.OR.C.005(a)(2) & ATS.OR.205(a)(2) General. 57 Some notified changes may be withdrawn by the service provider. Clearly, in such cases the assessment will not be

completed and the assurance case will not be needed. It is unlikely that the competent authority will wish to review any incomplete data or arguments in such cases.

58 Approval of a safety case may involve competent authority review of one or more safety support cases. 59 User here refers to another service provider or an aviation undertaking. 60 Safety impact applies to ATS providers. The impact on trustworthiness, which is a measure of the confidence one

has in the correctness and completeness of the specification of the service, applies to all other service providers.





Table 1 contains some examples of changes that may require safety assessment and

Table 2 contains examples of changes that may require safety support assessment . They

show which parts of the functional system may be changed. Table 3 contains some

examples of changes that may not require safety (support) assessment.

(h) Tactical changes.

In the case of tactical changes, an assessment does not need to be carried out provided

that they are inside the normal operational envelope and foreseen within the operating

procedures included in the operations manual. These tactical changes include

circumstances associated with day-to-day operations that result in alternatives61, e.g.

combining and splitting sectors, a change in runway configuration, the use of a different

procedure to accommodate changing weather conditions or traffic patterns, activation of

restricted airspace area, closures of an area due to search and rescue activities,

procedures due to the presence of intruders, temporary closure of an aerodrome,

procedures to handle special flights, change of summer/winter hour.

(i) Maintenance activities.

In the case of maintenance activities, where components are changed on a like-for-like

basis, e.g. the replacement of a piece of hardware by another one with an identical part

number (sometimes called a Line Replacement Unit (LRU)), an assessment does not need

to be carried out provided that the maintenance activity has been foreseen and is

covered by a maintenance procedure. A safety (support) assessment might need to be

carried out if the maintenance activity leads to a or discontinuity of the service.

(j) Changes described in (h) and (i) need to be covered in an assurance case, e.g. there

needs to be an assurance case for the development of the operational procedures

covering the tactical changes and maintenance activities. If these tactical changes or

maintenance activities are new and arise because of the planned change, then they will

need to be assured as part of the assurance case developed for the planned change.

However, if they were in existence prior to the planned change, then they may have

been assured in earlier assurance cases. However, it is possible that they have been in

existence for a considerable time and as a result may have been accepted by the CA via

another form of oversight. In this case, no assurance case will exist.

(k) Unplanned/unforeseen changes due to unforeseen urgent circumstances.

There may be a need for unplanned changes to the functional system due to unforeseen

circumstances, e.g. a system malfunction outside the contingency plan, volcanic ash or

any other natural disasters affecting aviation in an unforeseen manner. In order to

manage the risk introduced by these unforeseen circumstances, changes will need to be

made to one or more functional systems. Such changes will be managed, by a Member

State, through the application of Article 14(1) of the EASA Basic Regulation and will be

dealt with outside the scope of this provision.

61 While these alternatives can include large variations in operation that may last for long periods of time, they are

only considered to be changes if they have not been previously approved.





(l) Assessing the impact of a change.

Identifying whether a change, proposed by the service provider itself or by someone

other than the service provider, requires a responsive change to the service provider’s

functional system, relies on a process for deciding whether the proposed change will, in

the case of an ATS provider, have: no effect; an acceptable effect or an unacceptable

effect on the safety of the service delivered by the service provider. In the case of a

service provider other than an ATS provider, the process needs to decide whether the

proposed change will have: no effect; an acceptable effect or an unacceptable effect on

the behaviour of the service as currently specified. The process uses many of the

techniques and criteria associated with safety assessment and safety support assessment

(and assurance). Moreover, the nature of the change will determine how easy it is to

satisfy those criteria.

(m) The process described below, together with the examples of changes that show different

paths through the process and different levels of difficulty, is for guidance purposes only.

It is not intended to be a representation of any particular process. It is only complete

insofar as it explains the differences in assessing whether a responsive change is

necessary and the assessment needed if the service provider decides to make a change

to its functional system. The process is illustrated in Figure 1. The process is very similar

for an ATS provider and a service provider other than an ATS provider, except that

questions and actions associated with safety risk are replaced by questions and actions

associated with the specification of the service and the specification of the context over

which the specification is valid.





Environmental Change proposed by an external

agency

Environmental Change proposed by the organisation (B)

Would the proposedChange alter the way the service

delivered by Serviceprovider B behaves?

Store impact analysis

No

+

Yes

Notify CA(Or update information each

time ‘round the loop’)ATM/ANS.OR.A.045

Add to changeProposed last

time

Safety Assessment

Service provider B

ATS.OR.205

Change proposed by another organisation

e.g. Service provider A

Change proposed by an unregulated body

Scope of changeSafety Criteria

Risk AssessmentRisk Evaluation

Does theproposed change

pose an unacceptable level of

risk?

Propose a change to the FS to mitigate the

risk

Yes

Change VerificationChange Assurance

Store Assurance case(or present to CA)

ATM/ANS.OR.A.045(c) & (d)

No

Would the proposed changehave an unacceptable impact on the way the service delivered by

Service provider Bbehaves?

No

Impact analysis – Paragraphs (l) to (t)

Safety Support Assessment

ATM/ANS.OR.C.005

Scope of changeDecide on specification

Does theproposed change

meet all regulations & can it be

implemented?

Change VerificationChange Assurance

Yes

ATS ProviderFollows this

path

Other service providers follow

this path

Yes

NoModify the proposed

change to the FS

Change to the Functional System (FS) proposed by Service provider

B

The process used for the change

depends on whether Service

provider B is an ATS provider or not

Figure 1: The assessment of change





(n) The first thing that needs to be done is to establish whether the way Service B (provided

by service provider B) behaves is in any way dependent on the proposed change. This

can be as simple as reading the change description and immediately coming to the

conclusion that there is no impact on safety or the specification of the service.

Alternatively, it can be as complicated as having to do a full scope analysis on a sizeable

part of service providers B’s functional system. The need to do an interdependency

analysis is stated in ATM/ANS.OR.A.045(e)(1) and (3).

(o) At this stage, a scope analysis is needed, i.e. service provider B needs to identify all the

parts of its functional system that may be affected by the change62.

(p) If the scope analysis determines that there are no interactions between the proposed

change and the functional system, then the answer to the question: ‘Would the proposed

change alter the way the service delivered by service provider B behaves?’ is ‘no’, and

the service provider simply stores the impact analysis63. Clearly, the impact analysis

needs to be fit for purpose64 (of acceptable quality and with a valid argument).

Consequently, depending on the difficulty of identifying dependencies, the analysis can

be from a few lines to many pages.

(q) However, if the analysis determines that there is some interaction between the proposed

change and the functional system or its context of operation and, consequently, there

may be some impact on service provider B’s service, then the level of impact needs to be

established65. In order to do this, there is a need to establish:

(1) what ‘hazards’ are affected (or whether new ones will be introduced);

(2) what level of ‘risk’ these changes to the hazards represent; and

(3) whether this level of ‘risk’ is acceptable without changing the functional system

For an ATS provider, ‘hazards’ and ‘risks’ are safety hazards and safety risks. For a

service provider other than an ATS provider, ‘hazards’ and ‘risks’ are not safety hazards

or safety risks. Instead, they will be hazards that might cause the service to behave

differently to that which is currently specified and the risks of so doing.

(r) If the level of impact is determined as being acceptable, then the answer to the question:

‘Would the proposed change66 have an unacceptable impact on the way the service

delivered by service provider B behaves?’ is ‘no’, and the analysis stops here. The

62 Such a scope analysis needs to identify:

(1) interfaces and interactions between the elements being changed and the functional system; and

(2) interfaces and interactions between the elements being changed and the environment in which it is intended to operate.

This analysis uses similar techniques to those responding to ATS.OR.205(b)(1) or ATM/ANS.OR.C.005(b)(1). 63 If the impact analysis does not lead to a responsive change, then the competent authority may wish to review the

results of the impact analysis during periodic oversight. 64 The purpose here is that of communicating the findings to someone else, e.g. a competent authority, so that their

adequacy may be assessed. 65 Such determination uses similar techniques to those responding to ATS.OR.205(b)(1) or ATM/ANS.OR.C.005(b)(1)

e.g. for an ATS provider:

(1) identification of hazards;

(3) determination of the safety criteria applicable to the change;

(4) risk analysis in relation to the harmful effects or improvements in safety related to the change; and

(5) risk evaluation. 66 Note that here we are still dealing not with a proposed change to the functional system, but with some other

proposed change. This other proposed change may or may not require notification to the CA.





analysis is stored67. Again, it can be quick and simple or long and difficult; it all depends

on the nature of the change. The analysis must be of acceptable quality and the argument

valid. The stored analysis is effectively an assurance case.

(s) What if the answer to the question is: ‘yes’. In these circumstances, service provider B

must propose a change68. The minimum change is simply to do the minimum necessary

to mitigate the risk — the service provider could do more, if it so desired. In this case,

there is an identified change to the service provider’s functional system, so the CA must

be notified and the requirements for safety assessment or safety support assessment

apply.

(t) If a change to the functional system is proposed, then not only does all the analysis have

to be performed on that change (which implies taking the service specification and

context specification from the service provider making the change into account, if this

was the source of the original change), but verification of the implementation has to be

performed as required in ATM/ANS.OR.C.005 and ATS.OR.205.

(u) Once this has been completed (successfully), the safety case (as specified in

ATS.OR.205) or safety support case (as specified in ATM/ANS.OR.C.005) can be stored

and, if required, delivered to the CA.

(v) In the case of an ATS provider, it is possible that, initially, the proposed change does not

adequately mitigate the risks, i.e. the answer to the question: ‘Does the proposed change

pose an unacceptable level of risk?’ is ‘yes’. In this case, a proposal to mitigate the

additional risk is made, i.e. an additional change is proposed69 and is added to the

previous proposal. The CA is informed of any changes to the material it has already

received as part of the process used to determine whether it wishes to review the change

or not and the safety assessment process starts again from the beginning70. Whether it

can deal simply with the differences or it means a considerable re-work of the material

developed so far, depends upon why the first change did not mitigate the risk — as it

was intended to do.

(w) Similarly, it is possible that, for a service provider other than an ATS provider, the

proposed change does not mitigate the risks, i.e. the answer to the question: ‘Does the

proposed change meet all regulations and can it be implemented?’ is ‘no’. Mitigation

would take the form of either modifying the proposed change to the functional system so

that it better matches service provider B’s intent or changing the specification to match

the functionality and performance of the changed service. The CA is informed of any

changes to the material it has already received as part of the process used to determine

whether it wishes to review the change or not and the safety assessment process starts

again from the beginning71. Whether it can deal simply with the differences or it means a

considerable re-work of the material developed so far, depends upon why the first

change did not mitigate the risk — as it was intended to do.

67 There is a subtlety here: If the way the service behaves still meets the specification promulgated by service

provider B, then there is no change. However, if service provider B still believes it behaves acceptably but it does not meet the specification, then service provider B will have to notify the competent authority of the change.

68 It could also attempt to prevent service provider A or any other change proposers making the change they propose.

69 ‘Additional change’ is used for simplicity. It could, of course, be a modification to the original mitigation change proposal, i.e. the addition could be a subtraction.

70 Guidance on the safety assessment process may be found in GM4 ATS.OR.205(b) Safety Assessment and Assurance.

71 Guidance on the safety support assessment process may be found in GM1 ATM/ANS. OR.C.005 Safety support assessment and assurance of changes to the functional system.





(x) There may be no externally instigated change. The service provider may simply wish to

change its functional system. When it decides to do so, it plans the change and notifies

the CA. The planned change is assessed72 and an assurance case produced73 74. But what

if the change to the ATM/ANS functional system was found to have an acceptable level of

impact on the first pass through the assessment process? It would, therefore, appear

that the safety assurance case could be produced after the question: ‘Would the

proposed change pose an unacceptable level of risk?’ is answered negatively or the

safety support assurance case could be produced after the question ’Does the proposed

change meet all regulations and can it be implemented?’ is answered positively. It could

be argued that to perform verification on the change is an unnecessary and consequently

extremely inefficient use of resources because adequate safety or specification of service

has already been demonstrated by design. Such a view appears to be a proportionate

response to the findings of the assessment. However, this view is unjustified because

while the intent may be to perform a change that ‘does what it is supposed to do’ and the

design supports this intent, the implementation may not match the design and so a

change which has no designed safety or other performance consequences may have

some when it is implemented. The verification, therefore, guards against the failure to

implement the design as intended75.

72 Complying with ATS.OR.205(b) or ATM/ANS.OR.C.005(b) as appropriate. 73 Complying with ATS.OR.205(d) or ATM/ANS.OR.C.005(d) as appropriate. 74 For a full explanation of the interactions between the service provider and the competent authority during change,

see GM1 ATM/ANS.AR.C.035 & ATM/ANS.OR.A.045 General 75 This argument applies to the verification of changes to all ATM/ANS functional systems and not just to ATS

functional systems.





Table 1 — Examples of changes that may require safety assessment76

Examples of changes for ATS providers that may require safety assessment (and perhaps supervision),

i.e. those within the scope of ATS.OR.205

Change

description

Possible reason

for change Potential changes to… Remarks

Increase in traffic

in airspace

(Environmentally-

triggered change)

Business-driven:

e.g. management’s

desire to increase

market share by

seeking an increase

in the level of traffic

handled

People

Training for new procedures and

equipment

Increase in personnel

Working hours/shift patterns

(fatigue and the associated

increased risk of human errors)

The change is a deliberate attempt by the

provider of ATS to increase throughput.

Daily fluctuations in traffic are not

considered to be a change, neither is an

increase in traffic that is already covered in

the organisations certification or a previous

change safety case.

The change is actually a change in the

environment of operation that would

require a change in the functional system

in order to make the operation acceptably

safe.

Procedures

New or changed procedures to

handle new services and increased

traffic

Changes to the ATM/ANS

organisation for delivering services

76 The table is written from the perspective of an ATS provider. However, in many places changes in equipment could refer to another service provider’s equipment, which could

be linked with the ATS providers functional system via a service, e.g. surveillance and communications equipment could be replaced by surveillance and communications services respectively. In such cases, safety support assessments would have to be produced for these services and the change is a Multi-Actor Change.







Change

description

Possible reason


Equipment

Possibly improved surveillance,

communication and/or other

systems, e.g. ATCO decision support

tools

Changes to the display of

operational data to controllers at

the point of service delivery

Changes to communications

systems (architecture, etc.) used for

the delivery of an ATS service

If changes are required to the surveillance

or communications systems already

present, the changes may involve the

operational use of new or modified

information that is already within the

current system. Such use could involve an

architectural change to make the

information available to the changed

components.

Architecture77

Possibly if the surveillance and

communication systems change it

may require changes in the

interfaces with equipment already

present

Environment Increase in traffic

Airspace change

Changed

communication

system (gr/ac,

Business-driven:

e.g. obsolescence

(efficiency), desire

People

Possibly training for new equipment

interface

Training for technical personnel

This is not intended to include the like-for-

like replacement of a piece of equipment.

However, it does include the replacement

77 This refers to an organisational change to the operational system i.e. a change to the architecture of the functional system — the way the system interacts. It does not refer to

the ‘organisation’ i.e. the management of the company, which is not relevant for this provision and so is not considered.







Change

description

Possible reason


gr/gr)

(Functional

system change)

to increase market

share

SMS-driven: e.g.

‘alarp’, operational

deficiencies

Procedures Change to maintenance procedures of a component with a similar but not

identical one i.e. a component having

similar functionality but whose design is

different (including different software) as

demonstrated by having a different part

number.

It could also include the introduction of

new technology to improve the information

exchange between a/c and ATS, e.g.

ADIRS. This may be for safety reasons or

because the business wishes to introduce

new services. However, the example given

here deals with a simple replacement and

is not intended to imply that the current

operational service is altered.

Equipment New equipment

Architecture

A change in the equipment, e.g. the

use of new interfaces, or a change

in services. For example,

introduction of gr/ac

communications, would alter the

architecture.

Environment Possibly the re-siting of aerials

Introduction of

new surveillance

facility

(Functional

system change)

Business-driven:

e.g. desire to

increase market

share

SMS-driven: e.g.


deficiencies

People

Training on new procedures and

equipment

New or changed technical personnel

This example is the introduction of a new

form of surveillance rather than a change

to pre-existing surveillance equipment.

This may be a ‘leading change’ i.e. a

change in the surveillance system as a

prelude to making a change in the services

offered in order to increase throughput.

It could also be a change to improve the

quality of surveillance material in order to

Procedures

Procedures changed to include the

use of new forms of surveillance

Change to maintenance procedures

Equipment New equipment and possibly new or

changed sensors







Change

description

Possible reason


Architecture Integration of the new surveillance

with rest of the system

make the system safer or to correct

recently identified operational deficiencies.

Environment

Possibly siting of new sensors or re-

siting of current sensors in the

external environment

Changed

surveillance

facility

(Functional

system change)

Business driven:

e.g. obsolescence

(efficiency), desire

to increase market

share

SMS driven: e.g.,


deficiencies

People

Possibly training for new equipment

interface


This is not intended to include the like-for-

like replacement of a piece of equipment.

However, it does include the replacement

of a component with a similar, but not

identical one i.e. a component having

similar functionality but whose design is

different (including different software) as

demonstrated by having a different part

number.

It could also include the introduction of

new technology to improve the information

exchange between a/c and ATS, e.g. SSR.

This may be for safety reasons or because

the business wishes to introduce new

services. However, the example given here

deals with a simple replacement and is not

intended to imply that the current

operational service is altered.

Procedures Change to maintenance procedures

Equipment New equipment

Architecture Unlikely

Environment Possibly the re-siting of

aerials/sensors







Change

description

Possible reason


Airspace re-

organisation

(Class E – A, Mil

– Civil, Shape of

sectors)

(Environmentally-

triggered or

Functional

system change)

Environmentally-

driven: strategic

state initiative

People

Possibly additional operational

personnel


equipment

Possibly additional technical

personnel


This change is driven by the State and is

probably due to a strategic review of

national airspace use.

The provider of ATS cannot ignore it and,

therefore, it is an environmental change

that may require a responsive change to

the functional system.

If the change of airspace type makes the

airspace more restrictive, e.g. airspace

classes C to A, then there will be a

considerable change to the operational

procedures and the skills required of

operational personnel. It may also be

necessary to improve the surveillance

and communication facilities in order to

meet the demands of the new

classification, in which case technical

Procedures

Change to or the creation of

procedures (operational &

maintenance)

Equipment

Possibly to improve

surveillance/communications if

change of airspace classification.

Architecture Likely if procedures call for the use

of new/changed information.







Change

description

Possible reason


Environment Possible change to sector shape

personnel and maintenance procedures

will also change.

Such a change will, in all likelihood, alter

the way that information is used and

distributed in the system, thus,

necessitating a change in organisation.

Both a change in airspace classification

and a change in sector shape will have to

be promulgated in the AIP.

Airspace re-

organisation

(Class E – A, Mil

– Civil, Shape of

sectors)

(Environmentally-

triggered or

Functional

system change)

Business-driven:

e.g. desire to

increase market

share, desire to

increase efficiency

SMS-driven: e.g.


deficiencies

People


personnel


equipment


personnel.


In this case, the change is driven by the

desire to improve the business. It is,

therefore, likely that the drive will be for

more traffic or improvements in

effectiveness or efficiency. Consequently,

there may be a considerable change to

the operational procedures and the skills

required of operational personnel. It is

also likely that the business will wish to

improve the surveillance and

communication facilities in order to

facilitate the changes it desires in its

operations, in which case technical

personnel and maintenance procedures

Procedures



maintenance)

Equipment Likely in order to improve

surveillance/communications







Change

description

Possible reason



of new/changed information

will also change.

Such a change will, in all likelihood, alter

the way that information is used and

distributed in the system, thus

necessitating a change in organisation.

The desire for efficiency may lead to a

reorganisation of the airspace, e.g.

changed shape or

temporal/circumstantial manipulation of

several sectors.

Both a change in airspace classification

and a change in sector

shape/organisation will have to be

promulgated in the AIP.

Environment Possible change to sector

shape/organisation

VFR pilots obliged

to carry

transponders

below TMA

(outside ANSP

controlled

airspace)

(Environmentally

triggered change)

Environmentally

driven: strategic

State initiative,

European initiative

People

Training to recognise VFR a/c

moving towards infringement with

controlled airspace

This change has a safety objective and is

driven by regulation. The objective is to

make VFR a/c more easily seen and,

thus, avoid conflict with controlled traffic

caused by their invisibility, primarily to

providers of ATS.

The providers of ATS cannot ignore it

and, therefore, it is an environmental

change that may require a responsive

Procedures Possibly, due to different way of

recognising and reacting to VFR a/c

Equipment Possibly if the responses from VFR

saturate the ATSP’s SSR.








Change

description

Possible reason


Environment Increase in SSR traffic due to VFR

a/c

change to the functional system.

This may necessitate retraining

operational personnel and changing their

procedures in order to accommodate the

new form of surveillance for VFR a/c.

It may also necessitate changes to the

SSR to accommodate the increase in

responses due to VFR a/c close by.

Wind farm

(Environmentally-

triggered change)

Environmentally-

driven: local/State

initiative

Business-driven,

e.g. desire to

improve efficiency

by generating their

own electricity

People Unlikely unless procedures change

dramatically

Wind farms change the electromagnetic

environment, the visible environment and

the physical environment (by generating

turbulence). Depending on their

relationship to the controlled airspace

and operation personnel, changes may

vary from simply installing filters in

surveillance and/or communications

equipment to re-siting runways (so a/c

avoid turbulent areas), re-siting

Procedures

Change to accommodate loss of

surveillance information and likely

change in flight paths

Equipment To mask the interference effects of

the wind farm








Change

description

Possible reason


Environment

Re-siting of aerials, changes to lines

of sight for ATCOs, reconfiguration

of runways

operational personnel (so their line of

sight is not affected and they are not

affected by flicker) and re-siting

communication aerials/sensors (so as to

avoid or minimise the interference

effects).

Whilst wind farms are a particular

example, any object that, while not

placed on the aerodrome or whose

placement is not a result of a decision by

an provider of ATM/ANS, could still

potentially affect the operation of the

provider of ATM/ANS, needs to be

assessed for its impact on safety and if

necessary trigger a change to the

functional system.

New missed

approach

procedure

(Functional

system change)

Business-driven:

e.g. desire to

increase efficiency,

desire to increase

effectiveness

SMS-driven: e.g.


deficiencies

People Training on new procedure

Procedures New procedure

Equipment Unlikely


Environment Unlikely







Change

description

Possible reason


Removal of

assistant position

(tasks go to

ATCO and/or

automation)

(Functional

system change)

Business-driven:

e.g. desire to

increase efficiency

People

Reduction in operational personnel

Training for new role, possibly

different personnel.


personnel


In order for the ATCO to take over the

role of the assistant, then it is likely that

the information used by the assistant will

have to be presented to the ATCO.

Moreover, in order to avoid overload, the

information used by the assistant and the

information used by the ATCO will have

to be presented in a different, more user-

friendly, form. It may also be necessary

to provide additional automation to

perform some assistant’s tasks or

additional safety nets to accommodate

the loss of the ‘second pair of eyes’. This

certainly implies changes to the

equipment at the ATCO’s working

position and very probably implies

changes to the functions providing

information to those working positions.

Procedures Change to operational and

maintenance procedures

Equipment

Change to operator interface likely

to change the functions for the

manipulation and visibility of

surveillance and communications

information/management

Possibly the addition of safety nets

Architecture

Removal of assistant position and

likely changes to the way

information is managed and

distributed within the system.

Redistribution of

function/responsibility between

human-automation







Change

description

Possible reason


Environment

Possible change to sector

shape/organisation to limit ATCO

workload

Integration of

automatic

meteorological

information e.g.

METAR, SIGMET

(Environmentally-

triggered or

Functional

system change)

The provider of MET

services wishes to

improve its

efficiency or seeks

a larger share of

the market

People

Possibly training if operational

personnel were used to transform

MET data for operational use

Possibly training if MET data will

now be displayed in a different form


Depending on the form and content of

the data supplied by the provider of MET

services currently, the provider of ATS

may simply have to change the way the

equipment manipulates and displays the

data. However, it may also be able to

reduce the need for human intervention

in transforming the data so that it can be

used directly by the ATCO (or transmitted

to the a/c). If it chooses to do the latter,

then procedures will have to be changed

and, consequently, operational staff re-

trained.

Procedures

Possibly change of procedures if

MET data cannot be transformed

automatically and displayed in the

current form


Equipment

Possibly new or changed equipment

to receive the data in its new form

and modify/distribute it to

operational personnel

Architecture Changed interface with the provider

of MET services








Change

description

Possible reason


Integration of

automatic

meteorological

information e.g.

METAR, SIGMET

(Environmentally-

triggered or

Functional

system change)

Business-driven:

e.g. desire to

increase efficiency

SMS-driven: e.g.


deficiencies

People

Reduction in personnel used to

transform MET data for operational

use

Likely training to accommodate

changes in operational use/display

of MET data

Training for technical personnel.

The desire to improve efficiency would, in

all probability, lead to an increase in

automation, i.e. the automatic

transformation and display of MET data in

a form more easily used by the ATCO or

a/c.

The business driver would be a reduction

in the number of staff used to transform

and communicate MET data.

This may also be an appropriate solution

to an operational deficiency if it is related

to the manual transformation or

communication of MET data.

Procedures

Likely change of procedures to

accommodate automatic

transformation and display of MET

data


Equipment

Likely new or changed equipment to

receive the data in its new form and

modify/distribute it to operational

personnel

Architecture Changed interface with the provider

of MET services


Change to cross

wind limits

(Environmentally-

Environmentally-

driven: discovery

that the a/c type

People Unlikely A reclassification of the a/c type for cross

wind manoeuvres probably does not

necessitate retraining of operational Procedures Re-categorisation of a/c type for

cross wind manoeuvres







Change

description

Possible reason


triggered or

Functional

system change)

manual is wrong

SMS-driven: e.g.

safety is worsening

Equipment Unlikely personnel. Notification and awareness

may be sufficient.

However, a change to the cross wind

classification of many a/c, which may be

due to the observation that safety is

worsening, may result in the need for

more extensive changes to the

procedures and, consequently, the

retraining of operational personnel.


Environment Different distribution of a/c in cross

winds

Change to cross

wind limits

(Environmentally-

triggered or

Functional

system change)

Business-driven:

e.g. desire to

increase market

share

People


personnel


equipment


personnel


Larger a/c can usually manoeuvre safely

in higher cross winds than lighter a/c.

Therefore, this business-driven change is

to allow the aerodrome operator to

handle larger a/c, presumably because

the organisation wishes to increase

passenger throughput.

Consequently the change to the

functional system is related to the change

in a/c types and the number of them

handled by the aerodrome operator, and

is, therefore, much more extensive than

the change described above.

Procedures



maintenance)

Equipment

Likely in order to improve

surveillance/communications due to

increase in traffic







Change

description

Possible reason



of new/changed information

Environment Heavier and possibly many more a/c

in the environment

Table 2 — Examples of changes that may require safety support assessment78

Examples of changes for service providers other than ATS that may require safety support assessment (and perhaps supervision),

i.e. those within the scope of ATM/ANS.OR.C.005

Change

description

Possible reason


Introduction of a

new tool for

issuing NOTAM

Business-driven:

e.g. desire to

increase efficiency

People Training for new procedures and

equipment

If the service does not change, then there

is no need for the users of the service to

make any assessment of that change. If

the service changes e.g. the content and

format of the NOTAM change, then the

NOTAM users may need to make an

assessment of the impact of these changes

to them. The change then becomes a

multi-actor change.

Procedures

New or changed procedures to

handle the new tool

Changes to the AIS organisation for

delivering services

Equipment Likely changes in software and also

in hardware

78 The table is written from the perspective of an service provider other than ATS provider. However, in many places these changes services with be dealt with as a multi-actor

change.





Examples of changes for service providers other than ATS that may require safety support assessment (and perhaps supervision),

i.e. those within the scope of ATM/ANS.OR.C.005

Change

description

Possible reason


Changes on the

Transmissometer

providing

runway visual

range

information

Business-driven:

e.g. desire to

reduce

maintenance costs

by changing the

units by others with

longer MTBFs

People Training for new procedures and

equipment, where needed

The proposed change may not change

anything in the information contained in

the METARs and will not, therefore, affect

the ATS provider or the airspace users.

However, if there would be any impact in

the information provided in the METARs or

in the way and time they are distributed,

the change may affect the ATS provider

and/or the airspace user and needs to be

treated as a multi-actor change

Procedures New or changed procedures to

maintain the new units

Equipment Changes of units





Table 3 – Examples of changes that may not require safety or safety support

assessment

79 ‘Covered by a procedure’ includes the concept that a safety assessment has been performed on the procedure, and the

maintenance action is shown to be acceptably safe. So here we are dealing with maintenance action against a pre-approved procedure.

80 It is assumed that a safety or safety support assessment has already been performed on the operations manual and the change is simply dealing with the use of the procedure, not its introduction or removal.

81 These are pre-approved operational and maintenance procedures that have been specifically created for use in the circumstances of the failed system/component, e.g. for a large system failure, the operational procedure will be one for reducing and limiting traffic in the airspace until normal operation can be resumed.

Examples of changes for service providers that may not require

safety or safety support assessment,

i.e. those not in the scope of ATM/ANS ATS.OR.205

Change description Type of change Possible reason for

change

Organisational

change

Change to

organisation,

not to the

functional

system.

Political reasons/Desire

to increase efficiency

Maintenance change,

covered by a

procedure79, where

components are

changed on a like-for-

like basis

Planned/Regular Preventive actions on

technical components

Day-to-day

operations e.g. a

change in runway

direction, described in

operational manuals80

Operational

tactical change

Change in environment

of operations, e.g. wind

direction, weather,

regular change

associated with noise

abatement

Use of alternative

procedures81 in

response to the

failure of a

system/component

Operational

tactical change

Failure of an

operational system





AMC/GM to ANNEX II — Requirements for competent authorities —

Service provision and network functions (Part-ATM/ANS.AR)

SUBPART A — GENERAL REQUIREMENTS

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

SUBPART C — OVERSIGHT, CERTIFICATION, AND ENFORCEMENT

(ATM/ANS.AR.C)

GM1 ATM/ANS.AR.C.035 & ATM/ANS.OR.A.045 General

INTERACTIONS BETWEEN SERVICE PROVIDERS & COMPETENT AUTHORITIES DURING THE

CHANGE PROCESS

(a) The purpose of this GM is to describe the interactions that take place between the service

provider making a change to its functional system and the CA in deciding whether to review

the change or not, and in reviewing the change. It also explains the use of some of the

technical terms provided in the IR82.

(b) This GM uses GM2 Annex I Definitions (35) as the basis for understanding what is meant by

a change, i.e. it is some physical alteration to one or more of the components (people,

procedures or equipment (HW or SW)) of the functional system or to the architecture

(connections between components or the set of laws governing the relationships between

the inputs to the functional system and its outputs) of one or more service providers that

would potentially alter the way the service they deliver behaves. The change may be a

necessary response to a (proposed) change in the operational context of one or more of

these services. As the word ‘change’ has many meanings, it is not possible to give an

adequate and appropriate definition of a ‘change’; some guidance has been provided to

explain the different cases of changes needing safety and safety support assessments as

per ATM/ANS.OR.C.005 and ATS.OR.205 and some examples have been provided..

(c) Overview of the change process (See Figure 2)

(1) Most changes start by identifying the need for a change and establishing sufficient

information about the change, that it can be put to the organisation’s management

board for their agreement. From the perspective of change regulation, this (planning)

phase is not included in this GM and is not shown on Figure 2.

(2) When a service provider has a real intent to implement a change, it should notify the

CA of its intent to change the functional system as early as possible bearing in mind

that:

82 Many different process models and technical terms are used by ATM/ANS providers and competent authorities to

describe aspects of change. These models and the technical terms used are not standardised throughout Europe and the scope of changes varies considerably. It is, therefore, impossible to define a generic process model, that includes al variability in terms used, the stages/phases used and the milestones. Consequently, the approach taken in this

General GM is to explain the terminology, phases and milestones used in the legislation in enough detail and with enough clarity that both ATM/ANS providers and competent authorities can see how the legislation maps to their particular model of the change process.





(i) It has to give the CA sufficient time to decide whether to review the assurance

case83 or not; and

(ii) if the CA decides not to review the change, the service provider may make the

change in accordance with the approved procedures. An important element of

the procedures is that the service provider will produce a valid assurance case

before making any change to the functional system that could affect the

operation.

Note that, as part of general oversight, the competent authority may select such

a change to determine if the procedures are applied properly and the change is

safe. Apart from general oversight the CA will not be involved in the change.

(iii) If the CA decides to review the change, the CA will be involved in the change

process. As a consequence of the CA’s decision, the implementation of the

change is dependent on the approval of the CA.

(3) The details of the interaction process will be described in both the CA and service

provider’s procedures. For optimum effectiveness and efficiency, the parts of these

procedures dealing with the interaction between the CA and the service provider are

best developed cooperatively.

(4) The general concept that rules such procedures will be that the service provider will

inform the CA about the planning and important steps in respect of safety in the

development of the change. If the CA decides not to review a change, the exchange of

information will be minimal.

(5) All work related to the development of the change can continue until any part of the

change, if implemented, would affect the operational service. At this point, the change

needs to be accepted by the service provider and where the change is to be reviewed,

approved by the CA.

Transitional Service Intended Service

(Changing service) (Changed service)

Development Implementation

Operation

Change is

complete.

Full entry into

intended service

Operational system

may begin to change

from here

Transitional monitoring Operational monitoring

Transition

into serviceDefinition

Current Service (operational system)

Figure 1:

An overview of the change process

83 ‘Assurance case’ is used to describe either a safety case, a safety support case or both, and is used throughout this

GM as shorthand way of saying ‘assurance arguments and evidence’.





(6) Figure 1 shows that the change process consists of two different processes:

development and implementation. No timescales are implied in Figure 1 because the

definition and transition into service phases may take many years in some cases, e.g.

moving an ATC unit to a different location and a few days in others, e.g. simple

change to a procedure is made and communicated to the operators by means of a

briefing paper.

(7) The difference between developing and implementing a change is that development

deals with design84, whereas implementation deals with concrete artefacts i.e. those

built or manufactured component parts that were identified in the design, and also

with integrating them into the functional system to become a whole. Since, at any

stage, some artefacts are being developed, while others are being implemented e.g.

COTS components may be purchased before some other components have been

designed, and simple changes to software may predate the changes to the hardware

on which it operates, the diagram shows considerable overlap between development

and implementation.

(8) Note that any part of the implementation that has the potential to affect the

operational service85 cannot be started until a valid assurance case for the change

exists or, where the CA has decided to review the assurance case, it has been

approved8687.

(9) The service provider may decide to implement the change in phases. This is described

in (d) below, which introduces the notion of a ‘transitional service’ where the change

may be introduced gradually. Figure 3 shows such a situation. The first

implementation activities begin before the change has any influence on the operation.

Overall development continues during the transitional service and is finalised well

before the change reaches the point where the change is completed. Each transition

may enter operational service provided a valid assurance case for it exists.

(10) The development of the change may continue during the transition of the change into

service. However, the assurance case needs to contain a valid safety argument that is

in line with such an approach.

(11) The ‘operation’ phase begins when the change has been completed88 and the

operation is as intended. As part of the safety/safety support assessment89, it may

have been decided that, during operation, monitoring activities are required to be

established. The CA may wish to review this monitoring process or may wish to be

84 There is also an interaction between development and implementation. Concrete (implemented) artefacts may be used

in a manner that assists the development (design) of other dependant artefacts. 85 That is, one that potentially changes the way the operational service behaves, e.g. the installation of Mode S, even

though the information is not used immediately after installation — also see footnote 8. Note that building and testing the Mode S radar can be done before it is installed into the functional system. So implementation of the radar is in two parts: building and testing it in isolation from the functional system and implementing (installing) it within the functional system.

86 This is shown on the diagram as a vertical line separating the current and transitional services. 87 This may be more difficult than would appear to be the case at first sight. It is difficult to prevent the knowledge

gained in training or the skills learnt in the simulation of a new procedure being adapted to modify the current procedures. Consequently, it may be necessary to include such training and simulation exercises as part of the transitional service rather than part of development.

88 Shown on the diagram as a vertical line, with the caption ‘Change is complete. Full entry into intended service’, separating the transitional service from the intended service.

89 See monitoring requirement in safety assessments and safety support assessments as part of ATS.OR.205(b)(7) and ATM/ANS.OR.C.005 (b)(3) respectively.





informed about its results as part of its general oversight. This will lead to the

necessary interactions.

(12) The assessment of the monitoring activities identified above may lead to two types of

monitoring requirements:

(i) Temporary monitoring requirements; and

(ii) Permanent monitoring requirements.

Temporary monitoring may be used, during transitions, to build confidence in the

assurance case. It may be accompanied by temporary measures such as mitigations

that reduce the risk of the operation. These measures can be removed once the

necessary level of confidence has been established.

Transition finishes (and ‘Operation’90 begins) when all the confidence building

measures (Temporary monitoring and mitigations) have been removed. Consequently,

if the transition phase is long, the implementation phase is correspondingly long. The

monitoring that remains is then the permanent monitoring that is required to show

that the change remains safe and behaves as predicted in the assurance case.

(13) In cases where the change does not meet the expectations, i.e. does not satisfy the

temporary monitoring requirements, then. a ‘back out’ or recovery plan is needed.

This plan may depend on the risk involved and also may be conditional on the chance

of an unexpected outcome after implementation of the change.

(d) Different types of transitions in services

(1) Changes, e.g. novel, large or multi-actor changes, may involve several transitional

steps when going from the current operational service to the intended service. The

service provided during these steps varies as a result of phased changes to the

functional system. These steps are included in the ‘Transitional Service’ shown in

Figure 2.

(2) The service provider’s decision to implement the change in steps may have various

reasons, such as planning, training of personnel, gaining experience with specific

elements of the change before progressing. Independently of the reason for the

decision, it is important to inform the CA of the approach that is chosen and the

consequences for the change process, as it allows the CA to prepare, if necessary, for

a series of related changes rather than approaching it as a single change.

In general, there are two ways of making transitional changes:

(i) Each transition is treated as a separate change. In this case, each change is

notified separately to the CA and will have its own assurance case (as illustrated

in Figure 3 below91).

(ii) All the transitions are included within a single change and governed by a single

assurance case that must cover all transitions (as illustrated in Figure 4 —

section (e) below).

90 This is the Operation phase shown in Figure 2. During transitions, operations are affected. However, these operations

are part of the phase called ‘transition in to service’ in Figure 2, in order to differentiate them from those operations that will be in place once the change is complete.

91 For simplicity, this diagram and all others are illustrated as though the change were being made by an ATS provider. If the change only involved an ATM/ANS provider, then the diagram would use Safety Support language.





Monitoring

Current ServiceTransitional

ServiceIntended Service

Develop Assurance Case 1

Assurance Case

approved

ATM/ANS.AR.C.040(c)


(Changing

service)

Assurance Case 1 covers this operation

Tactical changes

Maintenance

(on condition, planned)

(Changed service)

Transitional



(Changing

service)


Maintenance


(Changed service)

Transitional


Monitoring

(Changing

service)


Maintenance


(Changed service)

Tactical changes Tactical changes

Assurance Case

approved

ATM/ANS.AR.C.040(c)

Assurance Case

approved

ATM/ANS.AR.C.040(c)

Figure 2:

Concatenated changes

(3) In cases where separate changes are concatenated, as shown in Figure 3, the CA will

decide for each change whether it will be reviewed or not. However, the provider

should avoid separating the change into multiple small changes unnecessarily (the so-

called ‘salami slicing’) as the lack of information about the relationships between the

various changes may leave the intent of the final service uncertain.

(4) If there is a relationship between the changes, it would be best to inform the CA about

the relationship in order to expose the common information. For such changes,

specific arrangements between the service provider and the CA may be supportive for

proper understanding and communication. Furthermore, the CA may wish to make

suitable internal arrangements in respect of its own phasing of the review of the

change.

(5) The assurance case must argue and provide evidence that shows that the final

operational service is acceptable92. However, since a transition may not meet the

acceptance criteria for the transition in the assurance case, as part of the transition

planning, the service provider may need or the CA may require a way of returning to

an acceptable service. This part of the transitional planning may be called a ‘back out

plan’ in the assurance case.

(6) If it is foreseen that the overall change would lead to an improvement of safety, but a

specific transitional step would lead to a reduction of safety, the CA needs to decide if

this is acceptable and may impose specific conditions. The foreseen reduction in safety

is to be brought to the CA’s attention as soon as it becomes clear. In supporting such

a decision, the service provider will explain why such a reduction of safety can’t be

prevented, what measures will be taken to limit the reduction of safety and what

overall safety gain will be achieved.

(7) As discussed in (d) above, in all cases, the assurance case must cover the transition

service(s) and the operational service(s) of concern.

(e) Interactions — From notification to approval

A more detailed view93 of the process from notification to approval is shown below:

92 In the case of an ATS change, it is ‘acceptably safe’. In the case of any other ATM/ANS service, ‘acceptable’ means

that the service meets the declared specification for the particular transition. 93 In the diagram, the ‘transition into service’ (see ATM/ANS.OR.C.005(b)(1)(iv) and ATS.OR.205(b)(1)(iv)) is

accomplished via a series of transitional changes to the functional system which results in a number of transitional services. To aid readability, the diagram uses the term ‘transition’ instead of the more correct ‘transitional service’.





Transition

1

Transition

2Transition

3

Change Deployment

(Implementation)

InteractionInteraction

Assurance Case

approved

ATM/ANS.AR.C.040(d)

Changing the operational service

(via a number of transitional

changes – see (d)(2)(ii))

Interaction

Supervision

Change Development/implementation

Notify CA of change

ATM/ANS.OR.A.045

(c)(1)

Observe change progress

(offer guidance & review draft assurance cases)

Seek & Review Change

informationReview Assurance Case

Change Development and offline implementation

Current Service (operation)

Notify ATM/ANS

provider of decision

to review safety

argument

ATM/ANS.AR.C.035(d)

Deliver Assurance

Case to CA

Implied by:

ATM/

ANS.OR.OR.A.045(d)

Service

provider

Competent

Authority

No Change to

the operational

service before

this point

Figure 4: Processes prior to initial entry into service

(1) The competent authorities activities in this part of the model are divided in three

stages:

(i) Seek and review change information;

(ii) Observe change progress94 and possibly review draft versions of the assurance

case; and

(iii) Review assurance case

(2) Seek and review change information

(i) This stage begins when the service provider notifies the CA of the change95.

Immediately after this the CA will seek the information needed in order to decide

whether to review the assurance case96 or not97 .This information will result from

interaction between the CA and the service provider and it will help the CA in

understanding the scope, size, complexity and novelty of the change98. As every

change is different, definitive rules for the required information cannot be given

and so the process is best regarded as one that is beneficial to both parties. The

CA does not need or wish to review every assurance case and the service

provider will minimise the effort of interacting with the CA if it provides

appropriate and sufficient information about the change99.

(ii) Notification is an event. Its intent is to alert the CA to the fact that a change is

proposed by a service provider. However, given that some changes, those that

94 This is usually achieved by regular coordination activity during development and implementation. See (e)(3) for more

detail. 95 Please see ATM/ANS.OR.A.045(a). 96 It may seem unusual to review the assurance case rather than review the change. However, since the change has not

been implemented at this stage, then the only available course of action is for the CA to review the change via its assurance case.

97 See ATM/ANS.AR.C.030(a). 98 Guidance is given on the range of information that may be required in AMC2 ATM/ANS.OR.A.045(a) &

GM1 ATM/ANS.OR.A.045(a). 99 If the information provided is not appropriate or sufficient to help the CA to make its review decision, the CA should

request additional information from the service provider about the change as requested in ATM?ANS.AR.C.035(a).





carry very low levels of risk, will not be reviewed, the notification carries

sufficient information to identify these cases without further interaction between

the CA and the service provider100.

(iii) Having decided whether or not to review the assurance case for the change, the

CA needs to inform the service provider of the decision101. The service provider

should be advised of the decision whether it is positive or negative. This

guarantees for each change clarity between the service provider and the CA

about the involvement of the CA.

(3) Observe change progress

(i) Once the service provider has been advised that the assurance case will be

reviewed, the CA could wait for the assurance case report102 to be delivered by

the service provider. However, in reality, since the review will normally take

place where the change is either large, complex or novel103, the CA would be well

advised to engage with the service provider earlier. This will allow the CA to

acquire knowledge of the safety aspects and the details of the change slowly via

workshops, attending the service provider’s coordination activities or the phased

delivery of the assurance case, rather than having to assimilate a very large

amount of information in a short time. The review time is critical, as once the

service provider has completed the assurance case, it is likely that it would wish

to start changing the operational service quickly. These coordination activities

will also allow the CA to establish that the acceptance criteria are valid104

(relevant, sufficient and necessary).

(ii) Interaction may also be beneficial to the service provider. For instance, the CA,

may have experience of similar projects for which the service provider does not

have (i.e., he change may be larger or more complex than they are used to or

may be novel). The CA may be able to provide timely information that will assist

the service provider’s approach and should do so, providing it does not

compromise the regulator/regulated relationship (regulatory capture).

(iii) In summary, in the period between advising the service provider that a change

is to be reviewed and receiving the assurance case, there will be a period of

interaction between the CA and the service provider where the CA learns about

the change in a comfortable way and can offer guidance on the likely

acceptability of the assessment and the assurance case105.

(4) Review assurance case

(i) The next stage begins once the assurance case has been delivered to the

CA106107. Fundamentally, the purpose of the review is threefold, i.e. to determine

that:108

100 See AMC2 ATM/ANS.OR.A.045(a) & GM1 ATM/ANS.OR.A.045(a) for a definition of the information required in a

notification. 101 See ATM/ANS.AR.C.035(c). 102 Assurance case report: a summary of the assurance case that enables the CA to gain full access to the assurance case

— see GM1 ATM/ANS.OR.C.005(a)(2) & ATS.OR.205(a)(2) General. 103 The CA may also randomly select assurance cases for review. This may be done as a means of validating the review

selection criteria. 104 In the case of a safety case, the acceptance criteria are safety criteria. In the case of a safety support case, the

acceptance criteria are the validity of the specifications of behaviour and context. 105 Including the acceptance criteria. 106 Implied by ATM/ANS.OR.A.045(d).





(A) the change is and will remain safe in accordance with the safety criteria

(for ATS providers) or the service after the change will behave and will

continue to behave only as specified in the specified context (for service

providers other than ATS);

(B) the safety criteria are justified and establish a valid safety level that is as

low as is reasonably practicable and establish the appropriate safety

support requirements (for ATS providers) and that the change conforms to

the scope that was subject to safety support assessment, the service

behaves only as specified in the specified context, and 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 (for service providers other than ATS); and

(C) the assurance case validly argues that the safety criteria will be satisfied

when the change is implemented and will remain satisfied throughout the

perceived operational use (for the ATS provider) and that the assurance

case validly argues that the service after the change will behave and will

continue to behave only as specified in the specified context (for service

providers other than ATS).

(ii) The assurance case will be discussed by the service provider and the CA. When

an assurance case submitted by the provider is judged to be not sufficient, not

completely correct, or not comprehensible, it is not necessary, in the first

instance, for the CA to reject the assurance case. It may instead involve itself in

additional interaction with the provider. The additional interaction may uncover

missing information, unclear arguments or misunderstandings about the validity

of arguments, the sufficiency of evidence or the justification of the methods used

in the assessment. This could lead to an update of the assurance case (perhaps

more than once) or a disagreement that will have to be resolved by

management. When the change and the argument are considered acceptable to

the CA, the assurance case will be approved and the change to the functional

system can begin.

(iii) The phase ends with the approval or rejection of the change by the CA109. For

purposes of transparency and ultimately resolution of any legal challenge, the CA

needs to justify the decision. In case of rejection, the justification will be

included with the rejection notification, since it is important for the service

provider to understand the considerations110.

(f) Interactions — Making the change operational

An overview of the final part of the process is shown below.

107 The assurance case delivered may not actually be an assurance case, but may be an assurance case report, which

may be limited to the identification of the claims and arguments (although not necessarily all of them) and will probably not include the bulk of the evidence. That will be retained by the ATM/ANS provider simply because of its bulk.

108 If any of these criteria are not satisfied, it could be a result of flaws in the accepted change procedures. The realisation

of this should trigger separate supervisory activity. Clearly, this activity will interact with the change review process, but is not the subject of this General GM.

109 See ATM/ANS.AR.C.040(c). 110 See ATM/ANS.AR.C.040(c)(2).





Current Service Intended Service

Assurance Case

approved

ATM/ANS.AR.C.040(d)

Monitoring

(Operation vs Assurance case)

(Changing service)

Operation covered by Assurance Case

Tactical changes

Maintenance (preventative and on-condition, )

(Changed service)

Review Assurance Case SupervisionCompetent

Authority

Development

Implementation

Service

provider

Changing the operational service

(via a number of transitional

changes – see (d)(2)(ii))

Transition

1

Transition

2Transition

3

Figure

5: Making the change operational

(1) The operational service may begin to be changed after the:

(i) receipt of the CA’s approval if the assurance case has been reviewed111; or

(ii) completion of a valid assurance case if the change is not to be reviewed by the

CA112.

(2) In this final stage, there is a transition from the current operational system to the new

intended operational system (the changed system). This transition may itself consist

of several phases. These are shown as Transitions 1, 2 & 3 on the diagram and

described fully in (c).

(3) Where the change is approved by the CA, normally there will be no interaction

between the service provider and the CA in this phase. However, the review will have

taken into consideration that the assurance case also covers any foreseen113:

(i) tactical changes114, i.e. day-to-day alterations in the operation, and

(ii) maintenance activities, i.e. preventive and on-condition maintenance.

In all cases, the service provider will consider these elements as part of their change.

(4) The service provider will monitor the operational system to show that it conforms to

the monitoring requirements in the assurance case. Some of these monitoring

requirements may be for specific and permanent monitoring, while others may be

temporary and/or addressed through the on-going performance monitoring of the

functional system. Later changes may make monitoring requirements identified in

previous assurance cases obsolete. The service provider may decide to introduce this

type of monitoring into the framework of the SMS.

111 See ATM/ANS.OR.A.045(d). 112 See ATM/ANS.OR.A.045(c). 113 Only those tactical changes and maintenance actions affected by the change need to be covered in the assurance case

of interest. It is expected that others are part of the design basis for the current functional system and so will already have been covered by a previous assurance case..

114 As defined in point (h) of GM1 Annex I Definitions (35) & ATM/ANS.OR.A.045 & ATM/ANS.OR.C.005 & ATS.OR.205 General.





(5) If the change does not satisfy the monitoring requirements, then usually either the

change is not as predicted or the assurance case itself is incomplete or incorrect, or

both. In either case, the service provider must take action to make the service and the

assurance acceptable again, which may include ‘backing out’ of the change i.e. the

service reverts to a previously known safe state, or proposing a new change.

(6) During general oversight related to changes, the CA may perform audits and/or

inspections to check that115:

(i) any changes made were made validly, i.e.:

(A) no un-notified changes have been made;

(B) all un-reviewed changes have assurance cases; and

(C) the properties that determine whether a change should or should not be

reviewed have not altered such that a change that was not reviewed,

should have been reviewed.

(ii) the service operation is being monitored and checked against the monitoring

requirements; and

(iii) if, as a result of the supervision, the assurance case is found to be invalid, then

the CA will require the service provider to take appropriate corrective actions,

which may include an amendment to make the argument valid, the instigation of

a change in order to make the service acceptable or even to revert to the

situation before the change.

AMC1 ATM/ANS.AR.030 Approval of change management procedures for ATM/ANS

functional systems

GENERAL

(a) The CA should check that the procedures used by a service provider to manage changes

cover the complete life cycle of a change.

(b) When reviewing the content of the procedures, modifications, and/or deviations referred to

in ATM/ANS.AR.030(a), the CA should use the compliance matrix provided by the service

provider referred to in AMC1 ATM/ANS.OR.B.015(a).

(c) The CA should check that the procedures are capable of initiating all the actions and

producing all the evidence to comply with requirements laid down in ATM/ANS.OR.A.045,

ATS.OR.205, ATS.OR.210, and ATM/ANS.OR.C.005 through their AMCs or alternative means

of compliance, if any . As part of this oversight activity, the CA should check that the

compliance matrix covers all the aforementioned requirements.

(d) The CA should check that the procedures identify the roles and responsibilities of the service

provider in the change management processes.

(e) The CA should agree with the service provider the means and method of submitting the

procedures, modifications and deviations referred to in ATM/ANS.AR.030(a). Until an

agreement is reached, the CA will prescribe the means and method of submission.

115 The checks described in this GM fall only within the scope of the supervision of a particular change. That supervision is,

as with other periodic supervision, done on a sampling basis and so these checks will not be performed each time a CA periodic supervision visit occurs. Clearly, other checks are made during periodic supervision, but these are not the subject of this GM. One related check is that, as a result of the experience of a particular change, the CA may decide to review the fitness for purpose of the change procedures themselves.





(f) The CA should check that the service provider’s change management procedures state that

it is not allowed to use new, modified or deviating change management procedures until

approval is granted.

(g) The CA should check that the service provider’s change management procedures state that

any change selected for review must not enter into operational service before the approval

is granted.

(h) The CA should keep a record of all the change management procedures, modifications, and

deviations it has approved in accordance with ATM/ANS.AR.030(a) and those that have

been rejected, together with a rationale. The CA should be able to cross-reference them to

the requirement of the associated Implementing Rule that they intend to comply with.

GM1 ATM/ANS.AR.030 Approval of change management procedures for ATM/ANS

functional systems

GENERAL

The review by the CA is focussed on the change management procedures and not on the project

management part of these procedures that are not required by the regulations, even though they

may be useful for the smooth execution of the project dealing with the change. Consequently, not

all parts of a procedure may be approved by the CA. The approved parts should be identified in

the record (see paragraph (h) of AMC1 ATM/ANS.AR.030) and communicated to the service

provider.

GM1 ATM/ANS.AR.C.035(b)(1) Decision to review the notified change

REVIEW CRITERIA — ATS PROVIDERS

(a) The review of a safety case.

(1) As the change to the functional system will only start being implemented once the

safety case is complete and in some cases approved, the review of the change is, in

fact, a review of the safety case.

(2) The change may or may not be adequately safe. Similarly, the safety case may

correctly identify the actual risk of the change or it may not. The table below describes

the desired outcome for all possible states of the change and its associated safety

case.

Change

Safety case claim:

‘The change is

adequately safe.’

Adequately safe

(Risk is acceptable)

Not adequately safe

(Risk is not acceptable)

Safe

ty c

ase

Sound:

The inferences and

supporting evidence

justify the claim.

Review is unnecessary. Review cannot happen.

The aim of the selection

criteria is to minimise

the number of reviews

here.

Selection criteria are

not relevant because

the change will be

abandoned and the

safety case will not be

submitted for review.

No action needed — the State cannot happen.





desired state.

Unsound:

The inferences or

supporting evidence

are insufficient to

justify the claim i.e.

the actual risk of the

change is not

correctly identified (it

may be higher or

lower than predicted

or its value may be

more or less certain).

Review may be useful

because it may help to

prevent future safety

cases being unsound.

Review is necessary116 if

the severity of the

consequences117 of the

change is reasonably

high.

Otherwise, the review

may be useful because

it may help to prevent

future safety cases

being unsound.


criteria is to select a

sufficient number of

these safety cases118.


criteria is to maximise

the number of reviews

here

Fix the safety case. Fix the change

and the safety case119.

Table 1: The possible states of a change

(3) The need for an independent review is based on the notion that two heads are better

than one. There is some likelihood (small though it may be) of an unsafe change being

developed, but the accompanying safety case claiming that the change is safe. While

the ATS provider will use skilled and dedicated staff in the development and review of

the change and its associated safety case, mistakes may still be made that remain

undiscovered. A CA who views things from a different perspective and is not immersed

in the change may uncover the mistakes, i.e. if a solution is looked at from different

perspectives, any problems with it are more likely to be discovered. The culture of a

developer of a change and that of the regulator are sufficiently different that the

interaction between the two parties may help uncover any flaws that remain even

after the review interactions that will have already taken place within the developer.

Moreover, because the CA deals with many ATS providers is likely to have a wider

experience of different changes.

(4) The purpose of the review is to establish if the change is as risky as predicted by the

safety case and if the claimed risk is acceptable or not. Changes are selected for

review well before the safety case exists and so the objective of the selection criteria

is to identify those safety cases that, when they arrive for review, may not correctly

identify the actual risk, providing the actual risk of the change is great enough to be of

concern. Selection, which is based on the ‘risk posed by the change’, uses the

combination of the probability that the safety case will be unsound and the severity of

the consequences associated with the change as the selection criterion.

116 The change is not adequately safe but the safety case has been submitted for review so the ATS provider believes the

change to be adequately safe. 117 The risk of the change is unknown at the time the selection decision is made. The reason the consequences are known

is explained in (e) 118 The change is safe but this is unknowable at the time of review. 119 Since the change is defined in the safety case, fixing the change necessitates fixing the safety case as well.





(5) The decision to review is expected to be taken well before the full safety assessment

has been performed and before the safety case is available because:

(i) coming to a decision as to whether to review a change or not is a process that

may need more information than is present in the notification. The decision may,

therefore, not be available for some time after notification;

(ii) interactions between the ATS provider will take place after the decision has been

taken and before the safety case is presented for review. These interactions are

described in GM1 ATM/ANS.AR.C.035 & ATM/ANS.OR.A.045 General;

(iii) these interactions themselves take time. The time they will take cannot be

estimated accurately as the extent of the interactions may not have been

completely foreseen by either the CA or the ATS provider. Therefore, a

significant period should be allocated in the project for this interaction;

(iv) the interactions may change the safety argument (its inferences and the

evidence needed) and so time needs to be available for this activity; and

(v) since the activities described above only occur once a decision has been made, it

is likely to be more efficient to interact with the CA while the change is being

developed and the safety assessment is being performed, than to wait until the

safety assessment has been completed before seeking the decision as to

whether to review the safety case or not.

Consequently, the information on which the CA has to make the decision as to

whether to review the safety case or not will be coarse-grained and early i.e. without

the depth or completeness that the safety case will finally have when developed.

(b) The risk posed by a change

(1) In any change, it is unlikely that all the risk associated with the services offered by an

ATS provider will be subjected to the change. In other words, there are always some

elements of the ATS provider’s operational system that will be completely unaffected

i.e. not directly or indirectly affected, by the change, , and the risk associated with

these elements is not altered by the change.

(2) An example of this is that while the operational misuse of a VOR poses a considerable

risk, this is not the risk in question when one is being re-sited. In this instance, it is

the risks due to dismantling and re-assembling the VOR and those due to its new

position that are the issue. These are a subset of all the risks connected with the VOR

and, hence, it is these risks that could be considered to be the risk associated with the

change. However, as identified above, this risk is not known to a sufficient degree of

accuracy at the time the decision is to be made.

(3) It should be noted that the need to review the safety case is not based on the net risk

after the change. In most cases, the purpose of the change is to restore the risk level

to what it was before the change or even to reduce the risk, and so the net risk

associated with the change is zero or it has a negative value. Clearly, if the selection

criteria used this risk, then there would be no need of a review in almost all cases.

However, a change that is intended to have a zero or negative net risk could clearly

have significant consequences associated with it, e.g. the removal of an ATC centre

from one location to another.

(4) The risk associated with the change, i.e. the severity of the consequences associated

with the changed part of the functional system together with the probability of their





occurrence, while being an appropriate risk to use for modulating the review, is not

appropriate for selection purposes — it is unknown at selection time.

(5) Moreover, there is no benefit in reviewing a change that deals with a great deal of risk

if the safety case is sound and the resultant risk of the service is correctly predicted to

be acceptable.

(6) Similarly, there is little benefit in reviewing a change, even though the safety case

may be unsound if the severity of the consequences associated with the change are

small, as indicated in Table 1.

(7) Selection for review should, therefore, be based on a combination of the likelihood

that the safety case may be unsound and the severity of the consequences associated

with the change. This is a risk function and is referred to as the ‘risk posed by the

change’. However, it can only be based on the coarse-grained data available at the

time the decision needs to be made, i.e. close to the time of notification.

(8) The definition of the risk posed by a change developed above is shown, in Figure 1

below:

Severity of all

consequences associated

with the change

f

Risk posed by change

Probability that an

unsound safety case

will be developed

Figure 1: The risk posed by a change

(c) Selection Process criteria

The process for evaluating the risk posed by a change should satisfy the following criteria:

(1) it should be rational, in line with the CA’s goal to promote safety;

(2) its procedures should be of a kind that inspectors find familiar and clear in their

meanings;

(3) it should be applicable, using the information (about each change request or

background information) available at each new change request, when the process is

first introduced; and

(4) it should be able to evolve and improve with the information that becomes available

over time, in part through the application of the process itself. What kind of

information this is in detail will depend on the details of the process, but will certainly

include:





(i) whether a change, once applied, proves to be unacceptable, and/or its safety is

queried by the CA due to evidence arising after the change has started to be

applied, and whether that change request had been reviewed or not; and

(ii) whether a change that has been reviewed has, as a result of the review, been

subject to queries by the CA and/or changes before being approved or rejected

or withdrawn by the ATS provider.

(d) The probability that an unsound safety case will be developed

(1) The actual risk, that is to be mitigated by the review of a change, is that associated

with an unsound safety case i.e. one that misidentifies or misevaluates the risks

associated with the change or provides insufficient evidence to support the inferences

used in the arguments. The risks associated with the change stem from:

(i) changes in the number of hazards;

(ii) changes in hazard rates;

(iii) changes in mitigations;

(iv) changes in mitigation probability;

(v) changes in accident trajectories120; and

(vi) changes to the circumstances of an accident trajectory, perhaps leading to new

accidents

both during operation and during the transition from the current service to the new

service. Note: In all cases, ‘change’ means: addition, removal or a change in

value/nature of some property of the system.

(2) Three different aspects of the change and the organisations performing the change

can affect the likelihood that an ATS provider will develop an unsound safety case:

(i) The difficulty of the change

(A) Its size;

(B) Its complexity (technical & managerial);

(C) Its novelty; and

(D) Its span (the range of different services impacted).

(ii) The capability of the ATS provider121

(A) Its technical capability — to manage the complexity, novelty and span of

the individual changes to be made to the functional system; and

(B) Its managerial capability — to manage the number and range of different

organisations involved in the change.

(C) Its operational capability — to manage the implementation and

introduction of the change, possibly across a number of service providers

and airspaces.

120 When modelling an accident, an accident trajectory is a chain of events starting with a hazardous event and

terminating in an accident. 121 Including the implied capability to develop a sound safety case using these technical/managerial/organisational

capabilities.





(iii) The ATS providers safety culture

(A) The stability of the organisation; and

(B) The quality of its SMS.

The way these aspects interact is shown in Figure 2 below:

+-

-

-

-

Organisation’s Culture(Is the organisation’s safety

culture mature enough to

withstand pressure to reduce

endeavours with respect to

safety?)

Change Difficulty(Do the characteristics of the

change make it more or less likely

that the safety case will be

sound?) Organisation’s Capability(Do the characteristics of the

organisation make it more likely or

less likely that a sound safety case

will be developed?)

Probability that an

unsound safety case

will be developed.

As the difficulty of the change increases,

then the probability of developing an

unsound safety case will also increase.

As the organisation’s capability

increases, then the probability of

developing an unsound

safety case decreases.

As the appetite for

safety increases,

then the probability

of developing an

unsound safety

case decreases.

The difficulty of the change

has a negative impact on

the organisation’s culture,

i.e. an increase in the

difficulty of the change is

likely to lower the

organisation’s appetite for

safety.

The difficulty of the change has a negative

impact on the organisation’s capability, i.e.

an increase in the difficulty of the change will

reduce the ability of the organisation to

develop a sound safety case.

Figure 2: The probability of developing an unsound safety case

(e) The severity of the consequences associated with the change:

(1) The assessment of the severity of the consequence is made at a very early stage in

the development of the change and, therefore, will be based on coarse data. It should,

therefore, be conservative.

(2) In the decision process, such a conservative estimate of the severity of the

consequences associated with the change can be established by making the

assumption that any demand on the part of the system being changed leads to a

response that is not adequately safe and is only mitigated by those parts of the

system unaffected by the change, i.e. the normal mitigations to be provided by the

change itself do not work. Another form of mitigation can be provided by assuming

that the unsatisfactory nature of the change will be identified at some point and the

change reversed. The time taken to detect and reverse the change can be thought of

as the ‘time at risk’. The consequence model is shown in Figure 3 below. The data

needed for it is available once the scope of the change has been identified as it relies





only on data from the current system and possibly a projection associated with the

future demand rate if it is to be different from the current demand rate.

Demand Rate Time at risk

Max number of

demands

Probability that the response to a

demand will not be adequately safe

(for a conservative model: external

mitigation only)

Max number of

accidents

Severity of the

consequences per

accident

Severity of all consequences

associated with the change,

e.g. max number of deaths.

Consequences

associated with the

change

Figure 3: The consequences of a change

(3) The proposed approach may seem unusual in that it combines a pessimistic bound

(largest estimated expected loss in case of unsound safety case) with a probability (of

the safety case being unsound, so that the change may not be adequately safe).

However, estimating the expected value of loss would require a much deeper analysis

than is possible at the early stage when the decision to review or not is required; it

may require most of a complete safety case for the proposed change to the functional

system. Given the limited information and, thus, high level of uncertainty, assessing

based on worst-case loss is a defensible decision criterion. Worst-case loss plausibly

correlates with expected loss, and this avoids the risk of underestimating it. Similar

approaches are used elsewhere e.g. in the nuclear industry, where conservative

estimates are used, together with claim limits to prevent excessive optimism.

(f) Establishing the risk function

(1) The risk posed by a change should be a scalar measure associated with the change

and will be some combination of the two inputs: the probability of an unsound safety

case (meaning the change may not be adequately safe), and the severity of the

consequences of the proposed change. Unless strong arguments against it exist,

assuming the function to be a product is a reasonable starting point. The selection

criterion, a function of risk, is then a hyperbole in the Cartesian plane, or a straight

line if the scales are logarithmic. The diagram below illustrates the logarithmic

approach: if both inputs are assessed on coarse scales (which is inevitable when

involving judgement as inputs), then the result is that the risk posed by a change (the





output of the model) is the sum of the inputs, which is an intuitive measure (distance

from the origin, in a log-log graph).

(2) In practice, the selection process may use a risk matrix in which risk parameters are

represented according to a coarse-grained measurement scheme, and the selection

criteria establishes the boundary beyond which safety cases will be selected for

review, as shown below:

Increasing probability

(of an unsound safety case being developed)

Inc

rea

sin

g s

ev

eri

ty

(of

the

co

ns

eq

ue

nc

es

of

a c

ha

ng

e)

Increasing

Risk

Review

Don’t

Review

Risk posed by

change is ‘significant’

GM2 ATM/ANS.AR.C.035(b)(1) Decision to review the notified change

OTHER SELECTION CRITERIA

(a) The selection criterion for review may deviate from a simple threshold on the scalar risk

metric (distance from the origin), to deal with concerns due to the coarse grain and high

uncertainty of the inputs. For instance, a separate threshold on the ‘severity’ axis may be

used to specify, for instance:

(1) that changes with very high potential severity should always be reviewed, irrespective

of the probability of the safety case being unsound (Figure 1 below). This criterion

may well respond to common perceptions and could be justified by the fact that

judgements of low probabilities based on limited information are often unreliable, and

errors in the judgment of risk are proportional to the error on probability and the size

of the loss; and

(2) that changes with minor potential severity need not be reviewed, irrespective of the

probability of the safety case being unsound (Figure 2 below) (though the process

may retain the option for the CA to review the change, since the estimate itself of

potential severity may be suspected of being erroneous).

(b) It is also possible that deviations be required on the basis of some of the component factors

that affect either probability or severity, e.g. exempting changes based on small size of

change and high competence of the ATS provider.

(c) In order to validate the process or provide data for the evolution of the process, it may be

advisable to randomly select changes to review and then assess whether the safety case is





sound or not and whether or not the case would have been selected for review using the

current criteria for the selection process.



Inc

rea

sin

g s

ev

eri

ty

(of

the

co

ns

eq

ue

nc

es

of

a c

ha

ng

e)

Increasing

Risk

Review

Don’t

Review

Risk posed by


Figure 1: Criteria that may be used when severity is high



Inc

rea

sin

g s

ev

eri

ty

(of

the

co

ns

eq

ue

nc

es

of

a c

ha

ng

e)

Increasing

Risk

Review

Don’t

Review

Risk posed by


Figure 2: Criteria that may be used when severity is low





AMC/GM to ANNEX III — Common requirements for service providers

(Part-ATM/ANS.OR)

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

GM1 ATM/ANS.AR.C.035 & ATM/ANS.OR.A.045 General

INTERACTIONS BETWEEN SERVICE PROVIDERS AND COMPETENT AUTHORITIES DURING THE

CHANGE PROCESS

For a description of interactions between service providers and competent authorities during the

change management process, please refer to GM1 ATM/ANS.AR.C.035 &

ATM/ANS.OR.A.045 General in AMC/GM to ANNEX II — Requirements for competent authorities

— Service provision and network functions (Part-ATM/ANS.AR).


ATS.OR.205 General


For a description of changes to functional systems and examples and their assessment, please

refer to GM1 Annex I Definitions (35) & ATM/ANS.OR.A.045 & ATM/ANS.OR.C.005 &

ATS.OR.205 General in AMC/GM to ANNEX I — Definitions of terms used in ANNEXES II to XIII.

AMC1 ATM/ANS.OR.A.045(a) Changes to the functional system

GENERAL

(a) A service provider should notify its CA of all changes proposed by the provider itself or

stemming from the impact of any other change proposed by another service provider or by

another regulated or unregulated body that affect the following:

(1) the functional system under the managerial control of the service provider; or

(2) the way the services of the service provider behave.

(b) A service provider should submit the notification of changes in a manner agreed between

the provider and the CA. Until an agreement is reached, the CA will prescribe the means of

submission. In any case, the notification means should be legally binding.


NOTIFICATION DATA

The notification of a change is not considered complete until the following information is provided:

(a) Name of the organisation notifying the change;

(b) Unique identifier of change;

(c) Version number of notification;

(d) Title of the change;

(e) Date of the submission of the original of this change notification;

(f) Scheduled date of entry into service (even if only approximate);

(g) Change description;

(h) Entity in charge of the assurance case; and

(i) Identity of a point of contact for communications with the CA.





GM1 ATM/ANS.OR.A.045(a) Changes to the functional system

NOTIFICATION DATA

(a) A change should be notified as soon as the data defined in AMC2 ATM/ANS.OR.A.045(a) is

available. The decision to review a change by the CA will be based, in most circumstances,

on the notification data. Exceptions to this are cases where the CA is not familiar with the

type of change or the complexity of the change requires a more thorough consideration.

(b) Early and accurate notification facilitates the interactions between the provider and the CA

and, thus, maximises the likelihood of introducing a change into service in due time and

according to the service provider’s initial schedule when the CA has decided to review an

assurance case. Therefore, it is advisable that the change description identified in AMC2

ATM/ANS.OR.A.045(a) is completed as soon as possible and contains the following data:

(1) Purpose of the change;

(2) Reasons for the change;

(3) Place of implementation;

(4) New/modified functions/services brought about by the change;

(5) High level identification of the constituents of the functional system being changed,

and what is modified in their functionality;

(6) Other service providers affected by the change identified (and informed) in accordance

with ATM/ANS.OR.A.045(a)(3);

(7) Other aviation undertakings e.g. airport, a/c operators, power energy providers, a/c

manufacturers and maintenance organisations, affected by the change, identified (and

informed) in accordance with ATM/ANS.OR.A.045(a)(3); and

(8) Consequence of the change.

(c) The information provided in (b) may speed up the decision whether to review or not the

proposed change because it will allow the CA to gain complete knowledge of the change

and, consequently, reduces the need for additional information. However, lack of some of

this data should not delay the service provider submitting the notification if to do so is likely

to impede the introduction of the change. It should be noted that early interaction with its

CA may help to complete the missing data.

(d) The service provider should take into account that an early, clear, and accurate change

notification will assist the CA in making the decision to review or not the change and may

prevent such inconveniences as:

(1) the CA having to ask for more information about the change, as a necessary precursor

to identifying the additional information it will seek in order to make its decision as

required in ATM/ANS.OR.A.045.(a)(2);

(2) the CA deciding to review a change unnecessarily because the notification is not clear

enough; or

(3) the delay in the CA deciding whether to review a change, caused by the lack of

information, having an impact on the proposed date of entry into service.

(e) It is recognised that the understanding of the change will improve as the change process

progresses, and the interaction between the CA and the ATM/ANS strengthens. An update of

the notification is required when the information provided in the previous notification is no

longer valid or when the information previously missing becomes available. When additional





information — other than the data specified in AMC2 ATM/ANS.OR.A.045(a) — is supplied at

the CA’s request, then no update of the notification is required.

(f) For ATS providers, the consequences of the change specified in (b)(9), should be expressed

in terms of safety risks as the result of a preliminary safety assessment, if available. For

service providers other than ATS providers, the consequences should be expressed in terms

of criticality of the change, e.g. what aspects of the performance of the service are impacted

by the change.

(g) The point of contact, as required in field 9 of the table in AMC2 ATM/ANS.OR.A.045(a),

provides a focal point for the CA when seeking complementary information about the

change when required. The aim is to improve communications between the provider and the

CA about the change.

(h) All notified changes should be unambiguously identified. The service provider and its CA

should agree on a means of referencing so as to associate a unique identifier to a given

notified change.


ROUTINE CHANGES

(a) Some changes may not necessarily need to be reviewed providing they fulfil certain criteria

defined by the CA. These changes may include, for example, changes that, even though

they relate to safety, can be considered as routine by the provider as they have been

consistently assessed, implemented and proved safe in the past and, therefore, the CA has

sufficient confidence that the provider will address them in a similar manner. The service

provider has to keep a record of these changes and the notification to the CA may be done

in a simpler manner, e.g. using forms less detailed as specified in

AMC2 ATM/ANS.OR.A.045(a) or notifying these changes collectively after being

implemented at regular periods of times agreed between the provider and the CA.

(b) A service provider and its CA should coordinate so as to reach a common agreement on

these types of changes that may not be reviewed by the CA. The list of such changes should

be documented and formalised.


MEANS OF NOTIFICATION

(a) There are different means of notifying changes to the CA. An appropriate means has to be

selected and agreed with the CA, which depends on various parameters such as:

(1) the size of the service provider;

(2) the number of changes it undertakes;

(3) the type of changes that are likely to be notified; and

(4) the way the CA and/or the service provider is (are) organised.

(b) The following cases are given as examples and are not, by any means, exhaustive.

(1) Individual notification

The service provider notifies the CA of each change it plans to undertake as soon as a

substantial part of the ‘notification data’, as defined in AMC2 ATM/ANS.OR.A.045(a), is

available.





This type of notification is usually well-suited for:

(i) small service providers; or

(ii) service providers undertaking a small number of changes; or

(iii) service providers for which change notification is directly undertaken by the

individual operational units.

The CA has to respond to each notification in order to inform the service provider

which changes are going to be reviewed and which are not, if any.

One of the advantages of this notification means is that the CA can start the review

decision process early.

(2) Periodic notification

The service provider notifies changes to the CA on a regular basis, for instance on a

quarterly basis. The service provider notifies the changes it has planned during the

previous period. The notification consists of a list of changes and their associated

notification data transmitted by the means agreed with the CA.

This type of notification is well-suited for:

(i) large service providers; or

(ii) service providers undertaking a significant number of changes; or

(iii) service providers that have a specific entity dealing with the management of

changes and that can centralise the notifications for the operational units.

The CA has to respond to each notification in order to inform the service provider

which changes are going to be reviewed and which are not, if any. The periodic

notification allows the CA to produce one single answer listing the changes subject to

review, facilitating the response process.

Month n-2 Month n-1 Month n

Change 2 is planned

Change 1 is planned

Change 3 is planned

Change 4 is planned

Notification of change 1








In addition, the periodic notification allows the CA to organise periodic meetings to

collectively review the list of changes and make an appropriate decision if they will be

reviewed or not.

(3) Short lead time notifications

When notification occurs close to the scheduled date of entry into service, the service

providers and the CA may make the appropriate arrangements to allow individual

notifications to be submitted out of the periodic notification period so as to be able to

deal with changes on time. This type of short lead time notification is a departure from

the periodic notification procedure and should be duly justified with valid reasons.

These deviations should be exceptional and not become the norm, otherwise the

service provider and the CA should agree on amending the change management

process.

The ATS provider may submit an explanation of the impact on safety and other service

providers may submit an explanation of the impact on performance that a delayed

entry into service would have, compared to the initial planned date to allow the CA to

balance the safety risk of not reviewing the change with the business and/or safety

risk of delaying the entry into service of the change due to its review.

Whatever the type of notification used by the service provider, short lead time

notifications have to be tagged so that they can easily be spotted by the CA. This may

be done adding the following fields to the notification data listed in AMC2

ATM/ANS.OR.A.045(a):

10 Short Lead Time Notification

1 The reason why the change was not notified earlier to the CA.

2 The safety impact of not implementing the change at the initially

planned date of entry into service, i.e. due to the likely delay

introduced by a review by the CA. For ATS providers, a risk-

based argument justifying the timing of the change and

explaining the safety consequences of a possible delay in the

entry into service should be provided. Note that a potential delay

might not have any safety consequences.

That way, the CA knows that the time frame will be tight if it chooses to review the

associated change. A specific means of notification such as a direct phone call to a

pre-determined point of contact can be useful for this kind of notifications.

The short lead time notification process is particularly suitable when the periodic

notification process is used. For example, on the basis of a monthly notification, a

change which is decided by the service provider at the beginning of the month and

planned for the middle of the next month would be notified to the CA only two weeks

before its planned date of entry into service.






REGISTER OF NOTIFIED CHANGES

The service provider should keep a single centralised register of the records of all notified

changes. The register should include:

(a) the status of the implementation of the change, i.e. planned, under review, under

implementation, implemented, or cancelled;

(b) the notification;

(c) (a link to) the location of the actual record, including a reference to all information passed

to the CA as part of ATM/ANS.OR.A.045(a)(2).

In addition, when the changes are selected for review, the register should also include:

(a) the review decision from the CA; and

(b) a link to records of the change approval by the CA.

GM4 ATM/ANS.OR.A.045(a) Management of change to a functional system

REGISTER OF NOTIFIED CHANGES

It is advisable that the fields of the notification form are searchable in the register.

GM5 ATM/ANS.OR.A.045(a) Management of change to a functional system

EXAMPLE OF NOTIFICATION FORM FOR AN AERODROME FLIGHT INFORMATION SERVICES (AFIS)

PROVIDER

AFIS change notification form

[To be filled in as soon as the requested information is known.]

Month n-2 Month n-1

Change 1

planned

Notification of change 1 to the CA

(using the monthly notification process)

Planned date entry into

service

Month n

Time for the decision to

review and to execute the

review (periodic

notification case)

Notification of change 1 to CA

(using the ‘short lead time notification’ process)

Time for the decision to review

and to execute the review

(individual notification case)





[If needed, insert more guidance here for the use of this notification form]

1. CHANGE IDENTIFICATION Version: Vx.y

[Title and reference number specific to the change]

[The form version has to be incremented for any data update concerning the notification]

[Example: AFIS_xxx_CHGT-1234 ‘title’- V1.1]

2. CHANGE SUMMARY

Entity assuring

project

management for

this change:

(and responsible

for the decision for

its entry into

service)

AFIS

Other entity [Precise which entity: other ANSP, aerodrome operator, military

organism, airspace users, ,etc.]

Change

description

[Indicate here:

- The reasons for having decided the change

- Description of the change and its components:

o Technical systems (HW, SW)

o Human factors (trainings, competency, HMI, etc.)

o Procedures (working methods, ATS procedures, maintenance

procedures, etc.)

- Interfaces of the change :

o with the ATM/ANS functional system managed by the AFIS

o with the remainder of the ATM/ANS functional system (other ANSP, etc.)

o with external entities (aerodrome operators, etc.)

Scheduled date of

entry into service

3. POINT OF CONTACT

Identity of a person to contact in case further information is needed

Name/function :

Phone(s) :

E-mail :

AMC1 ATM/ANS.OR.A.045(a)(3) Changes to the functional system

NOTIFICATION TO USERS OF THE SERVICE

When informing other service providers and aviation undertakings potentially affected by the

change of a planned change, the service provider proposing the change should:





(a) address the notification individually to all known service providers and aviation

undertakings; and

(b) publish the proposed change in a dedicated publication of the service provider.

GM1 ATM/ANS.OR.A.045(a)(3) Changes to the functional system

DEDICATED PUBLICATION FOR PROPOSED CHANGES

The final users of services potentially affected by a change to a functional system may not be

known by the service provider proposing the change. However, this should not prevent the

provider from seeking notification using other means than direct communication with the

interested parties. In that case, the changes may be published in a dedicated site where the

users of the service can periodically check for current proposed changes to the functional system

that may affect them. For example, the service provider may dedicate a website to publish the

notifications.

AMC1 ATM/ANS.OR.A.045(b) Changes to the functional system

MODIFICATION OF A NOTIFIED CHANGE

(a) The service provider proposing a change should update the notification data when the

information provided in previous notification about the same change is no longer valid or

when the information previously missing becomes available. The service provider should

inform the other service providers and aviation undertakings of this update, when they are

affected by the new data, and competent authorities that were initially informed about the

change.

(b) The cancellation of a previously notified change is considered a modification of a notified

change. Therefore, the service provider should notify this update to the competent

authorities, and inform other service providers and aviation undertakings that were initially

informed about the change.

AMC1 ATM/ANS.OR.A.045(d) Changes to the functional system

ENTER OPERATIONAL SERVICE OF A CHANGE SELECTED FOR REVIEW

Where the CA has decided to review the assurance case of a proposed change, the service

provider should not start the implementation of any part of the change that has the potential to

affect the functionality or performance of the service until it has been approved by the CA.

GM1 ATM/ANS.OR.A.045(c); (d) Changes to the functional system

TRANSITION INTO OPERATION

Even where the CA has not decided to review the assurance case of a proposed change, the

service provider should not start the implementation of any part of the change that has the

potential to affect the functionality or performance of the service until it has produced a valid

assurance case in accordance with either

ATS.OR.205(d) or ATM/ANS.OR.C.005(d) as appropriate. For a complete description of the

different transitions of a change into operations, see GM1 ATM/ANS.AR.C.035 &

ATM/ANS.OR.A.045 General in Annex II.

GM2 ATM/ANS.OR.A.045(c); (d) Changes to the functional system

CHANGES IMPLEMENTED PRIOR TO RECEIVING APPROVAL

Some changes might stem from the need to implement immediate action and, therefore, their

implementation cannot be delayed until they receive approval or communication that the change

is not being reviewed from the CA. Examples of these changes are changes due to urgent





unforeseen circumstances122 that would, if uncorrected, lead to an unsafe condition e.g. presence

of volcanic ash. The service provider is in any case responsible for the safe provision of the

service.

GM1 ATM/ANS.OR.A.045(e) Changes to the functional system

CHANGES AFFECTING MULITPLE SERVICE PROVIDERS AND AVIATION UNDERTAKINGS —

GENERAL

(a) Any change proposed by a service provider as defined in AMT/ANS.OR.A.045(a) affects

other service providers and/or aviation undertakings when:

(1) the proposed change may alter the service delivered to other service providers and

aviation undertakings as users of that service; or

(2) the proposed change may alter the operational context in which the services of other

service providers and aviation undertakings are delivered or in which the aviation

undertakings are operating.

(b) The changes referred in AMT/ANS.OR.A.045(e), are those changes that require coordination

to be implemented due to the presence of dependencies between the service providers that

planned the change and other affected service providers and/or other aviation undertakings.

The coordination is essential to ensure a correct safety assessment when there are

dependencies.

(c) The following is a list of examples of changes affecting multiple service providers and/or

undertakings, which is not necessarily complete:

(1) any coordinated set of changes proposed by several service providers to their

functional systems, where the ultimate purpose of the change is a shared objective of

all the stakeholders involved in the change. For instance, within a Functional Airspace

Block (FAB) two neighbouring ATS providers agree to re-design completely their

respective adjacent airspace to move the departure flows from two main airports

(each one served by each provider) reducing interference of traffic flows, improving

efficiency and increasing the throughput of both airports;

(2) any change to a functional system of a service provider that affects how the service

behaves and has a potential impact on the service provided by a different service

provider to the end user. For instance, a MET provider seeks to improve its efficiency

and reduce cost by fully automating the weather observations, production of MET

aeronautical reports, e.g. METARs, and its delivery to the ATS provider at airports.

This change will have implications for the ATS service provided at the airports because

the ATCOs will have to be re-trained on certain issues associated with the reports,

such as implications on the accuracy of observations, interpretations of automatic

observations, or backup procedures to deal with sensor failures. The implication of the

effects of the new report (i.e. the information, the delivery, and the new procedures)

will require a safety assessment by the ATS provider, potentially involving the airport

operator too;

(3) any change to a functional system of a service provider that has a potential impact on

the context in which services are provided by a different service provider, even where

both service providers do not share any service. For example, an ATS provider

122 These circumstances are not foreseen in the design and, thus, not considered either in maintenance processes or in

contingency plans. For example, corrective repairs of equipment malfunction must be considered in the designed and procedures to deal with them included in the maintenance processes. They are not changes that require notification.





introduces a new approach procedure in the airspace near another ATS provider’s

airspace where initially there are no interactive procedures between the providers.

This new approach procedure close to the other provider’s controlled airspace may

impact the other ATS provider’s services by, for example, increasing the number of

intrusions into the other ATS provider’s airspace. A coordinated safety assessment is

required between both providers;

(4) any change to the functional system of an ATS service provider that may affect

exclusively the a/c operators that use its delivered services and require coordination

with a/c operators to ensure that the service provider is able to implement the change

as intended. For example, to ameliorate the noise impact of arrival approaches at a

certain airport, the ATS provider serving the airport seeks to introduce new arrival

procedures utilising continuous descent operations and, thus, avoid the conventional

stair-step approaches. The envisaged continuous descent operation requires the usage

of a ground automation tool that advises, via data-link, pilots and ATCOs where and

when to initiate the descent in order to resolve separation conflicts while satisfying

time-based metering constraints at destination. The need to evaluate the effects of the

changed information on the operation of the a/c needs to be assessed by the a/c

operators. In order to implement the change, the a/c operators need to agree on the

training of pilots and implement, if needed, changes to the on-board equipment that

manage the information uplinked, so as to ensure that the change works in the way

intended by the design;

(5) any change to the functional system of a service provider that may affect an

aerodrome operator. For example, an ATS provider decides to balance the use of

runways at a certain airport in order to balance the noise impact on the areas

surrounding the airport (this may be required by local or national regulatory

authorities through requirements on the ATS provider). The new balance may result in

changing the active runway more often than the wind conditions would require. This

will have an effect on the taxiing flows at the airport, and potentially an effect on

runway incursions and excursions. Evaluating the effects must be coordinated with the

airport operator and local airlines.

GM2 ATM/ANS.OR.A.045(e) Changes to the functional system

AFFECTED STAKEHOLDERS — SERVICE PROVIDERS AND AVIATION UNDERTAKINGS

(a) Other service providers included in AMT/ANS.OR.A.045(e) refer to European service

providers other than the service provider proposing the change, that are regulated in

accordance with Regulation (EC) No 216/2009 and its Implementing Rules;

(b) Aviation undertakings affected by the change included in AMT/ANS.OR.A.045(e) can be

understood as the stakeholders with dependencies with the changed service, and may

include the following:

(1) service providers that do not fall under the remit of Regulation (EC) No 216/2008 and

its Implementing Rules e.g. non-European service providers;

(2) aerodrome operators;

(3) a/c operators;

(4) military authorities;

(5) airframe and equipment manufactures;

(6) maintenance organisations;





(7) European regulatory bodies, e.g. European Commission, EASA; and

(8) other bodies not regulated by Regulation (EC) No 216/2008 and its Implementing

Rules, e.g. power supplier organisation, staff associations, or passenger associations;

GM1 ATM/ANS.OR.A.045(e)(1) Changes to the functional system

CHANGE AFFECTING MULITPLE SERVICE PROVIDERS AND AVIATION UNDERTAKINGS — FORMS

OF DEPENDENCIES

(a) Dependencies can be of two forms: unidirectional dependencies and bidirectional

dependencies, i.e. interdependencies.

(b) Unidirectional dependencies always exist between a provider of a service and its users. The

way the users behave relies on the properties of the service, and in that sense the user is

dependent on the provider. There are two types of unidirectional dependencies:

(1) Direct: This is the dependence that exists between the provider of a service and its

users when the service is delivered directly.

(2) Indirect: There may be indirect dependencies between a provider and the end user if

there are other providers in between.

(c) In this context, the term interdependencies is to be understood as the relationship between

two or more stakeholders where each stakeholder is dependent upon the other.

Interdependencies are bidirectional dependencies. For example, in the simplest case, where

a single service provider delivers a service to a single (type) of aviation undertaking, an

interdependency exists when the service provided by the service provider depends on the

behaviour of the aviation undertaking. This may cause, for example, changes in the context

in which the service is provided. In other cases, involving several service providers and

aviation undertakings, the identification of interdependencies is more complex, and,

therefore, it is more important to identify them as they may not be immediately obvious for

the service provider proposing the change.

(d) In addition, the notion that there are interdependencies may suggest that the service

provider proposing a change will not be able to implement it unless the affected service

providers and aviation undertakings have implemented changes themselves, if required,

and, therefore, the alignment and agreement of assumptions and risk mitigations among

those affected is paramount.

(e) The notion of dependencies and interdependencies is depicted in Figure 1. The figures do

not contain all possible situations but just the most representative ones in order to make

the notion of dependencies and interdependencies clearer.





Notional Depiction Description

Unidirectional

dependency

Direct

Interdependency

(bidirectional

dependency)

Series of

unidirectional

dependencies123

Indirect

interdependency

(example). The

aviation undertaking

has an indirect

interdependency

with service

provider A. It is also

depicted a direct

interdependency

between the

aviation undertaking

and service provider

123 The aviation undertaking may be indirectly dependent on the service provided by service provider A.

Text

ATM/ANS provider – A(plan change)

Service

OperationalContext


Text


OperationalContext

Service

Affects


Text

ATM/ANS provider - BOperational

Context

ServiceText


Service

OperationalContext


Text

ATM/ANS provider - BOperational

Context

Service

Affects

Text


Service

OperationalContext






Notional Depiction Description

B

Indirect

interdependency

(example). Service

provider A has an

indirect

interdependency

with service

provider B. This is

because a change in

service provided by

A may affect the

behaviour of a/c

operator (an

aviation

undertaking), which

in turn may affect

the context in which

service provided by

B is delivered, and,

thus, may affect the

context and the

service of service

provider A.

Figure 1: Notional depiction of examples of dependences

(f) In complex systems, as the ATM system is, the complexities of interactions and

dependencies mean that the effects of a change on any part of the system may not be

readily visible to the initiator of the change. In order to identify all effects due to

interactions and dependencies, all affected service providers and aviation undertakings need

to work together. The identification of dependencies and interdependencies becomes

essential to determine the scope of the change and the extent of the assessment and

assurance activities required.

(g) When a change, as defined in AMT/ANS.OR.A.045(e), involves a single service provider but

affects other aviation undertakings, the assumptions and risk mitigations need to be agreed

with all parties. This is best accomplished by a coordinated assessment involving all those

parties. However, whilst recommended, this is not required by this Regulation. The service

provider should as a minimum seek confirmation that the assumptions, related to the

behaviour of the aviation undertakings, it is making are valid and also seeks their

agreement on any mitigations for risks that affect these undertakings, in accordance with

AMT/ANS.OR.A.045(f)(2).

(h) When interdependencies exist, the change to the service may create new or modified

interactions that affect services not apparently related to the change, e.g. a change to the

form of communications, such as datalink, may increase pilot workload to the point where

there is an increased number of potential conflicts for ATC to resolve thus having a negative

impact on navigation. In turn, this would increase the messages between controllers and

Affects


Service

ATM/ANS provider - B

Service

OperationalContext

Affects

OperationalContext





pilots, which may have an impact on the communication service. For this reason, it is

important that all interactions are analysed before the change is implemented to identify

those that may be altered as a result of the proposed change.

(i) When interdependencies exist, the change to the service may cause a reaction by the CA,

which in turn causes a change to the practices used in the environment, e.g. a change in

the nature of an ATM/ANS service might change the regulatory context for all other air

transport stakeholders, which may in turn affect the way they behave in the environment.

(j) Service providers affected by the change need to cooperate in order to identify the

interdependencies. The identification of dependencies is, on the other hand, a more straight

forward exercise.

(k) The apparent absence of interdependencies does not automatically imply that the change

does not affect multiple actors. There may be direct and indirect unidirectional dependencies

impacting multiple service providers that require coordination. For example, a change to a

functional system that affects the service used by another service provider, which in turn

affects the service delivered to a/c operators.

(l) Trying to identify all dependencies, even in simple cases, it is more likely to be successful if

carried out in a cooperative manner with all affected parties than if carried out by individual

service providers. Dependencies and, above all interdependencies, can be subtle and this

coordination may help uncover them more efficiently, thus, resulting in a more successful

identification of affected services and functional systems. This will result in a correct

identification of the scope of the change.

AMC1 ATM/ANS.OR.A.045(e)(3) Changes to the functional system

CHANGES AFFECTING MULITPLE SERVICE PROVIDERS — OVERARCHING SAFETY ARGUMENT

A change as defined in AMT/ANS.OR.A.045(e) may involve more than one service provider

changing their functional systems. In this case, the change will consist of a set of changes to

different ATM/ANS functional systems or their context. However, no matter how many individual

changes to service providers’ functional systems are part of the change, they should be

coordinated. An overarching safety argument, coherent with the arguments of the individual

changes, that claims the complete change is safe should be provided.


CHANGES AFFECTING MULITPLE SERVICE PROVIDERS — EXAMPLE OF OVERARCHING SAFETY

ARGUMENT

(a) The overarching argument, stating a complete change (i.e. a change that comprises

changes to functional systems of several service providers or several contexts) is acceptably

safe, can be provided in various forms. For illustrative purposes, an example of a particular

approach, which is by no means unique, is presented. Other forms of organising the safety

arguments may be also valid, provided the complete change is covered.

(b) Two ATS providers are providing services in two different but neighbouring airspaces. ATSP

A decides to make a change to its functional system that has an impact on the environment

in which the service is provided, which in turn impacts the operating context in which ATSP

B provides its services (because their operating contexts interact). As a consequence, it is

identified that ANSP B has to change its own functional system in order to achieve an

acceptably safe service in its context of operation. ATSP A can only argue about the safety

of the service it provides in the part of its operating context (A) where there is no

interaction with the operating context of ATSP B. Similarly, ATSP B can only argue about the

safety of the service it provides in the part of its operating context (B) where there is no





interaction with the operating context of ATSP A. In the interface (and surroundings) where

both contexts overlap and there are interdependencies between the ATSPs, the safety

argument can only be produced when there is full cooperation between the providers, e.g.

setting up a coordination team. Consequently, this cooperation generates a common

overarching safety argument. The way the arguments are built and in which safety cases

they are included is irrelevant, as far as the coordinated safety assessment is performed.

The following is a non-exhaustive list of ways in which this overarching argument can be

presented:

(1) In an overall safety case that uses two separate safety cases from ATSP A and ATSP B

(see Case ‘a’ in Figure 2);

(2) As part of the safety case of ATSP A, as initiator of the change (see Case ‘b’ in Figure

2);

(3) As part of a single safety case that argues about the combined changes of both ATSPs

(see Case ‘c’ in Figure 2)

Case ‘a’

Overarching safety argument

Safety argument

(Operating

Context A)

Safety argument

(Operating Context

B)

Coord Team

ATSP A ATSP B

Overarching

safety argument

Safety argument

(Operating Context A)

Safety argument

(Operating Context B)

Coord

Team

ATSP A ATSP B

Safety Case

Responsible personnel





Case ‘b’

Case ‘c’

Figure 2: Notional depiction of examples of dependencies


CHANGE AFFECTING MULITPLE SERVICE PROVIDERS AND AVIATION UNDERTAKINGS —

COORDINATED SAFETY ASSESSMENT

(a) The provisions in AMT/ANS.OR.A.045(e) apply to all the affected service providers involved

in the change, and, therefore, they must participate in a coordinated assessment, as

required by AMT/ANS.OR.A.045(e)(3), and agree and align the assumptions and mitigations

that are jointly related to them as required by AMT/ANS.OR.A.045(e)(4).

(b) Assumptions and risk mitigations used during the assessment of the change that are not

shared by the affected service providers can be handled independently by each service

provider.

(c) A coordinated assessment should imply that the affected service providers:

(1) have jointly identified the scope of their responsibilities with regard to the change, and

in particular their safety responsibilities, e.g. what part of the change will be covered

in whose safety (support) assessment case;

(2) have jointly identified the dependencies;

(3) have jointly identified the hazards associated with the change in the common context;

(4) have mutually agreed on the assumptions for the change that affect each provider and

those assumptions that jointly relate to them; and

(5) have mutually agreed on the mitigations for risks each provider is supposed to

implement and those mitigations for risks that require joint implementation.

(d) Service providers would need to achieve a common understanding about:

(1) consequences in the shared operational context; and

(2) chains of causes/consequences.

(e) Service providers would jointly need to identify their dependencies to be able to assess the

change to their functional systems.

(f) Where necessary in relation to the interdependences identified in accordance with GM1

AMT/ANS.OR.A.045(e)(1), the service providers may do together:

Overarching safety argument

Safety argument

(Operating Context A)

Safety argument

(Operating Context B)

Coord

Team

ATSP A

ATSP B





(1) identification of hazards/effects;

(2) assessment of risks;

(3) evaluation of risks;

(4) planning and assessment of risk mitigations; and

(5) verification.

(g) The level of interaction and coordination between service providers and aviation

undertakings will vary depending on the particular needs of the change at hand.


CHANGE AFFECTING MULITPLE SERVICE PROVIDERS AND AVIATION UNDERTAKINGS —

ASSUMPTIONS AND RISK MITIGATIONS

In order to seek mutual agreement and alignment, the assumptions and risk mitigations that

affected service providers should determine those that relate to:

(a) more than one service provider;

(b) a service provider and one or more aviation undertakings; or

(c) multiple service providers and aviation undertakings.

GM1 ATM/ANS.OR.A.045(f)(2) Changes to the functional system

ALIGNMENT AND AGREEMENT WITH AFFECTED AVIATION UNDERTAKINGS

(a) The provisions in AMT/ANS.OR.A.045(e) do not apply to aviation undertakings that are

affected by a change as described in GM1 AMT/ANS.OR.A.045(f)(2). However, any affected

service provider should seek the participation of aviation undertakings when assumptions

and risk mitigations used in the safety (support) assessment are shared with the affected

aviation undertakings.

(b) The feasibility mentioned in the provisions of AMT/ANS.OR.A.045(f)(2) refers to the fact

that this Regulation does not apply to aviation undertakings and, therefore, there are no

means of enforcement available to make them participate in the alignment and agreement

of assumptions and risk mitigations. This is because, were it not so, any affected service

providers who, even though they have tried to align and agree the assumptions and risk

mitigations with affected aviation undertakings, could not do so, would have infringed the

Regulation.

(c) If an aviation undertaking decides not to cooperate, the service provider affected by the

change, including the originator of the change, needs to consider the impact of having the

assumptions and risk mitigations not agreed with the related aviation undertakings. They

should propose a way forward by :

(1) making the assumptions themselves and providing evidence that supports them;

(2) adding additional mitigating measures so that the change remains acceptably safe;

and

(3) modifying the scope of the change, or even reconsidering and cancelling the change.

In addition, the service provider proposing the change may want to inform the CA about

those aviation undertakings that are not participating and their form of non-participation as

required in AMT/ANS.OR.A.045(f)(2), to seek the assistance of the CA in trying to persuade

the aviation undertaking to participate.





(d) When the number of aviation undertakings affected by the change is large, the service

providers may not need to involve every individual stakeholder. If a body can represent the

views of a group of affected aviation undertakings, it may suffice to involve that

representative body to obtain the supporting evidence to move forward with the assessment

of the change.

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

GM1 ATM/ANS.OR.B005(a)(5) Management system

IDENTIFICATION OF CHANGES

This process is the main driver within the change identification process that is used by the service

provider to correctly identify proposed changes. The changes are proposed changes to the

functional system and can be triggered internally by changing circumstances that are related to

the provider of concern or externally by changing circumstances that are related to others or to

the context, i.e. in situations where the provider does not have managerial control over them.

(a) Identification of internal circumstances

The procedure to identify changes needs to be embedded in all parts of the organisation

that can modify the functional system, i.e. the operational system used to support the

services provided. Examples of proposed changes to the functional system as response to

changing circumstances under the control of the organisation, therefore, include:

(1) changes to the way the components of the functional system are used;

(2) changes to equipment, either hardware or software;

(3) changes to roles and responsibilities of operational personnel;

(4) changes to operating procedures;

(5) changes to system configuration, excluding changes during maintenance, repair and

alternative operations;

(6) changes that are necessary as a result of changing circumstances to the operational

context under the managerial control of the provider that can impact the service, e.g.

provision of service under new conditions;

(7) changes that are necessary as a result of changing circumstances to the local physical

(operational) environment of the functional system; and

(8) changes to the working hours and/or shift patterns of key personnel which could

impact the safe delivery of services.

These changes are often identified by the service provider using business processes, which

will be used to identify changes planned for the medium and long term. Such processes can

include:

(1) annual business plans;

(2) strategic safety boards;

(3) equipment replacement projects;

(4) airspace reorganisation plans;

(5) introduction of new operational concepts, e.g. RVSM; and

(6) accident and incident investigation reports.





(b) Identification of external circumstances

The service provider should have processes in place to react appropriately to notifications

received from those service providers that supply services to them. In addition, changes to

the context that can impact the service provided and are not under the managerial control

of the service provider should be identified and treated as potential triggers. Furthermore,

the service provider should negotiate contracts with unregulated service providers in

accordance with ATM/ANS.OR.B.015(f) ‘Contracted activities’ that place a responsibility on

such organisations to inform them of planned changes to their services.

AMC1 ATM/ANS.OR.B.010(a) Change management procedures

GENERAL

(a) The procedures, and the modification of the procedures, used by a service provider to

manage changes should cover the complete lifecycle of a change.

(b) The service provider should show that the procedures address all the actions and all the

evidence needed in order to comply with the requirements laid down in ATM/ANS.OR.A.045,

ATS.OR.205, ATS.OR.210, and ATM/ANS.OR.C.005. For that purpose, the service provider

should use a compliance matrix, which shows:

(1) which part of a procedure addresses which part of the Regulation (i.e. article of the

Implementing Rule); and

(2) a rationale explaining how the procedures demonstrate compliance with the

Implementing Rule.

(c) The service provider should ensure that the roles and responsibilities for the change

management processes are identified in the procedures.

(d) Procedures should be submitted in a manner agreed between the service provider and the

CA. Until an agreement is reached, the CA will prescribe the means of submission.

(e) The procedure that defines the notification process for changes includes:

(1) the point of contact in charge of the notification of changes, e.g. person, or part of the

organisation and the role;

(2) the means used for notification, e.g. fax, email, mail, use of database, or others.

(f) The management of change procedures (ATM/ANS.OR.B.010(a)), should include a change

identification procedure. This procedure, which is a precursor of the change notification

process, should seek out potential changes, confirm that there is a real intent to implement

them (propose the change) and, if so, initiate the notification process.

GM1 ATM/ANS.OR.B.010(a) Change management procedures

GENERAL

(a) The scope of procedures spans the identification of proposed changes to the approval of the

change, as well as the monitoring criteria to ensure that the change will remain acceptably

safe as long as it is in operation. The monitoring of the change is part of the activities

related to the management system of the service providers, but it is not covered by the

change management procedures themselves. The procedures that manage changes to

functional systems do not include the process to identify the circumstances that will trigger

the change. This is part of the management system (see ATM/ANS.OR.B.005(a)(5)).

However, the procedures that manage changes to functional systems do include the

identification of the scope of the change, i.e. the identification of what parts of the

functional system are to be changed.





(b) The change management procedures should address the following:

procedural-oriented content, which details:

(i) the roles and activities with regard to change management, safety assessment,

and safety support assessment;

(ii) the identification of the parts of the functional system affected by the proposed

change;

(iii) the type of safety assessment or safety support assessment that has to be used

for the identified type of changes;

(iv) the competence of the persons performing change management, safety

assessments and safety support assessments;

(v) the identified triggers for undertaking a safety assessment and a safety support

assessment;

(vi) the means124 of change notification;

(vii) the means of identifying any organisations or aviation undertakings using the

service potentially affected by the change; and

(viii) the means of informing those identified in (vii).

(i) methodology oriented content, which details description of the safety assessments and safety

support assessments methodologies and mitigation methods used by the service provider.

(c) A service provider and its CA should coordinate so as to reach a common agreement about

guidance on when modifications of an already approved procedure are not considered

material, and, therefore, does not require a new notification and/or approval. This guidance

will detail criteria to consider whether a modification of an already approved procedure

either:

(1) requires a new approval before use;

(2) requires only notification; or

(3) does not need to be notified.

(d) For each change management procedure or part of a change management procedure

approved, the agreement on notification of any change over them should be documented

and formalised. In any case, the service provider should keep records of these changes.

124 ‘Means’ include the form of notification.






EXAMPLE OF COMPLIANCE MATRIX FOR CHANGE MANAGEMENT PROCEDURES APPROVAL

The following is provided as an example of a compliance matrix in which the service provider shows the compliance status of their change

management procedures, i.e. those required by AMC1 ATM/ANS.OR.B.010(a).

Service provider [Name of the provider]

Provided services ATS: C: N: S: MET: AIS: DAT: ASM: ATFCM:

Date MM/DD/YYYY

Version of the form Vx.y

Submitted procedure(s)

Procedure « XYZ » - version « a.b » of the MM/DD/YYYY

Procedure « JKL » - version « c.d » of the MM/DD/YYYY

[…]

Requirement in

regulation

Acceptable Means

of Compliance Procedure Rationale Status Competent Authority

comment

ATM/ANS.OR.A.045(c) None Procedure « JKL » -

version « c.d » - §4

§4 states that the transition into

operation of any functional change will

occur following the completion of the

activities required by the procedures

XYZ, MNO, and ABC

Non-

approved To be assessed

ATM/ANS.OR.A.045 (d) AMC1 ATM/ANS.OR.A

.045 (d)

Procedure « XYZ » -

version « a.b » - §3

§3 stresses that a change subject to

CA review should not be allowed to be

put into service before formal approval

has been granted.

Approved None






LIASON WITH THE COMPETENT AUTHORITY

A service provider may liaise with the CA before submitting new complex change management

procedures or before significant modification to an existing and previously approved change

management procedure, so as to be able to explain the critical issues related to the procedures

and the rationale for them.

AMC2 ATM/ANS.OR.B.010(a);(b) Change management procedures

MODIFICATION OF PROCEDURES AND DEVIATIONS FROM PROCEDURES

When the CA has approved a modification to the procedure, the service provider should use the

modified procedure for all new applications of the procedures. However, when the CA has

approved a deviation of the procedure for a specific change, the service provider should use the

deviation only for that change.

SUBPART C — SPECIFIC ORGANISATIONAL REQUIREMENTS FOR SERVICE

PROVIDERS OTHER THAN ATS PROVIDERS (ATM/ANS.OR.C)



For a description of different responsibilities for safety between an ATS provider and other types

of service providers, please refer to GM1 Annex I Definitions(35) & ATM/ANS.OR.C.005 &



ATS NAVIGATION PLAN — VIEW OF SAFETY

For a description of an ATS provider’s responsibilities for safety, please refer to GM2 Annex I

Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General in AMC/GM to ANNEX I —

Definitions of terms used in ANNEXES II to XIII.


ATS.OR.205 General


For a description of changes to functional systems and examples, and their assessment, please

refer to GM1 Annex I Definitions (35) & ATM/ANS.OR.A.045 & ATM/ANS.OR.C.005 &


GM1 ATM/ANS.OR.C.005(a)(2) & ATS.OR.205(a)(2) General

SAFETY SUPPORT CASE AND SAFETY CASE125

(a) The key concepts used in safety and safety support assurance and the terms used to

describe them126 are given in the table below:

125 The terminology used here to describe the functional system is explained in GM1 Annex I Definitions(35) The

terminology used here to describe the results of the assurance activities is explained in GM1 ATM/ANS. OR.C.005 Safety Support Assessment and Assurance. Where reference is made to either a safety case or a safety support case (depending on the circumstance) it will be referred to as an assurance case.

126 Where reference is made to either a safety support case or a safety case or both, the term ‘assurance case’ is used.





Safety Support Safety

Safety

support

assurance

Argues that the service

behaves only as

specified127 in the

specified context.128

Safety

assurance

Argues that the proposed

change to the functional

system is acceptably

safe.

Safety

support case

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 case A structured documented

argument, supported by

a body of evidence that

provides a compelling,

comprehensible and valid

justification that a

system is acceptably safe

for a given application in

a given operating

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 CA requires for

the evaluation.

Safety case

report

The safety case report for

a change will identify the

arguments (claims,

inferences and evidence)

of the safety 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 ATS

provider is obliged to

facilitate access to any of

this additional

information that the

regulator CA requires for

the evaluation.

Safety

support

assessment

All the activities required

to produce a safety

support case, i.e. all the

activities defined in

ATM/ANS.OR.C.005.

Safety

Assessment

All the activities required

to produce a safety case,

i.e. all the activities

defined in ATS.OR.205.

Assurance

case

The collective noun used for either safety cases or safety support

cases.

Assurance The collective noun used for either safety case reports or safety

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.





case report 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.

(b) Model of an Argument

Fact (probably) Conclusion

Warrent

Backing

Rebuttal

Rick has fair skin, red

hair and freckles and

he sunbathed all day

yesterday.

People with fair skin,

red hair and freckles

usually get sunburnt

easily

Those people have little

melanin in their skin.

Melanin protects

against sunburn.

Rick will probably get

seriously sunburnt.

Rick’s parents both

have fair skin, red hair

and freckles and they

never seem to get

sunburnt however

much they sit outside.

Figure 1: The general form of an argument

The general shape of arguments129 consists of grounds, claims, warrants, backing, qualifier

and rebuttal. Claims, as the name suggests, are assertions put forward for general

acceptance. The justification for the claim is based on some grounds, the ‘specific facts

about a precise situation that clarify and make good the claim’. Next, the basis of the

reasoning from the grounds (the facts) to the claim is articulated. This is referred to as a

‘warrant’, which are ‘statements indicating the general ways of arguing being applied in a

particular case and implicitly relied on and whose trustworthiness is well established’. The

basis for the warrant may be questioned and here the notion of backing for the warrant is

introduced. The confidence in the claim may also be questioned and here the notion of a

qualifier is introduced, e.g. phrases such as ‘probably’, ‘possibly’ or ‘certainly’ may be used

to temper or vary the confidence apparent in the claim. Finally, there may be evidence or a

further argument that the warrant may not in fact be true in all circumstances. In such

cases, it is said that the claim has been rebutted which is shown a ‘rebuttal’ on Figure 1.

(c) An assurance case is, in general, the argument that the provider of a service makes to

demonstrate that the service meets pre-ordained criteria (the claim) with an acceptable

level of confidence. It is analogous to the case that the service provider may have to make

to a court following a serious challenge to the integrity or efficacy of the service.

(d) The assurance case is an argument, its general form is illustrated below. In this diagram:

(1) a claim is an assertion that something is true;

129 Put forward by Toulmin in one of the first formal analyses of arguments - Toulmin's The Uses of Argument, 1958.





(2) evidence is the available body of facts or information indicating that the claim is true.

The evidence may be directly related to the claim (‘Facts’ in Figure 1) or may be

related to the warrant (‘Backing’ in Figure 1).

(3) An inference130 is the basis of the reasoning linking the evidence (‘Facts’ or ‘Backing’ in

Figure 1) to the claim. It is equivalent to the warrant in Figure 1

Inference

Inference

Inference

Inference

Inference

Inf

eren

ce

Claim

Evidence

Evidence

Evidence

Evidence

Argument

Figure 2: The general form of an assurance case

(e) More properly, since evidence can be replaced by a lower level argument, an assurance

case is an argument that contains a hierarchy of arguments, culminating in a single claim131

as illustrated below:

130 Note that inference replaces warrant from the general form of an argument because the definition of inference is more

suitable to the written form of argumentation used in assurance cases. 131 For a safety case, this is that the system is acceptably safe and its risk is as low as is reasonably practicable. For a

safety support case, this is that the service meets its specification in a given context and does nothing else.





Inference

Inference

Inference

Inference

Inference

Inf

eren

ce

Claim

Evidence

Evidence

Evidence

Argument

Inference

Claim

Evidence

Evidence

Evidence

Argument

Argument

Figure 3: The assurance case as a hierarchy of arguments

(f) The symbols used represent parts of the argument that are provided in the form of

narrative text (claims & inferences) combined with data/facts (evidence) taken from many

sources. In simple cases, all this may be contained in a single document. However, in any

reasonably sized assurance case the data will be extensive. Consequently, an assurance

report is usually produced, which is a document that contains the argument structure in

sufficient detail such that all the narrative and data that form a part of the assurance case

may be unambiguously located. It is often the case that notations based on the diagram

above are used as an index into the narrative of the assurance case and the data/facts used

to support the claims made. Therefore, an assurance report can be thought of as an index

for the assurance case.

(g) It is not possible to give guidance on the complete structure of a change assurance case

because it depends on the circumstances of the change and the strategies used to argue the

case. This is deliberately so as it allows for the necessary flexibility in arguing in novel

circumstances such as those likely to be found when introducing SESAR concepts of

operation.

(h) Since an argument contains a hierarchy of arguments, it follows that any of these

arguments may be treated independently of the others and may, therefore, come from any

source providing that the claim is valid in the context of its use. For example, there may be

an argument about the behaviour of part of a proposed change, perhaps specifically related

to a general piece of equipment or some common concept, which has already been

assessed and generated by someone other than the service provider planning the change.

The evidence for this argument can come from any source and may be re-used in the

assurance case provided it is valid and the context in which it is going to be used matches

the context in which it was produced.

AMC1 ATM/ANS.OR.C.005 Safety support assessment and assurance of changes to the

functional system

GENERAL





Service providers other than ATS providers should ensure that the safety support assessment is

carried out by personnel adequately trained and competent to perform safety support

assessment.

GM1 ATM/ANS.OR.C.005 Safety support assessment and assurance of changes to the

functional system

GENERAL

(a) Service providers other than ATS providers, i.e. AIS, MET, CNS, ASM, ATFM, DAT, can affect

the safety of the flight through the functions or services they provide, e.g. directly to pilots

or indirectly via ATS providers132, but this will always be influenced by the way in which they

are used. However, since these providers are not responsible for how their functions or

services are used, they cannot say whether that use will be safe or not, but they can say

the service they provide behaves as specified. In other words, they cannot assess the safety

impact of a change of their services, but they can only assess if their services comply with

the stated specifications. These providers must comply with the requirements of the

Implementing Rule and make an assessment of any changes to their functional systems,

but the type of assessment they are able to undertake is necessarily different from those

produced by ATS providers. This different type of assessment has been termed a ‘safety

support assessment’ in the rule and relates to the behaviour of services (rather than their

use for flight navigation and control which is not within the responsibility of the provider

making the change). This behaviour refers to such properties as function, accuracy,

availability, continuity, timeliness, reliability, confidence, integrity, etc.

(b) If a service provider other than an ATS provider, e.g. AIS, CNS, MET, ATFM or DAT,

provides services directly to an a/c without involving an ATS provider, then the provision of

a safety assessment is outside the scope of this Implementing Rule, because it is the end

user of the service (i.e. the pilot or the operator) who should undertake a safety

assessment. However, a safety support assessment is required in that case to ensure that

the service behaves only as specified. In these circumstances, the safe use of the service is

either the responsibility of the airline, a/c operator or the pilot.

(c) Service providers producing a safety support assessment need to assess what impact the

changes to their functional systems will have on the functionality and performance of the

services they provide. This impact is defined in the specification of the changed service. The

context in which this specification is valid is defined in the context specification. The results

of a safety support assessment are, therefore, the safety support assurance argument133,

the specification of the changed service and the context specification. The specification of

the changed service and the context specification should be made available to any service

provider or other body or person that wishes to use the changed service.

(d) If a service provider uses a function or service provided by another service provider, the

user must assess whether any changes made to the service that it uses affects the way the

132 The term ‘ATS provider’ is used here only to describe those service providers that control a/c and excludes those that

only provide information. 133 The safety support assurance argument is contained in a safety support case. The terminology and guidance on

assurance arguments is provided in GM1 ATM/ANS.OR.C.005(a)(2) & ATS.OR.205(a)(2) General. The terms ‘safety case’ and ‘safety support case’ will be used from now on to refer to the documentation associated with a safety argument and safety support argument respectively.





ATM/ANS service it delivers behaves. This assessment134 must take into account the results

of any associated safety support assessments.

(e) A safety assessment or a safety support assessment can be supported by one or more

safety support assessments, e.g. a chain of services (Figure 1) or a tree of services (Figure

2).

Figure 1: Example of a chain of services

(f) In Figure 1 above, when the Navigation Data Provider proposes a change, it will perform a

safety support assessment and develop a safety support case. It will supply a safety support

case report to the Navigation Provider. If the safety support case report shows that the

service provided is unchanged, then no further action is required. However, if the service

provided is changed, then the Navigation Provider must also perform a safety support

assessment. If the Navigation provider’s safety support case report shows that its service is

unchanged, then no further action is required by the Air Traffic Service Provider. This is the

only case where a safety support case will be produced without there being an associated

safety case. However, if the service provided is changed ,then the Air Traffic Service

provider must produce a safety case to describe the effects of the change on its air traffic

services.

134 The assessment may either be a safety assessment or safety support assessment, depending on whether the service

provider that uses the service is an ATS provider or not, respectively.

TextSeparationService

Text


SystemRules &

Procedures

Air Traffic Service Provider

Serv

ice

Text

OperationalContext

OperationalContext

Service

OperationalContext

Text


SystemRules &

Procedures

Navigation Data Provider

Serv

ice

OperationalContext

OperationalContext

Text


SystemRules &

Procedures

Navigation Provider

Serv

ice

OperationalContext

OperationalContext

Nav ServiceDat Service

Regulated service

Unregulated service

Independent organisations





Figure 2: Example of tree of services

(g) In Figure 2 above, the Surveillance provider and the Navigation provider will supply safety

support case reports to the ATS provider, who will take them into account in the safety case

report it produces for the ATS it provides. When several safety support case reports are

used in a safety assessment (or another safety support assessment), the interdependencies

between the different services must have been assessed135.

(h) If a safety support assessment and a safety assessment are performed in the same

organisation, it could either be done separately or together as part of the safety

assessment. In this case, the scope of the safety assessment must cover the whole change.

(i) Changes to the functional system of a service provider, other than an ATS provider, may be

proposed by either itself or at the request of a customer, e.g. another service provider. The

interactions involved in both cases are illustrated below. In the first case, the customer has

to check that their requirements have been satisfied. In the second case, the customer has

to design a change that will accommodate the change in the way that the service provided

behaves, given the limitations of the declared context of evaluation, i.e. those stated in the

context specification.

(j) Case 1:

If the user of a service requests a change to the service delivered by a service provider,

other than an ATS provider, the safety support case is used to demonstrate that the user’s

requirements are met or have been modified to reflect what can be delivered.

(1) In the diagram labelled Case - 1 below, an ATS provider has requested a change from

another service provider. The requirements for the change (Component

135 The interdependencies between multiple safety support arguments and the safety case reports that use them are

described in GM1 ATM/ANS.OR.A.045(e)(1) Changes to the functional system.

Surveillance

Provider

Nav Provider

Text

Operational

Context

Nav Service

Text

Text

Operational

Context

SeparationService

Surveillance Service

Functional

System

Functional

System

Functional

System

ATS Provider

Operational

Context

Independent organisations





Requirements136 137) are written by the ATS provider and given to the other service

provider along with the specification of the context in which the component or service

will be used (Component Operational Context). However, both the ATS provider and

the service provider making the change must remember that any proposed change

must still comply with the requirements of other regulations that may proscribe and

prescribe the way the service behaves, therefore, having an impact on the change.

Such requirements may come from the requirements for the services included in

Annexes V to Annex XIII to this Regulation, in Regulation (EC) No 552/2004 and in

other more general standards published by ICAO, CEN/CENELEC/ETSI or guidance

published by EUROCAE.

Having developed the component or service, the other service provider will assess the

component or service and assure itself that the Component Requirements are satisfied

over the Component Operational Context. It can then write down the arguments for

assurance in the safety Support Case.

(2) However, initially, the other service provider may not be able to achieve the

functionality or performance required138. In this case, the safety support assessment

would fail (and so would the safety assessment fail if it were to be performed at this

stage). In order to achieve a successful change, either the component or service will

have to meet the requirements of the ATS provider139 or the ATS system will have to

change in order to accommodate the functionality and performance that can be

achieved by the component or service. Consequently, the differences between the

functionality and performance achieved and that required by the ATS provider are

discussed (Differences) and agreement reached as to whether the component or

service will change or the ATS functional system will be changed.

(3) If the component or service is to be modified, then the differences will disappear and

the safety support case can be completed.

(4) If the ATS system is to be changed to accommodate the actual functionality and

performance of the component or service, then the ATS provider will have to change

the Component Requirements and possibly the Component Operational Context.

However, since the Component Requirements will now match the functionality and

performance that can be achieved by the component or service, then the differences

will disappear and the safety support case can be completed.

(5) In both cases, the safety support case can now be used by (added to) the safety case.

136 Bracketed terms refer to items on the diagrams. The term ‘step’ used on the diagrams refers to the process being

described in the relevant section, i.e. Step 2 refers to the process described in paragraph (k)(2). 137 Some of these will be safety requirements. 138 Alternatively, the other service provider may wish the service to do more than is required. 139 In other examples, the customer may be a service provider other than an ATS provider.





Figure 3: The relationships between ATS and non-ATS providers during a change

affecting the services provided by a non ATS provider

(k) Example 1

(1) For instance, when an ATS provider wants an additional data field to be added to the

data it gets from a MET provider, the safety support case along with the specification

and the operational context is used by the ATS provider to assure itself that its

requirements are met or have been modified to reflect what can be delivered by the

MET provider.

(2) The requirements for the change to the MET data (Component Requirements) are

written by the ATS provider and given to the MET provider along with the specification

of the interface to be used to deliver the data (Component Operational Context).

Having developed the additional data field, the MET provider will assess it and assure

itself that the ATS provider’s requirements are satisfied over the Component

Operational Context. It can then write down the arguments for its assurance in the

safety support case, which will then be used in developing the ATS provider’s safety

case.

(3) However, the MET provider may not be able to achieve the update frequency required,

i.e. there will be differences (Differences) between what can be achieved and what is

required. In order to achieve a successful change in these circumstances, the ATS

functional system will have to be changed in order to accommodate the lower update

frequency. If the ATS system can be changed to accommodate the lower update

frequency of the MET service, then the ATS provider will have to change the MET data

ATSP - System Development

ATM / ANS provider other than an ATSP - Component / Service Development

Component / Service

Operational Context

Component / Service

Requirements

Differences

Verifies

Are satisfied over

( Add safety support case to safety case )

( Step 5 )

Safety Support Case

ATM / ANS provider

Development ( Functional

System )

ATS Development ( Functional

system )

Changes Additional functionality Failure to satisfy requirements

in given context

Changes

Success

Case – 1 Component / Service is developed as a

result of a request from ATSP

Components of the functional system are : hardware , software , people , or procedures .

Safety Case Uses

Change ATS System ( Step 4 )

Failure Change

Component / Service ( Step 3 )

F a i l u r e Safety Assessment

Step 1

Step 1

Step 2

Steps 3 &





requirements (Component Requirements) and possibly the interface to be used to

deliver the data (Component Operational Context) to record the new design intent.

(4) Alternatively, if the ATS functional system cannot be changed, it may still be possible

to modify the MET Functional system so that it does fulfil the original requirements.

However, this may incur some additional cost and delay. In this case, the differences

(Differences) between the performance that can be achieved by the MET functional

system and what is required by the ATS provider will disappear.

(l) Case - 2:

Service providers, other than ATS providers may independently elect to make changes to

their functional systems or change them as a consequence of a change to a standard or rule

that is pertinent to the service they are providing. The key rules that might require such

changes are identified in the requirements for the services included in Annexes V to Annex

XIII to this Regulation and in Regulation (EC) No 552/2004. It is also possible that changes

to other more general standards published by ICAO, CEN/CENELEC or ETSI, or guidance

published by EUROCAE, which have to be complied with, may trigger the change. Where a

service provider, other than an ATS provider, makes such an unsolicited change to its

functional system, it uses the safety support case to confirm that the specification of the

proposed changes to the service provided is valid, where ‘valid’ means that the specification

correctly specifies the way the service behaves and that it complies with and does not

contradict any requirements placed on the service by another part of the regulations e.g.

both rules and necessary standards.

The service provider may have proposed the change in order to sell the service to a number

of current and new end users. In these circumstances, he cannot know the full context of its

use. The safety support case must, therefore, clearly state the context within which the

service was evaluated and ensure that the service does not behave in any other way than

that which is stated in the specification.

(1) In the diagram labelled Case - 2 below, an ATS provider is already using a component

or service provided by another service provider. The other service provider wishes to

change that component or service. A safety support case will be produced showing

that the specification of the changed component (Component Specification) is satisfied

over some context (Evaluation Context) that the other service provider assumes will

be representative of the context of use for the component or service.

(2) In order to use the component or service the ATS provider has to show that it can

develop safety requirements that match (Match ?) the specification of the changed

component or service. It also has to show that the operational context for the service

is the same as (Match ?) the context the other service provider used in the safety

support assessment for the component or service (Evaluation Context). The ATS

provider may find that it cannot perform a valid safety assessment because either the

Safety Requirements do not match the Component Specification or the contexts are

different (Evaluation Context does not match the Operational Context for the

component or service). It could also be because the safety support case does not

provide sufficient confidence in the performance of the component in order for it to be

used in the manner foreseen by the ATS provider.

(3) In the case where the matching of specification to requirement fails or the matching of

the contexts fails, the ATS provider may need to alter the ATS system in order to use

the component or service in its changed form. In so doing, the requirements (Safety

Requirements) will be changed, the context in which the component or service is used





(Operational Context) will be changed or both will be changed. This will allow a valid

safety assessment to be performed and the safety case including the safety support

case to be created.

(4) Where there is insufficient confidence in the component or service, the ATS provider

may either change the ATS functional system such that the component or service can

be used safely or can ask the other service provider140 to increase the depth of

evaluation, i.e. change the Evaluation Context, in order to improve the level of

assurance as argued in the safety support case.

(5) In both cases, the safety support case can now be used by (added to) the safety case.

Figure 2: The relationships between ATS and non-ATS providers during a change

affecting the services provided by a non ATS provider

(m) Example 2:

(1) For instance, when a Surveillance provider wants to change the format of the data

fields it provides to an ATS provider, e.g. from UK CAA format to ASTRIX format, the

safety support case is used to demonstrate to the ATS provider that the data will be

delivered as specified (Component Specification) over the interface to be used to

deliver the data (Evaluation Context). It should be noted that such changes will not be

limited to adopting new publically available standards or regulations. The service

provider may elect to introduce new features, of their own design, to the service that

140 Or perform a deeper evaluation itself or ask a third party to do so.

Component/

Service

Specification

Evaluation

Context

Operational

Context

(component/

service)

Failure Failure

Match ?

Match ?

assures

are valid

over

is valid

over

Change

System

Additional

Evalution

Success

ATSP - System DevelopmentATM/ANS provider other than an ATSP

- Component/Service Development

Safety Support

case

assures

Safety case

Safety

Assessment

Uses

Case – 2

Component/Service is developed independently of ATSP

but ATSP wishes to use it

(Add safety support case

to safety case)

(Step 5)

Changes

ChangesStep 1

ATM/ANS

provider

Development

(Functional

System)

ATS

Development

(Functional

system)

Steps 1 & 4

Step 1

Step 2

Safety

Requirements

(component/

service use)

Step 2

Step 2

Step 2

(Step 3) (Step 4)





is provided in the hope that it will provide a commercial competitive advantage or in

response to demands made by other service providers.

(2) Having developed the provision of the new data format, the Surveillance provider will

assure itself that the Surveillance data is delivered as specified (Component

Specification) in the new format over the interface to be used (Evaluation Context).

The Surveillance Provider will then write down the arguments and provide the

evidence for this assurance in the safety support case, which should then be used in

developing the ATS provider’s safety case.

(3) The ATS provider now needs to establish whether or not changes in the Surveillance

data format (Component Specification) or the interface to be used (Evaluation

Context) are compatible with their existing system, e.g. the Radar Data Processor can

already accept either format. In this case, the new component specification matches

(Match ?) the safety requirements and the Evaluation Context matches (Match ?) the

Operation Context

(4) However, the ATS provider may not be able to fully accommodate the change in the

data format within its existing system, i.e. the Surveillance provider’s Component

Specification no longer matches the ATS provider’s Safety Requirements or the

Evaluation Context no longer matches the Operational Context. In order to achieve a

successful change in these circumstances, the ATS functional system will have to be

changed in order to match the new data format and interface. If the ATS system can

be changed to accommodate the new Surveillance data format, then the ATS provider

will have to change its Safety case to reflect any changes in Safety Requirements and

interface (Operational Context) made as a consequence of the changed Surveillance

service.

GM2 ATM/ANS.OR.C.005(a) Safety support assessment and assurance of changes to

the functional system

PROVISION OF SAFETY SUPPORT ASSESSMENTS BY COMPOUND PROVIDERS

Service providers other than ATS providers should perform safety support assessment for any

changes that they propose to make to their functional systems or for any changes that will be

made to the context in which their services are provided and will affect the way those services

behave. Guidance on the need to carry out safety support assessment is given below for

organisations that consist of more than one provider.

(a) Only ATS providers can perform a safety assessment. If an ATS provider uses a service

provided by a service provider, other than an ATS provider, and both are within the same

organisation, a safety assessment can also be performed. Service providers other than ATS

providers cannot be responsible for or perform a safety assessment for the use of their

services. Service providers other than ATS providers can only perform a safety support

assessment to determine that the new or changed service behaves only as specified in a

specified context.

(b) Safety support assurance must be carried out by a service provider, other than an ATS

provider, for changes to the way the ATM/ANS services that cross the organisation’s

boundary behave.

(c) If the organisation chooses not to perform a safety support assessment for changes to its

internally delivered ATM/ANS services, i.e. ones that do not cross the organisation’s

boundaries, the effect of the changes on the services that cross the organisation’s boundary

must be included in an assessment of those services.





(d) In some cases, it may be seen to be of commercial benefit for safety support cases to be

produced by a service provider, other than an ATS provider, for changes to the ways the

services it provides internally behave, i.e. ones that do not cross the organisation’s

boundary and, therefore, do not require a safety support assessment.

GM3 ATM/ANS.OR.C.005(a)(1) Safety support assessment and assurance of changes

to the functional system

SAFETY SUPPORT ASSESSMENT

(a) A safety support assessment is needed141 whenever the functional system of a service

provider other than an ATS provider changes. This may be as a result of:

(1) the provider proposing a change to:

(i) its functional system;

(ii) the services it provides;

(iii) the context in which its functional system operates; or

(iv) the context in which the service is provided;

(2) the services used by the provider in the delivery of its services are planned to change;

or/and

(3) a change to the context in which the service provider’s functional system operates as

a result of a proposed change by another service provider, another organisation

regulated by the EASA Basic Regulation or an unregulated body.

(b) The size of the safety support case report will depend on:

(1) the scope of the change;

(2) the nature and number of arguments; and

(3) the necessary and sufficient evidence needed to provide appropriate confidence that

the safety support assurance is valid (complete and correct).

If there is sufficient data to show that the service behaves as specified in a given context, a

safety support assessment can be very small. In these cases, it could be a few sheets of

paper.

141 For an explanation of why this is the case, see GM1 Annex I Definitions(35) & ATM/ANS.OR.C.005 &

ATS.OR.205 General.





(c) Examples of changes where assessments should be performed:

Service

being

changed

Characteristics of planned

change

Safety support

assessment to address

Safety

assessment142 143

to address

NAV

provider

changes

Introduction into service (or

modification) of an ILS CATIII on

a controlled aerodrome

For the quality and the

way that the ILS signal

behaves, installation and

maintenance of the ILS,

definition of the critical

areas, etc.

For the impact on

the ATSP, the

definition of LVP in

the OPS manual,

the training of the

ATCOs)

Introduction into service (or

modification) of a VOR on an

uncontrolled aerodrome (used

only for instrument approach)

Required (cf. VoR) N/A

New software release for

mitigating the ionospheric

perturbation on the EGNOS SoL

service

Required Required if there is

an impact on the

ATSP services (and

in particular when

the quality of the

SoL service is

degraded)

Replacement of a satellite for the

broadcast of the SoL EGNOS

service (in order to have a more

robust SIS)

Required Required if there is

an impact on the

ATSP services (and

in particular when

the quality of the

SoL service is

degraded)

Increase/decrease of the span of

the EGNOS SoL service area

Required Required

COM

provider

changes

New radio and/or telephone

system any entity providing air

traffic control services

Required Required

Introduction of datalink services Required Required

Modification of the type of

emission/reception

aerials/equipment with no change

in the frequencies used by the

ATSP and no degradation of the

coverage

Required N/A

142 Safety assessments are only necessary if the ATSP is using the changed service. 143 ‘Safety assessment’ is used here within the context of the ATM/ANS IR. It is not intended to mean a general form of

safety assessment such as would be performed by others, e.g. pilots prior to flight.





Service

being

changed

Characteristics of planned

change

Safety support

assessment to address

Safety

assessment142 143

to address

SURV

provider

changes

Evolution of a Mode A/C radar into

a Mode S radar

Required Required

Replacement of the radar tracking

and monitoring software system

Required Required (but not

necessarily if the

ATCO HMI and the

way that the

tracking system

behaves are not

impacted)

Setup of ADS-B in a non-radar

area

Required Required

MET

provider

changes

Replacement of visibility meters

by new ones of a different brand

but that behave in the same way

Required N/A

Modification of the tool used to

produce and broadcast ‘significant

weather charts’

Required N/A

Setup of cloud ceilometers on a

controlled aerodrome

Required Required (if the

cloud base height

information was

not available to the

ATCOs before)

AIS

provider

changes

Modification of the NOTAM

production and publication tool

Required N/A

Setup of a new WGS84 server for

ADQ-IR compliance

Required N/A

Any change to the tools used to

produce the AIP (AIC, IAC, AIP

Sup, etc.) with no change to the

format and content itself

Required N/A

ATFM

provider

changes

New version of the CIFLO

(Collaborative Interface for Flow

Management Positions) used by

the FMP position of an ACC and

provided by the network manager

Required from network

manager for the provision

of the new version

Required from

ACCs for the use of

the new version





AMC1 ATM/ANS.OR.C.005(a)(2) Safety support assessment and assurance of changes


FORM OF ASSURANCE

(a) Service providers, other than an ATS provider, should ensure that the assurance required

by ATM/ANS.OR.C.005(a)(2) is documented in a safety support case.

(b) A safety support case shall be an argument that provides a compelling, comprehensible and

valid justification that the system behaves only as specified in a given context. The

argument shall consist of claims that are supported via inferences by a body of evidence.



SPECIFICATION

‘Continues to be behave only as specified in the specified context’ means that assurance needs to

be provided that the monitoring requirements of ATM/ANS.OR.C.005(b)(3) are suitable for

demonstrating, during operation, that the argument remains valid, i.e. the service behaves only

as specified in the specified context during operation.



ASSURANCE LEVELS

The use of assurance level concepts, e.g. design assurance levels (DAL), software assurance

levels (SWAL), hardware assurance levels (HWAL), human assurance levels (HAL), procedure

assurance levels (PAL), might be helpful in generating an appropriate and sufficient body of

evidence, which in turn may help to establish the required confidence in the argument.



COMPLETENESS OF THE ARGUMENT

The argument shall be considered to be complete when it shows that:

(a) the safety support assessment of ATM/ANS.OR.C.005(b) has produced a service

specification and context specification where:

(1) the service has been defined in terms of functionality, performance and the form of

the interfaces;

(2) the specification of context correctly and completely records the conditions under

which the specification of the service is true;

(3) the interaction of components, under failure conditions or failures in services delivered

to the components have been assessed for their impact on the service and where

necessary degraded modes of service have been defined; and

(4) the specification encompasses all interaction with the environment;

(b) safety support requirements have been placed on all elements affected by the change;

(c) the behaviour necessitated by the safety support requirements is the complete behaviour

expressed by the service specification;

(d) all safety support requirements have been traced from the service specification to the level

of the architecture at which they have been satisfied;





(e) each component satisfies its safety support requirements; and

(f) the evidence is derived from known versions of the components and the architecture and

known sets of products, data and descriptions that have been used in the production or

verification of those versions.




Besides completeness, the argument must provide sufficient confidence that the change is

sufficiently trustworthy.

(a) Sufficiency of specifications

The way the service specification is arrived at is not of particular interest in a safety

support case. However, it does imply that the service meets the providers intent, i.e. it is

valid.

(1) Assessment of failure conditions

(i) Failures or failure conditions are malfunctions of behaviour. This means either

the loss or corruption of some behaviour e.g. behaviour that is considered to be:

(A) more than (quantity, information);

(B) less than (quantity, information);

(C) additional to;

(D) faster than;

(E) slower than;

(F) part of;

(G) reverse of;

(H) other than;

(I) not;

(J) earlier than;

(K) later than;

(L) before; or

(M) after

that which was intended. This is further explained in the GM on degraded modes

of operation (GM1 ATM/ANS. OR.C.005(b)(1) & (2)).

(ii) Some failures may not result in a degraded service.

(iii) Some failures may not be relevant in the context of use.

(iv) Strictly, the failure and failure conditions described here are malfunctions of the

services delivered by a component and may be caused by failures of

components, errors in design or failures of services used by the component.

(v) When a redundancy within a component is no longer available, the behaviour of

the component is considered to have changed, e.g. the reliability of the





component will have changed and an indication of the loss of redundancy

provided.

(2) Interaction with the environment

It is necessary to argue that the behaviour of the implementation, i.e. the system as

built, matches the specification and there is no additional (unspecified) behaviour. This

implies verification of service behaviour, which is required by

ATM/ANS.OR.C.005(b)(2) and stated here in a more specific way.

(b) Safety support requirements

(1) Safety support requirements are requirements whose implementation will affect the

context of operation144. However, if it is hard to argue that a valid requirement is not a

safety support requirement, it may be better to treat it as a safety support

requirement.

(2) In the terminology used within this GM, requirements are design artefacts that lead to

an implementation, while specifications are the result of verifying an implementation

in a given context. Consequently, when verified and no difference is found between

the observed behaviour and the required behaviour of the system, the requirements

become the specification.

(3) The highest level safety support requirements represent the desired behaviour of the

change at its interface with the operational context. These, ultimately become the

specification, once the implementation is verified. The important aspects of safety

support requirements are their properties, their relationships, their completeness,

their consistency and their validity.

(4) The way safety support requirements are arrived at is not of particular interest in a

safety support case because a safety support case is the argument for the

trustworthiness of the specification and is not about how the specification was

developed.

(5) The architecture does not have requirements. During development, the need to argue

satisfaction of system level requirements, which cannot be performed at the system

level for any practical system, drives the architecture because verifiability depends on

the decomposition of the system into verifiable elements.

(6) Demonstration that safety support requirements at system level are met allows them

to be transformed into the safety support specification.

(c) Completeness of safety support requirements

(1) The concept underpinning AMC2 ATM/ANS.OR.C.005(a)(2) is that, provided each

element meets its requirements, the system will behave as specified. This will be true

provided (2), (3) and (4) below are met.

(2) The activity needed to meet objective (c) of AMC2 ATM/ANS.OR.C.005(a)(2) consists of

obtaining sufficient confidence that the set of requirements is complete and correct,

i.e. that:

(i) the architectural decomposition of the elements leads to a complete and correct

set of requirements being allocated to each sub-element;

144 The interface to the context of operation is explained in paragraph (b) of GM6 ATM/ANS.OR.C.005(a)(2).





(ii) each requirement is a correct, complete and unambiguous statement of the

desired behaviour, and does not contradict another requirement or any other

subset of requirements; and

(iii) the requirements allocated to an element necessitate the complete required

behaviour of the element in the target environment.

(3) This should take into account specific aspects such as:

(i) the possible presence of functions within the element that produce unnecessary

behaviour. For instance, in the case where a previously developed element is

used, activities should be undertaken to identify all the possible behaviour of the

element. If some of this behaviour is not needed for the foreseen use, then

additional requirements may be needed to make sure that these functions are

not solicited or inadvertently activated in operation;

(ii) element requirements that are not directly related to the desired behaviour of

the functional system. This kind of requirement can, for instance, ask that the

element be developed in a given syntax, or be designed in a certain way. These

requirements often relate to technical aspects of the element. Activities should

be undertaken to ensure that each of these requirements is a correct, complete

and unambiguous statement of the desired effect, and does not contradict

another requirement or any other subset of requirements.

(4) In the context of a service delivered by a service provider, other than an ATS provider,

the complete behaviour is not complete in the sense that it is all possible behaviours

of the service in all possible contexts, but is complete in the sense that the

specification is only true for the defined context. This restriction to the context of the

use of the service makes safety support assessment and assurance of changes to the

functional system a practical proposition.

(d) Traceability of requirements

(1) The traceability requirement can be met by tracing to the highest level element that

has been shown to satisfy its requirements, by verifying it in isolation. It is likely and

completely acceptable that this point will be reached at a different architectural level

for each element.

(e) Satisfaction of safety support requirements

(1) The component view taken must be able to support verification, i.e. the component

must be verifiable — see guidance in (b).

(2) Care should be taken in selecting subsystems that are to be treated as components for

verification to ensure that they are small and simple enough to be verifiable.

(f) Configuration identification

(1) This is only about configuration of the evidence and should not be interpreted as

configuration management of the changed functional system. However, since the

safety support case is based on a set of elements and the way they are joined

together, the safety support case will only be valid if the configuration remains as

described in the safety support case. This guidance has been given in ‘Maintenance of

configuration’ and is provided in GM1 ATM/ANS.OR.C.005(b)(1) & (2).

(2) Evidence for the use of the same component in different parts of the system or in

different systems should probably not rely on testing in a single context since it is





unlikely that the contexts for each use will be the same or can be covered by a single

set of test conditions. This applies equally to the reuse of evidence gathered from

testing subsystems.



SUFFICIENCY OF SAFETY SUPPORT REQUIREMENTS

A valid set of safety support requirements specifies:

(a) for equipment, the complete behaviour, in terms of functions, accuracy, timing, order,

format, capacity, resource usage, robustness to abnormal conditions, overload tolerance,

availability, reliability, confidence and integrity;

(b) for people, their complete expected behaviour and performance in terms of tasks, accuracy,

response times, workload, reliability, confidence, skills, knowledge and personal

characteristics, in relation to their tasks;

(c) for procedures, the circumstances for their enactment, the resources needed, the sequence

of actions to be performed and the timing and accuracy of the actions; and

(d) interactions between all parts of the system.



SUFFICIENCY OF SAFETY SUPPORT REQUIREMENTS

(a) Equipment

The complete behaviour is limited to the scope of the change. Safety support requirements

only apply to the parts of a system affected by the change. In other words, if parts of a

system can be isolated from each other and only some parts are affected by the change,

then these are the only parts that are of concern and so will have safety support

requirements attached to them.

(b) People

(1) The workload is that which would result from someone (with the defined skills,

knowledge and personal characteristics) performing the task in the context of the

provision of an actual operational service and in compliance with the stated accuracy,

response times and reliability. It will have to be shown to be a reasonable workload

given the abilities of those performing the task.

(2) The skills and knowledge required of the people performing the task will normally be

provided for by the selection of and general training provided for different types and

levels of personnel.

(3) The personal characteristics are those required of anyone who is expected to perform

the defined task, i.e. those who have the required skills and knowledge, and do so

within the bounds of the defined accuracy, response times and reliability. These

personal characteristics are:

(i) resilience to distraction;

(ii) self-awareness — the ability to know when they are out of their depth and need

help;





(iii) team ‘playerness’ — the ability to work together with other members of a team

to best resolve abnormal situations (CRM – Behavioural Markers);

(iv) adaptability — the ability to synthesise/innovate when unforeseen things

happen.

(c) Procedures

The resources referred to in GM4 ATM/ANS.OR.C.005(a)(2)(c) are the resources in terms

of the equipment, and the people that are needed to perform the procedure.

GM1 ATM/ANS.OR.C.005(b) Safety support assessment and assurance of changes to


PROCEDURE DEVELOPMENT

If the change modifies the way people interact with the rest of the functional system, then they

will require training before the change becomes operational. People may also need refreshment

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 refreshment

training is part of the maintenance of the functional system after the change is in operation.

AMC1 ATM/ANS.OR.C.005(b)(1) Safety support assessment and assurance of changes


COMPLETENESS OF THE SCOPE OF THE SAFETY SUPPORT ASSESSMENT

The service provider, other than an ATS provider, should ensure that the assessment of the

change includes:

(a) all the components of the functional system that are altered due to the change or whose

inputs or outputs behave differently due to the change;

(b) all the elements in the environment of operations that interact with the components

identified in (a); and

(c) all operational transitions that are part of the change.

GM1 ATM/ANS.OR.C.005(b)(1) Safety support assessment and assurance of changes


COMPLETENESS OF THE SCOPE OF THE SAFETY SUPPORT ASSESSMENT

(a) The description of the elements being changed includes the nature, functionality, location,

performance, maintenance tasks, training and responsibilities of these elements, where

applicable. The description of interfaces and interactions, between machines and between

humans and machines, should include communication means, e.g. language, phraseology,

protocol, format, order and timing and transmission means, where applicable. In addition, it

includes the description of the context in which they operate.

(b) There are two main aspects to consider in evaluating the scope of a change:

(1) The interactions within the changed system.

(2) The interactions within the changing system, i.e. those that occur during transitions

from the current system to the changed system.

As each transition can be treated as a change to a system, the identification of both has a

common approach described below.





(c) The scope of the change is defined as the set of the changed components and impacted

components. In order to identify the impacted components and the changed components, it

is necessary to:

(1) know which components will be changed;

(2) know which components might be directly affected by the changed components and,

hence, identify the directly impacted components;

(3) identify indirectly impacted components by:

(i) identifying new interactions introduced by the changed or directly impacted

components;

(ii) identifying interactions with changed or directly impacted components via the

context.

(4) Further directly and indirectly impacted components will be identified as a result of

applying the above iteratively to any directly and indirectly impacted components that

have been identified previously.

The scope of the change is the set of changed, directly impacted and indirectly

impacted components identified when the iteration identifies no new components.

(d) The context in which the changed service is intended to be provided (see

ATM/ANS.OR.C.005(b)(1)(iii)) includes the interface through which the service will be

delivered to other service providers.

GM1 ATM/ANS.OR.C.005(b)(1)(i) Safety support assessment and assurance of

changes to the functional system

DEFINITIONS

(a) A functional system can be divided into functional subsystems, although system and

subsystem may be used synonymously.

(b) In addition, for brevity and in agreement with normal systems nomenclature, ‘system’ and

‘subsystem’ are used as synonyms for ‘functional system’ and ‘functional subsystem’.

(c) An element can comprise only sub-elements of the same type, i.e. equipment, procedure,

human resource.

(d) An element can be a set or assembly of elements of the same type, e.g. a group of people,

a set of procedures or a collection of equipment.

(e) Elements and sub-elements may be used synonymously.

(f) A system or subsystem can comprise elements of different types.

(g) A subsystem that comprises only either equipment elements, procedural elements or human

resource elements is also an element.

(h) There is no unique way of decomposing systems into subsystems or elements.

(i) A subsystem is viewed/described as a component when, for the current analysis, there is no

interest in its composition, i.e. the subsystems (parts) it consists of.

(1) For example, a control tower may be considered to be a component, where the

analytical view is that of the parts of an airport even though the tower actually

consists of many elements of different types, e.g. the control tower consists of people,

procedures and equipment.





(2) The definition of what is viewed as a component is not absolute, but depends on the

analysis being carried out, i.e. in the hierarchy of the subsystems of a functional

system, a subsystem may be viewed as a component for one analysis and may be

considered to be part of a component for a different analysis.

GM1 ATM/ANS.OR.C.005(b)(1)(iii) Safety support assessment and assurance of


INTERACTIONS

The identification of changed interactions is necessary in order to identify the scope of the change

because any changed behaviour in the system comes about via a changed interaction. Changed

interaction happens via an interaction at an interface of the functional system and the context in

which it operates. Consequently, identification of both interfaces and interactions is needed to be

sure that all interactions have identified interfaces and all interfaces have identified interactions.

From this, all interactions and interfaces that will be changed can be identified.

GM1 ATM/ANS.OR.C.005(b)(1)(iv) & ATS.OR.205 (b)(1)(iv) General

LIFECYCLE OF THE CHANGE FOR EQUIPMENT AND ASSURANCE

(a) The life cycle of the change for equipment can be considered to consist of a number of

phases:

(1) During the design phase, a concept is repeatedly refined until elements are described

that can be built. During the refinement process, elements whose characteristics are

proposed are analysed to show that, given a perfect build, the change will behave as

intended. This design phase may include building models of some of the elements

(particularly software in a host environment) in order to gain confidence that the

design will behave as intended.

(2) At some point there is sufficient confidence in the design to start building the

equipment, i.e. to manufacture the equipment that will be used in service. This

implementation phase consists of building equipment, testing it, usually in isolation,

then integrating it with other pieces of equipment and testing the integration as a

whole.

(3) Testing software on a host that is not part of the final system implementation is

considered to be part of design.

(b) Design assurance, therefore, is argued from the evidence gathered during the development

of elements or their constituent parts. The design assurance demonstrates that constructs

known to be prone to error or constructs for which the behaviour cannot be predicted, are

prevented from being included in the design. Design assurance also demonstrates that only

the design intent will be implemented.

(c) Implementation assurance is argued from the evidence gathered by testing the elements or

their constituent parts.

(d) Evidence about the design of an element is gathered from inspecting and analysing the

design of the constituent parts of the element, e.g. computer programmes, whereas

evidence about the operation of the element is gathered from testing the constituent part,

e.g. software.

(e) Typically, for design assurance and implementation assurance, following industry standards

helps in the gathering of evidence.





GM1 ATM/ANS.OR.C.005(b)(1) & (2) Safety support assessment and assurance of


DEGRADED MODES OF OPERATION

(a) The following guidance deals with the safety support assessment associated with degraded

modes of operation, it, therefore, applies to the safety support assessment of all

components of the functional system (people, procedures, equipment) and includes training

for personnel and the degraded modes of operation of the services delivered by the

functional system. The work involved, described below, is considered to be part of the

safety support assessment of the change and does not require a separate safety support

assessment.

(b) The scope of the change includes all planned degraded modes. Degraded modes occur for

two reasons:

(1) The service behaves incorrectly or is incomplete because of a malfunction; and

(2) The level of the service offered varies due to maintenance activities, i.e. when

repairing the functional system as a result of a malfunction or when trying to prevent

a malfunction.

(c) Malfunctions

(1) The service will at some point malfunction. Malfunctions result in:

(i) loss of function; or

(ii) corruption of the information associated with a service.

Corruptions may be taken as a synonym for unwanted behaviour.

(2) A loss implies that some necessary service or part of a service has become

unavailable. A corruption implies that the system is behaving incorrectly. Both forms

of malfunction unless covered in the specification of the service, would invalidate that

specification.

(d) Planning for degraded modes

(1) In order to be confident that the service will meet its specification, even though

malfunctions occur, all conceivable malfunctions associated with the change should be

identified, assessed and any necessary responses identified, i.e. malfunctions are

foreseen and mitigated145.

(2) Responses will be necessary when the way the service behaves, after the malfunction

has occurred, does not comply with the specification of the normally accepted

service146, i.e. one that is free from malfunctions.

(3) Responses take the form of maintenance and operational procedures that come into

play either periodically or when a malfunction is identified. These are considered

further below. The safety support assessment has to consider these procedures and

show that an appropriate service is still delivered when they are being used and that

during periods of maintenance the way the service behaves is included in the

145 In the case of a safety support, service mitigation is needed to prevent an unacceptable service being delivered.

However, as there is no absolute criteria for what is acceptable and what is not, agreement with users or common sense should be the main guide. For example, it is almost certain that flooding a network with data as a result of a malfunction would be considered to be unacceptable behaviour.

146 The normally accepted service is the service without malfunction. The complete service specification includes the normally accepted service and the service delivered when malfunctions are present.





specification of the changed service. Consequently, these procedures must be shown

to mitigate unacceptable variations in the way the service behaves as a result of the

malfunction, i.e. they need to be proposed, designed, validated, assessed for their

impact on the way the service behaves and their implementation verified.

(4) Note that in mitigating the unacceptable behaviour associated with a malfunction, the

time between the onset of the malfunction and the point at which the maintenance

activity mitigates this behaviour, i.e. it becomes acceptable, may be significant. In

such case, the means of automatically detecting some malfunctions may need to be

designed into the service in order to decrease this time.

(5) Planned degraded modes can, therefore, be considered to be those modes of

operation where maintenance activities are occurring due to the presence or potential

presence of malfunctions and where the variations in the way the service behaves as a

result of the malfunction is considered to be unacceptable.

(e) Maintenance is of three forms:

(1) On condition maintenance — an element within the functional system has failed or will fail

imminently and needs to be replaced with an identical element.

NB: Replacing an element with a different element is a change, it is not maintenance.

(2) Preventive maintenance — the operational performance will degrade sometime in the

future if maintenance is not performed. This may also be called periodic maintenance,

since in order to preserve the future performance of the system it is performed

periodically, usually at regular intervals.

(3) Maintenance of configuration — operational performance and, hence, the validity of

the specification is not assured if an element of the functional system or its

architecture deviates from that which was evaluated during the assessment and

justified in the assurance case.

NB: ‘maintenance’ is not meant to be restricted to ‘technical systems’. It applies to all

the constituents of the functional system : procedures, people and equipment (HW

and SW) and the architecture of the functional system.

(f) On condition maintenance

(1) Maintenance activity results from the detection of the malfunction. In general, the loss

of a function of the service is usually detected when it happens, whereas corruption

may not be detected for some time and then only as a result of an incident occurring.

(2) Prior to the malfunction, the airspace users or other service provider receiving the

services are supported by the full range and capability of the services offered. After

the malfunction is detected and isolated, the range or level of services offered may

necessarily need to be reduced as the functional system, now available, is incomplete.

The diagram below shows how the range or level of services might vary during a

malfunction and the processes through which the malfunction is managed.





Transition to Normal Service

(iv)

Modified Service(iii)

NormalService

NormalService

Transition to Modified Service

(ii)

Malfunction Detected

Malfunction Event

(i)

UndetectedMalfunction

Servicevariation

Process change (work around malfunction)

Note: This variation is unacceptable because it is

inappropriate and unspecified

Time to Repair(Maintenance)

Acceptable variation in the services delivered

(3) It can be seen that the processes following a malfunction encompass the following

phases:

(i) The malfunction occurs, but may initially be undetected;

(ii) The malfunction is detected and the service modified to account for the

malfunction147;

(iii) A modified service is performed while the cause of the malfunction is

investigated and put right; and

(iv) Once the malfunction has been put right, the functional system is restored to its

normal state and the normal service is resumed.

(4) Clearly the way the service behaves does not meet its specification (possibly by a

considerable margin) during the time the malfunction is undetected. It then changes

to an acceptable and specified mode of operation, as the modified service is

introduced. This is unlikely to be instantaneous and in any case does not instantly

change the way the service as a whole behaves, as it will take users of the service

time to adjust the services they offer, or in the case of an a/c user, the way it uses the

service, such that a new, stable and acceptable set of operating conditions exists.

(5) During a malfunction, two kinds of processes will be in use:

(i) The process to identify, isolate, repair and replace the elements causing the

malfunction;

(ii) The operational process needed to mitigate the effects of the malfunction and its

repair and to restore services to their normal levels once the malfunction has

been repaired.

147 Note that in some circumstances the detection of a malfunction may result in an automatic isolation of the faulty part

and indication to the operators that degraded mode operational procedures should be put in place. The physical removal and repair of the faulty part may, therefore, be delayed and does not necessarily coincide with the onset of the degraded mode operational procedures.





(g) Preventative maintenance

(6) In general, mechanical elements, such as radar heads, degrade with use, and will, at

some point, fail. In order to prevent their future failure, these elements are

maintained periodically to restore them to such a condition that they will continue to

operate until the point at which the next maintenance occurs.

(7) During maintenance, the range or level of services offered may necessarily need to be

reduced as the functional system, now available, is incomplete. Consequently, two

kinds of processes will be in use:

(i) The process to isolate and bring back the elements being maintained to their intended

condition and then to return them to operational service; and

(ii) The operational process needed to mitigate the effects of the removal of the elements

being maintained and to restore services to their normal levels once the maintenance

has been completed.

(h) Procedure development

The procedures governing the processes identified in (f) and (g) above, i.e. those associated

with maintenance (i) and with operational use during maintenance (ii) are part of the

change and must be proposed, designed, validated, their implementation verified and their

impact on the way the service behaves assessed. The circumstances of their use, their

desired content and any refreshment training needed, together with the periodicity of

refreshment, form the maintenance requirements for the change, i.e. they form the

requirements for degraded modes of operation.

(i) Maintenance of configuration

(1) Although not generally regarded as a maintenance activity, it is, nonetheless,

important to maintain the configuration of the change during the time it is operational.

(2) The validity of the safety support case is predicated on the declared configuration of

the changed functional system. If the configuration were to change, the way the

service behaves will be uncertain and so the safety support case would become invalid

and the validity of the service specification will not be assured. Such uncertain

behaviour can be considered as a degraded mode of operation.

(3) Maintenance of configuration will usually be covered by the MS procedures of the

service provider, however, as part of the change, these should be assessed to verify

that they cover configuration management for the proposed change. The safety

support assessment should verify that the change does not include some new element

or arrangement of elements, e.g. ones using new technology, whose configuration

cannot be verified using the current MS procedures.



DETERMINATION OF THE SPECIFICATION OF THE CHANGED SERVICE

When determining the changes in the service specification that have resulted from the change to

the functional system, service providers, other than an ATS provider, should ensure that:

(a) the properties specified for the service can be observed and measured either directly or

indirectly with a degree of certainty commensurate with the level of confidence sought from

assurance; and





(b) the specification must cover everything that has changed in the service provided when

operated within the declared operational context.



DETERMINATION OF THE OPERATIONAL CONTEXT FOR THE CHANGE

(a) When determining the operational context for the change service providers, other than an

ATS provider, should ensure that:

(1) the specification can be shown to be true for all circumstances and environments in

which the changed service is declared to operate;

(2) the operational context is completely and coherently specified and is internally

consistent;

(b) (b)The operational context must be specified so that its adherence to (1) and (2) is

observable and measurable either directly or indirectly with a degree of certainty

commensurate with the level of confidence sought from assurance.



SPECIFICATION OF THE CHANGED SERVICE

(a) The specification of the change in the service defines how the service will behave after the

change and does not restate how the unchanged service behaves, i.e. the change

specification is an alteration to the full specification of the service.

(b) The specification required is for how the service behaves at the interface with its user, and

NOT for the detailed design level of the systems internal workings, i.e. a black box

specification NOT a white box specification. It includes the form of the interface and any

constraints on the context of use.

(c) Typically, specifications for services describe the functionality and performance of the

service in terms of e.g. accuracy, reliability, availability, continuity, and timeliness.

(d) The service provider, other than an ATS provider, of the service to be changed should

explain where the changes in the specification have come from, e.g. ICAO, EC, Internal

business, Standards, user organisation to aid understanding of the change.

(e) There are specifications for: every phase of the service, each transition of the change and

the final commissioning of the change.

(f) The specification in a given context means that there are two kinds of specifications:

(1) The specification of the functionality and performance of the service, i.e. how it

behaves;

(2) The specification of the context in which the specification of the way it behaves is

valid.

(g) Specification for the difference in the service provided, as a result of the change made to

the functional system, is the property of the service provider of the service.







VERIFICATION

Service providers, other than an ATS provider, should ensure that verification activities of the

safety support assessment process include:

(a) verification that the full scope of the change is addressed throughout the whole assessment

process, i.e. all the elements that are changed and those elements of the functional system

or environment of operation that depend upon them and on which they depend;

(b) verification that the way the service behaves complies with and does not contradict any

requirements placed on the changed service by another part of the regulations or conditions

attached to the providers certificate;

(c) verification that the specification of the way the service behaves is complete and correct;

(d) verification that the specification of the operational context is complete and correct;

(e) verification that the specification was for the service analysed in the context specified by the

operational context;

(f) verification, to the intended degree of confidence, that the implementation behaves only as

specified in the given operational context; and

(g) where verification cannot be performed to the intended degree of confidence, amendment

of the specification to reflect the actual degree of confidence achieved.



MONITORING

Service providers, other than an ATS provider, should ensure that within the safety support

assessment process for a change, the monitoring criteria that are to be used to demonstrate that

the safety support case remains valid during the operation of the changed functional system, i.e.

that the changed service continues to meet its specification, are identified and documented.

These criteria should be such that:

(a) they indicate that the assumptions made in the safety support case remain valid; and

(b) they remain within the bounds predicted by the safety support case, whether they are direct

or indirect measures.

GM1 ATM/ANS.OR.C.005(b) Safety support assessment and assurance of changes to


NO SAFETY SUPPORT REQUIREMENTS AT SYSTEM LEVEL

(a) As the complete behaviour of the change is reflected in the specification of the service and

the context, no safety support requirements are required at system or change level.

Nevertheless, safety support requirements can be placed on the elements affected by the

change. This is addressed in AMC ATM/ANS.OR.C.005(a)(2).

(b) Safety hazards, safety criteria, safety risk analysis and safety risk evaluation are not

relevant to SSA because the service provider does not know how the service will be used.



VERIFICATION





This requirement is seeking verification because it is a simple cross-check of available material,

i.e. that the specification reflects the requirements of other parts of this Regulation.

(a) Behaviour

ATM/ANS.OR.C.005(b)(2)(ii) requires that the service meets its specification. Consequently,

the specification must be complete and valid, i.e. it includes the behaviour addressed in

ATM/ANS.OR.C.005(b)(2)(iii) and any additional behaviour in the specified context.

(b) Compliance with other requirements

(1) ATM/ANS.OR.C.005(b)(2)(iii) requires the service providers to identify all parts of this

Regulation that impose behaviour on the changed service and also includes any

conditions attached to the certificate. They have to identify only those parts of this

Regulation that describe required behaviour relevant to the changed service. The

identified behaviour shall be included in the specification of the changed service.

Note: The Regulation or conditions attached to the certificate may make compliance

with technical standards and ICAO SARPS mandatory.

(2) Compliance to other non-mandatory standards may also be a necessary condition for

other reasons.

(3) ATM/ANS.OR.C.005(b)(2)(iii) does not say that the service only meets the

requirements of the other parts of this Regulation. It may do other things as well, as

described in (5) below.

(4) In ATM/ANS.OR.C.005(b)(2)(iii) ‘Does not contradict’ is used to express the concern

that behaviour beyond that required by a standard might cause the behaviour required

by the standard to be undermined.

(5) The behaviour of a service is likely to include behaviour unspecified in standards; such

behaviour may come from:

(i) the behaviour of degraded modes of operation;

(ii) additional behaviour not required by the standard, but put there for commercial

purposes, e.g. competitive edge; or

(iii) other behaviour identified by the customer, e.g. an ATS provider.

(6) Consequently, the total behaviour that must be specified includes mandatory

behaviour and additional behaviour whether wanted or not wanted.







MONITORING OF INTRODUCED CHANGES

(a) Monitoring is intended to maintain confidence in the safety support case during operation of

the changed functional system. Monitoring is, therefore, only applicable following the entry

into service of the change. This is further explained in point (c)(11) of

GM1 ATM/ANS.AR.C.035 & ATM/ANS.OR.A.045 General, where the monitoring referred to

here is called ‘permanent monitoring’ in paragraph (c)(11).

(b) Monitoring is likely to be of internal parameters of the functional system that provide a good

indication of the performance of the service. These parameters may not be directly

observable at the service level, i.e. at the interface of the service with the operational

environment. For example, where a function is provided by multiply redundant resources,

the availability of the function will be so high that monitoring it may not be useful. However,

monitoring the availability of individual resources, which fail much more often, may be a

useful indicator of the performance of the overall function.





AMC/GM to ANNEX IV — Specific requirements for the provision of Air Traffic Services (Part-ATS)

SUBPART A — ADDITIONAL ORGANISATION REQUIREMENTS FOR THE

PROVISION OF AIR TRAFFIC SERVICES (ATS.OR)



For a description of different responsibilities for safety between an ATS provider and other types

of service providers, please refer to GM1 Annex I Definitions(35) & ATM/ANS.OR.C.005 &



ATS NAVIGATION PLAN — VIEW OF SAFETY

For a description of the responsibilities for safety of ATS providers, please refer to GM2 Annex I

Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General in AMC/GM to ANNEX I —

Definitions of terms used in ANNEXES II to XIII.


ATS.OR.205 General


For a description of changes to functional systems and examples, and their assessment, please

refer to GM1 Annex I Definitions (35) & ATM/ANS.OR.A.045 & ATM/ANS.OR.C.005 & ATS.OR.205

General in AMC/GM to ANNEX I — Definitions of terms used in ANNEXES II to XIII.

GM1 ATM/ANS.OR.C.005(a)(2) & ATS.OR.205(a)(2) General

SAFETY SUPPORT CASE AND SAFETY CASE

For a description of safety support case and safety case concepts, please refer to

GM1 ATM/ANS.OR.C.005(a)(2) & ATS.OR.205(a)(2) in AMC/GM to ANNEX II — Requirements for

Competent Authorities — Service Provision and Network Functions (Part-ATM/ANS.AR).


system

GENERAL

(a) The safety assessment should be conducted by the provider itself. It may also be carried

out by another organisation, on its behalf, provided that the responsibility for the safety

assessment remains with the provider of air traffic services.

(b) A safety assessment needs to be performed when a change affects a part of the functional

system (people, procedures, equipment, or the way they are organised or to any

combination of these elements) managed by the provider of air traffic services and that is

being used in the provision of its (air traffic) services. The safety assessment or the way it

is conducted does not depend on whether the change is a result of a business decision or a

decision to improve safety.





AMC1 ATS.OR.205(a)(2) Safety assessment and assurance of changes to the

functional system

FORM OF ASSURANCE

(a) The ATS provider should ensure that the assurance required by ATS.OR.205(a)(2) is

documented in a safety case148.

(b) A safety case is an argument that provides a compelling, comprehensible and valid case

that a system is safe for a given application in a given context. The argument consists of

claims that are supported via inferences by a body of evidence.


system

SAFETY CRITERIA

‘Safety criteria will remain satisfied’ means that assurance needs to be provided that the

monitoring requirements of ATS.OR.205(b)(7) are suitable for demonstrating, during operation,

that the argument remains valid, i.e. the safety criteria continue to be satisfied in operation.


system

ASSURANCE LEVELS

The use of assurance level concepts, e.g. design assurance levels (DAL), software assurance

levels (SWAL), hardware assurance levels (HWAL), human assurance levels (HAL), procedure

assurance levels (PAL), might be helpful in generating an appropriate and sufficient body of

evidence, which in turn may help to establish the required confidence in the argument.

AMC2 ATS.OR.205(a)(2) Safety assessment and assurance of changes to the

functional system


The argument is to be considered to be complete when it shows that:

(a) the safety assessment in ATS.OR.205(b) has produced a sufficient set of non-contradictory

valid safety criteria;

(b) safety requirements have been placed on all elements affected by the change and whose

behaviour can affect safety;

(c) the behaviour necessitated by the safety requirements meets the safety criteria;

(d) all safety requirements have been traced from the safety criteria to the level of the

architecture at which they have been satisfied;

(e) each component satisfies its safety requirements;

(f) each component’s behaviour, within the context in which it is intended to operate, does not

adversely affect safety; and

(g) the evidence is derived from known versions of the components and the architecture and

known sets of products, data and descriptions that have been used in the production or

verification of those versions.

148 For additional information related to the term safety case, see GM1 ATM/ANS.OR.C.005(a)(2) &

ATS.OR.205(a)(2) General.






system


Besides completeness, the argument must provide sufficient confidence that the change is

sufficiently safe149.

(a) Sufficiency of safety criteria

(1) A sufficient set of safety criteria is one where the safety goal of the change is validly

represented by the set of individual safety criteria, each criterion of which must be

valid in its own right and not contradict another criterion or any other subset of

criteria. A valid criterion is a correct, complete and unambiguous statement of the

desired property. An individual valid criterion does not necessarily represent a

complete safety criterion. A typical example of an invalid criterion is that the max

take-off weight shall not exceed 225 Tonnes because weight is measured in Newtons

and not in Tonnes. A typical example of an incomplete criterion is that the accuracy

shall be 5 m because no reliability attribute is present. This implies it must always be

within 5 m, which is impossible in practice.

(2) Optimally, a sufficient set of criteria would consist of the minimum set of non-

overlapping valid criteria. This means that a set containing overlapping criteria or

criteria that are not relevant would not form an optimum set.

(3) Criteria that are not relevant, i.e. ones that do not address the safety goal of the

change at all, should be removed from the set as they contribute nothing, may

contradict other valid criteria and may serve to confuse.

(4) There are two forms of overlap: complete overlap and partial overlap.

(i) In the first case, one or more criteria can be removed and the set would remain

sufficient, i.e. there are unnecessary criteria.

(ii) In the second case, (partially overlapping criteria) if any criterion were to be

removed, the set would not be sufficient, consequently all criteria are necessary,

however, validating the set would be much more difficult. Showing that a

significant150 set of overlapping criteria do not contradict each other is extremely

difficult and consequently prone to error.

(5) It may, in fact, be simpler to develop an architecture that supports non-overlapping

criteria than to attempt to validate a partially overlapping set of criteria.

(b) Safety requirements

(c) Satisfaction of safety criteria

(1) The concept underpinning AMC2 ATS.OR.205(a)(2) is that, provided each element

meets its requirements, the system will meet its safety criteria. This will be true

provided (2), (3) and (4) below are met.

(2) The activity needed to meet this objective consists of obtaining sufficient confidence

that the set of requirements is complete and correct, i.e. that:

(i) the architectural decomposition of the elements leads to a complete and correct

set of requirements being allocated to each sub-element;

149 The structure of this GM relates directly to the structure of the AMC above and not to the IR. 150 Significant could either be a significant number of criteria or criteria of significant complexity or a combination of both.





(ii) each requirement is a correct, complete and unambiguous statement of the

desired behaviour, and does not contradict another requirement or any other

subset of requirements; and

(iii) the requirements allocated to an element necessitate the complete required

behaviour of the element in the target environment.

(3) This should take into account specific aspects such as:

(i) the possible presence of functions within the element that produce unnecessary

behaviour. For instance, in the case where a previously developed element is

used, activities should be undertaken to identify all the possible behaviour of the

element. If some of this behaviour is not needed for the foreseen use, then

additional requirements may be needed to make sure that these functions will

not be solicited or inadvertently activated in operation;

(ii) element requirements that are not directly related to the desired behaviour of

the functional system. This kind of requirement can, for instance, ask that the

element be developed in a given syntax, or be designed in a certain way. These

requirements often relate to technical aspects of the element. Activities should

be undertaken to ensure that each of these requirements is a correct, complete

and unambiguous statement of the desired effect, and does not contradict

another requirement or any other subset of requirements.

(d) Traceability of requirements

(1) The traceability requirement can be met by tracing to the highest level element that

has been shown to satisfy its requirements, by verifying it in isolation. It is likely and

completely acceptable that this point will be reached at a different architectural level

for each element.

(e) Satisfaction of safety requirements

(1) The component view taken must be able to support verification, i.e. the component

must be verifiable — see guidance in (b).

(2) Care should be taken in selecting subsystems that are to be treated as components for

verification to ensure that they are small and simple enough to be verifiable.

(f) Adverse effects on safety

(1) All interactions of components, operating in their defined context, have to be identified

and assessed for safety in order to be able to show that they do not adversely affect

safety. This assessment must include the failure conditions for all components and the

behaviour of the services delivered to the component including failures in those

services.

(2) Interactions in complex systems are dealt with in ATM/ANS.OR.A.045(e)(1).

(g) Configuration identification

(1) AMC2 ATS.OR.205(a)(2)(g) is only about configuration of the evidence and should not

be interpreted as configuration management of the changed functional system.

However, since the safety case is based on a set of elements and the way they are

joined together, the safety case will only be valid if the configuration remains as

described in the safety case. Guidance on ‘Maintenance of configuration’ is provided in

GM1 ATS.OR.205(b)(1), (2) & (4).





(2) Evidence for the use of the same component in different parts of the system or in

different systems should probably not rely on testing in a single context since it is

unlikely that the contexts for each use will be the same or can be covered by a single

set of test conditions. This applies equally to the reuse of evidence gathered from

testing subsystems.


systems

SUFFICIENCY OF SAFETY REQUIREMENTS

A valid set of safety requirement specifies:

(a) for equipment, the complete safety behaviour, in terms of functions, accuracy, timing,

order, format, capacity, resource usage, robustness to abnormal conditions, overload

tolerance, availability, reliability, and confidence;

(b) for people, their complete expected safety behaviour and performance in terms of tasks,

accuracy, response times, workload, reliability, confidence, skills, knowledge and personal

characteristics, in relation to their tasks;

(c) for procedures, the circumstances for their enactment, the resources needed, the sequence

of actions to be performed and the timing and accuracy of the actions; and

(d) interactions between all parts of the system.


systems

SUFFICIENCY OF SAFETY REQUIREMENTS

(a) Equipment

(1) The complete safety behaviour is limited to the scope of the change. Safety

requirements only apply to the parts of a system affected by the change. In other

words, if parts of a system can be isolated from each other and only some parts are

affected by the change, then these are the only parts that are of concern and so will

have safety requirements attached to them.

(b) People

(1) The workload is that which would result from someone (with the defined skills,

knowledge and personal characteristics) performing the task in the context of the

provision of an actual operational service and in compliance with the stated accuracy,

response times and reliability. It will have to be shown to be a reasonable workload

given the abilities of those performing the task.

(2) The skills and knowledge required of the people performing the task will normally be

provided for by the selection of and general training provided for different types and

levels of personnel.

(3) The personal characteristics are those required of anyone who is expected to perform

the defined task, i.e. .those who have the required skills and knowledge, and do so

within the bounds of the defined accuracy, response times and reliability. These

personal characteristics are:

(i) resilience to distraction;





(ii) self-awareness — the ability to know when they are out of their depth and need

help;

(iii) team ‘playerness’ — the ability to work together with other members of a team

to best resolve abnormal situations (CRM - Behavioural Markers); and

(iv) adaptability — the ability to synthesise/innovate when unforeseen things

happen.

(c) Procedures

The resources referred to in AMC3 ATS.OR.210(a)(2)(c) are the resources, in terms of the

equipment, and the people that are needed to perform the procedure.

AMC1 ATS.OR.205(b) Safety assessment and assurance of changes to the functional

system

SAFETY ASSESSMENT PROCESS

(a) Completeness of the scope

The ATS provider should ensure that the assessment of the change includes:

(1) all the components of their functional system, as required in ATS.OR.205(b)(1)(i), that

are altered due to the change or whose inputs or outputs are altered by the change;

(2) all elements in the context of operations that are affected by the change to the

components identified in (1); and

(3) all operational transitions that are part of the change.

(b) Completeness of hazard identification

The ATS provider should ensure that hazard identification:

(1) targets complete coverage of any condition, event, or circumstance related to the

change, which could, individually or in combination, induce a harmful effect;

(2) should be done by personnel trained and competent to perform this task; and

(3) need only identify hazards that are generally considered as credible.

(c) Hazards to be identified

The following hazards should be identified:

(1) New hazards, i.e. those introduced by the change relating to the:

(i) failure of the ATM/ANS functional system; and

(ii) normal operation of the ATM/ANS functional system; and

(2) Already existing hazards that are affected by the change and are related to:

(i) the existing parts of the ATM/ANS functional systems which are not changed;

and

(ii) hazards outside the ATMS/ANS functional system, for example those inherent to

aviation.

(d) Determination of the safety criteria for the change

When determining the safety criteria for the change being assessed, the ATS provider

should, in accordance with ATS.OR.210, ensure that:





(1) the safety criteria support a risk analysis that is:

(i) relative or absolute, i.e. refers to:

(A) the difference in safety risk of the system due to the change (relative); or

(B) the difference in safety risk of the system and a similar system (absolute

and relative); and

(C) the safety risk of the system after the change (absolute); and

(ii) objective, whether risk is expressed numerically or not.

(2) the safety criteria are measurable to an adequate degree of certainty;

(3) proxies for safety risk, used as safety criteria for those parts of the functional system

affected by the change, can only be employed when:

(i) a justifiable causal relationship exists between the proxy and the harmful effect, e.g.

proxy increase/decrease causes risk increase/decrease;

(ii) a proxy is sufficiently isolated from other proxies to be treated independently;

and

(iii) the proxy is measurable to an adequate degree of certainty.

(4) the set of safety criteria, whether represented totally by proxies or a mixture of

proxies and risks, should cover the complete change;

(5) the safety criteria selected are consistent with the overall safety objectives established

by the ATS provider through its Safety Management System and represented by its

annual and business plan and Safety Key Performance Indicators; and

(6) where a safety risk or a proxy cannot be compared with its related safety criteria

without their being unacceptable uncertainty, the safety risk should be constrained

and actions should be taken, in the long term, so as to manage safety and ensure that

overall the ATS provider’s safety objectives are met.

(e) Completeness of risk analysis

The ATS provider should ensure that the risk analysis is carried out by personnel trained

and competent to perform this task and should also ensure that:

(1) a complete list of harmful effects in relation to the identified:

(i) hazards, when the safety criteria is expressed in terms of safety risk; or

(ii) proxies, when the safety criteria is expressed in relation to proxies;

(iii) hazards introduced due to implementation

is produced; and

(2) the risk contributions of all hazards and proxies are evaluated;

(3) risk analysis is conducted in terms of risk or in terms of proxies or a combination of

them, using specific measurable quantities that are related to operational safety risk;

and

(4) results can be compared with the safety criteria.

The risk analysis takes into account the reduction of risk due to the change, i.e. the positive

safety contributions of the change are also evaluated (success approach).





(f) Severity classification of accident leading to harmful effects

When performing a risk analysis in terms of risk, the ATS provider should ensure that the

harmful effects of all hazards are allocated a safety severity category and that, where there

is more than one safety severity category of harm, any severity classification scheme

satisfies the following criteria:

(1) The scheme is independent of the causes of the accidents that it classifies, i.e. the

severity of the worst accident does not depend upon whether it was caused by an

equipment malfunction or human error;

(2) The scheme permits unique assignment of every harmful effect to a severity category;

(3) The severity categories are expressed in terms of a single scalar quantity and in terms

relevant to the field of their application;

(4) The level of granularity (i.e. the span of the categories) is appropriate to the field of

their application;

(5) The scheme is supported by rules for assigning a harmful effect unambiguously to a

severity category; and

(6) The scheme is consistent with the ATS providers views of the severity of the harmful

effects covered and can be shown to incorporate societal views of their severity.

(g) Evaluation

The ATS provider should ensure that the risk evaluation includes:

(1) an assessment of the identified hazards for a notified change, including possible

mitigating means, in terms of risk or in terms of proxies or a combination of them;

(2) a comparison of the risk analysis results against the safety criteria taking the

uncertainty of the risk assessment into account; and

(3) the identification of the need for risk mitigation or reduction in uncertainty or both.

(h) Risk mitigation

When the risk evaluation results show that the safety criteria cannot be achieved, then the

ATS provider should either abandon the change or propose additional means of mitigating

the risk. If risk mitigation is proposed, then the ATS provider should ensure that it

identifies:

(1) all of the elements of the functional system, e.g. training, procedures, that need to be

reconsidered; and

(2) for each part of the amended change, those parts of the safety assessment

(requirements from (a) to (f)) that need to be repeated in order to demonstrate that

the safety criteria will be satisfied.

(i) Verification

The ATS provider should ensure that verification activities of the safety assessment process

include:

(1) verification that the full scope is addressed throughout the whole assessment process,

i.e. all the elements of the functional system or environment of operation that are

changed and those unchanged elements that depend upon them and on which they

depend are identified;





(2) verification that the design is completed and correct;

(3) verification that the design was the one analysed; and

(4) verification that the implementation is that of the design and behaves only as

specified.

(j) Monitoring

The ATS provider should ensure that within the safety assessment process for a change, the

monitoring criteria, that are to be used to demonstrate that the safety case remains valid

during the operation of the changed functional system, are identified and documented.

These criteria are specific for the change and should be such that:

(1) they indicate that the assumptions made in the argument remain valid;

(2) they indicate that critical proxies remain as predicted in the safety case and are not

more uncertain; and

(3) safety indicators defined in relation to the change remain within the bounds predicted

by the safety case.

GM1 ATS.OR.205(b) Safety assessment and assurance of changes to the functional

system

PROPORTIONALITY OF SAFETY ASSESSMENT

ATS providers may carry out safety assessment in a way that is commensurate with the type and

nature of the change and its impact on safety.


system

SAFETY ASSESSMENT METHODS

(a) The ATS provider can use a standard safety assessment method or it can use its own safety

assessment method to assist with structuring the process. However, the application of a

method is not a guarantee of the quality of the results.

(b) There are databases available that describe different safety assessment methods, tools and

techniques151 that can be used by the ATS provider. The provider must ensure that the

safety assessment method is adequate for the change being assessed and that the

assumptions inherent in the use of the method are recognised and accommodated

appropriately.


system

PROCEDURE DEVELOPMENT

If the change modifies the way people interact with the rest of the functional system, then they

will require training before the change becomes operational. People may also need refreshment

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 refreshment

training is part of the maintenance of the functional system after the change is in operation.

151 For example, http://www.nlr.nl/downloads/safety-methods-database.pdf, http://www.scsc.org.uk/

http://www.nlr.nl/downloads/safety-methods-database.pdf

http://www.scsc.org.uk/






system

SAFETY ASSESSMENT PROCESS

(a) Figure 1 below shows a schematic representation of the safety assessment process.

Figure 1: Schematic representation of the risk assessment process

(1) The rectangular boxes in Figure 1 correspond to the steps in the execution of a safety

assessment. The lines between these boxes are not intended to indicate that these

steps must be executed sequentially; they simply indicate a top-down order that is a

comprehensible sequence and a common practice. However, it might be beneficial to

go from one step to another in a different sequence or in a number of steps.

(2) The box ‘Mitigating means’ corresponds to the decision by the ATS provider to adapt

the design by incorporating mitigating means (‘yes’) or to accept the design from the

perspective of risk evaluation (‘no’). The box ‘Risk acceptance’ corresponds to the

decision by the ATS provider and, whenever the change is reviewed by the CA, the

approval by the CA to let the change enter operation (‘yes’) or not (‘no’).

Define scope

Evaluate risk

Analyse risk

Determine criteria

Identify hazards

Verify

Specify monitoring

Design

Mitigating means

Implementation

Operation

Risk acceptance

yes

no

yes

no





(3) The rounded boxes at the right of the figure correspond to the main steps in the

processes for the development of the change. The rounded boxes in the middle

correspond to the main decisions that govern the outcome in the development of the

change made during the safety assessment. Several processes and decisions are not

explicitly indicated. These include decisions and actions by the CA, preparatory

activities and documentation.

(4) The decisions can occur at different points in the safety assessment process:

(i) It is possible to adopt mitigating means (indicated by ‘yes’ at the right of the box

‘mitigating means’) before the risk evaluation is finished. The decision to

implement the change (indicated by ‘no’) should, however, be based on the

results of the risk evaluation.

(ii) It is possible to decide not to implement the change (indicated by ‘no’, below the

box ‘risk acceptance’) before all steps of the safety assessment process are

finished. The decision to put the change into service (indicated by ‘yes’) should

only be taken when a valid safety case for the change exists, which is based on

the overall results of the safety assessment.

(b) The process of executing the risk analysis and the risk evaluation may depend on the

maturity of the change and on the selected safety assessment method.

(1) It is, for example, possible to compare the estimated risk directly to the safety

criteria, after which decisions on implementation, adaptations of the design and risk

mitigation can be made. This is more likely to be of benefit later on in the process

when the risk evaluation is relatively mature.

(2) It is also possible to derive safety objectives and safety requirements from the safety

criteria. These are allocated to the different elements/parts of the functional system

affected by the change. The planned change is adapted during its development to

make sure that the safety objectives and safety requirements can be met.


system

IDENTIFYING THE SCOPE — GENERAL

(a) The description of the elements being changed includes the nature, functionality, location,

performance, maintenance tasks, training and responsibilities of these elements, where

applicable. The description of interfaces and interactions, between machines and between

humans and machines, should include communication means, e.g. language, phraseology,

protocol, format, order and timing and transmission means, where applicable. In addition, it

includes the description of the context in which they operate.

(b) There are two main aspects to consider in evaluating the scope of a change:

(1) The interactions within the changed functional system;

(2) The interactions within the changing system, i.e. those that occur during transitions

from the current system to the changed system.

As each transition can be treated as a change to a system, the identification of both

have a common approach described below.

(c) The scope of the change is defined as the set of the changed components and impacted

components. In order to identify the impacted components and the changed components, it

is necessary to:





(1) know which components will be changed;

(2) know which components might be directly affected by the changed components and,

hence, identify the directly impacted components;

(3) identify indirectly impacted components by:

(i) identifying new interactions introduced by the changed or directly impacted

components; and/or

(ii) identifying interactions with changed or directly impacted components via the

environment.

(4) Furthermore, directly and indirectly impacted components will be identified as a result

of applying the above iteratively to any directly and indirectly impacted components

that have been identified previously.

The scope of the change is the set of changed, directly impacted and indirectly impacted

components identified when the iteration identifies no new components.

(d) The context in which the changed service is intended to operate (see ATS.OR.205(b)(1)(iii))

includes the interface through which the service will be delivered to other service providers.


system

DESCRIPTION OF THE SCOPE — MULTI-ACTOR CHANGE

In the case where the change is a multi-actor change, in accordance with ATM/ANS.OR.A.045(e),

the interfaces and interactions described in GM1 ATS.OR.205(b)(1)(iii) include the interfaces with

the other providers and organisations that are also affected by the change. EUROCAE ED-78A

may be used as guidance to cooperatively identify the scope of multi-actor changes.

GM1 ATS.OR.205(b)(1), (2) & (4) Safety assessment and assurance of changes to the

functional system

DEGRADED MODES OF OPERATION

(a) The following guidance deals with the safety assessment associated with degraded modes of

operation, it, therefore, applies to the safety assessment of all components of the functional

system (people, procedures, equipment (software & hardware)) and includes addressing

training for personnel and the degraded modes of operation of the services delivered to

functional system. The work involved, described below, is considered to be part of the

safety assessment of the change and does not require a separate safety assessment.

(b) The scope of the change should include all planned degraded modes. Degraded modes occur

for two reasons:

(1) The service behaves incorrectly or is incomplete because of a malfunction; and/or

(2) The level of the service offered varies due to maintenance activities, i.e. when

repairing the functional system as a result of a malfunction or when trying to prevent

a malfunction.





(c) Malfunctions

(1) The service will at some point malfunction. Malfunctions result in:

(i) loss of function; or

(ii) corruption of the information associated with a service.

Corruptions, may be taken as a synonym for unwanted behaviour.

(2) A loss implies that some necessary service or part of a service has become

unavailable. A corruption implies that the system is behaving incorrectly. Both forms

of malfunction increase the risk of the functional system at their onset and until they

can be mitigated by maintenance activity.

(d) Planning for degraded modes

(1) In order to be confident that the service will remain acceptably safe, even though

malfunctions occur, all conceivable malfunctions associated with the change should be

identified, assessed and any necessary responses identified, i.e. malfunctions are

foreseen and mitigated.

(2) Responses will be necessary when the risk associated with the malfunction is great

enough that it requires to be mitigated as per ATS.OR.205(b)(5).

(3) Responses take the form of maintenance and operational procedures that come into

play either periodically or when a malfunction is identified. These procedures are

considered further below. The safety assessment has to consider these procedures and

show that the changed functional system will also be safe during periods of

maintenance. Consequently, the risk associated with these procedures also needs to

be assessed and they must be shown to correctly mitigate the risk caused by the

malfunction without increasing the operational risk to an unacceptable level

themselves, i.e. they need to be proposed, designed, validated, assessed for safety

and their implementation verified.

(4) Note that in mitigating the risk associated with a malfunction, the time between the

onset of the malfunction and the point at which the maintenance activity reduces this

risk to an acceptable level may be significant, in which case the means of

automatically detecting some malfunctions may need to be designed into the service

in order to decrease this time.

(5) Planned degraded modes can, therefore, be considered to be those modes of

operation where maintenance activities are occurring due to the presence or potential

presence of malfunctions and where the risk associated with the malfunction is

considered to be unacceptable.

(e) Maintenance is of three forms:

(1) On condition maintenance — an element within the functional system has failed or will

fail imminently and needs to be replaced with an identical element. Notice that

replacing an element with a different element is a change, it is not maintenance and

so it requires a new safety assessment.

(2) Preventive maintenance — the operational performance will degrade sometime in the

future if maintenance is not performed. This may also be called periodic maintenance,

since in order to preserve the future performance of the system, it is performed

periodically, usually at regular intervals.





(3) Maintenance of configuration — operational performance and, hence, safety is not

assured if an element of the functional system or its architecture deviates from that

which was evaluated during the assessment and justified in the assurance case.

NB: ‘maintenance’ is not meant to be restricted to ‘technical systems’. It applies to all the

constituents of the functional system : procedures, people and equipment (HW and SW). In

that sense, maintenance applied to people should be understood as refreshment training.

(f) On condition maintenance

(1) Maintenance activity results from the detection of the malfunction. In general, the loss

of a function of the service is usually detected when it happens, whereas corruption

may not be detected for some time and then only as a result of an incident occurring.

(2) Prior to the malfunction, the user receiving the services is supported by the full range

and capability of the services offered. After the malfunction is detected and isolated,

the range or level of services offered may necessarily need to be reduced as the

functional system, now available, is incomplete.

The diagram below shows how risk might vary during a malfunction and the processes

through which the malfunction is managed.

Transition to Normal Service

(iv)

Modified Service(iii)

NormalService

NormalService

Transition to Modified Service

(ii)

Malfunction Detected

Malfunction Event

(i)

UndetectedMalfunction

RISK

Process change (work around malfunction)Traffic level change (reduce number of a/c)

Note: This level of risk maybe slightly lower or

slightly higher than theNormal Service level

Time to Repair(Maintenance)

(3) It can be seen that the processes following a malfunction encompass the following

phases:

(i) The malfunction occurs, but may initially be undetected.

(ii) The malfunction is detected and the service is modified to account for the

malfunction152.

(iii) A modified service is performed while the cause of the malfunction is

investigated and put right.

152 Note that in some circumstances the detection of a malfunction may result in an automatic isolation of the faulty part

and indication to the operators that degraded mode operational procedures should be put in place. The physical removal and repair of the faulty part may, therefore, be delayed and does not necessarily coincide with the onset of the degraded mode operational procedures.





(iv) Once the malfunction has been put right, the functional system is restored to its

normal state and the normal service is resumed.

(4) Clearly, safety risk rises (possibly considerably) during the time the malfunction is

undetected. It then falls to an acceptable level, which may be lower or higher than the

normal level of risk, as the modified service is introduced. This is not instantaneous,

as it will take time to change the navigation plans of all the affected a/c, alert them,

convey new instructions and allow them to adjust their flight paths, if necessary.

Furthermore, if it is necessary to reduce the number of a/c receiving the service in

order to reduce the risk to an acceptable level, then it will take some time to establish

the new level of traffic.

(5) During a malfunction, two kinds of processes will be in use:

(i) The process to identify, isolate, repair and replace the elements causing the

malfunction; and

(ii) The operational process needed to mitigate the effects of the malfunction and its

repair and to restore services to their normal levels once the malfunction has

been repaired.

(g) Preventative maintenance

(1) In general, mechanical elements, such as radar heads, degrade with use and will, at

some point, fail. In order to prevent their future failure, these elements are

maintained periodically to restore them to such a condition that they will continue to

operate until the point at which the next maintenance occurs.

(2) During maintenance, the range or level of services offered may necessarily need to be

reduced as the functional system, now available, is incomplete. Consequently, two

kinds of processes will be in use:

(i) The process to isolate and bring back the elements being maintained to their

intended condition and then to return them to operational service; and

(ii) The operational process needed to mitigate the effects of the removal of the

elements being maintained and to restore services to their normal levels once

the maintenance has been completed.

(h) Procedure development

The procedures governing the processes identified in (f) and (g) above, i.e. those associated

with maintenance (i) and the operational use during maintenance (ii) are part of the change

and must be proposed, designed, validated, their implementation verified and their effects

on safety assessed. The circumstances of their use, their desired content and any

refreshment training needed, together with the periodicity of refreshment, form the

maintenance requirements for the change, i.e. they form the requirements for degraded

modes of operation.

(i) Maintenance of configuration

(1) Although not generally regarded as a maintenance activity, it is, nonetheless,

important to maintain the configuration of the change during the time it is operational.

(2) The validity of the safety case is predicated on the declared configuration of the

changed functional system. If the configuration were to change, the way the service

behaves will be uncertain and so the safety case would become invalid and the safety





of the change will not be assured. Such uncertain behaviour can be considered as a

degraded mode of operation.

(3) Maintenance of configuration will usually be covered by the SMS procedures of the

service provider, however, as part of the change, these should be assessed to verify

that they cover configuration management for the proposed change. The safety

assessment should verify that the change does not include some new element or

arrangement of elements, e.g. ones using new technology, whose configuration

cannot be verified using the current SMS procedures.


system

HAZARDS IDENTIFICATION

(a) Completeness of hazard identification

In order to achieve completeness in the identification of hazards, it might be beneficial to

aggregate hazards and to formulate them in a more abstract way, e.g. at the service level.

This might in turn have drawbacks when analysing and evaluating the risk of the hazards.

The appropriate level of detail in the set of hazards and their formulation, therefore,

depends on the change and the way the safety assessment is executed.

(b) Sources of hazards

(1) Hazards introduced by failures or nominal operations of the ATM/ANS functional

systems may include the following factors and processes:

(i) design factors, including equipment, procedural and task design;

(ii) operating practices, including the application of procedures under actual

operating conditions and the unwritten ways of operating;

(iii) communications, including means, terminology, order, timing and language and

including human-human, human-machine and machine-machine

communications;

(iv) installation issues;

(v) equipment and infrastructure, including failures, outages, error tolerances,

nuisance alerts, defect defence systems, and delays; and

(vi) human performance, including restrictions due to fatigue and medical conditions,

and physical limitations.

(2) Hazards introduced in the context in which the ATM/ANS functional system operates

may include the following factors and processes:

(i) wrong, insufficient or delayed information and inadequate services delivered by

third parties;

(ii) personnel factors, including working conditions, company policies for and actual

practice of recruitment, training, remuneration and allocation of resources;

(iii) organisational factors, including the incompatibility of production and safety

goals, the allocation of resources, operating pressures and the safety culture;

(iv) work environment factors, such as ambient noise, temperature, lighting,

annoyance, ergonomics and the quality of man machine interfaces; and





(v) external threats, such as fire, electromagnetic interference and sources of

distraction.

(3) The hazards introduced in the context in which the ATM/ANS services are delivered

may include the following factors and processes:

(i) errors, failures, non-compliance and misunderstandings between the airborne

and ground domains;

(ii) traffic complexity, including traffic growth, fleet mix, and different types of

traffic;

(iii) wrong, insufficient or delayed information delivered by third parties;

(iv) inadequate service provisioning by third parties; and

(v) external physical factors, including terrain, weather phenomena, volcanoes and

animal behaviour.

(c) Methods to identify hazards

(1) The ATS provider may use a combination of tools and techniques, including functional

analysis, what if techniques, brain storm sessions, expert judgement, literature search

(including accident and incident reports), queries of accident and incident databases in

order to identify hazards.

(2) The ATS provider needs to make sure that the method is appropriate for the change

and produces (either individually or in combination) a valid (necessary and sufficient)

set of hazards. This may be aided by drawing up a list of the functions associated with

part of the functional system being changed.


system

SAFETY CRITERIA IN TERMS OF PROXIES FOR SAFETY RISKS

(a) A proxy is some measurable property that can be used to represent the value of something

else. In the safety assessment of functional systems, the value of a proxy may be used as a

substitute for a value of risk, providing it meets the requirements for a proxy as stated in

point (d)(3) of AMC1 ATS.OR.205(b). Examples of proxies are the frequency of airspace

infringements, runway incursions, false alert rate, head down time, limited sight, level of

situation awareness, fraction of read back errors, reduced vigilance, amount of turbulence,

distraction of controller’s attention, inappropriate pilot behaviour, system availability,

information integrity and service continuity.

An example of the concept of using a different but specific quantity to assess an actually

relevant quantity is the transposition/measure of an a/c’s altitude which is in terms of

barometric pressure or the transposition/measure of an a/c’s airspeed which is in terms of

dynamic pressure.

(b) Proxies might be preferred where the extra effort needed to identify, describe and analyse a

complete set of sequences of events from the occurrence of a hazard to the occurrence of

an accident or incident has no added value in the safety assessment. The intrinsic reasons

for the difficulties are the number of significantly different event sequences, the complexity

of some accident scenarios, the existence of many barriers preventing the occurrence of a

hazard developing into an accident and the lack of evidence on the probability of some

events or the frequency of occurrence of some external circumstances and factors. The





usage of proxies might then make the safety assessment more tractable and

comprehensible and increase the quality of the risk analysis.

(c) The main advantages of proxies are the easy recognition of safety issues by operational

staff involved in the safety assessment, and the direct focus on the analysis and mitigation

of the identified hazards and safety issues introduced or affected by the change.

(d) The main disadvantage of using proxies is that it is not possible to express risk by a uniform

measure. However, the level of the proxy should be measurable.

(e) For further details on the use of proxies, please refer to GM2 ATS.OR.205(b), which contains

two examples to assist in the selection and use of proxies in safety analysis.

GM1 ATS.OR.205.(b)4 Safety assessment and assurance of changes to the functional

system

RISK ANALYSIS IN TERMS OF SAFETY RISK

(a) Concept of Safety Risk

‘hazard’ means any condition, event, or circumstance which could induce a harmful effect,

as per Annex I.

‘risk’ means the combination of the overall probability, or frequency of occurrence of a

harmful effect induced by a hazard and the severity of that effect, as per Annex I.

‘harm’ (as per Oxford dictionary) means:

noun

— physical injury, especially that which is deliberately inflicted, e.g. I didn’t mean to

cause him any harm.

— material damage, e.g. It’s unlikely to do much harm to the engine.

— actual or potential ill effects or danger, e.g. There’s no harm in asking her.

‘safety’ (as per Oxford dictionary) means

noun

— the condition of being protected from or unlikely to cause danger, risk, or injury, e.g.

They should leave for their own safety.

The survivors were airlifted to safety.

Consequently, a safety risk is:

A combination of the overall probability, or frequency of occurrence of a harmful (injurious)

effect on people and the severity of that effect.

NB: The term ‘risk’ is used throughout the IR, AMC and GM as a synonym for safety risk.

This is for simplicity and is justified because the IR deals primarily with the safety of a

change.





AccidentHazard Mitigation Harmful effect

Incident

EventCircumstance

Condition

Is a

OccurrenceEvent

Is a

OccurrenceEvent

Is a

Hazardous Event Fails Causes

Succ

eed

s

Not all accidents cause harm to people

Incidents do not cause harm to people

Mitigations can fail as well as succeed

FatalitySerious injury…Minor injury

Is a

Taxonomy of Safety (Harm to people) – relating to OR.ATM/ANS.bbb.(b).(2), (4) & (5)

Severity

has a

While hazards can be a circumstance, a condition or an event, for the purposes of the

taxonomy and subsequent guidance, only hazardous events are considered. While

circumstantial or conditional hazards, e.g. presence of dense fog, may contribute to a

hazardous event, e.g. taking a wrong taxi exit, it is the event that is primarily of interest in

accident (harmful effect) analysis.

(b) Risk analysis

When a risk assessment of a set of hazards is executed, in terms of risk:

(1) the frequency or probability of the occurrence of the hazard should be determined;

(2) the possible sequences of events from the occurrence of a hazardous event to the

occurrence of an accident, which may be referred to as accident trajectories, should be

identified. The contributing factors and circumstances that distinguish the different

trajectories from one another should also be identified, as should any mitigations

between a hazardous event and the associated accident153;

(3) the potential harmful effects of the accident, including those resulting from a

simultaneous occurrence of a combination of hazards, should be identified;

(4) the severity of these harmful effects should be assessed, using a defined severity

scheme according to point (f) of AMC1 ATS.OR.205(b); and

(5) the risk of the potential harmful effects of all the accidents, given the occurrence of

the hazard, should be determined, taking into account the probabilities that the

mitigations may fail as well as succeed, and that particular accident trajectories will be

followed when particular contributing factors and circumstances occur.

(c) Hazards and accidents

(1) A hazard may lead to several accidents. For example, at a junction of a taxiway and a

runway the hazard of an a/c going outside a protected piece of airspace e.g. failure of

the a/c to stop at an intersection of taxiways, when expected to do so, could lead to

an accident with a low speed a/c, a high speed a/c or an airport vehicle. Also, an

153 Note that the diagram in (a) shows a single accident trajectory, of which there may be many associated with a hazard.

This notion is developed in the next section.





accident may be caused by several hazards. For example, in the same circumstances,

the collision of two a/c at the junction could be caused by a failure of both a/c to stop

at different intersections, when expected to do so. This leads to the general

hazard/accident model shown below:

AccidentsAccidentsHazardsHazards

A1

A2

A3

A4

A5

H2

A6

H1

H3

M11

M12

M13

M16

M14

M15

For clarity mitigations are only shown for Hazard 1

(2) In general, there are many causes for a hazard and some of those causes may be

common to a number of hazards, e.g. the same procedure may be used for controlling

taxying a/c over many different routes. If the procedure is flawed, i.e. it creates a

hazard, it will contribute to service level hazards (see (3) below) at particular points

on each route or for particular circumstances during each transition over a different

route. Consequently, a complete generalised model of the relationships between

causes, hazards and accidents may be formed as illustrated below:





AccidentsAccidentsHazards(For an optimum Model, these

would be Service Level Hazards)

Hazards(For an optimum Model, these

would be Service Level Hazards)

A1

A2

A3

A4

A5

H2

A6

H1

H3

M11

M12

M13

M16

M14

M15

For clarity, mitigations are only shown for Hazard 1

C1

C2

C3

C4

C5

C6

CausesCauses

Thre

ats

Thre

ats

Co

nse

qu

en

ces

Co

nse

qu

en

ces

M63

M62

M61

For clarity, mitigations are only shown for Cause 6

Note that causes are also hazards but are called causes here to differentiate them

from the hazard of interest (Service Level Hazard - Hn).

(3) In any reasonably sized change, there may be many causes, many hazards and many

accidents. In these circumstances, it may be more convenient and less confusing to

work on a single hazard at a time. The Bow Tie Model represents an appropriate way

of doing this. The bow tie is a simplified representation of the conjunction of a fault

tree and an event tree with the cause of accidents on the extreme left of the bow tie

and the accidents on the extreme right of the bow tie. The Hazard of interest or

hazard point (the knot in the bow tie) can be declared to be anywhere between these

two points, i.e. where the fault tree stops and the event tree starts is a modelling

decision. For optimum efficiency/effectiveness, the Hazard of interest should be

declared at the point where a service is delivered (Service level hazard) as it gives the

fewest hazards to manage. If the Hazard of interest is set too far to the left, resources

may be wasted and mistakes may be made assessing an explosion of hazards that in

fact have common higher level hazards. Positioning the hazard point too far to the

right can result in real accident trajectories being missed. Therefore, positioning the

centre of the Bow Tie at the right hazard is important for an efficient and correct risk

analysis.

(4) An accident trajectory is a chain of events starting with a hazardous event and

terminating in an accident. At each event, it may be possible to arrest the progress

along the accident trajectory and, thus, avoid the accident, i.e. these events may be

used to trigger activities that reduce the effective probability or frequency of an

accident. These activities are called mitigations and are shown above as a single

mitigation. In reality, at each event, there could be considered to be an individual

mitigation, each one of a different form. There can be two outcomes of a mitigation:





— it fails and so progress towards the accident continues; or

— it succeeds and so progress is arrested and the accident does not happen.

In the second case, an incident occurs.

Note 1: In these circumstances, an incident is bound to occur since the hazard itself is

an unwanted event and any terminal event between the hazard and the accident

should be considered as an incident.

Note 2: While an incident is considered to be a terminal event, it is, of course, possible

for an incident to be the start of another, different, accident trajectory, e.g. an a/c

performing a go-around, as a result of one hazard, may fly into the path of another

a/c, thus, creating a new hazard, the result of which may, if not mitigated, be an

accident involving the go-around a/c and the other a/c. In this respect, the Bow Tie

Model is a simplification and care should be taken to account for such compound

accident trajectories when using it.

Consequently, the full Bow Tie Model is as shown below:

H1

A1

A3

A2

C1

C3

C4

C2

Accidents(Mitigations were

not successful )

HazardCauses

Mitigations

Full Cause/Hazard/Accident Model (Bow Tie Model)(for one hazard)

Mitigations may be:a) within the functional system b) within the environment

Accident Trajectory(Different circumstances

lead to different accidents)

M6

M8

M1

M3

M2

M4

M5 M7

M9

Accidents with different characteristics including different severities

M1

M2

M3

M4

Incidents(Mitigations were successful )

For clarity only single mitigations are only

shown for each cause

Mitigations between causes and hazards, shown above as a single mitigation, may also

comprise a number of mitigations, although this expansion is not shown on the

diagram. The successful outcome of these mitigations is not usually considered to be

an incident because the hazardous event will not happened if the mitigation is

successful.

(5) Care should be taken when using the Bow Tie Model to remember that it represents

only a single hazard and there will be many hazards associated with the change.

Moreover, each accident may be a result of more than one hazard. Consequently,

steps should be taken to assess the implications of both common cause and common

mode effects, for the complete part of the system involved in the change, when

related to the risks identified in each Bow Tie Model used.





(d) Severity schemes

The severity determination should take place according to a severity classification scheme.

This section provides guidance on such schemes.

(1) Severity schemes resulting in a single value of risk

The accident/incident severity scheme commonly used in ATM/ANS is the one

reproduced below:

Severity

Class

Effect on operations

1

(Most

severe)

Accident as defined in Article 2 of Regulation (EU)

No 996/2010 of the European Parliament and of the

Council154

2 Serious incident as defined in Article 2 of Regulation (EU)

No 996/2010.

3 Major incident associated with the operation of an a/c, in

which the safety of the a/c may have been compromised,

having led to a near collision between a/c, with ground or

obstacles.

4 Significant incident involving circumstances indicating that

an accident, a serious or major incident could have

occurred if the risk had not been managed within safety

margins, or if another a/c had been in the vicinity.

5

(Least

severe)

No immediate effect on safety.

(i) If this scheme is used, then only severity class 1 can be used in safety risk

analysis and safety risk evaluation155. This is because only events that can be

classified as severity class 1 could possibly cause harm to humans156. This is in

contrast to the severity classification scheme used for aircraft certification, where

the first three classes can cause death or physical injury to humans. In the

scheme above, the risks evaluated would always be proportional to the

frequency or probability of the harmful event and there would be no possibility of

comparing harmful events with different consequences. For example, a mid-air

collision involving two large commercial airliners would have the same, i.e. it

would be placed in the same, severity class as a similar accident, with the same

probability of occurrence, involving small a/c carrying one or two passengers

each and so the safety risk of the two events would be the same.

154 Regulation (EU) No 996/2010 of the European Parliament and of the Council of 20 October 2010 on the investigation

and prevention of accidents and incidents in civil aviation and repealing Directive 94/56/EC (OJ L 295, 12/11/2010, p. 35).

155 However, the whole table (rows 1 to 5) may be used in accident/incident analysis and rows 2 to 5 may be used in accident pre-cursor analysis, which can be used to validate risk analysis.

156 It should be noted that when single valued severity schemes are used, the loss of an a/c usually replaces the concept of harm to humans.





(ii) Another instance where the consequences of harmful events cannot be

distinguished using this severity scheme is where the harmful events occur at

very different speeds. For example, an accident to an a/c on a low speed taxiway

would have the same severity as an accident to the same a/c in mid-air. The

likely harm caused to the passengers would be very different in each case, but

the risk would be the same157.

(iii) In these circumstances, risk analysis would actually be reduced to

frequency/probability analysis.

(2) Background to multiple risk value severity schemes

(i) The purpose of a severity classification scheme is to facilitate the management

and control of risk. A severity class is, in effect, a container within which

accidents can be placed if their severities are considered different and to fall

within the bounds defined by the severity class. Each container can be given a

value which represents the consequences, i.e. small for accidents causing little

harm and big for accidents causing a lot of harm. The sum of the probabilities of

all the accidents assigned to a severity class multiplied by the value that is

related to the severity class, is the risk associated with that class. If the value

that represents severity for all classes is scalar, then the total risk is the sum of

the risks in each severity class.

Note that a scalar is tangible property that is expressed as the product of a

measurable numerical value and a physical unit, not merely a number. The

quantity does not depend on the unit, e.g. for distance, 1 km is the same as

1000 m, although the number depends on the unit. Examples of common scalars

include cost, mass, volume, time, speed, and temperature.

(ii) Severity classes facilitate the management and control of risk in a number of

ways. At the simplest level, the distribution of accidents across the severity

classes gives a picture of whether the risk profile of a system is well balanced.

For example, many accidents in the top and bottom severity classes with few in

between suggests an imbalance in risk, perhaps due to an undue amount of

attention having been paid to some types of accident at the expense of others.

More detailed management and control of risk includes:

(A) Severity classes may be used as the basis for reporting accident statistics.

For example, in reports by a regulator to government.

(B) Severity classes combined with frequency (or probability) classes can be

used to define criteria for decision making regarding risk acceptance. For

example, decisions regarding low severity/low frequency risks might be

made at a project level whereas acceptance of high severity/moderate

frequency risks may be made only at the highest level of an organisation.

(C) The total risk associated with one or more severity classes can be managed

and controlled so that it satisfies regulatory and/or shared managerial

objectives. For example, the sum of the risk from all severity classes

represents the total risk and may be used as a basis for making decisions

about changes.

157 That is, of course, assuming that the probability of the two events was the same.





(D) Similarly the risk associated with accident types of different levels of

severity can be compared, giving the organisation the opportunity to

manage the distribution of risk. For example comparing runway

infringement accidents with low speed taxiway accidents would allow an

organisation to focus their efforts on mitigating the accident type with

greatest risk.

(3) Attributes of multiple risk value severity schemes

(i) Because of their role in managing and controlling risk, severity classes must be

suitable for their intended application. What is good for one situation may not be

good for another.

(ii) The criteria that can be used to assess the suitability of a multiple value severity

scheme are given in point (f) of AMC1 ATS.OR.205(b). In addition, it should be

noted that criterion 5 supports criterion 2 and the two may be regarded as a

complementary pair. Criterion 2 says, in effect, that for any given accident it

must be possible to assign it to a severity class, i.e. there should be no ‘orphan’

accidents and that it must not be possible to assign it legitimately to more than

one severity class. Criterion 5 says that the assignment should be made on the

basis of rules such that there can be no doubt or difference of opinion as to

which severity class an accident should be assigned.

(iii) To illustrate the distinction between these criteria, consider a severity

classification scheme that has two classes: (x) 1 death; (y) from 2 to 100

deaths. This does not satisfy criterion 2 for accidents involving a/c since an

accident involving 120 deaths cannot be assigned to a severity class. Criterion 2

would, however, be satisfied by a scheme with the two classes: (x) 1 death; (y)

2 or more deaths. The scheme would not satisfy criterion 5, however, without

some rules. For example, an accident involving one death and five severe

injuries as its immediate consequences might be assigned to severity class (x)

on the basis of the single death. However, if it were judged that some of the

serious injuries would be significantly life shortening, then it might be argued

that these premature deaths should be counted as deaths due to the accident

and the accident assigned to severity class (y). Similarly, when accident

consequences are calculated, the assignment to a severity class might vary

according to whether the most likely or maximum credible number of deaths is

used.

(iv) Of course, it might not be possible for a specific scheme to have all 6 criteria

strongly represented. If that is the case, then they need to be prioritised. For

example, consistency with societal views of accident severity (criterion (6))

might need to be a high priority for an industry or activity that is the subject of

much public (and media) attention.

(4) General multiple risk value severity scheme

An example of a general severity scheme that supports multiple levels of risk is given

below.





Severity of Harm

Severity

Class

Harm to people158

Fatalities Serious

Injuries

Minor

Injuries

1 101 – 1 000

2 11 – 100 101 – 1 000

3 1 – 10 11 – 100 101 – 1 000

4 1 – 10 11 – 100

5 1 – 10

Another example for classifying the severity of harm could be to use the established

number of passenger capacity used for certification of a/c (more than 9 pax and more

than 19 pax) and for the operational rules for passenger evacuation (50 or more pax).

Severity of Harm

Severity

Class

Harm to people159

Fatalities Serious

Injuries

Minor

Injuries

1 > 49

2 10 - 49 > 49

3 1 - 9 10 - 49 > 49

4 1 - 9 10 - 49

5 1 - 9

A further example for classifying the severity of harm is derived from EUROCAE ED-

78A, and is shown below. This example uses a coarse scale that limits the number of

distinct severity categories. This scheme does not, in ATM/ANS, fully satisfy criterion 2

(in point (f) of AMC1 ATS.OR.205(b)) since it would be difficult to allocate an accident,

which caused a large number of injuries but few deaths, to a unique category. This

could be resolved by providing a fuller description of the level of harm to be included

in each category.

158 Strictly speaking, these injuries are additive, i.e. if an a/c carrying 100 people collided with a large skyscraper causing

additionally, several hundreds of major injuries, then, in all probability, rather than severity class 2, the accident would be a severity class 1 accident.

159 Strictly speaking, these injuries are additive, i.e. if an a/c carrying 49 people collided with a large skyscraper causing additionally, several hundreds of major injuries, then, in all probability, rather than severity class 2, the accident would be a severity class 1 accident.





Severity of Harm

Severity

Class

Harm to occupants160

1 Multiple fatalities.

2 Serious or fatal injury to a small number of

passengers or cabin crew.

3 Physical distress, possibly including injuries.

4 Physical discomfort.

5 Inconvenience.

In all the above examples, the relationship between the number of injuries and the

number of deaths is not justified161 here, but would have to be justified by any ATS

provider proposing to use such a scheme.

(i) Schemes such as these do not, in ATM/ANS, fully satisfy criterion 4 (in point (f)

of AMC1 ATS.OR.205(b)) since it will not be easy to predict precisely how many

deaths and injuries would result from an individual accident. However, the

probable mix of traffic will be known (or can be established) and the type of

accident predicted will lead to an approximation of the harm. For example, a

mid-air collision between two large a/c would fall into severity class 1, whereas a

low speed taxiway accident between two GA a/c is likely to fall into severity class

4 or 5, in the case of the first two schemes and into severity class 3 in the case

of the last scheme.

(5) Severity schemes using equivalence classes

In order to simplify the scheme and to make it more appropriate for ATM/ANS use, it

is feasible to use some other attribute of an accident to represent the number of

people harmed, i.e. the attribute can be used as an equivalence class for harm to

people. Typical equivalence classes could be:

(i) a/c size;

(ii) speed of accident; and

(iii) a combination of (A) & (B).

For example:

Severity of accident

(using a/c size as an equivalence class to harm)

Severity

Class

a/c size

1 Large, e.g. any a/c162

with a maximum certificated take-off mass

160 Strictly speaking, class 4 and 5 could not be used in safety risk assessment. 161 However, the ratio of injuries to deaths is commonly used in the railway industry. 162 The 5 700 kg or 19 pax or 2 pilots is from the definition of complex motor-powered airplane in Regulation (EC)

No 216/2008.





exceeding 5 700 kg, or

certificated for a maximum passenger seating

configuration of more than 19, or

certificated for operation with a minimum crew

of at least two pilots

2 Medium, e.g. any non-large a/c163

with a maximum certificated take-off mass

exceeding 3 175 kg, or

certificated for a maximum passenger seating

configuration of more than nine,

3 Small, e.g. any other a/c.

Another example could be to use a/c size as per AC23.13091E as an equivalence class

to harm as shown below:


(using a/c size as per AC23.13091E as an equivalence class to harm)

Severity

Class Class of Airplane as per 23.1309-1E

1 Class IV, e.g. commuter a/c and above

2 Class III, e.g. SRE, STE, MRE, or MTE greater than 6 000 pounds

3 Class II, e.g. STE, MRE or MTE less or equal than 6 000 pounds

4 Class I, e.g. SRE less or equal than 6 000 pounds

(i) These schemes could be used in constant speed environments, e.g. airways or

TMAs, where there is a mix of traffic types. The risk associated with accidents of

the same type would be evaluated according to the proportion of each size of a/c

in the environment and the probability of the accident and of the probability it

would happen to an a/c of the size allocated to the severity class.

(ii) In cases where the a/c are largely of the same size, the severity scheme shown

in (d)(1) could be used or the scheme above used, but only one row would be

relevant.


(using accident speed as an equivalence class to harm)

Severity

Class Speed of accident

1 High speed, e.g. Mid-air collision, CFIT,

Runway

2 Medium speed, e.g. High speed taxiway

3 Low speed, e.g. Low speed taxiway

163 The 3 175 kg or nine pax is from the definition of complex motor-powered helicopters in Regulation (EC) No 216/2008.





(iii) This scheme could be used where the speed range of a/c is large, but the size of

the a/c is fairly constant, e.g. in an airport environment dealing only with small

a/c. If the environment is amenable to being split into non-overlapping speed

zones, then this severity scheme would allow the organisation to manage the

risks in the different zones appropriately.

(iv) In cases where the a/c largely operate at roughly the same speed or the speed

zones overlap, the severity scheme shown in (d)(1) could be used or the scheme

above used, but only one row would be relevant.

(e) Combining severity schemes

Severity schemes may be combined to give greater granularity, greater coverage or to

make them more appropriate to the context in which they are used. The example given in

section (d)(4) was an early example of a combined severity scheme. It combined the

severity classes relating to death with two other severity classes relating to different levels

of injury. This allows the severity classification scheme to be more appropriate in

circumstances where accidents usually involve large numbers of people, but can also result

in a mix of the types of harm caused, depending on the circumstances of the accident and

often the vehicles involved.

(1) Mixed traffic environments


(using a/c size and speed as an equivalence class to harm)

Severity

Class

A/C Speed

High

Speed

Medium

Speed

Low

Speed

1 Large

A/

C S

ize 2 Medium Large

3 Small Medium Large

4 Small Medium

5 Small

Where there is both a mixed speed and mixed a/c size environment, e.g. a medium

sized aerodrome handling GA traffic as well as commuter and long haul a/c, then the

scheme shown above gives a greater level of granularity and is more appropriate for

the environment than either a speed-centred scheme or a size-centred scheme.

(2) Combining accident and incident schemes

(i) The following scheme could be used where a service provider wishes to perform

safety risk analysis, accident/incident analysis and precursor analysis using a

consistent classification scheme that can be used for all the different forms of

analysis.

(ii) Any of the severity schemes developed in sections (d)(4) and (d)(5) could be

used in place of the accident speed scheme illustrated.





Severity

Class Effect on operations

1

(Most

severe)

Accident as defined in Article 2 of Regulation (EU) No 996/2010 of the European

Parliament and of the Council, e.g.164:

one or more catastrophic accidents,

one or more mid-air collisions,

one or more collisions on the ground between two a/c,

one or more Controlled Flight Into Terrain, and

total loss of flight control.

Severity

Sub

Class

Speed of accident

A High speed, e.g. Mid-air collision, CFIT, Runway

B Medium speed, e.g. High speed taxiway

C Low speed, e.g. Low speed taxiway

2 Serious incident as defined in Article 2 of Regulation (EU) No 996/2010, e.g.:

large reduction in separation, e.g. a separation of less than half the separation

minima, without crew or ATC fully controlling the situation or able to recover from

the situation.

one or more a/c deviating from their intended clearance, so that abrupt

manoeuvre is required to avoid collision with another a/c or with terrain (or when

an avoidance action would be appropriate).

3 Major incident associated with the operation of an a/c, in which the safety of the a/c

may have been compromised, having led to a near collision between a/c, with ground

or obstacles, e.g.:

large reduction, e.g. a separation of less than half the separation minima, in

separation with crew or ATC controlling the situation and able to recover from the

situation.

minor reduction, e.g. a separation of more than half the separation minima, in

separation without crew or ATC fully controlling the situation, hence, jeopardising

the ability to recover from the situation (without the use of collision or terrain

avoidance manoeuvres).

AFIS officer is not in contact with (or aware of) one of the a/c (or vehicles in case

of runway incursion). A/c (or vehicle) needs to use avoidance manoeuvres (but

not at the last minute) to be able to reduce the risk.

4 Significant incident involving circumstances indicating that an accident, a serious or

major incident could have occurred if the risk had not been managed within safety

margins, if there had not been enough time to resolve the situation or if another a/c

had been in the vicinity, e.g.:

Increasing workload of the air traffic controller, AFIS officer or a/c flight crew, or

slightly degrading the functional capability of the enabling CNS system.

minor reduction, e.g. a separation of more than half the separation minima, in

164 Examples are taken from ESARR 4.





separation with crew or ATC controlling the situation and fully able to recover

from the situation.

Two (or more airplanes) in TIZ. No reduction in separation or risk of collision, but

the a/c flight crew or the AFIS officer is not aware of one of the a/c.

5

(Least

severe)

No immediate effect on safety, e.g.:

No hazardous condition, i.e. no immediate direct or indirect impact on the operations.

I. Rows 1A to 1C may be used in risk analysis

II. The whole table (rows 1 to 5) may be used in accident/incident analysis

III. Rows 2 to 5 may be used in accident pre-cursor analysis, which may be used to

validate risk analysis.

(f) ATS providers should coordinate their severity schemes when performing multi-actor

changes to ensure adequate assessment. This includes coordination with ATS providers

outside of the EU.

(g) Validating risk analyses

(1) It can be seen from the Bow Tie Model above ((c)(4)), that accidents and incidents are

terminal events, i.e. progress along the accident trajectory ceases at either an incident

or an accident. It can also be seen that they involve different scalar properties. The

accident scale is related to harm to people whereas the incident scale relates, in some

way, to the closeness an event is to an accident. Consequently, the severity of harm

to people cannot be related to the severity associated with the closeness of an event

to an accident and so, even though both may be related to risk, they are not

comparable risks, i.e. two distinct measures of risk will exist.

(2) There are relatively few a/c accidents from all causes and only a subset of them has

been attributed to the services provided by a service provider. It is, therefore, unlikely

that a service provider will be the cause of an a/c accident in any given year. If the

risk analysis for a change is to be based solely on safety risk, i.e. in relationship to an

a/c accident, it will be very difficult to generate any meaningful performance measures

and so validate the risk analysis. Any measured data would have to be taken over

decades in order to eradicate any statistical anomalies. Furthermore, even if the

service provided by a service provider is the cause of an a/c accident, this fact alone is

not sufficient proof that they have not met the safety criteria, because, very much like

the lottery, your number could be up tomorrow. It is, therefore, advisable to use

measures different to accidents for the purposes of validating risk analyses.

(3) The safety philosophy adopted in the air transport domain is one of fault tolerance,

accepting that in general no system is perfect and so will always fail. This leads to the

concept of a series of defensive barriers between a hazard and an accident, the

protective nature of which is determined by the actions of mitigations. A generalised

set of barriers for mid-air collision accident model is illustrated below:





Accident

Resolved byPilot

Resolved byProvidence

Resolved byATCO

without assistance

Resolved byATCO with assistance

Incidents

Increasing ‘Distance’(from the accident)

Barriers

Mit

igat

ion

FailsHazard

Succeeds

(4) The barriers are placed in the order shown because they notionally represent the

barriers’ ‘distance’ from an accident. In this context, ‘distance’ does not simply mean

separation distance, but some notion of the likelihood of the accident if the barriers

were to fail, e.g. the probability of an accident increases at each point along an

accident trajectory towards the accident and so its ‘distance’ to the accident

decreases. This should not be taken to preclude the use of separation distance.

(5) Since in the circumstances where an a/c is receiving a separation service, it is the

ATCO who is responsible for the operation of the overall separation strategy, then

he/she should have the most complete situational awareness and so be the first to

spot a potential accident and resolve it (‘Resolved by ATCO without assistance’ on the

diagram), even though the conflict may have been caused by the ATCO in the first

place. If the potential for an accident is not spotted, then other systems may alert the

ATCO to the potential for an accident and are, therefore, considered to be a barrier.

These systems are not necessarily ‘mechanical’, but could be a local ATCO or one from

a different unit alerting the ATCO in charge to the circumstances. Hence, the second

barrier is the ‘ATCO with assistance’.

(6) The pilot is likely to have an incomplete picture of the situation, but, nonetheless, may

be aware of becoming too close to another a/c or object. He/she may, therefore,

either alert the ATCO to the potential for an accident or take avoiding action and then

tell the ATCO what he/she has done. The third barrier, ‘resolved by pilot’ on the

diagram, is, therefore, the pilot. In a similar manner to the second barrier, there are

a/c systems (which may include the co-pilot or the pilot of another a/c) that alert the

pilot of the impending accident with TCAS being one example. These are included in

the third barrier in the diagram.

(7) Failure of the first three barriers still does not entail an accident. Providence, shown as

‘Resolved by Providence’ on the diagram, will play a part in avoiding the accident.





Research has shown that in some airspaces the probability of a collision, when both

ATCO and pilot barriers have failed, is approximately 300:1, which may well make it

stronger than most of the barriers. Its strength relies on the generally low density of

the airspace and on airspace policy.

(8) The Bow Tie Model may be modified in order to show the relationship between the

mitigations designed into an accident trajectory and the incidents resulting from the

success of those mitigations, i.e. a specific incident within a specific barrier, as shown

below:

H1

A1

A3

A2

C1

C3

C4

C2

AccidentsHazardCauses

Bow Tie Model using barriers(for one hazard)

M5

M8

M1

Barriers

Incidents Associated

with the same Barrier

M3

M2

M4

M9M7

M6

Accidents with different characteristics including different severities

M1

M2

M3

M4





Incidents with different characteristicsGrouped by Barrier

Incident rates are, therefore, associated with accident rates. Provided that the

relationships between the incidents associated with each barrier and the accidents are

well understood, and since such incidents will be far more frequent than the

associated accidents, they may be used to overcome the difficulty, identified in (2), of

validating the risk analysis and in giving sufficient confidence that the predicted

accident rates will be achieved. Moreover, if either risk or proxies are being used in

risk analysis, the design frequency of the incidents will be known and could, therefore,

become some of the monitoring requirements that show continuing satisfaction of the

safety criteria (ATS.OR.205(b)(7)).

(9) Although it should be a design aim to balance the incident rates associated with

different barriers, a change that makes a mitigation stronger will result in the

incidents associated with the mitigation occurring at a higher rate than before. This

may seem to unbalance the relationship between incident rate and distance from the

accident. However, this should be of only minor concern since the risk has in fact

decreased, which is a positive outcome.

(10) The diagram shows that for some accident trajectories there may be no mitigations or

more than one mitigation. The reason that there may be no mitigations is that there is

a common cause associated with the hazard and the normal mitigation means, e.g. if

the hazard was caused by some corruption in surveillance that also had an impact on





the STCA, then there may be no mitigations in the second barrier for that particular

accident.

(11) The reason that there may be more than one mitigation within a barrier is that there

may be more than one independent means of arresting the accident progression

within the barrier, e.g. the use of an STCA and someone else (another ATCO or a

pilot) independently alerting the ATCO to the conflict.

(12) The ease with which a compelling and comprehensible safety case can be produced

will be significantly enhanced by designing and evaluating mitigations for the change

that may be used to predict the incident rate, i.e. to design for known pre-cursors,

and so it is recommended that all ATS providers use the concepts proposed here in

their design processes.


system

SAFETY ANALYSIS IN TERMS OF PROXIES

(a) AMC1 ATS.OR.205(b) Safety assessment and assurance of changes to the functional system

SAFETY ASSESSMENT PROCESS (d) ‘Determination of the safety criteria for the change’

allows safety assessment to be performed in terms of risk, proxies or a combination of risk

and proxies. In this section, two examples are given to assist in the selection and use of

proxies in safety analysis.

(b) Use of proxies when assessing the safety of a wind farm installation

(1) A wind farm is to be introduced on or near an aerodrome. It is assumed that before

the introduction of the wind farm, the safety risk of the ATS services being provided at

the aerodrome was acceptable. To return it to this level after, the change would also

be acceptable.

A diagram showing the effects this has on the risk at the aerodrome is shown below:

Risk to traffic

(without ATS)

Comms

(VHF)

Vision

(Flicker)

Control

(Turbulence)

Move

Taxiiway

Move

TX/RX

Surveillance

(Radar)

ATS risk reduction

Risk to traffic after

introduction of wind farmRisk to traffic prior to the

introduction of the wind farm

Proxies

Risk

?Safety Acceptance Criteria (Proxies):

1. Control – Turbulence

2. Communications – Signal quality

3. Vision – Human error rate

Risk

Reduce

Transmisivity

① ②





(2) The risk due to the introduction of the wind farm from will rise from ① to ②, if not

mitigated, because:

(i) turbulence will increase and so may destabilise manoeuvring of a/c;

(ii) the movement of the blades will cause radio interference (communications radio

and surveillance radar) and so communications may be lost or a/c may be

hidden from view on the radar screen; and

(iii) the flicker in the peripheral vision of ATCOs, caused by the rotation of the

blades, may capture attention and increase their perception error rate.

(3) The problem of analysing the safety impact can be split into these areas of concern

since they do not interact or overlap and so satisfy criterion (3)(ii)165. However, whilst

it can be argued that each is a circumstantial hazard and that in each case a justifiable

qualitative relationship can be established linking the hazard with the resulting

accident (so satisfying criterion (3)(i)) the actual or quantitative logical relationship is,

in each case, extremely difficult to determine. Conditions for seeking proxies have,

therefore, been established:

— performing a risk evaluation using actual risk may not be worthwhile due to the

considerable cost and effort involved; and

— the first two criteria for proxies have been satisfied.

Consequently, it may be possible to find proxies that can be used more simply and

effectively than performing an analysis based on risk.

(4) The solutions proposed below are for illustrative purposes only. There are many other

solutions and for each change several should be investigated. In this example, the

following proxies, which satisfy criterion (3)(iii), are used to set safety criteria:

(i) Turbulence can be measured and predicted by models so the level of turbulence

can be a proxy.

In this example, let’s assume the only significant effect of turbulence is to light

a/c using a particular taxiway. It is possible to predict the level of turbulence at

different sites on the aerodrome and an alternative taxiway is found where the

level of turbulence after the introduction of the wind farm will be less than that

currently encountered on the present taxiway. This can be confirmed during

operation after the change by monitoring.

(ii) Signal quality can be also be predicted by models and measured so it can be

used as a proxy.

In this example, it is possible to move the communications transmitter and

receiver aerials so that communications are not affected by interference. Sites

can be found using modelling and the signal quality confirmed prior to moving

the aerials by trial installations during periods when the aerodrome is not

operating.

(iii) Human error rate in detecting events on the manoeuvring area can be measured

in simulations and can be used as a proxy.

It is suggested that increasing the opaqueness of the glass in the control tower will

reduce the effects of flicker on the ATCOs, but there is no direct relationship between

the transmissivity and the effects of flicker. It is, therefore, decided to make a

165 References to Proxy criteria are given in point (d) of AMC1 ATS.OR.205(b).





simulation of the control tower and measure the effects of flicker on human error rate

using glass of different levels of transmissivity.

However, there is a conflict between increasing the opaqueness of the glass to reduce

the effects of flicker and decreasing it to improve direct vision, which is needed so that

manoeuvring a/c can be seen clearly. In other words, the simulation predicts a

minimum for the human error rate that relates to a decrease, as the effects of flicker

decrease, followed by an increase, as the effects of a lack of direct vision increase.

This minimum is greater than the human error rate achieved by the current system

and so the risk of the wind farm, in respect of flicker, cannot be completely mitigated.

This is shown by the red box with a question mark in it on the diagram.

(5) Finally, the argument for the performance of surveillance radars is commonly

performed using risk. This can be repeated in this case since the idea is to filter the

effects of the interference without increasing the risk. Moreover, if necessary, a

system may be added (or a current one improved) to reduce the risk simply and

economically and the effects of the additional system may be argued using risk.

(6) Since risks can be combined, the safety impacts of the changes to the surveillance

radar by filtering the effects of the interference together with the addition of another

system or the improvement of the current system can be established by summing the

risks associated with these two kinds of change.

(7) In these circumstances, it is not possible to argue objectively that the risk of

introducing the wind farm has been mitigated, as risks cannot be summed with

proxies. This demonstrates the difficulties of using proxies. However, it may be

possible to argue convincingly, albeit subjectively, that installing another system or

improving the current system improves the current level of risk by a large enough

margin that it provides adequate compensation for the unmitigated effects of flicker.

(8) In summary, this example shows how proxies and risks can be combined in a single

assurance case to argue that a change to a functional system can be introduced

safely.

(c) Use of proxies when changing to electronic flight strips.

(1) An ATS provider considers the introduction of a Digital Strip System in one of its Air

Traffic Control Towers to replace the paper Flight Progress Strips currently in use. This

change is expected to have an impact on several aspects of the Air Traffic Control

service that is provided, such as the controller’s recollection of the progress of the

flight, the mental modeling of the traffic situation and the communication and task

allocation between controllers. A change of the medium, from paper to digital, might,

therefore, have implications on the tower operations, and, hence, on the safety of the

air traffic. The actual relation between the change of the strip medium and the risk for

the traffic is, however, difficult to establish.

(2) The influence of the quantity on the risk is globally known, but cannot easily be

quantified. One difficulty is that strip management is at the heart of the Air Traffic

Control operations: the set of potential sequences of events from a strip management

error to an accident or incident is enormous. This set includes, for example, the loss of

the call sign at the moment a ground controller needs to intervene in a taxiway

conflict, and whether this results in an incident depends for example on the visibility.

This set also includes the allocation of a wrong Standard Instrument Departure (SID)





to an a/c, and whether this results in an accident depends for example on the runway

configuration.

Figure 1: The Bow Tie Model of a strip management error has, figuratively speaking,

a vertically stretched right part. This expresses that a hazard — such as the loss of a

single strip — may have many different outcomes which heavily depend on factors

that have nothing to do with the cause of the hazard — factors such as the status of

the a/c corresponding to the absent strip, that a/c’s position on the aerodrome, the

traffic situation and the visibility.

(3) Another difficulty with the relationship between the change of the medium and the risk

to the air traffic is that several human and cultural aspects are involved. The difficulty

lies in the largely unknown causal relations between these human and cultural aspects

and the occurrences of accidents and incidents. As an example of this, it is noted that

strip manipulation — like moving a strip into another bay, or making a mark to

indicate that a landing clearance is given — assists a controller in distinguishing the

potential from the actual developments. The way of working with paper strips

generates impressions in a wider variety than digital strips by their physical nature:

handling paper strips has tactile, auditory and social aspects. This difference in these

aspects may lead to a difference in the quality of the controller’s situation awareness

which may lead to a difference in the efficacy of the controller’s instructions and

advisories, which may lead to a difference in the occurrence of accidents and

incidents. However, the relation between the change of the medium and the risk for

the air traffic is difficult to assess and would require a great deal of effort, time and

experimentation to quantify.

Figure 2: There is probably a relation between the change of the flight progress strip

medium and the risk for air traffic: a new Human-Machine-Interface may have an

effect on the situation awareness of some individual controllers in some

circumstances, which might have an effect on whether, when and what instructions

are given, and this in turn influences the a/c movements, and, hence, the risks. The

question by what amount risks increase or decrease is very hard to answer.

Change

SituationAwareness

Qualityinstructions

Risk for traffic

?





(4) Performing a risk evaluation using actual risk may not be worthwhile due to the

difficulties and considerable cost and effort involved in assessing the risk of the

change directly. Therefore, the use of proxies might be preferred. A quantity is only

considered an appropriate proxy if it satisfies the conditions in point (d)(3) of AMC1

ATS.OR.205(b):

(i) causality: The quantity used as proxy can be expected to be influenced by the

change, and the risk can be expected to be influenced by the quantity. In

addition to this causal relationship, a criterion can be formulated and agreed

upon that expresses by which amount the value of the quantity may shift due to

the change. Note that the influence of the proxy on the risk cannot easily be

quantified, otherwise it might be more beneficial to use risk as a measure and

the quantity as an auxiliary function.

(ii) measurability: The influence of the change on the quantity can be assessed

before as well as after the change.

(iii) independence: when the proxy selected does not cover all hazards, a set of

proxies should be used. Any proxy of that set should be sufficiently isolated from

other proxies to be treated independently.

Figure 3: There is a relationship between the change and the proxy, and there is a

relationship between the proxy and the risk to traffic. The first relationship can be

assessed (indicated by the ‘!’), while the second cannot (indicated by the ‘?’). An

acceptance criterion is typically formulated for the amount the proxy value might

increase or decrease.

(5) Proxy 1: Head down time. The head down time is a good proxy as it satisfies the

conditions of:

(i) causality. It is known that less head down time leads to a higher risk but there is

no well-established or generally accepted statement in literature in terms of: ‘x

% more head down time implies y% more accidents’, leave alone for the specific

circumstances of the specific ATC tower. The causal relationship indicated in

Figure 3 can be established because:

(A) the head down time can be expected to change as the manipulation,

writing and reading of digital strips might cost more, or perhaps less,

attention and effort than the handling of paper strips;

(B) the loss of head up time of ground and runway controllers implies less

surveillance, at least less time for the out-of-the-window-view in good

visibility, and this implies a later or less probable detection of conflicts; and

(C) an example of an acceptance criterion reads: ‘The introduction of the

Digital Strip System does not lead to a significant increase in the head

down time’.

Change Proxy Risk for traffic! ?





(ii) measurability. The influence of the change on the head down time can be

assessed before the change by means of real-time human-in-the-loop

experiments in which controllers are tasked to handle equal amounts of traffic in

equal circumstances, one time using paper strips and another time using digital

strips. The percentage of head down time can then be determined by observing

the controllers by cameras and eye-trackers.

(6) Proxy 2: Fraction of erroneous SID allocations. The fraction of erroneous SID

allocations is a good proxy as it satisfies the conditions of:

(i) causality. It can be imagined that an erroneous SID selected in the FMS might

lead to accidents, but the precise conditional probability is small and difficult to

estimate as it depends on several external factors such as the flight paths of the

correct and incorrect SIDs, the presence of other traffic, the timing and

geometry of the trajectories, the cloud base or the vigilance of the controller.

The causal relationship indicated in Figure 3 can be established because:

(A) the number of incorrect SIDs indicated on electronic strips can be expected

to be less than on paper strips, because of the possibilities of systematic

checks with respect to runway allocation, runway configuration, SID

allocation of the predecessor and destination in the flight plan;

(B) the allocation of an incorrect SID to an aircrew might lead to a situation in

which the a/c manoeuvres in an unanticipated way, possibly leading to a

conflict with another a/c, for example departing from a parallel runway;

and

(C) an example of an acceptance criterion reads: ‘The introduction of the

Digital Strip System should lead to a decrease of the fraction of erroneous

SID allocations of more than 20 %’.

(ii) measurability. The influence of the change on the fraction of erroneous SID

allocations can be assessed before the change by means of an analysis of the

causes and occurrences of such errors and the estimated efficacy of the

systematic checks. The fractions can be assessed after the change by the statics

of the event reports.

(7) Finally, the last condition of independence of proxies is also satisfied. The proxies in

(5) and (6) form a set of independent proxies that can be considered complete to

cover all identified hazards introduced by the replacement of paper strips by a Digital

Strip System.


system

OUTCOME OF RISK EVALUATION

The purpose of risk evaluation is to evaluate the risk of the change and to compare that to the

safety criteria with the following outcomes in mind:

(a) A possible (desired) outcome is that the assessed risk satisfies the safety criteria. This

implies that the change is assessed as sufficiently safe to implement (indicated by ‘no’ at

the right of the box ‘mitigating means’ in Figure 1 — Schematic representation of the risk

assessment process in GM3 ATS.OR.205(b) ‘Safety assessment and assurance of changes

to the functional system’).





(b) Another possible outcome is that the assessed risk does not satisfy the safety criteria. This

might lead to the decision to refine the risk analysis, to the decision to add mitigating

means (indicated by ‘yes’ at the right of the box ‘mitigating means’ in Figure 1 — Schematic

representation of the risk assessment process in GM3 ATS.OR.205(b) ‘Safety assessment

and assurance of changes to the functional system’), or to the decision to abandon the

change (indicated by ‘no’ below the box ‘risk acceptance’ in Figure 1 — Schematic

representation of the risk assessment process in GM3 ATS.OR.205(b) ‘Safety assessment

and assurance of changes to the functional system’).


system

RISK EVALUATION — UNCERTAINTY

(a) The outcome of a risk analysis is uncertain due to modelling, estimates, exclusion of rare

circumstances or contributing factors, incident and safety event underreporting, false or

unclear evidence, different expert opinions, etc. The uncertainty may be indicated explicitly,

e.g. by means of an uncertainty interval, or implicitly e.g. by means of a reference to the

sources the estimates are based upon.

(b) Where possible sequences of events, contributing factors and circumstances are excluded in

order to simplify the risk estimate, arguments and evidence justifying, this should be

provided in the safety case.


system

RISK EVALUATION — FORMS OF RISK EVALUATION

The risk evaluation can take several forms, even within the safety assessment of a single change,

depending on the nature of the risk analysis and the safety criteria:

(a) If a sufficient set of safety requirements has been created and can be unambiguously and

directly related to the safety criteria, then risk evaluation takes the form of justifying that

these requirements satisfy the safety criteria;

(b) If the frequency of occurrence of the hazards, the severity of occurrence of the harmful

effects and the frequency of occurrence of these effects given the occurrence of the hazards

have been determined, then risk evaluation takes the form of verifying that the assessed

risks satisfy the safety criteria in terms of risks; and

(c) If the levels of all relevant proxies have been determined, then risk evaluation takes the

form of verifying that these levels satisfy the safety criteria in terms of proxies.


system

RISK EVALUATION SCHEMES

(a) Risk evaluation, whether using risk or proxies, can take two forms:

(1) Each accident is allocated a fixed risk or proxy target and the change is designed to

achieve the targets, or

(2) The risk is evaluated using:

(i) the actual risk of each accident summed with other risks relating to the same

safety criterion to form a total risk value for the associated safety criterion; or





(ii) the proxy value associated with each accident summed with other or proxy

values relating to the same safety criterion to form a total proxy value for the

associated safety criterion; or

(iii) A combination of both the above methods.

The value of each risk or proxy value is not constrained in any other way.

(b) The use of a fixed target for the risk associated with each accident is convenient because it

is simple to use and efficient in application. However, it has the following drawbacks:

(1) It reduces design freedom;

(2) The choice of target must be justified, i.e. since it effectively divides the total

acceptable risk of the operation into a number of accidents (possibly of different

severities), then the total number of accidents (of each severity) needs to be known.

(3) Targets need to be set with a significant degree of conservatism. If the targets are to

be used over a significant number of changes without adjusting their values, in order

to preserve the convenience and ease of use of the scheme, they must be set very

conservatively. This is so that they can absorb the variations in the number of

accidents that can occur at each change.

(c) The evaluation of actual risk allows for a large degree of design freedom, simply by placing

no constraints on the design other than to ensure that the risk of the change is ultimately

acceptable, via compliance with the various safety criteria. However, it has the following

drawbacks:

(1) It may lead to a number of design iterations. This would occur if the design were not

sufficiently conservative and so make it likely that it would not achieve the safety

criteria during the first iteration.

(2) Some constraints on the variation in risks across the range of equivalent accidents

may be necessary in order to give a well-balanced distribution of risk or to alleviate

societal concerns. For example, it may not be appropriate to allow a single accident to

occur very much more often that other accidents in the same severity class even

though the total risk is acceptable.

The design of mitigations that achieve known predictable incident rates is still a

recommended feature of the design of the change when this form of risk evaluation is used.

(d) Some fixed risk evaluation schemes do not use safety risk, but use the notion of ‘distance’

from an accident as the severity scale and may set targets for incidents as well as

accidents. Such schemes have additional drawbacks:

(1) The target for accidents is not safety risk-based and so risk-based comparisons cannot

be performed making it difficult to alleviate societal concerns.

(2) The scalar used for ‘distance’ from accidents needs to be defined and justified.

(3) Additional constraints are placed on the design due to the need to design the change

such that it satisfies not only the accident target, but also the incident targets between

the hazard and the accident. In other words, since the relationship between incidents

and accidents is pre-defined in these schemes, the design of the change is constrained

by these relationships.






system

TYPE OF RISK MITIGATION

Risk mitigation may be achieved in the following ways:

(a) an improvement of the performance of a functional subsystem;

(b) an additional change of the ATM/ANS functional system;

(c) the implementation of a safety net;

(d) an improvement of the services delivered by third parties;

(e) a change in the physical environment; or

(f) any combination of the above-mentioned methods.

GM1 ATS.OR.205(b)(6)(ii) Safety assessment and assurance of changes to the

functional system

As the complete behaviour of the change is reflected in satisfying the safety criteria for the

change, no safety requirements are required at system or change level. Nevertheless, safety

requirements can be placed on the architecture and the components affected by the change. This

is addressed in AMC.


system

(a) Monitoring is intended to maintain confidence in the safety case during operation of the

changed functional system. At entry into service, the safety criteria become performance

criteria rather than design criteria. Monitoring is, therefore, only applicable following entry

into service of the change. This is further explained in point (c)(11) of

GM1 ATM/ANS.AR.C.035 & ATM/ANS.OR.A.045 ‘General’, where the monitoring referred to

here is called ‘permanent monitoring’.

(b) Monitoring is likely to be of internal parameters of the functional system that provide a good

indication of the performance of the service. These parameters may not be directly

observable at the service level, i.e. at the interface of the service with the operational

context. For example, where a function is provided by multiply redundant resources, the

availability of the function will be so high that monitoring it may not be useful. However,

monitoring the availability of individual resources, which fail much more often, may be a

useful indicator of the performance of the overall function.

GM1 ATS.OR.205(b)(1)(i) Safety assessment and assurance of changes to the

functional system

DEFINITIONS

(a) A functional system can be divided into functional subsystems, although system and

subsystem may be used synonymously.

(b) In addition, for brevity and in agreement with normal systems nomenclature, ‘system’ and

‘subsystem’ are used as synonyms for ‘functional system’ and ‘functional subsystem’.

(c) An element can comprise only sub-elements of the same type, i.e. equipment, procedure,

human resource.

(d) An element can be a set or assembly of elements of the same type, e.g. a group of people,

a set of procedures or a collection of equipment.





(e) Elements and sub-elements may be used synonymously.

(f) A system or subsystem can comprise elements of different types.

(g) A subsystem that comprises only either equipment elements, procedural elements or human

resource elements is also an element.

(h) There is no unique way of decomposing systems into subsystems or elements.

(i) A subsystem is viewed/described as a component when, for the current analysis, there is no

interest in its composition, i.e. the subsystems (parts) it consists of.

(1) For example, a control tower may be considered to be a component, where the

analytical view is that of the parts of an airport even though the tower actually

consists of many elements of different types, e.g. the control tower consists of people,

procedures and equipment.

(2) The definition of what is viewed as a component is not absolute, but depends on the

analysis being carried out, i.e. in the hierarchy of the subsystems of a functional

system, a subsystem may be viewed as a component for one analysis and may be

considered to be part of a component for a different analysis.

GM1 ATS.OR.205(b)(1)(iii) Safety assessment and assurance of changes to the

functional system

INTERACTIONS

The identification of changed interactions is necessary in order to identify the scope of the change

because any changed behaviour in the system comes about via a changed interaction. Changed

interaction happens via an interaction at an interface of the functional system and the context in

which it operates. Consequently, identification of both interfaces and interactions is needed to be

sure that all interactions have identified interfaces and all interfaces have identified interactions.

From this, all interactions and interfaces that will be changed can be identified.

GM1 ATS.OR.210(b)(1) Safety criteria

OTHER MEASURES REALATED TO SAFETY RISK

In the safety assessment of functional systems, it may not always be possible or desirable to

specify safety criteria in terms of quantitative values of risk. Instead, safety criteria may be

defined in terms of other measures that are related to risk. These measures are called proxies in

this Decision and they need to meet the requirements for a proxy as stated in point (d)(3) of

AMC1 ATS.OR.205(b). For a definition, see GM1 ATS.OR.205(b)(3), and for examples of their use,

see GM2 ATS.OR.205(b)(4).


4. Regulatory Impact Assessment (RIA)




4.1. Issues to be addressed — General overview

Please refer to point 2.1 of the Explanatory Note.

4.2. Structure of the RIA

The Agency has performed a Regulatory Impact Assessment (RIA) for a number of key

regulatory developments proposed in this NPA addressing the issues identified below:

— Risk-based review decision by the competent authority;

— Risk-based review by the competent authority;

— CNS providers performing safety support assessment instead of safety assessment;

— Severity classification scheme moved from IR to GM; and

— Changes affecting software and Regulation (EC) No 482/2008.

4.3. Risk-based review decision by the competent authorities

4.3.1. Issue to be addressed

Article 10 of current Regulation (EU) No 1034/2011 requires the competent authority to

review the safety arguments associated with changes to functional systems in certain

situations, implying that this is the result of a risk-based decision. However, the existing

requirements in point 1 of Article 10, if applied strictly, is not risk-based since it makes the

review subject to the severity of the effects of the identified hazards without considering

the likelihood dimension of the risk. Moreover, the decision to review can only made once

the service provider has completed the severity assessment of the notified change. The

problem with this approach is that the severity assessment occurs later during the

assessment of the change. It is very likely that it takes place well after the service provider

has notified the CA of the change, or if it is provided at the time of notification, it is likely

that the severity is assigned subjectively and not based on a thorough assessment, which

will happen later. Since a decision will be expected soon after the notification, the CA is

unlikely to have all the information needed in order to make their decision.

In addition, in the existing Regulation, a review is required if the implementation of the

change to the functional system requires the introduction of new aviation standards. This

also seems to support the notion that the decision is risk-based. The criteria themselves do

not clarify what circumstances would lead to the creation of a new aviation standard and,

therefore, its implementation is subjective.

It has been found that the implementation of the current Regulation is not harmonised and

substantial difficulties have been experienced by the competent authorities in complying

with the requirement. Moreover, there is insufficient information in the regulatory or

explanatory material to resolve these inconsistencies.

4.3.2. Safety risk assessment

The risks of not implementing risk-based review selection are the following:

— To review a change unnecessarily. This will result in a waste of the efforts of both

competent authorities and service providers, which are already scarce. That effort

could be devoted to performing other useful safety management activities.





— Not to review a change which is flawed risks putting an unsafe change into operation.

4.3.3. Who is affected?

Competent authorities (National Supervisory Authorities (NSA) and the Agency acting as a

competent authority), the service providers and the Agency rulemaking and

standardisation activities.

4.3.4. How could the issue/problem evolve?

If the regulatory framework does not change, the issue identified will continue to exist. The

situation could even become worse as the framework for the service providers will evolve

without a parallel evolution from the competent authorities’ side. Harmonisation in the

implementation of changes required at the European level, e.g. those changes stemming

from the implementation of SESAR, could be jeopardised.

4.3.5. Objectives

The general objectives of this NPA are described in Section 2.2 of the Explanatory Note.

The specific objective to be achieved here is to provide clear and correct regulation and

guidance on how a competent authority selects a notified change for review, based on risk.

4.3.6. Policy options

The following options have been identified:

Table 1: Selected policy options

Option

No

Short title Description

0 Do nothing Baseline option (no change in rules; risks remain as outlined in the

issue analysis).

1 Remove the concept of the

risk-based decision to review an assurance case

To remove the concept of risk-based selection and to leave the decision to review an assurance case of a change solely in the hands

of each competent authority and ultimately in the hands of each individual reviewer.

2 Delay the development of the requirements until sufficient

experience

exists to write them

This option proposes to delay the development of the risk-based review decision requirement until there is sufficient material to ensure its harmonised implementation. With this option, some AMC/GM could be provided to gather experience in the way the CAs would apply such a concept. However, the content of such AMC/GM would only be based

on the size, span, complexity and novelty of a change and may only be

loosely risk based. The preparation of the IR for risk-based review decision and the further development of AMC/GM could be done after further study is made complementing the study already done by UK-CAA.

3 Propose a coherent risk-based rule but delay implementation until sufficient


This option proposes to include the risk-based selection clause in the IR and to publish guidance on its meaning and intended consequences, but to delay implementation until further study foreseen has been completed and adequate AMC material has been written. In this way, competent authorities and service providers would be aware of the intentions and would have guidance material explaining how the

proposed system is supposed to work and can, therefore, plan their own efforts to accommodate the regulatory change when it happens.





While all these options were previously identified during the work done by the Agency with

the Rulemaking group for RMTs.0469 & 0470, only Option 0 and Option 3 were finally

considered. The other options were not considered as they did not follow the Agency/EC

policy of continuously improving the implementation of risk-based oversight, in order to

optimise the use of the scarce resources within competent authorities and within the

service providers. Therefore, only these two options are considered when analysing the

impacts.

4.3.7. Analysis of impacts

4.3.7.1 Safety impact

Option 0: With this option, the provision governing the risk-based review decision will

not be changed, therefore, there should not be any additional safety impact compared to

today’s situation. However, as explained previously, the strict implementation of the

existing requirements could lead to a situation in which all assurance cases should be

reviewed. If this were to be the case, then there could be a negative impact on safety as

it could lead to an inefficient way of using the scarce resources within the service

providers and competent authorities. However, as it is clear that the competent

authorities do not review all changes planned by the service providers, the safety impact

for this option has been set to 0.

Option 3: Once the proposed ‘risk-based’ review decision implementing rule and its

supporting AMC and GM have been implemented and are applicable, a positive safety

impact is expected as a consequence of the more efficient use of the scarce resources,

which would allow their reallocation to other more important issues.

4.3.7.2 Economic impact

Option 0: With this option, the regulatory framework will not be changed, therefore,

there should not be any additional economic impact compared to today’s situation.

However, as explained previously, the strict implementation of the existing requirements

could lead to a situation in which all assurance cases should be reviewed leading to an

increase in the costs of both service providers and competent authorities. This would

have a negative economic impact. However, as it is clear that the competent authorities

do not review all changes planned by the service providers, the economic impact for this

option has been set to 0.

Option 3: The implementation of any new regulation is likely to transiently increase

oversight costs as there will be a need to change existing procedures of the competent

authorities and there will also be a need to train the personnel responsible for overseeing

the service providers. It may also be useful to train the relevant service providers’ staff

so as to ensure facilitation of compliance with the applicable requirements. However, in

the long term, the costs may well decrease as the certainty associated with the rule

improves the efficiency of both the competent authorities and the service providers. This

decrease can also be associated with the implementation of risk-based review decision of

assurance cases. Therefore, the overall economic impact can be set to 0 when

implementing the new proposed provisions.

Question 8: The Agency would like to seek the stakeholders’ views on the

economic impact analysis. If a stakeholder does not agree, the Agency would

appreciate it if cost estimates are provided in justification.





4.3.7.3 Impact on ‘better regulation’ and harmonisation


there is no change compared to today’s situation. However, as explained previously, the

exiting regulation with regard to the selection for review, has led to a non-harmonised

implementation of the decision to review the changes across the EU and, therefore, it has

a negative impact on harmonisation.

Option 3: The clarity and fuller definition of this proposed provision is expected to create

a better regulation, i.e. risk-based and efficient, and to increase regulatory harmonisation

provided it is implemented in the way foreseen and as described in the supporting AMC

and GM. It is, however, necessary to emphasise that this positive impact on regulatory

harmonisation is a long-term effect and is only to be expected once the relevant staff are

properly trained and only after the transition period.

4.3.8. Comparison and conclusion

4.3.8.1 Comparison of options

The summary of the impacts by the different options can be found below.


Type of impacts Option 0

Do nothing

Option 3

Propose a coherent

risk-based rule, but

delay

implementation until

sufficient experience

exists to use it.

Safety impacts 0 +

Economic impacts 0 0

Regulatory coordination and harmonisation - +

Overall impact - +

Therefore, the preferred option is Option 3 and it is the one proposed in this NPA.

Some material explaining the risk-based selection model already exists. The model was

shown to be feasible in a study conducted by the UK CAA, which has been reviewed by

both the Rulemaking group for RMTs.0469 & 0470 members and the Agency. This study

argues that the principles and criteria needed to build a feasible risk-based selection model

that can achieve its intended purpose do exist. However, it recognises that before

mandating the model, it should be validated, i.e. the model should be implemented by

several CAs, and shown to be effective and lead to harmonisation. The proposed GM in this

NPA reflects the content of this study, outlines the model and describes the steps to

implement it. Consequently, it is felt that ample guidance material is provided in order to

prevent disharmony due to competent authorities wasting effort in developing short-lived

processes. Option 3, therefore, includes the risk-based selection clause in the IR and

guidance on its meaning and the intended method for enumerating the risk. However, the

validity of the model needs to be confirmed in practice and, consequently, implementation





will be delayed until the work foreseen in the feasibility study has been completed and

adequate AMC material has been written. In this way, competent authorities and service

providers are aware of the intentions and have guidance material explaining how the

proposed system is supposed to work and can, therefore, plan their own efforts to

accommodate the regulatory change when it happens.

The drawback of this approach is that since there will be no harmonised approach for some

time, the competent authorities and service providers may still go in different directions

and it would be difficult to realign them when the IR together with the AMC material is

applicable. However, in mitigation, the guidance material should give a relatively clear

steer to those establishing their own procedures and the Agency should closely monitor

and help to harmonise these developments.

4.3.8.2 Sensitivity analysis

As already explained, the main uncertainty with the preferred option is that there is still a

need to validate the proposed model and so enable the creation of a harmonised AMC for

risk-based review selection across Europe. The result of the study may be negative in the

sense that either a model is not feasible or its application does not bring harmonisation.

In that case, the Agency should re-evaluate the requirements related to the risk-based

selection and build an approach on different criteria. It might also lead to a re-evaluation

of the previously set objectives, even though this would appear to invalidate the

approach of Option 3.

4.3.8.3 Monitoring and ex post evaluation

Taking into account the sensitivity analysis made in 4.3.8.2, it is proposed to monitor the

implementation of these provisions after the transition period. One way of monitoring the

implementation is via means of standardisation inspections. For instance, if the Agency

observes, via means of standardisation inspections that the level of harmonisation of this

provision is worse than today (e.g. increase of number of findings to this provision), then

a re-evaluation of this provision will be made.

4.4. Risk-based review by the competent authorities


As already foreseen in Article 10 of Regulation (EU) No 1035/2011, the review of the

notified change is to be risk based. However, this provision is ambiguous without GM and

AMC to explain what risk the review should be subject to and how to modulate the review

appropriately. As in the case of the decision to review, sufficient material to clearly and

objectively define this risk and the means of modulating the review does not exist. While

the GM provided for the risk-based decision can be used by the competent authorities to

select the safety cases for review, the risk on which the level of the review is to be based

has not been clearly defined. Moreover, the lack of specific AMC or GM on the breadth and

depth of the review could jeopardise the harmonised implementation of such provision.

The aim of a risk-based review is to ensure that the competent authority’s scarce

resources, for the review of changes, are focused on the most relevant/important parts of

the assurance cases, i.e. they do not waste resources reviewing parts of the assurance

cases that are less likely to be wrong or, even if they were wrong, would have little impact

on the safety of the change.





The Agency is waiting for the results of a study being carried out by the Ministry of

Transport of the Netherlands in order to establish that such a risk-based review is

possible/feasible and to provide a high-level view of the risk to be used and the means of

modulating such a review. The IR has been written sufficiently broadly that it should not

need to be changed, and the detailed definition of the risk will be provided in AMC.

However, if this is not the case, then it will be necessary to amend the IR to describe the

risk. It is necessary to develop the GM and AMC that help ensure a harmonised

implementation of this provision. However, at the moment appropriate AMC and GM are

not available. This chapter of the RIA has, therefore, been developed to assist the Agency

in this decision.


As in the case of provisions on ‘risk-based review decision’, the risks identified of not

implementing a risk-based review decision are the following:

— To review unnecessary parts of an assurance case. This will result in a waste of the

resources of both competent authorities and service providers, consequently,

removing these resources from performing other useful safety management

activities.

— Not to review those parts of an assurance case which are flawed risks putting an

unsafe change into operations.






If the existing provisions do not change, the issue identified will continue to exist. The

situation could even worsen as the framework for the service providers evolves without a

parallel evolution from the competent authorities’ side. Harmonisation in the

implementation of changes required at the European level (e.g. those changes stemming

from the implementation of SESAR) could be jeopardised.

4.4.5. Objectives


The specific objective to be achieved here is to provide clear and correct regulations and

guidance on how to perform a risk-based review of the notified changes.




Option No


0 Do nothing Baseline option (no change in rules; risks remain as outlined in the issue analysis).

1 Remove the To remove the concept of risk-based review from the regulation and to





concept of the risk-based review

leave the means of reviewing an assurance case solely in the hands of each competent authority and ultimately in the hands of each individual reviewer.

2 Delay the

development of the requirements until sufficient experience exists to write

them.

This option proposes to delay the development of the risk-based

review provisions until there is sufficient material to ensure its harmonised implementation. With this option, some AMC/GM could be provided to gather experience in the way the CAs would apply such a concept. The rule and the content of such AMC/GM could be based on the outcome of the study currently being carried out by the Ministry of Transport of the Netherlands. The implementation of the IR for risk-

based review and the further development of AMC/GM could be done after an evaluation of the validity of the means proposed in the study.

3 Propose a risk-based review

rule, but delay implementation until sufficient experience exists to use it.

This option is to include the risk-based review clause in the IR, to publish guidance, when the outcome of the study carried out by the

Ministry of Transport of the Netherlands is available. After a period of analysis of a pilot study, the model can be validated and be proposed as AMC at a later stage. In this way, competent authorities and service providers would be aware of the intentions and would have guidance material explaining how the proposed system is supposed to work and can, therefore, plan their own efforts to accommodate the regulatory

change when it happens.

While all the above options have been identified, the Agency notes that Option 1 does not follow

the Agency/EC policy for continuously improving the implementation of a risk-based oversight, in

order to optimise the use of scarce resources within competent authorities and service providers.

Therefore, only Options 0, 2 and 3 are considered when analysing the impacts.



Option 0: With this option, the regulatory framework will not be changed; therefore,

there should not be any additional safety impact compared to today’s situation.

Option 2 and Option 3: Once the new proposed provisions on ‘risk-based’ review and

its supporting AMC and GM have been developed and implemented, it is expected that

they will have a positive safety impact since the implementation of the new provisions

should allow a more efficient use of scarce resources, which would allow them to be

reallocated to other safety management tasks. This option is expected to have a positive

impact on safety.



there should not be any additional increase in costs compared to today’s situation.

Option 2 and Option 3: The implementation of any new regulation (or even new AMC

and GM in the case of Option 2) is likely to transiently increase oversight costs as there

will be a need to change existing procedures of the competent authorities and there will

also be a need to train the personnel responsible for overseeing the service providers. It

may also be useful to train the relevant service providers’ staff so as to ensure facilitation

of compliance with the applicable requirements. However, in the long term, the costs

may well decrease as the certainty associated with the rule (or AMC/GM in the case of

Option 2) improves the efficiency of both the competent authorities and the service

providers. In this case, as opposed to the provisions for the risk-based selection decision,

the transition period may well be longer and recovery may prove more difficult. The more





immature state of the material will lengthen the transition and may mean the competent

authorities perform their reviews with a greater degree of dissimilarity as there will be no

clear rule and no means on which to base guidance material for a longer period.

Therefore, the economic impact is expected to be negative when implementing the new

proposed provisions.



appreciate it if cost estimates are provided in justification.


Option 0: With this option, the regulatory framework will not be changed, therefore, there

is no change to today’s situation. However, because there is no indication on which risk the

review should be based, the exiting regulation has led to disharmony in the

implementation of the review of changes by competent authorities across the EU.

Competent authorities implement the risk-based review differently, often based on the

subjective judgement of the CA or the reviewer. In turn, this may have a negative impact

on harmonisation, which is caused by the lack of common criteria for the evaluation of the

risk, the lack of a means of modulating the review and by the lack of AMC and GM to

support the implementation of the requirements.

Option 2: This option may have a positive impact on ‘better regulation’ because the

regulation will only be written when sufficient experience is gained with the use of the

concept included in AMC/GM. However, it may have a negative impact on harmonisation

since the competent authorities could still use different sets of AMC/GM to modulate their

reviews until the IR and a single set of AMC/GM arrive later. Consequently, it might be

very difficult to harmonise in such circumstances.

Option 3: The clarity and fuller definition of this proposed provision is expected to

increase regulatory harmonisation provided it is implemented in the way it is foreseen and

as described in the supporting AMC and GM. It is, however, necessary to emphasise that

this positive impact on regulatory harmonisation is a longer-term effect than that foreseen

in the review decision RIA and is only to be expected once the relevant staff are properly

trained and only after the transition period.



The summary of the impacts by the different options can be found below:







Do nothing

Option 2

Delay the development of

the requirements until sufficient

experience exists to write

it

Option 3

Propose a risk-based review rule, but delay implementation until sufficient


Safety impacts 0 + +

Economic impacts 0 - -

Regulatory coordination and harmonisation - -/+ +

Overall impact - -/+ +

Therefore, the preferred option is Option 3 and it is the one proposed in the NPA.

The results of the study that is being conducted by the Ministry of Transport of the

Netherlands are not yet available and, therefore, the AMC and GM cannot be presented in

this NPA.

The drawback of this approach is that there will be no AMC or GM to support the

implementation and, therefore, the application of the rule will need to be postponed until

this material is developed. However, the current situation will be unchanged as the

competent authorities will continue to do as they are doing today. Indeed, the competent

authorities are trying to implement the existing requirement on risk-based review by

developing a concept of ‘level of involvement’ based on some criteria that they can apply

on a case by case basis. The study being carried out by the Ministry of Transport of the

Netherlands includes an assessment of this method.


As already explained, this option implies that the notion risk-based review of assurance

cases by competent authorities can be enabled and harmonised on the basis of an

objective set of criteria and an objective means of modulating the review. However,

confirmation of the assumptions made depends on the results of a study. It might be that

the result of the study does not confirm this approach and, therefore, the requirement may

need to be re-evaluated and a different form of review modulation proposed.


Taking into account the circumstances descried in 4.4.8.2, the situation is and will remain

unchanged during the development period. Therefore, the level of harmonisation will be

the same as it is today. Appropriate monitoring and ex post evaluation will be considered

once the AMC/GM are developed.





4.5. CNS providers performing safety support assessment instead of safety assessment


The issue that is addressed here is associated with the identified inconsistency (reference

to Article 9.1 of Regulation (EU) No 1034/2011, point 3.1 of Annex I and point 2 of Annex

V to Regulation (EU) No 1035/2011) of the current regulations that request CNS providers

to perform a safety assessment of the changes they make to their functional systems. The

reason why a different set of requirements for ATS providers and for CNS providers is

needed is that they have different responsibilities related to safety and different abilities to

influence the safety of operations, thus, different abilities to implement mitigating

measures for safety risks.

First of all, it is important to highlight that CNS providers provide safety-related services in

the sense that their services are needed for the safe conduct of a flight, i.e. they have an

impact on the safe conduct of a flight as they are used either by the ATS provider or

directly by the aircraft. The difference between an ATS provider and a CNS provider is that

whereas an ATS provider can dynamically intervene in order to control the safe use of the

service it provides, if and when it sees an unsafe situation developing166, a CNS provider

cannot. The CNS provider does not have this dynamic view of the use of its service and,

therefore, cannot intervene in order to alter the situation. Furthermore, the CNS provider

may not know how its service is being used, either in normal circumstances or in

circumstances where immediate intervention is necessary in order to maintain safety.

Consequently, the CNS provider will not be able to judge whether it will be used safely.

While an ATS provider cannot be said to have absolute control over the use of any service

directly supplied to an aircraft, those services are provided within the framework of a plan

for controlling separation for all aircraft receiving an ATS. Within that plan, the ATS

provider has to be aware and take care of the fact that the initial plan may not be adhered

to and so it will have to modify the plan in order that all aircraft remain safe.

Consequently, while an ATS provider can make an argument for the safe use if its services,

a CNS provider cannot. This is the reason why it is necessary to differentiate between the

types of assessment the different type of service providers are able to conduct.

In resolving the CNS issue, it is apparent that the means used by CNS providers to

perform an appropriate assessment of and provide assurance for the changes they make

can be applied to all other regulated service providers other than ATS providers.

However, this RIA focuses on CNS providers since Regulation (EU) No 1035/2011 contains

detailed requirements for them to carry out the safety assessment of changes.


The risk identified with the existing regulation is that CNS providers, by trying to conduct

safety assessments, may prejudge the way the service will be used and will, therefore,

make invalid assumptions, invalid risk estimations and, thus, invalid risk mitigations, which

may even be out of their control. In other words, the risk analysis a CNS provider performs

may wrongly argue about the safety of the use of the services it provides, primarily

because this use and the management of the risk associated are out of its control.

166 More explanation can be found in GM1 Annex I Definitions(35) & ATM/ANS.OR.C.005 & ATS.OR.205 General —

SERVICES, INFORMATION AND THE RESPONSIBILITY FOR SAFETY.







competent authority), the CNS providers and the Agency rulemaking and standardisation

activities.


It is not clear how the situation could evolve in the future, e.g. during the implementation

of SESAR projects, since CNS services will be automated more and more and there will be

less and less human intervention. In that situation there will be a need to identify the right

service provider or aviation entity i.e. the one that has the overall view of safety and is

therefore in a position to conduct the safety risk analysis and to argue the safe use of all

the services. Therefore, the provisions proposed may need to be revaluated in the future in

line with the new or changed safety responsibilities of the different services providers and

aviation entities.

4.5.5. Objectives


The specific objective to be achieved when addressing this issue is to provide clear and

correct regulations and guidance on who is to perform safety assessment and who is to

perform safety support assessment and how they will be performed.




Option No


0 Don-nothing Baseline option (no change in rules which requires the CNS providers to assess the safety of the changes they make to their functional systems; risks remain as outlined in the issue analysis).

1 Do not specify the type of analysis the CNS providers need to

conduct when assessing the changes to the

functional systems

This option would require CNS providers to conduct an assessment of the changes to their functional systems but neither the form of that assessment nor the criteria associated with the assessment will have been specified. This is the same situation as exists today for service providers other than ATS and CNS providers. Currently, the

regulations require service providers other than ATS and CNS providers, i.e. MET, AIS, ATFM and ASM providers, to perform an assessment of their changes to the functional systems without

providing the success criteria.

2 Require the CNS providers (and other non-ATS providers) to

perform a safety support assessment when changing their functional systems

This option requires CNS providers (and other non ATS providers) to perform the same type of assessment when changing their functional systems. It is called a ‘safety support assessment’. The objectives for the safety support assessment are fully defined in the proposed regulation.





While all the above-mentioned options have been identified, the Agency notes that Option

1 would have made the situation for CNS providers the same as it is today for other non-

ATS providers by neither providing the requirements nor the means to perform an

assessment of the changes to their functional systems. This would be a backward step and

mean that the only service providers with adequate guidance and regulation for the

assessment of changes to their functional systems would be ATS providers. Therefore, only

Options 0 and 2 are considered when analysing the impacts.





Option 2: As already explained, this option may resolve the identified potential risk with

the application of the existing regulation by requiring CNS providers to perform a safety

support assessment instead of a safety assessment and, therefore, leaving the

argumentation about the safe use of a service to the ATS providers or other aviation

organisations (i.e. aircraft operators, aerodrome operators) that have a direct view of

safety in aviation and can, therefore, argue correctly about the safe use of the services.

This approach is expected to lead to a slight increase in safety.



there should not be any additional increase of the costs compared to today’s situation.

Option 2: As with any change in regulation, there will be increased costs incurred during

the learning and bedding in phase of the transition from one set of rules to another.

However, the longer-term effects on cost savings should more than compensate for this

short-term increase. In this case, these cost savings arise for the CNS service provider

because, by identifying that it has no direct view of safety, it is able to concentrate on

providing a service that fully meets its specification without the additional effort required

in trying, albeit unsuccessfully, to assess the safety of the change being made. Similarly,

competent authorities should reduce their costs in overseeing the changes made by CNS

providers due to the greater certainty as to what they are supposed to do. In conclusion,

the positive economic impacts outweigh the negative ones.



appreciate it if cost estimates were provided in justification.


Option 0: With this option, the regulatory framework will not be changed. The current

regulation is not harmonised with ICAO SARPs because ICAO requires safety assessment

of changes as part of an SMS framework, which is only applicable to CNS services when

they are provided by an ATS provider. The SMS framework does not apply to CNS

services provided independently of an ATS provider. The ICAO framework does not

contain organisational requirements for such independent providers, leaving the

Contracting State to establish these regulations. Since the current regulation requires

CNS providers to have a SMS, then this option perpetuates the disharmony with ICAO. It

is, therefore, considered to have a negative impact.





Option 2: The implementation of the new regulation, which requires CNS providers to

perform safety support assessment when carrying out changes to functional systems is

expected to have a positive impact not only on harmonisation with ICAO SARPs but also on

the implementation of the ‘better regulation’ concept by putting the right requirements at

the right level, only to those organisations that need to comply with them.






Do nothing

Option 2

Require the CNS providers (and other non-ATS providers) to perform a

safety support assessment when changing their functional systems

Safety impacts 0 +

Economic impacts 0 +


Overall impact - +


The disadvantage with this option is that some CNS providers may expend considerable

effort in adapting to the new regulatory framework during the transition period. In other

cases, it might only require a change of mindset and a change in the way things are

named, rather than a large-scale change in working methods. It might also require ATS

providers and entities and organisations outside the scope of this regulation to adapt to the

new situation because the assurance provided by the CNS provider will alter. Rather than a

pseudo safety assurance, they will, in future, provide assurance that their service will

behave as specified in the specified context.


The selected option may create some instability as it could be perceived as downgrading

the existing requirements for CNS providers. This may be based on the belief that safety

support assessments are easier and less important than safety assessments. The Agency

does not concur with this belief as it considers that it is equally difficult to fully assess the

behaviour of the changed functional system and equally important to provide adequate

assurance that this has been done to those using the changed services. In some cases,

the assessment by the CNS provider may be more complex and more difficult than the

one the ATS provider would need to perform to accommodate the change being made by

the CNS provider. Consequently, the concern is more about performing the right

assessment by the right aviation organisation, rather than whether it is more difficult for

one provider than another.






Taking into account the sensitivity analysis made in 4.5.8.2, it is proposed to monitor the

implementation of these provisions after the transition period. If after the transition

period, the Agency observes, via means of standardisation inspections, that the number

of findings to this provisions increases, then a re-evaluation of this provision is required.

4.6. Removal of Severity classification scheme from IR


The current regulation requires ATS providers to perform a safety risk assessment when

they make changes to their functional systems (point 3.2 of Annex II to Regulation (EU)

No 1035/2011). Risk is a two dimensional property: probability and severity. Safety risk

concerns harm to humans as explained in GM1 ATS.OR.205.(b)4 on risk analysis.

However, the severity table in the current regulation has only one level of severity that

relates to harm to humans, thus, there is only one suitable for use in a safety risk

assessment, i.e. level 1. It should be noted that this NPA does not propose the

abandonment of the other severity classes in point 3.2 of Annex II to Regulation (EU)

No 1035/2011, however, it does point out that they are not safety risk severity classes as

they do not relate to harm to humans. The GM explains how they be may usefully applied

in post-incident analysis and in verifying the design of the change. Reducing the number of

severity categories to one, effectively means that any safety analysis does not relate to

risk but only to the probability of the accident. In some instances, e.g. mid-air collisions, in

airspace where there is predominantly only a limited range of aircraft, this may be an

acceptable situation; however, in others, e.g. an airport where both high-speed and low-

speed accidents can occur and where there is a large range of aircraft types in operation, a

multi-valued safety risk-based scheme, i.e. one that has a range of severities for accidents

that result in different levels of harm to different numbers of people, would be a viable and

possibly useful option. The issue to be addressed is, therefore, that, whereas the

regulation requires safety risk-based assessments, the severity scheme it contains does

not allow for this. Moreover the Rulemaking group for RMTs.0467 & .0470 could not agree

on a common severity scheme. Consequently, it was suggested that the current scheme

should be removed from the IR.


The use of a single-valued risk scheme, such as the one currently in Regulation (EU)

No 1035/2011, does not allow comparisons to be made between different risk-bearing

scenarios and, therefore, effort may be misdirected and used to mitigate accidents with

little or no risk while not tackling accidents with a much greater risk.






A multi-valued safety risk severity scheme allows service providers to focus their efforts on

the most risky parts of their operation. Without such a scheme, effort may be wasted on

less risky parts of the operation. Consequently, safety may not improve as fast as it would

with the scheme.





Moreover, there is pressure from the EU Member States and stakeholders to reduce

regulatory costs. The proposed mechanism for achieving this is to move towards a risk-

based approach to regulation. The current regulations are probability-based rather than

risk-based, with regard to the assessment of change and so, if the proposal is rejected, i.e.

Regulation (EU) No 1035/2011 contains only a single safety risk severity category, it is

likely that there will be continuing pressure to change the regulation in order to satisfy the

‘better regulation’ goal.

4.6.5. Objectives


One specific objective to be achieved here is to have a more performance-based regulation

by allowing the ATS provider to use a multi-valued safety risk classification scheme. This is

in order for him to manage safety efficiently and to enable more improvements in safety to

be made given the limited resources of the service provider. It will also allow the ATS

providers to use different methods to conduct the safety assessment depending on the

type of change. Another specific objective is to reduce regulatory costs in line with the EU

Member States and stakeholders declared aims.




Option No


0 Do nothing Baseline option (no change in rules which requires the ATS providers to always conduct the safety assessment by using the severity table in

Regulation (EU) No 1035/2011, i.e. to perform a probability assessment rather than a safety risk assessment).

1 Provide a

universal severity scheme for safety risk

This option would create a universally acceptable severity classification

scheme for all scenarios and include the scheme in either the IR or in AMC. It could also be that a number of severity schemes, for use in individual scenarios, could be included in the IR or in AMC.

2 Provide the rules for creating severity schemes for

safety

This option would accept that, at this stage of maturity, a single universally acceptable severity scheme or set of acceptable schemes for use in different circumstance was not feasible. Instead, the criteria for assessing an acceptable severity scheme will be provided in AMC and guidance provided on the form and range of severity schemes and

on how to construct them.

Initially, within the Rulemaking group, Option 1 was favoured. However, after analysing a

considerable number of schemes, which are recorded in the GM on ‘Risk analysis in terms

of safety risk’, the group came to the conclusion that a universally acceptable severity

scheme was not feasible at the moment. The group was not able to agree on a set of

schemes to be used in different circumstances. Consequently, Option 1 is not considered

further in the RIA. It is noted, however, that it may be appropriate to return to the concept

once further experience has been gained in the use of multi-valued safety severity

schemes.







The purpose of a multi-valued severity classification scheme is to facilitate the

management and control of risk. The risk associated with accident types of different

levels of severity can be compared, giving the organisation the opportunity to manage

the distribution of risk. For example, comparing runway infringement accidents with low-

speed taxiway accidents would allow an organisation to focus their efforts on mitigating

the accident type with the greatest risk.



Option 2: This option would allow the development of the appropriate risk evaluation

method to be used in the safety assessment of changes to functional systems as it

provides examples that can be used for and adapted to in each particular case. This

option could have a positive impact on safety by focussing mitigation efforts on the

highest risks and, thus, maximising the gains in safety improvement for the least cost.



there should not be any additional increase of the costs compared to today’s situation.

Option 2: As with any change in regulation, there will be increased costs incurred during

the learning and bedding in phase of the transition from one set of rules to another.

Those ATS providers, for which a single-valued severity scheme is appropriate could still

use their existing risk evaluation methods as they are based on the current regulations’

severity scheme, which is single-valued. However, the flexibility allowed for in the

AMC/GM would permit the ATS provider to create and use a more appropriate multi-

valued scheme, which should have a positive economic impact. Initially, the costs will

rise for those ATS providers who would like to take advantage of a multi-valued severity

scheme due to the novelty and perhaps the increased complexity of the risk evaluation.

However, by allowing the appropriate management of the mitigation of risks, in the long

term, costs should actually decrease.

Overall, it is felt that there will be a neutral to positive economic impact.





Option 0: With this option, the regulatory framework will not be changed. Therefore,

from this perspective, there is no negative or positive impact on the concept of ‘better

regulation’ or regulatory harmonisation. However, as stated in 4.4.4, one of the goals of

better regulation is to move towards a risk-based regulatory approach. This is not

feasible with Option 0 and so, in these circumstances, there would be a negative impact.

Option 2: This option promotes the concept of ‘better regulation’ by transferring the

strict regulation on the method to be used to perform risk evaluation into GM. This option

may have a negative impact on harmonisation as each ATS provider could develop their

own severity scheme to be used in risk evaluation. However, this could be mitigated in





the long term by reviewing the severity schemes used by ATS providers and seeking to

minimise their variation, consequently, providing either a single severity scheme or a

small set of them. Moreover, since the proposal in this NPA contains the criteria for a

severity scheme in the AMC, the variation in the number of different schemes should be

limited to a manageable number.

Overall, there is probably a small positive impact which may increase over time as the

harmonisation of the severity schemes is improved.






Do Nothing

Option 2

Provide the rules for creating

severity schemes for safety

Safety impacts 0 +

Economic impacts 0 0/+

Regulatory coordination and

harmonisation

- +

Overall impact - +


The creation of multi-valued severity schemes should have the benefit of allowing more

appropriate and cost-effective risk analysis to be performed. It should also improve safety

by allowing ATS providers to maximise safety gains through focussing on scenarios with

the highest level of risk. The problem is that, initially, there may be a wide range of

different severity schemes proposed. However, with appropriate management and

oversight, these ought to be reduced to an acceptable number of schemes, which could

then be harmonised.


The variations in multiple-value severity schemes should be monitored and periodic

reviews should be performed to see if the range of variation can be reduced to the point

where a severity scheme or a very small range of severity schemes can be identified and,

thus, allow them to be included as AMC material. A long-term study group tasked with

performing such reviews could be established.

4.7. Changes affecting software and Regulation (EC) No 482/2008


Regulation (EC) No 482/2008 requires air navigation service providers and providers of

ATFM and ASM to establish a software safety assurance system. Assurance is required for

the whole functional system in Regulation (EU) No 1035/2011 for all service providers, but





the means to provide that assurance is not made clear. Regulation (EC) No 482/2008, on

the other hand, does provide the means for assuring software.

The two above-mentioned regulations are in conflict because they deal with the same

subject, but use different requirements and language.


No increase in safety risk is associated with the repeal of Regulation (EC) No 482/2008 as

this proposal covers all requirements of the said Regulation — see 6.2 of Appendix II.

Extending the detailed assurance criteria to the assurance of the other parts of the

functional system could lead to an improvement in the safety risk.


All air navigation service providers and providers of ATFM and ASM, their software

suppliers and their competent authorities who have to refer to the new regulation for their

activities and, in addition, the Agency for certification and standardisation activities.


If Regulation (EC) No 482/2008 is not repealed, all air navigation service providers and

providers of ATFM and ASM, their software suppliers and their competent authorities would

have to fulfil the requirements of and refer to both regulations. Furthermore, both

regulations could diverge if they were not maintained synchronously. It is very difficult to

synchronise the modification of separate regulations.

4.7.5. Objectives

The objective of the proposal made with this NPA is to have proper assurance

requirements for all changes and for all parts of the functional system. This is achieved by

extending the assurance requirements of Regulation (EC) No 482/2008 to other elements

of the functional system, thus, improving the level of safety because the concepts laid

down in Regulation (EC) No 482/2008 are extended to the entire functional system where

applicable.

An additional objective is to reduce the number of parallel regulations to which air

navigation service providers and providers of ATFM and ASM, their software suppliers and

their competent authorities have to adhere.


Apart from Option 0 ‘do nothing’, two additional options have been proposed.

Option 1:

Include the assurance criteria of Regulation (EC) No 482/2008 within the NPA and make it

applicable to all parts of the functional system, keeping redundant Regulation (EC) No

482/2008. This increases the likelihood that the regulations become inconsistent and is

likely to impose unnecessary additional work for industry and competent authorities.

Furthermore, the EC will have to approve two sets of redundant legislations and maintain

their translations. There are no safety benefits with this option due to the risk of

inconsistency, which will still exist due to redundant regulations.

Therefore, Option 1 is discarded.





Option 2:

The provisions proposed in this NPA are to extract the assurance means described in

Regulation (EC) No 482/2008 and make them applicable to any of the parts of the

functional system (people, procedures or equipment) of the service providers. As all the

concepts of Regulation (EC) No 482/2008 are in this proposal, which is also applicable to

software because it is one of the parts that gives the functional system its behaviour, there

is no need to keep Regulation (EC) No 482/2008.

The proposal is to repeal Regulation (EC) No 482/2008 because having two regulations

with requirements for the same thing is neither good regulation practice nor ‘better

regulation’. Firstly, because a different language is used in these two regulations and this

can cause confusion, and secondly, because either regulation can evolve in different

directions if not updated together.

The remaining policy options are outlined in the table below.


Option

No


0 Do nothing Do nothing. Software assurance remains as governed by Regulation (EC) No 482/2008, while the assurance of the other parts of the

functional system remain as regulated by Regulation (EU) No 1035/2011.

2 Repeal

Regulation (EC) No

482/2008

Include the assurance criteria of Regulation (EC) No 482/2008 within

the NPA and make it applicable to all parts of the functional system. Repeal Regulation (EC) No 482/2008.



There is no negative impact expected on safety for any of the options. However, Option 2

has the potential to improve safety by providing clarity in the applicable requirements.


Option 0 has a negative economic impact because the existence of two overlapping

regulations makes inconsistency and regulatory disagreement more likely with the effect

of wasting effort and time. For this reason, Option 2, which provides one set of criteria

for performing assurance and a single way of regulating assurance for all parts of the

functional system, has a positive impact.





No implementation problems are expected for Option 0 because nothing changes.

However, Option 0 does not support better regulation or harmonisation because two

different ways of defining assurance are used, one for both software and the other parts





of the functional system (within Annex II to Regulation (EU) No 1035/2011) and one for

software alone (within Regulation (EC) No 482/2008).

Option 2, which uses a single concept and a single set of words, supports better

regulation and harmonisation by avoiding redundancy.

For Option 2, no implementation problems for software are foreseen as any reference to

Regulation (EC) No 482/2008 shall be understood as a reference to the current NPA. For

the detailed references, see the table in Appendix 6.2

Option 2 takes the opportunity to simplify the existing rules and introduce ‘smart

regulation in line with EU requirements’, as it reduces the number of rules.

None of the options has any impact on a Member States’ obligations towards ICAO.






Do nothing

Option 2

Repeal Regulation

(EC) No 482/2008

Safety impacts 0 +

Economic impacts 0 +


Overall impact - +


While there are no negative safety or implementation impacts foreseen for Option 0

because nothing changes, there are no gains either. Option 0 has a negative impact on

better regulation and the cost effectiveness for the service provider and the competent

authority due to the fact that two regulations covering the same thing would be in force at

the same time. On the other hand, Option 2, which takes the opportunity to simplify the

existing rules and introduce ‘smart regulation in line with EU requirements’ has a positive

impact in all three categories.


It is proposed to monitor the implementation of these provisions after the transition

period. If after the transition period, the Agency observes, via means of standardisation

inspections that the number of findings to this provisions increases, then a re-evaluation of

this provision is required..


5. References



5. References

5.1. Affected regulations

— Commission Implementing Regulation (EU) No 1034/2011 of 17 October 2011 on

safety oversight in air traffic management and air navigation services and amending

Regulation (EU) No 691/2010 (OJ L 271, 18/10/2011, p. 15)

— 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 (OJ L 271,

18/10/2011, p. 23)

— Commission Regulation (EC) No 482/2008 of 30 May 2008 establishing a software

safety assurance system to be implemented by air navigation service providers and

amending Annex II to Regulation (EC) No 2096/2005 (OJ L 141, 31/05/2008, p. 5)

5.2. Affected CS, AMC and GM

None

5.3. Reference documents

None


6. Appendices



6. Appendices

6.1. Appendix I — Cross reference table of Regulations (EU) Nos 1034/2011 and 1035/2011 to the proposed

requirements in this NPA

Regulation (EU) No 1034/2011 to the proposed requirements in this NPA167

Regulation (EU)

No 1034/2011 — Reference

Subject NPA Reference Reason/Justification

Article 2 Definitions Annex I The definitions are amended as explained in Section 2.4.1 of the EN.

Article 6 1.(d)(ii)

Verification of compliance with safety regulatory

requirements

ATM/ANS.AR.C.010(5)&(6)

It covers all aspects of the oversight of the service providers’ management of changes to functional systems: that changes are managed in accordance with approved change management procedures, monitoring of the operation of the changed functional systems and appropriate reaction if the monitoring

shows that the change is not behaving as anticipated.

Article 9 1. & 2.

Safety

oversight of changes to functional systems

ATM/ANS.AR.C.030 ATM/ANS.OR.A.045 ATM/ANS.OR.B.010

The provisions have been enhanced to make it more explicit on what it is expected from the service providers and from the CAs in relation to the change management procedures development and approval process.

Article 9 3.

Safety

oversight of changes to functional

systems

ATM/ANS.OR.A.045 The requirement has been enhanced. It contains more explicit requirements on the change management procedures.

Article 10 1.

Review procedure of

the proposed changes

ATM/ANS.AR.C.035 The provision has been modified as explained in Section 2.4.3 of the EN.

Article 10 2.

Review procedure of the proposed changes

ATM/ANS.AR.C.040 The provision has been modified as explained in Section 2.4.3 of the EN.

167 This table contains only the cross references to those requirements related to the provisions proposed in this NPA. The cross reference of the complete Regulation (EU)

No 1034/2011 and the proposed regulations can be found in NPA 2013-08 under: http://easa.europa.eu/rulemaking/r-archives.php#npa



6. Appendices




Commission Implementing Regulation (EU) No 1035/2011 Reference


Article 2 Definitions Annex I The definitions are amended as explained in Section 2.4.1 of the EN.

Annex I, 3.1

SAFETY AND

QUALITY MANAGEMENT Safety management

ATM/ANS.OR.B.010 It reflects the original intent and it complements it with more details on what to do in case the change management procedures are not suitable for a particular change.

Annex II 3.1.1 (d), 3.1.3 (b)

Safety objective and safety

monitoring

ATM/ANS.OR.B.005(a) (5)&(6)

ATM/ANS.OR.B.005(d)

As explained in Section 2.4.4. of the EN, the provisions enhance the existing requirements by making them more explicit.

Annex II, 3.2.1

Safety requirements for risk assessment and

mitigation with regard to changes

ATS.OR.205 (a)(1) & (c) The requirements have been enhanced and AMC/GM have been added.

Annex II, 3.2.2

Safety requirements for risk

assessment and mitigation with regard to changes

ATS.OR.205(b) ATS.OR.210

AMC on safety assessment and assurance

The requirements for safety assessment have been enhanced and AMC/GM

have been added.

Annex II, 3.2.3

Safety

requirements for risk assessment and mitigation with

ATS.OR.205(a)(2) The requirements for safety assurance have been enhanced and AMC/GM have been added.

168 This table contains only the cross references to those requirements related to the provisions proposed in this NPA. The cross reference of the complete Regulation (EU)

No 1035/2011 and the proposed regulations can be found in NPA 2013-08 under: http://easa.europa.eu/rulemaking/r-archives.php#npa.



6. Appendices




Regulation (EU) No 1034/2011 — Reference


regard to changes

Annex II, 3.2.4

Safety requirements for risk assessment and mitigation with regard to

changes

ATM/ANS.OR.B.005(a)(6) ATS.OR.205 (b)(2)&(3)&(4) ATS.OR.210 AMC/GM on safety assessment and assurance

The requirement has been enhanced and modified as explained in Section 2.4.5 of the Explanatory Note.

Annex II, 3.2.5

Safety requirements for risk

assessment and mitigation with

regard to changes

ATS.OR.205(a)(2)

AMC/GM on safety assessment and assurance

Justification is provided in Appendix II to the EN.


6. Appendices



6.2. Appendix II — Cross reference table of the requirements of Commission Regulation (EC) No 482/2008

Regulation (EC) No 482/2008 to the proposed requirements in this NPA

Regulation (EC) No 482/2008 —

Reference


Article 1

Subject matter and scope

None

There is no scope paragraph within this NPA but its scope is inherited from the scope of the CRD to NPA 2013-08 as this proposal is to be included in that regulation. Therefore, within the scope of this NPA are ATS, CNS, MET, AIS, ATFM, ASM and DAT.

Software is no longer treated separately from the other parts of the

functional system (people, procedures and equipment excluding software). The requirements in the NPA ensure that all parts of the functional system are adequately assured. The NPA legislates for the objectives of assurance which implies that an assurance system must be present.

Article 2 Definitions

Annex I and GM In the NPA, not all definitions are used. Only those for words used are retained in the rule text.

Article 3.1 None

Not directly transposed.

The assurance system for software is encapsulated within the general requirement for the assurance of changes to the functional system, which requires assurance of all aspects of the functional system — people procedures, equipment and organisation. That software is part of equipment is made clear in GM1 Annex I Definitions(35). The procedures that govern both the collection of evidence (Assessment — ATM/ANS.OR.C.010(b)) and

the provision of an assurance argument (ATM/ANS/OR.C.010.(a)(2) have to

be approved before their use (ATM/ANS.OR.B.015). These procedures, therefore, establish an assurance system not just for software but for all the parts of the functional system.

Article 3.2 — Lead

sentence

ATS.OR.205 (a)(2)

ATM/ANS.OR.C.005(a)(2)

The proposed wording incorporates the intent of Regulation (EU) No 1035/2011 text and the intent of the Regulation (EC) No 482/2008 text. It extends the concepts of Regulation (EC) No 482/2008 to elements of the

functional system other than software.

Evidence, which is specifically mentioned in Regulation (EC) No 482/2008 is

not excluded in this NPA. It is now included within the definition of an


6. Appendices




Regulation (EC) No 482/2008 — Reference


argument (GM1 ATM/ANS.OR.C.005(a)(2) & ATS.OR.205(a)(2) General)

A very similar clause (in ATM/ANS.OR.C.005(a)(2)) provides the same level of regulation for the safety support assurance of changes to the functional

systems of service providers other than ATS providers.

Article 3.2(a)

AMC2 ATS.OR.205(a)(2)(b), (c) & (d)

AMC2 ATM/ANS.OR.C.005 (a)(2)(b), (c) & (d)

ATM/ANS.OR uses the term safety criteria to describe measurable properties that can be validly related to safety. They are higher level than the safety objectives placed on software in Regulation (EC) No 482/2008 and so ensure that safety requirements are placed on every part affected by the change,

which, by definition, includes software, thus, satisfying the intent of Regulation (EC) No 482/2008 for software. It also broadens the intent of the said Regulation by encompassing every other part affected by the change.

The requirements have to be traced to the level at which there is assurance that they have been satisfied. In most cases, this will be at the level of some software component, consequently, these clauses of the NPA apply to software even though it is not specifically mentioned.

A very similar clause (in AMC2 ATM/ANS.OR.C.005(a)(2)) provides the same level of regulation for the safety support assurance of changes to the functional systems of service providers other than ATS providers.

Article 3.2(b) AMC2 ATS.OR.205(a)(2)(d)

AMC2 ATM/ANS. OR.C.005 (a)(2)(d)

As explained above, assurance of requirement satisfaction implies all requirements, including those related to software, will be addressed.

Therefore, the intent of Regulation (EC) No 482/2008 is extended by

including all elements rather than just software.


Article 3.2(c)

ATS.OR.205(b)(6)(ii)

AMC2 ATS.OR.205(a)(2)(c), (e) & (f)

ATM/ANS.OR.C.005(b)(2)

AMC2 ATM/ANS. OR.C.005(a)(2)(c) & (e)

The implementation must meet the safety criteria and so it cannot adversely

affect safety. If there is a software change, all its functionality is included in the change and has to be assessed and verified in order to verify that the safety criteria have been satisfied.

The intent of EC 482 is met and broadened because the requirements apply to all types of element.


6. Appendices






A very similar clause (ATM/ANS.OR.C.005(b)(2)) provides the same level of regulation for the safety support assurance of changes to the functional

systems of service providers other than ATS providers.

Article 3.2 (d) ATS.OR.205(a)(2) ATM/ANS.OR.C.005(a)(2)

The wording has been improved to make it clear there is sufficient confidence that the change is and will remain acceptably safe. Safety criteria are derived from an overall safety objective/goal for the change. In assessing the level of confidence needed for satisfaction of the safety criteria, different levels of confidence may be allowed for the satisfaction of

each criterion. This implicitly imposes a level of ‘criticality’ on the elements of the functional system being changed i.e. more confidence is needed in some of them rather than in others , which in most cases will be the software component that is instrumental in providing the behaviour of the

functional system. The intent of EC 482 is met and broadened because the requirements apply to all types of element.

A very similar clause (ATM/ANS.OR.C.005(a)(2)) provides the same level of regulation for the safety support assurance of changes to the functional systems of service providers other than ATS providers.

Article 3.2 (e) AMC2 ATS.OR.205(a)(2)(g)

AMC2 ATM/ANS. OR.C.005 (a)(2)(f)

The proposed change captures the intent of Regulation (EC) No 482/2008 but broadens it to include all parts affected by the change.

‘Known version of the component’ captures the essence of Regulation (EC) No 482/2008 but broadens it to all parts affected by the change.

‘Configuration data’ is broadened to simply ‘data’.

It seems unnecessary to add ‘including specifications’ as specifications are a subset of description in Regulation (EC) No 482/2008.

Article 3.3

ATM/ANS.OR.A.045(c)

ATM/ANS.OR.B.010(a)

ATS.OR.205 (a)(2)


The organisation has to produce an assurance argument whether or not it is

to be reviewed by the national supervisory authority. The assurance argument will be made available to the national supervisory authority if the CA decides to review the change.

The intent of Regulation (EC) No 482/2008 is met and broadened because

the requirements apply to the whole change not just the software.


6. Appendices






A very similar clause (in AMC2 ATM/ANS.OR.C.005(a)(2)) provides the same level of regulation for the safety support assurance of changes to the

functional systems of service providers other than ATS providers.

Article 4.1 ATM/ANS.OR.B.010(a)(1)

Software is part of the functional system. Changes to the functional system have to be assured. The assurance system for software is, therefore, encapsulated in the procedures for the management of change. These procedures have to be documented in order that they can be reviewed by the CA.

The intent of Regulation (EC) No 482/2008 is met and broadened because the requirements apply to the whole change not just the software.

Article 4.2 None

Formally, assurance levels are used in Regulation (EC) No 482/2008 to

determine ‘the rigour to which the assurances are established’. This can only be understood as a means to provide the required level of confidence. The proposal in this NPA allows the level of confidence to be established directly,

without the need for assurance levels. Nevertheless, the use of software assurance levels might be helpful in generating appropriate and sufficient evidence to show that ATS.OR.205 and ATM.ANS.OR.C.005 are satisfied.

Moreover, software assurance levels can only be applied to bespoke software, of which there is very little in ATM. Most changes either add COTS to a functional system or are modifications to software that is already being

used in the functional system. Article 5.1 of Regulation (EC) No 482/2008

allows other means to be used for such software.

Article 4.3(a) Same reference as Annex II part A See Annex II part A

Article 4.3(b) Same reference as Annex II part B See Annex II part B

Article 4.3(c) Same reference as Annex II part C See Annex II part C

Article 4.3(d) Same reference as Annex II part D See Annex II part D

Article 4.4 ATS.OR.205(a)(2)


The intent of Article 4.4 is that ‘the assurance … must give sufficient confidence that the EATMN software can be operated tolerably safely’.

Formally, assurance levels are used in Regulation (EC) No 482/2008 to


6. Appendices






determine ‘the rigour to which the assurances are established’. This can only be understood as a means to provide the required level of confidence. The

proposal in this NPA allows the level of confidence to be established directly,

without the need for assurance levels. Nevertheless the use of software assurance levels might be helpful in generating appropriate and sufficient evidence to show that ATS.OR.205 and ATM.ANS.OR.C.005 are satisfied. Many useful standards e.g. DO 178/ED 12, DO 278/ED 109, ISO 61508, exist and will continue to be used.

A very similar clause (in ATM/ANS.OR.C.005(a)(2)) provides the same level

of regulation for the safety support assurance of changes to the functional systems of service providers other than ATS providers.

Article 4.5 ATM/ANS.OR.B.010(c)

The Regulation (EC) No 482/2008 clause seeks to monitor the assurance procedures and change them where they are found to be inadequate or where it is thought that their performance could be improved.

The assurance procedures for the management of change to a functional

system are part of the overall management system and are covered by the clauses shown on the left.

These satisfy the intent of Regulation (EC) No 482/2008, which is broadened because the requirements apply to any part of a change to a functional system and, therefore, to all types of elements.

Article 5.1 None The new requirements are formulated such, that this clause is no longer necessary. See the justification related to Articles 4.2 and 4.4.

Article 5.2 ATM/ANS.AR.B.010 There is no need for a special clause in the ATM IR, as the Basic Regulation allows qualified entities to perform all of the activities of a CA.

Article 6

Amendmen

t to Regulation EC (No) 2096/

2005

N/A

Article 7 Entry into N/A


6. Appendices






force

Annex I

Requirements applying

to the software assuranc

e level referred to in

Article 4(2)

None

See the justification for Article 4.4, which explains why software assurance levels are not included in the proposal in this NPA.

Furthermore, the definition of hazard in the current Regulation makes the severity of the effect of every hazard class 1, because the classification is according to the most probable outcome under worst-case conditions. There is no worst-case condition that isn’t an accident. The table is very good for classifying an event after the fact, but it is not suited for risk analysis before

the fact. Annex I just makes the statement that there shall be 4 software assurance levels where level 1 indicates the most critical level. Due to the fact that all hazards lead to severity class 1 effects and all software levels

must exist within this severity class, it means that the criticality is a probability not a risk. As the granularity of the software assurance levels is not prescribed in more detail, the Regulation does not help to standardise or

harmonise things but simply puts an undue burden on the regulated.

Regulation (EC) No 482/2008 only requires software assurance levels for bespoke software, of which there is very little in ATM. Most changes either add COTS to a functional system or are modifications to software that is already being used in the functional system. Article 5.1 of Regulation (EC) No 482/2008 allows other means to be used for such software.

Annex II — Part

A.1

ATS.OR.205(b)(1)

AMC2 ATS.OR.205(a)(2)(b)

AMC3 ATS.OR.205(a)(2)(a)


AMC2 ATM/ANS.OR.C.005(a)(2)(b)

AMC3 ATM/ANS.OR.C.005(a)(2)(a)

The intent of Regulation (EC) No 482/2008 is satisfied by the proposed text.

The assessment carried out covers all the behaviour of the change including downgraded modes (ATS.OR.210.(c)). Safety criteria are identified that ensure the behaviour of the change is safe over the complete range of uses of the functional system that could be affected by the change. Behaviour includes all the properties identified in the Regulation (EC) No 482/2008

clause. These criteria are refined to the level of the system at which they will be verified, which in most cases will be the software component that is instrumental in providing the behaviour of the functional system.

The intent of Regulation (EC) No 482/2008 has been extended by seeking to encompass every other part affected by the change.

Very similar clauses (in ATM/ANS.OR.C.005(b)(1) & (c)(4) and associated


6. Appendices






AMC/GM) provide the same level of regulation for the safety support assurance of changes to the functional systems of service providers other

than ATS providers.

Annex II — Part

A.2

AMC2 ATS.OR.205(a)(2)(b) & (c)

AMC2 ATM/ANS.OR.C.005(a)(2)(b) & (c)

The intent of Regulation (EC) No 482/2008 is satisfied by the proposed text as the aspects of completeness, correctness and compliance with the system safety requirements are covered. As explained above, the safety criteria form the basis of safety for the change and so relating the requirements to the satisfaction of safety is a higher-level goal than meeting the system

safety requirements which in themselves have been derived from the safety criteria.

A very similar clause (in AMC2 ATM/ANS.OR.C.005(a)(2)) provides the same

level of regulation for the safety support assurance of changes to the functional systems of service providers other than ATS providers.

Annex II — Part

B.1 AMC2 ATS.OR.205(a)(2)(e) This is a direct match with Regulation (EC) No 482/2008.

Annex II — Part B.2

ATM/ANS.OR.B.010(a)

AMC2 ATS.OR.205(a)(2)(c) & (e)

AMC2 ATM/ANS.OR.C.005(a)(2)(c) & (e)

The justification related to Article 3.2.(a) covers the adequacy of the verification.

The procedures used during verification are approved by the CA prior to their use and so can be considered to have been agreed.

Annex II — Part B.3

ATS.OR.205(b)(6)(ii)

AMC2 ATS.OR.205(a)(2)(c) & (e)


AMC2 ATM/ANS.OR.C.005(a)(2)(c) & (e)

The design and implementation of a change must be verified in order to

show that the safety criteria are met. There may be software changes and so their functionality is included in the change and has to be verified.

The intent of Regulation (EC) No 482/2008 is met and broadened because the requirements apply to all types of element.

A very similar clause (in ATM/ANS.OR.C.005(b)(2)) provides the same level

of regulation for the safety support assurance of changes to the functional systems of service providers other than ATS providers.

Annex II — Part

C.1

ATM/ANS.OR.B.035

AMC2 ATS.OR.205(a)(2)(g)

The assurance argument for a change to a functional system is a record in

the terms of ATM/ANS.OR.B.035. The argument includes the evidence. In most cases, this evidence will be that which is associated with the software


6. Appendices






AMC2 ATM/ANS.OR.C.005(a)(2)(f) component that is instrumental in providing the behaviour of the functional system.

Details of the evidence required are in AMC2 ATS.OR.205(a)(2) and comply

with the intent of Regulation (EC) No 482/2008. Consequently, the intent of Regulation (EC) No 482/2008 is met. It is also broadened because the requirements apply to all types of elements.


Annex II — Part C.2

ATM/ANS.OR.B.005(d)(1)

Any problems associated with software will, when they appear as substandard performance of the functional system, be identified, their cause

established, their implications determined and a change will be initiated in order to eliminate or mitigate the cause. The intent of Regulation (EC) No 482/2008 is met and broadened because the requirements apply to all types of elements.

Annex II — Part C.3

ATM/ANS.OR.B.035

The assurance argument for a change to a functional system is a record in the terms of ATM/ANS.OR.B.035. The argument includes the evidence. In most cases, this evidence will be that which is associated with the software component that is instrumental in providing the behaviour of the functional system.

While the Regulation (EC) No 482/2008 clause is an essential regulation which supports assurance, since there is no point in creating arguments and evidence if they cannot be reproduced at some later date, it is a common requirement and normally relates to all records.

The intent of Regulation (EC) No 482/2008 is met and broadened because the requirements apply to all types of elements.

Annex II — Part D.1

AMC2 ATS.OR.205(a)(2)(d)

AMC2 ATM/ANS.OR.C.005(a)(2)(d)

As explained above, assurance of requirement satisfaction implies that software will be involved. However, the intent of Regulation (EC) No 482/2008 is extended by including all elements rather than just

software.

A very similar clause (in AMC2 ATM/ANS.OR.C.005(a)(2)) provides the same


6. Appendices






level of regulation for the safety support assurance of changes to the functional systems of service providers other than ATS providers

Annex II — Part D.2

AMC2 ATS.OR.205(a)(2)(b),(c) &

(d)

AMC2 ATM/ANS. OR.C.005 (a)(2)(b),(c) & (d)

ATM/ANS.OR uses the term ‘safety criteria’ to describe measurable properties that can be validly related to safety. They are higher level than system safety requirements and so ensure that requirements are placed on every part affected by the change, which, by definition, includes software, thus, satisfying the intent of Regulation (EC) No 482/2008 for software. It also broadens the intent of Regulation (EC) No 482/2008 by encompassing

every other part affected by the change. The requirements have to be traced to the level at which there is assurance that they have been satisfied. In most cases, this will be at the level of some software component, consequently, the clause applies to software even though this is not

specifically mentioned.

A very similar clause (in AMC2 ATM/ANS.OR.C.005(a)(2)) provides the same level of regulation for the safety support assurance of changes to the

functional systems of service providers other than ATS providers.


6. Appendices



6.3. Appendix III — List of items to be covered in the second NPA

The following is a non-exhaustive list of items that may be addressed in the second NPA on

assessment of changes to functional systems by service providers in ATM/ANS and the

oversight of these changes by competent authorities:

— GM/AMC for the CA on continuous oversight, e.g. to the provisions in

ATM/ANS.AR.C.010(a)(5) and (a)(6);

— GM for the CA on risk-based review, i.e. to the provisions in ATM/ANS.AR.C.040(b);

— GM/AMC for the CA to review other aspects of changes, e.g. to the provisions in

ATM/ANS.AR.C.040 (a) & (c));

— GM for the CA’s decision to review a safety support assurance case elaborated from

service providers other than ATS;

— Provisions for the coordination of CAs during the oversight of multi-actor changes;

— GM/AMC for the CA and for the service providers on the handling of multi-actor

changes;

— GM/AMC on changes drivers, e.g. to the provisions in ATM/ANS.OR.B.005 (a)(5) and

(a)(6)); and

— GM/AMC on the safety of the changes, e.g. to the provisions in ATS.OR.200(b) and

(c)).

Date post:	22-Mar-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

European Aviation Safety Agency Notice of Proposed Amendment 2014 … · 2014-06-24 · European...

Documents