initial guide v14

8/8/2019 Initial Guide v14

1/57

EUROPEAN ORGANISATIONFOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

EUROCONTROL REGULATORY UNIT

INITIAL GUIDELINES FOR THECONFORMITY ASSESSMENT OF EATMN

SYSTEMS

Edition Number : 1.4Edition Date : 20 March 2006Status : Proposed IssueIntended for : General PublicCategory : Working Document


2/57

INITIAL GUIDELINES FOR THE CONFORMITY ASSESSMENT OF EATMN SYSTEMS

Page ii Proposed Issue Version 1.4

DOCUMENT CHARACTERISTICS

TITLE

INITIAL GUIDELINES FOR THE CONFORMITYASSESSMENT OF EATMN SYSTEMS

Reference:

Document Identifier Edition Number: 1.4

Edition Date: 20 March 2006

Abstract

This document presents the initial guidelines for the conformity assessment of EATMNsystems.

KeywordsConformity assessmentTechnical fileEC Verification of EATMNSystemsConformity Assessment Plan

Contact Person(s) Tel Unit

Mr Jean-Paul DORE +32 2 729 36 23 DG/Regulatory Unit

DOCUMENT STATUS AND TYPE

Status Intended for Category

Working Draft General Public Rule

Draft RestrictedEUROCONTROL

Specification

Proposed Issue Restricted RC Guideline Released Issue Restricted RU ---------------------------------------------

Policy Document Study Report Summary of Responses Working Document

ELECTRONIC SOURCE

Path: P:\DG\RU\WORK PROGRAMME\CONFORMITY ASSESSMENT\CONFORMITYASSESSMENT TASK FORCE\CASTUDIES\CA_study_SOF_O405_0106\initial_guidelines\intermediate_versions\Initial_Guidelines_V1.4.doc


3/57


4/57


DOCUMENT CHANGE RECORD

The following table records the complete history of the successive editions of the presentdocument.

EDITIONNUMBER

EDITION DATE REASON FOR CHANGEPAGES

AFFECTED

1.0 01/02/06 Initial document (draft) All sections

1.1 24/02/06 Review by CATF members All sections

1.2 06/03/06 Addition chapter 7 ; refinement about the role andresponsibility of stakeholders; introduction of

Community specifications in the generic process

Chapters 7,8, 9

1.3 09/03/06 Comments and proposed dispositions drafted inAnnex V of CATF#7-report_V1.1

Chapters 9,10

1.4 20/03/06 Update of the introduction Chapter1

Version 1.4 Proposed Issue Page iv


5/57


6/57


10.5 Verification of compliance with essential requirements ..........................................................3810.6 Verification of compliance with implementing rules ................................................................46

11 Synthesis ...........................................................................................................4711.1 Verification of compliance with essential requirements ..........................................................4711.2

Verification of compliance with the implementing rules ..........................................................49

Annex A - Template for the conformity assessment plan..........................50Annex B - Technical file for the EC verification of EATMN systems.........52Annex C - EC declaration of verification of the EATMN system................56

Table of figures

Figure 1: Scenarios and roles of ANSP ......................................................................................... 18Figure 2: Level 0 of the CA process............................................................................................... 20Figure 3: Level 1 of the CA process............................................................................................... 21Figure 4: Activity A1 ....................................................................................................................... 23Figure 5: Activity A2 ....................................................................................................................... 25Figure 6: Activity A3 ....................................................................................................................... 26Figure 7: Activity A4 ....................................................................................................................... 27Figure 8: Activity A5 ....................................................................................................................... 28Figure 9: Activity A6 ....................................................................................................................... 29Figure 10: Activity A7 ..................................................................................................................... 30Figure 11: Activity A8 ..................................................................................................................... 31Figure 12: Activity A9 ..................................................................................................................... 32Figure 13: Top-down activity flow diagram..................................................................................... 33Figure 14 : Case of several systems within the same ATSU......................................................... 35Figure 15: EC verification against essential requirements............... Error! Bookmark not defined.Figure 16: Reference materials...................................................................................................... 39

Table of tables

Table 1 : Activity A0: Highest level of description of the CA process ............................................ 20Table 2 : Activity A1 of the CA process.......................................................................................... 23Table 3 : Activity A2 of the CA process.......................................................................................... 25Table 4 : Activity A3 of the CA process.......................................................................................... 26Table 5 : Activity A4 of the CA process.......................................................................................... 27Table 6 : Activity A5 of the CA process.......................................................................................... 28

Version 1.4 Proposed Issue Page vi


7/57


Table 7 : Activity A6 of the CA process.......................................................................................... 29Table 8 : Activity A7 of the CA process.......................................................................................... 30Table 9 : Activity A8 of the CA process.......................................................................................... 31Table 10 : Activity A9 of the CA process........................................................................................ 32Table 11 : Regulatory baseline ...................................................................................................... 37Table 12 : Verification method for the essential requirements....................................................... 40Table 13 : Assessment of compliance with ICAO SARPs ............................................................. 43Table 14 : ER Safety: Assessment of compliance ......................................................................... 45Table 15: Summary of the verification activities............................................................................. 49

Version 1.4 Proposed Issue Page vii


8/57


1 INTRODUCTION

This document presents the initial guidelines for the conformity assessment of EATMN

systems. It takes into account the outcome of discussions within the Conformity AssessmentTask Force (CATF), including written comments received.

Two key elements have influenced the drafting of these initial guidelines:

The obligation to meet the requirements relating to the conformity assessmentspecified in the interoperability regulation.

The necessary pragmatic measures to implement conformity assessment activitiesbased where possible, on current practices.

These guidelines provide guidance material for the preparation of the conformity assessmentplan, which is the master document for the organization and management of the verificationactivities.

The priority objective is now to validate these initial guidelines through practical experience,including pilot trials which could be supported by the Regulatory Unit (RU). Such practicalvalidation is seen as a prerequisite before formal wide stakeholders consultation isperformed with a view to give the document the status of EUROCONTROL Guidelines asdescribed in the EUROCNTROL Regulatory and Advisory Framework (ERAF).

Version 1.4 Proposed Issue Page 8


9/57


2 DOCUMENT STRUCTURE

This document is structured as follows:

Chapter 1 presents an introduction to the initial guidelines,

Chapter 3 presents the progressive application of conformity assessment of systems,

Chapter 4 presents the list of reference documents,

Chapter 5 presents the list of abbreviations,

Chapter 6 describes the objective of these initial guidelines,

Chapter 7 underlines the key points for the definition of the generic process for theconformity assessment of EATMN systems

Chapter 8 describes the role and responsibility of stakeholders involved in the conformityassessment of an EATMN system,

Chapter 9 introduces the generic process for the conformity assessment of an EATMNsystem,

Chapter 10 provides guidance material for the EC verification of an EATMN system,

Chapter 11 presents a synthesis of the EC verification activities,

Annex A - Template for the conformity assessment plan,

Annex B - Contents of the technical file,

Annex C - Template for the EC declaration of verification of an EATMN system.



10/57


3 PROGRESSIVE APPLICATION OF CONFORMITY ASSESSMENT OFSYSTEMS

The essential requirements shall apply to EATMN systems and constituents ordered after20th April 2004 (20th day following the publication of the interoperability Regulation in theOfficial Journal of the European Union) and put into service from 20th October 2005onwards.

The implementing rules refining essential requirements of the interoperability Regulation aredeveloped and put into force progressively. It entails that the regulatory baseline applicableto EATMN systems will evolve progressively.

In the future, these initial guidelines will be enriched to address a wider regulatory baselineincluding implementing rules and further refinement in the definition of EATMN systems.



11/57


4 REFERENCE DOCUMENTS

The following reference documents are used in this report:

[Reference 1]: Regulation (EC) No 552/2004 of the European Parliament and of theCouncil of 10 March 2004 on the interoperability of the European AirTraffic Management network (the interoperability Regulation)

[Reference 2]: ATM Operational Concept, Volume 2, Concept of Operations

[Reference 3]: Council Decision 93/465/EEC of 22 July 1993 concerning themodules for the various phases of the conformity assessmentprocedures

[Reference 4]: Guide to the Implementation of Directives based on the New

Approach and the Global Approach/ European Commission.

[Reference 5]: - Common requirements on safety (safety management system,safety requirement for risk management and mitigation withregard to changes, safety requirements for engineering andtechnical personnel undertaking operational safety relatedtasks).

- ESARR6, Software in ATM systems.



12/57


5 ABBREVIATIONS

ANSP Air Navigation Service Provider

ATC Air Traffic Control

ATM Air Traffic Management

ATS Air Traffic Services

CA Conformity Assessment

CATF Conformity Assessment Task Force

CONOPs Concept of Operations

CS Community Specification

ATM/CNS Air Traffic Management/Communication, Navigation, Surveillance

EASA European Aviation Safety Authority

EATMN European Air Traffic Management Network

EATMP European Air Traffic Management Plan

EC European Community

EEC European Economic Community

ER Essential Requirement

ESARR EUROCONTROL Safety Regulatory Requirement

EUROCAE EURopean Organisation for Civil Aviation Equipment

ICAO International Civil Aviation Organisation

IR Implementing Rule

ISO International Standard Organisation

NB Notified Body

NSA National Supervisory Authority

RC Regulatory Committee

RU Regulatory Unit

SARP Standard And Recommended Practices

SES Single European Sky

SRC Safety Regulation CommitteeSRU Safety Regulation Unit



13/57


6 OBJECTIVE

The objective of these initial guidelines is to provide guidance materials for the harmonisationof the conformity assessment of EATMN systems.

To achieve this objective, the following points are addressed:

1. The key points for the definition of a generic process for the conformity assessment ofEATMN systems.

2. The role and responsibility of stakeholders involved in the conformity assessment ofEATMN systems.

3. The definition of a generic process for the conformity assessment of EATMNsystems. This process describes the different tasks, intermediate and final productsto carry out the conformity assessment of EATMN systems and to issue the EC

declaration of verification of system with its associated technical file.4. The preparation of the EC verification1 of an EATMN system with the description of

the system and the regulatory baseline applicable to this system.

5. The application of the EC verification to the EATMN system with practical guidance toimplement the EC verification.

Upon successful completion of the EC verification and before the putting into service of theEATMN system, the ANSP shall issue:

The EC declaration of verification of the EATMN system and the associated technicalfile.

As of today, the regulatory provisions applicable to EATMN systems correspond to theessential requirements and the implementing rules on Co-Ordination TRansfer (COTR) andInitial Flight PLan (IFPL). Further regulatory provisions specified in implementing rules willapply progressively to EATMN systems. These guidelines will be further refined with theemergence of implementing rules.

1Art 6 of Ref[1], Systems shall be subject to an EC verification by the ANSP ()



14/57


7 KEY POINTS FOR THE DEFINITION OF THE GENERIC PROCESS FOR THECONFORMITY ASSESSMENT OF EATMN SYSTEMS

7.1 Evolution of regulatory provisions applicable to EATMN systems

These initial guidelines are proposed as a first step focused on the EC verification ofcompliance of EATMN systems. The proposed process is open to accommodate two sourcesof regulatory provisions, the essential requirements and future regulatory provisions ofinteroperability implementing rules. Implementing rules are developed progressively andconsequently, regulatory provisions applicable to EATMN systems will also evolveprogressively.

7.2 Production of items for the EC declaration and the technical file

The process is designed to meet the basic requirements of the interoperability regulationrelating to the verification of compliance of EATMN constituents and systems. In particular, itis organised to produce all items required for the EC declaration of verification and thetechnical file. The following is an excerpt of Annex IV of the interoperability Regulation:

The technical file accompanying the EC declaration of verification must contain allthe necessary documents relating to the characteristics of the system, including theconditions and limits of use, as well as the documents certifying conformity ofconstituents where appropriate.

The following documents shall be included as a minimum:

- where a notified body has been involved in the verification of the system(s), acertificate countersigned by itself, stating that the system complies with thisregulation and mentioning any reservations recorded during performance ofactivities and not withdrawn,

- where there has not been involvement of a notified body, a record of the testsand installation configurations made with a view to ensuring compliance withessential requirements and any particular requirements contained in therelevant implementing rules for interoperability.

A copy of the technical file must be kept by the provider throughout the service life ofthe system. It must be sent to any other Member States which so request.

The process takes due account of the possible intervention of notified bodies to the extent itimpacts the contents of the EC declaration or the technical file.

7.3 Means of compliance and presumption of conformity

A means of compliance specifies a technical or procedural solution that ensures compliancewith essential requirements and regulatory provisions of implementing rules. Communityspecifications and EUROCONTROL specifications can give a presumption of conformity withidentified essential requirements and regulatory provisions of implementing rules, when thereference numbers of these specifications are published in the Official Journal of theEuropean Union by the Commission. In the absence or in complement to Communityspecifications other documents such as EUROCONTROL specification, ICAO or EUROCAEdocuments can be proposed as means of compliance. When an EATMN system implements



15/57


community specifications, there is no need to justify that these specifications are means ofcompliance with identified essential requirements and regulatory provisions of implementingrules. When an EATMN system implements other international standards or proprietarytechnical specifications, the ANSP must justify that these specifications can be considered asmeans of compliance with a set of essential requirements and regulatory provisions ofimplementing rules.

7.4 Scope of the verification of an EATMN system

The verification of an EATMN system applies to an EATMN system installed into itsoperational environment before its putting into service. The ANSP responsible for the ECdeclaration of verification of system is responsible for the verification of the EATMN system.This responsibility is clearly different from the specification of needs of a system, the design,development and factory integration of a system even if some ANSPs may be involved in allof these activities.

The verification of an EATMN system is broken down into 4 main verification tasks (seeAnnex IV (2) of the interoperability Regulation:

Verification of the overall design, T1

Verification of the development and integration of the system, T2

Verification of the system in its operational environment, T3

Verification of the maintenance procedures, T4.

Verification tasks T1 and T2 apply to documents produced during the design anddevelopment phases of the system under the responsibility of other entity (ies).

Verification task, T3 aims at ensuring that the EATMN system is interoperable in itsoperational environment and complies with the applicable requirements (interoperabilityRegulation and relevant implementing rules).

Verification task, T4 aims at ensuring that the maintenance procedures comply withapplicable regulatory provisions, if any.

For the sake of supervision of compliance, the NSA may require the inclusion of specificverification results of T1 to T4 into the technical file.

7.5 Upgrade of an EATMN system

The EC declaration of an EATMN system is valid as long as:

The regulatory baseline does not evolve, There is no upgrade impacting the operational characteristics of the system.

The regulatory baseline applicable to a given system may evolve when a new implementingrule enters into force. In that case, the EC verification must take due account of these newregulatory provisions.The implementation of an upgrade of an EATMN system must give rise to an update of theEC verification if and only if this upgrade has an impact upon its operational characteristics orperformances (modification of controllers HMIs, modification of capacity to support air traffic,



16/57


modification of messages exchanged with external systems,). The impact of an upgradewith respect to the EC verification must be assessed and agreed with the NSA.



17/57


8 ROLE AND RESPONSIBILITY OF STAKEHOLDERS

8.1 Role and responsibility with respect to the lifecycle of EATMN systems

The role and responsibility of stakeholders involved in the conformity assessment of EATMNsystems are defined as follows:

System Customer: Responsible for the capture of needs, the drafting of usersrequirements and elements of the system definition, and also the final acceptance ofthe system from the system developer.

System Designer: Responsible for the design of the system in accordance with theusers requirement and the elements of system definition provided by the systemcustomer.

System Developer: Responsible for the development and integration of systemelements in accordance with the design of the system provided by the systemdesigner.

System Verifier: Responsible for the EC verification of the EATMN system installed inits operational environment by the system developer.

Three different scenarios in the development and putting into service of EATMN systems areidentified:

First scenario: ANSP is the manufacturer of the overall system Second scenario: ANSP procures a subset of constituents of the system

Third scenario: ANSP procures the overall system

Note: The scenario depends usually on the kind of system. The first scenario can apply to anANSP for a given system, and another scenario can apply for another system.

The different areas of responsibility for each of these roles in the three different scenarios areillustrated in the figure below:



18/57


Lifecycle of the system

2nd scenario: ANSP :defines its needsdefines the system according to itsneeds,is the manufacturer of the systemprocures a subset of constituents

Captureof needs

Definition ofthe system

Systemdesign

Development

Factorysystem

Integration

On-sitesystem Integration

EC declarationof verification

1st scenario: ANSP :

defines its needsdefines the system according to itsneeds,

is the manufacturer of the system

3rd scenario: ANSP :defines its needs

procures the system (is not themanufacturer of the system)

For all scenarios: ANSP :Is responsible for the verification ofthe EATMN system ConformityAssessment ofanEATMN system

System documentation EC declaration of verification ofsystem

AO

Decision:Either to modify anexistingsystemOr to createa new system

Technical fileEATMN referencearchitecture

System customer System designer/customer

System customer

System customer

System verifier

System designer/customer

System customer

Putting intoservice the

EATMN system

System

developer

External manufacturer(s)

System

designer

System

designer

System

developer

System

designer

System

designer

System

developer

System

designer

System

designer

External manufacturer

Figure 1: Scenarios and roles of ANSP

8.2 Role and responsibility of the notified body

The role and responsibility of the notified body for the verification of systems are described

as follows.

1. The ANSP responsible for the verification of an EATMN system can (or shall ifrequested in the implementing rule) subcontract some verification tasks to anotified body. The notified body is not empowered to assess the compliance of theEATMN system with relevant Regulations. The notified body provides verificationresults in the context of the verification tasks subcontracted by the ANSP. Thenotified body can judge whether the verification results are in accordance with theexpected results (as specified in the verification specifications). The verificationtasks subcontracted to the notified body are defined by specific procedures in theapplicable implementing rules.

2. The notified body draws up a certificate of conformity (not to be confused withthe EC declaration of conformity of constituents) covering the verification taskswhich have been subcontracted by the ANSP. This certificate of conformity isdelivered by the notified body to the ANSP. This certificate of conformity is notincluded into the technical file.

3. The notified body countersigns the certificate drawn up by the ANSP stating thatthe system complies with the interoperability Regulation and mentioningreservations, if any. This certificate, included in the technical file, is used whenverification tasks are subcontracted to a notified body. This certificate is differentfrom the certificate of conformity. The countersignature by the notified body

testifies that the verification tasks have been successfully achieved with



19/57


reservations, if any. If the certificate countersigned by the notified body is includedin the technical file there is no need to add any other evidence materials such asverification results, records of tests, etc.



20/57


9 GENERIC PROCESS FOR THE CONFORMITY ASSESSMENT OF AN EATMNSYSTEM

The process is defined in terms of diagrams inspired from the SADT (Structured Analysisand Design Technique) method.

The following figure represents the highest level of description of the generic process:

Conformity Assessment of an

EATMN system

System documentation EC declaration of verification of system

AO

Decision:Either to upgrade an existing systemOr to develop a new system

Technical fileEATMN referencearchitecture

Figure 2: Level 0 of the CA process

Note: The heading lines of the EATMN reference architecture are given in the Annex I of theinteroperability Regulation.

Activity A0 Conformity assessment of an EATMN system Traceability to theregulatoryrequirements

Activity The activity aims at assessing the conformity of an EATMN system against

the SES interoperability regulation and its IRs.

552/2004 Chapter

IIIControl The activity is triggered by an ANSPs decision to develop and install a new

system or to upgrade an existing system.

Inputs EATMN reference architecture:

identifies and defines the EATMN reference systems andconstituents

System documentation (not directly related to the interoperability regulationand its IRs):

describing the system as a whole, and identifying therequirements that the system shall implement

describing the architecture of the system

technical specifications and Community specifications (CS) used

for procurement of the system.

Outputs EC declaration of verification of the EATMN system

technical file.

552/2004 ChapterIII

Mechanisms Not identified at this level.

Table 1 : Activity A0: Highest level of description of the CA process

The following figure describes a first refinement of the process.



21/57


Verificationofthe

operationalsystem

Verificationofthe

developmentand

integrationofthe

system

Verificationofthe

specificsystem

maintenance

provisions

Verificationofthe

overalldesign

Systemdocumentation

Determinationoftheon-site

EATMN

system

Determinationofthe

regulatorybaseline

Implementingrules

Decision:

Eithertoupgradeanexistingsystem

Ortodevelopanew

system

EATMN

Systemdescription

A1

A2

MakingtheEC

d

eclaration

Making

thetechnicalfile

A8

Guidelinesfor

thedetermination

oftheon-site

EATMN

system

Guidelinesfor

thedeterminationof

theregulatorybaseline

A4

A5

A6

A7

ManagementoftheCA

plan

A9

Requirements

fortheinter-operability/performance/safety

ofthesystem

A3

Verification

results

Verification

results

Verification

results

Verification

results

CAplan

CAplan:

-Elementsubmittedtoverification

-Verificationspecification

-Verificationenvironment

EC

declarationofverificationofsystem

Technicalfile

CArequirements

(implementingrules)

Guidelinesfor

themanagementofthe

CAplan

CAplan:Verificationprotocol

EATMN

reference

architecture

Otherinputs

PreparationoftheECverification

ExecutionoftheECverification

Essentialrequirements

Verificationofthe

operationalsystem

Verificationofthe

developmentand

integrationofthe

system

Verificationofthe

specificsystem

maintenance

provisions

Verificationofthe

overalldesign

Systemdocumentation

Determinationoftheon-site

EATMN

system

Determinationofthe

regulatorybaseline

Implementingrules

Decision:

Eithertoupgradeanexistingsystem

Ortodevelopanew

system

EATMN

Systemdescription

A1

A2

MakingtheEC

d

eclaration

Making

thetechnicalfile

A8

Guidelinesfor

thedetermination

oftheon-site

EATMN

system

Guidelinesfor

thedeterminationof

theregulatorybaseline

A4

A5

A6

A7

ManagementoftheCA

plan

A9

Requirements

fortheinter-operability/performance/safety

ofthesystem

A3

Verification

results

Verification

results

Verification

results

Verification

results

CAplan

CAplan:

-Elementsubmittedtoverification

-Verificationspecification

-Verificationenvironment

EC

declarationofverificationofsystem

Technicalfile

CArequirements

(implementingrules)

Guidelinesfor

themanagementofthe

CAplan

CAplan:Verificationprotocol

EATMN

reference

architecture

Otherinputs

PreparationoftheECverification

ExecutionoftheECverification


Figure 3: Level 1 of the CA process



22/57


The process breaks down into two main streams activities:

The first set, hereinafter designated as Preparation of the EC verification, gathers thefollowing two activities:

The determination of the EATMN system (in its operational environment) subject toan EC verification. The EATMN system is the counterpart of an EATMN referencesystem (identified and defined in the EATMN reference architecture) in a givenoperational environment.

The determination of the regulatory baseline. It consists of selecting the relevant partsof interoperability regulatory provisions which apply to the EATMN system.

The second set, hereinafter designated as Execution of the EC verification, gathers thefollowing activities:

The drafting of the conformity assessment plan, which is the master documentsupporting the EC verification of the EATMN system.

The 4 verification tasks identified in Annex IV (2) of the Regulation (EC) 552/2004.

The making of the technical file to be delivered to the national supervisory authority.

The making of the EC declaration of verification to be delivered to the nationalsupervisory authority.



23/57


9.1 Determination of the on-site EATMN system

The following figure describes the activity:

System documentation Determination of the on-site EATMNsystem

Decision:Either to upgrade an existing systemOr to develop a new system

A1

Guidelines forthe determination

of the on-siteEATMN system

EATMN referencearchitecture

EATMN systemdescription

Figure 4: Activity A1

Activity A1 Determination of the on-site EATMN systemTraceability to theregulatoryrequirements

ActivityThe activity aims at describing the EATMN system subject to ECverification in its operational environment.

552/2004 ChapterIII

ControlThe activity is triggered by the ANSPs decision to develop and install anew system or to upgrade an existing system.

Inputs

EATMN reference architecture:

identifies and defines the EATMN reference systems andconstituents (see note 1 below),

System Documentation (not directly related to Regulations):

describing the system as a whole, and identifying therequirements that the system shall implement,

describing the architecture of the system,

operational service and environment definition (OSED).

Outputs

EATMN system description for the purpose of the CA addressing:

cross-traceability to the EATMN reference architecture,

functions/services,

constituents,

HMIs (operators dialogues),

external interfaces,

technical specifications and Community specifications (CS) usedfor procurement of the system.

552/2004 Annex IV

Mechanisms Guidelines for the determination of the on-site EATMN system.

Table 2 : Activity A1 of the CA process



24/57


Note:

When a constituent is identified in an implementing rule, manufacturers of thisconstituent shall issue an EC declaration of conformity.

Any manufacturer can develop a constituent of its own and issue an EC declaration ofconformity with relevant interoperability provisions. The constituent is identified by themanufacturer.

The ANSP can require an EC declaration of conformity with relevant interoperabilityprovisions for a constituent developed by a manufacturer. The constituent is identifiedby the ANSP.



25/57


9.2 Determination of the regulatory baseline


Determination of the regulatory

baseline

EATMNsystem description

A2

Guidelines for

the determination ofthe regulatory baseline

Requirementsfor the inter-operability/performance/safetyof the EATMN system

Essential requirements

CA requirements(Implementing Rules)

Implementing rules


Activity A2 Determination of the regulatory baselineTraceability to theregulatoryrequirements

ActivityThe activity aims at determining all regulatory requirements applicable tothe EATMN system.

Control The activity is dependent upon the EATMN system description

Inputs

Essential requirements (ER1 to ER7) as specified in the interoperability

regulation.

Implementing rules addressing interoperability targets supported by theEATMN system.

552/2004 Annex I

IRs

Outputs

Filtered requirements for the interoperability/performance/safetyaddressing interoperability targets supported by the EATMN system:

among the essential requirements

among the regulatory provisions specified in the relevant IRs,

Filtered CA requirements:

identified in the relevant IRs.

552/2004 Annex I

IRs

Mechanisms Guidelines for the determination of the regulatory baseline.




26/57


9.3 Management of the CA plan


Management of theCA plan

A3

Guidelines for

the management of theCA plan

EATMNsystem description

Requirementsfor theinter-operability/performance/safetyof the system

CA plan

CA requirements(implementing rules)


Activity A3 Management of the CA planTraceability to theregulatoryrequirements

ActivityThe activity aims at elaborating the CA plan, describing the verificationtasks of the EATMN system.

ControlThe activity is constrained by the CA requirements specified into therelevant IRs.

IRs: Specificannexes

InputsEATMN system descriptionRequirements for the interoperability/performance/safety of the EATMNsystem.

552/2004 Annex 1IRs: Specificannexes

Outputs

The CA plan describes:

the EATMN system,

the regulatory baseline,

the verification tasks as required by Annex IV of theinteroperability regulation:

Verification protocols,

Verification specifications,

Elements submitted to verifications,

Verification environment,

the verification coverage of the verification tasks.

Mechanisms Guidelines for the management of the CA plan.




27/57


9.4 Verification of the overall design


Verification of the overalldesign

CA Plan: Verification protocol

Verificationresults

CA plan:-Element submitted to verification-Verification specification-Verification environment

Technical specificationA4

Community specifications


Activity A4 Verification of the overall designTraceability to theregulatoryrequirements

Activity

The activity aims at verifying that the system:

is designed as an assembly of constituents,

is designed to meet the provisions of the regulatory baseline.

552/2004

Annex IV.2

ControlThe activity is conducted in accordance with the verification protocoldefined in the CA plan.

Inputs

The CA plan,

Technical specifications and Community specifications required for theprocurement of the system.

Outputs

The verification results contain in particular:

evidence that the overall design defines an assembly ofconstituents,

evidence that the system meets the provisions of the regulatorybaseline,

evidence that the system meets the technical specifications andCommunity specifications (CS) used for procurement of thesystem.

Mechanisms None.




28/57


9.5 Verification of the development and integration of the system


Verification of the developmentand integration of the system


Verificationresults

A5


Technical specification



Activity A5 Verification of the development and integration of the system Traceability to theregulatoryrequirements

Activity

The activity aims at verifying that the system:

is developed and integrated in accordance with the overall design,

and complies with the provisions of the regulatory baseline in afactory verification environment.

552/2004

Annex IV.2


Inputs

The CA plan.

Technical specifications and Community specifications required for theprocurement of the system.

Outputs


evidences that the system is developed and integrated inaccordance with the overall design,

evidence that the system is developed and integrated inaccordance with the technical specifications and Communityspecifications (CS) used for procurement of the system,

the verification of the integration of the system in a factoryenvironment.

552/2004

Annex IV.3

Mechanisms None.




29/57


9.6 Verification of the operational system


Verification of the operationalsystem


Verificationresults

A6



Activity A6 Verification of the operational system Traceability to theregulatoryrequirements

ActivityThe activity aims at verifying that the EATMN system in its operationalenvironment complies with the provisions of the regulatory baseline.

552/2004

Annex IV.2


Inputs The CA plan.

Outputs


the verification coverage,

the result of verifications,

a record of the verifications, installation configurations,

reservations, if any.

552/2004

Annex IV.3

Mechanisms None.




30/57


9.7 Verification of the specific system maintenance provisions


Verification of the specificsystem maintenance

provisions


Verificationresults

A7



Activity A7 Verification of the specific system maintenance provisionsTraceability to theregulatoryrequirements

ActivityThe activity aims at verifying that the maintenance procedures of theEATMN system comply with system maintenance regulatory provisions ofthe regulatory baseline, if any.

552/2004

Annex IV.2


Inputs The CA plan.

Outputs


the verification coverage,

the result of verifications, a record of the verifications,

installation configurations,

reservations, if any.

552/2004Annex IV.3

Mechanisms None.




31/57


9.8 Making the technical file


Making the technical file Technical fileTechnical specifications

A8

CA Plan

Verification results

Certificates of conformity


EC declaration ofconformity of constituents


Activity A8 Making the technical file

Traceability to the

regulatoryrequirements

ActivityThe activity aims at collecting and consolidating the material required bythe technical file.

552/2004

Chapter III Article 6

Control The activity is dependent upon the Regulation 552/2004.552/2004

Annex IV.3

Inputs

The CA plan,

The verification results,

The technical specifications used for procurement,

The community specifications used for procurement,

The certificate(s) of conformity of the notified bodies,

The EC declaration of conformity of constituents.

Outputs

The technical file which contains the following elements:

the relevant part of technical specifications used for procurement,

where appropriate, the Community specifications (CS),

the list of constituents of the EATMN system,

the copies of EC declarations of conformity for those procuredconstituents submitted to IRs,

the certificate(s) of conformity of the notified bodies,

the record of the tests and installation configurations (if noinvolvement of notified bodies).

552/2004


Mechanisms None.




32/57


9.9 Making the EC declaration of conformity


Making the EC declarationTechnical file

A9

EC declaration ofverification of system


Activity A9 Making the EC declaration of verification of systemTraceability to theregulatoryrequirements

Activity The activity consists in making the EC declaration of verification of system.552/2004


Control The activity is dependent upon the regulation 552/2004.552/2004

Annex IV.2

Inputs

The technical file, which provides for this purpose:

the brief description of the system (through the CA plan),

the regulation references (through the CA plan),

the description of the procedure followed in order to declareconformity of the system (through the CA plan),

the references of the documents contained in the technical file,

the relevant temporary or definitive provisions to be complied with

by the systems.

Outputs The EC declaration of verification of system.552/2004


Mechanisms None.




33/57


10 APPLICATION OF THE EC VERIFICATION TO AN EATMN SYSTEM

10.1 Top-down activity flow diagram

The figure below presents a top-down flow diagram driven by questions and answers for theorganisation of conformity assessment activities.

Newsystem

Description of the newsystem

Is this new systemsubmitted to an EC

declaration ?

Initiate the CA process

YesNote : The CA process may start from the

beginning of the V-cycle

What is theregulatory baseline

that the system shallcomply with ?

Select the relevant ERs

Note : This description is necessary for theCA Plan as well as for the content of the

Technical file and the EC declaration

How to describethe verificationof compliance ?

For the ERs:1) Presumption ofcompliance (CS)2) Assessment ofcompliance to:

CONOPS

SARPSEUROCAE

ANSP documents

Note : In the CA plan, the verification ofconformity is planed to be performed:For CONOPS, through a paper-basedrationale demonstrating that the futuresystem is compliant with its relevant partsFor SARPS and EUROCAE, through a paper-based rationale demonstrating that the futuresystem is designed (or procured) inaccordance withFor the ANSP documents, through a paper-based rationale demonstrating that the futuresystem is compliant with the relevantproprietary technical specifications

Note : The relevant ERs must be identified aspart of the requirements gathered for

designing the system. As such, they must beidentified in the early stages of the V-cycle.

How tomanage/describe/org-anize the CA tasks ?

Realize a CA PlanNote : The CA P lan may be initiated during

the early stages of the V-cycle

Activity of theCA process

How to verify thesystem ?

For ERs, by claimingpresumption of compliance(CS) or by performing the

assessment of compliance

For IRs, by providingevidences that the system

takes them into account, andcarrying out tests

Note : For the assessment of compliance,this verification is performed through the

analysis of documents produced during theV-cycle, and formalized in the paper-based

rationale

Note : The initial guidelines will be completed

How to finalize theCA ?

Realize the Technical file andthe EC declaration

Note : These files uses products of theprevious activities

Issue Answer Comment

A1

A2

A3

A4, A5,A6, A7

A8, A9

Select the relevant IRs Note : To be further completed

What is this newsystem ?

For the IRs:Following :-the verificationprotocols prescribed inthe IRs

Note : The initial guidelines will be completed

Preparationofthe

ECv

erification

Execution

oftheECv

erification

Figure 13: Top-down activity flow diagram



34/57


10.2 Determination of the EATMN system

The determination of on-site systems is left to the initiative of ANSPs. The description of theon-site system must comply with the definition of EATMN systems adopted for implementing

rules. As of today, the material defining EATMN systems is the systems breakdown given inAnnex I of the interoperability regulation.

In a pragmatic approach, one may consider that a system is potentially in the scope of theCA if at least:

it provides identified high-level services for the purpose of air navigation services

it can be clearly identified as belonging to one of the 8 groups of systems given inAnnex 1 of the Interoperability Regulation :

o Group N1: Systems (and procedures) for airspace management.

o Group N2: Systems (and procedures) for air traffic flow management.

o Group N3: Systems (and procedures) for air traffic services (in particular

flight data processing systems, surveillance data processing systems andhuman-machine interface systems).

o Group N4: Systems (and procedures) for ground-to-ground, air-to-groundand air-to-air communications.

o Group N5: Systems (and procedures) for navigation.

o Group N6: Systems (and procedures) for surveillance.

o Group N7: Systems (and procedures) for aeronautical information services.

o Group N8: Systems (and procedures) for the use of meteorologicalinformation.

The essential requirements shall apply to EATMN systems and constituents ordered after

20th April 2004 (20th day following the publication of the interoperability regulation in theOfficial Journal of the European Union) and put into service from 20th October 2005onwards.

Most often, an ANSP is responsible for several ATSUs, Air Control Centres. An ATSUprovides air traffic services in a well-bounded subpart of the EATMN. These services may besupported by the 8 groups of systems or a subset of these 8 groups.

For example, an ATSU can use three groups of EATMN systems. The ANSP may plan to putinto service individual systems belonging to each of these groups from 20th October 2005:

Systems for air traffic services (flight data processing systems, surveillance dataprocessing system, ).

Systems for communications (systems for air-ground voice communications, systemsfor ground-ground voice communications, systems for air-ground datacommunications, ).

Systems for navigation (ground navigation equipment (VOR, DME, ILS).

The ANSP should draft a high level description for each group of EATMN systems. This highlevel description should be along the following lines:

a. Operational functions supported by the group of systems.b. Interfaces supported with systems external to this group (inter and intra centres).c. Breakdown of the group of systems into individual systems.

The ANSP should indicate which individual system (in the group) is concerned by the putting

into service and is subject to the EC verification.



35/57


An ATSU provides air traffic services in a well-boundedsubpart of the SES airspace

These services are supported by a subset of the 8 groups ofsystems

These services are provided byindividual systems

(local implementation of each of the relevant group ofsystem)

ANSP

-Group i-Group j-Group k

-Individual system A belonging to group i-Individual system B belonging to group j-Individual system C belonging to group k

Each individual system is subject to an EC verification

-CA process for the individual system A-CA process for the individual system B-CA process for the individual system C

Figure 14 : Case of several systems within the same ATSU

10.3 Determination of the regulatory baseline

Seven generic essential requirements are specified in Annex II Part A of the interoperabilityregulation. They are network-wide requirements that are generally applicable to each one ofthe systems identified in Annex I. Specific essential requirements refining or complementinggeneric essential requirements are defined for some groups of systems in Annex II Part B.

ESSENTIAL REQUIREMENTSGROUPS OF SYSTEMS :

GENERAL SPECIFIC

1. AIRSPACEMANAGEMENT

Annex II, Part A,

1. Seamless operation2. Support for new concepts of operation

3. Safety

4. Civil-military coordination

5. Environmental constraints

Annex II, Part B,

1.1. Seamless operation

2. AIR TRAFFIC FLOWMANAGEMENT

Annex II, Part A,

1. Seamless operation

2. Support for new concepts of operation

3. Safety



Annex II, Part B,




36/57



GENERAL SPECIFIC

Annex II, Part A,



3. Safety



Annex II, Part B,

3.1.1. Seamless operation

3.1.2. Support for newconcepts of operation

Annex II, Part A,



3. Safety



Annex II, Part B,

3.2.1. Seamless operation


3. AIR TRAFFIC

SERVICES

Flight data processingsystems

Surveillance dataprocessing systems

Human-machine interfacesystems

Annex II, Part A,1. Seamless operation


3. Safety



Annex II, Part B,3.3.1. Seamless operation


4. COMMUNICATIONS

Annex II, Part A,



3. Safety



Annex II, Part B,


4.2. Support for newconcepts of operation

5. NAVIGATION

Annex II, Part A,



3. Safety



Annex II, Part B,


6. SURVEILLANCE

Annex II, Part A,



3. Safety



Annex II, Part B,


7. AERONAUTICALINFORMATIONSERVICES

Annex II, Part A,



3. Safety



Annex II, Part B,





37/57



GENERAL SPECIFIC

8. METEOROLOGICALINFORMATION

Annex II, Part A,



3. Safety



Annex II, Part B,



Table 11 : Regulatory baseline

Each ANSP has to define by itself the relevance of the essential requirements for each of theconsidered individual systems.

It should be noted that:

all these specific essential requirements refine two generic essential requirements,seamless operation and support of new concept of operations.

approximately two thirds of specific essential requirements specified in Annex II of theinteroperability regulation, apply to group N 3 systems for air traffic services.

The main issue facing these essential requirements is their lack of precision, not sufficient toprovide enough details for performing detailed technical verifications as prescribed in theregulation.

In fact, for the moment, these essential requirements are more general principles that the

coming systems have to fulfil, rather than true technical requirements, as usually specified byANSPs or manufacturers.

Furthermore, two of these essential requirements (ER6 and ER7) clearly deal with technicalsolutions for the logical and physical system architecture without having a comprehensiveand approved logical and physical reference architecture.

However, three implementing rules have been developed, and two of them formallyendorsed, in December 2005. It is likely that these two first implementing rules are the first ofa set of technical specifications focusing on the interoperability concerns. In the coming

years, according to the needs, the evolution of the EATMN, new implementing rules will bedeveloped.

10.4 Verification of compliance with the regulatory baseline

The generic process for the conformity assessment of systems is based on the principle of aregulatory baseline containing essential requirements and implementing rules that are putinto force progressively.

The verification of compliance is split into two parts:



38/57


The verification of compliance with essential requirements, VER.

The verification of compliance with implementing rules, VIR.

Both activities are complementary and are in keeping with the generic process. Bothactivities produce evidences to be kept within the technical file. These initial guidelines do notaddress activities relating to VIR.

The verification of compliance with essential requirements gives a general qualitativeindication about the impact of essential requirements upon EATMN systems. The verificationof compliance with essential requirements does not prejudge of the verification of compliancewith implementing rules.

10.5 Verification of compliance with essential requirements

10.5.1 Proposed approach

The proposed approach for the verification of compliance with essential requirements is tocombine two levels of verification:

Presumption of compliance granted when Community specifications declared asmeans of compliance with essential requirements are implemented by the system

Assessment of compliance against essential requirements translated into anassessment of compliance against reference materials2 contributing to theachievement of essential requirements.

An assessment of compliance is intended to show to what extent an EATMN system is

influenced by an essential requirement. The terms influenced by an essential requirementare used on purpose to leave open the nature of the dependency between essentialrequirements and the EATMN systems.

2

Recital 10 of the interoperability regulation, IRs should rely on standards developed by internationalorganisations such as EUROCONTROL or ICAO



39/57


10.5.2 Selection of reference materials

The first step for the EC verification against these essential requirements is to select the

relevant reference materials and then, to apply ad-hoc verification methods.


Referencematerials

Verification methods

Figure 15: EC verification against essential requirements

Five lines of reference materials are proposed:

Community specifications (CS) in relation to conformity assessment and essentialrequirements.

EUROCONTROL documents, [Concept of operations, ESARR6, EUROCONTROLspecifications].

ICAO documents [standards and recommended practices, SARPs, technicalmanuals].

EUROCAE documents [ED series of technical standards].

ANSP documents [proprietary technical specifications].


Referencematerials

Verification methodsEurocontrol documents:

CONOPS, ESARRs, Eurocontrol specifications

ICAO documents: SARPS,

Eurocae documents

ANSP documents

Community specifications (CS)


Referencematerials

Verification methodsEurocontrol documents:

CONOPS, ESARRs, Eurocontrol specifications

ICAO documents: SARPS,

Eurocae documents

ANSP documents

Community specifications (CS)

Figure 16: Reference materials

Note:

The community specifications are the primary reference materials.

Any use of other reference materials (different from CS) does not convey apresumption of conformity with the essential requirements.

Any use of other reference materials (different from CS) should be justified.

The following sections provide guidance materials for the assessment of compliance.



40/57


10.5.3 Verification methods for essential requirements

The following table summarises the verification methods, proposed to demonstratecompliance with essential requirements:

General essential requirements Verification method: Assessment of compliance

Seamless operation Rationale demonstrating compliance with the relevant:

part of the concept of operations [2]

SARPs, ICAO technical manuals

EUROCAE standards

proprietary technical specifications.

Support for new concepts ofoperations

Rationale identifying which main changes, as identified in the concept ofoperations [2,] are planned for implementation and for deployment intothe EATMN.

Safety Rationale demonstrating the application of safety requirements of

common requirements to the system [5].

Rationale demonstrating the application of ESARR6 [5].

Rationale demonstrating compliance with the relevant part of the ATMprocess model defined in the concept of operations [2].

Civil-military coordination

Environmental constraints To be developed.

Table 12 : Verification method for the essential requirements

The following sections provide further information about the verification methods for each ofthe essential requirements.

10.5.4 Essential requirement: Seamless operation

Seamless operation of the EATMN at all times and for all phases of flight is expressed interms of information-sharing, operational status information, common understanding ofinformation and comparable operational performances. More specifically for the flight dataprocessing system, the essential requirement explicitly makes reference to an agreed andvalidated operational concept. The same concept of operations ruling all phases of flightmust apply everywhere in the EATMN.



41/57


For each system, it is proposed that the verification of compliance with this essentialrequirement Seamless operationsrelies upon:

an assessment of compliance with the relevant part of the ATM operational processas defined in the concept of operations;

an assessment of compliance with the relevant ICAO SARPs;

an assessment of compliance with the relevant EUROCAE standards;

an assessment of compliance with the relevant proprietary technical specifications.

These four lines of reference materials are considered as potential reference materialscontributing to the achievement of seamless operation.

Use of the reference material Concept of operations:The description of the operational concept supported by the system should be given. Theassessment should also contain the traceability to the EUROCONTROL Concept ofOperations wherever applicable. For example, the description of the implementation of thelayered planning scheme under the responsibility of the ATSU and the ATM process model.

Use of the reference material ICAO SARPs and/or technical manuals:

When an EATMN system implements functions covered by ICAO SARPs and/or technicalmanuals, it is recommended to take advantage of works aiming at demonstrating compliancewith these ICAO documents. An assessment of compliance with applicable ICAO SARPs

and/or technical manuals should contain: a cross-reference to a document identifying applicable ICAO provisions.

a cross-reference to verification specifications (test plans).

a cross-reference to verification results (test reports with conclusions).



42/57


The following table illustrates which SARPs might be used for EATMN systems:

Group of systems SARP Id.

Systems (and procedures) for airspace management N/ASystems (and procedures) for air traffic flow management N/A

Systems (and procedures) for air traffic services (in particular flight dataprocessing systems, surveillance data processing systems and human-machine interface systems)

N/A

Systems (and procedures) for ground-to-ground, air-to-ground and air-to-air communications:

aeronautical fixed service (AFS)

o ATS direct speech circuits and networks

o Meteorological operational circuits, networks andbroadcast systems

o Aeronautical fixed telecommunications network (AFTN)

o Common ICAO data interchange network (CIDIN)

o Air traffic services (ATS) message handling services

o Inter-centre communications (ICC)

aeronautical mobile service: Data-link communications

aeronautical radio navigation service;

aeronautical broadcasting service

Digital Data Communication Systems:

o Aeronautical Telecommunication Network

o Aeronautical Mobile-Satellite Service

o SSR Mode S Air-ground Data Link

o VHF Air-ground Digital Link (VDL)

o AFTN Network

o Point-to-Multipoint communications

o HF data-link

Voice communication systems:

o Aeronautical Mobile Service

o SELCAL System

o Aeronautical Speech Circuits

o Emergency Locator Transmitter (ELT) for Search andRescue

Annex 10

o Volume II - Section 4.2

o Volume II Section 4.3





Volume II Section 8

N/A

N/A

o Volume III Part I - Section 3

o Volume III Part I Section 4






o Volume III Part II - Section 2




Systems (and procedures) for navigation

ILS

Precision approach radar system

VOR

NDB

DME

En-route VHF markers beacons

Global navigation satellite system (GNSS)

Airborne ADF receiving systems

Microwave landing system (MLS)

Annex 10

Volume I - Section 3.1









Systems (and procedures) for surveillance

Secondary surveillance radar (SSR) characteristics

Annex 10

Volume IV - Section 3.1



43/57


Group of systems SARP Id.

Systems (and procedures) for aeronautical information services Annex 15

Systems (and procedures) for the use of meteorological information N/A

Table 13 : Assessment of compliance with ICAO SARPs

Use of the reference material EUROCAE standards:

When an EATMN system implements functions covered by EUROCAE standards, it isrecommended to take advantage of works aiming at demonstrating compliance with thesestandards. An assessment of compliance with applicable EUROCAE standards shouldcontain:

a cross-reference to a document identifying applicable EUROCAE technicalrequirements.



a cross-reference to conformance statements when requested by EUROCAEStandards.

Use of the reference ANSP proprietary technical specifications:

When an EATMN system implements functions covered by proprietary technicalspecifications, it is recommended to take advantage of works aiming at demonstratingcompliance with these technical specifications. An assessment of compliance with applicabletechnical specifications should contain:

a cross-reference to a document identifying applicable requirements of technicalspecifications.



10.5.5 Essential requirement: Support for new concepts of operation

The EATMN shall support on a coordinated basis new agreed and validated concepts ofoperation that improve the quality and effectiveness of air navigation services. New conceptssuch as collaborative decision-making, increasing automation and alternative methods ofdelegation of separation responsibility shall be examined taking due account of technologicaldevelopments.

The EUROCONTROL concept of operations describes the concept of operations fordifferent time windows. This ConOps is defined for the timescale up to 2011 and takes due

consideration of the main changes in the forthcoming years.

For each system, it is proposed that the verification of compliance with this essentialrequirement Support for new concepts of operation relies upon an assessment ofcompliance with the foreseen main changes identified in the concept of operations.

Use of the reference material concept of operations:

The support for new concepts of operations cannot be achieved without an appropriatedefinition of concepts of operation allowing for new enabling technology and new operations.The concept of operations [2] has identified the main changes foreseen until 2011. Arationale describing which of these main changes are planned for implementation and

deployment into the EATMN will give evidence of compliance with this essential requirement.



44/57


10.5.6 Essential requirement: Safety

For each system it is proposed that the verification of compliance with this essentialrequirement safety relies upon an assessment of compliance showing the application of

safety requirements specified in common requirements to this system.Use of the reference material safety requirements specified in common requirements:

The following table shows how the assessment of compliance with the essential requirementsafety can be developed.



45/57


Safety requirements(qualitative or quantitative) :

2004/552

ANNEX II part A chapter 3:

Essential requirements - safety

Demonstration ofcompliance to safetyessential requirementachieved by :

Systems and operations of theEATMN shall achieve agreed highlevels of safety.

Establish agreed levels ofsafety:

Severity and risk classificationscheme

Application of safetyrequirements specified incommon requirements to thissystem

Agreed safety management andreporting methodologies shall beestablished to achieve this

Establish:

a safety management system

a reporting system


In respect of appropriate ground-based systems, or parts thereof,these high levels of safety shall beenhanced by safety nets which

shall be subject to agreed commonperformance characteristics.

Establish:

agreed safety requirements onsafety nets

risk classification scheme


Application of ESARR6 forsoftware

A harmonised set of safetyrequirements for the design,implementation, maintenance andoperation of systems and theirconstituents, both for normal anddegraded modes of operation, shallbe defined with a view to achievingthe agreed safety levels, for allphases of flight and for the entireEATMN.

Establish:

the life cycle of the system withregard to safety activities

agreed safety requirementsrelated to modes.



Systems shall be designed, built,maintained and operated, using theappropriate and validatedprocedures, in such a way that thetasks assigned to the control staffare compatible with humancapabilities, and are consistent withrequired safety levels in both thenormal and degraded modes ofoperation,

Establish:procedures applying to the lifecycle phase of the system aswell the safety requirements

Establish:

safety requirement and processto people, equipment ,procedures, taking account ofdifferent modes



Systems shall be designed, built,maintained and operated using the

appropriate and validatedprocedures, in such a way as to befree from harmful interference intheir normal operationalenvironment

Establish :

procedures applying to the life

cycle phase of the system aswell the safety requirements

Establish:

safety requirement and processto people, equipment ,procedures, taking account ofharmful interference with theirnormal operational environment

Application of safety

requirements specified incommon requirements to thissystem


Table 14 : ER Safety: Assessment of compliance



46/57


10.5.7 Essential requirement: Civil-military coordination

EATMN systems shall support the progressive implementation of civil/military coordination, tothe extent necessary for effective airspace and air traffic flow management, and the safe and

efficient use of airspace by all users, through the application of the flexible use of airspace.The same concept of operation including civil-military coordination must apply everywhere inthe EATMN.

For each system, it is proposed that the verification of compliance with this essentialrequirement civil-military coordination relies upon an assessment of compliance with therelevant part of the ATM operational process as defined in the concept of operations [2].

Use of the reference material concept of operations:

See 10.5.5.

10.5.8 Essential requirement: Environmental constraints

To be further investigated.

10.6 Verification of compliance with implementing rules

To be further completed.



47/57


11 SYNTHESIS

11.1 Verification of compliance with essential requirements

The table below provides a synthesis of the verification activities summarising, for each sortof requirement, the verification methods, the evidences giving credence to the complianceand the responsibilities and phasing.


ERVerification of

compliance withER is:

Verification methodapplied by the ANSP

verifier and to detail intothe CA plan

Evidence giving credence tothe compliance

(to detail into the CA plan)

Responsibility and V-

cycle phase

ER1 An assessmentof compliance(paper-based)againstICAO/EUROCONTROL/Eurocae/ANSP materials

-Rationale demonstratingcompliance with therelevant part of theconcept of operations

-When applicable(systems implementingfunctions covered byICAO/SARPs)

-When applicable(systems implementingfunctions covered byEUROCAE standards)

-When applicable(systems implementingfunctions covered by

proprietary technicalspecifications)

-Paper-based rationaledemonstrating compliancewith the relevant parts of theconcept of operations

-Cross-reference to adocument identifyingapplicable ICAO provisions

-Cross-reference to adocument identifyingapplicable EUROCAEprovisions

-Cross-reference to adocument identifyingapplicable requirements of

technical specifications

Customer(definition

phase)

Designer

(designphase)

ER2 An assessmentof compliance(paper-based)againstEUROCONTROLConops

-Rationale demonstratingcompliance with therelevant part of theconcept of operations

-Paper-based rationaledemonstrating compliancewith the relevant parts of theconcept of operations

Customer(definition

phase)

Designer

(designphase)

ER3 An assessmentof compliance(paper-based)against safetyrequirementsspecified incommonrequirements andagainst ESARR6

-Rationale demonstratingthe application of safetyrequirements specified incommon requirementsand of ESARR6

-Paper-based rationaledemonstrating compliancewith the safety requirementsspecified in commonrequirements and withESARR6

Customer(definition

phase)

Designer

(designphase)

Verificationof theoveralldesign (A4)

ER4 An assessmentof compliance(paper-based)againstEUROCONTROLConops

-Rationale demonstratingcompliance with therelevant part of theconcept of operations(ATM operational process)

-Paper-based rationaledemonstrating compliancewith the relevant parts of theconcept of operations (ATMoperational process)

Customer(definition

phase)

Designer

(designphase)

ER5 To be completed To be completed To be completed



48/57



ERVerification of







cycle phase

ER1 An assessment

of compliance(paper-based)againstICAO/EUROCONTROL/Eurocae/ANSP materials

-When applicable

(systems implementingfunctions covered byICAO/SARPs): Testingstrategy

-When applicable(systems implementingfunctions covered byEUROCAE standards):Testing strategy

-When applicable(systems implementingfunctions covered byproprietary technicalspecifications): Testingstrategy

-Cross-reference to

verification specifications(test plans)

-Cross-reference toverification results

-Cross-reference toverification results (testreports)

-Cross-reference toconformance statementswhen requested(EUROCAE)

Designer

(factorysystem

integration)

{ExternalManufactur

er}

ER2 N/A N/A N/A


-Rationale demonstratingthe application of safetyrequirements specified incommon requirementsand of ESARR6, focusingon testing strategy.


Designer(factorysystem

integration)

{ExternalManufactur

er}

ER4 N/A N/A N/A

Verification

of thedevelopment andintegrationof thesystem (A5)

ER5 To be completed To be completed To be completedER1 An assessment

of compliance(paper-based)againstICAO/EUROCONTROL/Eurocae/ANSP materials

-When applicable(systems implementingfunctions covered byICAO/SARPs): Testingstrategy

-When applicable(systems implementingfunctions covered byEUROCAE standards):Testing strategy

-When applicable(systems implementing

functions covered byproprietary technicalspecifications): Testingstrategy

-Cross-reference toverification specifications(test plans)



-Cross-reference toconformance statementswhen requested(EUROCAE)

Customer

(on-sitesystem

integrationphase)

ER2 N/A N/A N/A

Verificationof theoperationalsystem (A6)


-Rationale demonstratingthe application of safetyrequirements specified incommon requirementsand of ESARR6, focusingon testing strategy.


Customer

(on-sitesystem

integrationphase)



49/57



ERVerification of







cycle phase

ER4 N/A N/A N/A


ER1 An assessmentof compliance(paper-based)againstICAO/EUROCONTROL/Eurocae/ANSP materials

-When applicable(systems implementingfunctions covered byICAO/SARPs): Testingstrategy of specificmaintenance provisions

-When applicable(systems implementingfunctions covered byEUROCAE standards):Testing strategy ofspecific maintenance

provisions-When applicable(systems implementingfunctions covered byproprietary technicalspecifications): Testingstrategy of specificmaintenance provisions

-Cross-reference toverification specifications(test plans)



-Cross-reference toconformance statementswhen requested

(EUROCAE)

Customer

(on-sitesystem

integrationphase)

ER2 N/A N/A N/A

ER3 An assessmentof compliance(paper-based)against safety

requirementsspecified incommonrequirements andagainst ESARR6

-Rationale demonstratingthe application of safetyrequirements specified incommon requirements

and of ESARR6, focusingon testing strategy ofspecific maintenanceprovisions

-Paper-based rationaledemonstrating compliancewith the safety requirementsspecified in common

requirements and withESARR6

Customer

(on-sitesystem

integration

phase)

ER4 N/A N/A N/A

Verificationof thespecificsystemmaintenanceprovisions(A7)


Table 15: Summary of the verification activities

11.2 Verification of compliance with the implementing rules

To be further complemented.


initial guide v14

Documents